[formerly_proven]

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.

[marcosdumay]

They are designed to expose the API, not as an example.

They expose a C API as a Bash API. There is just no reason not to use the higher level one.

[wahern]

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.

[TheCycoONE]

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.

https://ffmpeg.org/doxygen/trunk/ffplay_8c_source.html