[FFmpeg-devel] [PATCH, V2] avformat/concat: Fix wrong wrapped timestamp
mymoeyard at gmail.com
Fri Dec 29 18:17:44 EET 2017
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.
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Sorry for top-posting.
Normally pts_wrap_reference is based on the first packet when calling
which will call function update_wrap_reference , in libavformat/utils line
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)
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,
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.
More information about the ffmpeg-devel