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

Re: Summary of replace track status

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D244F26@ESESSMB209.ericsson.se>
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

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