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

"Benjamin M. Schwartz" <> Mon, 25 July 2011 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25ECD21F8BA4; Mon, 25 Jul 2011 10:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kj2fEQ9vdno9; Mon, 25 Jul 2011 10:56:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5184821F8B7F; Mon, 25 Jul 2011 10:56:57 -0700 (PDT)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id A54F21F71CF; Mon, 25 Jul 2011 13:56:56 -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=CI3neouXH273ES+ jpDwFnPi9pPqX3A8wMh99A+0+VuQ=; b=qLIzdVOggFTqYg7c+hwEyWB4Iu0tBHn pXTjH8dpCjY2mm0dOT/9+QsgGKqkoVzxR1MxIaZLsRyzmPAgsNR0ZuFqgjx6cGyl 52VtosIivqJLFkNfLEqixQb558PozO7g4htxnlH7nmCpeDnGtdkc8PExpN8v+orR cmR220O2gIOc=
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=I5061MSsD 5F/inLiZfucXmD0Vt4mr7oBWPwxnZRD6xQFGFDuFeJDRGivfQfs4TRJTYrf0XGmU xNLRKY/kwoJzXJTwiYAsSlrQGaOoTJT03daZUjlmvi5mu7p3fRGt1bRrCsa4zxK8 f+UDz78GAhVQkbz8JIge+tupETWXFxsBjg=
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 9C5831F71CD; Mon, 25 Jul 2011 13:56:56 -0400 (EDT)
Message-ID: <>
Date: Mon, 25 Jul 2011 13:56:55 -0400
From: "Benjamin M. Schwartz" <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Christian Hoene <>
References: <00ec01cc4ad6$8125b2d0$83711870$>
In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE092448E8E6DC7BDA0A387E8"
Subject: Re: [codec] [payload] Frames to Packets in draft-ietf-codec-opus-07?
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, 25 Jul 2011 17:56:58 -0000

On 07/25/2011 10:23 AM, Christian Hoene wrote:
> I was wondering why the draft-ietf-codec-opus-07 draft has feature to
> concatenate multiple codec frames to packets. At the same time,
> draft-spittka-payload-rtp-opus-00 does not support to place multiple codec
> entities in on RTP packet.

I think we are in agreement that for many packet transports, a single
frame per packet (max duration of 20~ms for general audio, minimum of
2.5ms or 400 pps) would be inappropriate, and so a concatenation scheme is
required.  The question is then: where should the concatenation scheme be

The motivation for specifying concatenation inside the codec is to promote
interoperability and adoption by reducing the total amount of engineering
work required to implement Opus.  This happens in two ways:

1. Avoiding duplicative software work

Given the structure of existing networked audio software, I expect that
software using Opus will typically rely on a pre-existing Opus library,
and there will be only a small number of widely used Opus implementations.
 However, there will likely be many implementations of the Opus-RTP
specification, due to engineering integration requirements.  As such, we
can reduce implementation effort by minimizing the complexity of the RTP

2. Avoiding duplicative specification work

Opus will be distributed over many transports other than RTP, and a
concatenation scheme may be desirable in each case.  Specifying
concatenation inside the codec avoids the need to specify a new
concatenation scheme for every transport.  Having a single concatenation
scheme should therefore accelerate adoption, minimize confusion when
moving packets between transports, and minimize the amount of software
required to make Opus work.

Personally, I've found H.264 to be an example of how specifying framing
outside the codec can create problems. H.264's packet/framing schemes (the
"network abstraction layer", "access units", bytestream alignment, etc.)
are specified outside the codec, so that they must be handled by the
stream processing layer.  Correctly distinguishing and converting between
the various possibilities is so confusing that, until the latest release
last month, gstreamer's H.264 parser could not correctly depayload H.264
from the popular AVCHD format.