On Tue, 6 Jun 2017 11:16:01 -0700 Sasi Inguva <isasi-at-google....@ffmpeg.org> wrote:
> Fixes t/6421. If the videos starts with B frame, then the minimum composition > time as computed by stts + ctts will be non-zero. Hence we need to shift the > DTS, so that the first pts is zero. This was the intention of that > code-block. However it was subtracting by the wrong amount. > For example, for one of the videos in the bug nonFormatted.mp4 we have > stts: > sample_count duration > 960 1001 > ctts: > sample_count duration > 1 3003 > 2 0 > 1 3003 > .... > > The resulting composition times are : 3003, 1001, 2002, 6006, ... > The minimum composition time or PTS is 1001, which should be used to offset > DTS. However the code block was wrongly using ctts[0] which is 3003. Hence > the PTS was negative. This change computes the minimum pts encountered while > fixing the index, and then subtracts it from all the timestamps after the > edit list fixes are applied. > > fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2 > Bframes. Before this change the PTS of first two B-frames was -6006 and > -3003, and I am guessing one of them got dropped when being decoded and > remuxed to the framecrc before, and now it is not being dropped. > > Signed-off-by: Sasi Inguva <is...@google.com> > --- Applied. I added line breaks and white space to the commit message, and added links to those chromium issues. I hope that's ok. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel