That's great. Thanks. On Jun 9, 2017 9:24 AM, "wm4" <nfx...@googlemail.com> wrote:
> 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 > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
