tpad weird behavior on clips that have been joined with concat

[fduck]

Summary of the bug:

The "tpad" filter works fine normally, but when I use it on a clip created by joining two or more clips with "concat", it outputs the joined clip without any padding.

Additionally, if I try to use the padded clip by "concat"ing with another clip, it gets even weirder: it outputs the original two concat'ed clips, with a piece from the end of another clip equal to the number of padding frames requested.

How to reproduce:

ffmpeg version: 4.4
built on Mac OS Big Sur (11.2.3)

1. Using tpad on a concat'ed clip:

% ffmpeg -y -i 'input.mp4' -filter_complex '
[0:v] split [one][two];
[one][two] concat [doubled];
[doubled] tpad=stop=30 [outV]
' -map [outV] 'output1.mp4' > output1.txt 2>&1

Expected output: two copies of input.mp4 with a pad of 30 black frames at the end.
Actual output: two copies of input.mp4 with no pad at the end.


2. Trying to concat the tpad'ed clip:

% ffmpeg -y -i 'input.mp4' -filter_complex '
[0:v] split [one][two];
[one][two] concat [doubled];
[doubled] split [one][two];
[one] tpad=stop=30 [one];
[one][two] concat [outV]
' -map [outV] 'output2.mp4' > output2.txt 2>&1

Expected output: two copies of input.mp4 followed by 30 black frames followed by two more copies of input.mp4.
Actual output: two copies of input.mp4 followed by the a repeat of the final 30 frames of input.mp4.

I tried a number of different input videos from diverse sources, all under a minute long, all mp4s in h.264 format.

I tried inserting ", setpts=PTS-STARTPTS" to reset the presentation timestamps after each operation, in case they were causing issues. That made no difference in the output.

Forgive me if this is something caused by user error. I think I understand how tpad is supposed to work, but maybe not.

[fduck]

Output of first command

[fduck]

Output of second command

[Elon Musk]

Fixed in 51c22f6621e57f2836048ec1779e2fe195786a9a