Re: replaceTrack proposal

On 9/3/14 2:39 PM, Martin Thomson wrote:
> I think that I like replace, mainly because this is an operation that
> can fail.  If the source is a camera that produces a different codec,
> then it is going to fail.
>
> Rather than trigger onnegotiationneeded, I think we should make this a
> silent operation that only succeeds for compatible tracks.

I think that aligns best with the purpose of the API being to avoid 
negotiationneeded.

>> 2.  Why would it matter at all what MediaStream the track is in?  I
>> don't see why it would matter.  And for that matter, when would you
>> have two video tracks in a MediaStream in the first place?  What does
>> that even mean?
> The definition of compatible tracks probably doesn't need to be
> limited to tracks in the same stream.  Though the potential for the
> tracks to be synchronized seems best, since if we aren't sending any
> other signals, a disjoint time sequence would cause errors.

I guess mediaStreams were meant to be a structural indication of "these 
things are (meant to be?) synchronized", while in reality, as I 
understand it, timestamps are tied to capture sender-side, and synced up 
receiver-side.

.: Jan-Ivar :.