[FFmpeg-devel] [PATCH] lavc/libopenh264: Drop openh264 runtime version checks

[Martin Storsjö]

Hi,

On Fri, 8 Dec 2023, Kalev Lember wrote:

> This should no longer be an issue with newer openh264 releases and we
> can drop the runtime version check and rely on upstream doing the right
> thing and bump the library soname if the ABI changes, similar to how
> other libraries are consumed in ffmpeg.
>
> Almost all major distributions now include openh264 and this means there
> are more eyes on ABI changes and issues are discovered and reported
> quickly. See e.g. https://github.com/cisco/openh264/issues/3564 where an
> ABI issue was quickly discovered and fixed.
>
> Relaxing the check allows downstream distributions to build ffmpeg
> against e.g. openh264 2.3.1 and ship an update to ABI-compatible
> openh264 2.4.0, without needing to coordinate a lock step update between
> ffmpeg and openh264 (which can be difficult if openh264 is distributed
> by Cisco and ffmpeg comes from the distro, such as is the case for
> Fedora).
>
> Signed-off-by: Kalev Lember <klember at redhat.com>
> ---
> libavcodec/libopenh264.c    | 15 ---------------
> libavcodec/libopenh264.h    |  2 --
> libavcodec/libopenh264dec.c |  4 ----
> libavcodec/libopenh264enc.c |  4 ----
> 4 files changed, 25 deletions(-)

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.

// Martin