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

Re: Summary of replace track status

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 29 May 2015 23:01:56 -0700
Message-ID: <CAJrXDUGx1yu7R2t0Pp+pC4h-n4yXfsPUYZnbbGoQmkGJhfDSfQ@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
 On Fri, May 29, 2015 at 9:51 PM, Jan-Ivar Bruaroey <jib@mozilla.com> 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<stefan.lk.hakansson@ericsson.com> <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 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.

​And
 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

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