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" <mich...@niedermayer.cc> wrote: >On Wed, Nov 06, 2019 at 10:36:11AM +0800, manuelyuan wrote: >> From: Mengyang Yuan <manuely...@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 <manuely...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
