On Fri, Dec 8, 2023 at 9:39 AM Martin Storsjö <mar...@martin.st> wrote:
> I guess this seems reasonable to me, so LGTM. > > The version check would be more relevant if we would be dlopening the > OpenH264 library (which pretty much is what one has to do in order to take > advantage of the patent offer from Cisco), but the libavcodec wrapper > doesn't dlopen this library (and doing the dlopen dance for ffmpeg is kind > of pointless, there's more of a point to it if individual apps want to > integrate OpenH264 directly), so this should indeed be fine. > Thanks! As for dlopening, I think instead of version checks, it would make sense to try to dlsym() all of the actual required symbols, and error out in init if anything is missing. That should make it all super flexible and resilient to e.g. struct size changes that would normally be an ABI change. In Fedora, we are planning on changing things up a bit and starting to build packages that link with openh264 against the "noopenh264" stub implementation and replacing it at runtime with the actual openh264 library downloaded directly from Cisco. Flathub flatpak runtimes already use that approach and it seems to work well there. This should hopefully let us take advantage of the Cisco patent grant and fit well in the build system architecture that we have. https://gitlab.com/freedesktop-sdk/noopenh264 -- Kalev _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
