The fetch step in HTML5.1's resource fetch algorithm no longer exists

[tidoust]

In 2.4.1 Attaching to a media element, the Media Source Extensions specification plugs itself into the "Perform a potentially CORS-enabled fetch" step of the resource fetch algorithm, defined in HTML5.1.

This algorithm has been updated in HTML5.1 and that step no longer exists.

Actually, I think that algorithm got updated precisely to cover media provider objects à la MediaSource, although the expected attachment method is rather via srcObject, which seems planned for VNext (#28).

Perhaps you can plug after the first step in this algorithm to force mode to local, reset the delaying-the-load-event-flag, etc. Step 4. in "Attaching to a media element" would then not be needed anymore. I may have missed something though.

Also note that steps à la "If the media data cannot be fetched at all, ..." are now defined in a separate media data processing steps list algorithm and are no longer in the resource fetch algorithm. References should be updated accordingly in the End of stream algorithm.

[wolenetz]

This seems to me to be an editorial change. Please update if you disagree.

[mwatson2]

It seems to me that the only monkey-patch we need is to say that a MediaSource media provider object can be attached using src and the MediaSource object URL.

The new resource fetch algorithm already seems to support MediaSource as a media provider object, even if we do not specify that it can be attached with srcObject.

I guess we should also say that in the case a MediaSource is attached via src and a MediaSource object URL then the srcObject attribute may not reflect this.

[wolenetz]

It looks like a combination of @mwatson2's simplified monkey patch, plus @tidoust's note that references in MSE need to be updated to the new "media data processing steps", is the way to go. In VNext, we can get srcObject hooked up appropriately for MediaSource (#28).

[wolenetz]

I'll begin work on this shortly.

[wolenetz]

Note that whatwg/html#1037 is what moved the MediaSource objectURL piece to the "local" branch in the resource selection algorithm in HTML5.1. However, I don't see the specific text there which would effectively make this MSE issue much simpler (perhaps just a non-normative note that srcObject support for MSE is a quality of implementation issue).
@foolip : Why isn't whatwg/html#1037 reflected in https://www.w3.org/TR/html51/semantics-embedded-content.html#resource-fetch-algorithm ?

edit:
Even with that PR1037, we'd still need to correct the "CORS fetch" text in the MSE monkey-patch of HTML5 to align it with the media provider object wording in HTML51.

edit:
Aha -- that was the whatwg version of HTML which took the text change, not the w3c HTML51 version. @foolip, what's the prognosis of such text getting into w3c's HTML51 version? For now, it seems MSE v1 must make a monkey-patch to align with w3c HTML51's "local" mode.

[foolip]

This is a bit of a mess and I'm not a neutral third party, but let's see... w3c/html is maintained by a separate group of people, and copying changes from whatwg/html is a manual process because the whole spec was reformatted to use Bikeshed. Right now it looks like the focus is on reaching PR or REC and not so much on keeping up to date with upstream changes.

I think you have these options:

1. File an issue or PR to port the change.
2. Change the monkey patch to make the first step "If the algorithm was invoked with media provider object or a URL record whose object is a media provider object, then let mode be local. Otherwise let mode be remote." and ignore the fact that the W3C spec will invoke the algorithm with a URL string and not a URL record, which is what you get by parsing the URL string.
3. Drop the monkey patching entirely and just say in a note that how this works depends on which version of HTML is implemented, and add a test to web-platform-tests testing the behavior from Treat blob: URLs as local in the resource selection algorithm whatwg/html#1037 because that's where you expect things to end up.

Sorry that you're having to deal with this situation.

[wolenetz]

Combo of (1) and (2) from #99 (comment) sounds like the way to go. I'll prepare an issue shortly for HTML51 w3c discussion ASAP (around (1)).

[wolenetz]

PR #143