concat filter: new fault between FFmpeg branches 5.1 and 6

[John Warburton]

Summary of the bug:
How to reproduce:
In FFmpeg latest git as of 13 June 2023, this concat of two pieces of audio, produced from the same input, hangs after the first ends. But in FFmpeg branch 5.1, it works as expected.

The point of this code is to copy the first 163 seconds of a news broadcast. Then, beyond 163 seconds, search for a brief pause in the audio, and end the copy of the audio at exactly that point.

% ffmpeg -v debug -y -i cbsnews-temp.mka -filter_complex "[0:0]asplit=2[st][fi];[fi]atrim=start=163,silenceremove=stop_periods=1:stop_threshold=-30dB:stop_duration=0.4,asetpts=N/SR/TB[cl];[st]atrim=end=163,asetpts=N/SR/TB[stc];[stc][cl]concat=n=2:a=1:v=0,asetpts=N/SR/TB,dynaudnorm=b=1:g=7,volume=-11dB" -acodec libfdk_aac -ar 48000 -ac 2 -vbr 5 cbsnews.mka

In latest FFmpeg git, the debug output stops here, showing only one of the two segments passed to the concat filter is read properly:

[Parsed_concat_4 @ 0x55feb835d580] EOF on in0:a0, 0 streams left in segment.
[Parsed_concat_4 @ 0x55feb835d580] Segment finished at pts=163000000

But in FFmpeg branch 5.1, we have this, in a successful encoding:

[Parsed_concat_6 @ 0x55dff39e4c80] EOF on in0:a0, 0 streams left in segment.
[Parsed_concat_6 @ 0x55dff39e4c80] Segment finished at pts=162999334
[Parsed_concat_6 @ 0x55dff39e4c80] EOF on in1:a0, 0 streams left in segment.
[Parsed_concat_6 @ 0x55dff39e4c80] Segment finished at pts=169547293

...showing both segments passed to the concat filter are used properly.

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[John Warburton]

Audio used for test purposes, to slice at silence

[Elon Musk]

Fixed in 374184a4dc16421ec6b182191898582d9275808a

[John Warburton]

Thank you for this work. Confirming this is fixed, as far as my test case allows me to discover.