IETF Logo Mail Archive

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" <bmschwar@fas.harvard.edu> Mon, 11 July 2011 14:53 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 9958E21F8C85; Mon, 11 Jul 2011 07:53:48 -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 Efen8oFhTybO; Mon, 11 Jul 2011 07:53:47 -0700 (PDT)
Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by ietfa.amsl.com (Postfix) with ESMTP id B187C21F8C83; Mon, 11 Jul 2011 07:53:47 -0700 (PDT)
Received: from us25.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 0D1641D7552; Mon, 11 Jul 2011 10:53:47 -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=j3XDDst7PZWkbIp MFqdQ9XysYK4ua8KJkatJivqFbKo=; b=sD+LkK4Y9KJB8KWKvMIDfxK7xOAqUY9 9Kfbuj20CdM0e8GNAO+5DSE4tmP+p42AI03JGQ2H/UdV63A61XG2Bod70FJy7ymT h+RGU0vzHQEJfSJUBrMk7DGyv1XsAiWTKtInTUTkwjeeDa8jFDOgSzmney41e2Lz IMoPfZoU/zyI=
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=iXFAtCM+X o00J/idudyyikSN7dxqPvqy3nOob70X/E2BDkcmlLCFiY6BSqQ9yXVNq7h/yHZct Fv3kUTXMTkZnsavG+bs0oV6v5TqFXVpOZcgK9KKRXGsCeL/T7FqIefcuSlq2bdeS A8dgzA534OlwxffO2S9l+4SHPNE8mX8eiM=
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 us25.unix.fas.harvard.edu (Postfix) with ESMTPSA id EF9D21D752F; Mon, 11 Jul 2011 10:53:46 -0400 (EDT)
Message-ID: <4E1B0E78.8090005@fas.harvard.edu>
Date: Mon, 11 Jul 2011 10:53:44 -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 <Even.roni@huawei.com>
References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com>
In-Reply-To: <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig865375B2228B1DC3ACBA6B69"
Cc: codec@ietf.org, payload@ietf.org
Subject: Re: [codec] [payload] 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: 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).

--Ben

v2.23.0 | Report a Bug | By Email