- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 1 Jun 2015 14:19:50 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, Jan-Ivar Bruaroey <jib@mozilla.com>
- CC: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 30/05/15 22:27, Martin Thomson wrote: > On 30 May 2015 at 12:26, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >> I'm arguing it's good enough for replaceTrack to flicker when I >> unplug/transition off my on-chip H.265 encoding USB camera to the built-in >> one. > > I'm not sure what you think is happening here. The concern is the > atomicity of the update, in all its aspects. You can negotiate a new, > bundled track and have a single instant in time where that applies > (setRemoteDescription most likely). That can almost be fast enough to > not matter (a round trip to JS, all going well). > > But the sender is never the concern. It's the coordination of the > transition at the receiver that hurts. I agree, and if replaceTrack (initially at least) was specced to only work if the UA could simply replace the content of existing outgoing RTP stream(s) - SSRC and all being the same - would feel the simplest (of course a full ref frame must be coded for the first frame of the new track). Personally I think that would be the best approach for 1.0; the application can always resort to add/removeTrack (and perhaps mute / unmute events are a good indication at the remote side on when to switch video that is displayed?) if replaceTrack fails.
Received on Monday, 1 June 2015 14:20:21 UTC