Subject: Re: [MMUSIC] MSID and mapping to tracks and streams

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Jan 2015 17:43:38 -0800

On 12/11/2014 10:50 AM, Martin Thomson wrote:
>    The value of the "identifier" field in the msid consists of the "id"
>    attribute of a MediaStream, as defined in its WebIDL specification.
>
>    The value of the "appdata" field in the msid consists of the "id"
>    attribute of a MediaStreamTrack, as defined in its WebIDL
>    specification.
>
> I think that this is backwards. The media section (m=) corresponds to
> a track, not a stream.  The MediaStream is the secondary identifier.

Yes, it's backwards, but only in the sense of being right-to-left rather
than left-to-right (I think).
The stream is the identifier that has to be carried using MSID. The
track is auxillary information, one could make things work without
specifying it at all (whatever comes in a media section belongs to the
stream), so the only purpose is carrying the track ID.

(note: the spec intentionally doesn't disallow this:

m=
a=msid: aaa bbb
a=msid: ccc ddd

This would, I think, mean that the media section is intended to cause
two tracks to appear on the receiver side, one in stream aaa and the
other in stream ccc. I'm not quite sure when that would be useful, however.)

>
> I'd have thought that this was merely personal bias, until I read this:
>
>    The identifier is a string of ASCII characters that are legal in a
>    "token", consisting of between 1 and 64 characters.  It MUST be
>    unique among the identifier values used in the same SDP session.  It
>    is RECOMMENDED that it is generated using a random-number generator.
>
> This rule, as specified and in combination with the aforementioned,
> would absolutely prevent the use of multiple tracks from the same
> stream (i.e., the most common case in existence).

The meaning of "unique" is that all streams have to have different IDs,
not that all msid lines have to have different stream IDs.
Is there a way in which we could reword this?

>
> Also, this is mightly confusing to me:
>
>    [...]  Once negotiation has completed on a
>    session, there is no memory apart from the currently valid SDP
>    descriptions; an msid "identifier" value that appears in a later
>    negotiation will be taken to refer to a new MediaStream.
>
> I have no idea what this might be saying.  I can imagine a whole lot
> of things that might be said here: "a track (not stream) that is bound
> to a given media section is unaffected by changes in the msid values
> in that media section during renegotiation" or "a track on the sending
> side that is bound to a media section, then subsequently swapped out
> (see replaceTrack) for another, MAY cause the msid values to change in
> subsequent renegotiations, but this does not result in action from the
> receiving side".

This was added in response to the question "what happens if I send SDP
with msid AA BB, then send SDP without msid AA BB, and then send SDP
with AA BB again" - the alternatives were that either the third SDP
"resurrected" the old stream (which would then not have ended at all,
and the recipient would have to remember that it had existed forever
just in case this happened), or the third SDP would create a new stream
in a new onaddstream event.

Now that the concept of streams ending is gone, the signalling of tracks
is done using an addtrack event with a stream parameter rather than an
addstream event, the pictcure might look different - the same stream
object could be used if it hadn't been garbage collected, or something
like that.
(I still wouldn't want old streams to hang around forever when all
references to them were lost, though.)

replaceTrack .. that isn't even in the spec yet. I think I know what
it's intended to do, and the likely-sounding signalling result would be
to change the msid from AAA BBB to AAA CCC (new track, same stream),
resulting in a removetrack and an anddtdrack event being fired on the
recipient's side.
But I don't feel that replaceTrack is stable in my perception of it yet.

>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Surveillance is pervasive. Go Dark.