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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 25 December 2009 03:26 UTC

Return-Path: <hallam@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 2D7EE3A67D3; Thu, 24 Dec 2009 19:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level:
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 IHhcxWOQVuau; Thu, 24 Dec 2009 19:26:28 -0800 (PST)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id C3FA53A6784; Thu, 24 Dec 2009 19:26:27 -0800 (PST)
Received: by yxe30 with SMTP id 30so9753469yxe.29 for <multiple recipients>; Thu, 24 Dec 2009 19:26:07 -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=WUsyIHvBEbpM6UgmDOpMKleebOE0MqhC2fBxMhR59Xs=; b=JL1BM/MXVvdXVPAEuZa5EyvfFB6U9RBE8URv8sBcKRfwcM8ks0csVBpwdDi3wnSW06 JUqfDCwEg+2TEq3t3M3mMPf+7Yy727A42WWQvNCdIhkM5UTBmDjItkIb1icnhNUfNZm4 /HsqQrDgCZVWmzQnFC3VXpaYc13eM6pRcrD8Y=
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=akto6VYqx9b1ZAfOZUJNlRFIXrxAXKq0KQ8kvitQLsW0x/baciB01hFrKDYDWV5CQC be42CND2sIxqTDQyhJNh9jfMdsV2YjT9W+gvYz6rqqIXt5Pr1Dpq5/0gB989v8IMZnUr ppiYZ3KQLorPVGHlVxxKbUrXORIC7bFSYt/z4=
MIME-Version: 1.0
Received: by 10.91.54.18 with SMTP id g18mr162781agk.92.1261711567577; Thu, 24 Dec 2009 19:26:07 -0800 (PST)
In-Reply-To: <4b3373d7.02135e0a.241a.fffffb62@mx.google.com>
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>
Date: Thu, 24 Dec 2009 22:26:07 -0500
Message-ID: <a123a5d60912241926l6f2255e3kc15d1d21573adeb9@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 24 Dec 2009 21:05:00 -0800
Cc: codec@ietf.org, iesg@ietf.org, kre@munnari.oz.au, 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: Fri, 25 Dec 2009 03:26:29 -0000

I don't think it is a very good idea to attempt this type of work in
the IETF. We have enough difficulty doing crypto algorithms and that
is an area where we have tens of people with decades worth of
expertise who pretty much mostly agree on the algorithms to use in any
case.

An unencumbered CODEC would be very useful, but any new CODEC that was
developed would be subject to attack by patent trolls. So the group
would be pretty much limited to reviewing existing technologies and
attempting to select one that is out of patent.

Looking at technologies that are out-of-patent or soon to be out of
patent, well DVD came out in 1995 and the patent licensing terms are
reasonably well defined. MP3 and AC3 are the existing industry
standards. If we know when the patents drop dead, I can't see how IETF
imprimatur is going to add or detract anything there. Its not as if
the IETF can stand behind the spec and say that it is definitively
unencumbered. So the most we are going to have is a document that
brings together all the relevant information and allows people to
quickly come to a degree of confidence that the technology will be
inencumbered on a certain date.



On Thu, Dec 24, 2009 at 8:56 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
> Hi,
> In line
> Roni Even
>
>> -----Original Message-----
>> From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU]
>> Sent: Thursday, December 24, 2009 11:47 AM
>> To: Roni Even
>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; iesg@ietf.org;
>> ietf@ietf.org; codec@ietf.org
>> Subject: Re: WG Review: Internet Wideband Audio Codec (codec)
>>
>>     Date:        Thu, 24 Dec 2009 08:50:30 +0200
>>     From:        "Roni Even" <ron.even.tlv@gmail.com>
>>     Message-ID:  <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com>
>>
>>   | I am not sure but are you suggesting that the IETF will define the
>>   | requirements, metric and quality assessment requirements and all
>> proposed
>>   | codecs should provide the results and then the WG will choose the
>> best codec
>>   | bases without discussing the codec itself. This is what I would
>> call a
>>   | selection process (at least in ITU terms).
>>
>> The WG can decide how it wants to go about the process, I'd just prefer
>> that
>> the charter not (effectively) rule out selection of something that
>> already
>> exists with an assumption that something entirely new will be created.
>>
>>   | The problem is that the IETF process allows anyone to contribute to
>> existing
>>   | work hopefully leading to a better the end result.
>>
>> Of course, but also be aware that there's no one definition of
>> "better".
>> Something that can be defined quickly and used immediately might be
>> much
>> better than something it takes 5 years to create and more to implement,
>> even if the invented one saves a little bandwidth or has better loss
>> recovery characteristics.
>
> This is the IETF process for better or worse, I asked similar questions and
> the response is that the IETF decide what is better is based on rough
> consensus.
> BTW: my personal view is that your suggestion is in line with the process at
> the ITU when doing codec selection, but there are people who prefer doing it
> at the IETF using the IETF procedures for other reasons.
>
>
>>
>>   | What about the change control, does it stay with the original
>> contributor or
>>   | can the IETF modify the codec based on input from other parties,
>> which means
>>   | that the codec may change by the IETF anyhow.
>>
>> The IETF will have change control over its protocol, of course, which
>> may
>> cause it to diverge from that upon which it was originally based.  And
>> yes,
>> everything changes with time.
>>
>> kre
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/