On Sat, 3 Jun 2017 19:31:37 -0700
Sasi Inguva <isasi-at-google....@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
