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

I was thinking about this whole MediaStreamTrack.id thing from scratch
today, and the the design I came up with is very similar to what you are
proposing here.  I like your proposal.  I'd like to propose we go one step
further.  If we model .addTrack after .createDataChannel a little and add a
"label" argument we could have this:

1.  The sending app calls addTrack like so:  var sender1 =
pc.addTrack("label1", track1);   Then, RtpSender has a readonly,
unchangable .label.

This is like your #2, except that instead of calling pc.addTrack() and then
sender.setId() before calling pc.createOffer(), it's done in one call.
 And the .label is fixed, not mutable.

2.  The sending browser puts the label in the SDP.  The receiving app calls
.setRemoteDescription and the receiving browser fires .ontrack.  The
RtpReceiver given has the .label from the SDP, which is fixed, not mutable.

This is like your #3, except I think it simplifies things to make the
.label immutable, must like for data channels.  I don't really see any use
case for it being mutable.

3.  The MediaStreamTrack.id that comes from the receiving side's .ontrack
is irrelevant.

This is like your #1.

4.  Calling .addTrack with the same label more than once gives an error.
It's not allowed.  This is a little different than data channels, but
solves the case of how to differentiate between removeTrack+addTrack vs.
replaceTrack in a simple way that doesn't require messing with SSRCs.

This is an alternative solution to your #4.

5.  We don't use "MSID" in the SDP.  Since at this point we are labelling
RtpSenders and not tracks, it doesn't make sense to call it "MSID" any
more.  In fact, we already have an ID in the SDP that identifies an
RtpSender:  MID.  I suggest we simply use that.   If it's immutable and
can't be reused, I don't see any reason not to use it, other than the
question of whether we can reuse m-line positions/indexes with different
MIDs.  If we can't, we might have a problem if we're adding and removing
lots of tracks because positions/indexes would get "used up".


Here's a little IDL for my proposal:

partial intrerface RTCPeerConnection {
  RTCRtpSender addTrack(DOMString label, MedaiStreamTrack track);
}

partial inteface RTCRtpSender {
  readonly attribute DOMString label;
}

partial inteface RTCRtpReceiver {
  readonly attribute DOMString label;
}



There just one issue I'm not sure what to do about:  if we use MID instead
of MSID, how do we signal the synchronization groups (ie the MediaStreams
the MediaStreamTracks are supposed to go in).



On Tue, Apr 14, 2015 at 12:25 PM, Martin Thomson <martin.thomson@gmail.com>
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.
>
> 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).
>
>