[AVT] Clarification on Offer Answer usage of H.264 payload format (RFC 3984)
Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 12 October 2005 12:58 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgC7-0002cA-Nk; Wed, 12 Oct 2005 08:58:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgC5-0002c1-Ou for avt@megatron.ietf.org; Wed, 12 Oct 2005 08:58:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19389 for <avt@ietf.org>; Wed, 12 Oct 2005 08:58:51 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgMK-0001N8-3o for avt@ietf.org; Wed, 12 Oct 2005 09:09:33 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13BBDD4D; Wed, 12 Oct 2005 14:58:45 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:58:06 +0200
Received: from [147.214.34.64] ([147.214.34.64]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:58:05 +0200
Message-ID: <434D085D.6090606@ericsson.com>
Date: Wed, 12 Oct 2005 14:58:05 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Oct 2005 12:58:05.0615 (UTC) FILETIME=[963F03F0:01C5CF2C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: Miska.Hannuksela@nokia.com, "Stephan Wenger (Nokia)" <Stephan.Wenger@nokia.com>, Dave Singer <singer@apple.com>
Subject: [AVT] Clarification on Offer Answer usage of H.264 payload format (RFC 3984)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi,
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.
Any comments on this clarification?
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
- [AVT] Clarification on Offer Answer usage of H.26… Magnus Westerlund
- Re: [AVT] Clarification on Offer Answer usage of … Randell Jesup
- Re: [AVT] Clarification on Offer Answer usage of … Randell Jesup
- [AVT] H.264/RFC 3984bis and SDP - levels, paramet… Randell Jesup
- Re: [AVT] H.264/RFC 3984bis and SDP - levels, par… Randell Jesup
- Re: [AVT] H.264/RFC 3984bis and SDP - levels, par… Randell Jesup
- Re: [AVT] H.264/RFC 3984bis and SDP - levels, par… Randell Jesup
- Re: [AVT] H.264/RFC 3984bis and SDP - levels, par… Even, Roni
- Re: [AVT] H.264/RFC 3984bis and SDP - levels, par… Randell Jesup
- [AVT] H.264/RFC 3984bis and SDP - width & height Jaehwan Kim
- Re: [AVT] H.264/RFC 3984bis and SDP - width & hei… Ye-Kui.Wang
- Re: [AVT] H.264/RFC 3984bis and SDP - width & hei… Dave Singer
- Re: [AVT] H.264/RFC 3984bis and SDP - width & hei… Even, Roni
- Re: [AVT] H.264/RFC 3984bis and SDP - width & hei… Randell Jesup
- Re: [AVT] H.264/RFC 3984bis and SDP - width & hei… Randell Jesup