Re: [codec] Multi-mode frame concatenation

Ralph Giles <giles@thaumas.net> Fri, 29 July 2011 17:12 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 829A621F8B2A for <codec@ietfa.amsl.com>; Fri, 29 Jul 2011 10:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.641
X-Spam-Level:
X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PILL=2.3, 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 LPezXMmhjXJ7 for <codec@ietfa.amsl.com>; Fri, 29 Jul 2011 10:12:10 -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 EF6C321F8B22 for <codec@ietf.org>; Fri, 29 Jul 2011 10:12:09 -0700 (PDT)
Received: by vws12 with SMTP id 12so3587441vws.31 for <codec@ietf.org>; Fri, 29 Jul 2011 10:12:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.202.140 with SMTP id fe12mr380145vcb.128.1311959529341; Fri, 29 Jul 2011 10:12:09 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Fri, 29 Jul 2011 10:12:09 -0700 (PDT)
X-Originating-IP: [66.119.183.150]
In-Reply-To: <4E320353.5050505@fas.harvard.edu>
References: <4E320353.5050505@fas.harvard.edu>
Date: Fri, 29 Jul 2011 10:12:09 -0700
Message-ID: <CAEW_Rkva4BmyXqVYzVHmuq3FX8yxRBp876P8pRRt_k2VeMGqXQ@mail.gmail.com>
From: Ralph Giles <giles@thaumas.net>
To: bens@alum.mit.edu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] Multi-mode frame concatenation
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: Fri, 29 Jul 2011 17:12:10 -0000

On 28 July 2011 17:48, Benjamin M. Schwartz wrote:

> """
> If M == 49, p == 0, and v == 1, then the packet is a "multi-mode packet".
>  The decoder MUST read the next byte to determine the true values of M, p,
> and v.  Decode shall then continue as normal, except that each frame shall
> be interpreted as a Code 0 packet.  Decoders MUST NOT continue decoding
> the packet if any frame indicates a code other than 0.
> """

To clarify, the spec limits code 3 packets to 48 frames, so M > 48 is
currently rejected, and we have (2^4 - 2 = 14) extensions to the Opus
framing we can signal by allowing additional values here while
maintaining backward compatibility with draft-ietf-codec-opus-07.

Your proposal for M = 49, p = 0, v = 1, or Opus frame count byte = 177
is to set the multimode extension flag in the decoder state, and then
read the next byte as the Opus frame count byte. Then by "each frame
shall be interpreted as a code 0 packet" you mean the frames are read
according to the second frame count byte, with lengths if v = 1 and
without if v = 0, but instead of reading undecorated frames, the
decoder will read a toc byte at the start of each frame, like so:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|1|s| config  |     49    |0|1|     M     |p|1|  Pad length   :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : N1 (1-2 bytes): N2 (1-2 bytes):     ...       :     N[M-1]    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|s| config  |                                               |
     :               Compressed frame 1 (N1 bytes)...                :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|s| config  |                                               |
     :               Compressed frame 2 (N2 bytes)...                :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|s| config  |                                               |
     :                     Compressed frame M...                     :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                     Padding (Optional)...                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      A VBR multimode packet


In any case, multimode packets would still be limited to 48 frames,
it's just that each would have a TOC byte so mode changes could be
signaled without forcing a packet boundary. Is that accurate?

 -r