Should MSE cause any "preload" attribute on parent media element to be ignored?

[wolenetz]

For example of interop issues around at least the preload="none" case, see Chromium bug https://crbug.com/539707.

Since MSE API gives the web app control over buffering, the preload attribute on the media element seems meaningless. Am I missing some particular behavior of the user agent for a media element with MediaSource attached that should be conditioned on the media element's "preload" attribute? Or should such a media element explicitly ignore or override to "auto" the "preload" value on attachment of a MediaSource?

[jdsmith3000]

Makes sense. We should ignore preload on media elements when being used with MSE.

[cpeterso]

Mozilla is tracking this issue in Firefox bug 1211752.

[foolip]

The distinction between preload states "metadata" and "auto" is indeed meaningless for MSE, but preload="none" is interesting.

Per the HTML spec, preload="none" can stop the load early in the resource fetch algorithm, inside the "If mode is remote" branch. In the "Otherwise (mode is local)" branch, preload simply has no effect. The local mode is for srcObject, and I think it would make sense to treat object URLs identically.

That would require a change to the HTML spec, if it sounds like the right fix for everyone involved I can file an issue and try to make it so.

[jdsmith3000]

@foolip Can you clarify an MSE use case where supporting this would be helpful? Does it have value for a case where a sourceBuffer is attached, and data is first appended to it?

[foolip]

What I suggest in #11 (comment) is a spec change to ignore preload="none" for MSE, not a way to support it. That isn't to support any use case, but to avoid the kind of bug encountered in https://crbug.com/539707. As a bonus, it would make the behavior of srcObject and object URLs more similar.

[wolenetz]

@foolip, the change you have suggested to the HTML spec sounds good to me. If there ends up being an issue filed and fixed in the HTML spec around this, please update this bug so that we can appropriately resolve this bug. For now, I'm marking this bug as blocked, since it sounds like an external issue (HTML spec update) is the route to a fix. @jdsmith3000, please chime in if you disagree especially.

[paulbrucecotton]

I STRONGLY recommend that we do NOT block MSE's progress out of CR status based on a request for a change to HTML5. The newly formed Web Platform WG has no idea on how it is going to do maintenance or feature requests on HTML5 and I think we should find some other way of handling this problem within MSE even if it means we "break HTML5 semantics".

[wolenetz]

@paulbrucecotton I agree. Let's fix MSE spec without blocking on external spec change to HTML5 as much as possible.

[foolip]

In this case, routing around the HTML spec doesn't seem feasible, since the steps where the blob URL (corresponding to the MediaSource object) is used are not even reached. I'm quite happy to help resolve this in whatwg/html#295. No changes to the MSE spec ought to be needed.

[wolenetz]

@foolip can you update on the ETA of whatwg/html#295 ? If it is not resolved soon for use in MSE spec, I think we'll need to make some explicit change to MSE spec to ignore any preload attribute.

[foolip]

Sorry, when I tried it back then I got hung up on a detail of phrasing and never got back to it. I've fixed it in whatwg/html#1037 now, should hopefully be merged soonish.

[wolenetz]

From the editors' call this morning, it sounds like an explicit mention to ignore 'preload' attribute in MSE spec will be best, even if eventually redundant with HTML spec. This will keep MSE spec from remaining blocked on getting external spec references updated around this, and let us focus on closing down these MSE v1 bugs. I'll prepare a PR shortly.

[wolenetz]

Commit 8aba06a fixed this issue.

[wolenetz]

I've upstreamed a Chromium compliance test for the behavior adjusted in this issue at web-platform-tests/wpt#2896

[foolip]

whatwg/html#295 has now been fixed, which means that 8aba06a could be reverted, as the "If mode is remote" branch which it modifies is no longer taken for valid blob: URLs.

[paulbrucecotton]

MSE contains only a normative reference to W3C HTML5.1 (ISSUE-78), so the rationale that a change in MSE can be reverted based on a change to WHATWG HTML does not hold. We need to check if a similar change has or can be made to HTML 5.1.

[foolip]

I am of course assuming that it will eventually trickle to all versions of HTML that implementors look at.