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

[Martin Storsjö]

On Fri, 8 Dec 2023, Kalev Lember wrote:

> On Fri, Dec 8, 2023 at 8:12 PM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel at 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 some minimum version above which
>> runtime version checks are not needed.
>>
>
> I don't have a very good answer here, sorry. It was more of a general
> observation that upstream is trying to keep the soname updated whenever
> there is an ABI change.
>
> However, if I had to pick a version, I did some digging and maybe version
> 1.3.0 because before that there was just an unversioned libopenh264.so, and
> 1.3.0 added an actual versioned libopenh264.so.0, which has been updated
> since then whenever there have been ABI changes.
>
> Do you guys want me to add a minimum 1.3.0 check?

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).

> Martin mentioned earlier that he once envisioned something like passing
> -openh264_lib /path/to/my/libopenh264.so to ffmpeg and that must have been
> before the versioned soname was introduced.

Not necessarily; my point was that if we would have allowed pointing at a 
specific file, we need to check that it matches the expected ABI version. 
As we don't have an ABI version number in the headers (and there was no 
effort to maintain an ABI at the time), checking the full version number 
was my approximation of it.

// Martin