rsioned sonames and the intent has
been to bump the soname every time there's a new release with an ABI
change.
This patch drops the exact version check and instead adds a minimum
requirement on 1.3.0 to the configure script.
Signed-off-by: Kalev Lember
---
configure
On Fri, Dec 8, 2023 at 9:34 PM Martin Storsjö wrote:
> If that was when the soname version was introduced, that sounds reasonable
> - since then, there's at least an intent not to break it (even if mistakes
> always can happen).
>
Yep, 1.3.0 is when the soname version was introduced. Let's go wi
On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> As of what version of openh264 though is it safe to assume that ABI won't
> change without soname changes? Since years ago ABI changes without soname
> changes were present there's likely to be som
On Fri, Dec 8, 2023 at 4:59 PM James Almer wrote:
> Does the configure check ensure a new enough openh264 version is the
> minimum supported?
>
Hm, I'd say that configure minimum version check is mostly orthogonal to
the patch here.
This patch just removes a check that made it error out if the
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö wrote:
> On Fri, 8 Dec 2023, Kalev Lember wrote:
>
> > 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
>
On Fri, Dec 8, 2023 at 9:39 AM Martin Storsjö 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),
o 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
---
libavcodec/libopenh264.c
