On Fri, Nov 29, 2019 at 3:44 PM manuelyuan <manuely...@163.com> wrote: > > Of course I did，and I can give you the bad case videos for your analysis if > you need. > How can I give them to you？ > > At 2019-11-28 14:38:34, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote: > > > > > >> Am 28.11.2019 um 03:34 schrieb manuelyuan <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. > > > >Do you have access to a stream analyser to verify the output file with your > >patch? > > I think you can open a ticket in trac (https://trac.ffmpeg.org/) and upload/attached the sample to the ticket _______________________________________________ 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".
