- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 8 Apr 2013 11:09:06 +1000
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Paul Adenot <padenot@mozilla.com>
These all sound like important use cases. What I am reading is that there is a need to manage mute state override, playback state management based on browser state, and latency management (some sort of urgency measure). Is there a reason that you have munged these into a single attribute? I am asking because I can see them as being independent dimensions, e.g. you could require low latency and mute state override together. Silvia. On Sat, Apr 6, 2013 at 12:50 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > Hi, > > As Wes suggested it recently [1], we need a way for content to be able > to ask for their media to be played in the background. This is > particularly useful on Mobile when applications could have their audio > shut down when they are in the background. However, we can imagine that > someone listening to a web music player might want to keep that music > stream playing when the browser is no longer in the foreground. Also, it > will help browsers to know when to keep media playing or pause them when > a tab is put in the background. > > However, that problem is a sub-class or a larger problem about assigning > media elements to a specific channel. This is a problem Firefox OS and > Windows 8 have tackled recently with proprietary extensions to > HTMLMediaElement [2][3]. This is a feature other platforms have, like > Android [4] or PulseAudio (GNU/Linux) [5]. > > Based on the prior work, Paul Adenot and I tried to figure out the use > cases that would apply on the web. > > Our proposal is to add a channel attribute on HTMLMediaElement. That > attribute would give information about the type of channel to use and > thus help the UA to know if the channel should be muted or not based on > the current context. In addition, depending on the type of channel, the > UA could decide to whether or not create a low-latency channel. > > There is open question regarding the default behaviour. Our proposal > makes the default behaviour to only play the media when the website is > visible but this is not the common default behaviour and such behaviour > might break some websites. Depending on how critical this > retro-compatibility issue is, we could add a 'Default' state that would > have an undefined behaviour to do whatever retro-compatibility requires. > > The proposal is the following: > > The channel attribute gives a hint about the type of channel the author > is expecting the UA to use. It is an enumerated attribute that uses the > following keywords and states: > > Keyword: media > State: Foreground Media > Fallback: none > Description: To be used for media element that wants to play basic media > such as an audio or video stream that should be paused when the page is > put in the background. > > Keyword: background-media > State: Background Media > Fallback: Foreground Media > Description: To be used for media element that wants to play basic media > such as an audio or video stream that should not be paused when the page > is put in the background. Music, podcast or radio players are expected > to use this state. > > Keyword: effects > State: Effects > Fallback: Foreground Media > Description: To be used for media element that creates short and quick > effects such as button click, game effects. It is intended to be used > for effects that are being heard while using the page, not for > notifications. When on this state, the media should use a low latency > channel. > > Keyword: notification > State: Notification > Fallback: effects > Description: Like the effects state, this intends to be used fort short > and quick media but that require to catch user attention whether the > page is currently visible or not. For example, this state could be used > for a sound notification when there is a new email in the user's inbox. > > Keyword: communication > State: Communication > Fallback: Background Media > Description: To be used for media element that transmits real time > communication such as phone calls or VOIP. When on this state, the media > should use a low latency channel. > > Keyword: alarm > State: Alarm > Fallback: Notification > Description: To be used for media element that wants to make sure to be > played even if the device is currently muted. Typical use case would be > an alarm clock. > > The UA might not support some channels or not allow a specific media > element to use some channels, in which case the fallback state should be > used. > > The missing value default is the Foreground Media state. > > [1] > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-March/039202.html > [2] https://wiki.mozilla.org/WebAPI/AudioChannels > [3] http://msdn.microsoft.com/en-us/library/windows/apps/hh767375 > [4] > https://developer.android.com/reference/android/media/AudioManager.html > (see STREAM_* constants) > [5] > > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties#line-58 > (see PA_PROP_MEDIA_ROLE) > > Thanks, > -- > Mounir >
Received on Monday, 8 April 2013 01:09:55 UTC