[Bug 27249] Correct the “All or Nothing” Approach Currently Implemented For HTMLMediaElement / MSE

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27249

--- Comment #2 from Karan Lyons <karan@karanlyons.com> ---
Yes, it picks the first source it can play. I couldn’t find that word so
settled for “best” in quotes. Sorry for the confusion there. The browser still
is doing some amount of work to determine the file type and codecs of the
various sources, but this information isn’t exposed to the developer (nor is
there any paired function to go with canPlayType, something like
getMediaType(URI)).

The preload attribute is useful, but doesn’t help in this case. I agree that
theoretically the browser should be in the best position to determine how much
to buffer, but removing control entirely from the developer drastically limits
their options within HTMLMediaElement (and right now, as far as I can tell, the
only way to mimic HTMLMediaElement’s streaming of data is with XHR hacks to
stream the binary data as text, convert it back to an ArrayBuffer on progress
events, and then appendSource() it, and after all those machinations there does
not *appear* to be a way to then remove some amount of the data, (it might be
covered by appendWindow, I’m still not certain.)). So there are definitely use
cases that aren’t currently covered by either HTMLMediaElement nor MSE, but
could easily be if either implementation opened up just a *bit* more control to
the developer. I understand that the question of where to draw that line is a
difficult one, and though I can’t give a definitive answer, I at least can say
that it needs to be moved a tad.

At the very least, regarding metadata, anything the browser is expected to use
in order to setup and run playback should also be available to the developer.
The first obvious one to me would be file type and codec information. This
doesn’t have to change in HTMLMediaElement, but in MSE at least there shouldn’t
be a need for manifests and the predetermining of media information when we’ve
proven with HTMLMediaElement that this is stuff that browser can handle. There
should be methods available in order to leverage what the browser can already
do.

One shouldn’t have to write a streaming mp4/webm parser in javascript (I truly
can’t think of another way, and I’m not trying to be facetious. I looked
through the specs, tried everything I could think of, and then wrote a partial
mp4 parser to process streaming data from XHR with an overridden MIME type.) in
order to get codec information for MediaSource.addSourceBuffer() when it’s
clear the browser already has some way of getting this information or handling
bad file types/codecs.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 6 November 2014 18:12:10 UTC