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

"Christian Hoene" <> Mon, 25 July 2011 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2CFB21F8BDF for <>; Mon, 25 Jul 2011 11:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.772
X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q3Fwjg6aKtZg for <>; Mon, 25 Jul 2011 11:46:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0FFBB21F8B74 for <>; Mon, 25 Jul 2011 11:46:21 -0700 (PDT)
Received: from hoeneT60 ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id p6PIkDNF005377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 20:46:20 +0200
From: "Christian Hoene" <>
To: "'Gregory Maxwell'" <>, <>
References: <007101cc4aee$e622bd50$b26837f0$> <>
In-Reply-To: <>
Date: Mon, 25 Jul 2011 14:46:12 -0400
Organization: =?us-ascii?Q?Universitat_Tubingen?=
Message-ID: <00d701cc4afb$24ef21c0$6ecd6540$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJtwoAskKc2oLEEloJVQeG4M1e3jQHD8BXzk6xO0MA=
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version:; host: mx06)
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:46:22 -0000

Hi Gergory,

> The ability to pack multiple frames is also requirement for the ability to
> produce constant duration packets even if the underlying transform block
> size is changing due to changing signal characteristics.  As such this
> is deeply a codec layer issue, as it allows the codec to be able to meet
> a reasonable requirement (constant duration frames) while changing
> modes based on its coding analysis.

[Christian Hoene] Uuh, be careful, there is a Fraunhofer claim on switching
frame sizes depending on signal information. 
The algorithm that you describe is not part of the reference implementation,
isn't it?

> What cost do you perceive this feature to have, and what benefit would
> we enjoy by removing it?

[Christian Hoene] It is the cost of complexity. I am just following the
saying "Everything should be made as simple as possible, but not simpler."

Currently, the Opus draft has a couple of features that do not belong in the
Codec WG nor in the Opus spec.