 Here is Luca, and he will be talking about Rust-AV, so please give him a round of applause. Okay, welcome. Well, let's start with me, who I am. I contribute to quite a bit of different open source project. Gentoo, Vidalan, Libvv, Rust directly, Vpx, Xuxx4. So my experience is mostly on everything that goes from fixing random software that ends up broken because of Gentoo. Since we build everything from source, if the source break with that compiler, we have to fix it. I have quite an experience with multimedia, both on fixing bugs, getting stuff built, designing APIs. I started to get my hand dirty directly with the Rust compiler, and today I'm going to talk to you about multimedia in Rust, as in writing a multimedia framework in pure Rust. Why to do that? I guess you all know already that Rust is thought as a quite safe language that is still for system programming, and it's supposed to be quite fast and quite good for writing credit code, multimedia's fill of it, and I say give you some guarantees that what you're writing is not going to explode just because you happen to fit it to the wrong pointer. What's the idea? Why not go in the other way so replacing just some piece of an existing framework with Rust? Well, Rust is also good to writing better APIs because the way Rust works makes you easier to describe concepts. So why not start writing a good API, write possibly good code and leverage the whole language, and actually try that what is currently touted about Rust is actually real and working for multimedia. So the main idea is that I want to make a framework that is easy to use, possibly fast and trustworthy. So possibly less bugs, less CVS, less bad situation because you play your movie and something bad happens. Easy to use. Do we have other frameworks that are easy to use? We have a problem with multimedia. Multimedia is a loss of easy to grasp concept with many, many, many different quirks and details that you have to work around. So usually the framework, if it's easy, is quite opinionated, makes decisions for you and you cannot undo them easily. On the other hand, if the framework lets you do everything that you could want, then you have to face the complexity. And the idea is, since Rust gives us this concept of zero cost abstraction, I can layer my abstraction so I can match your need regarding simplicity and, well, power to do whatever you want. Fast. Sebastian already said that you can write idiomatic Rust that result in code that executes fast enough or actually, in my experience, even faster than you would expect. Trustworthy. I guess everybody here already here and experienced the fact that the compiler prevents you to make lots of mistakes that are quite common if you're writing C or even Java. It would be good, but it is an experiment so far. I can tell you that so far Rust is great, but it's not perfect. And during this presentation I will show you, or I will tell you what I would like to have during this year that is currently not available. Also, since I don't like to reinvent completely the wheel, I'm leveraging other libraries that is part of the Rust ecosystem. Even in the case, multimedia needs can be different from the needs of other software. So even regarding libraries, we have some interaction. Some patches getting written. Sometimes I have to adapt to what the library wants to do. Currently, in this version, we are using a bit of num that I guess you know quite well. Who doesn't know num? Okay, enough people. Probably you don't know that there is the cookie-captor that is from the same person that wrote num and does exactly the opposite. Instead of chewing bites and give you structure, chew structure and give you bites. So what I did so far? The idea for the toolkit of framework is that I'd like to have it modular. So I want that all the code that is written for Rust-a-v can be reused as much as possible. As said already, I'm trying to use a layered approach. So if you don't care about details, you can write your player in few lines of code. If you do care about details, you can dig down as deep as possible, within reason. How I'm doing that? Modular. Rust as the concept of crate that works quite well to do that. Every single component, every single codec, every single format lives in a standalone crate. Then if you want to not care about details, we have crates that just re-export collection of different formats, collection of different codec. If you want capabilities, instead of directly using the codec, you can use a context that sort of embeds the codec and gives you some layer of abstraction to simplify your life. For the format, you can fit the format just with bites, but usually you want to use AO. You have a context that take an AO object, take the format that is supposed to be able to parse it, and then from there you can just get packets out of it. With reusable, I want to make sure that people like who is implementing G-streamer do not have to undo my choices about what should be done so they can just wiring directly in the specific codec format that should be helpful. What we have so far? The idea is that we have some essential crates that give us the basic data types that are used for multimedia. I want to represent a row frame. A row frame can contain video pixel or audio samples. If we are talking about encoded data, we have packets. That's the basics. That's the only part that currently everything else in Rust-avid depends on. When you are writing codecs, you usually want to read bit by bit having to deal with codebook, variable length codes and so on. We have another sort of base mostly used just for the codecs that is a bit stream reader and writer. Then we got the core functionality. So far, Rust-avid provides you a mean to the MOOCs, the code and encode. I say if you don't care about details, we have an upper layer. We have a player crate that just give you the base component just to have the playback. I give it a read object, I get back my frames that I can just fit to SDL and I have my player encoder, same idea. I got frames and I'm getting encoded data. Meta craze the concept of just making an ensemble so you don't have to think, okay, I want to have the... Matroska, Vorbis, you have just a jumble. You don't care, you have everything. We also have some test programs and transcoding tool and a player tool that is pretty much used to validate everything that is up there. Where are we so far? So far, what is done for the possibly first release is the API just to do that. So as I say, encoding, decoding, maxing, the maxing, we have already some codecs. We have non-native codes, codecs that are just wrapping known libraries from C to Rust is quite easy. I'm working on a native codecs, so completely pure Rust. So I'm experiencing phase fear first, how is it going, that kind of level of detail using just Rust. As a format, we have Matroska and the programs available are just those two. In the future, we will have more API surface so you can do more stuff with this toolkit. We will have more native code. We probably expose more reference codecs and we will have more formats. For the next version, we will still even discussing about hardware acceleration. So this is more or less the roadmap and is mostly related on my time and how mature Rust is for this purpose. What do I mean? Rust currently, in my experience, is a great language to write this kind of software because the compiler really helps you. You don't have that many problems in getting performance even if you're writing high-level, idiomatic code. It's quite easy to write bindings to C. So you don't have even problem in getting something that you can compare. What is missing and what we would like to have? Simdi. Simdi is pretty much a need when you're writing multimedia because you need code that is really fast. It's coming soon. It's coming quite soon and we have already two interesting ways in likely to use it. We have faster that is a crate that lets you use high-level iterators and it generates Simdi out of it. Quite good because you write it once and you sort out for free something that is faster. STD Simdi will be part of STD and will get you all the power of the intrinsics that you currently have from Clang and GCC. Another need is a location that is aligned to something large. Why? Simdi works much better or works at all with aligned buffers and hardware serration just need the buffer aligned to their specific needs that could be as large as a page. Something else that would be nice to have is not that compulsory but it's really nice to have and it's coming soon, constant generics. Currently you can write generic code in Rust but cannot be generic over a constant and in multimedia you have many situations in which you have some small details that are just constant and embedded this information in types is cumbersome and ugly. In line assembly some people likes it, some people doesn't. It's coming soon, it's sort of interesting since we edit from start but it's not really stable and since the language wants to be as stable as possible you cannot leverage the LLVM syntax that is completely in flux and you cannot even leverage the syntax that is currently shared between GCC and Clang because again you don't have any kind of warranties beside the fact that if the Clang slash GCC changed the syntax you will have lots of angry users that have perfectly working code that stops working but it's not exactly a great warranty. So what is going on is that we have a new RFC, a new syntax being discussed and possibly we will get that within this year and this is the good part the bad part is that for multimedia you would like to have lookup tables you want to generate a lot of them and Rust doesn't really work for this kind of purpose. Arrays in Rust are okay but they are not good as vector they are sort of second class citizen so you cannot collect real slides you cannot do a number of idiomatic use a number of idiomatic features on arrays it's going to change mainly because of the const generics but novities really working on that part and this is pretty much the remaining bit that we would need for having a perfect language for multimedia that's a we have five minutes left and if you have questions please I thought that the questions were part of the five minutes okay it is open source we have a GitHub organization everybody is welcome to contribute code I already have somebody that kindly offered a verb is the coder so now besides what we have we also have a verb is the coder that was sort of a surprise and was quite neat so I got a validation from a different person that the API works for the purpose let's say usual rules you can fork what you like to contribute and issue a request and I will be quite delighted to have more contribution problems with the various systems is that the CMD programming requires to rewrite everything for every architecture does CMD in Rust offer something that is a bit more generic? okay the question is when you write CMD you write CMD usually for specific architecture and you repeat the exercise for every architecture what Rust provide that help us in this regard say currently there is a crate that is called Fuster that is leveraging the fact that the Rust compiler itself can be made aware of CMD types and you can write idiomatic code so you can write iterators instead of doing loops and automatically up to a point and the Fuster crate tries to abstract more let you do some CMD that is generic enough so it's going to work on X86 doesn't matter which is your specific target and ARM possibly soon PowerPC but not yet Rust is as portable as LLVM provides that means that you can write Rust code and it's going to work pretty much on ARM, MIPS, X86, PowerPC, RISC-5 and some other platform that are a little stranger yes the output is not a concern your question is what about the output well the output is not exactly a concern for the toolkit usually what you have as output nowadays is some kind of open GL Vulkan open CV surface that you feel somehow but usually that part is a different problem it is more related to the GPU and graphics programming that multimedia once you got your buffer you want to convert it to something that you can put on the screen and usually that means that you just move to a different field open GL Vulkan and then that's another issue for the audio it's the same you have many different APIs to just directly output yes usually what you do right now is trying to if possible have the hardware do most of the work that means that your multimedia framework is supposed to be good with the formats then once you get the data usually you end up formatting it so it can be fit to the hardware pipeline you know probably NVIDIA, AMD, Intel, they all provide a open source friendly SDK to leverage that so that part is part of the roadmap 0.3 it's going to get there but first I wanted to prove that you can use Rust to write software decoders the hardware acceleration is part of the equation and will be implemented and obviously Rust is going to help you because then you don't have many problem in dealing with the hardware buffers that's usually an issue since the hardware buffer has to be properly reference counted and sometimes your API and SDK API and reality could not perfectly match other question if I wanted to get started to contribute do you have a place where you have a easy wins when you start getting involved? I have a, okay your question is if you want to contribute do you have an easy task to get your well fit wet yes we have few right now the code base is quite lean so we don't have many real issue or many tasks but we have a couple some are sort of easy if you have experience in writing bindings since that's one of the easiest part you write binding to a C library that is a reference implementation and you prepare the wrapper so you can expose it from RustCV that is the kind of easy task that currently we have I just wondered how much this is possible with SafeRust and how much help do you have to drop down to on SafeRust? currently we don't have any fit, your question is how much of it is on SafeRust and how much of it is SafeRust currently is almost everything SafeRust besides when you try to read bits because then you have some data type and you want to convert it to another data type and that operation is inherently unsafe you're welcome