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 <klem...@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
_______________________________________________
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".
