Re: Summary of replace track status

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 :.