[FFmpeg-devel] Fix ffmpeg -re behaviour

[Michael Niedermayer]

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.


> 
> 
> > 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 ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20081125/e1069e3d/attachment.pgp>