 So, the next speaker is Sebastian Dröger and he will be talking about G-Streamer and Rust or how to be fast, safe and productive. Let's give him a welcome. Thank you. Good morning. So, today I'm going to talk about, as you said, G-Streamer and Rust. But first of all, I will tell you who I am. So, I'm a G-Streamer developer since about 2006, a long, long time now. Did you speak up a bit? Yeah, I can try. So, I'm a G-Streamer developer since 2006, which is quite a long time now. I probably touched every piece of code over the last years. I'm doing currently the releases. And I'm one of the founders of Centricular, a consultancy company providing services around G-Streamer and related software. And since about 2014, 2015, I started experimenting with Rust and also with how we can use Rust for G-Streamer. And that's exactly what we are going to talk about today. In the beginning, I will introduce what G-Streamer is. Many of you probably don't know that. Then talk about why Rust is a perfect fit for G-Streamer. I will explain a bit what you can do nowadays, what kind of projects using G-Streamer you can write in Rust and give some kind of outlook into the nearer and farer future. And in the very end, something personal, a bit my experience with Rust for doing all of this. And maybe this also gives others some idea how it is to work with Rust for these kind of projects. So, what is G-Streamer? I will only give a very, very high level, short introduction. If you want to see details, go to the website. There's lots of documentation that you can read, probably more than you want to read. But from a very, very high level, what G-Streamer is, it's a pipeline-based cross-platform multimedia framework. It's completely open source, free software. It's LGPL licensed. And there's no big company behind it. There are lots of bigger and smaller companies that are driving it, but most of the development is really something that is community-driven. It's quite widely used nowadays, also commercially. You can find many applications using it, TVs, drones, cameras, all kinds of things in the cloud. And it's running on Linux, Android, iOS, Mac OS, Windows, basically everywhere where you have some kind of C compiler and a standard C library. And it's not, at this point, used only for multimedia-related things. There are also people using it for other stuff, for example, the LIGO project that was detecting the gravitational waves. They're using G-Streamer for their data processing, and that doesn't have anything to do with multimedia at all anymore at that point. So I said G-Streamer is pipeline-based. What does that mean? So in G-Streamer, the basic components that you have are so-called elements. There's something that are processing media data or data in general, and you connect them to other so-called elements. And each of these elements in the end is doing one little task. So for example, what we have here is a very small pipeline that could be used for playing a video file. So you have one element that is just reading from a file. In this case, another element that is splitting the file into the audio and video parts. Then you have decoders for the audio and video, and in the end, it goes to the speakers or the screen. And this is a playback example, but you could also imagine that in the beginning, you have an element that is outputting the video from your camera, the audio from your microphone, could have an input that somehow reads over the network. You could send data out over the network. In the end, each of these elements, they could do anything they would like to do with the data. And you're taking all these little components, put them together, build bigger components out of them. And in the end, you have something like Lego. And you can build anything you would like to out of this, out of small, little components. And in this picture, it all looks quite static, but if you're actually writing code, doing these things, you could also change the topology of the pipeline graph at any point in time if you want to or if you need. And the general philosophy of GSTUMA is that we provide some kind of toolbox for higher level multimedia processing. It's not a finished solution for anything, but it's something that allows you to build solutions for anything you would like to do. And the basis is that we have some kind of flexible, extensible design that is based on simple ideas like what we saw before with the pipelines. It's a very generic API. The core GSTUMA API does not know anything about multimedia. It doesn't know anything about video or audio. That's something that is added in other components. And the main focus is on making it very easy to embed GSTUMA into other things in both directions to make it easy to embed GSTUMA in applications in other frameworks like Qt or WebKit. They are, for example, able to use GSTUMA for their multimedia needs, but also on the other side to make it easy to embed existing multimedia solutions into GSTUMA like FFMPEG, OpenCV. We're not redeveloping the world. We try to make use of whatever is out there already. And the target systems are everything from embedded systems upwards. And I said GSTUMA itself doesn't know anything about audio and video. Everything is added via plugins. And we have some kind of batteries included philosophy here. There are more than 250 plugins provided by GSTUMA if you just get the source code and build it. And there are also plugins that are reusing existing libraries like FFMPEG, OpenCV, and what I mentioned before. And in addition, plugins that allow you to use things like on your embedded device, the hardware codecs, or to use cameras and stuff like that. The other thing here is GSTUMA itself is completely written in C at this point, but nobody wants to write C. So we provide bindings for many other languages like Python, C Sharp, C++, Java, Go, D, and also Rust. I wouldn't be here otherwise. And yeah. So what GSTUMA is not. It's not a media player or playback library. It's not a codec or protocol library or not a transcoding tool or not a streaming server. Many people seem to think that. That's not what it is, but it's something that can be used for building all these things. It's something more generic. Well, and I say it's not a playback library, but nowadays we also include a little playback library to make your life a bit easier if you want to just implement a playback application. But it's not the main focus. So now let's talk a bit about Rust and why GSTUMA, why for GSTUMA Rust is something like the perfect fit. Well, first of all, we have the usual suspects. The memory safety, the fearless concurrency, and that we have something that is a modern language, not from the 70s anymore and something that has modern tooling. So if I say here memory safety in the past in GSTUMA, what we had is a couple of CVEs, many bugs related to memory safety, which might not be really a security related. Often they are, but it might also be just something that is annoying. If you watch a movie, for example, you don't want it to stop in the middle just because something is crashing. And most of these bugs would be something that would never have happened with Rust. Sure, there would be other bugs, but at least not those. The other thing is GSTUMA is heavily multithreaded. As an application developer, you don't really see that. But internally, everything is running in different threads. In a normal playback application, you easily have tens of threads. And it's very annoying to do this kind of development in C, and Rust can help here. The last part, I said everything is written in C. Nobody wants to write C. Even worse, in the case of GSTUMA, it's using GObject, lots of macros, very hard and difficult to learn. And using Rust could make everything much more convenient to use. And ideally, it would also allow us to find new developers interested in using or developing for GSTUMA because new developers, they want to have fancy tools. They don't want to learn this weird C and GObject stuff. They want something more done. And similarly, Rust is perfect in the context of GSTUMA because it does not have any runtime. It does not have any garbage collection. And the keyword zero cost abstractions because our goal is to run on everything from low-power embedded systems where you can't really afford a big runtime or a garbage collection up to anything that is huge. And in general, whenever you do something with multimedia, you want to be able, for example, to have control over where things are allocated, when are they allocated, when are they released again. And in the case of Rust, what also is quite useful and nice is that everything in the end is compiling down to very optimized code. You don't have something like an interpreted language behind that. It's all very fast and low level. And the last part that I personally like very much is that the ownership model for things like video frames or in general media data and all kinds of other processing related things inside GSTUMA, the ownership model of that maps perfectly to the ownership model of Rust. And so far from all the languages that we support, Rust is the only language where this mapping is really one to one. And in the end, if you know a bit the Arc type in Rust, it has something that allows you to do a runtime copy on write. So you can check with this reference content container thing if you are the only owner. If you are the only owner, you can write to the thing. If not, you might have to take a copy. And this is exactly how the basic types in GSTUMA are working. If you're the only owner, you're allowed to do whatever you want with it. Otherwise, you might have to take a copy instead. And the nice thing here with Rust is that we have that all in C. In C, you have to call all kinds of functions manually. In the case of Rust, the compiler is making sure that you don't forget to do these things. And to some degree, it's also all happening automatically. So then let's talk a bit about using GSTUMA from Rust, what is possible at this point. So the first thing that you might want to do and what the majority of people using GSTUMA are doing is writing applications. So at this point, we have almost complete bindings of the GSTUMA core and lots of the helper libraries available. It's all based on the infrastructure that GTK-RS is providing. It's also using the same code generator to generate most of the bindings code from the API metadata that GSTUMA is providing. And you can find the code here. In the end, providing some kind of safe and more or less idiomatic bindings to the GSTUMA API. If you know GSTUMA, you can probably easily learn the bindings because in the end, all the functions are called the same, all the objects are called the same. It's just a different language. But different to see you actually have something that is safer or, in this case, actually memory safe to use. Personally, I use the bindings now for everything I can, including test cases that I have to write, even for things when if there's some kind of bug reported in GSTUMA and I need to write a test case, I'm just writing the test case in Rust because it's much more convenient and faster. And because it's so close to the metal, the debugging of things that are actually inside GSTUMA from a Rust application that's just like as if you had written the test case in C. There's no heavy runtime or anything in between. And this stuff is all stable and ready to be used. You can also find it on crates.io. It works at least on Linux, Mac OS, and Windows. I didn't try it anywhere else. I would assume that it also works elsewhere. The other part that is very important for GSTUMA is that all the functionality is provided via plugins. And with the code that you can find here, you can find some kind of infrastructure that allows you to write plugins for GSTUMA in Rust, completely plain Rust. There are, for writing the plugins, you don't have to use any macros, any weird language constructs or anything. You just have to implement a few traits and implement the functions of the traits, and that's it. You also don't have to use any unsafe code unless you want to. And it's really convenient to write GSTUMA plugins like that. Of course, not everything is perfect. As I said, GSTUMA is based on the object, so there's some kind of object-oriented paradigm behind that. So in GSTUMA, there's lots of inheritance happening. Well, it's kind of emulated in this infrastructure with traits. It's not perfect, but it works. And it's not as ugly as I would have expected from before I started this. So what is currently available as plugins written in Rust is FLVDMAXR, which is the container format that was used by Flash in the past. There's an HTTP source that is using Hyper. There's some audio and video filters available. There's Amazon S3 source and sync available. In other repositories, there's a start of an animated GIF decoder, VA API sync, and all kinds of things that I probably don't even know about. It's not complete yet. It's in the very early stages. But nonetheless, it's useful already. And you can use it to write GSTUMA plugins to extend GSTUMA with new functionality. And all these plugins, while they are written in Rust, they will work in any GSTUMA application no matter what language this application is written in. So for the future, of course, the plan is to write more Rust, to write less C, especially new plugins. If possible, it would be good to have them written in Rust now. And some of the ideas that have is to write a plugin around Rust AV, which we will have a talk afterwards. There are various codec libraries already available in Rust. There's a Flux decoder for the Flux audio format. There's a Warbus decoder. There's the start of an AV1 video encoder available, some subtitle decoders. And it would be nice to wrap all these existing Rust libraries in a GSTUMA plugin. Because then, every user of GSTUMA would have something safer available, something that is not wrapped around decades old C libraries that nobody's maintaining anymore. So that would be very, very nice. The other thing would be to write more applications, more useful applications in Rust. Currently, there are not that many out there. People are just starting to use the bindings. And all of this is something where you can also get involved. If you're interested in this kind of stuff, just look at the existing code. Look at the existing examples. If you have any questions, ask me. All this is something that I really care about. And if you need help with that, just ask for help. What we are not going to do at this point is to rewrite GSTUMA and Rust. It's a lot of code. Nobody is going to have the time for rewriting all that. But in the long run, if we continue to see that Rust is really the perfect fit, core GSTUMA components could be rewritten in Rust. But that's all in the long run. First of all, applications and plugins, which is already a huge part. And also now would be the perfect time for you to start writing GSTUMA applications and plugins in Rust. All what you need is available already. And also people that didn't touch GSTUMA before, because this is all C, this is weird object stuff, you can also start now if you prefer Rust. So I don't have that much time left, so I will speed up a little bit. So my Rust experience so far, as said before, I'm using it for my own projects wherever possible. We at Centricula, we are also using it for various client projects by now. It's mostly little applications or plugins. And for myself, everything is much, much more enjoyable to write in Rust than in C. And also more enjoyable, or also from what I saw so far, Rust is much better suited for this kind of applications than any of the other languages I tried before. Some things that I noticed though is that people are generally very afraid of unsafe code. So what I notice is that you really shouldn't be that afraid of unsafe code, especially if your alternative would be to write something in C. In C, everything is unsafe. It's just not written on it. So if you really have to use unsafe code, don't be afraid to do that. Just do it, but wrap it in safe abstractions. And before you do something very complicated and never get your code finished, it's better to do something unsafe, especially if it's impossible to do otherwise, like for FFI or for optimizations. Or in some cases, if you implement your own data structures and have situations where you can't possibly convince the compiler that what you're doing there is safe, these cases exist and, well, use unsafe code if you have to. Another thing I notice is that people are looking at Rust projects and also, for example, the Jisuma bindings. And they have a million dependencies. And people coming from C are usually very afraid of that, because dependencies, that's something very difficult. Some have to compile all that. And other people's code, it might not work properly. You might not have a way to fix it. So far, my experience with Rust in this regard is quite the opposite. It's very easy to depend on something new. It's very easy to create your own fork of that if you have to fix something in the maintainers, not available. But what I noticed so far is that all the projects that I'm depending on, the maintainers are very active, very friendly, and helpful. Even if I don't want to fix anything in there, usually they are interested in fixing it. And otherwise, usually the code is kind of clean. You don't have the situation that you often see that you might use a library that was written 20 years ago in a code style that nobody would use nowadays anymore. And it's just impossible to read. But I guess that's just because the language is kind of new. And the other part is people shouldn't be really afraid of performance penalties for using higher level abstractions, especially things like iterators. They look like complete magic, but in the end, they compile down to very fast and optimized code. So in general, what I saw is don't worry so much about optimizing things. In the beginning, just write readable code. And you will notice that for most things, it is already as optimal as possible. And in general, as usual, when you optimize in the end and you measure first what you want to optimize. And what I saw so far is that most of the things that I was writing, even the inner processing loops of audio filters, for example, in the end, the assembly that the compiler is outputting, that's basically the same thing that a C compiler would have output, or sometimes even better. But not everything is perfect. The language is continuously improving, but there are still many open construction sites. And for myself, I have a little wish list of things that I would really like to see in stable Rust in the near future. And these would be all these little, little items. So everybody who ever wrote a little bit of Rust code probably saw that at some point, you have to fight with a bold checker. And the non-lexical lifetimes are going to improve this situation a lot. And it's inightly already, as far as I remember. So it should be stable at some point in the future, we will see. And other things are supported in stable Rust releases for SIMD instructions, which is currently not available. Something which would make many multimedia processing tasks much, much faster. It's something that is available in nightly. But ideally, I wouldn't like to use nightly. And another thing would be the ability to use custom allocators. Also something that is in nightly but not stable yet. All the other parts are something that is planned or that is not even planned yet. We will have to see. I think Luca, who is doing the next talk, will also talk about these items in more details. And with that, I'm done. Thanks. Any questions? They can't write a plug-in, upstream plug-in in Rust. So they can't contribute to the big, decent plug-in. Can you repeat the question? So the question was that he was talking to someone before who was writing GSTMA code and why they don't use Rust. And the answer was currently it's impossible to submit Rust GSTMA plug-ins to the existing GSTMA source code modules, which is true, unfortunately. But for that, at least my plan in the near future is that we will have a new plug-in module called, I don't know, GST plug-ins RS or something like that. There is already the start of that. And then you would just have another module that has all the Rust-based things. The main reason for that is that it can't be merged in the existing modules is that you have to convince people that this new language is something that is not going to make their life more difficult to have inside the main source code modules. And also, currently, the build system is all auto-tools or MISON-based. And building Rust code from there is not trivial. So something else that is separate and completely cargo-based would be much nicer. But the goal is to have something like an official Rust plug-in module where all the things are collected. Do you see some of the official plug-ins replaced by Rust versions in the future? Probably. So the question was, if I see existing GST-MAR plug-ins replaced by Rust versions of them, and yes, I think so. There's one that is the FLV demuxer that I mentioned earlier that's almost feature equivalent with the existing one that is written in C. And that could very well replace it. But in the end, we don't really have to replace it. It is enough if it exists as an additional demuxer. We could give it a higher priority so that whenever it is installed, it will be used. And otherwise, people who don't want to worry about how to compile this weird Rust code, they could just continue using the C version. But yeah. Same thing with the HTTP source that I mentioned before. The goal is to make it feature equivalent with the existing one written in C. And then it would also be a replacement.