Opened 6 years ago

Closed 6 years ago

#4924 closed defect (fixed)

PTS/DTS timestamps get broken when concatenating MPEG-TS files using -f concat

Reported by: Jarda Snajdr Owned by: Marton Balint
Priority: important Component: avfilter
Version: git-master Keywords: concat regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by Carl Eugen Hoyos)

Steps to reproduce:

  1. Download two *.ts files and a list.txt from this Dropbox URL:

  1. Concat them with this command:

ffmpeg -f concat -i list.txt -c copy output.ts

  1. 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 233. 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,

Attachments (3)

chunk-106.ts (161.6 KB ) - added by Carl Eugen Hoyos 6 years ago.
chunk-107.ts (130.5 KB ) - added by Carl Eugen Hoyos 6 years ago.
list.txt (36 bytes ) - added by Carl Eugen Hoyos 6 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 by Carl Eugen Hoyos, 6 years ago

Component: ffmpegavfilter
Description: modified (diff)
Keywords: concat regression added
Priority: normalimportant
Version: unspecifiedgit-master

Please send your patch to the FFmpeg development mailing list, patches are ignored on this bug tracker.

by Carl Eugen Hoyos, 6 years ago

Attachment: chunk-106.ts added

by Carl Eugen Hoyos, 6 years ago

Attachment: chunk-107.ts added

by Carl Eugen Hoyos, 6 years ago

Attachment: list.txt added

comment:2 by Marton Balint, 6 years ago

Cc: added

The main cause of the regression is that avformatcontext->start_time is unset after opening the stream, but set after reading the first packet.

With my inpoint patch concat demuxer was changed to use the start_time before reading the first packet.

comment:3 by Jarda Snajdr, 6 years ago

Marton, in concatdec.c:open_file, shouldn't you get the file_start_time from cat->avf->start_time instead of from avf->start_time? The cat->avf struct contains the correct info, my debugging shows, as it's been read by avformat_find_stream_info a few lines earlier. I can't find where avf->start_time is set, but it contains garbage - when processing the first file, it's 0, when processing the second, it's the start_time of the first, and when processing third and next ones it stays at the same value (the first file's start_time).

comment:4 by Marton Balint, 6 years ago

Owner: set to Marton Balint
Status: newopen

You're right. avf->start_time is the start time of the output format context, that's why it is unset, the code should use the input format context, which is cat->avf->start_time like you said.

I'll make a patch and submit it to ffmpeg-devel.

Thanks for figuring this out, and sorry for the regression.

comment:5 by Marton Balint, 6 years ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.