[FFmpeg-trac] #4924(avfilter:new): PTS/DTS timestamps get broken when concatenating MPEG-TS files using -f concat
FFmpeg
trac at avcodec.org
Mon Oct 12 18:58:25 CEST 2015
#4924: PTS/DTS timestamps get broken when concatenating MPEG-TS files using -f
concat
-------------------------------------+-------------------------------------
Reporter: jsnajdr | Owner:
Type: defect | Status: new
Priority: important | Component: avfilter
Version: git-master | Resolution:
Keywords: concat | Blocked By:
regression | Reproduced by developer: 0
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Changes (by cehoyos):
* keywords: => concat regression
* priority: normal => important
* version: unspecified => git-master
* component: ffmpeg => avfilter
Old description:
> == Steps to reproduce: ==
> 1. Download two *.ts files and a list.txt from this Dropbox URL:
> https://www.dropbox.com/sh/j4rm230kj7qwlr1/AACkhVF8Eb7nQF77qORG85JAa?dl=0
> 2. Concat them with this command:
> {{{ffmpeg -f concat -i list.txt -c copy output.ts}}}
> 3. Look at the PTS/DTS timestamps of the output.ts file:
> {{{ffprobe -show_entries packet=codec_type,stream_index,pts,dts
> output.ts}}}
>
> == Expected result: ==
> The timestamps are in a continuous range and the transitions from one
> chunk to the next are seamless.
>
> == Actual result: ==
> The timestamps from the first chunk are OK, but at the start of the
> second, they start to be shifted by a big time interval backwards, which
> causes a timestamp wrap by 2^33. This causes a huge discontinuity and a
> resulting file duration of 26 hours instead of 6 seconds.
>
> Fixing the delta-computing algorithm in
> libavformat/concatdec.c:concat_read_packet fixed the issue for me (see
> the patch below). But I suspect it doesn't work in the general case. My
> case is special in that the timestamps are not-overlapping, following one
> sequence across files. Concatenating files where timestamps always start
> from zero probably won't work. I don't know how to fix it, the timestamp
> shifting/scaling logic is very complex and confusing.
>
> == Used software: ==
> ffmpeg bleeding-edge from Github master. The issue is new in 2.8 - it
> didn't happen in 2.7.
>
> == Proposed patch: ==
> {{{
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 832b7f4..1151b10 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -580,7 +580,7 @@ static int concat_read_packet(AVFormatContext *avf,
> AVPacket *pkt)
> av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
> av_ts2str(pkt->dts), av_ts2timestr(pkt->dts,
> &st->time_base));
>
> - delta = av_rescale_q(cat->cur_file->start_time -
> cat->cur_file->file_inpoint,
> + delta = av_rescale_q(cat->cur_file->file_start_time -
> cat->cur_file->file_inpoint,
> AV_TIME_BASE_Q,
> cat->avf->streams[pkt->stream_index]->time_base);
> }}}
New description:
== Steps to reproduce: ==
1. Download two *.ts files and a list.txt from this Dropbox URL:
https://www.dropbox.com/sh/j4rm230kj7qwlr1/AACkhVF8Eb7nQF77qORG85JAa?dl=0
2. Concat them with this command:
{{{ffmpeg -f concat -i list.txt -c copy output.ts}}}
3. Look at the PTS/DTS timestamps of the output.ts file:
{{{ffprobe -show_entries packet=codec_type,stream_index,pts,dts
output.ts}}}
== Expected result: ==
The timestamps are in a continuous range and the transitions from one
chunk to the next are seamless.
== Actual result: ==
The timestamps from the first chunk are OK, but at the start of the
second, they start to be shifted by a big time interval backwards, which
causes a timestamp wrap by 2^33^. This causes a huge discontinuity and a
resulting file duration of 26 hours instead of 6 seconds.
Fixing the delta-computing algorithm in
libavformat/concatdec.c:concat_read_packet fixed the issue for me (see the
patch below). But I suspect it doesn't work in the general case. My case
is special in that the timestamps are not-overlapping, following one
sequence across files. Concatenating files where timestamps always start
from zero probably won't work. I don't know how to fix it, the timestamp
shifting/scaling logic is very complex and confusing.
== Used software: ==
ffmpeg bleeding-edge from Github master. The issue is new in 2.8 - it
didn't happen in 2.7.
== Proposed patch: ==
{{{
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 832b7f4..1151b10 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -580,7 +580,7 @@ static int concat_read_packet(AVFormatContext *avf,
AVPacket *pkt)
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base));
- delta = av_rescale_q(cat->cur_file->start_time -
cat->cur_file->file_inpoint,
+ delta = av_rescale_q(cat->cur_file->file_start_time -
cat->cur_file->file_inpoint,
AV_TIME_BASE_Q,
cat->avf->streams[pkt->stream_index]->time_base);
}}}
--
Comment:
Please send your patch to the FFmpeg development mailing list, patches are
ignored on this bug tracker.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4924#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list