Re: Resolution changes

On 09/14/2015 09:32 PM, Jan-Ivar Bruaroey wrote:
> 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.

 Ah, that's where we got confused.

Martin's question was "What happens when MediaStreamTrack changes
resolution to something
outside of the negotiated envelope of the session?" - I took that to
mean that the MediaStreamTrack changes resolution, which would happen
only if the source changes resolution.

This could, for instance, happen for a remote data stream when the
remote source changed what it was sending. (VP8 supports changing
resolution at any I-frame; VP9 supports changing resolution even without
an I-frame).

I did not understand Martin to ask about what happens when the
negotiation window on a PeerConnection that is a sink to a
MediaStreamTrack changes - that's a completely different problem, and I
agree that the spec is silent on what should happen then.

Martin, can you clarify what you were asking?

Harald