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

Jean-Marc Valin <jmvalin@jmvalin.ca> Mon, 01 August 2011 01:27 UTC

Return-Path: <jmvalin@jmvalin.ca>
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 2F0AF5E8005; Sun, 31 Jul 2011 18:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kp+SWPPEQ87t; Sun, 31 Jul 2011 18:27:14 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (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 [192.168.1.14] ([184.160.206.46]) by vl-mr-mrz22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LP800CZ76P47J50@vl-mr-mrz22.ip.videotron.ca>; Sun, 31 Jul 2011 21:27:05 -0400 (EDT)
Message-id: <4E3600D7.1040603@jmvalin.ca>
Date: Sun, 31 Jul 2011 21:26:47 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.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.2
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
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: 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.

Correct.

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

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

Cheers,

	Jean-Marc