Different trimming of multi video output using ffmpeg filter_complex

Question

I need to generate two different videos starting from a common input source. For the sake of semplicity let's say they are different only in start time and duration, but production code is more complex and I must use filter_complex, so no -ss -to options are available.

This is my current script:

/Users/Luca/Downloads/ffmpeg-macosx -y \
-i "/Users/Luca/Downloads/2_dongiovanni_mov.mov" \
-filter_complex "\
[0:v]split=2[v1][v4];\
[v1]\
scale='if(gt(a,1.7777777777778),640,-2)':'if(gt(a,1.7777777777778),-2,360)',\
trim=start=4:duration=10,\
setpts=PTS-STARTPTS\
[vout1];\
[v4]\
scale='if(gt(a,1.7777777777778),640,-2)':'if(gt(a,1.7777777777778),-2,360)',\
trim=start=0:duration=247,\
setpts=PTS-STARTPTS\
[vout4];\
[0:a]asplit=2[a1][a4];\
[a1]\
atrim=start=4:duration=10,\
asetpts=PTS-STARTPTS\
[aout1];\
[a4]\
atrim=start=0:duration=247,\
asetpts=PTS-STARTPTS\
[aout4]" \
-map [vout1] -map [aout1] -codec:v libx264 -b:v 1000k -codec:a aac -b:a 384k -strict experimental  "/Users/Luca/Downloads/preview.mp4" \
-map [vout4] -map [aout4] -codec:v libx264 -b:v 5000k -codec:a aac -b:a 384k -strict experimental  "/Users/Luca/Downloads/large.mp4" \
2>&1

preview.mp4 (the [v1][a1] segment) is ok, as it lasts only 10 seconds (and it starts at 4th second of original video). Audio is also ok.

large.mp4 ([v4][a4]) lasts 247 seconds but the video is freezed at exactly 14 seconds (that is 4+10 of the first output) while audio has no problem (lasts 247 seconds without any freeze).

Works as expected when:

1) I remove both "scale" filters

OR

2) I swap the "trim" filters so basically ffmpeg can process the longest first and then the shortest (see the code below)

/Users/Luca/Downloads/ffmpeg-macosx -y \
-i "/Users/Luca/Downloads/2_dongiovanni_mov.mov" \
-filter_complex "\
[0:v]split=2[v1][v4];\
[v1]\
scale='if(gt(a,1.7777777777778),640,-2)':'if(gt(a,1.7777777777778),-2,360)',\
trim=start=0:duration=247,\
setpts=PTS-STARTPTS\
[vout1];\
[v4]\
scale='if(gt(a,1.7777777777778),640,-2)':'if(gt(a,1.7777777777778),-2,360)',\
trim=start=4:duration=10,\
setpts=PTS-STARTPTS\
[vout4];\
[0:a]asplit=2[a1][a4];\
[a1]\
atrim=start=0:duration=247,\
asetpts=PTS-STARTPTS\
[aout1];\
[a4]\
atrim=start=4:duration=10,\
asetpts=PTS-STARTPTS\
[aout4]" \
-map [vout1] -map [aout1] -codec:v libx264 -b:v 1000k -codec:a aac -b:a 384k -strict experimental  "/Users/Luca/Downloads/preview.mp4" \
-map [vout4] -map [aout4] -codec:v libx264 -b:v 5000k -codec:a aac -b:a 384k -strict experimental  "/Users/Luca/Downloads/large.mp4" \
2>&1

Anyone can explain this?

Answer 1

Strange behaviour. I can reproduce it here with a recent Windows binary. You should file a bug report.

Workarounds

#1 Place scale before split and process child streams in desired order.

[0:v]scale='if(gt(a,16/9),640,-2)':'if(gt(a,16/9),-2,360)',split=2[v1][v4];\

#2 Process child streams in desired order, but place scale after trim.

[v1]trim=..., scale=..., setpts=PTS-STARTPTS[vout1]; \
[v4]trim=..., scale=..., setpts=PTS-STARTPTS[vout2]; \

#3 If working directly on input, no need to split.

[0:v]scale=..., trim=..., setpts=PTS-STARTPTS[vout1]; \
[0:v]scale=..., trim=..., setpts=PTS-STARTPTS[vout2]; \