Concat of AAC + MP4 has gaps

[ronag]

ffmpeg -i big_buck_bunny.mp4 -ss 8 -to 10 -vn -c:a libfdk_aac 1.mp4
ffmpeg -i big_buck_bunny.mp4 -ss 10 -to 12 -vn -c:a libfdk_aac 2.mp4

touch list.txt
printf "file 1.mp4\nduration 2\nfile 2.mp4\nduration 2" > list.txt
ffplay -f concat -i list.txt

This problem seems to occur with most audio codecs/formats except for pcm_s16le + wav.

[ronag]

You can see in the attached screenshot that there is a gap in the audio exactly at the 2 second mark.

[ronag]

If I would guess then for some reason all the coded audio is not properly flushed to the end or 0 samples are appended to make the audio length evenly dividable by some chunk size.

[Carl Eugen Hoyos]

Is the issue only reproducible with ffplay or also with ffmpeg?
Is the issue only reproducible with libfdk or also with the native aac encoder?

[ronag]

Same problem with both 'aac' and 'libmp3lame'. Also tried with:

ffmpeg -f concat -i list.txt -c copy -f nut - | ffplay -i -

With 'opus' there is no gap but there is audible distortion at the 2 second mark.

[ronag]

Same problem with both 'aac' and 'libmp3lame'. Also tried with:

ffmpeg -f concat -i list.txt -c copy -f nut - | ffplay -i -

With 'opus' there is no gap but there is audible distortion at the 2 second mark.

[ronag]

This might be interesting:

[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=93184, dts=93184, size=1288, duration=1024, flags=1
[concat @ 0x7f8052808200] file:0 stream:0 pts:92160 pts_time:1.92 dts:92160 dts_time:1.92 -> pts:94208 pts_time:1.96267 dts:94208 dts_time:1.96267
[concat @ 0x7f8052808200] ff_read_packet stream=0, pts=94208, dts=94208, size=1291, duration=1024, flags=1
[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=94208, dts=94208, size=1291, duration=1024, flags=1
[concat @ 0x7f8052808200] file:0 stream:0 pts:93184 pts_time:1.94133 dts:93184 dts_time:1.94133 -> pts:95232 pts_time:1.984 dts:95232 dts_time:1.984
[concat @ 0x7f8052808200] ff_read_packet stream=0, pts=95232, dts=95232, size=1308, duration=1024, flags=1
[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=95232, dts=95232, size=1308, duration=1024, flags=1
[concat @ 0x7f8052808200] file:0 stream:0 pts:94208 pts_time:1.96267 dts:94208 dts_time:1.96267 -> pts:96256 pts_time:2.00533 dts:96256 dts_time:2.00533
[concat @ 0x7f8052808200] ff_read_packet stream=0, pts=96256, dts=96256, size=1388, duration=1024, flags=1
[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=96256, dts=96256, size=1388, duration=1024, flags=1
[concat @ 0x7f8052808200] file:0 stream:0 pts:95232 pts_time:1.984 dts:95232 dts_time:1.984 -> pts:97280 pts_time:2.02667 dts:97280 dts_time:2.02667
[concat @ 0x7f8052808200] ff_read_packet stream=0, pts=97280, dts=97280, size=1245, duration=2816, flags=1
[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=97280, dts=97280, size=1245, duration=2816, flags=1
[AVIOContext @ 0x7f805160cc00] Statistics: 160440 bytes read, 2 seeks
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8051874e00] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8051874e00] ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8051874e00] Before avformat_find_stream_info() pos: 83269 bytes read:33726 seeks:1
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8051874e00] All info found
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8051874e00] After avformat_find_stream_info() pos: 1347 bytes read:66494 seeks:2 frames:1
[concat @ 0x7f8052808200] file:1 stream:0 pts:-2048 pts_time:-0.0426667 dts:-2048 dts_time:-0.0426667 -> pts:98064 pts_time:2.043 dts:98064 dts_time:2.043
[concat @ 0x7f8052808200] ff_read_packet stream=0, pts=98064, dts=98064, size=1303, duration=1024, flags=1
[concat @ 0x7f8052808200] read_frame_internal stream=0, pts=98064, dts=98064, size=1303, duration=1024, flags=1
[concat @ 0x7f8052808200] file:1 stream:0 pts:-1024 pts_time:-0.0213333 dts:-1024 dts_time:-0.0213333 -> pts:99088 pts_time:2.06433 dts:99088 dts_time:2.064

[ronag]

Figured out what might be the issue:

Since most audio codecs have a specific frame_size ffmpeg will append zero samples and adjust the pts. This means that the pts values of 2 segments (i.e. segments can start at a negative pts) can slightly overlap and that is not properly handled.

[ronag]

Another example of weirdness:

ffmpeg -i src -af atrim=start_sample=1024*48*0:end_sample=1024*48*5 0.aac
ffmpeg -i src -af atrim=start_sample=1024*48*5:end_sample=1024*48*10 1.aac
cat 0.aac 1.aac | ffplay -f aac -

Produces a gap in the seam.

[derekr]

I believe I'm running into the same issue as this, with trying to do segmented transcode of video clips. Playback on the DASH client side produces these audio artifacts around segment boundaries.

Has there been any progress on this, or is there a solution/workaround for the issue?

[Enoque Filipe Costa Duarte]

Having the same issue with version N-78964-g5061579