Re: Summary of replace track status

On 30/05/15 06:51, 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
>>> <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.

Nice test. Having tested (also being on the same LAN) I agree, there is 
no big difference. But I don't know what to conclude from that really, is it

* we should allow replaceTrack to work even if a renegotiation is needed
or
* we don't really need replaceTrack in 1.0 - you can accomplish (almost) 
the same thing using add/removeTrack

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

This is an interesting idea, but personally I hesitate on adding 
functionality for 1.0. Also, could there be difficult corner cases such 
as the p2p connection breaking down in the middle of a offer/answer 
exchange meaning you'd have to exchange candidates out of band to 
re-establish the connection?

>
> .: Jan-Ivar :.
>

Received on Saturday, 30 May 2015 05:29:37 UTC