Re: ReplaceTrack - need to evaluate alternatives

On 4/15/2015 5:51 PM, Peter Thatcher wrote:
> 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.

+1!  An RTPSender is a pipe.  What you stuff into the pipe is your 
business, not the other ends.  Once a pipe is created, it may have both 
mutable (bitrate) and immutable-without-renegotiation characteristics 
that stuff pushed into it must comply with.  It adds useless complexity 
for the identifier to be tied to the source, especially once you start 
allowing different things to be put in the pipe.

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

+1

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

Agreed.

-- 
Randell Jesup -- rjesup a t mozilla d o t com