FFmpeg 4.3 - Hackdot

Re:FFmpeg 4.3 by tbran on Tuesday June 16, 2020 @01:27PM (#23541691)

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/

[ Parent | on HN ]

Re:FFmpeg 4.3 by fireattack on Tuesday June 16, 2020 @07:28PM (#23545617)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by nine_k on Tuesday June 16, 2020 @01:52PM (#23541974)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by touisteur on Tuesday June 16, 2020 @06:24PM (#23545044)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by strombofulous on Tuesday June 16, 2020 @08:23PM (#23546120)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by touisteur on Wednesday June 17, 2020 @02:58AM (#23548570)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by boomboomsubban on Wednesday June 17, 2020 @11:32AM (#23552630)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by touisteur on Wednesday June 17, 2020 @06:35PM (#23557615)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by bobbylarrybobby on Tuesday June 16, 2020 @08:43PM (#23546290)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by crispyambulance on Tuesday June 16, 2020 @01:54PM (#23542005)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by danudey on Tuesday June 16, 2020 @02:27PM (#23542429)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by rezonant on Tuesday June 16, 2020 @09:45PM (#23546770)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by dmerrick on Tuesday June 16, 2020 @09:29PM (#23546651)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by innocenat on Wednesday June 17, 2020 @01:22AM (#23548099)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by lmm on Wednesday June 17, 2020 @04:34AM (#23549177)

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?

[ Parent | on HN ]

Re:FFmpeg 4.3 by quintonish on Tuesday June 16, 2020 @04:15PM (#23543534)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by simcop2387 on Tuesday June 16, 2020 @02:20PM (#23542345)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by shakna on Tuesday June 16, 2020 @08:52PM (#23546369)

> 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

[ Parent | on HN ]

Re:FFmpeg 4.3 by rezonant on Tuesday June 16, 2020 @09:49PM (#23546802)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by Hamuko on Tuesday June 16, 2020 @03:35PM (#23543145)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by asveikau on Tuesday June 16, 2020 @11:12PM (#23547320)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by Hamuko on Wednesday June 17, 2020 @02:41AM (#23548478)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by scooter_de on Thursday June 18, 2020 @10:49PM (#23570493)

I wrap it in shell scripts or batch files.

[ Parent | on HN ]

Re:FFmpeg 4.3 by blululu on Tuesday June 16, 2020 @03:04PM (#23542829)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by LeoPanthera on Tuesday June 16, 2020 @02:47PM (#23542650)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by VWWHFSfQ on Tuesday June 16, 2020 @07:53PM (#23545836)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by 0x6c6f6c on Tuesday June 16, 2020 @06:00PM (#23544793)

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.

[ Parent | on HN ]

Re:FFmpeg 4.3 by nl on Wednesday June 17, 2020 @04:30AM (#23549153)

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

[ Parent | on HN ]

Re:FFmpeg 4.3 by kimown on Tuesday June 16, 2020 @09:53PM (#23546827)

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

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

[ Parent | on HN ]