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

[Paul Kyzivat <[e-mail]>]

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:[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
>>
>
>