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

"Christian Hoene" <hoene@uni-tuebingen.de> Mon, 25 July 2011 18:46 UTC

Return-Path: <hoene@uni-tuebingen.de>
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 D2CFB21F8BDF for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 11:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.772
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Fwjg6aKtZg for <codec@ietfa.amsl.com>; Mon, 25 Jul 2011 11:46:22 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFBB21F8B74 for <codec@ietf.org>; Mon, 25 Jul 2011 11:46:21 -0700 (PDT)
Received: from hoeneT60 (modemcable004.100-203-24.mc.videotron.ca [24.203.100.4]) (authenticated bits=0) by mx06.uni-tuebingen.de (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 <hoene@uni-tuebingen.de>
To: 'Gregory Maxwell' <gmaxwell@juniper.net>, codec@ietf.org
References: <007101cc4aee$e622bd50$b26837f0$@uni-tuebingen.de> <BCB3F026FAC4C145A4A3330806FEFDA93CE1882B9B@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA93CE1882B9B@EMBX01-HQ.jnpr.net>
Date: Mon, 25 Jul 2011 14:46:12 -0400
Organization: Universitat Tubingen
Message-ID: <00d701cc4afb$24ef21c0$6ecd6540$@uni-tuebingen.de>
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: 3.2.1.23; host: mx06)
Subject: Re: [codec] it MUST NOT exceed 1275 bytes?
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: 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. 

Christian