[whatwg] Proposal: channel attribute on HTMLMediaElement

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Sun Apr 7 18:09:06 PDT 2013


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 at 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
>



More information about the whatwg mailing list