[webkit-gtk] Question about Media Source Extension

Enrique Ocaña González eocanha at igalia.com
Wed Feb 28 01:45:32 PST 2018

El miércoles, 28 de febrero de 2018 8:20:12 (CET) Cédric Bellegarde escribió:

> I recently add a personnal build server for ArchLinux to get debug
> symbols packages for GNOME stack.
> enable-mediasource was True in Eolie, first test: 1080p is available in
> Youtube but WebKitGTK crashes.
> So, I decide to force enable-mediasource to False in Eolie for now
> instead of rebuilding WebKitGTK.
> And here my surprise, with -DENABLE_MEDIA_SOURCE=ON and
> enable-mediasource=False, 1080p is available in YouTube and WebKitGTK
> does not crash anymore.
> Why this behaviour?

MSE on WebKitGTK+ is a work-in-progress feature. While it works reasonably 
well for https://youtube.com/tv (note that this isn't the regular youtube.com 
website!) with MP4 using H.264 and mpeg audio codecs, it's still work in 
progress regarding the support of webm using vp9 and opus codecs. Also, the 
current work depends on GStreamer patches that are still on their way to get 
merged upstream, so things won't work well in unpatched vanilla distros. Your 
mileage may vary depending on the GStreamer multimedia codecs present on your 
system (eg: It looks like Fedora doesn't ship H.264 codecs and our webm 
implementation is still unstable).

When you "enable-mediasource=False", the browser stops advertising to the 
webpage that it supports MSE. Therefore, the webpage tries to use the regular 
non-MSE video player and a different codepath is exercised in WebKit.

> Why not enabling MEDIA_SOURCE in WebKitGTK if it works with
> enable-mediasource=False?

The build flag is disabled in order to avoid bloating the binary with MSE code 
(because of the MEDIA_SOURCE build flag) that in the end shouldn't (because 
it's still work in progress) and wouldn't (because of enable-
mediasource=False) be used by stable distros out there.

If you know what features your system supports and want to play with MSE at 
your own risk, enable the flags yourself.

Now about the specific crash you're having, we would appreciate a bug report 
in https://bugs.webkit.org with the "[MSE][GStreamer]" tags in the bug title. 
If you can provide a backtrace of the crash and GStreamer log and pipeline 
dumps, it would help us a lot to find the root cause.

To get GStreamer logs and pipeline dumps, define these environment variables 
in your shell before manually launching the browser:


Then collect all the *.dot files left in your /tmp directory.

Thank you.

Enrique Ocaña González

More information about the webkit-gtk mailing list