Re: [dispatch] IETF "Royalty-Free" codecs

"Roni Even" <ron.even.tlv@gmail.com> Tue, 02 June 2009 05:27 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F7828C155 for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 22:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
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 twUSX1qrj0BA for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 22:26:58 -0700 (PDT)
Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id CAAF928C118 for <dispatch@ietf.org>; Mon, 1 Jun 2009 22:26:57 -0700 (PDT)
Received: by fxm12 with SMTP id 12so6230683fxm.37 for <dispatch@ietf.org>; Mon, 01 Jun 2009 22:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=WvklXu4UpdEccAY8udcHAVIIlxp2wWl9e5AQ3jqOV5k=; b=eYu8A6ZLWh6Qm46ykaguzDrf2k5SjPo3dwu6uvGHAxw6fGnPE7TO45rrz1uDLeY59V 9luxmWA2K0NdwHudK/cXkzZtMatq0qhPNeJON+7y112pqMLoKHDqx391LBcgxzWjPIJ5 Nf9LAoqr2vHf6gburkHjbnvYUm0Lm0FzzzC+8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=hSceelLDdTbYOAdunNdGkvdTIGXLnZVeLShUzULGnKdmUuqxhPta1aOPWY/mFZnk3q +bCq5GX+PVfFrrz1YwVp8DtxG4aD/HtkBLoFJR17Q4IK/61jwh7MzOKILimlxTD7yCqi B2TKgFJuWbgO2M/ISESWFt1JWqVfiHPZDbOFU=
Received: by 10.86.82.17 with SMTP id f17mr7456549fgb.65.1243920416374; Mon, 01 Jun 2009 22:26:56 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-180-78-211.red.bezeqint.net [79.180.78.211]) by mx.google.com with ESMTPS id 3sm1101530fge.9.2009.06.01.22.26.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 22:26:55 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: "'Michael Ramalho (mramalho)'" <mramalho@cisco.com>, dispatch@ietf.org
References: <AA847E176042A54CBB8BA283835E7BCEDEB92D@xmb-rtp-219.amer.cisco.com>
In-Reply-To: <AA847E176042A54CBB8BA283835E7BCEDEB92D@xmb-rtp-219.amer.cisco.com>
Date: Tue, 02 Jun 2009 08:25:51 +0300
Message-ID: <4a24b81f.0305560a.26e5.21dd@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C9E35B.C18BBF20"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acni/oz+T97fyHVwSuKgma6uS9ZeqgAQCldA
Content-Language: en-us
Subject: Re: [dispatch] IETF "Royalty-Free" codecs
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 05:27:08 -0000

Michael,

I think your observation is valid. As a matter of fact even at the ITU some
companies wanted to have "royalty free" codecs and as far as I know some of
the audio codecs like G.722.1C are royalty free.  (I am not sure about your
ITU WP3 work)

I think that you cannot write as part of the term of reference (or charter)
that the codec must be "royalty free" since this is a business decision for
the technology contributor and not a technical one and will probably be
against some of the competition laws in some countries.

 

Roni Even

 

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Michael Ramalho (mramalho)
Sent: Tuesday, June 02, 2009 12:19 AM
To: dispatch@ietf.org
Subject: [dispatch] IETF "Royalty-Free" codecs
Importance: Low

 

All, 

 

I have read, with some interest and comment, Jason Fischl's email proposing
a working group for codec development that would produce a "royalty-free"
codec designed "specifically for the Internet".

 

While one cannot always know if there is IPR "lurking" in something that
someone has built (i.e., an "unknowing" infringement on a 3rd party right),
the goal of designing a codec with "old or otherwise unencumbered"
technology is an idea worth pursuing.

 

I do note, as Roni Even did, that most of the of the "codec expertise"
resides in other SDO groups (such as ITU-T SG16, and ETSI). Most of those
subject matter experts are represented by companies that also participate in
the IEFT.

 

I also remember that AVT has been down this road before with iLBC (the
result being an EXPERIMENTAL RFC  - not a standards track RFC).

 

However, I have explicitly noted that other SDO groups such as ITU-T SG16
have NO APPARENT INTEREST in developing a "royalty-free" designs. In my
observation the ITU-T SG16 tends to focus on bringing the "best technology"
from participating members to create a codec that meets a given goal
(specified by a Terms of Reference, ToR, document). Since the requirements
are written from the perspective of what "new technology can do", they have
the tendency to rule out "old/known/existing" technology.

 

Thus, it doesn't appear to me that the ITU-T or similar groups would even
strive to have a goal of "royalty-free" as a codec design criteria.  And
that is OK, given the way they operate. They produce high-quality results
for the work they perform.

 

Additionally, some SDOs explicitly request that  "royalty", or
"royalty-free" statements NOT be made at their meetings except in a
narrow-context of what their company position is given the SDOs IPR policy.
In other words, detailed discussion of the IPR dimensions of the work are
not to be discussed when developing the codec.

 

So  given:

 

Given 1: There are a bunch of folks that desire to specify a codec that does
not KNOWINGLY infringe on IPR/patents (perhaps by using "old or previously
disclosed" technology),

 

Given 2: That no SDO organization that I know of that works on codec issues
explicitly allows the discussion of specific IPR issues or "royalties" in
their meetings, and

 

Given 3: That some IETF participants desire a codec that does not KNOWINGLY
infringe on IPR and can be made "royalty-free" (except for potentially
lurking IPR).

 

The questions (for me) become:

 

Question 1: Where is such work to be performed?

 

Corollary Question 1: Does anyone know of a SDO that would allow for the
criteria of "no known IPR" in the design?

 

Question 2: Assuming that the IETF would allow such a "royalty-free"
criteria and that this work COULD be performed here, are there enough
"qualified people" in the IETF to perform such work?

 

I don't know the answers to the above, but I would be interested in this
work.

 

Regardds,

 

Michael A. Ramalho, Ph.D.

 

<Jason's initial email on dispatch@ietf.org follows>

 

All,

 

I would like to request agenda time inside the DISPATCH meeting to propose

the formation of a new working group to define a Proposed Standard wideband

audio codec.

 

The text of the proposal is below. Comments, questions, and suggestions

welcomed.

 

Regards, 

Jason

 

 

Internet Wideband Audio Codec (IWAC)

Mailing Lists: TBD

Chairs: TBD

Area Directorate: Real Time Applications (RAI)

 

Purpose:

 

This new working group would be chartered with the purpose of collecting

expertise within the IETF in order to review the design of audio codecs

specifically for use with the Internet. Unlike other SDOs, these codecs

would be optimized for use on the Internet, and as much as possible choose

technology that does not require paying patent royalties.

 

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt

that subsequent work should not be done in the AVT working group. This new

working group will have as its primary purpose the standardization of a

multi-purpose audio codec that can be used in various situations on the

Internet. Some of the proposed Internet-specific requirements include:

* scalable and adaptive bit rate;

* various sampling rate profiles from narrow-band to super-wideband;

* scalable complexity;

* low latency; and 

* resilience to packet loss.

 

There are a number of wide-band capable codecs defined by other SDOs. For

instance, G.722 is seeing adoption in Enterprise applications since it is

relatively simple and low-cost to deploy. However, it has a high, fixed

bitrate and is not appropriate for mobile applications where spectrum

efficiency is important or in consumer applications where available

bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted

by the 3GPP as a wideband standard for mobile applications. G.722.2 is

relatively high cost due to patent royalties and is seeing minimal

deployments outside of mobile handsets making it challenging to create

wideband experiences on Internet-capable mobile devices when extending

beyond the mobile network. In other cases, proprietary codecs are being

adopted which further create islands with no interoperability unless

widespread transcoding is performed. Transcoding leads to higher costs and

lower quality. 

 

The goal of this working group is to define a single codec with multiple

profiles which can be made available on a wide variety of Internet-capable

devices including low-power, mobile devices as well as devices capable of

utilizing high quality, high bitrate audio.

 

Proposed Deliverables:

 

1) Requirements for wideband, Internet audio codec(s).

2) Algorithm description for wideband, Internet audio codec(s) as Proposed

Standard. 

3) Specification of payload format(s) for defined codecs as Proposed

Standard