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

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

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

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

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.

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

There is no making all the people happy without just changing quick, eh?

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.

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.

Error correction also adds some latency.

My favorite "the world is terrible" curmudgeon observation is how awful hotel TVs (and hotel TV remotes) are. Every single hotel room TV I've had the displeasure of using in the last N years takes more than 20 seconds to turn on after multiple button-presses, starts out on a terrible in-house channel at high volume regardless of the last-watched channel+volume, takes multiple seconds to change channels, and has no real TV guide option to let you see what's on. This plus HDMI ports are regularly inaccessible and it's nearly impossible to use streaming sticks (roku) due to web-based wifi portals that only work half the time if you have an ad-blocker enabled.

Careful what you wish for - many years ago I worked for an interactive TV company that focused on the hospitality market. One large chain of hotels seriously asked if we could do a remote control with three additional large buttons at the top for "Beer", "Burger" and "Porn".

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.

Sounds like a legit app, though.

While in Japan, the TVs would often turn on the moment you entered the room. This was fine, as I would mute them or turn them off. At one hotel, I managed to bug one out such that volume didn't work anymore. No worries, I'll just turn it off. Except when I went to turn it off, it crashed the TV app and it automatically restarted. All the wires were integrated so they couldn't be tampered with and the unit had no real buttons. I thought I was going to have to sleep with the same four very excitable adverts on rotation blasting into my ears!

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.

In the hotels I stayed at in Europe it's usually a standard non-smart TV plus a custom board that connects to it over HDMI. Sometimes the whole thing is enclosed in some kind of plastic shroud that clips over the TV but nothing a bit of "percussive maintenance" can't fix. From there, the HDMI port is accessible.

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.

The usual problem I have is that I need to switch to DHCP based DNS to register my MAC address to the room number, then switch back so the hotel can't screw with my DNS lookups.

It might not be your ad-blocker or script-blocker; it might be your DNS settings.

Yes, pleease, just provide Miracast or Chromecast so I can watch content from my phone on the big screen.

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.

I'm in a room right now that has an HDMI cable on a little pug infront the TV. Unfortunately I never remember to bring my USB-C to HDMI adapter when I stay here.

Hotel remotes. You all triple-sanitize them, right? And then burn them....

I don't generally bother. I like to challenge my immune system once in a while to keep it in fighting condition.

Uhhh.

"In fact, we found semen on 30% of the remote controls we tested."

http://m.cnn.com/en/article/h_990ff64f90f909f55b916692ee340d...

When working on digital settop boxes a decade or 2 ago, channel change latency was one of the toughest problems. Eventually we (collectively, the whole industry) gave up and settled for 1 second as acceptable. Channel surfing quietly went away. When your i-frame only comes so often, there's not a whole lot you can do.

Nowadays, that problem is solved by reducing actual live content to a strict minimum; everything else can be on-demand.

Maybe there's not a lot you could have done while keeping the hardware cheap. I can think of a few ways to improve the user experience of channel surfing without waiting for an i-frame every time.

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.

These days they should be able to guess what 20 channels you might change to and start recording those in the background.

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.

The slowness can also be because the channel you are trying to watch is not even there.

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.

And that's one of the reasons things seem worse: there are massive, clever efforts to provide an infinity of options, but they're not completely seamless. Compared to the do-one-thing-and-one-thing-only appliances of yesteryear, it necessarily looks bad, especially when looking through the memory's rose-tinted glasses.

Nope, the STB has everything it needs to decrypt the channels you have access to. Tuning live TV channels happens 100% on the box. The only exception (a technology called Switched Digital Video) is just a way to save bandwidth on the cable, nothing to do with conditional access.

If I unplug my internet connection, my box won't let me do much at all. If I press pause or fast forward it just tells me the operation isn't authorized.

That's a weird system, certainly not the standard way of doing things on a traditional cable TV system.

I think it's pretty normal these days. The cable companies sell the data on what people watch, where the rewind, pause, fast forward, etc...

No, it's absolutely not normal for a regular cable DVR to tie authorization for DVR functionality to an Internet connection.

My last two have been like that. Try unplugging your internet connection then playing something you recorded earlier. If you have an AT&T or DirectTV DVR, it won't play.

Can't there be a dedicated channel or connection that's always tuned to that just broadcasts I frames from all channels, so that the box has all the latest frames for all channels and can start playing instantly when switching channels?

I remember when this happened, when it went "digital" and I know why it takes a second to switch channels, but it ruined the experience for me. While, at the time there was ways to watch video on the computer or from a DVD or VHS, I still liked to "channel surf" every once in a while. But that requires switching channels fast for an random amount of time based upon what was on and how long it took your brain in that moment to absorb it. And sometimes you'd stop and go back. But with digital, most of the time the load time was longer than the time I'd be on that channel in the first place. It'd take minutes to go through 10 channels as opposed to seconds. Channel surfing was its own activity for me back then - and it was ruined.

Nowadays there's youtube - but it's hardly the same thing.

I don't know who can afford cable any more to be honest. The only people I know who pay for cable are in the 45+ age range and they only use it because they just leave it on 24x7 or to watch the weather.

This I do agree with. I haven't had cable for years and years, but when I'm at someone elses house I am baffled how insanely slow it is. That would drive me NUTS on a day-to-day basis.

Analog TV were real time at the speed of electrons minus some layers of inertia (capacitance say).

Nowadays there's many layers of various quality, and software reactivity is a factor of so many things.

To be more accurate, the speed with which electrons move through the wire is rather low (which does not matter, of course, because the signals are carried by the electromagnetic forces which propagate very quickly).

Also, TVs kinda started having a black screen in between switching of channels. At night that becomes incredibly uneasy for eyes.

Modern cable systems are more akin to satellite broadcast systems than they are to the terrestrial broadcast systems of yore. There's an order of magnitude more content on cable these days. When you tune a channel now, instead of simply tuning to a frequency and demodulating the signal, content is spread across many frequencies, each of which carries a QAM-modulated MPEG transport stream that carries many programs. It takes longer to tune QAM than baseband analog or even PSK. So the physical frequency change takes longer than it used to do. Once frequency is tuned, decoder may need to check provisioning in order to be able to decrypt whatever program you've requested, so that adds to the time it takes.

It takes time to pick up the MPEG2 scheme and start decoding.

all they need is to create to a low rate channel with slowly updating snapshots of all the programs being transmitted.

i don't know anyone who does that, but it is damn trivial.

(former middleware engineer)

> all they need is to create to a low rate channel with slowly updating snapshots of all the programs being transmitted.

> i don't know anyone who does that, but it is damn trivial.

Getting this standardized in an international standard is far from trivial.

You may well be hitting a deeper point here.

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.

"they" usually write requirements for set top middleware and control the broadcast. the problem, i think, is not that it is difficult (Musk launched a massive electric car company and spacecraft to ISS in the relevant time frame), but that "they" don't care about the users.

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.

The Ericsson MediaRoom IPTV platform (used by AT&T Uverse in the US) does something similar to this, but it's only used to show a small window to preview the highlighted channel while you're scanning the guide.

It's not only switching channels, even just turning the thing on. Also switching between inputs takes a long time, a large part of which is spend in the menu. The only thing I ever do is switch between AppleTV and PS4 and adjust volume because the PS4 is orders of magnitude louder than the AppleTV, yet so of that always feels super clunky if I have to use the TV remote.

It's patently absurd that a modern cable box chugs just when flipping through the channel guide. The provider has control over the software and the hardware so it should be butter smooth all the time.

Doing that would take extra work, and cost more money. Why should they bother, when the dinosaurs who still watch cable TV aren't going to pay them any more for this butter-smooth experience? The people who care about such things have all moved to on-demand streaming services.

It is interesting to see just how much more information is in a second of video than it used to be.

That said, I'm not sure that counts for the latency by itself. Pretty sure it doesn't. :(

The problem is that (mpeg video frames, mpeg audio frames, streaming latency, hdmi decoding, etc...) all introduce a delay for reasons.

The answer: put an ad in there.

It depends on the TV or tuner box. Some are very fast and some are very slow. It is something you have to test before buying if you can.

Yeah, it sucks though that most tv providers supply the lowest-specced box they can provide. For my parents it was bad when they bought a 4k television, and the box "supports" that, though since some firmware update it starts lagging every 20secs. Dropped frames and the usual video-"smudge". I hope they get a (FREE) update soon. Because this is just a broken promise.

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

Yes. They can fade out the old screen with "snow" until the next MPEG stream starts to decode.

Also navigating through the "guide" is simply horrendous.