Regulate speed of decoded frames using presentation timestamp

[Andressio]

Thank you for your reply


Nicolas Dufresne-5 wrote
> This return back in time indicates the presence of B-Frames. The decoder
> will
> reorder them for you. Notice the DTS, which should be monotonic before the
> decoder.

I don't think there are B-frames in the stream. The return back in time
happens a variable number of times: in my experiments 3 times per hour at
most. I guess that if it was due to B-frames the jump back should be much
more frequent and predictable. Consider that I'm using a keyframe interval
of 10 at 25 fps.


Nicolas Dufresne-5 wrote
> In GStreamer, decoders are not responsible for smoothing the transmission.
> They
> simply process as fast as possible. Dowstream the decoder, playback
> pipelines
> will usually contain a short raw video queue (which allow buffering when
> decoding is faster).  After that queue, there is a display componenent,
> (could
> be glimagesink). These element are using GstBaseSink base class, which
> implement
> most of the synchronisation code. It will translate the PTS into
> running-time,
> and then translate this to clock time in order to determin how long to
> wait
> before displaying. Audio sink are much more complex.

I will look into GstBaseSink, thanks. Is relying on the PTS the best shot I
have to regulate the output?


Nicolas Dufresne-5 wrote
> p.s. Remember that decoding complexity varies within a stream, so not all
> frames
> decode at equal speed. Some HW decoder would smooth this, but this is
> atipical
> for GPU decoders and PC software.

It is very interesting. Could you please provide some documentation about
these different behaviours? 



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/