"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