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

Re: ReplaceTrack - need to evaluate alternatives

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 14 Apr 2015 01:34:26 -0400
Message-ID: <552CA6E2.7020901@jesup.org>
To: public-webrtc@w3.org

>> We have to decide:
>>
>> a) whether the proposals are complete enough to evaluate or not
>
> Thanks for posting Harald. Yes everyone please evaluate! Let us know 
> if there are things you think needs to be clarified or made more explicit.
>
>> b) whether the proposals' suggestions for how to handle signalling is 
>> the right one
>
> The model for RtpSender as a whole seems to be to allow changes 
> locally and have negotiationneeded fire in response only when needed. 
> ReplaceTrack follows that model.
>
> "Track-renaming" on the receiver of subsequent renegotiation, is new. 
> Please comment.

So long as we maintain the ability to not cause negotiation-needed 
except when actually required, this is good for me.  I want the be able 
to change what I'm pushing into the pipe without a negotiation delay 
(and failure modes, and ability for the other side to reject, etc).  For 
example when using it to mute/unmute a camera with a slate or 
anim/video, or to swap which local camera I'm streaming - I want the 
switch to happen now, not X-hundred ms from now (assuming all agree), 
and also avoid possible glitching/etc from the negotiation resolution.  
(I'm just re-iterating the discussion from the interim, with much less 
detail.)

This is especially important as we don't have the Video equivalent to 
WebAudio that could "hide" all these manipulations between a source and 
where it goes into a PeerConnection.

>
>> c) if we prefer the "replaceTrack()" or ".track" representation of 
>> the functionality.
>
> The latter returns a promise, is the only difference. The promise lets 
> you learn when the new track is sending, whatever that means. I 
> suppose it would allow for implementations to do some of the work that 
> might fail asynchronously. The reason I'm a little fuzzy on this is 
> that Firefox's current implementation is synchronous.

I'm good with either; at this point I don't see need for a promise, but 
predicting the future (and other people's impls) is hard.


-- 
Randell Jesup -- rjesup a t mozilla d o t com
Received on Tuesday, 14 April 2015 05:35:54 UTC

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