<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 24, 2016, at 10:00 AM, Enrique Ocaña González &lt;<a href="mailto:eocanha@igalia.com" class="">eocanha@igalia.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">These days I've been working on improving the layout test passrate of our new <br class="">Media Source Extensions GStreamer platform implementation <br class="">(MediaPlayerPrivateGStreamerMSE), but I'm having problems with the selection <br class="">of the right MediaPlayerPrivateInterface implementation for each use case.<br class=""><br class="">As I understand it (please correct me if I'm wrong), under normal <br class="">circumstances (no MEDIA_SOURCE enabled) MediaPlayer tries to find the best <br class="">media engine (ie: MediaPlayerPrivateInterface implementation) available to <br class="">play a content. It does so by asking each engine if they support (yes/no/<br class="">maybe) the particular mime type of the video. For the "maybe" case, the engine <br class="">is instantiated, loading goes forward and the networkState is set to <br class="">FormatError in case something goes wrong. In that case MediaPlayer tries the <br class="">next available engine.<br class=""><br class="">Things work different for MSE. No matter what support the engine reports, all <br class="">the engines are tried and the content loading is attempted. Setting <br class="">FormatError in networkState is the only way in which an engine can reject <br class="">being selected. Unfortunately, it's impossible for <br class="">MediaPlayerPrivateGStreamerMSE to take that decision at loading time, because <br class="">usually the load happens before the MediaSource has been configured with <br class="">SourceBuffers (the ones specifying a mime type). Therefore, the MSE player <br class="">private must always succeed blindly on loading if it wants to have any <br class="">opportunity. This works fine for real world use cases.<br class=""><br class="">My issue is related to MockMediaPlayerMediaSource, the test engine which <br class="">should take care of the "video/mock" content used in some layout tests. Our <br class="">MSE player private gets selected and performs the loading (of an empty <br class="">MediaSource). However, when a video/mock SourceBuffer is added, it's too late <br class="">for the MSE player private to reject being in charge. Both MediaSource and <br class="">SourceBuffer are already using the GStreamer-related subclasses as their <br class="">MediaSourcePrivate and SourceBufferPrivate counterparts and they can't be hot-<br class="">swapped with the Mock-related subclasses. Returning NotSupported in <br class="">MediaSourceGStreamer::addSourceBuffer() only makes things worse. The <br class="">JavaScript code triggering that call expects addSourceBuffer() to be handled <br class="">by the mock engine and to succeed on the first attempt. The JS code isn't <br class="">supposed to retry the call to addSourceBuffer().<br class=""><br class="">I wonder what's the right way to manage the competitive selection between the <br class="">platform player private and the mock player private to make real world use <br class="">cases and test use cases work together. In particular, I wonder how it can <br class="">successfully work in the Mac implementation.<br class=""></div></div></blockquote><div><br class=""></div><div>It’s a bit of a hack, the way this works in macOS. &nbsp;When a LayoutTest asks to install the mock MSE player in Internals::initializeMockMediaSource(), we uninstall all the AVFoundation-based MediaPlayerPrivates, including MediaPlayerPrivateAVFoundationObjC, MediaPlayerPrivateMediaSourceAVFObjC, and MediaPlayerPrivateMediaStreamAVFObjC. &nbsp;This leaves the MockMediaPlayerMediaSource player as the only remaining installed player.</div><div><br class=""></div><div>I’m very open to ideas about how to clean this area up, since, as you noted, we don’t even get a MIME type until long after the MediaPlayerPrivate is created. &nbsp;But for now, you can add some calls to disable the standard GTK MediaPlayerPrivates in Internals::initializeMockMediaSource(), which should allow you to run tests correctly.</div><div><br class=""></div><div>-Jer</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The MediaPlayerPrivateMediaSourceAVFObjC implementation declares that it <br class="">doesn't support and empty mimetype (irrelevant here, as it'll always be tried <br class="">by MediaPlayer when MEDIA_SOURCE is enabled). Then, on load, it doesn't check <br class="">anything so apparently succeeds.<br class=""><br class="">I would be really grateful if Jer Noble or anybody else with knowledge on the <br class="">matter could devote some minutes to shed some light about the right way to <br class="">make the mock player private and the MSE player private live together.<br class=""><br class="">Thank you.<br class=""><br class="">-- <br class="">Enrique Ocaña González<br class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></div></blockquote></div><br class=""></body></html>