[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