Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]

[Jonathan Lennox <[e-mail]>]

On Oct 30, 2013, at 4:11 AM, Christer Holmberg <[e-mail]>
 wrote:

> Hi Jonathan,
> 
>> This works as an outline, but I'm afraid it'll be too vague for solid interoperability.
> 
> At the end of the day, it is the receiver that informs the remote party which PT values it wants to receive, so if it chooses the same PT values it has to know that it is able to handle it.
> 
> We COULD go even more into detail, but then I'm afraid we would have to start defining codec specific criteria etc, and I don't think we should go that way.

I don't want codec-specific criteria -- but I do want to know, e.g., whether PT-specific a=rtcp-fb: attributes MUST be aligned across bundled m-lines, or if they're free to vary, or what.

There are a bunch of SDP attributes that have PT-scoped properties.  I think this analysis needs to be added to the mux-attributes draft.

> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> I think it works as a set of principles to guide discussion of PT-specific definitions in the mux-attributes draft, though.
> 
> On Oct 27, 2013, at 5:03 PM, Christer Holmberg <[e-mail]>
> wrote:
> 
>> This time in non-HTML format.
>> 
>> Lähettäjä: Christer Holmberg
>> Lähetetty: 27. lokakuuta 2013 23:03
>> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value 
>> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for 
>> single codec configuration)]
>> 
>> Hi,
>> 
>> It would be really great if those who have an opinion on this would 
>> indicate whether they are ok with the approach below. Then we can 
>> focus on where to document it :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> Lähettäjä: [e-mail] [mailto:[e-mail]] 
>> Puolesta Christer Holmberg
>> Lähetetty: 23. lokakuuta 2013 13:37
>> Vastaanottaja: Bo Burman; Jonathan Lennox
>> Kopio: mmusic
>> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage 
>> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec 
>> configuration)]
>> 
>> Hi,
>> 
>> Below is a copy of the current text in my Vancouver slide regarding the criteria for PT value re-usage in multiple m- lines within a BUNDLE group.
>> 
>> It is based on the ideas provided by Jonathan L and Bo B.
>> 
>> As you can see, apart from the rtpmap and fmtp attributes, it is not possible to define an exclusive list of attributes that must be identical. Such lists may also be codec dependent. Instead, the text talks more generally about memory and buffer sizes.
>> 
>> 
>>> REQUIREMENTS
>> - Decoder agnostic
>>> It shall be possible to switch decoders between media flows using the 
>>> same PT value
>> - Codec agnostic
>>> The criteria shall be applicable to any codec CRITERIA
>> - SDP rtpmap and fmtp attribute values must be equal (order of 
>> attribute parameters not significant)
>>> All parameters must be included
>> - Explictily
>> - Implicitly, if a default value is defined for the parameter
>>> Parameters not included are assigned their default values (if 
>>> defined)
>> - Decoder maximum memory and buffer sizes shall be assumed to match
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Christer Holmberg
>> Sent: 16. lokakuuta 2013 12:12
>> To: Bo Burman; Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT 
>> value for single codec configuration
>> 
>> Hi Bo,
>> 
>> Thanks for your input!
>> 
>> I'd ask anyone who might have an opinion about this to take a look at 
>> the proposal, comment on the list if needed, and hopefully we can 
>> agree on way forward in Vancouver (or, even earlier :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> From: Bo Burman
>> Sent: 16. lokakuuta 2013 11:44
>> To: Christer Holmberg; Jonathan Lennox
>> Cc: mmusic
>> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT 
>> value for single codec configuration
>> 
>> Hi,
>> 
>> I agree with Jonathan that in order to make two PT values "equal", their rtpmap and fmtp lines must be equal, as a start.
>> 
>> I don't think there is any "correct" criterion that can be used to judge PT for equality, but we just have to decide on a "reasonable" one that is as simple as possible without causing any major problems.
>> 
>> I have assumed a conceptual equality criterion where PT value A should be considered equal to another PT value B if an RTP stream with PT A can be fed into a decoder stack configured with PT B, and vice versa, without causing either decoder stack to "break".
>> 
>> I don't think we should require the fmtp lines are textually equal, but only that the same parameters are present and have the same values. The order of the parameters on the fmtp line does not matter. There is also the case when a parameter is specified with the default value for one PT and omitted for the other. To identify those as equal, which they semantically are, would require an "equality parser" to know every default value of every fmtp parameter for all codecs. This seems unreasonable.
>> 
>> Regarding Jonathan's question on H.264 sprop-., I guess they don't strictly need to be equal to make the PTs equal, but they may have to be. They effectively configure the decoder in some way and if there is a mismatch, the decoding process will likely break; like mis-interpretations or buffer overflows. On the other hand, some sprop-. can be updated by in-band information, overriding what is specified on the fmtp line, and in this case the fmtp line sprop-. information is obsolete. Requiring that all fmtp of the line is equal however makes a simple rule, which should be preferable and I don't think it is too restrictive or excessive.
>> 
>> However, if the potentially equal PT values are defined as part of different media descriptions, other media level attributes also contribute to the decoder stack configuration. Some attributes, like maxptime, can clearly cause problems (in this case buffer overflow) if it differs. Others, like ptime, framerate and imageattr are more of a receiver preference within a more formal "conformance point" and would not "break" a decoder stack if they differ.
>> 
>> I agree it can be a good idea to add some text into the mux-attributes draft about attributes that have to be the same to consider two PT in different media descriptions to be "equal", of course given that rtpmap and fmtp are also equal.
>> 
>> /Bo
>> 
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Christer Holmberg
>> Sent: den 11 september 2013 09:12
>> To: Jonathan Lennox
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT 
>> value for single codec configuration
>> 
>> Hi,
>> 
>> It would be so easy if we could define the PT mappings on the SDP 
>> session level, and then simply refer to them within the m- lines :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> From: Jonathan Lennox [mailto:[e-mail]]
>> Sent: 10. syyskuuta 2013 22:18
>> To: Christer Holmberg
>> Cc: mmusic
>> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT 
>> value for single codec configuration
>> 
>> My strawman proposal at the mic in Berlin was that a codec configuration is defined by the top-level media type of the m= line and the content of a given PT value's rtpmap and fmtp lines.  I.e., the full media type, with all its parameters.
>> 
>> The questions I would have to this straw man are:
>> 
>> * Is this excessive?  E.g., should items like H.264's sprop- parameters be allowed to differ across m= line blocks?
>> 
>> * Is this sufficient?  Should other items (sometimes) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) need to be the same across m-lines as well?
>> 
>> My suggestion would be that this work should be folded into the work being done in draft-nandakumar-mmusic-sdp-mux-attributes (which really should be integrated with BUNDLE).  Currently (I believe) the mux-attributes draft assumes that PTs are unique across m-lines, so this work is going to imply changes to the analysis of a number of attributes in that draft, regardless.  Probably a new category will need to be defined for attributes which have to be consistent per payload type.
>> 
>> On Sep 10, 2013, at 5:56 AM, Christer Holmberg <[e-mail]> wrote:
>> 
>> 
>> Hi,
>> 
>> Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.
>> 
>> Questions:
>> 
>> Q1: "Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration?"
>> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there are opinions that simply referencing RFC 3550 might not be clear enough?"
>> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration?"
>> 
>> Outcome:
>> 
>> Q1: Yes
>> Q2: Yes, Lennox will send suggested text to clarify the term "codec configuration".
>> Q7: Yes.
>> 
>> So, again, we need definition text for "codec configuration". Jonathan promised to submit something, but anyone is of course welcome to do that.
>> 
>> The other alternative is to not say anything about PT value usages within the scope of BUNDLE, but that is not what the meeting wanted.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Christer Holmberg
>> Sent: 23. elokuuta 2013 13:53
>> To: mmusic
>> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT 
>> value for single codec configuration
>> 
>> Hi,
>> 
>> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage of any given PT value.
>> 
>> My take of the outcome was that:
>> 
>> -          We agreed that any given PT value can only be used for a single codec configuration (Q1)
>> -          We agreed that we need some definition text for "codec configuration" (Q2)
>> -          We agreed that, within a BUNDLE group, any given PT value can be used in multiple m- lines, as long as it is used for a single codec configuration (Q7).
>> 
>> Jonathan Lennox promised to suggest some definition text for "codec configuration", so let's wait for that until we go into those discussions.
>> 
>> But, if you have any issues with the agreements in general, please 
>> bring them up :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> --
>> Jonathan Lennox
>> [e-mail]
>> 
>