[FFmpeg-devel] [PATCH, V2] avformat/concat: Fix wrong wrapped timestamp

[Wu Zhiqiang]

On Fri, Dec 29, 2017 at 8:00 PM, Nicolas George <george at nsup.org> wrote:

> Hi. Sorry for having missed your reply earlier.
>
> 吴志强 (2017-12-18):
> > I see wrap timestamp control is enable by pts_wrap_bits(default 33),
> > but mp4 demuxer  will later set this to 64 (means disabled).
> > Now pts_wrap_bits are always tied to 33 without copy it, which seems
> > strange.
>
> I understand the logic of this patch less and less. Why are you speaking
> about the MP4 demuxer?
>
> If I understand correctly how unwrapping timestamp works, concat should
> never have to do it.
>
> > 2017-12-17 22:55 GMT+08:00 Nicolas George <george at nsup.org>:
>
> Please remember that top-posting on this list is forbidden. If you do
> not know what it means, look it up.
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Sorry for top-posting.

Normally pts_wrap_reference is based on the first packet when calling
ff_read_packet,
which will call  function update_wrap_reference , in libavformat/utils line
734:

    if (ref == AV_NOPTS_VALUE)
        ref = pkt->pts;
    if (st->pts_wrap_reference != AV_NOPTS_VALUE || st->pts_wrap_bits >= 63
|| ref == AV_NOPTS_VALUE || !s->correct_ts_overflow)
        return 0;
    ref &= (1LL << st->pts_wrap_bits)-1;

    // reference time stamp should be 60 s before first time stamp
    pts_wrap_reference = ref - av_rescale(60, st->time_base.den,
st->time_base.num);

Because  concat_read_header  and concat_seek do not call ff_read_packet and
open_file does not copy pts_wrap_reference,
it is constant value during playing.

If  demuxing packets like avformat_open_input => avformat_seek_file =>
av_read_frame and seek time is larger than 60s,
the constant reference time will be positive value and not  indicate the
normal wrap margin.

Then seeking to time before pts_wrap_reference may generate huge timestamp,
which  not expected.

Thanks.