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

Re: Summary of replace track status

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Sat, 30 May 2015 15:26:15 -0400
Message-ID: <556A0ED7.10202@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.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 5/30/15 11:30 AM, Martin Thomson wrote:
> On 29 May 2015 at 21:51, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> It impressed me how small the difference was - granted my machines are
>> same-LAN (need to find another wifi, my wifi-4G test failed) - I see a
>> split-second flicker on Remove+Add compared to ReplaceTrack which is
>> super-smooth (though there's sometimes a delay flipping back, a bug?) Test
>> is also not glare-proofed.
> Once you have had to deal with this on a call between Australia and
> Europe, I think that you will find that this is not good enough.  And
> keep in mind that signaling in some call scenarios is multi-leg: you
> tell a bridge what you want to do and they have to coordinate with a
> large group of peers.

Good info.

But I'm not arguing it's good enough (I want replaceTrack).

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.

What's the alternative? Black?

.: Jan-Ivar :.
Received on Saturday, 30 May 2015 19:26:48 UTC

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