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

Martin Storsjö martin at martin.st
Fri Dec 8 14:17:09 EET 2023


On Fri, 8 Dec 2023, Kalev Lember wrote:

> 
> On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö <martin at martin.st> 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
>       > 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.
>
>       How would that help, if e.g. the SEncParamExt struct in
>       svc_encode_init
>       would change layout/size - which part would notice that change?
> 
> 
> Ah, hm, I didn't think this through apparently :) This would indeed still be
> an issue.
> 
> I guess maybe dlopening the soname version that matches the headers (e.g.
> libopenh264.so.7) would work then? With the expectation that upstream bumps
> soname whenever the struct layout/size changes.

Yeah I guess that would work, it's all up to who has the responsibility 
for keeping it in sync. At some point, I envisioned that one could run it 
with e.g. -openh264_lib /path/to/my/libopenh264.so, and in such a 
scenario, we definitely would need some sort of reassurance that we're 
using the right ABI.

But anyway, good that we agree how this works. And this wasn't relevant 
for our current way of linking it here anyway, so the patch still is ok 
(and can be pushed later if nobody else has further opinions on it).

// Martin


More information about the ffmpeg-devel mailing list