Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Monty Montgomery <xiphmont@gmail.com> Thu, 21 January 2010 05:41 UTC

Return-Path: <xiphmont@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E05C3A67FA; Wed, 20 Jan 2010 21:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-coeTS39ykT; Wed, 20 Jan 2010 21:41:32 -0800 (PST)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id A164C3A672E; Wed, 20 Jan 2010 21:41:31 -0800 (PST)
Received: by bwz22 with SMTP id 22so1923396bwz.5 for <multiple recipients>; Wed, 20 Jan 2010 21:41:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f+Gb48w8X4YZ6nFYhVr/+tG5l1nHYcSENi0duS5ZP/k=; b=NASDTraCJQ5Uq3ugmJYd0dg2BssRY+SC4VI9hdSjGPJfiFoVt9OfR4k1hr3QBepUQX LRkpvXPvc3irD+B5n8Q+Zct/HLFPyzkQFsn1gUb4v+LJ1PukNQBXTv483r2mENiUSMK/ WLqCrFmnuXYp59mmsITC+iaK6xHVxWykzqO0M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LFe1CgMY4gbiv+6eDE7PzbyZWIz7Ef7sdlOuGCfW4QxsroRrzHJYsBS/fjkpl+IWAy b/gfU9EIgfbC+q0yV8mD9C+7WNvKRNscafqAe4omyN5gt/6WwamfhPi2Cz24UEHBGRnN iMJQXvi/oKnADMs5mmfE06uUc7iPfr2rdBtSA=
MIME-Version: 1.0
Received: by 10.204.160.86 with SMTP id m22mr518621bkx.82.1264052484266; Wed, 20 Jan 2010 21:41:24 -0800 (PST)
In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C02959C6B@esealmw109.eemea.ericsson.se>
References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> <a123a5d60912241926l6f2255e3kc15d1d21573adeb9@mail.gmail.com> <B67FB114-FDA9-4431-A2E2-6ACF344B2EA7@cisco.com> <130EBB38279E9847BAAAE0B8F9905F8C02959C6B@esealmw109.eemea.ericsson.se>
Date: Thu, 21 Jan 2010 00:41:24 -0500
Message-ID: <806dafc21001202141m3ddb0a02v4960dd65f5b8cacb@mail.gmail.com>
From: Monty Montgomery <xiphmont@gmail.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: codec@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 21 Jan 2010 05:41:33 -0000

> As proposed by Xavier and his colleagues at Orange these requirements once defined should be giving the opportunity to the community and to other SDOs members to check for codecs potentially fullfilling the requirements.

It is already the case that submissions are welcome from any
interested parties, and we hope very much that the SDOs do have
technology or even finished codecs to offer.  I don't think that needs
to be spelled out in language special to the SDOs.

> What would be the point of conducting codec development when a standardized codec out there fullfills the requirements ?

This is another facet of 'our goals do not include rubber-stamping'.
Should an unremembered codec be found lurking that fufills all
requirements, it would serve to raise the bar we set for ourselves.
The more and better the inputs, the better the potential results. We
seek to touch fire.

> "Once the first requirement establishment stage is completed, the working group will then communicate detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG. If an available standardized codec actually fullfills, or codec under current standardization will likely fulfil the requirements, then the working group may decide to terminate the codec development work."

In the event an outside codec is discovered that meets all
requirements and cannot be improved upon, the only sensible course of
action would be accept it.  I see no reason to exhaustively codify
basic common sense for every unlikely scenario.  [It is not that I
consider contributions from the SDOs to be unlikely, I consider it
unlikely there would be no potential for any improvement given the
assembed talent and that such a codec already exists and nobody knows
about it.  If I'm wrong-- everybody still wins, and I'm happy with
losing the bet.]

Monty
Xiph.Org