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

Ralph Giles <giles@thaumas.net> Tue, 26 July 2011 18:01 UTC

Return-Path: <giles@thaumas.net>
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 CE37911E8135; Tue, 26 Jul 2011 11:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level:
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nhMcz4qiBspi; Tue, 26 Jul 2011 11:01:50 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C14711E8132; Tue, 26 Jul 2011 11:01:50 -0700 (PDT)
Received: by vws12 with SMTP id 12so646389vws.31 for <multiple recipients>; Tue, 26 Jul 2011 11:01:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.105.136 with SMTP id t8mr1639225vco.128.1311703309600; Tue, 26 Jul 2011 11:01:49 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Tue, 26 Jul 2011 11:01:49 -0700 (PDT)
X-Originating-IP: [66.119.183.150]
In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de>
References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de>
Date: Tue, 26 Jul 2011 11:01:49 -0700
Message-ID: <CAEW_RkuW++v6E2N2X2LEHmqFo+F4nmT77N3ZurfJoGfzs_xBiQ@mail.gmail.com>
From: Ralph Giles <giles@thaumas.net>
To: Christian Hoene <hoene@uni-tuebingen.de>
Content-Type: text/plain; charset=UTF-8
Cc: codec@ietf.org, payload@ietf.org
Subject: Re: [codec] 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: Tue, 26 Jul 2011 18:01:50 -0000

2011/7/25 Christian Hoene <hoene@uni-tuebingen.de>de>:

> 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 believe the codec authors have described some of their reasoning for
the internal framing. However, it sounds like your concern is the
presence of framing at the codec level, rather than at the RTP payload
level.

There is precedent for this in previous specifications.
http://tools.ietf.org/html/rfc3551#section-4.4 "Guidelines for
Frame-Based Audio Encodings" says:

  "Frame-based encodings encode a fixed-length block of audio into
   another block of compressed data, typically also of fixed length.
   For frame-based encodings, the sender MAY choose to combine several
   such frames into a single RTP packet.  The receiver can tell the
   number of frames contained in an RTP packet, if all the frames have
   the same length, by dividing the RTP payload length by the audio
   frame size which is defined as part of the encoding.  This does not
   work when carrying frames of different sizes unless the frame sizes
   are relatively prime.  If not, the frames MUST indicate their size.

   [...]

   All frame-oriented audio codecs SHOULD be able to encode and decode
   several consecutive frames within a single packet. [...]"

Opus can use variable length encoded frames, so the clause that
_frames_ must indicate their size, so that the codec can "decode
several consecutive frames within a single packet" applies. The
referent here is frames and codecs, not the payload format, so I don't
think we're breaking new ground here by having some framing at the
codec level.

I would also point out that the opus codec draft is nearly finished.
Continuing to specify framing there, rather than adding complication
to the newer RTP draft, is the quicker path to standardization of both
levels.

FWIW,
 -r