- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 14 Apr 2015 01:34:26 -0400
- 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