Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

["Mo Zanaty (mzanaty)" <[e-mail]>]

> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever.

It seems you both want to mandate this (Plan B). Why? I see no reason for bundle to pick a plan. Let the plan wars rage outside bundle.

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: Tuesday, July 02, 2013 4:00 PM
To: Christer Holmberg
Cc: Mo Zanaty (mzanaty); [e-mail]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

+1
(Except that I *am* Paul)

On 7/2/13 2:30 PM, Christer Holmberg wrote:
> Hi,
>
> I am not Paul, but just to verify that I understand his issue, the question is:
>
> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line?
>
> Regards,
>
> Christer
>
> -----Alkuperäinen viesti-----
> Lähettäjä: [e-mail] [mailto:[e-mail]] Puolesta Mo Zanaty (mzanaty)
> Lähetetty: 2. heinäkuuta 2013 19:09
> Vastaanottaja: Paul Kyzivat
> Kopio: [e-mail]
> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>
> An attempt at "an answer that makes sense". (Just snippets, not full SDP.)
>
> m=video 10000 RTP/SAVPF 96
> a=rtpmap:96 H264/90000
> a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker
>
> m=video 10000 RTP/SAVPF 97
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>
> m=video 10000 RTP/SAVPF 97
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>
> m=video 10000 RTP/SAVPF 97
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>
> m=video 10000 RTP/SAVPF 97
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>
> No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker).
>
> You could mandate that PT must be unique to allow unique mapping.
>
> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever.
>
> Which do you want to mandate and why?
>
> Cheers,
> Mo
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Tuesday, July 02, 2013 10:06 AM
> To: Mo Zanaty (mzanaty)
> Cc: [e-mail]
> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>
> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote:
>> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology?
>>
>> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan.
>
> I'm going to keep asking this question until I get an answer that makes
> sense:
>
> Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line.
>
> The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping.
> If the answerer isn't capable of doing the same mapping, then the use of plan A has failed.
>
> The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping.
>
> 	Thanks,
> 	Paul
>
>> Mo
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Paul Kyzivat
>> Sent: Saturday, June 29, 2013 12:12 PM
>> To: [e-mail]
>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>>
>> On 6/29/13 8:50 AM, Colin Perkins wrote:
>>> Christer,
>>>
>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
>>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed.
>>>>
>>>> We haven't had that much discussion about it yet, so I will not ask
>>>> a DECISION question at this point, but I would really like to get
>>>> some input from people who have opinions about this :)
>>>
>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care.
>>
>> I just replied elsewhere on this.
>> My opinion turns out to be the exact opposite of yours: we need to
>> support multiple algorithms, and that all applications should care.
>>
>> I won't repeat the stuff about multiple algorithms.
>>
>> I will repeat what I have said about the need for being able to associate:
>>
>> There must have been *some* reason that two m-lines were used, rather
>> than just one. Each m-line heads a media section of the SDP that
>> contains a bunch of declarations. Something must be different in those
>> two media sections, or else a single media section would have been
>> enough. Presumably whatever it is that is different is intended to
>> affect how received packets are processed or interpreted. (If not,
>> again there is no need for it to be there.) If you can't associate the
>> packet with the m-line, then you don't know which of the multiple
>> interpretations to apply to the packet.
>>
>> Maybe there is some exception to this, though I haven't come up with
>> anything. If there is, then I hope someone will call it out. If so,
>> then the constraint can be tightened.
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>