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

On 04/14/2015 09:25 PM, Martin Thomson wrote:
> On 14 April 2015 at 11:19, Harald Alvestrand <harald@alvestrand.no> wrote:
>>   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.
> I worry about this too.
>
> I have a different proposal.
>
> 1. MediaStreamTrack.id is chosen by the receiving browser.  Period.
> This whole mess with identifiers is moved to RTCRtpSender/Receiver.
> It becomes a WebRTC wart, not a problem for all MediaStream users.
I don't think this is either necessary or sufficient..... (and 
currently, there is no way to choose an ID for a track - the value is 
always constructed by the platform).

Just reiterating what I percieve as the original purpose of having IDs 
on these items:
To let Javascript applications talk to each other about the tracks.

That is:

A sends X and Y to B

A sends (data channel, via web server, whatever) to B, something like:
{'display_map: { 'X': 'left', 'Y: 'right' }}

B displays X to the left and Y to the right.

If tracks have IDs that are consistent over the connection, this can be 
done by an application without referring to any property of the 
PeerConnection whatsoever; it just looks at the tracks.

I'd like that property to remain - it's not necessary, because the 
receiver could look up the RTPReceiver for the track and get the 
identifier value from there, but it makes life easier in the simple case.

>
> 2. The id on the RTCRtpSender is primed with the track identifier.
> This is what gets put in the signaling (a=msid).  But this value can
> be changed by the app as long as the syntax constraints for the
> signaling are met.
>
> 3.  The id on the RTCRtpReceiver is set during setRemoteDescription to
> whatever the signaling says.  It can be mutable too.  There are no
> uniqueness constraints,
>
> The only catch here is being able to tell - at the signaling level -
> at the receiver end whether the sender of a given track has created a
> new track or not.  And therefore whether to use the existing
> RTCRtpReceiver, or whether to create a new one.  Otherwise, the
> difference between replaceTrack (which keeps RTCRtpSender in place)
> and removeTrack+addTrack (which creates a different RTCRtpSender) is
> undetectable.

Under this scenario, one could say "receiver: obey signalling".
That is - if the a=msid value changes, this is treated as a new track.
If it doesn't change, this is treated as an old track.

>
> 4. The idea that was proposed was to detect the change based on a
> difference in a=ssrc values.  New tracks will have new SSRCs.

That's messy in a simulcast / layered scenario (which is out of scope 
for 1.0, but we all know it's coming).

SSRCs come and go.


>
> This is perhaps more convoluted than any of your suggestions, but it
> does address the concern that you didn't cover (unless that was
> intentional).
>
It also offers plenty of opportunity to write confusing stuff, but 
that's nothing new.....

Received on Wednesday, 15 April 2015 07:02:14 UTC