- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 29 May 2015 23:01:56 -0700
- 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>
- Message-ID: <CAJrXDUGx1yu7R2t0Pp+pC4h-n4yXfsPUYZnbbGoQmkGJhfDSfQ@mail.gmail.com>
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