Re: Summary of replace track status

 On Fri, May 29, 2015 at 9:51 PM, Jan-Ivar Bruaroey <> wrote:

>  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<> <> 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!):
> 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 don't consider this a realistic test.  You're basically assuming that
signalling RTT is near-0.  I think you'd have to retry with a realistic
signalling RTT.

 if you can still see flicker with near-0 RTT,
​I think it's a failure.

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

​A library can already do that.

> .: Jan-Ivar :.

Received on Saturday, 30 May 2015 06:03:05 UTC