Re: [AVT] RFC 3984 offer/answer Question

[Randell Jesup <rjesup at wgate.com>]

"Even, Roni" <roni.even at polycom.co.il> writes:
>I went back to the mailing list and found the attached email.
>It is in line with my thought that the level can be downgraded

Darn! :-)  I knew this whole conversation sounded familiar.  I remember
(now) seeing that, and in fact I've kept the article "ticked" in Gnus
so it doesn't disappear on me.

There really should be an rfc 3984bis (or at least an informational RFC; I
don't know how this is supposed to work); everyone who comes to read it
without searching the mail-archives will make the same set of mistakes and
mis-readings.

Magnus?

Magnus wrote:
>We authors was made aware of an issue in the Offer/Answer usage for the 
>H.264 RTP payload format by Tang Yongliang.
>
>The issue is that section 8.2.2 says:
>
>    o  The parameters identifying a media format configuration for H.264
>       are "profile-level-id", "packetization-mode", and, if required by
>       "packetization-mode", "sprop-deint-buf-req".  These three
>       parameters MUST be used symmetrically; i.e., the answerer MUST
>       either maintain all configuration parameters or remove the media
>       format (payload type) completely, if one or more of the parameter
>       values are not supported.
>
>And later
>
>"  o  Parameters declaring a configuration point are not downgradable,
>       with the exception of the level part of the "profile-level-id"
>       parameter."
>
>That is contradicting for the "profile-level-id" parameter. The 
>intention of the authors was that the profile part (profile_idc and 
>profile_iop) would be fixed but the level (level_idc) can be downgraded. 
>That way you as an receiver state the profiles and highest level for 
>that profile you are willing to accept. The answerer can then respond 
>with the same profile but with a possibly lower level.
>
>So for clarification: An answerer MUST only maintain the profile_idc and 
>profile_iop bytes of the profile-level-id value and MAY downgrade the 
>level part.
>
>Please note: This may require the offering party to make a new offer to 
>provide its "sprop" parameters correctly due to the reduction in level.
>
>However without this clarification the only way of getting a successful 
>offer/answer for H.264 when not fully aware of the counter-parts 
>capabilities would be to write one payload type for each profile-level 
>combination that one could downgrade to.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt