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

Jean-Marc Valin <> Mon, 01 August 2011 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F0AF5E8005; Sun, 31 Jul 2011 18:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kp+SWPPEQ87t; Sun, 31 Jul 2011 18:27:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A283E5E8003; Sun, 31 Jul 2011 18:27:14 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=ISO-8859-1
Received: from [] ([]) by (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <>; Sun, 31 Jul 2011 21:27:05 -0400 (EDT)
Message-id: <>
Date: Sun, 31 Jul 2011 21:26:47 -0400
From: Jean-Marc Valin <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0
To: Jonathan Lennox <>
References: <00ec01cc4ad6$8125b2d0$83711870$> <> <>
In-reply-to: <>
X-Enigmail-Version: 1.2
Cc: "" <>, "" <>
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, 01 Aug 2011 01:27:15 -0000

Hi Jonathan, (sorry, just received your post now)

On 11-07-27 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.


> 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.

I don't really see the TOC byte changing frequently. I would expect that
for many/most uses, the TOC would never change during an RTP session.
For other uses, I'd be surprised to see it changed more than once every
5-10 minutes. The only potentially problematic case (when it comes to
aggregation) would be contents that has music and speech that alternates

> 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.)

I don't see these limitations as being a problem, but if they really are
(in practice, not in some theoretical scenario), then I'd rather change
this in the bit-stream than have RTP implementations mess it up on a
regular basis (and having non-RTP implementations do it differently).