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

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.)

I think we have to pick one.

Received on Tuesday, 14 April 2015 18:19:42 UTC