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

On 7/3/13 1:06 AM, Mo Zanaty (mzanaty) wrote:
> To clarify, I have no plan to use or abuse Plan A. The implementations I'm most interested in are all closer to Plan B. However, I'm aware of widely deployed implementations (from other vendors) which are closer to Plan A in general, and specifically for the thumbnail example below (one m-line per thumbnail, all with the same port/PT). While I personally would not chose this, I see no reason to forbid it, because I recognize it is just personal preference.

Since there currently is no BUNDLE, I don't know how you can say an 
implementation is closer to any of the plans. Instead, you can only 
hypothesize on how such an application might use any of the bundling 
schemes if it became available.

	Thanks,
	Paul

> Mo
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Tuesday, July 02, 2013 6:40 PM
> To: Mo Zanaty (mzanaty)
> Cc: Christer Holmberg; mmusic@ietf.org
> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>
> On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote:
>>> 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.
>
> So you want to use plan A *without* the association, so that the *only*
> purpose of the extra m-lines is to denote the number of flows?
>
> How would the receiver know if an incoming packet was associated with
> one of the flows defined by the m-lines?
>
> How would the receiver know if each ssrc should be treated as a
> different flow, or if appid should be used to define flows?
>
> I think you abuse plan A. Its different with plan B or No Plan. There
> you still need the ability to associate packets to m-lines, but that
> isn't sufficient to map them to flows. It is assumed that "extra"
> information, learned by different means, is used to sort out the flows.
>
> 	Thanks,
> 	Paul
>
>> Mo
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Tuesday, July 02, 2013 4:00 PM
>> To: Christer Holmberg
>> Cc: Mo Zanaty (mzanaty); mmusic@ietf.org
>> 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ä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty)
>>> Lähetetty: 2. heinäkuuta 2013 19:09
>>> Vastaanottaja: Paul Kyzivat
>>> Kopio: mmusic@ietf.org
>>> 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:pkyzivat@alum.mit.edu]
>>> Sent: Tuesday, July 02, 2013 10:06 AM
>>> To: Mo Zanaty (mzanaty)
>>> Cc: mmusic@ietf.org
>>> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: Saturday, June 29, 2013 12:12 PM
>>>> To: mmusic@ietf.org
>>>> 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
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>
>