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

Jonathan Lennox <> Wed, 27 July 2011 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF53321F8862; Wed, 27 Jul 2011 12:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03mTuBnRC5ra; Wed, 27 Jul 2011 12:11:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F095421F8779; Wed, 27 Jul 2011 12:10:41 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 5D3AB8BE73E; Wed, 27 Jul 2011 15:10:41 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB028.mail.lan (unknown []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCEB08BE54B; Wed, 27 Jul 2011 15:10:35 -0400 (EDT)
Received: from BE235.mail.lan ([]) by HUB028.mail.lan ([]) with mapi; Wed, 27 Jul 2011 15:10:26 -0400
From: Jonathan Lennox <>
To: "" <>, "" <>
Date: Wed, 27 Jul 2011 15:10:34 -0400
Thread-Topic: [payload] Frames to Packets in draft-ietf-codec-opus-07?
Thread-Index: AcxMkNzxKrhe3c1/SY+h3AcPKT1kOQ==
Message-ID: <>
References: <00ec01cc4ad6$8125b2d0$83711870$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 31 Jul 2011 17:38:49 -0700
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: Wed, 27 Jul 2011 19:11:18 -0000

On Jul 25, 2011, at 1:56 PM, Benjamin M. Schwartz wrote:

> 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
> specified?

Does the Opus framing allow packets to be split and/or aggregated by a middlebox along frame boundaries, without requiring transcoding?  (The use case for splitting is to forward traffic to a box with a lower maxptime than the stream you're receiving, and the use case for aggregation is to reduce the RTP header overhead at the cost of some additional delay.)

I tried to read the Opus spec to answer my question, and I think I came up with the answer, but I wanted to confirm this with the Opus experts.

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.

I get the impression that the TOC byte is expected to change only relatively infrequently in most encoding modes, in which case this would be fine -- there may be transient packets which couldn't be aggregated, resulting in occasional "short" packets, but most packets could be aggregated.  However, if an encoder might change its TOC frequently, this could be more problematic.

If the (Payload) WG is okay with this limitation (and the limitation of a maximum of 120 ms packets), I think the internal-framing-only is okay; if not, we might need external framing as well. (I appreciate that you don't want to change the Opus bitstream proper, at this point.)

Jonathan Lennox