[webkit-dev] Making MockMediaPlayerMediaSource and other MediaPlayerPrivateInterface subclasses work together
jer.noble at apple.com
Mon Nov 28 09:21:04 PST 2016
> On Nov 24, 2016, at 10:00 AM, Enrique Ocaña González <eocanha at igalia.com> wrote:
> These days I've been working on improving the layout test passrate of our new
> Media Source Extensions GStreamer platform implementation
> (MediaPlayerPrivateGStreamerMSE), but I'm having problems with the selection
> of the right MediaPlayerPrivateInterface implementation for each use case.
> As I understand it (please correct me if I'm wrong), under normal
> circumstances (no MEDIA_SOURCE enabled) MediaPlayer tries to find the best
> media engine (ie: MediaPlayerPrivateInterface implementation) available to
> play a content. It does so by asking each engine if they support (yes/no/
> maybe) the particular mime type of the video. For the "maybe" case, the engine
> is instantiated, loading goes forward and the networkState is set to
> FormatError in case something goes wrong. In that case MediaPlayer tries the
> next available engine.
> Things work different for MSE. No matter what support the engine reports, all
> the engines are tried and the content loading is attempted. Setting
> FormatError in networkState is the only way in which an engine can reject
> being selected. Unfortunately, it's impossible for
> MediaPlayerPrivateGStreamerMSE to take that decision at loading time, because
> usually the load happens before the MediaSource has been configured with
> SourceBuffers (the ones specifying a mime type). Therefore, the MSE player
> private must always succeed blindly on loading if it wants to have any
> opportunity. This works fine for real world use cases.
> My issue is related to MockMediaPlayerMediaSource, the test engine which
> should take care of the "video/mock" content used in some layout tests. Our
> MSE player private gets selected and performs the loading (of an empty
> MediaSource). However, when a video/mock SourceBuffer is added, it's too late
> for the MSE player private to reject being in charge. Both MediaSource and
> SourceBuffer are already using the GStreamer-related subclasses as their
> MediaSourcePrivate and SourceBufferPrivate counterparts and they can't be hot-
> swapped with the Mock-related subclasses. Returning NotSupported in
> MediaSourceGStreamer::addSourceBuffer() only makes things worse. The
> by the mock engine and to succeed on the first attempt. The JS code isn't
> supposed to retry the call to addSourceBuffer().
> I wonder what's the right way to manage the competitive selection between the
> platform player private and the mock player private to make real world use
> cases and test use cases work together. In particular, I wonder how it can
> successfully work in the Mac implementation.
It’s a bit of a hack, the way this works in macOS. 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. This leaves the MockMediaPlayerMediaSource player as the only remaining installed player.
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. 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.
> The MediaPlayerPrivateMediaSourceAVFObjC implementation declares that it
> doesn't support and empty mimetype (irrelevant here, as it'll always be tried
> by MediaPlayer when MEDIA_SOURCE is enabled). Then, on load, it doesn't check
> anything so apparently succeeds.
> I would be really grateful if Jer Noble or anybody else with knowledge on the
> matter could devote some minutes to shed some light about the right way to
> make the mock player private and the MSE player private live together.
> Thank you.
> Enrique Ocaña González
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev