Re: [mediaqueries4] Media queries for multichannel audio ?

On Mar 20, 2013, at 10:22 AM, Tab Atkins Jr. wrote:

> On Wed, Mar 20, 2013 at 10:19 AM, Mark Watson <watsonm@netflix.com> wrote:
>> On Mar 20, 2013, at 10:10 AM, Tab Atkins Jr. wrote:
>>> On Wed, Mar 20, 2013 at 8:37 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>> What I need is just the device width and height in device pixels, to know
>>>> when it is not worth delivering a high resolution version of the content.
>>>> It's not such a big deal with HD, since there are a dwindling number of SD
>>>> displays, but with 4K this will be an issue.
>>> 
>>> You don't want that.  What you want instead is some way to declare the
>>> resolution on the <source> element, so (1) the browser can
>>> intelligently choose which source to download, based on what it knows
>>> about the display, the user's internet connection, and possibly other
>>> things, and (2)  the browser can offer both options to the user, a la
>>> YouTube's resolution selection.
>> 
>> I'm interested in implementing the resource selection algorithm in
>> Javascript for the case where I am using the Media Source Extensions, not
>> the <source> element. See
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21336.
> 
> Forgive me for not finding that a compelling use-case.  ^_^
> 
> More seriously, if the EME stuff is so foreign that it can't even
> integrate with the <video> source selection, that's a bug in the EME
> spec, not something to be worked around in other specs.

It's not the Encrypted Media Extensions, it's the Media Source Extensions - there really is *nothing* associated with encrypted media in MSE (by design) and many people would like to use one without the other.

The object of the Media Source Extensions is to enable adaptive streaming to be implemented in Javascript. Rather than have the media element select and download chunks of media, the Javascript application does that (using XMLHttpRequest) and passes the downloaded chunks to the media element using the Media Source Extensions.

Here is not really the place to debate the pros and cons of that architecture, but there are a lot of advantages compared to the alternative of embedding the adaptive streaming logic and manifest format into the browser.

In this model, resource selection also becomes the job of the Javascript application, which likely has a lot more information about the available streams (as described in whatever manifest format the application uses) to inform it's decisions. It just needs access to information about codecs support (which it has through canPlayType) and output device properties. Media queries seem the natural way to handle the latter, since this is how that is already handled for the media element itself.

…Mark
> 
> ~TJ
>

Received on Wednesday, 20 March 2013 18:15:10 UTC