Why your FFmpeg version matters

ffmpeg -h muxer=whip on FFmpeg 7.1.1 returns Unknown format 'whip'. Not a warning, not a deprecated notice. FFmpeg 7.1.1 has never heard of WHIP as an output format, because the muxer that understands it didn't exist yet when 7.1.1 was built. It shipped in FFmpeg 8.0.

"FFmpeg" isn't one program with one fixed feature set. It's a project that cuts releases, and each release adds muxers, demuxers, filters and encoders that the previous one didn't have. A command that works on the FFmpeg installed on your machine can fail outright on someone else's, with nothing misconfigured. Their binary is a different version, or was compiled with different options.

Version is only half of it

Version explains WHIP. It doesn't explain everything. FFmpeg's ./configure step turns on and off entire families of functionality: --enable-libx264 for H.264 encoding, --enable-gpl to allow GPL-licensed components at all, --enable-nonfree for components whose licenses make the resulting binary non-redistributable. Two binaries built from the exact same FFmpeg source at the exact same commit can support different sets of encoders and muxers, because they were compiled with different flags. Version tells you what's possible to have. Build configuration tells you what a specific binary actually has.

Some things aren't a matter of configuration at all, because they were never written. FFmpeg has a WHIP muxer as of 8.0, for publishing a stream into a WebRTC session over HTTP. It has never had a WHEP demuxer, the matching piece for pulling a stream back out the same way, at any version, in any build. ffmpeg -h demuxer=whep fails the same way -h muxer=whip fails on 7.1.1, but for a different reason: no FFmpeg release includes a WHEP demuxer, so there's no version to upgrade to.

Asking the binary instead of the docs

The reliable way to know what a build supports is to ask it directly, because documentation drifts and a specific binary doesn't lie about itself.

ffmpeg -version          # version string and the full ./configure line
ffmpeg -buildconf        # the same configure flags, one per line
ffmpeg -encoders         # every encoder this binary has
ffmpeg -muxers           # every muxer
ffmpeg -h muxer=whip     # help for one muxer, or "Unknown format"
ffmpeg -h encoder=libx264  # the same check for one encoder

-h muxer=<name> and -h encoder=<name> are the most direct check, because they answer one question with no interpretation required: either the component's own help text prints, or FFmpeg tells you the name is unknown. -buildconf is the one to reach for when the question is broader, whether a whole category of feature was compiled in at all, since every --enable-* and --disable-* flag from the actual build is right there in the output.

Building a catalog that doesn't go stale

A course or a reference tool that teaches FFmpeg has the same problem at a larger scale: every encoder, muxer and filter the tool claims to know about. Writing that list by hand from documentation has the same failure mode as teaching WHIP on FFmpeg 7.1.1, a true statement about some version of FFmpeg, attached to a binary where it happens to be false.

BeemMeUp's answer is to generate its FFmpeg catalog by running the real binary rather than transcribing docs: spawning it enough times to ask each component for its own help text, and recording exactly what came back. Run against FFmpeg 6.1.1, that process turned up 555 filters, 226 encoders, and 189 muxers, with a written description recovered for 98.2% of them. Run it again against a different FFmpeg build and the numbers change, because the binary changed.

A generated catalog is still a snapshot of one binary. When the FFmpeg underneath changes, the catalog has to be generated again, the same way you'd rerun -h muxer=whip after an upgrade before trusting a WHIP command.