Robert Schlabbach wrote: > > From my observations, broadcasters typically send about 2 I-Frames per > second. This means that even after only switching the video stream _on the > same_ channel or transponder, you will have a delay of 0 to about 500ms > waiting for the first I-Frame on the new stream. For comparison, analog PAL > TV has a field rate of 50Hz, i.e. you would have a delay of only 0 to 20ms. > > When you also change the channel/transponder, you will have to wait for the > tuner PLL to settle on the new frequency and for the demodulator to lock > the signal. The time required for this varies with the DVB flavor: My > experience is that DVB-S demodulators can do this in less than 10ms, DVB-C > in less than 50ms, and DVB-T demodulators take 500-750ms. > > So there are your technical limits: DVB-S and DVB-C roughly half a second, > DVB-T one to 1.5 seconds. That's the best it can get. So your expensive > Philips TV seems to be 1-2 seconds slower than it could theoretically be.
My experience is that switching between services on the same multiplex is faster with DVB-T than with DVB-C or DVB-S. I think that DVB-T here in Berlin uses statistical multiplexing (i.e. the channel bandwidth is distributed dynamically between all services on the channel, which means real-time MPEG encoding), and the encoder makes shorter GOPs when bandwidth is available. I haven't confirmed this hypothesis, though. Does anyone know a software which can display the GOP structure of a captured stream? Also IIRC the Philips TU1216, and the frontnend in one of those ugly Nokia boxes tune significantly faster than 500ms. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
