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

[wm4]

On Sat, 3 Jun 2017 19:31:37 -0700
Sasi Inguva <isasi-at-google.com at ffmpeg.org> wrote:

> > -    // Offset the DTS by ctts[0] to make the PTS of the first frame 0
> > -    if (ctts_data_old && ctts_count_old > 0) {
> > -        edit_list_dts_entry_end -= ctts_data_old[0].duration;
> > -        av_log(mov->fc, AV_LOG_DEBUG, "Offset DTS by ctts[%d].duration:  
> %d\n", 0, ctts_data_old[0].duration);
> > +        av_log(mov->fc, AV_LOG_DEBUG, "Shifting DTS by %d because of  
> negative CTTS.\n", msc->dts_shift);
> >      }  
> 
> The above lines were the cause of making the first frame PTS of videos
> starting with B-frames negative. 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, ...
> Hence 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.
> 
> About the fate test expectations, 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 but I dont understand why.

All of this should go into the commit message.

Can't judge the correctness of the actual code.