Hi Alexander, I thought I'd chip in as a GStreamer maintainer and answer some of your questions :)
On Wed, 2026-05-13 at 12:19 +0200, Alexander Kanavin wrote: > > Unlike the other GStreamer submodules, the Rust plugins follow a > > separate release cycle and versioning scheme. These plugins are fully > > stable and required for a fully-featured GStreamer installation, as most > > new features and plugins are being written in Rust. > > > There should be evidence for this claim. If most new features are > written in rust, then the rust plugins should be in the core gstreamer > project, following its release cadence, and they aren't. gst-plugins-rs is a part of the core GStreamer project. Most new features and plugins are written in Rust, and in fact we are *rewriting* C plugins in Rust. These plugins aren't in the GStreamer monorepo and have their own release cadence for technical reasons that are documented in the project's README: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs#why-is-this-separate-from-the-gstreamer-monorepo-with-an-independent-release-schedule We have already rewritten the RTP/RTSP stack in Rust, including most of the RTP payloaders and depayloaders. As of the 1.29.1 development release (soon to be 1.30), these Rust implementations are preferred over the C implementations[1]. The WebRTC stack has also been rewritten in Rust[2], including the ICE library[3], and when this implementation is stable, it will replace the C version. 1) https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/work_items/755 2) https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/2955 3) https://docs.rs/librice/latest/librice/ The recommended fragmented MP4 muxer (used for HLS/DASH etc) is also the one written in Rust. Generally, all the plugins that are enabled- by-default in this V2 recipe posted by Tarun are important plugins that replace or accentuate functionality provided by C GStreamer plugins. This is also why at least _these_ plugins should be in oe-core. They are at-par with core functionality in gst-plugins-{base,good,bad}, and provide functionality that is not available elsewhere, e.g. RTP AV1 support or AC-4 audio parsing. > These all need to be split into their own recipes, or there should be > an explanation of why that isn't possible. It should be possible to split this recipe into N recipes one for each plugin, since these plugins are published individually to crates.io[4]. Then we could make a call for which ones should be in oe-core and which should be in meta-oe. That affects the maintenance burden, though. 4) for example: https://crates.io/crates/gst-plugin-webrtc Cheers, Nirbheek
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236971): https://lists.openembedded.org/g/openembedded-core/message/236971 Mute This Topic: https://lists.openembedded.org/mt/119293604/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
