Re: Summary of replace track status

On 6/1/15 10:19 AM, Stefan Håkansson LK wrote:
> On 30/05/15 22:27, Martin Thomson wrote:
>> On 30 May 2015 at 12:26, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>>> I'm arguing it's good enough for replaceTrack to flicker when I
>>> unplug/transition off my on-chip H.265 encoding USB camera to the built-in
>>> one.
>> I'm not sure what you think is happening here.  The concern is the
>> atomicity of the update, in all its aspects.  You can negotiate a new,
>> bundled track and have a single instant in time where that applies
>> (setRemoteDescription most likely).  That can almost be fast enough to
>> not matter (a round trip to JS, all going well).
>>
>> But the sender is never the concern.  It's the coordination of the
>> transition at the receiver that hurts.

However complicated renegotiation is seems irrelevant to me since we 
already have it. All we're discussing is whether replaceTrack should 
fire onnegotiationneeded on non-negotiated codecs, or fail and have the 
user remember to cover this POLA-violating corner-case *by detecting 
this specific error (by name?) and react by calling 
pc.onnegotiationneeded() themselves*, because I've not heard anyone 
suggest "forget it then" as a desirable outcome. More likely, different 
codecs just wont work by coding omission.

> I agree, and if replaceTrack (initially at least) was specced to only
> work if the UA could simply replace the content of existing outgoing RTP
> stream(s) - SSRC and all being the same - would feel the simplest

Simplest for whom? Browser implementers, spec writers, or users? 
Assuming no users want it to fail, then it seems simpler (to the user) 
for us to "just do it" (even in the hard corner-case).

More importantly, IMHO, if the Sender/Receiver API is to outlive 
renegotiation, then it needs to absorb it, not operate within its limits.

.: Jan-Ivar :.

Received on Tuesday, 2 June 2015 02:40:21 UTC