From internet-drafts@ietf.org Sun Oct 2 22:10:05 2011 Return-Path: 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 12AAE21F8678; Sun, 2 Oct 2011 22:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 k4fymaJ3k8kS; Sun, 2 Oct 2011 22:10:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6245F21F85FF; Sun, 2 Oct 2011 22:10:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111003051003.18908.83185.idtracker@ietfa.amsl.com> Date: Sun, 02 Oct 2011 22:10:03 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-guidelines-05.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 05:10:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Guidelines for the Codec Development Within the IETF Author(s) : Jean-Marc Valin Slava Borilin Koen Vos Christopher Montgomery Raymond (Juin-Hwey) Chen Filename : draft-ietf-codec-guidelines-05.txt Pages : 19 Date : 2011-10-02 This document provides general guidelines for work on developing and specifying a codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-guidelines-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-guidelines-05.txt From rjsparks@nostrum.com Wed Oct 5 09:01:24 2011 Return-Path: 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 2B21521F8D4A for ; Wed, 5 Oct 2011 09:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 U6Ipj2GqSfPg for ; Wed, 5 Oct 2011 09:01:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3921F8D42 for ; Wed, 5 Oct 2011 09:01:23 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p95G4Ukj014687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Oct 2011 11:04:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Robert Sparks In-Reply-To: <20111003051003.18908.83185.idtracker@ietfa.amsl.com> Date: Wed, 5 Oct 2011 11:04:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <37429858-4FBC-4F9A-86D6-D4B92D3F7F05@nostrum.com> References: <20111003051003.18908.83185.idtracker@ietfa.amsl.com> To: codec@ietf.org X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [codec] I-D Action: draft-ietf-codec-guidelines-05.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:01:24 -0000 Thanks for this revision - watch for the announcement of IETF Last Call = soon. There is one point from the AD review that this revision doesn't = sufficiently address - please address it with any other IETF Last Call comments: * Section 4 Item 1 should be scoped to codecs produced by this working = group - the sentence right now appears to try to place a requirement on any future work done = on codecs in the IETF. I suggest s/the IETF/the CODEC working group/ RjS On Oct 3, 2011, at 12:10 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Internet Wideband Audio = Codec Working Group of the IETF. >=20 > Title : Guidelines for the Codec Development Within = the IETF > Author(s) : Jean-Marc Valin > Slava Borilin > Koen Vos > Christopher Montgomery > Raymond (Juin-Hwey) Chen > Filename : draft-ietf-codec-guidelines-05.txt > Pages : 19 > Date : 2011-10-02 >=20 > This document provides general guidelines for work on developing and > specifying a codec within the IETF. These guidelines cover the > development process, evaluation, requirements conformance, and > intellectual property issues. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-codec-guidelines-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-guidelines-05.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From iesg-secretary@ietf.org Wed Oct 5 09:12:47 2011 Return-Path: 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 CC8DE21F8CA3; Wed, 5 Oct 2011 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7+1tTCbRVeXh; Wed, 5 Oct 2011 09:12:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6965221F8BEB; Wed, 5 Oct 2011 09:12:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111005161247.1554.47741.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 09:12:47 -0700 Cc: codec@ietf.org Subject: [codec] Last Call: (Guidelines for the Codec Development Within the IETF) to Informational RFC X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:12:48 -0000 The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Guidelines for the Codec Development Within the IETF' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides general guidelines for work on developing and specifying a codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ No IPR declarations have been submitted directly on this I-D. From hallam@gmail.com Wed Oct 5 13:22:25 2011 Return-Path: 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 7BB0211E8103; Wed, 5 Oct 2011 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 IdY3rF2iG0UD; Wed, 5 Oct 2011 13:22:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1811921F8B6D; Wed, 5 Oct 2011 13:22:22 -0700 (PDT) Received: by yxt33 with SMTP id 33so2378379yxt.31 for ; Wed, 05 Oct 2011 13:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hOex914GLKyK710+ikdpXkY3kSwt1G9X8rixsmieZJY=; b=VzTbSug2w45Juw2jeK7hzMnNJ4U0IcdnyOW7bQXHLAGkFHQpiQZkfr0+hYy+xzoU0r KnhFnhajEg59k9pTOuStn54+sHKLrLqAGZIl62E0X88OulTm/pJa9TOnt9ZjrfMWpfDd 12kJCxfwqSOlOCHwmZtKUhCEYSwu7HrG0qodg= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr2434235ani.74.1317846329714; Wed, 05 Oct 2011 13:25:29 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Wed, 5 Oct 2011 13:25:29 -0700 (PDT) In-Reply-To: <20111005161247.1554.47741.idtracker@ietfa.amsl.com> References: <20111005161247.1554.47741.idtracker@ietfa.amsl.com> Date: Wed, 5 Oct 2011 16:25:29 -0400 Message-ID: From: Phillip Hallam-Baker To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org, IETF-Announce Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:22:25 -0000 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. 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. 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. 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. The situation is very slightly different for video codecs, but not by a great deal. So the overall experience has been that it is like trying to negotiate the purchase of some fancy-schmancy kitchen cabinets from some guy who hasn't a clue about business but is desperate to make sure that they don't leave a penny on the table even if his dithering about is likely to cost him the business. Meanwhile you can get a perfectly serviceable set of cabinets from Home Depot and Lowes where they will give you price on the page ordering. In this case there is a free alternative in almost every application worth bothering about. On Wed, Oct 5, 2011 at 12:12 PM, The IESG wrote: > > The IESG has received a request from the Internet Wideband Audio Codec WG > (codec) to consider the following document: > - 'Guidelines for the Codec Development Within the IETF' > =A0 as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-10-19. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > =A0 This document provides general guidelines for work on developing and > =A0 specifying a codec within the IETF. =A0These guidelines cover the > =A0 development process, evaluation, requirements conformance, and > =A0 intellectual property issues. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --=20 Website: http://hallambaker.com/ From hoene@uni-tuebingen.de Wed Oct 5 14:33:30 2011 Return-Path: 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" To: "'Phillip Hallam-Baker'" , Date: Wed, 5 Oct 2011 17:36:36 -0400 Organization: =?us-ascii?Q?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' Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From giles@thaumas.net Wed Oct 5 14:41:25 2011 Return-Path: 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 7786511E8115; Wed, 5 Oct 2011 14:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 9Q7PHpZqatdG; Wed, 5 Oct 2011 14:41:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6B11E80C2; Wed, 5 Oct 2011 14:41:24 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2192185vcb.31 for ; Wed, 05 Oct 2011 14:44:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.40 with SMTP id q8mr3012878vdv.254.1317851072926; Wed, 05 Oct 2011 14:44:32 -0700 (PDT) Received: by 10.220.200.195 with HTTP; Wed, 5 Oct 2011 14:44:32 -0700 (PDT) X-Originating-IP: [184.71.166.126] In-Reply-To: References: <20111005161247.1554.47741.idtracker@ietfa.amsl.com> Date: Wed, 5 Oct 2011 14:44:32 -0700 Message-ID: From: Ralph Giles To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: codec@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:41:25 -0000 On 5 October 2011 13:25, Phillip Hallam-Baker wrote: > 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'm not familiar with AC2, but if you mean traditional audio codecs like MP3, AC3, and Vorbis, these all have a high encoding (and decoding) latency which makes them unsuitable for interactive applications. Addressing that, as much as the (almost 4-fold!) bandwidth reduction over legacy codecs, is what we're trying achieve with this working group. This is reflected in the requirements document published as RFC 6366 where low coding latency is a primary attribute of each use case. That doesn't have much to do with your comments on the other IPR issues, but I hope it explains why we can't just use mp3. Separately, mp3 is in fact still covered by patents, at least according to wikipedia[2], so that is not an IPR free solution for some years yet, even if it were technically suitable. -r [1] http://tools.ietf.org/html/rfc6366 [2] http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues From stewe@stewe.org Wed Oct 5 15:13:40 2011 Return-Path: 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 ACCF821F8C93; Wed, 5 Oct 2011 15:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599] 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 tqGLf5uG9qZO; Wed, 5 Oct 2011 15:13:39 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5921F8C92; Wed, 5 Oct 2011 15:13:36 -0700 (PDT) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 46274-1743317 for multiple; Thu, 06 Oct 2011 00:16:44 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 05 Oct 2011 15:16:18 -0700 From: Stephan Wenger To: Phillip Hallam-Baker Message-ID: Thread-Topic: [codec] Last Call: (Guidelines for the Codec Development Within the IETF) to Informational RFC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 22:13:40 -0000 Phillip, Please see inline. On 10.5.2011 13:25 , "Phillip Hallam-Baker" wrote: >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. I disagree for technical reasons that have already been pointed out by others. I would also suggest that something like AAC, according to your theory, should have never happened (as it covers essentially the same application space as MP3, with moderate gains in the quality/bitrate tradeoff), but it a) was standardized--in the same body as MP3, and b) was and is a commercial success, despite being quite expensive. >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. The IETF is certainly not in the business of regulating how licensing discussions are to be arranged :-) (Never mind that they can be quite frustrating, as, apparently, both of us know). >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. All what you write above is true. >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. Well, many folks actually do license, under sometimes expensive terms, protected technology, and use them to their benefit. >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. That your position. It's a position many of the opus proponents would probably share, even if you were broadening the technical features to include other alleged goodies of "opus". However, it's not the only reasonable position. Depending on your business model, and the business model of the rights holders, there are many situations where picking a licensing, and paying for it, is to the advantage of a rights taker. > >The situation is very slightly different for video codecs, but not by >a great deal. > > >So the overall experience has been that it is like trying to negotiate >the purchase of some fancy-schmancy kitchen cabinets from some guy who >hasn't a clue about business but is desperate to make sure that they >don't leave a penny on the table even if his dithering about is likely >to cost him the business. Meanwhile you can get a perfectly >serviceable set of cabinets from Home Depot and Lowes where they will >give you price on the page ordering. In this case there is a free >alternative in almost every application worth bothering about. Your email ends here. Now I'm at loss. Is your position that A) the section on IPR be modified with an explanation of the commercial constraints you have described, B) the section be modified to gate the issue of an RFC defining an IETF codec on terms compatible with YOUR commercial constraints you have described, or C) something else? If your choice is B), would you care describing how your request is supported by the IETF's patent policy? Stephan > > >On Wed, Oct 5, 2011 at 12:12 PM, The IESG wrote: >> >> The IESG has received a request from the Internet Wideband Audio Codec >>WG >> (codec) to consider the following document: >> - 'Guidelines for the Codec Development Within the IETF' >> as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-10-19. Exceptionally, comments may >>be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document provides general guidelines for work on developing and >> specifying a codec within the IETF. These guidelines cover the >> development process, evaluation, requirements conformance, and >> intellectual property issues. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From hallam@gmail.com Wed Oct 5 18:38:10 2011 Return-Path: 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 F3EFC21F8D90; Wed, 5 Oct 2011 18:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] 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 buMhQaaa1Zdl; Wed, 5 Oct 2011 18:38:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB04A21F8D8E; Wed, 5 Oct 2011 18:38:08 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2322181vcb.31 for ; Wed, 05 Oct 2011 18:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M/JiZw+BXz6FJ1AstaZuAV2v7QGj8w1oaFfssc4OUbI=; b=OqaVf8d0U9pdVu2rPHtrE3+rk2r9FEH60yQP4QqKNl6Kvjpa5dw3/ATkZu1DAJgOwu 5F+10IHBmQ9x26BUBUKSvRr4986Uh2M3ZSgk8rmQ9CJ3JyS6rPpBAIfMsxBrjB2kCc2t LY04JF3l2YfVdoCnSFe4StmscXkjG43ZL1t8Y= MIME-Version: 1.0 Received: by 10.220.6.193 with SMTP id a1mr32281vca.257.1317865276722; Wed, 05 Oct 2011 18:41:16 -0700 (PDT) Received: by 10.220.192.12 with HTTP; Wed, 5 Oct 2011 18:41:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 21:41:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 01:38:10 -0000 On Wed, Oct 5, 2011 at 6:16 PM, Stephan Wenger wrote: > Phillip, > Please see inline. > > On 10.5.2011 13:25 , "Phillip Hallam-Baker" wrote: > >>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. > > I disagree for technical reasons that have already been pointed out by > others. =A0I would also suggest that something like AAC, according to you= r > theory, should have never happened (as it covers essentially the same > application space as MP3, with moderate gains in the quality/bitrate > tradeoff), but it a) was standardized--in the same body as MP3, and b) wa= s > and is a commercial success, despite being quite expensive. I said that adopting a new encumbered algorithm would be stupid. At no time did I say that stupid did not happen. For evidence to the contrary see Planet:Earth Frequently IPR holders will attempt to prolong the validity of their patents by making minor tweaks of dubious technical value. What I said was that if any new CODEC is going to be accepted, the cost of using that CODEC must be strictly limited to the value that is provided in terms of limiting the number of bits required. In other words, I do not want to be paying for the patent that enables me to do Internet telephony since that can be achieved quite acceptably with no compression whatsoever. I may be willing to pay $X for a patent that allows savings significantly greater than $X. Unfortunately the current draft seems to me to be saying 'free is good but we might have to pay'. I think the presumption should be that there will be no payment for this particular application for reasons that go beyond the general preference for free. >>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. > > The IETF is certainly not in the business of regulating how licensing > discussions are to be arranged :-) =A0(Never mind that they can be quite > frustrating, as, apparently, both of us know). Again, mu law is seriously out of patent. No conversations with wolves or lawyers required. > All what you write above is true. > >>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. > > Well, many folks actually do license, under sometimes expensive terms, > protected technology, and use them to their benefit. MP3 became the standard for audio because it was the only widely supported option. Dolby Digital offered somewhat better fidelity and multi-tracks. But those technologies are close to twenty years old and the patents should be nearing expiry or have already expired. > Your email ends here. =A0Now I'm at loss. > > Is your position that > A) the section on IPR be modified with an explanation of the commercial > constraints you have described, > B) the section be modified to gate the issue of an RFC defining an IETF > codec on terms compatible with YOUR commercial constraints you have > described, or > C) something else? I was arguing for A. If we are talking about IPR we are inevitably talking about commercial terms. I would like IPR holders in this space to understand that this is not going to be the normal patent beauty contest that has been the norm in this space for the past 20 odd years. I am quite aware of the licensing schemes employed in the MPEG world and really don't have much good to say about it. --=20 Website: http://hallambaker.com/ From gmaxwell@juniper.net Wed Oct 5 22:04:23 2011 Return-Path: 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 99FA021F8D21 for ; Wed, 5 Oct 2011 22:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, 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 KB5ARjwmed-U for ; Wed, 5 Oct 2011 22:04:22 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5340521F8C75 for ; Wed, 5 Oct 2011 22:04:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Oct 2011 22:07:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 5 Oct 2011 22:03:22 -0700 From: Gregory Maxwell To: Phillip Hallam-Baker Date: Wed, 5 Oct 2011 22:03:22 -0700 Thread-Topic: [codec] Last Call: (Guidelines for the Codec Development Within the IETF) to Informational RFC Thread-Index: AcyDyRR4GyNeJDePROC2z3mjhpR0IAAFM4az Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 05:04:23 -0000 Phillip Hallam-Baker [hallam@gmail.com]: [snip] > Unfortunately the current draft seems to me to be saying 'free is good > but we might have to pay'. I think the presumption should be that > there will be no payment for this particular application for reasons > that go beyond the general preference for free. I believe you're reading meaning into the draft that isn't there. To my eyes the draft affirms and elaborates on the kind of trade-offs your mentioning here=97 that it acknowledges that RF status plays an important role in actually getting a codec adopted on the Internet. It then leaves it to the working group participants to drive for a solution that meets their needs on an overall basis: If the working group is going in a direction that doesn't meet your needs then propose fixes. draft-ietf-codec-guidelines-05.txt - section 5 states: >Therefore, a codec that can be widely implemented and easily >distributed among application developers, service operators, and end >users is preferred.[...]Because such encumbrances have made it difficult t= o >widely implement and easily distribute high-quality codecs across the >entire Internet community, the working group prefers unencumbered >technologies in a way that is consistent with BCP 78 and BCP 79. In >particular, the working group shall heed the preference stated in BCP >79: "In general, IETF working groups prefer technologies with no >known IPR claims or, for technologies with claims against them, an >offer of royalty-free licensing." Although this preference cannot >guarantee that the working group will produce an unencumbered codec, >the working group shall follow BCP 79, and adhere to the spirit of >BCP 79. The working group cannot explicitly rule out the possibility >of adopting encumbered technologies; however, the working group will >try to avoid encumbered technologies that require royalties or other >encumbrances that would prevent such technologies from being easy to >redistribute and use. I might have liked it better if we could have drafted different language or wrote into the charter different requirements, but there are practical, political, and legal complications with writing hard requirements related to IPR. You already raised the practical point: Practically, we have the issue that non-infringement is non-computable. It is generally uneconomical to convince someone that it is _proven_ that something is absent any possible infringement, especially if they benefit from being unconvinced. (Though submarine patents don't exist anymore, fwiw) This means that any requirement would always require the execution of judgment: "based on what you know, will the result meet your needs?" Anything that was a harder rule than that would be highly vulnerable to sabotage by parties with conflicting interests. You can't even say that _old_ technology is okay with complete certainty, because new (and from your perspective) trivial applications of old tech can be patentable. Also, patents are presumed to be valid so if someone manages to get a patent on something old through the system (which appears to be pretty easy to do) you still have a large burden to get the patent invalidated=97 for many business models, OSS developers, etc. even the most frivolous of patent litigation is just as deadly as the most solid. Likewise, for many parties the interesting IPR risk isn't= =20 the cost of losing, it's the cost of having the fight. Certainly using older techniques is persuasive, has a large benefit in terms of practical IPR attack resistance, and is a technique used in the development of the codec draft. But it is not _proof_. Politically, the subject of IPR requirements in the IETF is a complicated one with a long history. While some would love to continue the debate about IETF policy in yet another forum=97 but the people gathered here actually want to address a codec need, rehashing IETF IPR policy is not a good way to get actual work done. The IETF IPR policy doesn't actually or in practice prohibit royalty free work even when it fails to mandate it, which is sufficient for actually getting the work done. Legally, it's believed by some that it would actually be unlawful for the working group to have a hard royalty free requirement. I, personally, think this is an unreasonable concern in this context where we have the actual developers of codecs who prefer RF (and who will happily and aggressively remove, design around, etc any IPR they become aware of which can't be made available RF). But it's an earnestly held concern, and a law breaking working group isn't something anyone would want to be involved in. So the language in the guidelines (and the approved WG charter) is a best effort attempt to navigate around those issues. Part of the compromise is that it leaves open some of what I (and probably you) would consider failure modes. Realistically, I think if we were to fail that way we couldn't have been successful regardless of the language in the guidelines. ("The working group is not permitted to fail" would be a lovely but sadly unrealistic rule too :) ) Most importantly it replaces the highly political IPR issue with one that we're more competent to deal with here: As practitioners of internet technology the people around the WG and the IETF have far more expertise about what people will and won't deploy on the internet then we have about the nuanced legal technicalities. And by stating our requirement in terms of a consensus about the practical usability also addressing what matters most. If I've horribly misunderstood your position it may be helpful to me to drill it down to the specific language in the draft that is the source of the contention and attach specific examples about how that language will lead to outcomes which are not productive for the internet community. Cheers, From jdrosen@jdrosen.net Wed Oct 12 14:31:48 2011 Return-Path: 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 A1FF621F8B35 for ; Wed, 12 Oct 2011 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 ykR6x4j8C3LR for ; Wed, 12 Oct 2011 14:31:48 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.52.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1145F21F8B2E for ; Wed, 12 Oct 2011 14:31:48 -0700 (PDT) Received: from pool-173-63-39-69.nwrknj.fios.verizon.net ([173.63.39.69]:61745 helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RE6Ox-0002PF-3n for codec@ietf.org; Wed, 12 Oct 2011 17:31:47 -0400 Message-ID: <4E960743.5020800@jdrosen.net> Date: Wed, 12 Oct 2011 17:31:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: codec@ietf.org References: <4E52C241.2010208@jdrosen.net> <4E67BC0D.9070208@jdrosen.net> <6A58A83F7040374B9FB4EEEDBD835512A3FB7C@LHREML503-MBX.china.huawei.com> <20110908222842.GW17064@audi.shelbyville.oz> <027A93CE4A670242BD91A44E37105AEF2EE0FAA404@ESESSCMS0351.eemea.ericsson.se> <4E6A356C.3000900@stpeter.im> <4E6A3717.9010802@mozilla.com> In-Reply-To: <4E6A3717.9010802@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: Re: [codec] Adopt draft-valin-codec-results as a working group item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 21:31:48 -0000 The chairs believe that there is consensus to adopt this document as a working group item in fulfillment of our chartered deliverable. The proposal to move sections 2 and 3 to an appendix seems reasonable, and we can continue to discuss this and other changes to the document as we evolve it. Thanks, Jonathan R. On 9/9/2011 11:56 AM, Jean-Marc Valin wrote: > On 09/09/11 11:49 AM, Peter Saint-Andre wrote: >> I suggest that Sections 2 and 3 could be moved to an Appendix. The >> information presented in those sections is of interest but doesn't >> deserve to be the main focus. >> > > Sounds reasonable. > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From fluffy@cisco.com Mon Oct 17 17:41:39 2011 Return-Path: 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 75B0421F84AC for ; Mon, 17 Oct 2011 17:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 AfJ9wpJIoGwF for ; Mon, 17 Oct 2011 17:41:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E95D921F84AB for ; Mon, 17 Oct 2011 17:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=216; q=dns/txt; s=iport; t=1318898499; x=1320108099; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=FlYMHlNBRKxFrlmxB6f8Oid5z4l3l+osdbSX5cJTjD4=; b=AMFVVKl3LZ6FVi4Z3v/OdNqStO5MN0uPGtr3dfKOCBppgRpgJWr33vDd lqW93c0u4zCR80MIKjwI3UfVKbsBXzuVMtv25MNePXbxWEjnhppOHJR1i v+0z4dEnt6/CSHNX+IxD4UoxqgWwsRCSF5QDKft7o7DYwThrW3/LrALE/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEHAJDKnE6rRDoJ/2dsb2JhbABDmXWOY4EFgW4BAQEBAgESAXZRVzuHXZgJAZAwjlaHJ2EEiAKLe5F1 X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208";a="8466140" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2011 00:41:38 +0000 Received: from dhcp-171-68-21-243.cisco.com (dhcp-171-68-21-243.cisco.com [171.68.21.243]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9I0fcC1028750 for ; Tue, 18 Oct 2011 00:41:38 GMT From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 17:41:37 -0700 References: <20111013185249.1247.59184.idtracker@ietfa.amsl.com> To: codec@ietf.org Message-Id: <275364A3-010F-4668-8128-77420D40F7BF@cisco.com> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [codec] CODEC scheduled for IETF 82 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:41:39 -0000 FYI =85 hopefully this will not change =85 >=20 >=20 > codec Session 1 (2 hours) > Wednesday, Afternoon Session I 1300-1500 > Room Name: 101C > --------------------------------------------- >=20 From paulbeaumont.ietf@gmail.com Tue Oct 18 16:01:34 2011 Return-Path: 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 8316C21F8AC3 for ; Tue, 18 Oct 2011 16:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cc2+BIT36Y50 for ; Tue, 18 Oct 2011 16:01:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C100F21F8ABC for ; Tue, 18 Oct 2011 16:01:33 -0700 (PDT) Received: by wyh22 with SMTP id 22so1280173wyh.31 for ; Tue, 18 Oct 2011 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=PfZd4k1fT7FzuPK4/0YjMe4F1svPdcBRA7VfIXaZLts=; b=K0NkD5YT84OB3moBdJ3dTNTglEc88+jW9EDos2Ah5p2SqwMwEhP2m+xCplycIe7IiQ etqA+zizAqm8WZsh5Mdp8ZcflNXsxtc48XjlzArFPyBEwOfHbedXFiTRUplld9M/Nm/f O3wSjAsSCGFICk9hpADS+x6QZzqnAvK7sUziU= Received: by 10.216.54.20 with SMTP id h20mr1500947wec.97.1318978892924; Tue, 18 Oct 2011 16:01:32 -0700 (PDT) Received: from [192.168.0.7] (5e03bd2c.bb.sky.com. [94.3.189.44]) by mx.google.com with ESMTPS id q30sm6277021wbn.17.2011.10.18.16.01.27 (version=SSLv3 cipher=OTHER); Tue, 18 Oct 2011 16:01:31 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 19 Oct 2011 00:01:23 +0100 From: Paul Beaumont To: Jan Skoglund , IETF - CoDec Message-ID: Thread-Topic: [codec] Listening tests at Google In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [codec] Listening tests at Google X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:01:34 -0000 Hi Jan Thank you for performing and sharing the results of your testing. Please can you summarise what you see as the key findings wrt ... 1). Opus on Mandarin speech - be good to baseline this against comparable English speech results and 2). Opus when Transcoded/Tandemed Regards Paul -- On 14/09/2011 06:59, "Jan Skoglund" wrote: >Hey, > >The listening tests at Google are now done and here are the results. > >Regards, >Jan > > >On Fri, Aug 19, 2011 at 3:28 PM, Jan Skoglund wrote: >> Hey, >> >> We've prepared some listening tests for Opus on Mandarin speech and >> transcoding (English) speech at Google. We started the tests today and >> will have results at the end of August. The tests are split in four >> MUSHRA groups: >> >> Test 1a - Mandarin NB >> -------------------------- >> Opus NB >> Speex NB >> iLBC NB >> Reference and 2 anchors (LP 3.5 kHz and MNRU of 15 dB) >> >> Test 1b - Mandarin "HD Voice" (WB, FB) >> -------------------------------------------------------- >> Opus FB >> G.719 FB >> Opus WB >> Speex WB >> G.722.1 WB >> Reference and 2 anchors (LP 3.5 kHz and LP 7 kHz) >> >> Test 2a - Transcoding NB >> ------------------------------- >> G.711 -> Opus NB >> G.711 -> AMR-NB >> Opus NB -> G.711 -> AMR-NB >> AMR-NB -> G.711 -> Opus NB >> AMR-NB -> G.711 -> AMR-NB >> Reference and 2 anchors (LP 3.5 kHz and MNRU of 15 dB) >> >> Test 2b - Transcoding WB >> -------------------------------- >> Opus WB >> AMR-WB >> Opus WB -> AMR-WB >> AMR-WB -> Opus WB >> Reference and 2 anchors (LP 3.5 kHz and LP 7 kHz) >> >> >> Cheers, >> Jan >> >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jks@google.com Thu Oct 20 07:33:11 2011 Return-Path: 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 8DB6421F8C2F for ; Thu, 20 Oct 2011 07:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 eLVUJ3zjOoKw for ; Thu, 20 Oct 2011 07:33:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6E21F8C2B for ; Thu, 20 Oct 2011 07:33:10 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p9KEX9An029300 for ; Thu, 20 Oct 2011 07:33:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319121189; bh=LZ6GPMAz5eblnQ3qHrgEiijeWN4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=f3Jw2F4FZFhIH6EMMLkncifanRews25rEBVONBrnJ2Lshslyft8/W2M8eGQt1ln2g JOu6y2hzVklIEEbF2YljA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=snssXSJEIkACTPZZ5V0UL7perVj7b49Zaf9V84Kq5LPiZJtzdqO3jNkyd9MsL25fX UsaH8joO1Q5fGz7LEUdag== Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by hpaq5.eem.corp.google.com with ESMTP id p9KEVBLl017087 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 20 Oct 2011 07:33:08 -0700 Received: by gyd8 with SMTP id 8so4042355gyd.2 for ; Thu, 20 Oct 2011 07:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=1mZB556aKn9+aul2odqXjC31rBEojEYVtv7eEFAhdf8=; b=nTs4QyKYak5mdGVKppsdv9otmxPgwceXEXyJgKqhF9n3hGTm6RlZeox9QUTf31rKpc ezEbO56SlxQmm914YkaQ== Received: by 10.229.86.145 with SMTP id s17mr2469644qcl.36.1319121188572; Thu, 20 Oct 2011 07:33:08 -0700 (PDT) Received: by 10.229.86.145 with SMTP id s17mr2469633qcl.36.1319121188282; Thu, 20 Oct 2011 07:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.91.129 with HTTP; Thu, 20 Oct 2011 07:32:48 -0700 (PDT) In-Reply-To: References: From: Jan Skoglund Date: Thu, 20 Oct 2011 10:32:48 -0400 Message-ID: To: Paul Beaumont Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: IETF - CoDec Subject: Re: [codec] Listening tests at Google X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:33:11 -0000 Hey, Sure, 1) For narrowband Mandarin speech Opus at 11 kbps is comparable to iLBC at 15 kbps and superior to Speex at 11 kbps. In the previous tests with English speech Opus outperformed them both, so there was a (small) difference. For wideband/fullband speech a striking observation is that Opus at 32 kbps is (again) almost transparent, although there is a small and statistically significant difference from the fullband reference material. Opus at 32 kbps is also better than G.719 at the same bit rate. Opus at 20 kbps is not only better than Speex at 24 kbps and G.722.1 at 24 kbps, it is also better than the reference signal low-passed at 7 kHz. This is likely due to its high quality and its higher signal bandwidth (8 kHz). These results are pretty consistent with the previous results for English speech, with the difference that in the previous test Opus at 20 kbps outperformed G.719 at 32 kbps, which it did not this time. 2) Pre-coding Opus NB with G.711 is comparable to pre-coding AMR NB with G.711. Adding one stage of transcoding reduces the performance slightly (although statistically significant). Transcoding AMR NB with itself through G.711 is worse than transcoding AMR NB to Opus through G.711 or the other way around. Opus WB at 19.85 kbps is again better than speech LP-filtered at 7.0 kHz, as in the Mandarin and English speech tests. Single-coded AMR WB is significantly worse than single-coded Opus WB, also consistent with previous tests. Transcoding Opus and AMR WB is only slightly worse than AMR WB, although the difference is statistically significant. Jan On Tue, Oct 18, 2011 at 7:01 PM, Paul Beaumont wrote: > Hi Jan > > Thank you for performing and sharing the results of your testing. > > Please can you summarise what you see as the key findings wrt ... > > 1). Opus on Mandarin speech - be good to baseline this against comparable > English speech results and > 2). Opus when Transcoded/Tandemed > > Regards > Paul > > -- > > On 14/09/2011 06:59, "Jan Skoglund" wrote: > >>Hey, >> >>The listening tests at Google are now done and here are the results. >> >>Regards, >>Jan >> >> >>On Fri, Aug 19, 2011 at 3:28 PM, Jan Skoglund wrote: >>> Hey, >>> >>> We've prepared some listening tests for Opus on Mandarin speech and >>> transcoding (English) speech at Google. We started the tests today and >>> will have results at the end of August. The tests are split in four >>> MUSHRA groups: >>> >>> Test 1a - Mandarin NB >>> -------------------------- >>> Opus NB >>> Speex NB >>> iLBC NB >>> Reference and 2 anchors (LP 3.5 kHz and MNRU of 15 dB) >>> >>> Test 1b - Mandarin "HD Voice" (WB, FB) >>> -------------------------------------------------------- >>> Opus FB >>> G.719 FB >>> Opus WB >>> Speex WB >>> G.722.1 WB >>> Reference and 2 anchors (LP 3.5 kHz and LP 7 kHz) >>> >>> Test 2a - Transcoding NB >>> ------------------------------- >>> G.711 -> Opus NB >>> G.711 -> AMR-NB >>> Opus NB -> G.711 -> AMR-NB >>> AMR-NB -> G.711 -> Opus NB >>> AMR-NB -> G.711 -> AMR-NB >>> Reference and 2 anchors (LP 3.5 kHz and MNRU of 15 dB) >>> >>> Test 2b - Transcoding WB >>> -------------------------------- >>> Opus WB >>> AMR-WB >>> Opus WB -> AMR-WB >>> AMR-WB -> Opus WB >>> Reference and 2 anchors (LP 3.5 kHz and LP 7 kHz) >>> >>> >>> Cheers, >>> Jan >>> >>_______________________________________________ >>codec mailing list >>codec@ietf.org >>https://www.ietf.org/mailman/listinfo/codec > > > From butrus.butrus@gmail.com Thu Oct 20 08:39:34 2011 Return-Path: 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 6307721F8C8A for ; Thu, 20 Oct 2011 08:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Vk8j4OUkRjwI for ; Thu, 20 Oct 2011 08:39:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC16C21F8C88 for ; Thu, 20 Oct 2011 08:39:33 -0700 (PDT) Received: by wwe6 with SMTP id 6so3028170wwe.13 for ; Thu, 20 Oct 2011 08:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OmE3UrXGVU/VbPX/l4eP6GpeFf66nregNrcNbQYH+wM=; b=ZA/xfZhbCArhPPoQBynePVpR9XvXWkw2fQk2SNCuQQl3J8Dh9UxJnkaaxO8oD/euKl XU+wwYEHB36So5cUs+JK1qVL0BPUKLpfU8QeSJ2dtDlC1yNnuJbPmeW0lx14Zs7Nue9p Nb1ldY19GivfoHv0+hw8SUSdqpqYO0TNUrN6k= MIME-Version: 1.0 Received: by 10.227.170.8 with SMTP id b8mr4227081wbz.79.1319125172844; Thu, 20 Oct 2011 08:39:32 -0700 (PDT) Received: by 10.227.199.70 with HTTP; Thu, 20 Oct 2011 08:39:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 17:39:32 +0200 Message-ID: From: Butrus Damaskus To: Jan Skoglund Content-Type: text/plain; charset=UTF-8 Cc: IETF - CoDec Subject: Re: [codec] Listening tests at Google X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:39:34 -0000 On Thu, Oct 20, 2011 at 4:32 PM, Jan Skoglund wrote: > These results are pretty consistent > with the previous results for English speech, with the difference that > in the previous test Opus at 20 kbps outperformed G.719 at 32 kbps, > which it did not this time. Does it mean that there is a regression or is it rather due to the character of the Mandarine speech? From jks@google.com Fri Oct 21 12:59:38 2011 Return-Path: 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 8C89C11E8088 for ; Fri, 21 Oct 2011 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 b45QwHxUdOVL for ; Fri, 21 Oct 2011 12:59:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 104DB11E8082 for ; Fri, 21 Oct 2011 12:59:37 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p9LJxaGx019893 for ; Fri, 21 Oct 2011 12:59:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319227177; bh=W/rrGbXX/v8hv1+S6AUkFBjCoM0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YUXV3HOjiFmZ4Mp72Pmv9NLadqrPmCHZhCnzEFy1AciVPki08hfDrKgyeMdjIbmC0 bB+5YmZFheBIcDXsAAPUw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Yuc+FzxfcGdg6dYP5KgfZSZK+jWSn6CLj89hNLpNEf7ODHqTOBh+AX5Q0JWe9kyNd LDavVFtj3TVwBBW7PnFDA== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by hpaq2.eem.corp.google.com with ESMTP id p9LJw7Ji006522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 21 Oct 2011 12:59:36 -0700 Received: by gyd10 with SMTP id 10so6315208gyd.11 for ; Fri, 21 Oct 2011 12:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JrBqzBRXqJnMx+QYfhSKycRIV85kgsXBPSLBhcXYS0s=; b=eHOGGkY6ad26V9arq2ddSOZIa3FqAZlhjkTf2oywwQaGRuaUFrkE+ix+QWWCNYwQIN wTQvIloC8X9jzFD1l9+Q== Received: by 10.229.64.134 with SMTP id e6mr3508977qci.150.1319227172386; Fri, 21 Oct 2011 12:59:32 -0700 (PDT) Received: by 10.229.64.134 with SMTP id e6mr3508970qci.150.1319227172114; Fri, 21 Oct 2011 12:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.91.129 with HTTP; Fri, 21 Oct 2011 12:59:12 -0700 (PDT) In-Reply-To: References: From: Jan Skoglund Date: Fri, 21 Oct 2011 15:59:12 -0400 Message-ID: To: Butrus Damaskus Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: IETF - CoDec Subject: Re: [codec] Listening tests at Google X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:59:38 -0000 I think it can be due to the character of Mandarin speech (although I'm not a linguist), which does not seem to contain as much high frequency-rich consonants as English. I noticed that during recording of the Mandarin speech, and discussing afterwards with the talkers, who said that there are much more, e.g., [s] sounds in English. On Thu, Oct 20, 2011 at 11:39 AM, Butrus Damaskus wrote: > On Thu, Oct 20, 2011 at 4:32 PM, Jan Skoglund wrote: >> These results are pretty consistent >> with the previous results for English speech, with the difference that >> in the previous test Opus at 20 kbps outperformed G.719 at 32 kbps, >> which it did not this time. > > Does it mean that there is a regression or is it rather due to the > character of the Mandarine speech? > From butrus.butrus@gmail.com Fri Oct 21 13:33:38 2011 Return-Path: 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 17F121F0C36 for ; Fri, 21 Oct 2011 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8ehk4bkJ2DDc for ; Fri, 21 Oct 2011 13:33:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F05A61F0C35 for ; Fri, 21 Oct 2011 13:33:36 -0700 (PDT) Received: by wwe6 with SMTP id 6so4437999wwe.13 for ; Fri, 21 Oct 2011 13:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ngpP5KTu8qEJ7JLiBTKwUauSKSjbagHJwt3R4zYIxXI=; b=fAnOmA5Vctbj7smX5Yim5No+dNoj4jdWJ6eTkDFtPe8Anm4NxHreuUpE18gJBFl6bu MEuw2TxRRwWVJEbuLOyu8WZ6n/hk2ZLwJGM4oafGWlK64PthpGfeP1lohU/CNQRE+J5P gPgnFDdSSeZiTNon8bvILc6EimItnZQMxEDYY= MIME-Version: 1.0 Received: by 10.227.32.130 with SMTP id c2mr193057wbd.109.1319229216110; Fri, 21 Oct 2011 13:33:36 -0700 (PDT) Received: by 10.227.199.70 with HTTP; Fri, 21 Oct 2011 13:33:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 22:33:35 +0200 Message-ID: From: Butrus Damaskus To: Jan Skoglund Content-Type: text/plain; charset=UTF-8 Cc: IETF - CoDec Subject: Re: [codec] Listening tests at Google X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:33:38 -0000 Ok, thanks for the clarification, sounds interesting! On Fri, Oct 21, 2011 at 9:59 PM, Jan Skoglund wrote: > I think it can be due to the character of Mandarin speech (although > I'm not a linguist), which does not seem to contain as much high > frequency-rich consonants as English. I noticed that during recording > of the Mandarin speech, and discussing afterwards with the talkers, > who said that there are much more, e.g., [s] sounds in English. > > On Thu, Oct 20, 2011 at 11:39 AM, Butrus Damaskus > wrote: >> On Thu, Oct 20, 2011 at 4:32 PM, Jan Skoglund wrote: >>> These results are pretty consistent >>> with the previous results for English speech, with the difference that >>> in the previous test Opus at 20 kbps outperformed G.719 at 32 kbps, >>> which it did not this time. >> >> Does it mean that there is a regression or is it rather due to the >> character of the Mandarine speech? >> > From Internet-Drafts@ietf.org Mon Oct 24 15:15:03 2011 Return-Path: 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 3A55711E819D; Mon, 24 Oct 2011 15:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2U+MU6v--G-9; Mon, 24 Oct 2011 15:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306BC11E819C; Mon, 24 Oct 2011 15:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024221502.19205.46879.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 15:15:02 -0700 Cc: codec@ietf.org Subject: [codec] I-D ACTION:draft-ietf-codec-results-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:15:03 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Summary of Opus listening test results Author(s) : J. Valin, et al Filename : draft-ietf-codec-results-00.txt Pages : 31 Date : 2011-10-24 This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-results-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-codec-results-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-10-24150451.I-D@ietf.org> --NextPart-- From erik.norvell@ericsson.com Wed Oct 26 08:33:58 2011 Return-Path: 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 A8B9121F8A7A for ; Wed, 26 Oct 2011 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cUhaRsZXuCJs for ; Wed, 26 Oct 2011 08:33:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BE08221F8A6F for ; Wed, 26 Oct 2011 08:33:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a3-4ea82864f391 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.17.20773.46828AE4; Wed, 26 Oct 2011 17:33:56 +0200 (CEST) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.86]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 26 Oct 2011 17:33:56 +0200 From: Erik Norvell To: Cullen Jennings , "codec@ietf.org" Date: Wed, 26 Oct 2011 17:33:54 +0200 Thread-Topic: [codec] CODEC scheduled for IETF 82 Thread-Index: AcyNLrRofzkdMHdMQAq70gZ37JNGkQGxZ6ig Message-ID: <027A93CE4A670242BD91A44E37105AEF35A65B358B@ESESSCMS0351.eemea.ericsson.se> References: <20111013185249.1247.59184.idtracker@ietfa.amsl.com> <275364A3-010F-4668-8128-77420D40F7BF@cisco.com> In-Reply-To: <275364A3-010F-4668-8128-77420D40F7BF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] CODEC scheduled for IETF 82 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 15:33:58 -0000 Hi Cullen, I will likely not travel to Taipei but participate remotely. A colleague sa= id the meetecho tool was very useful for remote participation (http://ietf.= conf.meetecho.com/index.php/). Will there be meetecho support for this sess= ion? Cheers, Erik > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Cullen Jennings > Sent: den 18 oktober 2011 02:42 > To: codec@ietf.org > Subject: [codec] CODEC scheduled for IETF 82 >=20 >=20 > FYI ... hopefully this will not change ... >=20 > >=20 > >=20 > > codec Session 1 (2 hours) > > Wednesday, Afternoon Session I 1300-1500 > > Room Name: 101C > > --------------------------------------------- > >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > = From fluffy@cisco.com Wed Oct 26 08:52:57 2011 Return-Path: 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 210BF21F8783 for ; Wed, 26 Oct 2011 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.351 X-Spam-Level: X-Spam-Status: No, score=-106.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 orADiXrbnqF3 for ; Wed, 26 Oct 2011 08:52:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E78B21F86D0 for ; Wed, 26 Oct 2011 08:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1104; q=dns/txt; s=iport; t=1319644376; x=1320853976; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=9eYTZjA//PUNeYB4THH33JNYy7x2Js4/v9aWOee1gos=; b=MmwM28a7tFL7H8dZrZRyUrmeDwzO3kLJ/RVyG24c2gPImY0u7IitoJtH oAUcJacbSo7FxE1vEB6QhmNMFJL33sCDNqo+hMJzVTtgIxr6th4vgdaYa h5KnwrkAZf/Ome8pF80grhFyq8e+8NM8k32DvsNyhrDGHXIVBTpy8f+iL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQGAP0rqE6rRDoJ/2dsb2JhbAAoGppEjwWBBYFuAQEBAwEBAQEPASc0EAcECxEEAQEoBycfCQgZIodeCCSWCQGQL442iAlhBIgGjASFLYxR X-IronPort-AV: E=Sophos;i="4.69,410,1315180800"; d="scan'208";a="10417374" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 26 Oct 2011 15:52:56 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9QFq6Kb031993 for ; Wed, 26 Oct 2011 15:52:56 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <027A93CE4A670242BD91A44E37105AEF35A65B358B@ESESSCMS0351.eemea.ericsson.se> Date: Wed, 26 Oct 2011 09:52:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0833CE-6015-4C48-914F-7C5384A88B2B@cisco.com> References: <20111013185249.1247.59184.idtracker@ietfa.amsl.com> <275364A3-010F-4668-8128-77420D40F7BF@cisco.com> <027A93CE4A670242BD91A44E37105AEF35A65B358B@ESESSCMS0351.eemea.ericsson.se> To: codec@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [codec] CODEC scheduled for IETF 82 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 15:52:57 -0000 I have requested this. Not sure what will happen but in the past we have = had good luck getting meetecho support. On Oct 26, 2011, at 9:33 AM, Erik Norvell wrote: > Hi Cullen, >=20 > I will likely not travel to Taipei but participate remotely. A = colleague said the meetecho tool was very useful for remote = participation (http://ietf.conf.meetecho.com/index.php/). Will there be = meetecho support for this session? >=20 > Cheers, > Erik >=20 >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 >> On Behalf Of Cullen Jennings >> Sent: den 18 oktober 2011 02:42 >> To: codec@ietf.org >> Subject: [codec] CODEC scheduled for IETF 82 >>=20 >>=20 >> FYI ... hopefully this will not change ... >>=20 >>>=20 >>>=20 >>> codec Session 1 (2 hours) >>> Wednesday, Afternoon Session I 1300-1500 >>> Room Name: 101C >>> --------------------------------------------- >>>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec From mary.ietf.barnes@gmail.com Wed Oct 26 11:02:19 2011 Return-Path: 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 00ED421F89B8 for ; Wed, 26 Oct 2011 11:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 XcBPwRy82YGe for ; Wed, 26 Oct 2011 11:02:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 083A921F8478 for ; Wed, 26 Oct 2011 11:02:17 -0700 (PDT) Received: by vws5 with SMTP id 5so2037938vws.31 for ; Wed, 26 Oct 2011 11:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gIvX9DlueddZrPx1AteL5KKGV2upowkGCJhQv10Tb3M=; b=IVUl6hPCF3XptC1XS1twvxDBnF3ZZwajVEFyxMR5Q7aT63WxoYfvxuPKCcGGYZCIRY xFQs98KGRQT5UfETmaszITlDEACnDmE8XRR6rQyZhAcjNvEXv3hLVqfiwbzAJjGky8ut LXuhukHjjpmyTU5a93IIdRaHZi+257JQnt8eY= MIME-Version: 1.0 Received: by 10.52.33.140 with SMTP id r12mr125305vdi.36.1319652135528; Wed, 26 Oct 2011 11:02:15 -0700 (PDT) Received: by 10.52.169.164 with HTTP; Wed, 26 Oct 2011 11:02:15 -0700 (PDT) In-Reply-To: <8B0833CE-6015-4C48-914F-7C5384A88B2B@cisco.com> References: <20111013185249.1247.59184.idtracker@ietfa.amsl.com> <275364A3-010F-4668-8128-77420D40F7BF@cisco.com> <027A93CE4A670242BD91A44E37105AEF35A65B358B@ESESSCMS0351.eemea.ericsson.se> <8B0833CE-6015-4C48-914F-7C5384A88B2B@cisco.com> Date: Wed, 26 Oct 2011 13:02:15 -0500 Message-ID: From: Mary Barnes To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf3079beb6c3e8ef04b037740c Cc: codec@ietf.org Subject: Re: [codec] CODEC scheduled for IETF 82 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:02:19 -0000 --20cf3079beb6c3e8ef04b037740c Content-Type: text/plain; charset=ISO-8859-1 Here's the Meetecho info for IETF-82: http://ietf82.conf.meetecho.com/ Mary. On Wed, Oct 26, 2011 at 10:52 AM, Cullen Jennings wrote: > > I have requested this. Not sure what will happen but in the past we have > had good luck getting meetecho support. > > > On Oct 26, 2011, at 9:33 AM, Erik Norvell wrote: > > > Hi Cullen, > > > > I will likely not travel to Taipei but participate remotely. A colleague > said the meetecho tool was very useful for remote participation ( > http://ietf.conf.meetecho.com/index.php/). Will there be meetecho support > for this session? > > > > Cheers, > > Erik > > > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] > >> On Behalf Of Cullen Jennings > >> Sent: den 18 oktober 2011 02:42 > >> To: codec@ietf.org > >> Subject: [codec] CODEC scheduled for IETF 82 > >> > >> > >> FYI ... hopefully this will not change ... > >> > >>> > >>> > >>> codec Session 1 (2 hours) > >>> Wednesday, Afternoon Session I 1300-1500 > >>> Room Name: 101C > >>> --------------------------------------------- > >>> > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --20cf3079beb6c3e8ef04b037740c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's the Meetecho info for IETF-82:

Mary.=A0

On Wed, Oct 26, 2011 at 10:52= AM, Cullen Jennings <fluffy@cisco.com> wrote:

I have requested this. Not sure what will happen but in the past we have ha= d good luck getting meetecho support.


On Oct 26, 2011, at 9:33 AM, Erik Norvell wrote:

> Hi Cullen,
>
> I will likely not travel to Taipei but participate remotely. A colleag= ue said the meetecho tool was very useful for remote participation (http://ietf= .conf.meetecho.com/index.php/). Will there be meetecho support for this= session?
>
> Cheers,
> Erik
>
>> -----Original Message-----
>> From: codec-bounces@ietf= .org [mailto:codec-bounces@ie= tf.org]
>> On Behalf Of Cullen Jennings
>> Sent: den 18 oktober 2011 02:42
>> To: codec@ietf.org
>> Subject: [codec] CODEC scheduled for IETF 82
>>
>>
>> FYI ... hopefully this will not change ...
>>
>>>
>>>
>>> codec Session 1 (2 hours)
>>> =A0 Wednesday, Afternoon Session I 1300-1500
>>> =A0 Room Name: 101C
>>> =A0 ---------------------------------------------
>>>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--20cf3079beb6c3e8ef04b037740c-- From internet-drafts@ietf.org Mon Oct 31 09:24:52 2011 Return-Path: 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 9EFC421F8B47; Mon, 31 Oct 2011 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5Gsbk7Buo7Zk; Mon, 31 Oct 2011 09:24:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381BD21F8922; Mon, 31 Oct 2011 09:24:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031162451.515.90395.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 09:24:51 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-guidelines-06.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:24:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Guidelines for the Codec Development Within the IETF Author(s) : Jean-Marc Valin Slava Borilin Koen Vos Christopher Montgomery Raymond (Juin-Hwey) Chen Filename : draft-ietf-codec-guidelines-06.txt Pages : 21 Date : 2011-10-31 This document provides general guidelines for work on developing and specifying a codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-guidelines-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-guidelines-06.txt From internet-drafts@ietf.org Mon Oct 31 13:33:10 2011 Return-Path: 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 55D1211E8245; Mon, 31 Oct 2011 13:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pGM8ndgNZP1j; Mon, 31 Oct 2011 13:33:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E659911E8241; Mon, 31 Oct 2011 13:33:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031203309.30161.14718.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:33:09 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-09.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:33:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-09.txt Pages : 322 Date : 2011-10-31 This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bit-rate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-opus-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-opus-09.txt From internet-drafts@ietf.org Mon Oct 31 16:56:22 2011 Return-Path: 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 A6D8211E8421; Mon, 31 Oct 2011 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fURM+N0rlJpe; Mon, 31 Oct 2011 16:56:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E1111E841A; Mon, 31 Oct 2011 16:56:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031235616.12950.85516.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:56:16 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-10.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:56:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-10.txt Pages : 322 Date : 2011-10-31 This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bit-rate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-opus-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-opus-10.txt From jdrosen@jdrosen.net Mon Oct 31 17:58:09 2011 Return-Path: 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 69DC61F0DCA for ; Mon, 31 Oct 2011 17:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 RuNfJXOxhtea for ; Mon, 31 Oct 2011 17:58:05 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.52.42]) by ietfa.amsl.com (Postfix) with ESMTP id BE16D1F0DC8 for ; Mon, 31 Oct 2011 17:58:02 -0700 (PDT) Received: from pool-173-63-39-69.nwrknj.fios.verizon.net ([173.63.39.69]:50265 helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RL2fy-0001Xq-6I for codec@ietf.org; Mon, 31 Oct 2011 20:58:02 -0400 Message-ID: <4EAF4419.3000502@jdrosen.net> Date: Mon, 31 Oct 2011 20:58:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:58:09 -0000 The chairs would like to initiate a ~3-week WGLC on draft-ietf-codec-opus-10 (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/) which will end November 19, coincident with the conclusion of the Taipei IETF. Please note that this document has several IPR claims against it: Xiph.org: https://datatracker.ietf.org/ipr/1524/ Broadcom: https://datatracker.ietf.org/ipr/1526/ Skype: https://datatracker.ietf.org/ipr/1602/ Qualcomm: https://datatracker.ietf.org/ipr/1520/ The IETF cannot take a position on validity of these claims. It is up to IETF participants to make their own decisions. Participants are encouraged to form an opinion about whether you would like to proceed with publication of this document under these declarations, or whether you would like to suggest changes, which you should do during the last call period. As always, we will proceed based on consensus of the working group. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net