Mpegts packet corrupt with ffmpeg concat protocol - ffmpeg

Question

I'm trying to use the concat protocol in ffmpeg as described in the ffmpeg docs:
https://trac.ffmpeg.org/wiki/Concatenate
However I'm getting lots of errors about corrupt packets when running the concat, so I'm worried that this isn't the best approach. My actual use case will involve running unsupervised with a ton of different source videos, so I want to be sure that it's solid.
The concat demuxer approach succeeds without errors but takes about 10 times as long.
Steps to reproduce
Download Big Buck Bunny:
wget https://download.blender.org/demo/movies/BBB/bbb_sunflower_1080p_30fps_normal.mp4
Transcode a 30 second chunk:
ffmpeg -i bbb_sunflower_1080p_30fps_normal.mp4 -ss '00:06:30' -t 30 -c:v libx264 -crf 18 bbb30.mp4
Create one second parts:
mkdir -p parts;
for i in $(seq -f "%02g" 0 29); do \
ffmpeg \
-i bbb30.mp4 \
-ss "00:00:$i" -t 1 \
-c:v libx264 -pix_fmt yuv420p -crf 18 \
-bsf:v h264_mp4toannexb \
-f mpegts \
-y parts/$i.ts;
done
Combine all the parts into a new output mp4:
ffmpeg -y \
-i "concat:parts/00.ts|parts/01.ts|parts/02.ts|parts/03.ts|parts/04.ts|parts/05.ts|parts/06.ts|parts/07.ts|parts/08.ts|parts/09.ts|parts/10.ts|parts/11.ts|parts/12.ts|parts/13.ts|parts/14.ts|parts/15.ts|parts/16.ts|parts/17.ts|parts/18.ts|parts/19.ts|parts/20.ts|parts/21.ts|parts/22.ts|parts/23.ts|parts/24.ts|parts/25.ts|parts/26.ts|parts/27.ts|parts/28.ts|parts/29.ts" \
-c copy \
output.mp4
Stderr has lots of warnings about corrupt packets (in this case always at dts = 21300):
[mpegts # 0x555d172daa00] Packet corrupt (stream = 0, dts = 213000).
concat:parts/00.ts|parts/01.ts|parts/02.ts|parts/03.ts|parts/04.ts|parts/05.ts|parts/06.ts|parts/07.ts|parts/08.ts|parts/09.ts|parts/10.ts|parts/11.ts|parts/12.ts|parts/13.ts|parts/14.ts|parts/15.ts|parts/16.ts|parts/17.ts|parts/18.ts|parts/19.ts|parts/20.ts|parts/21.ts|parts/22.ts|parts/23.ts|parts/24.ts|parts/25.ts|parts/26.ts|parts/27.ts|parts/28.ts|parts/29.ts: corrupt input packet in stream 0
The resulting mp4 looks ok to my eye, but obviously ffmpeg isn't happy about something. Any ideas?

Answer 1

You can ignore these warnings.
Packets in a MPEG-TS container have a counter field which increments with each packet. These are expected to be continuous. Since you encoded your TS files in separate instances, that counter will start with 0 when switching from one TS input to another. But this has no salience in this use case. This happens with the concat protocol because a single TS demuxer instance is used to read all inputs as an amalgamated whole. The concat demuxer open a fresh TS demuxer for each input and then stitches all packets as a single stream.