Snapcraft should have content sharing mechanism gstreamer media codecs

I noticed size decrement while building snaps few days ago since now snap apps can use system fonts.
I was wondering there may be something like this with media player codecs and back-ends. Since packaging codecs in every app make no sense. it increases size more by 70mb.
Same for flash player.

@popey @zyga-snapd @ogra @jdstrand @niemeyer do we have anything like this in snapcraft already ??

Fonts are data, gstreamer plugins are loadable object files that live in the same process as the snap application would. I don’t see any way of making sure that they would be binary compatible.

1 Like

How about allowing snap app to use gstreamer plugins from host.
I noticed locales also responsible for huge size of snaps. Shipping locale with each app is stupid using locale from host system makes sense. I don’t know how you guys can achieve that but one day in future this issue needed to be solved.

I’m starting work on a snap that will expose chromium extra codecs through the content interface for other snaps to use (typically browser snaps based on chromium such as opera, brave, vivaldi, …).

Binary incompatibility was raised as a potential issue, and one possible way of solving this is to expose several versions of the dynamic library (libffmpeg.so) in the content snap, so that consumers can pick the version that suits them. It does mean extra logic on the consumer part to go through the available libs and pick the right version (by e.g. extracting a version number out of the .so). I am not sure this approach would be suitable for GStreamer plugins. Does GStreamer have a mechanism to look up plugins in different locations and fall back gracefully if it fails to load them due to binary incompatibility?

Can anyone think of a more elegant solution to that class of problems?

For the same reason as I described above this is pretty much impossible. The ABI may be compatible today but won’t be tomorrow. Instead the goal to pursue should be to package gstreamer plugins as snaps and allow other snaps to use them via the content sharing interface.

We discussed this issue at the last sprint in Budapest. The plan is to ship locales-all in the next core snap (CC: @mvo - is this correct or am I remembering things wrong)

1 Like

This isn’t necessary. You can just expose multiple content slots with distinct values of the content attribute. Then each consumer defines a plug with the same attribute. The rest is automatic.

I snapped a nwjs (chromium webengine based toolkit) based app today which ships ffmpeg with it, but i noticed that the videos are not being played and the debug says demuxer do not recoznige the steame. Am sure that lib ffmpeg is responsible for playback of that video in nwjs, am not sure if ffmpeg is also looking for gstreamer backend. I will find and update this post soon.

Hi, any updatr on this ?? locales are still being packaged into snaps .

Not at present. I have some prototypes but I’m not ready to publish them for any production use. I’m currently working on bug-fixes for mount namespaces and that has much higher priority.

I personally want to see this fixed so you can expect something early august, even if I work on it over weekends.

2 Likes