What's new in GStreamer land
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Dröge, Sebastian (slomo)
Müller, Tim
This talk will give an overview over the last 2 years of the GStreamer projectand gives an outlook into the future. It is targeted at both applicationdevelopers and anyone interested in multimedia on the Linux desktop andelsewhere. GStreamer is a highly versatile plugin-based multimedia framework that catersto a whole range of multimedia needs, whether desktop applications, streamingservers or multimedia middleware; embedded systems, desktops, or server farms.It is also cross-platform and works on Linux, *BSD, Solaris, macOS, Windows,iOS and Android. Since the last GStreamer status updated at FOSDEM in 2014, there were 4 newmajor releases of GStreamer, packed with lots of new features and otherimprovements for everybody, making the life of application developers,GStreamer plugin developers and also end-users easier and hopefully better. Join us to find out more and why you should care!
 Okay, good morning everybody. I introduce you. 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. First of all, first we planned to do this talk together with a friend of mine who is 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 yeah, these elements, they could be something like a file source, something that is reading from the file. It could be something like, well, 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 FFMPEC 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. 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 are showed before. And all these elements are something that are provided as plugins. It's not something that is part of GSMAR core, it's something that is some kind of extension, some kind of plugin that can be loaded at runtime. And 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 LGPL, 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. GSMAR 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. Well, GSMAR 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, like probably quite a few people don't, you can also use any other kind of language. And now 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 GSMAR. Also, lots of plugins are included. So the releases that we do, they contain something like 250 plugins. 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 better is included release that we're doing. So what GSMAR is not, there's some misconceptions about that every now and then. It's not a media player or a play-back 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 are 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 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 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. And 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, OpenHU64, Libde264 and that kind of libraries. Then before we had to talk about TTML, that's also something we support, including, well, 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 multi-channel, at least up to eight 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, GCMO 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. On top of that there are elements that are doing audio mixing, video mixing or composition. The important part is we supported that before, but not really for the live use cases. 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, some maxers were changed like that. We have an MXF maxer that is handling that now and also an FIV maxer. It is quite a while since it was implemented. Nowadays, 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 will be in the long term, but we have support for rendering via Vulkan, at least on Wayland and X11. For Wayland, we also have generic support, generic raw rendering support via the Wayland APIs. Even more important, we now have Help Alarby for OpenGL integration, which is currently not API stable yet, but will be really soon now. It is supporting OpenGL 3, Corporify and GLS 2 and 3. Currently, we are working on all those platforms. Basically, everywhere where G-Summa runs, you have some kind of GL, you can also use the GL library. It is coming with video sync with some simple elements that allow you to do filters via shaders. It is doing scaling, color space conversion via shaders. For application development, what is very nice is that we also have a few plugins that allow you integration into UI toolkits, like GTK, GTQML, core animation. 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. Now 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 is an extension that allows you to use G-Summa 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 do not 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 is working quite efficiently. Right now, we are supporting all these APIs listed here, so 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 do not know, 30 times speed, and it is 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 is 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 do 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 Quarento and Open WebRTC. Quarento 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. 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 is working quite well. We know of a few people implementing AS67 with DSTMA for example. I think later there is also a talk about that. Another thing that happened mostly interesting for application developers is high level and convenience APIs. There is 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, which will be more, but just the playback part will be really small. It is basically something like what you know from other platforms like Apple's AV player, Android's media player. There is also an example application for that, using GTK, QML, that is 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 DSTMA is still difficult. 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 will switch to that soon. It is Maison. Before we were using AutoTools, everybody knows AutoTools is a huge pain. Maison really does everything we need from AutoTools. It is making everything much simpler. The build is much, much faster. Only it is not so important, but on Windows it is really tens of times faster. We can finally build Visual Studio Binary, which is also quite important for Windows users. Similar, we improved our documentation a lot. There is a new documentation that is some kind of tutorial style and you can find it here. 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. There is always something to do. 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. 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 on how to implement things in a performant way. I think that will come sooner or later. What would also 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. With that, I'm done for now. Thanks. Do you have any questions? You mentioned hardware acceleration. 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. There is a commercial plug-in for that. Ideally we would have a free plug-in for that. There is no reason why it couldn't exist. It just needs someone to write it. Someone who knows Windows well to do that. Nobody knows Windows well. Not here. Talk to me later. I have a question. Is it a replacement for auto tools or make? It's a replacement for auto tools or make. It's a replacement for auto tools or auto make. It's replacing the configs step and creation of the build files. It has backends for Ninja and Vizel Studio and Xcode. The default back-end is Ninja, which is basically like make. Thank you.
 Okay, good morning everybody.  I introduce you.  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.  First of all, first we planned to do this talk together with a friend of mine who is 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 yeah, these elements, they could be something like a file source,  something that is reading from the file.  It could be something like, well, 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 FFMPEC 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.  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 are showed before.  And all these elements are something that are provided as plugins.  It's not something that is part of GSMAR core, it's something that is some kind of extension, some kind of plugin that can be loaded at runtime.  And 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 LGPL, 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.  GSMAR 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.  Well, GSMAR 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, like probably quite a few people don't, you can also use any other kind of language.  And now 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 GSMAR.  Also, lots of plugins are included.  So the releases that we do, they contain something like 250 plugins.  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 better is included release that we're doing.  So what GSMAR is not, there's some misconceptions about that every now and then.  It's not a media player or a play-back 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 are 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 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 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.  And 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, OpenHU64, Libde264 and that kind of libraries.  Then before we had to talk about TTML, that's also something we support, including, well, 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 multi-channel, at least up to eight 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, GCMO 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.  On top of that there are elements that are doing audio mixing, video mixing or composition.  The important part is we supported that before, but not really for the live use cases.  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, some maxers were changed like that.  We have an MXF maxer that is handling that now and also an FIV maxer.  It is quite a while since it was implemented. Nowadays, 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 will be in the long term, but we have support for rendering via Vulkan, at least on Wayland and X11.  For Wayland, we also have generic support, generic raw rendering support via the Wayland APIs.  Even more important, we now have Help Alarby for OpenGL integration, which is currently not API stable yet,  but will be really soon now.  It is supporting OpenGL 3, Corporify and GLS 2 and 3.  Currently, we are working on all those platforms.  Basically, everywhere where G-Summa runs, you have some kind of GL, you can also use the GL library.  It is coming with video sync with some simple elements that allow you to do filters via shaders.  It is doing scaling, color space conversion via shaders.  For application development, what is very nice is that we also have a few plugins that allow you integration into UI toolkits,  like GTK, GTQML, core animation.  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.  Now 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 is an extension that allows you to use G-Summa 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 do not 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 is working quite efficiently.  Right now, we are supporting all these APIs listed here, so 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 do not know, 30 times speed,  and it is 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 is 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 do 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 Quarento and Open WebRTC.  Quarento 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.  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 is working quite well.  We know of a few people implementing AS67 with DSTMA for example.  I think later there is also a talk about that.  Another thing that happened mostly interesting for application developers is high level and convenience APIs.  There is 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,  which will be more, but just the playback part will be really small.  It is basically something like what you know from other platforms like Apple's AV player,  Android's media player.  There is also an example application for that, using GTK, QML, that is 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 DSTMA is still difficult.  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 will switch to that soon.  It is Maison.  Before we were using AutoTools, everybody knows AutoTools is a huge pain.  Maison really does everything we need from AutoTools. It is making everything much simpler.  The build is much, much faster. Only it is not so important, but on Windows it is really tens of times faster.  We can finally build Visual Studio Binary, which is also quite important for Windows users.  Similar, we improved our documentation a lot.  There is a new documentation that is some kind of tutorial style and you can find it here.  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. There is always something to do.  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.  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 on how to implement things in a performant way.  I think that will come sooner or later.  What would also 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.  With that, I'm done for now. Thanks. Do you have any questions?  You mentioned hardware acceleration. 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.  There is a commercial plug-in for that. Ideally we would have a free plug-in for that.  There is no reason why it couldn't exist. It just needs someone to write it.  Someone who knows Windows well to do that.  Nobody knows Windows well.  Not here.  Talk to me later.  I have a question.  Is it a replacement for auto tools or make?  It's a replacement for auto tools or make.  It's a replacement for auto tools or auto make.  It's replacing the configs step and creation of the build files.  It has backends for Ninja and Vizel Studio and Xcode.  The default back-end is Ninja, which is basically like make.  Thank you.
What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_0_131.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_132_527.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_528_1451.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_1452_1691.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_1692_2039.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_2040_3959.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_3960_6707.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_6708_8411.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_8412_11735.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_11736_12335.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_12336_12455.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_12456_13199.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_13200_14363.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_14364_22379.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_22380_23399.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_23400_28151.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_28152_28979.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_28980_29411.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_29412_29495.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_29496_29795.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_29796_32387.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_32388_32567.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_32568_32627.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_32628_32819.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_32820_33743.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_33744_34379.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_34380_34427.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_34428_34475.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_34476_34523.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_34524_34571.png What_s_new_in_GStreamer_land_The_last_2_years_and_the_future_34572_34696.png