IETF Logo Mail Archive

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

Koen Vos <koen.vos@skype.net> Mon, 11 July 2011 22:00 UTC

Return-Path: <koen.vos@skype.net>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0E11E82E0 for <payload@ietfa.amsl.com>; Mon, 11 Jul 2011 15:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 7JgXxmkoCRXC for <payload@ietfa.amsl.com>; Mon, 11 Jul 2011 15:00:39 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF011E826E for <payload@ietf.org>; Mon, 11 Jul 2011 15:00:38 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 1D52B16E2; Tue, 12 Jul 2011 00:00:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=JZi2rk3ZaOqJlCRBpCs65ohgXTI= ; b=tu/HWDZJ8TShdxVNiVCk1/C0kACzRUoklwbXKROWN4VLJa5y6npyQH7i6Zz0 KWULMg8fNnAGeLq7DvWp5GcoNKgr25mZWdboLV8WhCRWikPjT/fttBifg4+ZCOED aOOW4bkVyLNCqgwBu+WgKo01YEKWesayRh//SXMWc/fE79c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=BTGg1duYjQ9wt/6+XHvpvB mXRRyJrisMRSYkRwZeGx78JWdmVQxLb6qsDgOGEdaaUyc2xIakGqbrNGoWuO8IpV CdnYzebb+dhuPMm3VTHQ7oM5IxtOtvbc6DHR3pitA1cl3AnZnxuThoxG4wv+8Fxn 23HEDgMc35QLbFTbpEyQM=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1BE337F6; Tue, 12 Jul 2011 00:00:38 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id ECB3C3507E56; Tue, 12 Jul 2011 00:00:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i9-04dV5x4C; Tue, 12 Jul 2011 00:00:37 +0200 (CEST)
Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 3CE9635075DF; Tue, 12 Jul 2011 00:00:37 +0200 (CEST)
Date: Tue, 12 Jul 2011 00:00:37 +0200
From: Koen Vos <koen.vos@skype.net>
To: Randell Jesup <randell-ietf@jesup.org>
Message-ID: <1906705067.3121553.1310421637147.JavaMail.root@lu2-zimbra>
In-Reply-To: <4E1B5BCD.7050708@jesup.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [69.181.192.115]
X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686)
Cc: payload@ietf.org
Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2011 22:00:39 -0000

Randell Jesup wrote:
> ptime is I think desired but not required.  maxptime and minptime should 
> be hard receiver limits.

The goal has always been that every Opus decoder is able to decode any valid Opus bitstream.  Advantages are:
- In a multi-party call you can send the same bitstream to all end points.  If maxptime and minptime were hard limits, then two end points may not have any overlap in their ranges of allowed ptime, making it impossible to share bitstreams.
- Less reliance on parameter negotiation.  Keep in mind that bitstreams may be saved to file and played out later.

Note that the cost in storage requirements of maxptime being a soft limit is modest: payloads are stored in compressed format, and payloads with ptime > 20 ms can always be decoded in chunks of 20 ms (or less).

If Opus' use of minptime and maxptime differs from what is generally accepted, then perhaps we should use different names for these parameters?

Roni Even wrote:
> So what is the benfit for the receiver to signal it.

See section 7.2.1: performance (e.g. quality) may be better for some ptime values than for others.

best,
koen.


----- Original Message -----
From: "Randell Jesup" <randell-ietf@jesup.org>
To: payload@ietf.org
Sent: Monday, July 11, 2011 1:23:41 PM
Subject: Re: [payload] RTP Payload Format and File Storage Format for	Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00

On 7/11/2011 10:24 AM, Roni Even wrote:
> 11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by
> the receiver are just recommendations and not the desired value as in RFC
> 3264, and the sender can send any size it wishes upto 120. So what is the
> benfit for the receiver to signal it. I thought that this is a receive
> capability.

ptime is I think desired but not required.  maxptime and minptime should 
be hard receiver limits.
Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encoder can 
vary up to maxptime (and I
assume down to minptime).  (I didn't bother researching further).

-- 
Randell Jesup
randell-ietf@jesup.org

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

v2.23.0 | Report a Bug | By Email