Re: [codec] it MUST NOT exceed 1275 bytes?

Gregory Maxwell <> Mon, 25 July 2011 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93F0E21F8B97 for <>; Mon, 25 Jul 2011 11:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jb8pxOkWKtOO for <>; Mon, 25 Jul 2011 11:41:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D33EB21F8AA8 for <>; Mon, 25 Jul 2011 11:41:53 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTi246SEwzMdDq3L2IRaTvWr5/lmOXpH/; Mon, 25 Jul 2011 11:41:53 PDT
Received: from ([fe80::c821:7c81:f21f:8bc7]) by ([::1]) with mapi; Mon, 25 Jul 2011 11:39:37 -0700
From: Gregory Maxwell <>
To: "" <>, Christian Hoene <>
Date: Mon, 25 Jul 2011 11:39:37 -0700
Thread-Topic: [codec] it MUST NOT exceed 1275 bytes?
Thread-Index: AcxK8BxUyzWBhrH1RHSeT7dO+TLi+AACJbQb
Message-ID: <>
References: <007101cc4aee$e622bd50$b26837f0$>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [codec] it MUST NOT exceed 1275 bytes?
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, 25 Jul 2011 18:41:54 -0000

Benjamin M. Schwartz [] wrote:
>> 2) What are the calculations behind 1275?
>"The maximum representable size is 255*4+255=1275 bytes."
> Because the first N-1 frames in a packet cannot have a size greater than
> 1275, it would be very strange if this were permitted for the final frame.
> An unbounded frame size would also unreasonably increase the minimum
> computational performance required of a conformant decoder.

As Ben and the draft point out, the actual limit comes from the
scheme used to encoded lengths in the multiple packed frames

It's also worth pointing out that 1275 is high enough that the codec is 
at the point where it is often _unable_ to use more rate (and would just
be coding zeros) due to a multitude of internal complications and tradeoffs. 

It's also low enough that the frames will by supportable on common networks
even with a fair amount of higher layer overhead without needing

In the CELT modes the maximum precision used is limited by the codebook
size (memory trade-off) and band splitting depth (computation trade-off), so
higher rates couldn't be usefully supported without non-trivial worst case
complexity/memory increases for implementations.

And at 510kbit/sec we're at nearly twice the highest ABXable
bitrate for any killer sample I'm currently aware of... leaving plenty of
just-in-case headroom for VBR encoders to throw lots of bits at
challenging sections.