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).
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.
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).
But even in boxes with multiple tuners (DVRs) your solution would require tying up at least three tuners (current channel plus one up and down) which would cut down the number of simultaneous recordings that are possible. I doubt many people would like that tradeoff.
However, the biggest issue is that most boxes simply don't have more than one MPEG decoder in them.
How do you plan to obtain I-frames without decompressing them?
Some of the channels I like used to be difficult to tune with my previous cable box, because it would not correctly coordinate tuning with the infrastructure, so I'd have to retune. If I left the box on such a channel and turned it off, the next time I'd use the box the screen would be black.
In the old days all the channels were analog, and used 6MHz each (may vary in your region), and channel changes were much faster.
That's 50 cents the shareholders can pocket, and everyone has already inured themselves to the slower experience.
Isn't progress great?
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.
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?
50 cents x 4, along with the other increase likely $5+ of BOM cost increase could make or break a consumer product. But your reason is also true as it improves UX.
This is where innovation and Apple comes in, you need to market the product with a features that masses of consumer believes in it and are willing to pay for it. ( Lots of people, including those on HN often mistaken innovation as invention )
There is nothing "American" about this business practices, it is the same as any European, Chinese or Korean Manufacturers. They could have very well put this feature in but I am willing to bet $100 it wouldn't make a difference to consumer's purchase decision. So why continue to add $5 or more for a feature they cant sell.
But Apple has the ability to move consumers, and to charge higher ( as a package along to this feature ) to demand a premium. And if Apple successfully market this feature, say with some sort of brandname like "QuickSwitch", it is only a matter of time before other manufacturers copy it.
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.
(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)
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.
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.
This is a bad comment/reply - upstream wasn't complaining about the codec but about the usability (of the devices).
This would allow a rapid channel surfing, something I haven't been able to do on any recent TV.
Turns out getting like that manufactured in the quantities we were looking at is a nightmare - so it didn't happen.
Edit: Clearly it would have been easier to have one button for "Beer, burger and porn" - but that has only occurred to me now.
It might not be your ad-blocker or script-blocker; it might be your DNS settings.
"In fact, we found semen on 30% of the remote controls we tested."
http://m.cnn.com/en/article/h_990ff64f90f909f55b916692ee340d...
Or just let me use an HDMI port.
I don't watch channels anymore, and I don't want to pay for your pay-per-view content.
Mercifully, pressing the TV Source button triggered a different app that didn't crash when I pressed the off button, and in what must be the software engineering achievement of the decade, the off button turned off the screen.
However, in most cases, at least in mid-range rooms, the TV is barely bigger than my laptop so it just doesn't make sense to use it.
Nowadays, that problem is solved by reducing actual live content to a strict minimum; everything else can be on-demand.
I've always suspected the reason it's slow is because you press the remote button, the DVR sends that to the provider, the provider has to verify that you can do what you are asking it to do, then a response comes, then the change can start.
I'm not sure who all is using it now but I used to work on the setup for Switched Digital Video. If nobody in your neighborhood was watching a certain channel, it would stop getting broadcast. That freed up bandwith for other things like internet. Once you would tune to a channel, a request would go to the head-end, it would quicky figure out if the channel is being broadcast in your area. If not, a request would go to the content delivery system to start feeding it to the QAM and then obtain what frequency the channel was on, and finally relay that back to the settop box which would tune and start the decoding process.
Rather impressive tech but again, this would add a bit more latency to that particular channel switching.
The cheapest would be to just use a constant neutral-grey i-frame whenever the channel flips, and update that until a real i-frame comes along, while playing the channel audio immediately. Ugly video for a second, but high-action scenes fill in faster. I'd bet that most people could identify an already-watched movie or series before an i-frame comes in, at least 80% of the time.
More expensive would be to cache incoming i-frames of channels adjacent to the viewed channel, and use the cached image instead of the grey frame. Looks like a digital channel dropping update frames during a thunderstorm for a second.
Prohibitively expensive (back then) would be to use multiple tuners that tune in to channels adjacent to the viewed channel, and then swap the active video and audio when the channel up or channel down buttons are pressed. Drop the channels that just exited the surfing window, and tune in to the ones that just entered it. Surfing speed limited by number of tuners.
Televisions still don't do this, even after more than a decade of digital broadcast, and multiple-tuner, multiple-output DVR boxes.
Nowadays there's youtube - but it's hardly the same thing.
Nowadays there's many layers of various quality, and software reactivity is a factor of so many things.
i don't know anyone who does that, but it is damn trivial.
(former middleware engineer)
> i don't know anyone who does that, but it is damn trivial.
Getting this standardized in an international standard is far from trivial.
pretty much anything cable and satellite tv companies do is against the user. there is very little (if any) innovation in the industry, and that's why they will eventually die.
Many of the strongest AND weakest consumer technology experiences are influenced by standards in some way.
Positive Examples: pluging in an usb headset, electrical sockets, sms.
Negative examples: Trying to hook up your laptop in a random conference room, transferring a large file locally between 2 devices from different vendors.
Maybe with ever increasing conplexity and capability the annoyances fall between industry actors and solutions would need first multiple parties acknowledging the problem followed by succesful coordination.
That said, I'm not sure that counts for the latency by itself. Pretty sure it doesn't. :(
The answer: put an ad in there.
And I'm not even talking about the Netflix "app" that's on there. Holy s#!t that's slow. Or the TV-guide. They now resort to teletext because that's much faster... I mean...