Misleading undocumented use of env var FFMPEG_BIN

[j1elo]

Hi, thanks for maintaining this library, it helps a lot to bring FFmpeg where no system install is available!

A small "anti-feature" request, which might be seen as a bug, follows:

Use case

I wrote my code such that it will try to load an FFmpeg program if it was supplied by the user with the env var FFMPEG_BIN. The code checks in case the user made a mistake and provided a path that doesn't exist, or is not an executable file, then a fallback is obtained from "ffmpeg-static".

Imagine my surprise when "ffmpeg-static" points to the same path than the one provided by the user.

Then of course the mystery gets solved when checking the source code and this is found:

if (process.env.FFMPEG_BIN) {
  module.exports = process.env.FFMPEG_BIN
}

What's wrong

The bug report here that this is an unexpected behavior (and a totally undocumented one, too). "ffmpeg-static" has only one intended job and that is to bring a static build of Fmpeg; providing alternative builds or paths should be left for the application.

What's expected

"ffmpeg-static" promises to bring a working FFmpeg binary, and does it well. This is also what docs in README and NPM talk about, which is quite reasonable job to expect from this library. Hijacking other env vars to provide additional search paths is arguably out of scope for this lib, and has unexpected consequences for higher-level code that might have fallback mechanisms in place.

Thanks and have a good day.

[derhuerst]

Thanks for reporting, it helps knowing about cases where this logic didn't help.

However, there are specific cases where it makes sense not to let ffmpeg-static download an ffmpeg binary, such as environments where post-install hooks are disabled, or where the install phase needs to work offline.

I think the best way forward is to split ffmpeg-static into two parts: download-ffmpeg-binary, which downloads an ffmpeg binary appropriate for the current platform, and ffmpeg-static, which merely calls download-ffmpeg-binary after install.

This way, both use cases are supported.

[j1elo]

Thanks for acknowledging the issue; however there is something I'm not understanding, probably because I don't have in mind the same use cases you are contemplating.

I see ffmpeg-static as one possible source (among several) for the FFmpeg binary. As an application writer, to support "environments where post-install hooks are disabled, or where the install phase needs to work offline" I would just have to provide my own binary and make my application use it instead of using the one that is downloaded/provided by ffmpeg-static.

The way you are putting it, sounds like you see ffmpeg-static more as a universal provider, that should be the only one an application uses as source for the FFmpeg binary, and the application writer should configure ffmpeg-static in order to provide it with the actual binary, in those special cases where one cannot be downloaded. Is that it, from your point of view?

I would disagree with the second way of seeing it, because it suddenly changes the whole principle of this library, from a simple single-purpose "FFmpeg binary downloader" to "FFmpeg binary provider through different means" (which as mentioned, I believe that it makes more sense that the app itself handles the different ways to obtain it, because a 3rd-party library won't ever be able to cover all scenarios; for example my app gets the FFmpeg binary either from a custom HTTP repository, or if none is available from the path in a var named $FFMPEG_BIN, or from $PATH in case the package is installed in the system, or if all else fails, from ffmpeg-static. And right now I need to unset the $FFMPEG_BIN var before loading ffmpeg-static, to avoid them colliding.)

But of course all this is just my point of view! This is OSS, you're the author, and it's your library :-) so actually thanks a lot for writing it.

(But please, I'd request mentioning usage of $FFMPEG_BIN in the README, for future users)