Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?

["Stach, Thomas" <[e-mail]>]

inline

> -----Ursprüngliche Nachricht-----
> Von: Harald Alvestrand [mailto:[e-mail]] 
> Gesendet: Donnerstag, 11. Oktober 2012 17:16
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: AW: AW: How does mmt grouping work with multiple 
> streams of the same type?
> 
> On 10/11/2012 04:55 PM, Stach, Thomas wrote:
> > inline
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Harald Alvestrand [mailto:[e-mail]]
> >> Gesendet: Donnerstag, 11. Oktober 2012 16:45
> >> An: Stach, Thomas
> >> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >> Betreff: Re: AW: How does mmt grouping work with multiple
> >> streams of the same type?
> >>
> >> On 10/11/2012 04:13 PM, Stach, Thomas wrote:
> >>> Harald,
> >>>
> >>> thanks for the reply.
> >>> It helps for my second question, but not for my main question.
> >>> How can the answerer recognize (from the m=anymedia line
> >> alone) that multiple video streams need to be set up in the
> >> same RTP session?
> >> If each video stream is signalled by the presence of 
> SSRC-associated
> >> signalling for that video stream, you count the number of
> >> video streams signalled.
> > Could that be done by e.g. enhancing the new a=mmtype with 
> an ssrc element?
> > E.g.
> >
> >         a=mmtype: 0 audio ssrc=1
> >         a=mmtype: 8 audio ssrc=1
> >         a=mmtype: 97 audio ssrc=2
> >         a=mmtype: 31 video ssrc=3
> >         a=mmtype: 32 video ssrc=4
> >
> > would mean 2 audio streams and 2 video streams, whereas
> >
> >         a=mmtype: 0 audio ssrc=1
> >         a=mmtype: 8 audio ssrc=1
> >         a=mmtype: 97 audio ssrc=1
> >         a=mmtype: 31 video ssrc=2
> >         a=mmtype: 32 video ssrc=2
> >
> > means 1 audio and 1 video stream based on the number of 
> different SSRCs?
> 
> On the principle of "don't invent new stuff if you already 
> have stuff", 
> I think we should continue to use RFC 5576 for this purpose:
> 
> a=ssrc:1 <something follows>

I haven't thought about that, but yes it would work for as well.
For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it would look like this? 

   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:97 iLBC/8000
   a=mmtype: 0 audio 
   a=mmtype: 8 audio 
   a=mmtype: 97 audio
   a=ssrc:12345 fmtp:0 
   a=ssrc:12345 fmtp:8 
   a=ssrc:67890 fmtp:97 


> 
> The suggestion above wouldn't work for the case of two SSRCs 
> both using the same payload type.
Well it would if you duplicated the a=mmtype attribute with different ssrc elements in that case.
     a=mmtype: 0 audio ssrc=1
     a=mmtype: 0 audio ssrc=2
Would you do something else for a=ssrc?



Regards
Thomas


> 
> >
> >>> Regards
> >>> Thomas
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Harald Alvestrand [mailto:[e-mail]]
> >>>> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> >>>> An: Stach, Thomas
> >>>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >>>> Betreff: Re: How does mmt grouping work with multiple streams
> >>>> of the same type?
> >>>>
> >>>> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> >>>>> Christer, Harald, Jonathan,
> >>>>>
> >>>>> I have the impression that the
> >>>> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
> >>>> Jonathan's proposal
> >>>>> to have an explicit desrciption for the bundled streams as
> >>>> proposed in
> >>>>> 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >>>>>
> >>>>> Among other points the following is stated:
> >>>>> * The m=bundle is a complete description of an entirely
> >>>> separate m-line; if it's used, the other m-lines in the group
> >>>> are rejected and the information they carry is ignored.
> >>>>> I think this a desirable property
> >>>>>
> >>>>> Now, consider a case were you have 4 streams, i.e. 4
> >>>> m-lines (e.g. 2 audio and 2 video).
> >>>>> How would that be mapped to the m=anymedia line?
> >>>>> How does mmt grouping work with multiple streams of the 
> same type?
> >>>>>
> >>>>>    From the currently proposed syntax for the m=anymedia line
> >>>> I cannot deduce that multiple audio or video streams are offered.
> >>>>> I would have to look into the "legacy" m-lines to 
> recognize this.
> >>>>> In case that e.g. the video stream use different codecs, I
> >>>> could also learn that only from the legacy m-lines.
> >>>>
> >>>> In the case where it's desirable to carry multiple video
> >>>> streams in one
> >>>> RTP session, and have different descriptions in SDP for
> >> the different
> >>>> video streams, there has to be some signalling that tells the
> >>>> recipient
> >>>> which description applies to which video stream.
> >>>>
> >>>> The video streams will have different SSRCSs. Therefore, the only
> >>>> reasonable answer in the MMT grouping case seems to be
> >>>> SSRC-associated
> >>>> signalling.
> >>>>
> >>>> In the other variants, it's actually unclear to me how the
> >>>> video streams
> >>>> described by the different m= lines would be detected by the
> >>>> recipients;
> >>>> I'd been assuming SSRC-associated signalling for other
> >>>> reasons, so only
> >>>> when this discussion resurfaced, I started thinking about
> >> this again,
> >>>> and discovered that I didn't have an answer.
> >>>>
> >>>> That is, in the description
> >>>>
> >>>> a=group:bundle foo bar baz
> >>>> m=video 4270
> >>>> a=mid:foo
> >>>> a=property-x:1
> >>>> m=video
> >>>> a=mid:bar
> >>>> a=property-x:2
> >>>> m=video
> >>>> a=mid:baz
> >>>> a=property-x:3
> >>>>
> >>>> one would expect a single RTP stream to be set up; when
> >> the recipient
> >>>> gets 3 video streams with SSRCS 234, 235 and 236, how does he
> >>>> know which
> >>>> stream should have which value for "property-x"?
> >>>> One can solve it with SSRC-associated signalling in this 
> case too:
> >>>>
> >>>> a=ssrc:234 property-x:1
> >>>>
> >>>> but then you're back to doing SSRC-associated signalling, and
> >>>> if you're
> >>>> already doing that, we're not very different from the MMT
> >> description
> >>>> anyway.
> >>>>
> >>>> That's how I think of it at the moment, anyway - YMMV.
> >>>>
> >>>>
> >>>>
> 
>