MSE spec change is pending review @ https://github.com/w3c/media-source/pull/85
Chromium change is pending review @ https://codereview.chromium.org/2021573002/

Upstream web-platform-tests change is pending MSE spec and Chromium change landing, as well as wpt review at https://github.com/w3c/web-platform-tests/pull/3082

Do you think the spec change would be in MSE or HTML? At least as expressed in https://w3c.github.io/media-source/#mediasource-attach I think it has the problem that any change to the delaying-the-load-event flag could be undone by the resource fetch algorithm that runs after the src attribute is set.

https://codereview.chromium.org/2021573002/ seems to hook into the demuxer (in WebMediaPlayerImpl::StartPipeline()) so the timing of that is different, and doesn't have that problem.

foolip@, if I understand your comment correctly, is it unclear that the steps (in MSE spec PR 85) are already being run as part of the resource fetch algorithm. In fact, PR 85 doesn't change that. Current ED prior to landing PR 85 states the following right before the steps that actually perform the attachment as part of the resource fetch algorithm:
'If the resource fetch algorithm absolute URL matches the MediaSource object URL, ignore any preload attribute of the media element, skip any optional steps for when preload equals none, and run the following steps right before the "Perform a potentially CORS-enabled fetch" step in the resource fetch algorithm.'
Or am I misunderstanding some other race/ambiguity around this in the MSE spec?

s/./?/ at the end of first sentence in #6

Note: I'll pend landing the changes mentioned in #3 until foolip@ and I are on the same page about this :)

Oh, I hadn't actually read the diff of https://github.com/w3c/media-source/pull/85

Looks like the bit you're changing is the otherwise branch in https://w3c.github.io/media-source/#mediasource-attach, I just assumed that it would be around "by assigning a MediaSource object URL to the media element src attribute".

It looks like the intention is that as soon as we know that we've picked a resource that is a MediaSource object, the delaying-the-load-event flag should be set to false. I think that getting https://github.com/whatwg/html/pull/1037 done and hooking into the "Otherwise (mode is local)" steps would be the cleanest way to express this, but that's a matter of changing the wording of the reference before the steps, or adding a call in HTML to avoid the monkey-patching of course.

In https://codereview.chromium.org/2021573002/, would it work to instead unset the flag in HTMLMediaElement::startPlayerLoad() to more closely match how the spec is expressed? Where are the other steps of the that algorithm implemented?

Getting back to working on this now. c#9's:

> In https://codereview.chromium.org/2021573002/, would it work to instead unset the flag in HTMLMediaElement::startPlayerLoad() to more closely match how the spec is expressed? Where are the other steps of the that algorithm implemented?

I was being conservative about resetting the delay-the-load flag in the CL because, long ago in Chromium we had some bad MSE attachment races. We currently don't really finalize MSE attachment in Blink HTMLME until WebMediaPlayerClient::mediaSourceOpened() is called by m_webMediaPlayer() (which can occur after asynch pipeline thread hopping delays). Note that WebMediaPlayerClient::mediaSourceOpened() also synchronously triggers the MediaSource readyState transition into "open" and consequent enqueueing of "sourceopen".

Regardless, if we stop delaying the load event early (e.g. in ::loadResource()) and there is some pipeline error or delay on mediasource object initialization, or other WebMediaPlayer-introduced asynch delay, then the load event might be fired earlier. I don't think that's necessarily a problem, since we stop delaying the load event in HTMLME error paths, too.

Since steps 2 and 3 of the attachment algorithm continue in ::mediaSourceOpened(), I think for now, putting step 1 there is most consistent - though I don't have a terribly strong reason other than those, above.

I'll rebase the CL (https://codereview.chromium.org/2021573002/), address mlamouri@'s comments and add you (foolip@) as a reviewer to make sure we're on the same page about this before it lands.

See also bug 255652, which tracks making the attachment of MSE synchronous with transition of MediaSource readyState to "open". Though IIUC, there's already some asynchronicity in HTMLME between setting src attr and ::loadResource().

Last week was BlinkOn, sorry for the delay. Per issue 255652 it sounds like the timing of transition to readyState "open" and the sourceopen event is already going to be wrong per spec, and this just adds another step with similarly wrong timing.

If the reason for the current timing is attachment races, then maybe the spec as it is can't actually be implemented? Maybe the spec should just say that attachment happens async some time after the steps in the resource fetch algorithm?

Unless other implementations do precisely what the spec says and thus shows it to be possible and web compatible, can you file a spec issue to sort out this situation?

@#12, I don't think the race is a spec issue. Rather, in our implementation, we hop through the media thread to initialize the pipeline and the demuxer. This initialization binds the pipeline to the demuxer. There could be some refactoring (tracked in bug 255652) to make the minimum necessary MSE demuxer initialization be synchronous with attachment. I'm not aware of any spec reason why this can't be made synchronous, hence I've left it as a crbug to fix.

OK, that's good, leaves some options open spec-wise. Even if it's possible to implement this synchronously, does anything in the spec depend on demuxer initialization being synchronous? The buffer append algorithm happens async, at least from appendBuffer. So, would it be possible to make it async in the spec just for the sake of simplicity of implementation?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea101249f079972e2dd6b6448bb73c1b0437c8d8

commit ea101249f079972e2dd6b6448bb73c1b0437c8d8
Author: wolenetz <wolenetz@chromium.org>
Date: Thu Jun 23 01:53:14 2016

MSE: Reset delaying-the-load-event-flag on attachment

Currently, the earliest non-error case reset of media element's
delaying-the-load-event-flag when MSE is attached occurs at either the
'stalled' event scheduling or once first reaching >= HAVE_CURRENT_DATA.
This change makes Blink compliant with recent MSE spec
clarification [1] that resets this flag immediately upon MSE attachment.
Non-MSE media element delaying-the-load-event-flag behavior remains
unchanged.

[1] https://github.com/w3c/media-source/pull/85

TEST=http/tests/media/media-source/mediasource-attach-stops-delaying-load-event.html
BUG= 615481 

Review-Url: https://codereview.chromium.org/2021573002
Cr-Commit-Position: refs/heads/master@{#401516}

[add] https://crrev.com/ea101249f079972e2dd6b6448bb73c1b0437c8d8/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-attach-stops-delaying-load-event.html
[modify] https://crrev.com/ea101249f079972e2dd6b6448bb73c1b0437c8d8/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp

@#14, it could perhaps be asynchronous in spec - nothing seems to contraindicate that that I'm aware of. At the moment, though, I suspect allowing asynch attachment might be a substantive enough change to not be able to be included in MSE v1 spec.

I've filed MSE spec issue https://github.com/w3c/media-source/issues/104 to investigate formally clarifying allowance for asynchronocity of MSE attachment.

Thanks!

Good for jw players options platform 

Deleted: jwplayer.flash.swf 93.6 KB

jwplayer.flash.swf 93.6 KB Download