Re: [MMUSIC] Updated MSID draft

[Harald Alvestrand <[e-mail]>]

Thanks for the review!

Not addressing the whole thing, but just one:

On 11/01/2013 02:29 PM, Magnus Westerlund wrote:
> 3. Section 4:
>
> I don't know if this is the right place for it or where it should go.
> But applying MSID to WebRTC one runs into the question of how one needs
> to deal with none source packet streams, i.e. Packet Streams that do not
> carry the primary source encoding. Such streams that are redundancy
> streams, like RTP retransmission streams, FEC streams, as well as if one
> would use scalable encoding and have packet streams that are dependent.
>
> How should these be marked using MSID? As being part of the related
> MediaStreamTrack? OR should we use something that isn't dependent on the
> WMS semantics, SRCNAME, APPID or other?
If I ignore your advice to move msid back from being a media-level
attribute to being a stream-level attribute, Unified Plan makes that simple:

All packet streams that form part of a MediaStreamTrack are signalled as
part of the same m-line, so the MSID applies to all of them. Marking for
simulcast is entirely independent of MSID; MSID just identifies the
MediaStreamTrack and MediaStream, it does not help in parsing the
components of a MediaStreamTrack.

The one case where this gets into trouble is a FEC stream that applies
to multiple SSRCs; this is the same case (and the same issue) as the one
where you might want to use the same a=ssrc attribute in multiple m-lines.

Either we can define how that is done, or we can define that this is
impossible in Unified Plan. Some issues may not be worth solving.


-- 
Surveillance is pervasive. Go Dark.