Why does the average digital TV set take so long to "come on"?

[james_s]

I'm not sure if this is representative of the market as a whole, but most of the people I know want a TV that is just a large monitor with a simple UI and a bunch of HDMI inputs. Pretty much all bigger TVs these days have built in "smart" features but very few people actually make use of them, they're almost universally terrible.

[CatalinaWOW]

The CPU/controller and firmware in the TV for sure take quite some time to initialize, depending on the TV.
And the channel change?  Yes, the I-frame is part of the equation, but there are other things that affect this.  We run all of our broadcast OTA channels with a variable GOP schema.  For us, it might take as many as 45 frames until an I frame is sent, or it might happen every frame, all depending on how much motion exists in the video.  I don't know how other broadcasters have their encoders configured, and there really is no "standard" on how many P and B frames before an I frame.
The other factors are the PSIP table repeat rates.  There are several that are sent, at different rates, and a few of them are essential to being able to put a picture on your screen, while the rest are not needed to display the picture.  The most important table is the MGT (Master Guide Table).  It's the table that describes all of the separate PIDs being sent in the program stream, including all of the other PSIP data.  Without it, your TV doesn't know what to display.  That's why we have ours set to repeat at 90 millisecond intervals.  Next up would be the VCT (Virtual Channel Table).  Again, the TV will likely not be able to display pictures until this table is received and processed.  I've set ours to repeat every 395 milliseconds.  These two tables are essential to displaying the pictures.  As such, your TV has to wait until both have been received before making those pictures visible.  I think the "standard" allows for slightly longer intervals for the MGT and VCT (I think 150ms and 400ms, respectively) So, a "channel flicker" will have to wait at least 400ms with most terrestrial broadcast stations before it's displayed.

All this goes a long ways toward explaining a phenomena on my system.  Periodically when changing channels the set will get confused, go dark and eventually come up with a resolution not supported message.  The frequency of occurrence is very heavily dependent on the channel.  Unfortunately one of the worst is the local news channel which we frequently go to.  Presumably the local channel has much lower refresh rates on these various elements of the transmission, and the set has more opportunity to get confused or have a noise event.

[SeanB]

Your news channel likely has been allocated a very low bitrate in the multiplex it is using, meaning the data rate is very low, plus they have a very long I frame interval as the typical content is low motion. Thus the long time to both decode the channel out of the stream and then get a valid frame to start the video from, plus it likely is a multiplex that is transmitted at lower power so has a higher error rate to contend with for initial acquisition in the first place. Likely a bit of work on the antenna ensuring the signal strength is both high enough, and that all connections are well made ( basically undo every F connector, clean the core and apply a bit of contact cleaner, then tighten them up again, and replace any premade leads that are made from the nastiest grade of cheap almost screened cable) and there is a good error free signal into the tuner should improve things a lot.

[SL4P]

With MJPEG, MPEG1 & MPEG2 streams of past, the streaming GOP structure was typically less than 2 seconds (I,B,P frames), but the newer codecs H.26x use much longer encoding structures, hence the 3-4-5 second wait for the next I-frame (full ‘Intracoded’ frame) equivalent.
The bandwidth efficiency goes up, but the quality for a given (spatial and temporal) resolution and frame rate drops significantly.
Money talk$.

[CatalinaWOW]

Your news channel likely has been allocated a very low bitrate in the multiplex it is using, meaning the data rate is very low, plus they have a very long I frame interval as the typical content is low motion. Thus the long time to both decode the channel out of the stream and then get a valid frame to start the video from, plus it likely is a multiplex that is transmitted at lower power so has a higher error rate to contend with for initial acquisition in the first place. Likely a bit of work on the antenna ensuring the signal strength is both high enough, and that all connections are well made ( basically undo every F connector, clean the core and apply a bit of contact cleaner, then tighten them up again, and replace any premade leads that are made from the nastiest grade of cheap almost screened cable) and there is a good error free signal into the tuner should improve things a lot.

Generally good advice on improving the situation, but this comes in through the satellite, and short, clean signal paths on my end.  The local news is a small town operation and the many signs of low budget in the production tell me that the signal problems were inserted before it ever got to the satellite provider.  Or the satellite provider is providing some "payback" for the rather contentious rate negotiations that go on between the local guys and the satellite guys periodically.

[paulca]

Switching channel delay is due to buffering.  The TV wants to get WELL ahead in the stream, like several seconds ahead so it can drop corrupt packets.  If it cannot decode an audio or video packet it has to drop the correct length of both audio and video streams to keep the audio in sync.  Even with a perfect signal all it takes is someone to switch on the oven or hoover and it will glitch.  There is error correction built into the DVB stream but it has it's limits.

Trust me, you want this.  If you ever get a raw DVB card when it plays a corrupt audio packet it "chirps" really loudly, when it plays a corrupt video packet the screen goes nuts, when it doesn't resync the A and V streams the lip sync gets out of phase.  When it runs out of buffer (or has none) then it freezes and stutters from time to time.

If the later happens anyway, and it does, use "Live pause" if you have it available to create a new buffer of a few seconds.

As to it taking ages to come on, probably because most of the TVs are just a custom built computer with a CPU and DSP which has a boot up time, possibly a warm up time on the analogue receiver and then buffering time for the selected channel.

[bson]

A modern TV is not just like a computer. It is a computer, and a perfectly good development system for its own code. In the TV development labs I've been to, people just connect a USB keyboard and mouse to a TV, and sit in from of its 65" panel developing the TV's code.

I've never seen that, but I have worked many times with Broadcom's reference boxes to create firmware for TVs, Blu-Ray players, and whatnot.  (And grown to completely hate MIPS in the process.)  Since these run Linux (usually very much the BCM stock BSP system and toolchains) it's convenient to tftpboot them from a cross build on the computer you work on when doing anything kernel or system related.  For app development they all these days have environments like Air/Flash Lite with tricks like running off a USB stick or a CIFS mount.

[bson]

Audio always leads video, so in an MTS stream the audio you receive right now correlates with future video.  This is to maintain lip sync; it's much cheaper and easier buffer and delay audio than video, then sync it to the video playback.  This means when you first start demuxing MTS you get video for which you don't yet have audio.  This delay also permits all kinds of audio processing, like surround sound and room equalization.  This means if the video lags the audio in the muxed MTS stream by 1 second there's at least a 1 second playback delay, plus whatever lag the video decode and playback pipeline introduces.  Obviously you also might suffer from large GOP sizes.

Video processors also add lag when doing cadence corrections, cadence changes, and hide bad splices that introduce cadence errors.  (This also ties into quality deinterlacing since apart from a slight stutter a cadence error can introduce field flips, where you get two odd/even fields in a row, which need to be detected and avoided as it causes horrible artifacting.)

[ez24]

I have a Hisense and the problem is it takes too long to turn off.  I have to turn it off two times and there is about a 15 second delay between each turn off.  It comes back on when I turn it off the first time.

[Chris Wilson]

I never though my post would creates as many replies, seems I am expecting too much and the old analogue sets, once warmed up were superior in instant channel locking I still run two proper CRT analogue sets with digital converters, much to my wife's disgust who gets sniffy about having "ancient old tat" about the place. She won't want to her watch her soaps on one of mine then, when her SMPS caps in her mega screen beast let go....

Thanks for all the fascinating info!