FFmpeg Linux binaries: Include version in file name

[FreezyLemon]

I explain the rationale behind this change in #6154.

The included patch is necessary for local builds on some distros, and it will become necessary on more distros (and CI) as binutils gets updated (ver 2.41 breaks the ffmpeg build).

Note that the new NativeLibs version will cause the current logic to not find the new libraries. See the linked PR for the required logic change.

[bdach]

Ugh this stinks...

• Does ffmpeg not do backports at all?
• Is this patch going to work for binutils <2.41? The commit message doesn't say, but we build the images on github actions on ubuntu 20.04, and as per https://packages.ubuntu.com/search?keywords=binutils, it'll be 2.34 on there.

[FreezyLemon]

I know. I don't exactly like adding the responsibility of maintaining patchfiles to the project. But while the FFmpeg project does release patches to older versions, I couldn't find a 4.3 or even 4.X-compatible release with this fix.

And yes, this will work on older versions. The if (__builtin_constant_p(shift)) is used to check whether the old code can be used or not. To make sure, here's a build from the PR branch. (this is the line confirming the patch)

[FreezyLemon]

Another possible solution would be updating FFmpeg to 6.1. That would require some working around an unfixed bug in the framework code, but it would also avoid this kind of patching. (this issue tracks the path to a 5.X upgrade, and there hasn't been movement on FFmpeg's side for a while)

[FreezyLemon]

I've been playing around with using newer FFmpeg versions (>=5.0) in osu-framework and I noticed that FFmpeg.AutoGen had a major API change at some point.

Edit (disregard previous comment version): The API has changed, but it looks like there are still ways to get more control over library loading (it looks like it's even possible to delete the Linux workaround regarding RTLD_GLOBAL.

Note for later: It looks like it's possible to inject a custom FunctionResolver before Initialize is called, which actually seems nicer than the current GetOrLoadLibrary API.