W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2016

Re: Remote tracks. Why?

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 4 Mar 2016 09:49:55 +0000
To: Martin Thomson <martin.thomson@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B374BAF9C@ESESSMB209.ericsson.se>
(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

This archive was generated by hypermail 2.3.1 : Friday, 4 March 2016 09:50:29 UTC