5 ms·
I wanted to create a slideshow a couple weeks ago and came across this article [0] on creating a Ken Burns Effect Slideshow. Very cool and is a great demo of so
by tbran 6y ago
I wanted to create a slideshow a couple weeks ago and came across this article [0] on creating a Ken Burns Effect Slideshow. Very cool and is a great demo of some of ffmpeg's functionality.
However, the final command is a little crazy:
ffmpeg -i 1.jpg -i 2.jpg -i 3.jpg
-filter_complex "color=c=black:r=60:size=1280x800:d=10[black];[0:v]format=pix_fmts=yuva420p,crop=w=2*floor(iw/2):h=2*floor(ih/2),zoompan=z='if(eq(on,1),1,zoom+0.000417)':x='0':y='ih-ih/zoom':fps=60:d=60*4:s=1280x800,crop=w=1280:h=800:x='(iw-ow)/2':y='(ih-oh)/2',fade=t=in:st=0:d=1:alpha=0,fade=t=out:st=3:d=1:alpha=1,setpts=PTS-STARTPTS[v0];[1:v]format=pix_fmts=yuva420p,crop=w=2*floor(iw/2):h=2*floor(ih/2),pad=w=9600:h=6000:x='(ow-iw)/2':y='(oh-ih)/2',zoompan=z='if(eq(on,1),1,zoom+0.000417)':x='0':y='0':fps=60:d=60*4:s=1280x800,fade=t=in:st=0:d=1:alpha=1,fade=t=out:st=3:d=1:alpha=1,setpts=PTS-STARTPTS+1*3/TB[v1];[2:v]format=pix_fmts=yuva420p,crop=w=2*floor(iw/2):h=2*floor(ih/2),zoompan=z='if(eq(on,1),1,zoom+0.000417)':x='0':y='0':fps=60:d=60*4:s=1600x800,crop=w=1280:h=800:x='(iw-ow)/2':y='(ih-oh)/2',fade=t=in:st=0:d=1:alpha=1,fade=t=out:st=3:d=1:alpha=0,setpts=PTS-STARTPTS+2*3/TB[v2];[black][v0]overlay[ov0];[ov0][v1]overlay[ov1];[ov1][v2]overlay=format=yuv420"
-c:v libx264 out.mp4
[0] https://el-tramo.be/blog/ken-burns-ffmpeg/ https://el-tramo.be/blog/ken-burns-ffmpeg/
- nine_k 6y agoIf you read the post by the link, each of these settings (or rather groups thereof) look reasonable and readabale in isolation. This demonstrates, in a rather extreme example, the colossal composability of the interface, even if it lacks nice formatting here.
- touisteur 6y agoI feel the same about imagemagick. Oh the things you can do with just curl, bash, imagemagick... And gnuplot if you're rich.
- strombofulous 6y agoWhy do you need to be rich for gnuplot? Aren't gnu things generally GPL?
- bobbylarrybobby 6y agoMy guess is they’re referring the need for lots of compute power to get it to run in a reasonable time, which is expensive
- touisteur 6y agoSorry it was a bit tongue in cheek. On many systems I work with and have to debug, gnuplot won't be already installed (and won't be installable on a system not connected to the Internet) so 'rich' would be 'flush in packages with a full system available'. Sometimes, even imagemagick isn't there, but rsvg-convert is, you can still do amazing things with just bash+curl+svg...
- boomboomsubban 6y agoApparently gnuplot is unrelated to GNU, and the original developers were making a pun on "newplot." It's license is a bit complicated, which is why most systems don't have it.
- touisteur 6y agoOr the IT security guys that expertly hand-picked all your available packages for minimum attack surface removed it (but let imagemagick... after some time you stop asking some questions :-)
- crispyambulance 6y agoFFmpeg is infamous for absurdly complex command options. It's really too much for a "one-liner" CLI. When I use it, I just look for "pre-baked recipes" otherwise it's a really unpleasant rabbit hole to get into.
- simcop2387 6y agoI'd recommend looking at something like kdenlive, it generates the ffmpeg command and script for you. It's still complex and difficult to do somethings but it can be much nicer than trying to work out the command line interface for something you want to do. It's also nice because you can save the project at a higher level and reopen it later without having to do all the work of figuring things out again.
- shakna 6y ago> I'd recommend looking at something like kdenlive, it generates the ffmpeg command and script for you. Doesn't kdenlive use melt [0] instead of ffmpeg directly? [0] https://www.mltframework.org https://www.mltframework.org
- danudey 6y agoIf you look at it as more of a "composable" interface (as the sibling poster suggested), it makes a lot more sense. No one is going to type out this one-liner from scratch, or have an easy time understanding what it means by reading it, but as it's made up of a series of smaller, more easily understood commands, in a shell or Python script it could be vastly more legible and, dare I say it, usable. This is also the reason why there are so many frontends to ffmpeg, to simplify various specific tasks. I can't count how many one-off apps I've seen that do one thing and do it well, and just ship a full copy of ffmpeg to do that one thing. Making an actual GUI for all of this would be just... insane, really, but it's so versatile and flexible that you can basically do anything with it.
- dmerrick 6y agoThe problem with calling ffmpeg multiple times in a script is you often waste compute time. If you can manage to cobble together a single command (as illegible as that may be), you might be able to do what you're looking to do in far less time
- LeoPanthera 6y agoInsert a line break at every instance of a ":" (while editing) and it becomes a lot clearer.
- blululu 6y agoThat's awesome. Every section on the command is simple, but taken as a whole, it is pretty thorny. I find that MoviePy (https://zulko.github.io/moviepy/ https://zulko.github.io/moviepy/) is a great tool for more complex operations like the aboce. A lot of MoviePy's functionality is derived from an FFMPEG wrapper, but it is just easier to split things up into a small script.
- 0x6c6f6c 6y agoJust did a little 1-day hackathon project where we built out a video presentation automation tool. One of those components would compile together a series of photos, video, and audio clips (with optional text to go with it for subtitle generation) and it would build everything out. The final command would look insane, there being a line for each added clip and any spacing between them, but it worked perfectly.
- fireattack 6y agoJust so you know, FFMPEG has a long-standing bug (reported 8 years ago) [1] that affects precisely the type of work you're doing, converting static images to video. The gist of it is that if your static image is in bgr24 (most of BMP images) format, when converting to typical video pixel format (like yuv420p), the color will be distorted. This can be worked around by converting to rgb24 first (which is exactly why this bug is bizarre, since the two should be practically identical.) (There is also the BT601/BT709 conversion thing, but that's not a bug, just something need to be taken care of.) [1] https://trac.ffmpeg.org/ticket/979 https://trac.ffmpeg.org/ticket/979 Edit: small correction: I said PNG before, but it's actually BMPs that are usually in bgr24.
- VWWHFSfQ 6y ago> However, the final command is a little crazy Someone could make a million dollars by making a blog that just writes about ffmpeg incantations for use-cases like this.
- kimown 6y agohttps://trac.ffmpeg.org/wiki/Xfade https://trac.ffmpeg.org/wiki/Xfade You can try Xfade filter, hope oneday I can write opengl glsl effect in ffmpeg.
- nl 6y agoThere's probably a way to fix the compression artefacts there too. Something like https://stackoverflow.com/a/42989654/280795 https://stackoverflow.com/a/42989654/280795