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

[Harald Alvestrand <[e-mail]>]

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.

>
> 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.
>>
>>
>>