Comment by tbran | Hacker News Reader

Comment by tbran | Hacker News Reader

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/

Just 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

Edit: small correction: I said PNG before, but it's actually BMPs that are usually in bgr24.

If 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.

I feel the same about imagemagick. Oh the things you can do with just curl, bash, imagemagick... And gnuplot if you're rich.

Why do you need to be rich for gnuplot? Aren't gnu things generally GPL?

My guess is they’re referring the need for lots of compute power to get it to run in a reasonable time, which is expensive

Sorry 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...

Apparently 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.

Or 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 :-)

FFmpeg 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.

I'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.

> 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

If 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.

The 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

No to mention you also loss quality (the generation loss) unless you use lossless format as intermediate.

> 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.

Challenge accepted! (No seriously, that's what I'm working on)

Maybe what's missing is some kind of ffmpeg shell where you can build pipelines and then run them? A bit like spark-shell, or avisynth on windows?

I actually made my own CLI frontend just because I didn't want to try and memorize ffmpeg options to do the simple things that I want to do most of the time. Now I can just do `--h264 -s X -e Y` to do a h.264 encode from X timecode to Y timecode.

Is -s X -e Y really much easier than -ss X -t $((Y-X)) ?

Every couple of years worth of not using an option I need to look it up again. But it's usually not too hard.

Yes, because that doesn't actually work proper. In order to seek fast while having the ability to start encoding at any point without issues with keyframes, I need to actually do `ffmpeg -ss X1 -i FILE -ss X2 -t (Y-X)` where X1 + X2 = X.

Compare:

    frontend -s 05:28:38.667 -e 05:28:58.767 input.ts
    ffmpeg -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 1
    ffmpeg -y -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 2

I've been working on making "pre-baked recipes" for a while to help with simple tasks like cutting/merging a video [0]. I recently made an npm package for making time lapses with effects from the command line with FFmpeg as well [1].

[0] https://github.com/zvakanaka/ffeasy [1] https://www.npmjs.com/package/mklapse

The syntax is very difficult to wrap your head around, but beyond that, it is the implicit behavior that makes it difficult to reason about. I find that the short ffmpeg commands that take advantage of automatic stream selection and omit the inputs/outputs of filters because ffmpeg can hook them up automatically to be much harder to reason about than the fully written out, fully explicit ffmpeg command lines.

It almost seems like the best way to understand an ffmpeg complex filter graph is to actually draw a graph...

I wrap it in shell scripts or batch files.

That'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/) 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.

Insert a line break at every instance of a ":" (while editing) and it becomes a lot clearer.

> 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.

Just 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.

There's probably a way to fix the compression artefacts there too. Something like https://stackoverflow.com/a/42989654/280795

https://trac.ffmpeg.org/wiki/Xfade

You can try Xfade filter, hope oneday I can write opengl glsl effect in ffmpeg.

Reply on news.ycombinator.com