Re: [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Sat, 09 July 2011 04:30 UTC

Return-Path: <bmschwar@fas.harvard.edu>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D373921F8A14; Fri, 8 Jul 2011 21:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEMdd792ExHJ; Fri, 8 Jul 2011 21:30:21 -0700 (PDT)
Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC1E21F89D8; Fri, 8 Jul 2011 21:30:18 -0700 (PDT)
Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id 5F6AB4D5E06; Sat, 9 Jul 2011 00:30:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=PHexp4Z0S2Wwybm r7+gLUHhtmvfdG0JjWkn1OduhsLE=; b=qEsKLxddz8fwTmrujtD5ZHgPTcOSBNQ 5gf9SpLQNzfGBjDbiP6KBF5YMaGsWSB24f1atD77MVpIV8NuVAZGBzplvZn6SaUd jcdkxWo4iIQQwqr2L4Dh6l0Phhwbvij1etXNcfR36N/wHGa2IWK1oS+vhxCQPr8N WBp7Y+gQb12o=
DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=tbxg53AKI UOXCIHrYwbPPXpkbDWlxNU3MrYNKIGvhQ0QC3ORO0wIdUt3iQ6DEh9AIiu+0/D0n UDPNISVZiqphQlLzbfMOQgqnLpe7AFYGJjuDmSoKIaGERkx0ljGmZU6Gi+l5pkL8 5Q6IuXRja3IEfEG/eSH1rs8jhoTmnV+wm0=
Received: from [192.168.1.141] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 491F94D5DFD; Sat, 9 Jul 2011 00:30:17 -0400 (EDT)
Message-ID: <4E17D958.6060903@fas.harvard.edu>
Date: Sat, 09 Jul 2011 00:30:16 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <4E133E21.3050001@fas.harvard.edu> <4e137f74.9545d80a.4f62.65af@mx.google.com>
In-Reply-To: <4e137f74.9545d80a.4f62.65af@mx.google.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26B74FE2FCAF403AA9EF9243"
Cc: codec@ietf.org, payload@ietf.org
Subject: Re: [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: bens@alum.mit.edu
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jul 2011 04:30:21 -0000

On 07/05/2011 05:15 PM, Roni Even wrote:
> In general the payload specification should provide enough information that
> will enable the reader to create or parse the RTP payload without
> understanding the codec payload based on the payload specification. As such
> it is useful to provide information that will explain the general concepts
> of the codec and the optional parameters. So I find sections 1 and 3 useful
> and they should be in the document

Despite having removed Section 3 in my suggested edit, I agree.  The
payload document should present relevant information about Opus, such as
the available frame sizes and the significance of the low-bitrate
redundancy feature.  However, it should not discuss non-normative
behaviors of the reference coder, or internal details such as subsampling
and coding modes.

The most important thing to understand about Opus coding modes is that the
encoder can, and does, dynamically switch among them on a packet-by-packet
basis in order to optimize quality.  The draft seems to have been written
under the assumption that a stream, once started in a particular mode, may
not be able to switch to other modes.   This is no longer true, as
explained in the latest Opus draft.

--Ben