Re: Remote tracks. Why?

Den 04. mars 2016 10:49, skrev Stefan Håkansson LK:
> (contributor hat on) I was just about to write a similar mail related to 
> the "readonly" marker. Even if a track is sourced by a camera under 
> control of someone else (or a PeerConnection) it could be constrained in 
> certain ways. It could change characteristics at any time, but it could 
> even if it was not controlled by someone else.
> 
>  From my perspective the usefulness of "remote" and "readonly" is not clear.

These two markers were added very early in the document's history.

>From my perspective, "readonly" has never had a proper justification;
even the cited use case ("you can't manipulate this source because it
might affect someone else") feels odd, since it flies in the face of "a
source with multiple users gets configured in such a way that all the
users can be happy, if possible", which is explicitly stated in the
"constraints" discussion.

"remote" has been asserted to be useful, but I haven't figured out
exactly how.

What code would break if we deleted both?

> 
> 
> On 04/03/16 10:31, Martin Thomson wrote:
>> I'm looking at the recent activity regarding remote tracks and I can't
>> find any real justification for this special marker.  The remote=true
>> condition is a pretty dire one.  Apparently constraints do nothing.
>>
>> I think that this is a mistake.  I think that constraining remote
>> tracks is a perfectly good thing to do.  It might even address some of
>> our concerns regarding track control.  But we don't have to go that
>> far, we could simply say that RTCPeerConnection ignores the
>> constraints on the tracks it emits; or better yet, attempts to
>> constrain them in ways not supported by the negotiated session fail.
>> That's something that the WebRTC spec can manage.
>>
>> If our abstraction needs to be this leaky, can we at least document why?
>>
>>
> 
>

Received on Friday, 4 March 2016 10:39:52 UTC