obsproject/obs-deps

Bundled ffmpeg library files use real name instead of soname

aramg opened this issue · 4 comments

aramg commented

Operating System Info

macOS 11.6

Other OS

No response

OBS Studio Version

27.2.0

OBS Studio Version (Other)

No response

OBS Studio Log URL

N/A

OBS Studio Crash Log URL

No response

Expected Behavior

OBS.app ships with the more generic "soname" for ffmpeg dylib files rather than full name.

This was the case up until OBS 27.1.3, eg:

/Volumes/OBS-Studio 27.1.3/OBS.app/Contents/Frameworks/libavcodec.58.dylib # <---
...
/Volumes/OBS-Studio 27.1.3/OBS.app/Contents/Frameworks/libavutil.56.dylib # <---

Current Behavior

As of OBS 27.2 this has changed, which breaks external modules (plugins) linked against libavcodec

/Volumes/OBS-Studio 27.2.0/OBS.app/Contents/Frameworks/libavcodec.58.134.100.dylib # <---
...
/Volumes/OBS-Studio 27.2.0/OBS.app/Contents/Frameworks/libavutil.56.70.100.dylib # <---

Steps to Reproduce

Check the OBS.app bundle contents, under the Frameworks folder as shown above.

Anything else we should know?

While external modules can link with the full library ("libavcodec.58.134.100.dylib") or maybe somehow ship their own copies of ffmpeg, it's reasonable to assume a big component like this should be shared and has consistent naming.

The "soname" (libfoo.X.dylib) convention makes things very easy, with plugin updates only being required when a major ffmpeg upgrade occurs within OBS.

aramg commented

I've been digging though the code and seems some of the re-writes in this repo last summer changed the produced files.

users-MBP | tmp $ tar tvf macos-deps-x86_64-2021-03-25.tar | grep libavutil | grep dylib
lrwxr-xr-x  0 runner staff       0 25 Mar  2021 obsdeps/lib/libavutil.dylib -> libavutil.56.dylib
-rwxr-xr-x  0 runner staff  537320 25 Mar  2021 obsdeps/lib/libavutil.56.dylib


users-MBP | tmp $ tar tvf macos-deps-2021-08-17-universal.tar | grep libavutil | grep dylib
lrwxr-xr-x  0 runner staff        0 16 Aug  2021 lib/libavutil.dylib -> libavutil.56.31.100.dylib
lrwxr-xr-x  0 runner staff        0 16 Aug  2021 lib/libavutil.56.dylib -> libavutil.56.31.100.dylib
-rwxr-xr-x  0 runner staff   925048 16 Aug  2021 lib/libavutil.56.31.100.dylib

When I compile ffmpeg manually, I get the correct naming

users-MBP | build $ pwd
/tmp/ffmpeg/ffmpeg-4.4.1/build

users-MBP | build $ find . -name \*.dylib
./libavutil/libavutil.dylib
./libavutil/libavutil.56.dylib

Not yet sure where/why things are different for the releases here.

After some digging, seems this change occurred between the deps releases 2021-10-25 and 2021-10-27 - which apparently means it was introduced in #75. Maybe it was a previous change that didn't apply until the cache was refreshed? I'm unsure.

aramg commented

I cant reproduce it (on a MBP), may be its the github build environment ?
This large refactor looks to be the more likely candidate #60

Good find, though this was less an issue with obs-deps than an issue with OBS' build script only copying the actually linked files into the App Bundle, but not the symlinked variants.

We fixed this upstream (see linked PR).