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)

> 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.

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

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.

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.

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.

While everything is usually on the cable (there are exceptions) the STB only has a limited number of tuners, which means it can't "see" everything at once. The channels that are nearby in number may or may not be on the same physical channel, which would mean the STB is effectively blind to them.

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.

Actually that's a good point, my sky tv box lets me record 6 streams plus watch a channel at once, however i rarely have more then 1 or 2 recordings at a time, so on average i have +2-2 channels available to holder in buffer.

Feel free to find a chipset on the market that can decode hundreds of channels of Full HD H.264 simultaneously...

Only your current transponder.

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.

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)

Essentially waiting for I-frames as the mini-GP noted it?

Many channels are broadcast, but some are a hybrid. Observe that not everyone needs every channel every second. You can set aside some over-committed bandwidth in an area for the less-in-demand channels and deliver to that area the channels actually desired. This required a change to the CableCard architecture, which has been rolled out for a while now.

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.

> probably not much because you don't need to decompress them, just keep in volatile memory

How do you plan to obtain I-frames without decompressing them?

The decompression could be done lazily when you switch to that channel.

The same way that switching to a channel does it. But instead of waiting for next one to arrive you first scan your 0.5s buffer.

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.

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.

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 ...

IIRC Microsoft did this in their IPTV platform.

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

> 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?

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.

> 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.

I think you and your OP are both correct.

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.

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?

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.

Sure. The answer is then, probably, "it's not cost-effective to do that in COTS consumer equipment."

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.

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.

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.

> 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).

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

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.

joncrane was complaining about the time to change channels. This approach does nothing to decrease this time.

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.

> 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).

You can show the program name and what's on on that black screen, this info is already available from EPG.

That's actually a nice spiff. Doesn't entirely fix the problem, but could help with surfers looking for something interesting.

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

Error correction also adds some latency.