W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Re: Resolution changes

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Tue, 15 Sep 2015 00:32:20 -0400
To: Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <55F79F54.4050303@mozilla.com>
On 9/14/15 11:20 PM, Harald Alvestrand wrote:
> On 09/14/2015 07:20 PM, Jan-Ivar Bruaroey wrote:
>> On 9/14/15 9:17 PM, Harald Alvestrand wrote:
>>> On 09/14/2015 02:38 PM, Martin Thomson wrote:
>>>> What happens when MediaStreamTrack changes resolution to something
>>>> outside of the negotiated envelope of the session?  There is no
>>>> language in the spec.  Presumably if the resolution can be reduced,
>>>> reduce it.  Increasing resolution might be the only option we have in
>>>> the case that the session has a resolution floor.
>>> Section 5:
>>>
>>> Let's look at a slightly different situation starting from the same 
>>> point. In this case, instead of the first track attempting to apply 
>>> a conflicting constraint, the user physically locks the camera into 
>>> a mode where the fill light is on. At this point the source can no 
>>> longer satisfy the second track's mandatory constraint that the fill 
>>> light be off. The second track is transitioned into the muted state 
>>> and receives an|overconstrained| 
>>> <http://w3c.github.io/mediacapture-main/getusermedia.html#event-mediastreamtrack-overconstrained>event.
>>>
>>> More info in section 11.1.1.
>>
>> Constraints are properties of the application, not the browser, and 
>> no constraints were violated here.
>
> I don't even know what this means, but if it has meaning, I think 
> you're wrong.
> the "light must be off" constraint is violated whenever the light is on.

I'm not challenging the spec text, only its relevance to Martin's case.

   source -> track -> sink

Camera fill-light switch = source property.
PeerConnection negotiation window = sink property.

While I find support for peerConnection being able to change a source 
*within constraints*, I find no support for sink properties trumping 
constraints.

Instead I read: "Many sinks may .. take these [source setting] changes 
in stride. ... Others like the Recorder API may fail as a result of a 
source setting change." [1]

I take this to mean the sink fails, not applyConstraints.

[1] 
http://w3c.github.io/mediacapture-main/getusermedia.html#the-model-sources-sinks-constraints-and-settings

.: Jan-Ivar :.
Received on Tuesday, 15 September 2015 04:32:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC