Re: Summary of replace track status

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.

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 (of 
course a full ref frame must be coded for the first frame of the new track).

Personally I think that would be the best approach for 1.0; the 
application can always resort to add/removeTrack (and perhaps mute / 
unmute events are a good indication at the remote side on when to switch 
video that is displayed?) if replaceTrack fails.





Received on Monday, 1 June 2015 14:20:21 UTC