Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

While GStreamer may not be something that generates a lot of headlines, it's a much loved and well-used bit of open source tech for handling media on Linux and many other systems and it just got a big funding boost from the Sovereign Tech Fund.

The announcement today from the STF mentions they're investing €203,000 in the project via Centricular, a company that specialises in working on open source software. 

What are they actually funding:

STF has commissioned work from Centricular to enhance the GStreamer multimedia framework by implementing critical components in Rust for improved security, maintainability, and sustainability. These include RTCP parsing, RTP session handling, real-time communication enhancements, and comprehensive support for audio and video formats, ensuring GStreamer's continued versatility and compatibility across a range of applications.

  1. Re-writing Foundational GStreamer Components in Rust
    • Real-Time Control Protocol (RTCP) Parsing and Real-Time Transport Protocol (RTP) Session Handling.
    • RTP/AVPF profile support.
  2. Real-Time Communication Enhancements
    • GStreamer RTP Jitterbuffer and Synchronization in Rust.
  3. Comprehensive Audio and Video Support
    • RTP Payloaders and Depayloaders in Rust for basic audio and video formats.
    • Including RTP support for H.264, H.265, VP8, VP9, and container/meta formats.
  4. Re-writing Real-Time Streaming Protocol (RTSP) Handling in Rust
    • GStreamer RTSP protocol client element in Rust, focusing on essential features, live playback, and RTSP 1.0 support

Check out the announcement for more info.

Who are the STF? From the website: "The Sovereign Tech Fund started in October 2022 and is financed by the German Federal Ministry for Economic Affairs and Climate Action. It is currently incubated at SPRIND GmbH". They also announced funding for GNOME late last year.

Article taken from GamingOnLinux.com.
Tags: Misc, Open Source
23 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
18 comments
Page: «2/2
  Go to:

F.Ultra Jan 18
View PC info
  • Supporter
Quoting: Arehandoro
Quoting: F.Ultra
Quoting: Purple Library GuyOne problem with working for the Sovereign Tech Fund is that insistence on paying in Sovereigns. Bags of coins in this day and age . . .

Considering that 1 Sovereign coin is worth aprox £400 I think they would be quite happy :)

Much better that kind of Sovereign than the Mass Effect's one

Yeah one of those is one too many!
Samsai Jan 18
Quoting: TheSHEEEPI once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.
 
    let string1 = String::from("Hello, world!");
    let string2 = String::from(&string1);

    println!("Here they are: {} {}", string1, string2);

You can write spaghetti in any language, Rust enforces a couple of pretty basic rules and most times when you are actually having to thread code through unwraps and whatnot you are dealing with nullability. And sure, languages like C and C++ will let you just bulldoze your way through that, you'll probably just catch a segfault at the end. :)
TheSHEEEP Jan 18
View PC info
  • Supporter Plus
Quoting: Samsai
Quoting: TheSHEEEPI once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.
 
    let string1 = String::from("Hello, world!");
    let string2 = String::from(&string1);

    println!("Here they are: {} {}", string1, string2);

You can write spaghetti in any language, Rust enforces a couple of pretty basic rules and most times when you are actually having to thread code through unwraps and whatnot you are dealing with nullability.
Maybe I should have mentioned it was in an Option in a Result and also containing a Mutex (or another permutation of that situation, I worked with in a REST project back then, don't fully remember), it wasn't just the simplest possible case.
Working with only base types is fairly rare in Rust, at least in my experience, which is doing more high-level code and not so much low-level calculations (low-level is generally the most "pure" and easiest to read).
Usually, you have at least one additional layer around things, and that can quickly spiral, too, where you might end up with Lists of Options of Results of different types from several different libraries you are using in tandem but need to tie together somehow...

Quoting: SamsaiAnd sure, languages like C and C++ will let you just bulldoze your way through that, you'll probably just catch a segfault at the end. :)
Unless I'm working on something that must never fail or is highly concurrent, I'd rather have a segfault that I can quickly fix than always writing more code than I feel I should need to.
Besides, I had plenty of runtime crashing with Rust, too. Sometimes in our own code, sometimes in libraries we used. It's not like Rust code automatically has no runtime errors.
The "error safety" of Rust is somewhat overrated. It's certainly safer than C, but far from "safe" safe.
So you still have to do all of the testing routines you'd do in any other language, not really saving you much time there.

Again, I'm not saying Rust is bad.
It's pretty good. It has very clear advantages and disadvantages. Depending on the project, I wish I was working with it instead of what it is I'm forced to use.
I'm just somewhat annoyed by (some) Rust fanboys seeing only the good bits and brushing the downsides off as "you just don't know what you're doing", is all.


Last edited by TheSHEEEP on 18 January 2024 at 2:25 pm UTC
mattaraxia Jan 18
Quoting: TheSHEEEP
Quoting: mattaraxiaHeh, I laughed surprisingly hard at that first part. I had really similar feelings while learning Rust, though after a while I wrote most of it off as just not-the-way-I'm-used-to-itis.
Of course you can get used to it and understand it.
Hell, you can get used to abominations like Objective-C. Which Rust thankfully isn't as bad as.

But there are just objectively much harder to parse languages (as in, read and understood even by uninitiated people). Due more complex structures in Rust code than you'd find in C-code.
C++ can get nightmarish to parse on its own, but more rarely so and in cases that can usually be auto'd away nowadays. And pure C code is just very simple to read as it "lacks" (I've grown to think it's a feature) all the bells and whistles of C++.

With Rust, you get a lot more special characters (&|*::<>?!..'+) throughout the entire code outside of calculations, more function calls per thing you want to do and once type specifiers and lifetimes come into play, all hope is lost to the uninitiated anyway ( what's this type do, why is there a ': "Box<Fn() + Send + 'static>" ).

It's not that it couldn't be understood, it's that it couldn't be understood quickly except by experts.
And if I have learned one thing in 15+ years of coding, it's that the most important attribute of code after "it works" is that it is easily readable to people new-ish to the project and/or the language.
Because code is hundreds to thousands of times more often read than written and lack of understanding leads to way more problems down the line.

The first ~four years of my professional life were largely coding Perl.

There's really not much more to add.
Samsai Jan 18
Quoting: TheSHEEEPMaybe I should have mentioned it was in an Option in a Result and also containing a Mutex (or another permutation of that situation, I worked with in a REST project back then, don't fully remember), it wasn't just the simplest possible case.
 
fn make_copy(value: Option<Result<Mutex<String>, String>>) -> Option<String> {
    if let Some(option) = value {
        if let Ok(mutex) = option {
            let string = mutex.lock().expect("Failed to acquire lock");

            return Some(string.clone());
        }
    }

    return None;
}

Even in this pretty pathological case where you are nesting containers like this, it isn't exactly complicated. And all of these steps are going to be necessary anyway, you might be allowed to read-write a mutex without locking it or attempt to read a null pointer in other languages but it almost certainly is not correct. And if you are developing something that can fail then you always have the choice to `.unwrap()` or `.expect()` your problems away. As a bonus when those fail, you'll get told exactly where it failed rather than needing to go through your the core dump from your segfault.

Quoting: TheSHEEEPThe "error safety" of Rust is somewhat overrated. It's certainly safer than C, but far from "safe" safe.
So you still have to do all of the testing routines you'd do in any other language, not really saving you much time there.
You have to always do testing, but it's debatable whether you have to "do all of the testing routines" compared to other languages. In some cases you can just API design some error scenarios to be wholly unrepresentable, whereas in Java or something any object can at any point be null and you either test for how your system deals with that or you let it die. Not to mention the nature of the beast by default limits the scope of entire categories of errors. Runtime errors exist, sure, but outright crashes are rare.

Quoting: TheSHEEEPAgain, I'm not saying Rust is bad.
It's pretty good. It has very clear advantages and disadvantages. Depending on the project, I wish I was working with it instead of what it is I'm forced to use.
I'm just somewhat annoyed by (some) Rust fanboys seeing only the good bits and brushing the downsides off as "you just don't know what you're doing", is all.
I get that Rust fans can be annoying, like all programming language fans, but I disagree strongly with the notion that Rust makes things necessarily "ridiculously complicated", especially with the kind of hyperbole you were throwing around. Yes, I understand that you can write some real spaghetti with Rust but as a language it's not unique in this regard. And after a bit of time with the language you'll start to see why Rust was giving you trouble with a particular approach and you'll learn approaches that work out better. And often those approaches involve less nested containers too.


Last edited by Samsai on 18 January 2024 at 7:12 pm UTC
To anyone dissatisfied with Rusts complexity I recommend looking into hare.
It's a really nice, minimal systems programming language. In some ways it's even simpler than C
Its tool-chain can already be found in repositories of some of the distros, also bootstrapping it is a breeze.
Despite sparse documentation it is not that hard to pick up and the source code of the standard library is very easy to read and understand
Whatever happened to Vala? That always struck me as kind of a neat concept, assuming it worked.
Nod Jan 22
Quoting: JörmungandrTo anyone dissatisfied with Rusts complexity I recommend looking into hare.

Can't mention hare without mentioning zig. Similar to hare with some compelling features of its own like comptime and powerful C/C++ compilation tools.

I would say zig has more traction than hare but Drew DeVault is great!
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.