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

Sasi Inguva isasi at google.com
Thu Jun 8 22:28:41 EEST 2017


Ping!

On Jun 6, 2017 11:17 AM, "Sasi Inguva" <isasi at google.com> wrote:

> Got it. Added to the description.
>
> On Tue, Jun 6, 2017 at 6:51 AM, wm4 <nfxjfg at googlemail.com> wrote:
>
>> 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.
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>


More information about the ffmpeg-devel mailing list