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.