Remove white shape from black background silhouette, leaving a transparent shape *īrighten & increase saturation of original image In my example, two distinct inputs are required, resulting in one output.
I would ultimately like to pipe the output of one command into the next command, without the temporary files.Īlthough many questions discuss filter-complex (which is how I believe results passing as inputs is accomplished), I can't seem to find an example of commands that use filter_complexs flowing into other filter_complex commands (nested filter-complex commands?).
#FFMPEG FILTER COMPLEX CODE#
I've tried having a look at the source code and debugging it myself but I'm not too experienced with C.I've pieced together 3 commands but my solution involves writing a number of tempory files. There's some sort of deep-seated long-standing bug here that's never been fixed and has been a known issue since at least 2014 (in the ticket I linked originally). Of course, the expected behaviour here would be for FFmpeg to stop encoding once the shorter audio stream finishes, but that doesn't happen. The m4a file will obey the duration=shortest and stop when the other audio stream finishes, but encoding will continue until the video stream, which in this case is the longest stream, stops. You can prove this by using an input video that has an audio stream shorter than the video stream and trying it with my original command. In that case it just appears to be working. It works if you set this option to "shortest".īut this doesn't explain why the -shortest option doesn't work.įfmpeg -i input.mp4 -i song.m4a -lavfi amix=duration=shortest null -map -map -y output.mp4Įven with that command -shortest is still not actually getting triggered when adding duration=shortest to amix, because all that's doing is shortening the m4a back to the original video's audio stream, which is likely the same length as the video itself, so it's still reverting to default behaviour. Combine both files (-shortest should work here but it does not)įfmpeg -i input.mp4 -i song.m4a -lavfi amix null -map -map -shortest -y output.mp4 The issue can be easily recreated by anyone using these commands (courtesy of Michael Koch):įfmpeg -f lavfi -i testsrc2 -f lavfi -i sine=2000 -t 5 -y input.mp4įfmpeg -f lavfi -i sine=500 -t 10 -y song.m4a
#FFMPEG FILTER COMPLEX WINDOWS#
I'm using a self-compiled FFmpeg build on Linux (using the most recent Git version as of writing this) but I can confirm I can also recreate the issue with the official Linux AND Windows builds as well, even when using different audio and video files too. I guess my question is why is -shortest made redundant when combining both audio and video filters in a single -filter_complex argument? Is this a bug, or the intended behaviour? How can I get it to work as intended with just one -filter_complex? Using the above 2 commands results in a 20-second long video as intended. Same with if I remove the video filters entirely:įfmpeg -i input.mp4 -i song.m4a -filter_complex amix -map -map 0:v -shortest output.mp4 When I separate the audio and video filters into 2 separate -filter_complexs, it works as intended (doing this was also the solution given in the issue a linked at the top):Īmix -filter_complex pad=height=ceil(ih/2)*2:width=ceil(iw/2)*2 \ However, in the command above, -shortest seems to be not working entirely. To ensure that the output file does not become 8 minutes long, I'm using the -shortest option, which should make FFmpeg stop encoding once it hits the shortest audio/video stream. I want to mix both the audio streams together, so that the first 20 seconds of song.m4a plays alongside the original audio of input.m4a. Input.mp4 is only about 20 seconds long, but song.m4a is about 8 minutes long. I'm using the following command to mix the audio of input.mp4 with song.m4a and ensure that the dimensions of my output file are even numbers:įfmpeg -i input.mp4 -i song.m4a -filter_complex \Īmix pad=height=ceil(ih/2)*2:width=ceil(iw/2)*2 \ Pretty much the exact same issue was described here several years ago, but the 'solution' given, while it works, is more inconvenient and doesn't explain why the actual command in question does not work.
0 kommentar(er)
