Both ffmpeg(1) and openssl(1) share that they're meant, or used to be meant, as examples/demos of the underlying APIs. No one was actually supposed to run an actual CA with openssl(1), for example. Both also share that some things are vastly easier using the API than bending over backwards thrice at full moon using the CLI, but because using the API has more friction to it, people generally stick to the CLI (almost) no matter how hard that'll make things.
Oh, and just like you have to know a ton about how media containers, streams and codecs actually work to use the ffmpeg API, you likewise need to be a crypto expert to use the OpenSSL API. Almost the same is true for their CLIs as well, though.
I'm less familiar with ffmpeg, but the openssl(1) command wasn't originally designed to expose the API. It was intended to provide very rudimentary examples for using the API, and perhaps operated as a useful development tool for contributors, but that's it. There were plenty of APIs it never exposed, and plenty API changes it was never updated to accommodate. And IIRC there were some breakages along the way.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
The same is true of ffmepg. The api documentation even links to the source of the bins so you can read the example code. To pick on ffplay, I think it most clearly illustrates this - with the bare minimum rendering context to get video on the screen but clean code continously updated to reflect the api's best practices, and an invaluable resource when I was writing an embedded player for a game.
True, but you use the wrong FFMpeg codec, or transcode an audio track instead of copying it to the output, no one is left dangerously insecure. You just have a bloated MKV :-D
There are plenty of ffmpeg interfaces, though. The most prominent is Handbrake. Of course, I don't think any of them try to expose every single option. The goal for them is almost always to create an interface that works for the 99% and let the 1% deal with the CLI
An FFMPEG GUI in the style of this OpenSSL one would be great if you are familar with the options but don't use the tool enough to remember the exact commands. It'll also let me explore interesting parameters that I can look up in the manual later to see if they apply to my application. Maybe the GUI could even have buttons that will open the manual page to that specific option. With the CLI I'll likely only grab the specific options I need from the manual and not explore as much.
