Re: [codec] [payload] Frames to Packets in draft-ietf-codec-opus-07?

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Wed, 27 July 2011 19:21 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 E8FB821F8BB1; Wed, 27 Jul 2011 12:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ufQBNGmp-CIU; Wed, 27 Jul 2011 12:21:08 -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 3609A21F8BB4; Wed, 27 Jul 2011 12:21:08 -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 6F2F14D5E5B; Wed, 27 Jul 2011 15:21:05 -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=o5m8AaVwZHWkcLF osnnIOC6QROi33hIxdkW2mqiYsNA=; b=smLHgS46p2YyDGxathyoNRzbweimiax 79sisqo6yToHoL8lME62DBulSkaQ510tMMcgP2K2C40CfUtiYpLZIcawFqLJ8bGE vb/UKRIKAK86JMSaSMYJ95mMCSdcpbnIf/23SEtDcwd+2qre6MUnrPkef8F+HLIj XM9lKc27+KWY=
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=JOgYjhtG3 mRpSabQ1Pi5OWMiZeh9yg6XdjpoyRwbgdLH4aaWv4qBJO38EjosJVWwj367IQb4F yETrrX/Z3tzMkEFimb+0xk3v3nmMN8CoDRke/MW81woCplDLG/ONcPm25g/5Kb4K 77I5pvU1IdvHeDdDeTQHsz6mq514lDAOd8=
Received: from [172.23.141.135] (bwhmaincampuspat25.partners.org [170.223.207.25]) (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 675FB4D5E54; Wed, 27 Jul 2011 15:21:05 -0400 (EDT)
Message-ID: <4E30651E.7090305@fas.harvard.edu>
Date: Wed, 27 Jul 2011 15:21:02 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Jonathan Lennox <jonathan@vidyo.com>
References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> <4E2DAE67.6090008@fas.harvard.edu> <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com>
In-Reply-To: <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig6B7A58D6D542A520C5D890BD"
Cc: "codec@ietf.org" <codec@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [codec] [payload] Frames to Packets in draft-ietf-codec-opus-07?
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: Wed, 27 Jul 2011 19:21:09 -0000

On 07/27/2011 03:10 PM, Jonathan Lennox wrote:
> Based on my reading of the Opus spec, it looks like splitting should be possible, relatively trivially.  Aggregation, however, is only possible if the packets to be aggregated have the same value for the Opus TOC byte.

That is a correct reading of the Opus spec as of Opus-02 and later.  Prior
to Opus-02, the spec also described a packet mode that could contain
frames of different types, allowing arbitrary aggregation.  I believe it
was removed because the authors expected that it would be rarely used, and
removing it allowed them to improve the efficiency of more common cases.

--Ben