Currently gstreamer based multimedia applications like WebKitGTK are unable to decode or encode av1 media without media-plugins/gst-plugins-aom. It would be great if it could be pulled in via the meta package. aom is already used by libavif, vlc and libheif (in ffmpeg's case it's named libaom not sure why since it also pulls media-libs/libaom just like the aom use flag should probably be renamed?). This could be done in the 1.24x version bump.
So I looked around and #575228, #425308, #677490 suggest that the meta package is mainly for decoding purposes and yet there is ffmpeg and x264 in here but no av1 (via aom), h264 (via openh264) and h265 (via gst-plugins-libde265) decoding. The ebuild's currently a mess. The decoding purpose is fine IMO since I imagine thats what the majority of people will use gstreamer for e.g this is what WebKitGTK does and packages using it as a webview. The ebuild should either be repurposed like indicated in bugs.gentoo.org/425308#c1 or x264 be removed (ffmpeg is fine I think? it provides loads of codec support) and aom, openh264 and libde265 be added for decoding. Thoughts?
Created attachment 915381 [details] gst-plugins-meta-1.22.12.ebuild Heres the ebuild I'm using currently
(In reply to wxviolation from comment #2) > Created attachment 915381 [details] > gst-plugins-meta-1.22.12.ebuild > > Heres the ebuild I'm using currently The fact you've had it working with 1.22 means it's not blocked on 1.24.
Also, bug 575228 is already in See Also.
FWIW the ebuild works with the 1.24 version pull request on github, I am using that right now with my own local repository
Sure, I just mean it doesn't depend on the bump, and if anything, I'd prefer to not make it harder to do by bundling in other changes.
Created attachment 915382 [details] media-plugins/gst-plugins-meta-1.22.12.ebuild Forgot to add libde265
