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

"Benjamin M. Schwartz" <> Mon, 11 July 2011 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9958E21F8C85; Mon, 11 Jul 2011 07:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Efen8oFhTybO; Mon, 11 Jul 2011 07:53:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B187C21F8C83; Mon, 11 Jul 2011 07:53:47 -0700 (PDT)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id 0D1641D7552; Mon, 11 Jul 2011 10:53:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed;; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=j3XDDst7PZWkbIp MFqdQ9XysYK4ua8KJkatJivqFbKo=; b=sD+LkK4Y9KJB8KWKvMIDfxK7xOAqUY9 9Kfbuj20CdM0e8GNAO+5DSE4tmP+p42AI03JGQ2H/UdV63A61XG2Bod70FJy7ymT h+RGU0vzHQEJfSJUBrMk7DGyv1XsAiWTKtInTUTkwjeeDa8jFDOgSzmney41e2Lz IMoPfZoU/zyI=
DomainKey-Signature: a=rsa-sha1; c=simple;; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=iXFAtCM+X o00J/idudyyikSN7dxqPvqy3nOob70X/E2BDkcmlLCFiY6BSqQ9yXVNq7h/yHZct Fv3kUTXMTkZnsavG+bs0oV6v5TqFXVpOZcgK9KKRXGsCeL/T7FqIefcuSlq2bdeS A8dgzA534OlwxffO2S9l+4SHPNE8mX8eiM=
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by (Postfix) with ESMTPSA id EF9D21D752F; Mon, 11 Jul 2011 10:53:46 -0400 (EDT)
Message-ID: <>
Date: Mon, 11 Jul 2011 10:53:44 -0400
From: "Benjamin M. Schwartz" <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Roni Even <>
References: <00f601cc3aa7$ff4c9460$fde5bd20$> <008901cc3fd6$4d18e490$e74aadb0$>
In-Reply-To: <008901cc3fd6$4d18e490$e74aadb0$>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig865375B2228B1DC3ACBA6B69"
Subject: Re: [codec] [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2011 14:53:48 -0000

On 07/11/2011 10:24 AM, Roni Even wrote:
> 5. In section 3.5 "If a decoder can not take advantage of the benefits of a
> stereo  signal this SHOULD  be indicated at the time a session is set up.
> In  that case the sending side SHOULD  NOT send stereo signals as it leads
> to an inefficient usage of network bandwidth". I think that the SHOULD NOT
> need to be MUST NOT. Is there a reason for the sender to ignore the receiver
> request?

If a stream is being sent to many recipients, most of whom prefer stereo,
then it may be appropriate to send a single stereo stream to all
recipients, rather than increase the encoder CPU requirements by encoding
multiple versions of the stream.

> 14.In 7.1 the CBR parameter let the decoder specify if to use CBR or VBR.
> Yet the CBR does not specify a value making it look a bit like VBR. I think
> that there should be an option for the receiver to ask for a specific CBR
> rate.

I think the implication was that in CBR mode, "maxaveragebitrate" also
sets a hard ceiling on the size of an individual packet.  I agree that
this is not a perfect solution.  Personally, I would prefer that the
receiver indicate both a hard limit and a soft target (or similar).