6 ms·

The central reason is that modern video codecs use I-frames and P-frames (sometimes also B-frames; even though as far as I am aware, these are not used for TV b

The central reason is that modern video codecs use I-frames and P-frames (sometimes also B-frames; even though as far as I am aware, these are not used for TV broadcasts); see https://en.wikipedia.org/w/index.php?title=Video_compression_picture_types&oldid=916270429 https://en.wikipedia.org/w/index.php?title=Video_compression... I-frames are only sent, say, once or twice a second. When a channel is switched, the TV has to wait for the next I-frame, since P-frames (and B-frames) only encode the difference to the previous I-frame (or to the previous and next I-frame in the case of B-frames). If you are aware of a possibility for efficient video compression that avoids this problem, tell the HN audience; the really smart people who developed the video codecs apparently have not found a solution for this. ;-) Otherwise complain to your cable provider that they do not send more I-frames to decrease the time to switch between channels (which would increase the necessary bandwidth).

jasonjayr 7y ago
Cache the most recent iframe on the network and have the STB pull + display the cached iframe till it catches up? This would enable fast channel scanning/flipping at the very least ...
- wmf 7y ago
  IIRC Microsoft did this in their IPTV platform.
fortran77 7y ago
No. It's not a codec problem. They can leave it on the last decoded frame and fade it nicely to, say, the average color for the 1 second without going to black, and you don't have to be a super decoder genius to implement something that's a little less aesthetically jarring.
- wolfgke 7y ago
  joncrane was complaining about the time to change channels. This approach does nothing to decrease this time.
  - ddingus 7y ago
    Exactly. It does placate users with some indication of activity. This can impact how someone feels about the change, but does nothing to solve the time to change problem. One thing it does do is confirm the change is in progress. That is a subset of the time to change problem. Many current UX on this do not give a very good, or any indicator of successful input. Quite a few people may see their feelings about the time to change improve because they can diver their attention away from the change knowing it will eventually happen.
    - wolfgke 7y ago
      > Exactly. It does placate users with some indication of activity. [...] One thing it does do is confirm the change is in progress. A black screen is also a sign that a change is in progress. But this is exactly what my parent fortran77 complained about (https://news.ycombinator.com/item?id=21835676 https://news.ycombinator.com/item?id=21835676).
      - ddingus 7y ago
        There is no making all the people happy without just changing quick, eh?
    - tomaskafka 7y ago
      You can show the program name and what's on on that black screen, this info is already available from EPG.
      - ddingus 7y ago
        That's actually a nice spiff. Doesn't entirely fix the problem, but could help with surfers looking for something interesting.
seanalltogether 7y ago
Unless I'm very mistaken about modern digital transmissions, cable coming into the house is still based on a broadcast system, which means you're getting everything all the time. The frames are all there for every channel, they're just not being read. I don't know how much processing or memory it would take to read and store frames for surrounding channels to the one you're on, but I imagine its possible.
- phonon 7y ago
  Feel free to find a chipset on the market that can decode hundreds of channels of Full HD H.264 simultaneously...
  - seriesf 7y ago
    You wouldn’t have to actually decode it, just receive it all and buffer everything after the last key frame. That eliminates waiting for the next key frame.
    - grenoire 7y ago
      Essentially waiting for I-frames as the mini-GP noted it?
    - sigstoat 7y ago
      receiving it all _is_ the problem. nobody would pay the price for an RF front end with the bandwidth to digitize the entire OTA TV portion of the spectrum. they're spread from 54MHz to 806MHz. that's 752MHz of analog bandwidth. that's huge. (i'm not even sure you could buy that frontend for love or money. ok, maybe you take advantage of the gaps and just have 3-4 frontends. now there's a correspondingly large amount of PCB space taken up, more interference issues, increased defect rate, etc)
  - gsich 7y ago
    Only your current transponder.
- jaywalk 7y ago
OrangeMango 7y ago
The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels.
- CharlesColeman 7y ago
  > The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels. That's 50 cents the shareholders can pocket, and everyone has already inured themselves to the slower experience. Isn't progress great?
  - spookthesunset 7y ago
    50 cents per unit times several hundreds of millions of units adds up to real money in a hurry. BOM costs make or break mass market hardware products. You don't just add 50 cents of BOM to a mass market item without a real good reason.
    - CharlesColeman 7y ago
      > BOM costs make or break mass market hardware products. You don't just add 50 cents of BOM to a mass market item without a real good reason. I guess the question is, why is that so? IMHO, a valid "real good reason" is fixing a product/technological UX regression. However, it seems American business practices have settled on shamelessly selling the cheapest acceptable product for the highest acceptable price. If cheaper means a little crappier and enough customers will put up with it, cheaper it is. I'm dissatisfied with it because it usually means the stuff I buy is less durable or lacking on some fit-and-finish area.
      - spookthesunset 7y ago
        Go look at all the failed hardware-based kickstarters for why BOM costs matter. It has nothing to do with “American Business”. Just a fact of life in a competitive market. Is it worth spending an extra 2-5 million in tuner chips so 100 million set top boxes can channels can change faster? You tell me?
jaywalk 7y ago
That's a big part of it. But the other part, which can actually contribute more time than the decoding, is simply slow software on the STB.
- 01100011 7y ago
  There are some terrible middleware implementations out there. I remember hearing about some early attempts from DirecTV at building a DVR. They were encoding everything in xml and sending it through IPC spaghetti. IME, the level of talent in the consumer electronics space is much less than, say, a big N company. You have a lot of EE turned sw guy types, or java-trained CS grads who don't understand performance. Now that the industry is slowly dying, it's losing even more talent.
gsich 7y ago
I think what parent also meant is input delay from the remote.
cabaalis 7y ago
I complained about the style of the article elsewhere in the thread, but this doesn't exactly disprove the point that it's objectively worse now.
zozbot234 7y ago
> When a channel is switched, the TV has to wait for the next I-frame, since P-frames (and B-frames) only encode the difference to the previous I-frame (or to the previous and next I-frame in the case of B-frames). You can apply the encoded difference to a grey (or black!) screen, the way (IIRC) VLC does in such cases. This means that the user immediately gets a hint of what's happening onscreen, especially since the audio can start playing immediately (also, often the P/B-frames replace a large portion of the on-screen content as people move around, etc.). Surely it isn't any worse than analog TV "snow". If it looks too weird for the average user, make it an "advanced" option - 'quick' channel changes or something.
- DonHopkins 7y ago
  Anyone old enough to remember the revolution of interlaced GIF files on the web? ;)
jagged-chisel 7y ago
I remember when a family member first got satellite - the tuner would change instantly, and the show would "pepper in" over a second or so until the next full frame. There's no technical reason the change can't be displayed immediately - it might not be pretty, but whether that's preferable is subjective.
- jdofaz 7y ago
  If my memory is correct that was the first directv/ussb system. I think I remember reading they were using something like a pre-finalized version of mpeg2.
Taniwha 7y ago
It's actually worse than that - first you have to tune, then you have to wait for a PAT frame (which has a index of PMTs in it), then you have to wait for a PMT (which contains pointers to the audio, video and ECM streams, and then you have to wait for an ECM (encrypted key for the stream), at that point you have have decrypted video and can start looking for I-frames .... (smart systems both cache a whole bunch of this stuff and revalidate their caches on the fly while they are tuning - first tunes after boot might be slower as these caches are filled)
Uhhrrr 7y ago
Based on my recent interview with a company that does a huge amount of livestreaming, the really smart people at least have a few ideas about this.
- Piskvorrr 7y ago
  Sure. The answer is then, probably, "it's not cost-effective to do that in COTS consumer equipment."
  - Uhhrrr 7y ago
    Remember, decoding is much cheaper. And if you own or have some control over the client, there is flexibility about how you get things. That said, it's true that there still may not be a practical solution which is better for the user than letting them wait a second.
thibran 7y ago
Why not have the previous and next channel frame-data points loaded in the background? This would enable to switch quickly, even if it costs a bit more resources on the hardware side.
pedrocr 7y ago
No need to reinvent video encoding. At least my local provider seems to fix this by having all the channels streamed as multicast continuously and then having the TV box request a small bit of video over normal TCP to do the channel switch immediately and only later syncing to the multicast. That allows you to change channels quickly at any time and starting to watch at whatever the latest I-frame was. I notice this happening when IGMP forwarding is broken in my router and channels will only play for a second or two after being switched to and then stopping. Switch times are pretty good.
taffer 7y ago
Error correction also adds some latency.
zepearl 7y ago
> If you are aware of a possibility for efficient video compression that avoids this problem, tell the HN audience etc... This is a bad comment/reply - upstream wasn't complaining about the codec but about the usability (of the devices).
- wolfgke 7y ago
  I explained that an important reason why the switching time is like that lies in the fact how modern video codecs work. Taniwha gave an important addition: https://news.ycombinator.com/item?id=21836542 https://news.ycombinator.com/item?id=21836542
tomaskafka 7y ago
Or, the TV UX designers can realize this, and make the TV respond instantly by switching eg. to channel logo plus a name of current programme (it is available from EPG) and then replacing it with video 0.5 later. This would allow a rapid channel surfing, something I haven't been able to do on any recent TV.

jasonjayr 7y ago

Cache the most recent iframe on the network and have the STB pull + display the cached iframe till it catches up? This would enable fast channel scanning/flipping at the very least ...

wmf 7y ago
IIRC Microsoft did this in their IPTV platform.

fortran77 7y ago

No. It's not a codec problem. They can leave it on the last decoded frame and fade it nicely to, say, the average color for the 1 second without going to black, and you don't have to be a super decoder genius to implement something that's a little less aesthetically jarring.

wolfgke 7y ago
joncrane was complaining about the time to change channels. This approach does nothing to decrease this time.
- ddingus 7y ago
  Exactly. It does placate users with some indication of activity. This can impact how someone feels about the change, but does nothing to solve the time to change problem. One thing it does do is confirm the change is in progress. That is a subset of the time to change problem. Many current UX on this do not give a very good, or any indicator of successful input. Quite a few people may see their feelings about the time to change improve because they can diver their attention away from the change knowing it will eventually happen.
  - wolfgke 7y ago
    > Exactly. It does placate users with some indication of activity. [...] One thing it does do is confirm the change is in progress. A black screen is also a sign that a change is in progress. But this is exactly what my parent fortran77 complained about (https://news.ycombinator.com/item?id=21835676 https://news.ycombinator.com/item?id=21835676).
    - ddingus 7y ago
      There is no making all the people happy without just changing quick, eh?
  - tomaskafka 7y ago
    You can show the program name and what's on on that black screen, this info is already available from EPG.
    - ddingus 7y ago
      That's actually a nice spiff. Doesn't entirely fix the problem, but could help with surfers looking for something interesting.

seanalltogether 7y ago

Unless I'm very mistaken about modern digital transmissions, cable coming into the house is still based on a broadcast system, which means you're getting everything all the time. The frames are all there for every channel, they're just not being read. I don't know how much processing or memory it would take to read and store frames for surrounding channels to the one you're on, but I imagine its possible.

phonon 7y ago
Feel free to find a chipset on the market that can decode hundreds of channels of Full HD H.264 simultaneously...
- seriesf 7y ago
  You wouldn’t have to actually decode it, just receive it all and buffer everything after the last key frame. That eliminates waiting for the next key frame.
  - grenoire 7y ago
    Essentially waiting for I-frames as the mini-GP noted it?
  - sigstoat 7y ago
    receiving it all _is_ the problem. nobody would pay the price for an RF front end with the bandwidth to digitize the entire OTA TV portion of the spectrum. they're spread from 54MHz to 806MHz. that's 752MHz of analog bandwidth. that's huge. (i'm not even sure you could buy that frontend for love or money. ok, maybe you take advantage of the gaps and just have 3-4 frontends. now there's a correspondingly large amount of PCB space taken up, more interference issues, increased defect rate, etc)
- gsich 7y ago
  Only your current transponder.
jaywalk 7y ago

OrangeMango 7y ago

The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels.

CharlesColeman 7y ago
> The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels. That's 50 cents the shareholders can pocket, and everyone has already inured themselves to the slower experience. Isn't progress great?
- spookthesunset 7y ago
  50 cents per unit times several hundreds of millions of units adds up to real money in a hurry. BOM costs make or break mass market hardware products. You don't just add 50 cents of BOM to a mass market item without a real good reason.
  - CharlesColeman 7y ago
    > BOM costs make or break mass market hardware products. You don't just add 50 cents of BOM to a mass market item without a real good reason. I guess the question is, why is that so? IMHO, a valid "real good reason" is fixing a product/technological UX regression. However, it seems American business practices have settled on shamelessly selling the cheapest acceptable product for the highest acceptable price. If cheaper means a little crappier and enough customers will put up with it, cheaper it is. I'm dissatisfied with it because it usually means the stuff I buy is less durable or lacking on some fit-and-finish area.
    - spookthesunset 7y ago
      Go look at all the failed hardware-based kickstarters for why BOM costs matter. It has nothing to do with “American Business”. Just a fact of life in a competitive market. Is it worth spending an extra 2-5 million in tuner chips so 100 million set top boxes can channels can change faster? You tell me?

jaywalk 7y ago

That's a big part of it. But the other part, which can actually contribute more time than the decoding, is simply slow software on the STB.

01100011 7y ago
There are some terrible middleware implementations out there. I remember hearing about some early attempts from DirecTV at building a DVR. They were encoding everything in xml and sending it through IPC spaghetti. IME, the level of talent in the consumer electronics space is much less than, say, a big N company. You have a lot of EE turned sw guy types, or java-trained CS grads who don't understand performance. Now that the industry is slowly dying, it's losing even more talent.

gsich 7y ago

I think what parent also meant is input delay from the remote.

cabaalis 7y ago

I complained about the style of the article elsewhere in the thread, but this doesn't exactly disprove the point that it's objectively worse now.

zozbot234 7y ago

> When a channel is switched, the TV has to wait for the next I-frame, since P-frames (and B-frames) only encode the difference to the previous I-frame (or to the previous and next I-frame in the case of B-frames). You can apply the encoded difference to a grey (or black!) screen, the way (IIRC) VLC does in such cases. This means that the user immediately gets a hint of what's happening onscreen, especially since the audio can start playing immediately (also, often the P/B-frames replace a large portion of the on-screen content as people move around, etc.). Surely it isn't any worse than analog TV "snow". If it looks too weird for the average user, make it an "advanced" option - 'quick' channel changes or something.

DonHopkins 7y ago
Anyone old enough to remember the revolution of interlaced GIF files on the web? ;)

jagged-chisel 7y ago

I remember when a family member first got satellite - the tuner would change instantly, and the show would "pepper in" over a second or so until the next full frame. There's no technical reason the change can't be displayed immediately - it might not be pretty, but whether that's preferable is subjective.

jdofaz 7y ago
If my memory is correct that was the first directv/ussb system. I think I remember reading they were using something like a pre-finalized version of mpeg2.

Taniwha 7y ago

It's actually worse than that - first you have to tune, then you have to wait for a PAT frame (which has a index of PMTs in it), then you have to wait for a PMT (which contains pointers to the audio, video and ECM streams, and then you have to wait for an ECM (encrypted key for the stream), at that point you have have decrypted video and can start looking for I-frames .... (smart systems both cache a whole bunch of this stuff and revalidate their caches on the fly while they are tuning - first tunes after boot might be slower as these caches are filled)

Uhhrrr 7y ago

Based on my recent interview with a company that does a huge amount of livestreaming, the really smart people at least have a few ideas about this.

Piskvorrr 7y ago
Sure. The answer is then, probably, "it's not cost-effective to do that in COTS consumer equipment."
- Uhhrrr 7y ago
  Remember, decoding is much cheaper. And if you own or have some control over the client, there is flexibility about how you get things. That said, it's true that there still may not be a practical solution which is better for the user than letting them wait a second.

thibran 7y ago

Why not have the previous and next channel frame-data points loaded in the background? This would enable to switch quickly, even if it costs a bit more resources on the hardware side.

pedrocr 7y ago

No need to reinvent video encoding. At least my local provider seems to fix this by having all the channels streamed as multicast continuously and then having the TV box request a small bit of video over normal TCP to do the channel switch immediately and only later syncing to the multicast. That allows you to change channels quickly at any time and starting to watch at whatever the latest I-frame was. I notice this happening when IGMP forwarding is broken in my router and channels will only play for a second or two after being switched to and then stopping. Switch times are pretty good.

taffer 7y ago

Error correction also adds some latency.

zepearl 7y ago

> If you are aware of a possibility for efficient video compression that avoids this problem, tell the HN audience etc... This is a bad comment/reply - upstream wasn't complaining about the codec but about the usability (of the devices).

wolfgke 7y ago
I explained that an important reason why the switching time is like that lies in the fact how modern video codecs work. Taniwha gave an important addition: https://news.ycombinator.com/item?id=21836542 https://news.ycombinator.com/item?id=21836542

tomaskafka 7y ago

Or, the TV UX designers can realize this, and make the TV respond instantly by switching eg. to channel logo plus a name of current programme (it is available from EPG) and then replacing it with video 0.5 later. This would allow a rapid channel surfing, something I haven't been able to do on any recent TV.