[FFmpeg-devel] Fix ffmpeg -re behaviour

[Stefano Sabatini]

On date Tuesday 2008-11-25 01:02:22 +0100, Michael Niedermayer encoded:
> On Mon, Nov 24, 2008 at 06:37:12PM +0000, Luca Abeni wrote:
> > Hi Michael,
> > 
> > Michael Niedermayer wrote:
> > [...]
> > >> 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
> > 
> > Ok; thanks for the clarification.
> > Note that the documentation of "-re" refers to input frame rate; so, I 
> > do not know if the fact of re-encoding the media stream instead of 
> > copying it will affect the correctness of the input timestamps (but I 
> > might be just confused :).
> > 
> > 
> > > anyway, the whole is not even remotely correct for streaming. What is
> > > correct requires at minimum logic similar to the MPEG-PS muxer
> > [...]
> > 
> > Yes, I can agree with most of this. But (I think) the point of this 
> > patch is not to provide a "correct" streaming support. I think the point 
> > of this patch is to fix "-re", which currently works only in some 
> > special cases (it does not work for audio only-files, and it does not 
> > work for some input containers/codecs - flv, if I remember well).
> > In this sense, I think the patch is actually fixing a bug (then, it can 
> > be questioned if "-re" is the right thing for streaming, etc... But I 
> > think it's a different issue ;-). And I think the code after applying 
> > this patch is more compliant with the definition of "-re" given by 
> > ffmpeg (but this is just my opinion).
> 
> ohh well, fine, lets fix the -re hack but please use pts instead of next_pts
> unless that works less well.

As long as I've tested it, they seem to work the same, there is an
initial delay on the receiving end, with RTP streaming all the first
packets seem to be sent too lately so ffplay first hangs then runs
until the frames are again in synch (all this lasts for few seconds, I
think it was the same without the fix).

I'll send an updated patch this night.

> > > anyway all of above is implemented in our mpeg-ps muxer, maybe that could be
> > > used ...
> > 
> > Yes; and that code would be useful for other muxers too (MPEG TS, for 
> > example).
> 
> yes, and there was a unfinished patch, not sure if anyone is working on it ...

Regards.
-- 
FFmpeg = Fiendish and Frenzy Martial Purposeless Embarassing Gadget