I know this isn't a small task but I'm opening a ticket just for the record. Here are the release notes: https://gstreamer.freedesktop.org/releases/1.16/
*** Bug 677492 has been marked as a duplicate of this bug. ***
Gstreamer-1.16.0 had 5 months to mature into: https://gstreamer.freedesktop.org/releases/1.16/#1.16.1 --- Highlighted bugfixes in 1.16.1 GStreamer-vaapi: fix green frames and decoding artefacts in some cases OpenGL: fix wayland event source burning CPU in certain circumstances Memory leak fixes and memory footprint improvements Performance improvements Stability and security fixes ... Related: a version bump for app-misc/tracker-2.2.2 to 2.3.1: tracker-miners-2.3.1 now can make use of gstreamer for parsing audio tags
The second 1.16 bug-fix release (1.16.2) was released on 03 December 2019. https://gstreamer.freedesktop.org/releases/1.16/#1.16.2
Is there a particular insurmountable difficulty with this?
@lanodan - the author of [guru]www-client/badwolf - seems to be the only one in the whole Gentoo community to work on gstreamer-1.16 But maybe he is trying for private purpose only, because he doesn't version bump the majority of gst-plugins - as you can see here: https://gitlab.com/lanodan/overlay/tree/master/media-plugins
Created attachment 611728 [details] new gstreamer-meson.eclass for gst-1.16+ Since nobody else seems to be working on this and the autotools build seems to be bit-rotting, I've ported gstreamer.eclass to meson. This seems to be working well for gstreamer-1.16.x, with the exception of media-libs/gst-plugins-base/bad having to have explicit calls to meson_src_compile and explicit disabling of plugins provided by media-plugin/gst-plugin-* ebuilds. All the media-plugins/gst-plugin-* ebuilds work perfectly with a version bump and "inherit gstreamer-meson".
Created attachment 611766 [details] new gstreamer-meson.eclass for gst-1.16+ (bugfix) Fixed a bug where the plugin install path included the filename.
Nice start, thanks! How do split plugins behave with this that need helper libraries from the same tarball? The splits that call "gstreamer_system_link" right now to handle it in the libtool world - gst-plugins-dvb, gst-plugins-cdparanoia, gst-plugins-libvisual, gst-plugins-opus, gst-plugins-smoothstreaming. gst-plugins-opencv is another interesting case.
It seems to be correctly linking with system libraries with meson builds, unless I've missed something: ldd /usr/lib64/gstreamer-1.0/libgstlibvisual.so ldd: warning: you do not have execution permission for `/usr/lib64/gstreamer-1.0/libgstlibvisual.so' linux-vdso.so.1 (0x00007ffff7fd3000) libgstpbutils-1.0.so.0 => /usr/lib64/libgstpbutils-1.0.so.0 (0x000000342e000000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x0000003fb1400000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x0000003fb1a00000) libvisual-0.4.so.0 => /usr/lib64/libvisual-0.4.so.0 (0x0000003192a00000) libgstreamer-1.0.so.0 => /usr/lib64/libgstreamer-1.0.so.0 (0x0000003fe1600000) libc.so.6 => /lib64/libc.so.6 (0x00000036d4a00000) libgstvideo-1.0.so.0 => /usr/lib64/libgstvideo-1.0.so.0 (0x000000342de00000) libgstaudio-1.0.so.0 => /usr/lib64/libgstaudio-1.0.so.0 (0x000000342e200000) libgsttag-1.0.so.0 => /usr/lib64/libgsttag-1.0.so.0 (0x000000342e400000) libgstbase-1.0.so.0 => /usr/lib64/libgstbase-1.0.so.0 (0x0000003fe1800000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00000036d9000000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036d4c00000) libffi.so.7 => /usr/lib64/libffi.so.7 (0x0000003103000000) libm.so.6 => /lib64/libm.so.6 (0x00000036d4e00000) libmvec.so.1 => /lib64/libmvec.so.1 (0x00000036d9400000) libdl.so.2 => /lib64/libdl.so.2 (0x00000036d5200000) libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x0000003fb1800000) libunwind.so.8 => /usr/lib64/libunwind.so.8 (0x0000003848e00000) libdw.so.1 => /usr/lib64/libdw.so.1 (0x0000003b94200000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x000000391e200000) librt.so.1 => /lib64/librt.so.1 (0x00000036d5c00000) /lib64/ld-linux-x86-64.so.2 (0x00007ffff7fd4000) libz.so.1 => /lib64/libz.so.1 (0x0000003919000000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00000033bd800000) libbz2.so.1.0 => /lib64/libbz2.so.1.0 (0x00000032df400000)
I've pretty much finished up the modular plugins, but I haven't yet converted media-libs/gstreamer, but I have a working version-bumped ebuild still using autotools. I've not yet done media-libs/gst-plugins-ugly/good but base/bad are done. I still need to test it's all working properly at run-time which is why I've not yet made anything public.
Can you share the build.log of one of these system_link ones, like gst-plugins-libvisual? You can FEATURES=keeptemp on command line (so it's only to this), to keep it after a successful emerge too. I suspect it's building it in the background still, but just not installing it. A build.log of gst-plugins-opencv could be useful too. This all just to push it along further before I can start testing and work on this on my own machine. Also, do you want to add your name to the AUTHORS list in the eclass?
ping
1.16 is mostly there, but as this bug contains meson work, retitling for that. gst-rtsp-server-1.16.2 needs investigation of test failures under network-sandbox; gst-transcoder and gstreamer-editing-services can probably go meson in the bump and fix a few open bugs together with the bump and maybe a few other things left.
In my overlay (::lanodanOverlay) I bumped gstreamer-1.18.0 with the gstreamer-meson.eclass given earlier and ran into some issues, and one that I couldn't fix easily so I want to make you aware of it. The parsing of the `meson_options.txt` file includes non-plugins into it's plugin listing, which really doesn't seems to work well for gst-plugins-{base,good,bad,ugly} packages which needs to include the ones without dependencies plus some extra features (for example gl and tools in gst-plugins-base). After looking at how other projects handled it (specially OpenBSD for this one) I think the eclass should more go towards disabling+enabling a ebuild-given list of plugins and otherwise doing nothing as the `meson_options.txt` file isn't that reusable outside of maybe doing a quite involved function if gstreamer confirms it as a stable format. (getting options between `# Feature options for plugins with external deps` and an empty line, same for `# Feature options for plugins with no external deps`)
Good evening, Gstreamer 1.18 would be very useful to me (as it stabilizes a lot of webRTC stuff. What is the current state of the meson transition and is this being actively worked on? Is there something I could do to help out? I did look into bumping my local ebuilds, since the lanodan overlay does not have all the plugins I usually use, but I would prefer to not duplicate effort of course. Thank you, Nico
https://gstreamer.freedesktop.org/news/ "GStreamer 1.18.2 stable bug fix release 2020-12-06 15:00 The GStreamer team is pleased to announce another bug fix release in the stable 1.18 release series of your favourite cross-platform multimedia framework! This release only contains bugfixes and it should be safe to update from 1.18.x. Highlighted bugfixes: Fix MPEG-TS timestamping regression when playing DVB streams compositor: fix artefacts in certain input scaling/conversion situations and make sure that the output format is actually supported, plus renegotiation fixes Fix sftp:// URI playback in decodebin/playbin via giosrc adaptivedemux/dashdemux/hlsdemux fixes rtsp-server fixes android media: fix crash when encoding AVC fix races in various unit tests lots of other bug fixes and memory leak fixes various stability, performance and reliability improvements g-i annotation fixes build fixes See the GStreamer 1.18.2 release notes for more details."
(In reply to Haelwenn Monnier from comment #14) > In my overlay (::lanodanOverlay) I bumped gstreamer-1.18.0 with the > gstreamer-meson.eclass given earlier and ran into some issues, and one that > I couldn't fix easily so I want to make you aware of it. > > The parsing of the `meson_options.txt` file includes non-plugins into it's > plugin listing, which really doesn't seems to work well for > gst-plugins-{base,good,bad,ugly} packages which needs to include the ones > without dependencies plus some extra features (for example gl and tools in > gst-plugins-base). > > After looking at how other projects handled it (specially OpenBSD for this > one) I think the eclass should more go towards disabling+enabling a > ebuild-given list of plugins and otherwise doing nothing as the > `meson_options.txt` file isn't that reusable outside of maybe doing a quite > involved function if gstreamer confirms it as a stable format. (getting > options between `# Feature options for plugins with external deps` and an > empty line, same for `# Feature options for plugins with no external deps`) Hello Haelwenn, could you try 18.2 and add all other gst-plugins to your overlay? btw, there is https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/85 if someone uses ffmpeg-9999 EGIT_OVERRIDE_COMMIT_FFMPEG="87f0c8280c7556b52b72b9379547eed77e9810d7"
There is no one to bump the latest version in the official repo ?
Highlighted bugfixes in 1.18.3 fix ogg playback regression for ogg files that also have ID3 or APE tags compositor: fix artefacts and invalid memory access when blending subsampled formats exported mini object ref/unref/copy functions for use in bindings such as gstreamer-sharp Add support for Apple silicon (M1) to cerbero package builder Ship RIST plugin in binary packages various stability, performance and reliability improvements memory leak fixes build fixes
