[vdr] Re: Nothing good for me... [Was]-> ( Implementing newdevice, but video is choppy)

[Reinhard Nissl <rnissl@gmx.de>]

Hi,

I've had the same stuttering problem with my vdr-xine-0.0.2 plugin. Since 
vdr-xine-0.0.3 (aka 0.1.0) I've solved the issues similar to your approaches 
so far. I think, the hint below will solve your final problem.

Stefan Schluenss wrote:

> Maybe i'm wrong, but
> how does you control the output "speed" of your decoder ? You have to adjust 
> your decoding system clock to that of the data source. That's the reason for 
> the SCR (System Clock Reference)-Fields in the MPEG format definition.
> If it's not done, your buffer could run empty resulting in choppy video 
> output.
Absolutely true. As long as the decoder's system clock is running ahead of the 
stream's system clock reference, the decoder throws away every frame that is 
too old until it gets up to frames that are in the future.

> When reading data from a file (replay mode) the data source is controlled by 
> the speed of your decoder (it reads what it needs).
In this case, throwing away old images works and as the decoder sees a couple 
of increasing SCRs within a short time, it finally adjusts its system clock to 
the stream (at least xine behaves like that).

When watching TV, the satelite controls the speed of your decoder, as it 
broadcasts data at a constant rate. If you don't tell your decoder to 
synchronize it's system clock as soon as possible to the stream, the above 
case for auto adjusting will never hit (maybe it will if you have awfully 
large buffers, that cause ugly delays when switching channels).

Prebuffering:
In my plugin, I've instructed xine to prebuffer 31 frames after synchronizing 
it's system clock just before starting decoding. This is, because a decoder 
typically needs two I-frames plus the frames between them to start decoding. 
The frames from one I-frame up until the next I-frame are called a Group Of 
Pictures (GOP). Most often a GOP of 15 frame is used (IBBPBBPBBPBBPBB), so 
prebuffering 15 frames plus 1 (the next I-frame) should be a good start.

When switching channels, the transmitted stream might start anywhere within a 
GOP, so in the worst case, it takes 14 frames to get to the next I frame, 
which is heading a GOP. With this information in mind, I was setting 
prebuffering to 30 frames. But as there still was stuttering in very rare 
cases, I increased the value to 31 frames, which seems to be perfect for xine.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de




--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.