FWIW when I asked about doing something on IRC (splitting a stream, process one, and overlay it over the existing one at 20%), they were quite helpful.

It was: `split[a][b];[b]lut3d=${path}[c];[a][c]blend=all_mode=overlay:all_opacity=${opacity}`

I find gstreamer (using gst-launch)[1] a more pleasant experience than ffmpeg.

You can't use some expresions on the command line like `x=(w-text_w)/2:y=(h-text_h)` but it can be workaround with some scripting using python bindings for example.

Some (simple) text overlay can be acomplished with:

  gst-launch filesrc location=sample.mp4 \
    ! decodebin \
    ! videoconvert \
    ! textoverlay text="Hello" font-desc="Sans Bold 150px" y-absolute=0.5 \
    ! autovideosink

1. http://manpages.org/gst-launch

They also have very cool support for HTML overlays: https://base-art.net/Articles/web-overlay-in-gstreamer-with-...

Looks like BBC’s Brave project was the inspiration for this: https://github.com/bbc/brave (specifically the gst-WebRenderSrc) Brave is a real-time remote video/audio editing app. Looks neat.

Unrelated but wow, BBC has quite a bit of interesting and relevant open source projects. Simorgh, their react SSR framework, caught my eye “used on some of our biggest websites”. Encouraging for those looking to build out performance react/amp platforms https://github.com/bbc/simorgh

I used CasparCG[0] to do live html overlays with a major broacaster out of Singapore about 5 years ago, still going strong. The actual on air graphics that were used rather tame compared with the sample ones I did to prove the system.

[0] https://github.com/CasparCG/

Why do you say you can't do expressions like that on the command line? I do it all of the time. You have to escape the parentheses, but other than that it is totally doable.

You can't use expressions like that (from ffmpeg cmld) in gst-launch.

As far as I know in gst-launch you can't access properties from one element (video stream width) in other elements.

Yes, and the best part is everything is turned into command line arguments.

ffmpeg of 15 years ago was confusing, but now it's so simple - to compile, to add your own filters, and to use, they've done a great job.

Yes, same here. The big problem is that the filters DSL is probably too complex because it uses too many short expressions.

It is unbelievably powerful though.

Very true. And, the parameters change over time, but, the stackoverflow answers using the old parameters remain on top. This IMO adds to the confusion :)

Yes, the stackexchange (implicit) model contributes to this. It assumes once a Q has been asked and answered, the issue is resolved. Due to the non-duplicates policy, any corrections or updates are supposed to be added to the same thread. But the original accepted answer will have a tick mark next to it and likely a high score. So naive users don't read further and the obsolete answers remain heeded.

Some sort of deprecation or salience decay needs to be added.

You can edit the accepted answer!

I don't like to mix voices - that's inorganic when the changes are more than minor and can lead to parts of the 'answer' being at odds with itself.

Except for typos, syntax..etc, I don't edit someone else's answer; I leave a comment and let the original respondent edit.

Indeed. I use libraries such as MoviePy* that wrap ffmpeg and allow you to implement effects on each frame.

* https://zulko.github.io/moviepy/index.html

Seems like everyone has a notebook of ffmpeg commands: https://hhsprings.bitbucket.io/docs/programming/examples/ffm...

Yes

And the worse part is everything is turned into command line arguments

It would be easier if you could specify it in something more human readable like (sigh) yaml

someone need to make a GPT-3 to ffmpeg commands converter

I wrote a small Python front-end for ffmpeg just so I can do some of my most common video encoding tasks done without Google.