Re: [codec] Multi-mode frame concatenation

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Fri, 29 July 2011 17:31 UTC

Return-Path: <bmschwar@fas.harvard.edu>
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 099EA21F8B79 for <codec@ietfa.amsl.com>; Fri, 29 Jul 2011 10:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 S1+S0+qjquqe for <codec@ietfa.amsl.com>; Fri, 29 Jul 2011 10:31:18 -0700 (PDT)
Received: from us26.unix.fas.harvard.edu (us26.unix.fas.harvard.edu [140.247.35.202]) by ietfa.amsl.com (Postfix) with ESMTP id F085C21F8B4C for <codec@ietf.org>; Fri, 29 Jul 2011 10:31:17 -0700 (PDT)
Received: from us26.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us26.unix.fas.harvard.edu (Postfix) with ESMTP id 3D3351F75AE; Fri, 29 Jul 2011 13:31:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=nQO9cUY9m1wJ/vh v0HeN1Z+gfvZgSSWujj3eH01PZMY=; b=q38cBDr/0ghlF0LK4fnhq78SYQtDgK3 PSZF/5zR/AczpGM7c5Fdm88/TrHrsDQrOPLeft5e0NkIlC+SQspBQLGATTuOkFCc a+53EpE+DflL7HwOHyGz4an3uFto/Z0I7kdNi1A9QfSW3GWQ2A4RGOhdhpecjoXn xitmIU9bx/ZM=
DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=n+A5CRg8m t4F8PBQkkGzyJbfDarbV0+J3snutsrQTokf2SrgqCkQcohTpo3oYUAKQHkKepQ9w G6q8E7ljd2zubZ98UNhO4MQ26PAMhel8gRVXYKOr0HTHWmAQByU+JEJ3hNTza7+J kLEVwmJAbW1DRWudme4jAjhK+fx/6OF5aw=
Received: from [172.23.141.135] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us26.unix.fas.harvard.edu (Postfix) with ESMTPSA id 2CAA51F7545; Fri, 29 Jul 2011 13:31:17 -0400 (EDT)
Message-ID: <4E32EE61.1040304@fas.harvard.edu>
Date: Fri, 29 Jul 2011 13:31:13 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ralph Giles <giles@thaumas.net>
References: <4E320353.5050505@fas.harvard.edu> <CAEW_Rkva4BmyXqVYzVHmuq3FX8yxRBp876P8pRRt_k2VeMGqXQ@mail.gmail.com>
In-Reply-To: <CAEW_Rkva4BmyXqVYzVHmuq3FX8yxRBp876P8pRRt_k2VeMGqXQ@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F26707D26464B7722B78946"
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
Reply-To: bens@alum.mit.edu
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:31:19 -0000

On 07/29/2011 01:12 PM, Ralph Giles wrote:
> 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.

For some definitions of backwards compatibility, yes.  The draft's text
indicates that this extensibility is deliberate.  I'm not sure where you
get 14; I get (64-49)*4 = 60, at a minimum.

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

This is all extremely accurate.  I had originally intended (following the
language in your diagram) for Compressed frame 1 to consist of N1-1 bytes,
so that its entirety (including the TOC byte) had size N1.  However, I now
see that your version is superior, as otherwise it would be impossible to
represent the max-size frame (1275 bytes, or 1276 with the TOC byte).