Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

On 14/04/15 20:22, Harald Alvestrand wrote:
> Contributor hat on....
>
> I'm worried about the idea that tracks have IDs that vary over time, and
> that the change in the ID is not correlated with the change in content.
>
> In particular, the scenario (-> = signalling)
>
> A -> B: I send video track with id X
> B -> A: OK, I can receive
> B gets a video track with id X
>
> A sends the content of X
>
> A decides to send the content of Y instead, and does ReplaceTrack
>
> B receives the content of Y, but associates it with id X
>
> At some later time, A decides that negotiation is needed:
>
> A -> B: I send video track with id Y (where X was before)
> B -> A: OK, I can receive
>
> What happens next?
>
> Either of these is a self-consistent description, but they're mutually
> exclusive:
>
> - B simply never updates the ID of the track. X is a perfectly valid
> identifier, and if A wants to talk about it, A can take on the task of
> remembering that it has to say "X" when talking to B about this video,
> even though its local track has id Y. (This is the simplest solution. I
> like simple.)
>
> - B updates the ID of the track when signalling happens. A has to
> remember that it must use X when talking about the track before
> signalling, and Y afterwards. (I think this is what Jan-Ivar's pull
> requests state now).
>
> - B takes the signalling as an indication that track X has stopped and
> track Y (a new track) has started. It has actually been receiving
> Y-content on track X for a while, but has no way of knowing that, so it
> has to tear down the X-association and establish the Y-association
> (perhaps replacing the track in its MediaStream, so that it remains
> connected to the same <video> or other sink?) (this is the most
> convoluted. I don't like convoluted.)


We have briefly been talking about this before, and at that time ended 
up (IIRC) at a model that is very similar to the first of your three 
proposals. The only difference was that the Id presented at the remote 
end was something the sending app could modify on the RTPSender object. 
It would be initialized to the Id of the track used with pc.addTrack, 
but (as said) be possible for the sending app to modify.

The notion is that the sending app decides the Id at the remote end 
which sort of makes sense since the PeerConnection + the sending app is 
the source.

I'm not sure there is really a use case for allowing the sending app to 
modify the Id, perhaps it could be set to the Id of the track added with 
addTrack and never modified.

>
> I think we have to pick one.

I think the first proposal is the most straightforward one.

>
>
>

Received on Tuesday, 14 April 2015 19:04:24 UTC