On Mon, Feb 28, 2022 at 7:11 AM Vitaly Zaitsev via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 28/02/2022 03:45, Ian McInerney via devel wrote: > > How are these removed codecs handled in the library? > > ffmpeg is a monolithic library. > ffmpeg is a set of libraries. The libavcodec library is a monolithic library of compiled-in codec code. > > Can we link an upstream application against FFMPEG in Fedora now and have it gracefully fail when it tries to access a non-free codec that was removed, or does the removal of these codecs create a different API that upstream applications would have to code around? > > Applications need to use a special API to check if the codec is > available before attempting to use it. Otherwise, the application will > instantly crash. > It's not a special API, it's how you're supposed to use libavcodec. If you know you need a specific codec, you're supposed to use avcodec_find_decoder()/avcodec_find_encoder() and check if it's even available and before trying to initialize it, since you need the AVCodec struct for the codec to pass into the initializer function. If those functions return NULL, then you're supposed to gracefully fail. And if you want to know what codecs are provided by FFmpeg, you are supposed to use av_codec_iterate() to identify all the registered codecs in libavcodec that are functional and use that to populate what your application can work with. This lets you collect AVCodec structs for all the codecs built in FFmpeg for you to do something with it. Most applications will probably want to do the latter and do their own prioritization/handling of codec alternatives, because that lets applications expose hardware acceleration options. Applications not doing this properly are broken, because this is literally how you're supposed to use libavcodec. > > 2) Is there an easily accessible list of the enabled codecs we can point upstreams to when talking about this? > Most upstream developers don't want to deal with such situations: "Use > our binary/snap/flatpak. It works fine". Fortunately, that's where we can bring value to the ecosystem, as we're supposed to be capable enough to work with upstreams to fix broken code. And we're not the first to offer reduced functionality FFmpeg (both Debian and openSUSE do too, so we're in good company here). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
