[Bug]: ffmpeg and other shared libraries in the snap

[soumyaDghosh]

What happened?

PR #220 changes the OBS build process from using Wimpy's portable build to leveraging the official OBS PPA. It also adds the Kobuka Team PPA for Intel drivers. However, I am concerned about whether these additions are effectively utilized by the prebuilt OBS binaries. For example, the included ffmpeg shared libraries from the content snap likely won't be used since OBS already pulls ffmpeg 6 from the Ubuntu archives. Additionally, since the Snap package uses the gnome extension and the mesa-2404 content snap, the content snap might be left unused.

Would it be possible to consider suggesting the use of the Kobuka Team PPA to the mesa-2404 snap and also using the PPA contents when rebuilding OBS Studio from source (mainly the api keys for different streaming services)? This approach would make it easier to keep libraries up to date and to rebuild from source when needed, streamlining the process of shipping plugins as snap components.

What should have happened?

NA

Output of snap info $snap_name

NA

Output of snap connections $snap_name

NA

Output of snap version

NA

Relevant log output

Teminal output of app

[soumyaDghosh]

To further explain the issue.

1. This snap adds the ffmpeg-2404 runtime snap, which is a shared library of ffmpeg with various new & improved codec support and better nvidia support. It's being maintained by us here. Now, as the new build pulls a prebuilt obs binary from the OBS Project PPA, it also automatically pulls in the ffmpeg libraries from the Ubuntu archive. The Ubuntu archive contains ffmpeg 6 and those are the libraries which are linked to by the OBS binaries. So, I think the ffmpeg libraries from the snap are left unused and would be preferable to use them.
2. This snap also uses the gnome extension. Gnome extension automatically adds the gpu-2404 interface in the manifest. But, this snap also pulls in intel and other gpu related libraries like (libva) from the Kobuka Team PPA, which seems to contain more newer libraries and the dependencies are seems to be linking to those libraries. Thus the libraries mesa-2404 is again left unused.

These require two different fixes.

1. To use ffmpeg from the content snap, the only solution I've found is to rebuild OBS from scratch. We can do this using the same build code as the PPA, so we're as close as possible to the PPA. As the ffmpeg in the archive is ABI & API incompatible with the ffmpeg that the content snap contains. Also, I think this would streamline the build of various OBS plugins, as they might require ffmpeg in the build time and runtime. I think this will also help us ensure that we will be able to make sure that all the libraries are properly compatible.
2. For the graphics content snap, the gpu-2404 interface, will it be possible to suggest the mesa-2404 snap to also use the same PPA for those libraries? Are there any compatibility reasons why we don't want to use the latest drivers everywhere?

[frenchwr]

Hey @soumyaDghosh !

Thanks a lot for raising these issues.

To use ffmpeg from the content snap, the only solution I've found is to rebuild OBS from scratch. We can do this using the same build code as the PPA, so we're as close as possible to the PPA. As the ffmpeg in the archive is ABI & API incompatible with the ffmpeg that the content snap contains. Also, I think this would streamline the build of various OBS plugins, as they might require ffmpeg in the build time and runtime. I think this will also help us ensure that we will be able to make sure that all the libraries are properly compatible.

One of the main reasons we switched to the PPA is that the OBS development team has stated they do not want to provide support (or even chime in on discussions) for the snap unless it's based on the PPA they are publishing to.

Probably the simplest solution is to remove the ffmpeg-2404 plug and just rely on the version from the archive, as I don't think there are any special features or support we're missing in the older (v6) version compared to the v7 version in ffmpeg-2404.

For the graphics content snap, the gpu-2404 interface, will it be possible to suggest the mesa-2404 snap to also use the same PPA for those libraries? Are there any compatibility reasons why we don't want to use the latest drivers everywhere?

The PPA provides newer versions of what is already in the archive, but it should be viewed as a sort of edge channel for the packages. For the case of OBS we've performed testing against the PPA (and this is one of the reason we're soliciting more testing/validation from the community) so can be reasonable confident that these newer versions work. However, given that a large number of snap packages that rely on gpu-2404 and mesa-2404, it's probably too risky to add packages from the PPA to these snaps.

Note that this PPA is relatively new (~6-8 months) and we also use it as a staging/validation area for candidate package versions that we want included in the archive. The validation and review processes are slow since the project is relatively new, so the delta between package versions in the archive vs. the PPA is somewhat large, but as we refine the validation and review processes we expect this delta to get smaller.

[soumyaDghosh]

Thanks a lot for the reply @frenchwr

One of the main reasons we switched to the PPA is that the OBS development team has stated they do not want to provide support (or even chime in on discussions) for the snap unless it's based on the PPA they are publishing to.

This thing definitely came up during a discussion between me, wimpy and popey from last year during the summit. I think and believe that if we are able to deliver a properly maintained snap, with the best possible performance on any platform (atleast on any Ubuntu release), then I am sure they'll at least understand our point of view.

If we build OBS from source, the only downside I can think of is if we can legally reuse the API keys they use to build OBS in the PPA, which we can easily acquire from the PPA itself.

I think the current solution has its downsides too. For example, snap environment will be a bit different from regular environments, so, any patch needed or required, we will not be able to apply that. We will not be able to control the source, so, if there is any ABI & API incompatibility (an example can be how due to mismatched packages from an archive update, there were seg faults happening with webkitgtk library). Also, we'll have to be extra sure about anything that we ship.

Probably the simplest solution is to remove the ffmpeg-2404 plug and just rely on the version from the archive, as I don't think there are any special features or support we're missing in the older (v6) version compared to the v7 version in ffmpeg-2404.

At the current situation, I agree that it'd be the simplest solution, but I'd still suggest to not take this route. As ffmpeg v7 has a lot of known improvements over ffmpeg v6, including multithreading in the main cli tool, Dolby Vision encoding support, and support for newer encoders, new vulkan shaders etc. The content snap has its own advantage too, we build it with support for many possible encoders, a much better nvidia support and all the libraries built from their latest stable release. This I believe really makes it a better candidate than the ffmpeg in the archive.

I think a solution can be to have a separate track for our unofficial build, and thus we can prove the stability of the snap and agreeing with the OBS team's idea too.

The PPA provides newer versions of what is already in the archive, but it should be viewed as a sort of edge channel for the packages. For the case of OBS we've performed testing against the PPA (and this is one of the reason we're soliciting more testing/validation from the community) so can be reasonable confident that these newer versions work. However, given that a large number of snap packages that rely on gpu-2404 and mesa-2404, it's probably too risky to add packages from the PPA to these snaps.

Note that this PPA is relatively new (~6-8 months) and we also use it as a staging/validation area for candidate package versions that we want included in the archive. The validation and review processes are slow since the project is relatively new, so the delta between package versions in the archive vs. the PPA is somewhat large, but as we refine the validation and review processes we expect this delta to get smaller.

I can understand that and believe in that case, obs will also not be a good snap as a testing ground for the PPA. So, I think the best solution here will be to create a track or a channel with these newer libraries in the gpu-2404 interface. Thus, we can test the libraries and drivers without risking anything.

[lucyllewy]

I'd like to get a meeting together to discuss this.