Re: Remote tracks. Why?

(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.


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 09:50:28 UTC