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

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.

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.

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.

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

Received on Tuesday, 14 April 2015 19:25:48 UTC