[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 #4 from Karan Lyons <karan@karanlyons.com> ---
For codec information there’s the desire for API symmetry, and more practically
MSE SourceBuffers require that you specify the filetype and codec information.
Given that this is determinable by the browser, the ability to get that
information should be exposed to the developer. It also can be useful to have
in plain HTMLMediaElement scenarios, for example: Given a list of <source>s
with varying quality and multiple filetypes (say HD and SD versions of
audio/video in ogg and mp4), allow the user to switch between the two quality
versions, supplying them with the correct filetype/codec based on what their
browser can play. Requiring the end user or developer to supply codec
information as an attribute on the source is less than ideal, again given that
the browser is fully capable of working this out itself. And guessing based on
file extension (the browser is currently playing ".mp4”, so the other mp4s
*probably* work), is again not ideal because as unlikely as that is to be
incorrect, it’s still a guess.

As for the buffer scenario, the goal is to account for waste in various
scenarios. A good example (and one very similar to my own) is handling media
playback when the user’s actions influence the amount of media you want to play
post initialization. Even being able to do some form of media fragment URI like
functionality would suffice (but *without* having to reload the source, which
would require a momentary media dropout, and is thus a bad user experience).
This can be useful for things like preroll ads that aren’t required to be
watched the whole way through, or switching source qualities on the fly without
requiring the user to experience a dropout (controlling the buffer is important
here as buffering two sources makes it harder to move up to a higher quality.
Going full MSE to solve this problem is also not a good solution at this time,
again because it requires up front knowledge about filetypes/codecs, something
you can’t provide if you don’t control the sources, and that—again—the browser
is fully capable of figuring out itself), and other cases.

There is also certainly the matter of browser heuristics for buffering varying
from vendor to vendor, and while it would certainly be great to have full
control over buffering (for example, setting the “window” as a TimeRange of
data that you’d like to be buffered, which can be updated at any time), I can
certainly understand some of the argument against it. Even still, it’d provide
some very helpful functionality for many developers looking to do more complex
work with HTML5 media.

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

Received on Friday, 14 November 2014 19:18:30 UTC