USS McCain collision ultimately caused by UI confusion

Re:USS McCain collision ultimately caused by UI confusion by oasisbob on Friday November 03, 2017 @02:19AM (#15617024)

Yes, the MPEG-2 decoder in your TV needs to be fast enough to keep up with the transmitted data rate, but that doesn't mean that it has instantaneous stream startup times.

Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC A/53 video for as long as 700ms. It needs to buffer quite a bit of timing information and at least an I-picture frame before it can start displaying anything: http://www.bretl.com/mpeghtml/startbuf.HTM

Not only that - the overall standard has tight timing tolerances to keep video arriving at the encoder/transmitter in-sync with audio/video leaving the decoder in your TV. It's not like MP3 streaming where every client has its own buffer size and time to start playing depending on network conditions, bitrate, etc.

Having a reliable buffering process to keep receivers in-sync is a feature, not a bug.

[ Parent | on HN ]

Re:USS McCain collision ultimately caused by UI confusion by dreamcompiler on Friday November 03, 2017 @02:24AM (#15617039)

And the way to solve this -- at least for the case of consecutive channel surfing -- is to have multiple decoders and multiple buffers. It's simply precaching.

[ Parent | on HN ]

Re:USS McCain collision ultimately caused by UI confusion by oasisbob on Friday November 03, 2017 @02:33AM (#15617073)

Eventually you're going to run into RF limits, especially if the signal is coming in over the air.

You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?

[ Parent | on HN ]

Re:USS McCain collision ultimately caused by UI confusion by dreamcompiler on Saturday November 04, 2017 @01:54PM (#15626109)

I'd pay extra for it. I'd pay even more for a TV that didn't spy on me and that couldn't update its firmware without my consent. But I'm probably not the target consumer.

[ Parent | on HN ]