- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 21 Mar 2013 00:10:53 +0000
- To: Sylvain Galineau <galineau@adobe.com>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, Kenneth Rohde Christiansen <kenneth.r.christiansen@intel.com>, "florian@rivoal.net" <florian@rivoal.net>, "www-style@w3.org" <www-style@w3.org>
On Mar 20, 2013, at 4:49 PM, Sylvain Galineau wrote: >> >> >> >> Tab suggests we need some way to declare the resolution, or channel >> count, of the media to the UA, but that would move the responsibility for >> deciding how to match media properties with physical properties from the >> user to the UA: a different distribution of responsibility from selection >> based on media queries. Why should these particular properties (physical >> resolution, audio output channels) be treated differently from others >> (color depth, aspect ratio, etc.) ? > > Sorry, I don't follow the distribution of responsibility argument at all. > I - and, I think, Tab - is suggesting media queries pick the right source > so you then know what stream you need. I'll respond to Tab's mail on this point ... > >> >> I still think what is needed is media query properties for these >> properties of the output device. > > My apologies if I missed the obvious as it's a long thread; what about the > media attribute of the <source> > element doesn't work for this purpose? Yes, I'm talking about the media attribute which specifies a media query. It's just that media queries can't express conditions related to audio output channels, physical resolution or frame rate capability. I'd like to propose that those be added to Media Queries 4. > >> >> Second, we could let the media element select between multiple <source> >> elements, each connected to a different MediaSource object. Each <source> >> would have a media query specifying when it should be used. The >> MediaSource associated with the chosen <source> would change state when >> selected, with an event indicating to the script that this has happened, >> prompting the script to start appending the appropriate media to this >> object. Everything needed to do this exists (except the additional >> properties described above). > > If the media queries in the media attributes of each source select the > right element and your script knows which source was picked, > doesn't that give you what you want? Yes, but … see below ... > >> >> The issue with this is combinatoric explosion. Suppose I have SD, HD and >> UHD video streams and stereo, 5.1 and 7.1 audio. I need to provide >> <source> elements with associated media queries. If I add 60fps as well >> as 30fps now I have 18. Ok, maybe a few less because I don't have the SD >> in 60fpsŠ >> >> Alternatively, I can call window.matchMedia() at most 8 times at which >> point I will know exactly which video and audio streams to use and can >> create a single MediaSource and append these. Again, though, everything >> needed to do this exists except the additional properties. > > OK, this explains why you might want to add audio capability detection to > MQ as well. If the properties were added to MQ, then both of the above approaches (<source> selection, or script-based selection) would be possible. …Mark > >
Received on Thursday, 21 March 2013 00:11:21 UTC