[dispatch] IETF "Royalty-Free" codecs
"Michael Ramalho (mramalho)" <mramalho@cisco.com> Mon, 01 June 2009 21:18 UTC
Return-Path: <mramalho@cisco.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 F1F623A6B9A for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 14:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 7jrEQGzwTyqg for <dispatch@core3.amsl.com>; Mon, 1 Jun 2009 14:18:25 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E29F83A692E for <dispatch@ietf.org>; Mon, 1 Jun 2009 14:18:24 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.41,286,1241395200"; d="scan'208,217"; a="45794809"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2009 21:18:24 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n51LIORu008407 for <dispatch@ietf.org>; Mon, 1 Jun 2009 17:18:24 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n51LIO3O029964 for <dispatch@ietf.org>; Mon, 1 Jun 2009 21:18:24 GMT
Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jun 2009 17:18:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E2FE.7F85F402"
Date: Mon, 01 Jun 2009 17:18:47 -0400
Message-ID: <AA847E176042A54CBB8BA283835E7BCEDEB92D@xmb-rtp-219.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IETF "Royalty-Free" codecs
Thread-Index: Acni/oz+T97fyHVwSuKgma6uS9Zeqg==
X-Priority: 5
Priority: Non-Urgent
Importance: low
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: dispatch@ietf.org
X-OriginalArrivalTime: 01 Jun 2009 21:18:24.0728 (UTC) FILETIME=[7F9C2580:01C9E2FE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24760; t=1243891104; x=1244755104; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20<mramalho@c isco.com> |Subject:=20IETF=20=22Royalty-Free=22=20codecs |Sender:=20 |To:=20<dispatch@ietf.org>; bh=I5yyf7XQnGwFWzlwgxYMQOF/J51LLTlmGEyt97mGRWc=; b=XvJFhG+qWuECiXcIFTTQJ+qf6qhKKi9dfGGkefjcYqHh+CGhFzEdhhWdZj Il+erb8ZELPxBpxacULSZuUkIoEWLgrcV+Cr1MOAKYcVsvInJyAbouqXxO3P DVt87lSleu;
Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Mailman-Approved-At: Mon, 01 Jun 2009 14:23:10 -0700
Subject: [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: Mon, 01 Jun 2009 21:18:34 -0000
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
- [dispatch] IETF "Royalty-Free" codecs Michael Ramalho (mramalho)
- Re: [dispatch] IETF "Royalty-Free" codecs Roni Even