[FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration

manuelyuan manuelyuan at 163.com
Thu Nov 7 11:21:09 EET 2019


Thanks for your reply! 
My changes break make fate but this is inevitable. I will update the corresponding references to make sure make fate success



At 2019-11-07 00:47:42, "Michael Niedermayer" <michael at niedermayer.cc> wrote:
>On Wed, Nov 06, 2019 at 10:36:11AM +0800, manuelyuan wrote:
>> From: Mengyang Yuan <manuelyuan at 163.com>
>> 
>> In this case, the input video is of dynamic frame rate and we don't want to
>> duplicate or drop frames, but the output video duration calculated by DTS is
>> incorrect, I solved it by using PTS.
>> There are many UGC videos with dynamic frame rates, which are represented by
>> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
>> video duration becomes longer.By reading the code of x264/encoder/encoder.c,
>> I found that in order to predict the B frame, x264 needs to ensure that there
>> are enough reference frames when DTS = 0, so the DTS of these reference frames
>> will subtract the cache time. However, the cache time includes the part of PTS
>> jumps, which results in the abnormal small DTS.
>> 
>> Signed-off-by: Mengyang Yuan <manuelyuan at 163.com>
>> ---
>>  libavformat/movenc.c | 23 ++++++++++++++---------
>>  libavformat/movenc.h |  2 ++
>>  2 files changed, 16 insertions(+), 9 deletions(-)
>
>this breaks make fate / changes checksums
>if the changes are intended, the references would need to be updated
>with the patch doing the change
>
>make: *** [fate-lavf-mp4] Error 1
>make: *** [fate-lavf-mov] Error 1
>make: *** [fate-binsub-movtextenc] Error 1
>make: *** [fate-movenc] Error 1
>
>thanks
>
>[...]
>-- 
>Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>Asymptotically faster algorithms should always be preferred if you have
>asymptotical amounts of data


More information about the ffmpeg-devel mailing list