Right, but there's a social/business reason why this is true. There are various things that could be done technically to fix this, for example, you could have three decoders running simultaneously so you always had the adjacent channels buffered, you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.

The real reason problems like this aren't solved is that the organization does not allocate resources to fix them. The status quo has been deemed to be good enough and not leading to the loss of too many customers to the competition, so that's where it stands. This pervades all engineering -- everything just barely works, because once it barely works, for most things, it's good enough, and no more resources are deployed to make it better.

I think some boxes advertise that, but how much does it help? On an analog TV you could be switching channels at a rate of say 3-4 per second while still registering the channel logos and stopping on the right one (by going one back immediately). One receiver in either direction isn't going to keep the charade up. Some cleverness, like decoding adjacent channels, but if the user switches a channel down, have the "up" decoder jump to the 2nd channel down in anticipation of the user going another channel down etc., might help, but still. You can't feasibly emulate the channel agility (across ~800 channels on satellite) of an analog RF receiver in a digital system with a modulation that has a self-synchronisation interval of up to a few seconds.

> you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.

GOP length / I-frame interval directly relates to bitrate. Longer GOPs generally result in a lower bitrate at similar quality; in DVDs or Blu-rays I believe the GOPs can be quite long (10+ seconds) to achieve optimum quality for the given storage space.

Non-predictive video codecs are usually pretty poor quality for a reasonable bitrate (like a bunch of weird 90s / early 00s Internet video codecs), or near-losless quality but poor compression (because they're meant as an intermediate codec).

There are technical reasons for this I guess (as you pointed them out). But what gp is talking about is really a ubiquitous phenomenon of not trying to do anything with it.

Users want to change channels quickly? Okay, let's decompose a problem into what they really want to do, then make N "preview of i-j" channels in 720p with channel pictures in e.g. 8x5 grid and show numbers so that a user could just dial them on a remote. After finding an interesting preview, it's not an issue to push some buttons and wait a couple of seconds to get 2160p or whatever quality there is. Didn't like it? "99<n>", "ok", repeat. This solution would be a jquery of tv world, dumb, straightforward, non-automated, but it would be a thousand (fourty to be honest) times better than nothing.

When I had an hd tv set, I just checked 3-5 channel numbers that I remembered and turned tv off if there was nothing of interest, because you could easily spend half an hour by just peeking them one by one.

Right but your assumption is that bandwidth efficiency is the only important thing. Why don't they use 10 second intervals if they're more efficient?

My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.

Honestly it seems pretty obvious to me that the I-frame intervals that are typically used are the outcome of a balance between usability (having to wait until a clear picture can be viewed) and bandwidth as well as processing requirements.

Bandwidth matters because spectrum is a finite commons. Digital TV required giving up bands that were in use for other things (e.g. wireless microphone systems and some ham bands) as it is, using even more bandwidth would have required even more spectrum. Other people have stakes in the spectrum for very good reasons and often much more important reasons than "I wanna watch TV". Even for satellite TV, which uses frequencies high enough that there is lots of bandwidth is limited, because using a lot of bandwidth would require new LNBs and multiswitches for all customers.

> My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.

Can you name one for each category you bring up? Especially the "engineering" one would be interesting. Obviously dedicating an even huger chunk of spectrum to "I wanna watch TV" would make things easier, so that's not really interesting. And "let's just give each customer a TVoIP stream that can start immediately" is also a pretty obvious "money is no concern" (and also "we don't care about customer adoption costs") option.

I think we're really saying the same thing but from a slightly different perspective.

We agree that there a whole series of parameters that can be traded off against each other: 1. Bandwidth required

2. Number of channels

3. CODEC complexity/engineering effort/cost for encoders and decoders

4. Iframe interval

5. Number of tuners/decoders in receiving equipment

6. Resolution

7. Frame rate

8. Video quality

So the standardization people decide how to set those, and basically channel switch time gets set to the maximum value that doesn't cause people to cancel their service.

If you want to see something pretty astonishing that can happen if you set the tradeoffs differently, check this out: https://puffer.stanford.edu/player/

Realistically, it’s because it was considered an acceptable tradeoff for replacing 480i analog video with 1080p digital video.

By who?

Many people wouldn't even be able to reliably tell the difference with common dpi's and viewing distances.

The difference between 576i50 (PAL equivalent, free version of the main private channels) and 720p50 (that's what German public service uses for "HD"; it's not actually 1080p, although they use a pretty high bitrate) is pretty stark, the difference between 576i and 1080p is even more obvious. Although TVs don't really have a neutral setting and try their best to mess every image up as much as they can.

Between 1080p and 480i? Have you never watched old video/shows on an HDTV? The difference is stark.

All the time, and unless the images are next to each other you don't really notice unless you're looking for it. Not because there isn't a big difference, but because you just don't really care that much unless it is called to your attention.

I've found pixel-count improvements stop mattering for me somewhere around DVD quality for a lot of content. I can tell the difference between that and 1080P, but stop caring once I'm actually watching the show/film. For the occasional really beautifully-shot film or some very detailed action movies, I guess I might care a little. 1080P versus 4K, I don't notice the difference at all unless I'm deliberately looking for it. And that's even with a 55" screen at a fairly close viewing distance.

What does make a difference? Surround sound. I'd take 5.1 or up with DVD-quality picture over 4K with stereo any day, no hesitation.

I remember a clear improvement in the legibility of things like onscreen scoreboards in sports broadcasts. In the NTSC era I would squint at the TV trying to figure out if the score was 16 or 18 for a football game, and for a basketball game you just had to keep track of it in your head since the scoreboard wasn’t even persisted onscreen. Other things, like telling different players apart, are also easier these days (you can even make out their facial features in a wide shot!)

I remember seeing my first HD hockey game in a bar around 2000. Wow! I could actually see the puck.

maybe it IS good enough

Maybe it leads to less impulsive tv watching and aimless surfing and ends up being a benefit.

Hmm, those 2 seconds in between channel changes might be enough to insert a micro ad that could be preloaded in the background. That would appear instantaneously while your channel loads, it would feel a lot more responsive.

Just that thought makes me want to jump out the window.

Most video players can decode an "in progress" stream just fine. This obviously involves quite a few artifacts for the first 0.5–2 seconds or so, but seeing artifacts is generally preferable to seeing a totally blank screen.

It's obvious that TV makers have decided that seeing artifacts is not preferable. I wish that was toggleable.

Implicitly TV users are also prohibited from making their own technical decisions. I claim this is because the TV predates the era of open computing platforms like Unix.

> I claim this is because the TV predates the era of open computing platforms like Unix.

I claim it's because DRM, since if it wasn't for DRM wanting control of the whole reception to display path to be protected, you could just stick an open computing device in between the streaming signal and the display device, and make your own technical choices.

You still can, AFAIK, for content that doesn't require HDCP.

I don't think it has anything to do with Unix or DRM or any of that.

It's because we have a trendy now-decades-long wave of product managers and designers who assume their job is to know better than the user.

Open source software is not immune.

TV and broadcasting in general has always been mostly controlled in a top-down manner by companies and governments, since before computers existed.

cough Ubuntu cough

cough systemd cough

I remember having a TV tuner card back in the day on my old desktop and this is exactly what I did. I don't watch much TV or anything so.I haven't really checked, but are such cards available today with the encrypted digital cable that's ubiquitous everywhere? Even most broadcast is digital now and requires a decoder box between.

OTA: Yes.

Cable: no, you'd need a CableCard, and approved device (i.e. DVR), etc.

> the TV predates the era of open computing platforms like Unix.

Do you mean Unix-like? I'm not sure what you mean by "open" in this instance, but Unix definitely was not very open, leading to nascent platforms and movements such as GNU and Free/Libre software.

It's easy to say this but flipping through channels could be 30s straight of garbled images, followed by learned behavior to flip channels slowly.

I recall reading about TVs with multiple tuners to resolve adjacent channels when flipping, but I don't remember if they actually made it to market.

True, and the decoders in receivers already have this capability, since they keep decoding even if the forward-error-correction can't save the stream any more, resulting in similar artifacts. I'm not sure why it's not done on a channel change, perhaps it's the manufacturers not wanting their TVs to routinely show glitched footage, or perhaps advertisers don't want it because it would be against Corporate Design rules to glitch-effect the logos they use on the daily.

Our cable box has three decoders. My gf can watch one channel and record two others at the same time.

Yet does it use any of those extra decoders when not recording to proactively decode the previous and next channel, or something smart like that? No, of course not...

Recording doesn't use a full decoder.

The incoming channel data stream is saved as-is. It will need a demultiplexer to separate out one channel from the multi-channel data stream, but it won't need to decode that stream, which is the intensive bit. Decoding happens when you play it back later.

Ah, I did check out the specs again and it does indeed say it has a bunch of tuners, not decoders.

Mental slip then. Thanks for the correction, very interesting.

> proactively decode the previous and next channel

Do you find yourself actually moving up and down the channels, and not through the guide to somewhere else entirely different than where you once where? My first move if I'm switching channels is to go to the guide, not to a channel one above or below my current channel.

I suppose it could run on the previous channel, but it certainly can't guess my next channel.

The first startup I worked with was an IPTV startup that would send the I-Frames for the channels on either side of the channel you were watching at the higher bandwidth tiers so you could channel flip instantly like the old days.

Toxic culture and relationships so the startup imploded, but there was some cool tech.

There is also the matter of modern screens needing 5-30 seconds to "boot" when old TVs and monitors turned on in less than a second.

CRTs did tend to take a couple seconds to properly warm up, charge up and reach final image size (the image is directly scaled by the acceleration voltage, which is a high impedance source charging a not-so-small capacitor formed by the aquadag on the inside and outside of the picture tube).

CRTs did need a moment to stabilize the image, but they showed signs of life virtually instantly. At the least they'd make a little noise and had buttons with tactile feedback so you knew something was happening. Many screens today have capacitive touch buttons and have 5 seconds or more between a button 'press' and anything happening at all, leaving you to wonder if you even managed to successfully press the power button in the first place.

Yes! I remember movies and TV shows would have scenes where a character is called and told to turn on the TV for breaking news. They'd see it the story instantly, and that was actually realistic! (Assuming it was big enough news to be on all channels.)

Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".

> Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".

But they still have these scenes in movies

The way these scenes work now is "picks up phone - check the news!", they grab the remote, and turn the volume up on one of the many already running and tuned in wall-mounted 24/7 on TVs ... :)

>But they still have these scenes in movies

Yes, and if such a TV turns on instantly, that scene is not realistic.

(I think if the were going for realism today, they'd say "pull up reddit/Drudge/google news".)

Are we talking about seeking in media players, or streaming websites? If I watch a random twitch stream I just see a loading throbber, while it loads, not a artifacted version.

I won't be surprised if TV manufacturers further screw customers by forcing them to watch ads in between switching channels.

I don't buy this. We had an old cable box that had instantaneous channel-switching. The cable company made us switch to a brand new one. Same signal coming in, but the new one was infinitely slower. It wasn't some change in the signal that made things slow, it was the software and the complete lack of care for performance.

You not "buying" it doesn't make it untrue.

You get the cable box for the new system BEFORE they switch the old system off, or else you wouldn't have service until you got a new box. That's why you saw behavior change with the new box.

It simply isn't possible to send all the channels to customers at all times. There isn't enough bandwidth. So, the cable box at your house negotiates with the central or regional system so only a subset of channels are sent to you. There is no other way to do it in digital cable systems, and the switch to digital was made because it uses significantly less bandwidth than analog.

The old cable boxes were literally switches, with all channels flowing into the box all the time. Now switching is virtual and done on the server (plus all the software encoding/decoding).

Right now I would be satifsied with at least some caching of the menus, so it doesn't have to pull the data every damn time I scroll up or down. Come on, it should be able to remember what channels I have for more than 5 minutes in a row.

It probably does cache the data, and it just takes ages to draw. Manufacturers really cheap out on settop box CPU and RAM specifications in order to make the pricing attractive to cable companies.

...but then it costs you a thousand dollars if you lose or damage the set top box.

Yes and they still have insurance to cover the loss, anyway.

You didn't think a cable company was going to deal with it's customers fairly, did you?

Every time you interact with a customer, there is an opportunity for profit. Telecommunications companies, cable TV included, are masters at this type of behavior.

Another reason for the lag is that the modulation scheme is complex and requires considerable time to both acquire the actual demodulator lock (in fact, the symbol in typical terrestrial DTV system is surprisingly long) as well to acquire synchronization of the higher level FEC layers.

> The technical reason is that digital TV is a heavily compressed signal [1] (used to be MPEG2, perhaps they have moved on to h.264) with a GOP (group of pictures) length that is usually around 0.5-2 seconds.

Just because they transmit keyframes and deltas in the steady state doesn't mean they need to wait for the next keyframe when starting the stream. They could also choose to send you the current reconstructed frame as a keyframe immediately instead of waiting several seconds for the next pre-made one. The cost to them would be epsilon (one new stream client per channel to be the source of reconstructed keyframes), and the customer experience difference would be noteworthy.

There is no stream being started in DVB-T/S/C as far as I know, since they are actual broadcasts. US cable tv might work differently though.

Sorry. My context here is cable boxes, which do communicate bidirectionally and somehow take even longer than DVB receivers to change channels. If you're actually receiving everything all the time, then there are other things you can do to make channel switching not take ridiculously long.

That will only work if the original is in lossless.

No. It will work regardless. I'm talking about having a single additional client decompress the broadcast and act as a first-frame keyframe source based on the decompressed stream. In a traditional compressed stream, a reconstructed frame is already the context for the next delta after the first. Sending a frame reconstructed by someone else allows you to immediately begin using deltas, and it's a close enough approximation of the original uncompressed frame that the immediate result will be quite good even if not perfect, especially compared to waiting.

At worst it would only be as bad as a transcoded stream for the first few seconds until the subsequent true keyframe arrives. That's loads better than no stream at all.

There's additional issues with changing channels than just GOP sizes. For cable TV signals are still channelized into 6MHz channels. QAM modulation is used which gets about 40Mbps per 6MHz channel.

An MPEG transport stream is sent over that 40Mbps "channel". Inside of that transport stream are several elementary streams, each carrying either video, audio, or data/program information. A TV station will be carried by a combination of a video (MPEG-2/4) and audio stream. These streams are packetized such that a receiver won't get buffer underruns or overruns. The transport stream is further packetized. Adjacent station broadcasts aren't always carried on the same transport stream.

So when you hit the button to "change channels" the cable box may need to tune to a new radio channel, wait for transport stream packets for the station, and then buffer enough data to start playback.

The GOP size then plays a part because the decoder needs an I-frame to do anything useful with the P-frames inside the GOP. Cable providers use longer GOPs to get better quality at a given bitrate, I-frames are much larger than P-frames so the more you send the higher the bitrate you need.

Sending I-frames for other broadcasts in the same transport stream would be a waste of bandwidth. The data used for these rarely used extra I-frames takes away from bandwidth programming in the stream could use. There's also still the lag from tuning a new channel and waiting for those I-frames to show up. So you've wasted bandwidth for a very slight increase in responsiveness.

Currently I'm talking only about sending _one_ additional I-frame per station switch at the time of the switch, not always sending them or sending them for unrelated broadcasts. I just object to the idea that it's reasonable for a feed to start with seconds-worth of unusable P-frames, and it doesn't seem to be strictly necessary.

Cable boxes do not typically have bidirectional connections. The cable head end doesn't know about channel changes. Don't think of cable TV like web streaming.

Cable systems don't often re-encode streams they receive from upstream sources. The video from upstream is already compressed so the elementary streams are remuxed into the cable system's channel plan. The cable head end doesn't receive raw video and encode it in real-time. Even local OTA stations just get remuxed rather than re-encoded.

Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end in case someone flips a channel. Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.

Even IPTV isn't a bidirectional signal. It uses IP multicast and the tuners just change their multicast address to change stations. The stream is the same MPEG transport stream as the QAM signal but sent as IP packets. The head end still doesn't decode every station to send bespoke I-frames in the event someone flips the channel.

> Cable boxes do not typically have bidirectional connections

This hasn't been true in many places since the takeover of digital cable in the 2000s. Without a bidirectional data link, how do you think cable internet works? Or cable telephony? Or pay-per-view for that matter? It's all on the same line into the same box.

> Cable systems don't...

Don't isn't couldn't. When talking about solutions to problems, merely describing a problem isn't where the conversation ends.

> Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end

That's what I described. The cost of doing it is epsilon.

> Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.

If you can stream Netflix while watching TV without hurting your neighbors, then you can receive one single I-frame.

How does a DVB-T Transmitter know about a receiver switching channels? A DVB-S signal is just forwarded by a space relay fed by an uplink site fed by a number of stations. These are not interactive duplex media like the internet or by possibly some forms of cable TV.

Sorry. My context here is cable boxes, which do communicate bidirectionally and somehow take even longer than DVB receivers to change channels. If you're actually receiving everything all the time, then there are other things you can do to make channel switching not take ridiculously long.

Cable boxes aren't bidirectional in the way you seem to think.

That's wrong everywhere with cable internet. See my response to your other similar comment.

I'm not sure if this is the whole story. Watching DVB terrestrial TV on my television, channel changing is definitely slower than a good analog TV, but it's much faster than any satellite/cable box I've ever used. And there's a lot of variance between cable boxes. I strongly suspect some of them are doing something silly.

OTA TV (Rabbit Ears picking up Digital TV - c.f. older analog NTSC), at least here in Canada, is still using MPEG2. The stream is typically around 20 Mbps, including the audio, which is Dolby Digital 5.1 (except certain channels, such as TVO (TV Ontario), which is DD 2.0).

It's all based on ATSC. While there is an ATSC 2.0, they skipped that in Canada, there will be ATSC 3.0, which will use HEVC (H265) for 4K. But don't hold your breath on that...the TV stations aren't exactly opening their wallets to upgrade anything!

And yet using puffer[0] I get instant channel switches at 1080.

There is no technical reason you can't have instant channel switches, it's just that they aren't making the right technical decisions to allow it and/or don't want to pay for it.

[0] https://puffer.stanford.edu