[FFmpeg-devel] Fix ffmpeg -re behaviour

[Luca Abeni]

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


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


				Luca