Remote tracks. Why?

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:30:54 UTC