Re: [MMUSIC] Relation between SRCNAME and MSID

["Roni Even" <[e-mail]>]

Hi,
I had the same question when looking at mapping RTP streams to CLUE media
capture and after trying to address simulcast in that environment it looked
to me that srcname can be used for mapping since if we look at hierarchy of
CNAME.srcname we can say that if we have an endpoint that have multiple
media sources (e.g. 3 cameras) this can be reflected using the same CNAME
with srcnames V1,V2 and V3. 
If using srcname for the simulcast case it make sense not to have a
different identifier for the non simulcast case.

Roni Even  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Magnus Westerlund
Sent: 06 November, 2012 8:01 AM
To: mmusic (E-mail)
Subject: [MMUSIC] Relation between SRCNAME and MSID

Hi,

I got to reading the MSID this morning and as it was some questions how
SRCNMANE (draft-westerlund-avtext-rtcp-sdes-srcname-02) relates to MSID
(draft-alvestrand-mmusic-msid-01) I will give my view on this.

So SRCNAME is a hierarchical structure who's root is a media stream source,
i.e. a camera or a microphone. Its primary usage is to bind SSRCs that are
all related to that media source together. A simple example would be if one
produced simulcast, i.e. alternative encodings, of the same media source V1,
you can have a source name that is V1.enc1 for the first encoding, V2.enc2
for the second one, and so on. When you apply RTP retransmission or FEC you
do that to a particular SSRC, which then is one of the encodings. Or even
more complex if an encoding is an SVC MST stream, then you have several
streams in different RTP sessions for the different layers, and your FEC or
retransmissions only applies to one of these substreams. Thus you can have a
SSRC that carries a SRCNAME of V1.enc1.baselayer and use that label for both
the media stream and on the FEC SSRC to tie them together. So SRCNAME shares
a property with MSID that is that is ties SSRCs both within and across RTP
Sessions together.

So MSID, especially in its usage with WebRTC to create the WebRTC
MediaStream actually have an interesting relation to SRCNAMES. As MSID are
application level groupings of particular mediaStreamTracks, a MSID can be
used to tie in RTP media stream and its related SSRCs (the ones carrying the
FEC or the layers) into a MediaStream object. Lets try an simple example to
illustrate.

A WebRTC end-point has one video camera (V1) and one microphone (A1).
The video is to be provided at two different encodings V1.enc1 and
V1.enc2 in SRCNAME terms. But for a WebRTC application it can actually
select to deal with these two encodings as two different WebRTC MediaStreams
which I will give MSID values Var1 and Var2, where the variants contain one
video encoding and the audio

In SDP using a=ssrc to provide the SRCNAME it would look like this


m=video
a=ssrc: 1111 SRCNAME:V1.enc1
a=ssrc: 1111 msid:Var1 v1
a=ssrc: 2222 SRCNAME:V1.enc2
a=ssrc: 2222 msid:Var2 v1

a=audio
a=ssrc: 3333 SRCNAME:A1
a=ssrc: 3333 msid:Var1 a1
a=ssrc: 3333 msid:Var2 a1

In other words a given SSRC might actually be a MediaStreamTrack in multiple
MediaStreams and thus have multiple MSIDs. While a SSRC will only have one
SRCNAME, but that one may specify to a higher detail.

If we would have RTP retransmission in the above, a question around MSID
arises. Should all SSRCs that are part of representing be given a MSID or
would it be simpler to just label the media entry point to the hierarchical
relations SRCNAME is capable of expressing? And I need to point out that
MSID can't replace the SRCNAME as currently defined as it doesn't make clear
the hierarchical relation of the SSRCs.

If you are interested in discussion SRCNAME please show up in AVTEXT on
Wednesday at 1300-1430.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic