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

Re: Summary of replace track status

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 01 Jun 2015 20:54:24 -0400
Message-ID: <556CFEC0.9070004@mozilla.com>
To: Randell Jesup <randell-ietf@jesup.org>, public-webrtc@w3.org
On 6/1/15 2:35 AM, Randell Jesup wrote:
> On 5/30/2015 12:51 AM, Jan-Ivar Bruaroey wrote:
>> Make sure you see both fiddles at once and press |ReplaceTrack| vs 
>> |Remove+Add| to compare.
>> 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.
> To do a more real-world test: add a setTimeout() for say 50, 100 or 
> 200ms to delay each send() in the renegotiation to see the impacts 
> based on RTT.  Even at 50ms it should be perceivable (since you get at 
> least 2x the delay, plus overhead).  Also make sure your camera isn't 
> running at 5 or 10fps in a dark room. :-)

In http://jsfiddle.net/7vxzbybp set:

|var additionalSignalingDelayMs = 200;

||(|Don't forget to hit "Run" so you're running what you've changed).

I don't understand why this is unacceptable for a codec corner-case.

.: Jan-Ivar :.
Received on Tuesday, 2 June 2015 00:54:55 UTC

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