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
(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`) Are you interested in making a PR?
https://gstreamer.freedesktop.org/releases/1.18/#1.18.4 The fourth 1.18 bug-fix release (1.18.4) was released on 15 March 2021. This release only contains bugfixes and security fixes and it should be safe to update from 1.18.x. Highlighted bugfixes in 1.18.4 important security fixes for ID3 tag reading, matroska and realmedia parsing, and gst-libav audio decoding audiomixer, audioaggregator: input buffer handling fixes decodebin3: improve stream-selection message handling uridecodebin3: make "caps" property work wavenc: fix writing of INFO chunks in some cases v4l2: bt601 colorimetry, allow encoder resolution changes, fix decoder frame rate negotiation decklinkvideosink: fix auto format detection, and fixes for 29.97fps framerate output mpeg-2 video handling fixes when seeking avviddec: fix bufferpool negotiation and possible memory corruption when changing resolution various stability, performance and reliability improvements memory leak fixes build fixes: rpicamsrc, qt overlay example, d3d11videosink on UWP
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67eea7c9ed1b7c6f009d7dc1fd9bce6219fb4ae7 commit 67eea7c9ed1b7c6f009d7dc1fd9bce6219fb4ae7 Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me> AuthorDate: 2021-03-17 01:17:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-30 00:34:55 +0000 gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+ Gstreamer switched to meson in 1.16.0 and removed autotools support in 1.18.0, this eclass is an update of gstreamer.eclass. One significant change is that we lost the gstreamer_system_link function. Differences from version 1: - Move to EAPI-7, including moving deps from DEPEND to BDEPEND when appropriate - Port python script to perl, this allows to avoid having to add PYTHON_COMPAT into a python-unrelated eclass - Drop errorneous MULTILIB_USEDEP on virtual/pkgconfig - Fix running tests: defining multilib_src_test, media-libs/gstreamer[test] dep - Fix ebuild emesonargs being ignored - Remove legacy prune_libtool_files - virtualx wrapped for testing Differences from version 2: - Get list of plugins from meson_options.txt instead of hard-coding them, this adds GST_PLUGINS_NOAUTO for ones managed by the ebuild - Fix @AUTHOR order - Sort inherits - remove stray semicolon in test - Add virtx to tests - Remove gstreamer_environment_reset - Put GST_ORG_MODULE conditions into gstreamer_multilib_src_{compile,install} - QA warn when IUSE=orc is defined but the option is absent - Pass gst_debug/examples/nls/tests options only when declared - Use code similar to orc for introspection Closes: https://bugs.gentoo.org/690468 Signed-off-by: Haelwenn (lanodan) Monnier <contact@hacktivis.me> Signed-off-by: Sam James <sam@gentoo.org> eclass/gstreamer-meson.eclass | 367 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 367 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82965d45c4d1e6ed870b2ddc470ae49130b847cd commit 82965d45c4d1e6ed870b2ddc470ae49130b847cd Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-30 00:39:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-30 00:39:22 +0000 profiles: mask new GStreamer 1.18.x for testing Bug: https://bugs.gentoo.org/756298 Bug: https://bugs.gentoo.org/690468 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+)
see also bug 793032 media-libs/gstreamer-1.18.4 - circular dependencies on itself
Time to unmask gstreamer-1.18.4 now? There are a few CVEs against older gstreamer so getting 1.18 into unstable would be good.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=016c24d54f1a9631412f50859453ca921db994a2 commit 016c24d54f1a9631412f50859453ca921db994a2 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-27 05:16:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-07-27 05:16:06 +0000 profiles: unmask gsteamer 1.18.x I think we've had as much testing as a masked set of ebuilds can offer. Please report any issues if you hit them. Bug: https://bugs.gentoo.org/756298 Bug: https://bugs.gentoo.org/690468 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 86 --------------------------------------------------- 1 file changed, 86 deletions(-)