Open xxyzzzq opened 7 years ago
From @richtr on June 30, 2015 10:58
FWIW, transient-solo
probably makes the most sense for a WebRTC-based media session right now. However, that is not really ideal for telephony longer-term since other transient-solo
content could then still pause those media elements (without pausing its associated media stream).
Related: there was some discussion on this issue yesterday in the #WHATWG IRC channel http://krijnhoetmer.nl/irc-logs/whatwg/20150629#l-186.
We could always add a 'telephony' media session category. Alternatively we could add special handling when mediaElement.srcObject
is a MediaStream
object or when mediaElement.src
is a Blob
object generated from a MediaStream
object.
Perhaps ideally WebRTC could start returning RTCMediaStream
objects so we can distinguish WebRTC-originating MediaStream
objects from other non-WebRTC sources of media streams. Then we could provide telephony with a suitable session only when it really is a telephony-generated media stream.
interface RTCMediaStream : MediaStream {}
From @foolip on July 1, 2015 16:30
From the IRC discussion with @annevk I can see two main points:
From @mounirlamouri on June 29, 2015 15:55
AFAIK, WebRTC output is usually piped to a
<video>
that means that the element will be part of a MediaSession of some sort. However, even if it's close tocontent
, it's not reallycontent
because it wouldn't make sense to pause the video when there is a notification or have a pause button in the device's lock screen.We should try to see how we can make that UC fit into the spec model.
Copied from original issue: WICG/mediasession#81