[FFmpeg-devel] Fix ffmpeg -re behaviour

[Stefano Sabatini]

On date Tuesday 2008-11-25 13:43:33 +0100, Stefano Sabatini encoded:
> 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.

Attached patches.

Patch #3 make -re global, that is it will affect every stream in input
rather than set it only for the first video stream encountered.

Regards.
-- 
FFmpeg = Fostering and Furious Magical Portable Elastic Gadget
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-rate-emu-pts.patch
Type: text/x-diff
Size: 632 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081125/9951346f/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove-ist-frame.patch
Type: text/x-diff
Size: 985 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081125/9951346f/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rate-emu-global.patch
Type: text/x-diff
Size: 1281 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081125/9951346f/attachment-0002.patch>