 Okay, good morning everybody. So our next speaker is Sebastian Dröger. He will introduce us to what's new in the Gistrima land since last time we talked. Yeah, exactly. So today I will tell all of you a bit about what happened in Gistrima in the last two years. But first of all, a few words about me. Well, first of all, first we planned to do this talk together with a friend of mine who's sitting back there, but it doesn't make sense for 25 minutes, so I'm just alone here. But yeah, myself, I'm Sebastian Dröger. I'm working on Gistrima since 2006 now, almost more than 10 years. And currently I'm working for Centicular, which is a consultancy providing services around Gistrima and related free software. So today, as I said, I will tell all of you what happened in the last two years because last time we were here for talking about Gistrima, it was 2014 I think. So a lot of stuff has happened in the meantime. But first of all, what is Gistrima? A very, very short introduction. If you want to have details, you can find it on the website. Most of you probably have a rough idea what it is, so really just very short. So Gistrima is a multimedia framework. It's pipeline-based. You have some kind of data flow graph. And most of you probably have some kind of idea what pipeline-based multimedia processing means, but basically you have little components that you somehow put together and the media is somehow flowing from one point to another. The interesting part about Gistrima in this context is that the pipeline graph is not static. It's dynamically reconfigurable at runtime. You can basically build anything you want and can change it to anything else on the fly while data is flowing. And what we have at the lowest level is something called Element. It's the smallest reusable components that we have. And what they basically do is one single thing. They do that very well and they can somehow be combined to bigger things similar to what you have in the shell or also what you have with Lego. You have lots of little building blocks and you can build something great out of it. And these elements, they could be something like a file source, something that is reading from the file. It could be something like, in this case, a Fiora decoder, something that is taking Fiora video and decoding it to something. Anything you can imagine. The goals for Gistrima are that multimedia is difficult. We saw it in the talk before. People have many, many misconceptions. Don't really understand how this kind of stuff works. And that's even true for all of us software developers in the end. And our goal is to make it really, really easy to build more complex multimedia applications. And for that what we provide is a very generic, simple interface that is hiding all the details you don't really want to know or need to know most of the time while at the same time allow you to really dig into it and if you need to tune every single knob that you might want to tune. And as I said before, Gistrima is a framework, so it's not an application or anything. And as a framework we want to make it really, really easy to integrate in other kinds of software in both directions. So for example, other frameworks like Qt or WebKit, they can and are using Gistrima for their multimedia things to some degree at least. And on the other side we also want to make it easy to integrate things like FFmpeg to have access to all kinds of codecs or other software, OpenCV, whatever you can think of. The other thing is a framework would be quite useless if our API would change all the time. So we try and we succeed with that also to have a stable API. Currently we have the 1.0 release series which started in 2012. Since then not a single API change. Everything you are building back then still works nowadays and I think that's a good thing to have. So what do we have? At the very core we have a very abstract core framework which is completely media agnostic. It doesn't know anything about audio or video. It's very abstract but from an application point of view, you use it with the knowledge that actual audio and video is passing there and what you do from the application point of view is use this abstract API to build some kind of processing graph and all the actual functionality is in these elements I showed before and all these elements are something that are provided as plugins. It's not something that is part of GCMAR core, it's something that is some kind of extension, some kind of plugin that can be loaded at runtime. With this design we have a very good split of concerns. Everything is only known in the part of the system where it has to be known and it's working quite well like that. And as an application you build on top of this generic API and build this kind of data processing graph. From a community point of view we are a community driven free software project. It's not one big company behind that and every year we have something like 200, 300 different contributors working for all kinds of companies or just hobbyist students. It's released under the LGPR so also we have the possibility that proprietary software can be built upon it and quite a few companies are also doing that. And thanks to that there's also quite a huge commercial ecosystem around that. GCMAR is also a cross-platform. It runs on basically every kind of system where you have a C compiler and some kind of rating system that provides you memory management and that kind of stuff. So right now the main things that we support is Linux, all kinds of embedded Linux systems, Windows, all the VSDs, Mac OS, iOS, Android, basically everything you care about for multimedia handling. GCMAR is written in C which is not ideal. It's a very low-level language. Usually if you want to build applications you don't really want to go that low. And the API that we provide is based on the object. So you all know C doesn't have object orientation. For that we used the object which is adding it to C. And also thanks to that it's very easy to create bindings for other languages. So if you don't like C, probably quite a few people don't, you can also use any other kind of language. We have bindings for languages like Python, C++, C-sharp, Java, JavaScript for various implementations for Rust, for Go. So whatever language you want to use you can build your multimedia application on top of GCMAR. Also lots of plugins are included. So the releases that we do, they contain something like 250 plugins. And that's also including things like a plugin for FFMPEG for all the codecs, plugins for basically everything you would like to do. So it's some kind of batteries included released that we're doing. So what we must not, there's some misconceptions about that every now and then. It's not a media player or playback library. It's also not a codec or protocol library. It's not a transcoding tool, not a streaming server or anything like that. But it can be used to build all these things and that's also what people are doing. And many of you are probably using it in some kind of device that you have on your laptop or whatever. Maybe you don't even know about that. So let's go to the changes. Last time we were here was 2014 and since then there were lots of major, new major releases. So there was the 1.4, 1.6, 1.8, 1.10, 1.12 release very soon. And what we're trying to do is something like every six months new major release with lots of new features, lots of improvements. We're not very good with keeping that six months cycle as you can see, but somewhat. And yeah, on the next slides I will just give some highlights of the most interesting, most important things that happened in those releases. So one thing that was added, many people needed that actually is some kind of device probing API. Say you have an application, want to use a camera. You want to know what kind of cameras are there. And for that we have a very simple API now that gives you information about all the cameras that are there, all the capabilities that these cameras have. And you can just tell it, give me an element for this specific camera in some kind of configuration and then you can use it. You don't have to know about video for Linux or any other API. It's all abstracted away from you. The same thing can also be used for things like audio inputs, outputs for CD, DVD, Blu-ray drives and that kind of stuff. Everything that is somehow a device. Then of course, codec support was extended a lot in the last years. So now we have H265 VP9 support. It's more or less normal nowadays, but two years ago we didn't have that. And with that comes also support in all kinds of supporting libraries, container format support, support for these codecs in RTP and also lots of plugins that are wrapping codec libraries for FFNPEG, OpenH264, LPD264 and that kind of libraries. Then before we had a short talk about TTML, that's also something we support, including for presentation at least, including all kinds of formatting and styling. This is right now experimental, but we'll be in the next release. And another nice thing that happened is there were many improvements to Opus, to the free audio codec, like we now have proper support for our multi-channel, at least up to 80 channels with support for our packet loss concealment, if you use it for some kind of real-time communication and that kind of stuff. Also another major thing that happened is before, last time we were here, GCML was still using LibAV. Nowadays we are using FFNPEG again for most of the codecs and reasons for that is mostly. Back then FFNPEG didn't really have stable releases. There was something in SVN at some point, but not releases nowadays. It's all done properly again and most distros also switched to FFNPEG. Chrome is using it, so what's the point of using something nobody's using? Then we also wrapped a few new libraries like OpenH264, Fraunhofer, AAC, SDK, those kinds of things. Another big thing that happened is we now have proper support for live mixing of streams and live maxing that comes together with a base class that is handling most of that and on top of that there are elements that are doing audio mixing, or composition and the important part is we supported that before, but not really for the live use cases and for the live use cases is the main point that was a problem before is that we couldn't provide guaranteed latency. Consider the case you are mixing together two video streams and someone is plugging the cable of one of the cameras. What would have happened back then is that everything stops until you plug in the camera again, which you usually don't want. With the new stuff we have, it will just continue. You have the ability to just show some kind of technical problem for the camera that is not anymore there. Similarly, also some maxers were changed like that, so we have an MXF maxer that is handling that now and also an FIV maxer. It's quite a while since it was implemented, so nowadays also a few professional broadcasting products are using that and it seems to work. Then what happened is that we added support for a few new video rendering APIs. Of course, Vulkan is the great big new thing. Not sure how useful it's going to be in the long term, but we have support for rendering via Vulkan, at least on Vailent and X11. For Vailent we also have generic support, generic raw rendering support via the Vailent APIs. Even more important, we now have help-a-larby for OpenGL integration, which is currently not API stable yet, but will be really soon now. We are supporting OpenGL 3, Corporify and GLS 2 and 3, and currently working on all those platforms. Everywhere where G-SUMAR runs and you have some kind of GL, you can also use the GL library. It's coming with video sync with some simple elements that allow you to do filters via shaders. It's doing scaling, color space conversion via shaders. For application development, what is very nice is we also have now a few plugins that allow you integration into UI toolkits, like GTK, QT, QML, core animation, and it makes it really easy for applications to integrate the video before you had to do all kinds of dances with raw video window handles and hope that somehow it works. You just get a widget or whatever is the terminology in the toolkit. The library also allows you to do that kind of integration, like if you are writing a game, you could use this API. For example, the Unity 3D game engine, there's an extension that allows you to use G-SUMAR for running videos inside there using this stuff. Then a big thing that happened is improved hardware codec support. We always had that to some degree, but nowadays it really works more or less out of the box. You don't have to do anything special in your applications anymore. If you have hardware codecs in your device, you can just use them and they can be used transparently, including stuff like zero-copy rendering or input for encoders, and it's working quite efficiently. Right now, we are supporting all these APIs listed here. Basically, all the major platforms are covered. Then what happened and seems to be quite big in the industry right now is some HTTP adaptive streaming. For that, we have support for Dash, HLS and smooth streaming now, including lots of advanced playback features like support for common encryption, for the DRM things. We have support for keyframe-only trick modes, which works for some HLS stream for basically all Dash streams. You can just play your Dash stream with, I don't know, 30 times speed, and it's just going to show the keyframes or just going to show a few keyframes so that you can still handle that with your internet connection and your processing power. This is all playback right now. For creation of streams, we have support for HLS. Dash will probably come soon. There are some patches to do that. It's just not integrated yet. Another big thing in yet another area is WebRTC right now. Everybody is talking about that. At this point, we have all the building blocks needed to WebRTC. We have support for RTP in all kinds of flavors. We have support for SRTP and DTLS. There are now a few software products using DSTMA for WebRTC. Best-known ones are probably Corento and Open WebRTC. Corento is basically some kind of streaming server thing that is also supporting WebRTC. Another thing that happened in this context is also that we now have good support for remote clock synchronization via RTP, which is kind of important for standards like AS67 or the SMPD2110 or VSFTR4. They are doing, in those cases, you somehow want to be able to really synchronize to whatever is sending you the data. We support that now via NTP and TTP, and it's working quite well. We know of a few people implementing a S67 with DSTMA, for example. I think later there's also a talk about that. Another thing that happened mostly interesting for application developers is high-level and convenience APIs. There's one API now for writing playback applications. You can basically write a good playback application in, I don't know, five, six lines of code. It will not do much. You have to do all the plumbing around that and the user interface, of course, which will be more, but just the playback part will be really small. It's basically something like what you know from other platforms like Apple's AV player, Android's media player. There's also an example application for that, using GTK, QML, that's one for iOS and Android. You can just look at that and hopefully be able to use it for your media playback needs. We are going to continue on that road also because people say GSTMA is still difficult, so we should make it easier for people to implement their common use cases. Then we also have a new build system, which is alternative right now, but hopefully we'll switch to that soon. It's Maison. Before we were using AutoTools, everybody knows AutoTools is a huge pain. Maison really does everything we need from AutoTools. It's making everything much simpler. The build is much, much faster. Only notice it's not so important, but on Windows it's really tens of times faster. We can finally build Visual Studio Binaries, which is also quite important for Windows users. Similar. We improved our documentation a lot. There's a new documentation that is some kind of tutorial style, and you can find it here. And some example Git repository, which has a few little example applications. These things I will skip for now. You can look at the slides on the website later. I don't have that much time anymore. What comes next? You all know, software is never finished. In the future, we would like to have easier integration into OpenCV, some kind of library that allows you to use arbitrary OpenCV code, build it into your GSMAR pipeline, make use of that. There is some start of that already, but in the future, there will be more. Another thing that will happen in the future is GST Transcoder, which is something that allows you to easily build transcoding pipelines. Ideally, it would also come with a little command line tool, similar like the FFMPEC command line tool that would allow you to do transcoding between any kind of format. And further away, ideally, we would at some point really support SDI over IP. I know people say nowadays that's impossible to much data. I think in the future, we will be able to do that. Computers are getting faster. People get better ideas to implement things in a performant way. I think that will come sooner or later. What also would be nice to have is some kind of showcase demo application for a player based on GSTRIMAR with a nice UI. Basically, something like VLC just using GSTRIMAR. We have all the building blocks for that. It basically only needs someone to do a nice UI. If you are interested in doing UI development, talk to me. That would be a really nice thing to do, I think. With that, I'm done for now. Thanks. Do you have any questions? One question, I think. You mentioned hardware acceleration or can't, but I didn't see any Windows-related stuff. On Windows, we don't support it yet. He was asking if we also support hardware codecs on Windows. Currently not. There is a commercial plug-in for that. But ideally, we would also have a free plug-in for that. There's no reason why it couldn't exist. It just needs someone to write it. And someone who knows Windows well to do that. Talk to me then later. One last question. That was quick. It's a replacement for... He was asking if Meson was a replacement for AutoTools or MAKE. It's a replacement for AutoTools, for Autocon for AutoMAKE, LibTool. Basically, it's replacing the configure step and creation of the not MAKE files, but of the build files. And currently it has backends for Ninja and Visual Studio and Xcode. And the default back-end is Ninja, which is basically like MAKE.