Re: Summary of replace track status

On 5/29/15 4:28 PM, Stefan Håkansson LK wrote:
> On 29/05/15 18:17, Martin Thomson wrote:
>> On 29 May 2015 at 05:55, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> I think you are right, and it also seems (based on feedback from others)
>>> that replaceTrack should work even if a renegotiation is required.
>> That's not what I got from Cullen's comment.  His point was that
>> replacing should work from any state.  Your statement here leads me to
>> infer that replaceTrack can cause renegotiation.  That's what
>> addTrack/removeTrack are for.
> I did not get that from Cullen's comment either. I got that from
> Harald's [1], Ekr's [2] and Jan-Ivar's [3] (but I'm not sure I interpret
> this one correct) comments (it is also how Jan-Ivar's PR [4] is designed
> if IIUC).
>
> OTOH, Peter [5] and Jan-Ivar in another message [6] said that
> replaceTrack should never lead to renegotiation (but instead fail), so
> it is not really clear what is the preferred model.

I flip-flopped. For several reasons, but mostly because I tried 
renegotiation over a data-channel.

Here's a fiddle (Firefox-specific, sorry!): http://jsfiddle.net/7vxzbybp

Some instructions:

 1. With no server (it's a fiddle!), press the |Offer| button and copy
    the offer.
 2. (It can take 20 seconds for all candidates on Windows, zero on Mac,
    go figure)
 3. Paste to the same spot in the same fiddle in another tab or on
    another machine.
 4. Press ENTER, then copy the answer you get and paste that back in the
    first fiddle.
 5. ENTER again and you should be connected with chat and signaling
    data-channels.
 6. Press |addTrack| in one and video should appear instantly in the other.
 7. Press |addTrack| in the other, and you should have video both ways.


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.

Still, there's no perceivable difference in the time it takes, which is 
enough to convince me that in the corner-case where codecs differ, POLA 
is split-second flicker, not failure.

I'm also wondering why we don't add |pc||.turnOnAutoRenegotiation();| to 
do renegotiation over a data-channel automatically with zero JS involvement.

.: Jan-Ivar :.