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

Reply via email to