[FFmpeg-devel] Fix ffmpeg -re behaviour

Michael Niedermayer michaelni
Sun Nov 23 17:41:07 CET 2008

On Sun, Nov 23, 2008 at 04:40:20PM +0000, Luca Abeni wrote:
> Michael Niedermayer wrote:
> [...]
> >> * fixrate-emu-pts.patch
> >>   Use ist->next_pts rather than use frame_nb * codec_time_base as the
> >>   timestamp for the next frame to print.
> >>   This assumption is not always true and only works for video codecs anyway.
> > 
> > I dont think next_pts is the correct variable to use, but then what exactly
> > where the use cases of rate_emu anyway?
> rate_emu should read a stream and transcode it at a rate given by the 
> input timestamps. I find it useful when streaming, or when doing 
> real-time video conversion without consuming too much CPU time.
> In theroy, I think that the input dts should be used, but it can often 
> be AV_NOPTS_VALUE... I see that ffmpeg.c sets next_pts according to the 
> input dts, and then updates it (with the guessed value) so that it will 
> have a reasonable value even if the next dts is AV_NOPTS_VALUE.
> So, I had the impression that next_pts can be used in this case (the 
> exact value is not really important; the important thing is to maintain 
> an acceptable average rate).
> Would ist->pts be a better solution?

the variable pts should be the timestamp of the current decoded frame,
next_pts should be approximately the next but is unreliable
with raw video (and maybe vcodec copy) ist->pts may be correct
with encoded video both will give too late times

anyway, the whole is not even remotely correct for streaming. What is
correct requires at minimum logic similar to the MPEG-PS muxer, that
is maintain information of the decoder audio and video buffer states and
send data so they dont over or underflow.
That is the receiver side removes packets at their DTS from its buffer
and feeds them to the decoder. If you assume the clocks are synchronized
then the sender can send packets so the decoder doesnt run out of data
while keeping bounds on the
amount of time of data (time of data in the receiver buffer)
amount of bytes of data (bytes of data in the receiver buffer)

also a proper implementation cannot consider video or audio alone and instead
has to send the one that will be needed first, first.

anyway all of above is implemented in our mpeg-ps muxer, maybe that could be
used ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081123/d3c12a13/attachment.pgp>

More information about the ffmpeg-devel mailing list