W3C home > Mailing lists > Public > public-media-capture@w3.org > June 2013

Re: Media Capture and Streams question - applying constraints

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 14 Jun 2013 13:30:06 +0200
Message-ID: <51BAFEBE.6060304@ericsson.com>
To: public-media-capture@w3.org
On 2013-06-14 01:19, Frederick.Hirsch@nokia.com wrote:
> The latest editors draft of getUserMedia (Media Capture and Streams)
> [1] says in section 4.3.2 [2]
>
> [[ Constraints are independent of sources. However, if the sourceType
> is "none", the readonly attribute is true, or the remote attribute is
> true, the track's constraints will not be applied to the source. ]]
>
> Is it true that muting is not a constraint, so a source (remote or
> not, read only or not) can always be muted for a given sink?

Muting is something the application does not control, a source can be 
muted by the UA, by a button on the microphone etc., but not by the 
application.

The application can control if a MediaStreamTrack is enabled or not (via 
the enable attribute). And this is something that can be done regardless 
of remote or not, readonly or not - you're just controlling if the track 
outputs any media or not.

 From the draft:

"Applications are able to enable or disable a MediaStreamTrack to 
prevent it from rendering media from the source. A muted track will 
however, regardless of the enabled state, render silence and blackness. 
A disabled track is logically equivalent to a muted track, from a 
consumer point of view."

(The above is my understanding)

>
> I think the draft needs an example and more explanation regarding the
> characteristics of read-only and remote sources and what the
> limitations are and mean in practice.

Good point.

>
> regards, Frederick
>
> Frederick Hirsch Nokia
>
> [1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
>
> [2]
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#tracks-and-constraints
>
>
>
Received on Friday, 14 June 2013 11:30:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:17 UTC