Re: [codec] Last Call: <draft-ietf-codec-guidelines-05.txt> (Guidelines for the Codec Development Within the IETF) to Informational RFC

"Christian Hoene" <hoene@uni-tuebingen.de> Wed, 05 October 2011 21:33 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 1E35411E80F1; Wed, 5 Oct 2011 14:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FesQympaEy65; Wed, 5 Oct 2011 14:33:29 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2921D11E80C4; Wed, 5 Oct 2011 14:33:28 -0700 (PDT)
Received: from hoeneT60 (201-75-53-66-ma.cpe.vivax.com.br [201.75.53.66]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p95LaNoo030038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Oct 2011 23:36:33 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'Phillip Hallam-Baker' <hallam@gmail.com>, ietf@ietf.org
Date: Wed, 05 Oct 2011 17:36:36 -0400
Organization: Universitat Tubingen
Message-ID: <004a01cc83a6$e3e3aae0$abab00a0$@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: AcyDptguXQtUGNPMTyyDs/oLAq5o9Q==
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx05); id=31900-5oxFZ9
Cc: codec@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>
Subject: Re: [codec] Last Call: <draft-ietf-codec-guidelines-05.txt> (Guidelines for the Codec Development Within the IETF) to Informational RFC
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: Wed, 05 Oct 2011 21:33:30 -0000

Dear Phillip Hallam-Baker,

> I have some issues with the way that the section on IPR is written.
> While I agree with most of the statements there. I don't see my two
> biggest IPR concerns listed.
> 1) Specific to this document, we already have unencumbered CODECs that
> permit encoding of audio and video with acceptable fidelity and
> adequate compression for 95% of all purposes. Thus it is essential
> that the IPR regime for any future CODEC strictly limits the cost of
> using that technique to some portion of the cost savings from
> reduction in bandwidth use.

[Christian Hoene] Bandwidth vs. quality is just one out of many
characterizing features of a codec. Codecs also differ in latency,
complexity, switching characteristics, bandwidth scalability, APIs, etc. To
that respect, the WG codec is making a unique codec. 

Remember, at the successful codec BOF it was agreed that there is a need for
a new codec happing unique features. Or shall we start this discussion
again, here?

> 2) The principal concern I have with IPR licensing in general is not
> the cost of licensing but the difficulty of licensing. I have on
> several occasions been in negotiations with an IPR holder who is
> completely unable to decide how much money they want or on what terms
> they are willing to offer their IPR.

[Christian Hoene] Yes, this is also happening here - at least with one set
of IPR claims. 
But luckily, some very big players will lead us the way making the path
towards using the codec smoother. For example, if a big player would use the
codec in some open source projects, then many other small companies would
follow without doing all the negotiations and IPR checks.

 > 3) Linked to that is the problem of uncertainty. A purported rights
> holder can only grant a license for the rights they hold, they cannot
> and will not provide a warranty with respect to any other rights.
> While due to the lingering effects of submarine patents it is
> impossible to know if any CODEC is completely unencumbered, it is a
> very safe bet that the audio codecs used for cinema sound in the mid
> 1980s are now unencumbered. It is not possible to be confident that
> any new audio codec is unencumbered.

[Christian Hoene] Making a well-known, open source, and (hopefully)
standardized codec is an efficient way to figure out, whether somebody has
submarine patents. 
But then again, submarine patents may exist for any new technology, any
protocol, or any other codec out here.

> Taken in combination, I cannot imagine any reason to use any audio
> codec other than MP3 or AC2 (or some other similar legacy scheme) once
> we can be assured that the corresponding patents have expired. I
> really could not care less what fidelity or other benefits might be
> claimed for them. Bandwidth and storage are much cheaper than the
> financial benefits offered by the technology held by the rights
> holders.

[Christian Hoene] As said above, the Opus codec is going to be different and
we need it.

With best regards,

 Christian Hoene