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

Re: Summary of replace track status

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sat, 30 May 2015 13:27:46 -0700
Message-ID: <CABkgnnWGu5+2uoh1MOaF4zxSgdjYP0R6s2oHSK1vvCMbKf2ydQ@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "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 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.  The receiver applies the new
description, and then receives the new track.  But that track contains
nothing until the other side makes the switch, so you have to rely on
other signals: do you attach the new track to a new video element and
wait for one of the many inscrutable events to fire there before
switching out the display?  It might work.
Received on Saturday, 30 May 2015 20:28:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:07 UTC