W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: ReplaceTrack - need to evaluate alternatives

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 15 Apr 2015 14:51:48 -0700
Message-ID: <CAJrXDUEk_CpAMq+u9hrUdrHz1o_3_WFoQsM10wSPNX3JnTNCxg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, Apr 13, 2015 at 1:51 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> <chair hat>
> At the October 2014 TPAC, we had a presentation on the proposed
> ReplaceTrack function.
>
> Despite some misgivings (OK, a lot of them mine) about the way
> ReplaceTrack works with the identifiers of tracks, the WG decided to go
> ahead with adopting ReplaceTrack, and asked for a complete proposal.
>
> At the moment, we have two proposals for ReplaceTrack or equivalent up as
> pull requests, both by Jan-Ivar.
>
> The two proposals are:
>
> https://github.com/w3c/webrtc-pc/pull/195 - RTCRTPSender.ReplaceTrack(MediaStreamTrack
> withTrack)
>
> https://github.com/w3c/webrtc-pc/pull/196 - RTCRTPSender.track attribute
>
> Both proposals suggest that the action of replacing a track either fires
> negotiationnneeded or "just switches". Neither proposal says what happens
> to the identifiers on the receiving side - presumably they would be
> unchanged in the "no signalling" case, but I'm not sure what would happen
> in the "signalling" case.
>
> We have to decide:
>
> a) whether the proposals are complete enough to evaluate or not
>
> b) whether the proposals' suggestions for how to handle signalling is the
> right one
>

​The more I read the discussion, the more I think it's a mistake to be
signalling MediaStreamTrack.ids at all.  There's just too much complexity
for too little gain.  Like Justin and Martin have suggested, I think we
need to change our thinking to having and our IDs or labels on RtpSenders
and RtpReceivers, not tracks.  I think we should signal IDs or labels for
RtpSenders, not tracks.

As I suggested in another thread, I think there is a good comparison to be
made with RTCDataChannel and createDataChannel.  The JS provides a label
for the channels, not the "source" of where the data comes from.
Similarly, I think we can simplify things a lot by labelling the RtpSender
and RtpReceiver, not the "source" where the media comes from.


> c) if we prefer the "replaceTrack()" or ".track" representation of the
> functionality.
>

​As I suggested on the other thread, I prefer replaceTrack (or setTrack).
I think ".track = " would be a mistake.​



>
> Comments welcome!
>
>           Harald
>
>
>
Received on Wednesday, 15 April 2015 21:52:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC