tl;dr: The GStreamer 1.18 release ships with UWP support out of the box, with official GStreamer binary releases for it. Try out the 1.17.90 pre-release 1.18.0 release and let us know how it goes! There's also an example gstreamer app for UWP that showcases OpenGL support (via ANGLE), audio/video capture, hardware codecs, and WebRTC.
Short History Lesson
Last year at the GStreamer Conference in Lyon, I gave a talk (slides) about how “Firefox Reality” for the Microsoft HoloLens 2 mixed-reality headset is actually Servo, and it uses GStreamer for all media handling: WebAudio, HTML5 Video, and WebRTC.
I also spoke about the work we at Centricular did to port GStreamer to the HoloLens 2. The HoloLens 2 uses the new development target for Windows Store apps: the Universal Windows Platform. The majority of win32 APIs have been deprecated, and apps have to use the new Windows Runtime, which is a language-agnostic API written from the ground up.
So the majority of work went into making sure that Win32 code didn't use deprecated APIs (we used a bunch of them!), and making sure that we could build using the UWP toolchain. Most of that involved two components:
- GLib, a cross-platform low-level library / abstraction layer used by GNOME (almost all our win32 code is in here)
- Cerbero, the build aggregator used by GStreamer to build binaries for all platforms supported: Android, iOS, Linux, macOS, Windows (MSVC, MinGW, UWP)
The target was to port the core of GStreamer, and those plugins with external dependencies that were needed to do playback in
<audio>
and <video>
tags. This meant that the only external plugin dependency we needed was FFmpeg, for the gst-libav plugin. All this went well, and Firefox Reality successfully shipped with that work.Upstreaming and WebRTC
Building upon that work, for the past few months we've been working on adding support for the WebRTC plugin, and also upstreaming as much of the work as possible. This involved a bunch of pieces:
- Use only OpenSSL and not GnuTLS in Cerbero because OpenSSL supports targeting UWP. This also had the advantage of moving us from two SSL stacks to one.
- Port a bunch of external optional dependencies to Meson so that they could be built with Meson, which is the easiest way for a cross-platform project to support UWP. If your Meson project builds on Windows, it will build on UWP with minimal or no build changes.
- Rebase the GLib patches that I didn't find the time to upstream last year on top of 2.62, split into smaller pieces that will be easier to upstream, update for new Windows SDK changes, remove some of the hacks, and so on.
- Rework and rewrite the Cerbero patches I wrote last year that were in no shape to be upstreamed.
- Ensure that our OpenGL support continues to work using Servo's ANGLE UWP port
- Write a new plugin for audio capture called wasapi2, great work by Seungha Yang.
- Write a new plugin for video capture called mfvideosrc as part of the media foundation plugin which is new in GStreamer 1.18, also by Seungha.
- Write a new example UWP app to test all this work, also done by Seungha! 😄
- Run the app through the Windows App Certification Kit
And several miscellaneous tasks and bugfixes that we've lost count of.
Our highest priority this time around was making sure that everything can be upstreamed to GStreamer, and it was quite a success! Everything needed for WebRTC support on UWP has been merged, and you can use GStreamer in your UWP app by downloading the official GStreamer binaries starting with the 1.18 release.
On top of everything in the above list, thanks to Seungha, GStreamer on UWP now also supports:
Try it out!
The example gstreamer app I mentioned above showcases all this. Go check it out, and don't forget to read the README file!
Next Steps
The most important next step is to upstream as many of the GLib patches we worked on as possible, and then spend time porting a bunch of GLib APIs that we currently stub out when building for UWP.
Other than that, enabling gst-libav is also an interesting task since it will allow apps to use FFmpeg software codecs in their gstreamer UWP app. People should use the hardware accelerated d3d11 decoders and mediafoundation encoders for optimal power consumption and performance, but sometimes it's not possible because codec support is very device-dependent.
Parting Thoughts
I'd like to thank Mozilla for sponsoring the bulk of this work. We at Centricular greatly value partners that understand the importance of working with upstream projects, and it has been excellent working with the Servo team members, particularly Josh Matthews, Alan Jeffrey, and Manish Goregaokar.
In the second week of August, Mozilla restructured and the Servo team was one of the teams that was dissolved. I wish them all the best in their future endeavors, and I can't wait to see what they work on next. They're all brilliant people.
Thanks to the forward-looking and community-focused approach of the Servo team, I am confident that the project will figure things out to forge its own way forward, and for the same reason, I expect that GStreamer's UWP support will continue to grow.
Servo doesn't have a MSE implementation yet, AFAIK. It was on their roadmap though.
ReplyDelete@Phil I don't know if Servo supports all media source extensions, but they definitely support <audio> and <video> :)
ReplyDeletehttps://blog.servo.org/2019/07/09/media-update-h1-2019/
Your post mentions "Media Source Extensions", to me that implies this spec https://www.w3.org/TR/media-source/ which is about adaptive streaming :) And this specific spec is not supported in Servo currently.
ReplyDelete@phil You're right! I forgot that phrase was there in the beginning. Fixed now, thanks for pointing it out :)
ReplyDeleteNice work
ReplyDeleteGreat work. I'm running the UWP sample and the videotestsrc works nicely. When I change the pipeline to use playbin with a URI I receive an error that No URI handler implemented for http in gsturidecodebin. I also tried using souphttpsrc, but no luck there. Is playing back from a URI not yet supported?
ReplyDeleteThe HTTP URI handler is libsoup, as you've guessed. However, the soup element is currently not built for UWP since its dependencies are currently built with Autotools. No plugins that have dependencies that use Autotools are available for UWP at present.
ReplyDeleteSeungha has plans to write a new HTTP source element that uses native UWP APIs. That will likely use a new HTTP base class first so as to not duplicate everything done by souphttpsrc.
This is great news! Congratulations on the work! To broaden adoption and use, C# bindings and a NuGet package with compiled binaries would be awesome!
ReplyDelete