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

[Christer Holmberg <[e-mail]>]

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]> [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]<mailto:[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]> [mailto:[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]<mailto:[e-mail]>