[FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

[Sasi Inguva]

That's great. Thanks.

On Jun 9, 2017 9:24 AM, "wm4" <nfxjfg at googlemail.com> wrote:

> On Tue,  6 Jun 2017 11:16:01 -0700
> Sasi Inguva <isasi-at-google.com at 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 <isasi at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>