waldonnis
commented
9 months ago Looks like someone just enabled everything they could (e.g. the gopher protocol) regardless of whether or not it was enabled by default or even commonly useful, so it's mostly a "nothing to see here" type of thing. IMO, doing so for most people just leads to a larger (and potentially somewhat slower) binary with no real benefit. It's a useful thing to do when doing QA/validation builds since it can help figure out when little-used configuration options in complex projects conflict, no longer compile cleanly, or even function correctly. Outside of that, there's nothing really to gain. I'd say most builds (including my own, lol) already include a ton of features that never get used, but this is an order of magnitude beyond that. My opinion is that the existing upstream default and Zeranoe config sets are good starting points for a vast majority of uses, and people can always add/subtract features on their own as desired/needed.
As for what everything does, the ffmpeg documentation is actually quite good in most areas. The bsf options are bitstream filters for manipulating the actual media data streams (not at the container level) without re-encoding. A typical example is using the h264_metadata bsf to quickly fix a h.264 video that has the wrong aspect ratio embedded in its bitstream rather than having to re-encode (and further degrade) the video itself.
hydra3333
Goodness me.
https://ffmpeg.org/pipermail/ffmpeg-user/2023-October/056952.html is an ffmepg-user report about an issue with nvenc, and has a link https://github.com/aperim/docker-nvidia-cuda-ffmpeg/blob/7d7c1d85c79239210b4b5314c2fb2aaac1170d4e/ffmpeg/Dockerfile#L151 where the referenced line is shown below.
I have never seen so many
--enable-bsf=things and do not know what effect they have.So,
Cheers