From wwwrun@core3.amsl.com Wed Dec 1 11:13:37 2010 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 693B13A6C8F; Wed, 1 Dec 2010 11:13:37 -0800 (PST) To: jean-marc.valin@octasic.com,koen.vos@skype.net From: IETF Secretariat Message-Id: <20101201191337.693B13A6C8F@core3.amsl.com> Date: Wed, 1 Dec 2010 11:13:37 -0800 (PST) Cc: codec@ietf.org, gonzalo.camarillo@ericsson.com, ipr-announce@ietf.org Subject: [codec] IPR Disclosure: Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 19:13:37 -0000 Dear Jean-Marc Valin, Koen Vos: An IPR disclosure that pertains to your Internet-Draft entitled "Definition of the IETF Interactive Audio Codec" (draft-ietf-codec-description) was submitted to the IETF Secretariat on 2010-11-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1447/). The title of the IPR disclosure is "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)." The IETF Secretariat From jmvalin@jmvalin.ca Thu Dec 2 03:57:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2F128C0E7 for ; Thu, 2 Dec 2010 03:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfCXSuC-xrn4 for ; Thu, 2 Dec 2010 03:57:44 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 5EE3828C0D9 for ; Thu, 2 Dec 2010 03:57:44 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.14] ([70.81.109.112]) by vl-mh-mrz25.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LCS005ZUULJRH30@vl-mh-mrz25.ip.videotron.ca> for codec@ietf.org; Thu, 02 Dec 2010 06:58:31 -0500 (EST) Message-id: <4CF78A1C.2090109@jmvalin.ca> Date: Thu, 02 Dec 2010 06:59:24 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 To: "codec@ietf.org" X-Enigmail-Version: 1.0.1 Subject: [codec] Naming the modes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 11:57:45 -0000 Hi, So far we've had three Opus modes named SILK, CELT and Hybrid. Because of the potential confusion with the stand-alone versions of SILK and CELT released in the past, we thought it might be better to find new names for these modes. Anyone has a good suggestion for naming these modes? Here's some initial suggestions: - Speech/Audio/Hybrid (or just S/A/H) - LPC/MDCT/Hybrid (or just L/M/H) - A/B/C - 1/2/3 Any thoughts? Jean-Marc From Pochol@WebfootGames.com Thu Dec 2 07:17:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27143A696C for ; Thu, 2 Dec 2010 07:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Svd2A17vMY4 for ; Thu, 2 Dec 2010 07:17:01 -0800 (PST) Received: from mail.webfootgames.com (mail.webfootgames.com [68.248.244.61]) by core3.amsl.com (Postfix) with ESMTP id B99F73A696B for ; Thu, 2 Dec 2010 07:17:01 -0800 (PST) Received: from mail.WebfootGames.com (softdnserr [::ffff:127.0.0.1]) (AUTH: LOGIN pochol) by mail.webfootgames.com with esmtp; Thu, 02 Dec 2010 09:20:40 -0600 id 000010A9.4CF7B948.0000700A Message-ID: <753a2fd7e7e0fadf01a7699090291c8a@WebfootGames.com> Date: Thu, 02 Dec 2010 09:20:40 -0600 From: "Pascal Pochol" To: Jean-Marc Valin In-Reply-To: <4CF78A1C.2090109@jmvalin.ca> References: <4CF78A1C.2090109@jmvalin.ca> X-Mailer: Webfoot's WebMail 1.6-CVS x-priority: 3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mime-Autoconverted: from 8bit to 7bit by courier 0.64 Cc: codec@ietf.org Subject: Re: [codec] Naming the modes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Pochol@WebfootGames.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:17:02 -0000 Jean-Marc, > - Speech/Audio/Hybrid (or just S/A/H) Not being in the audio field myself (just a user of the library) this is by far my favorite, I can understand what it means and easily explain it to others. FYI: SAH.org - Society of Architectural Historians And just to help with the brainstorming I'll throw in some names too not particularly better Voice/Music/Hybrid Voice/Music/Generic Simple/Complex/Multipurpose I know it's not only for music, but if you think about it every sound is music to someone's ears. -Pascal From bmschwar@fas.harvard.edu Thu Dec 2 07:24:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71D928C13E for ; Thu, 2 Dec 2010 07:24:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOGaknFKg+At for ; Thu, 2 Dec 2010 07:23:50 -0800 (PST) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by core3.amsl.com (Postfix) with ESMTP id D1D4228C115 for ; Thu, 2 Dec 2010 07:23:49 -0800 (PST) Received: from us17.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us17.unix.fas.harvard.edu (Postfix) with ESMTP id ACD2641E26B; Thu, 2 Dec 2010 10:25:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=cZnzZONZbs8vknk D3mitxTnSVO4w9v36f1OCOrz1gxQ=; b=VtCi69x2EV6Xt46/9ZQ5XPr8h9QjUip cVpe/PKptmXtYcPtWU+GQIuaF7f1y6+DEigpCpsHHTlQk4pp0Rtjk0goZpdmk4i7 g2fMLlLEtN3Iagt3I6CsiftkK3Oin/urn6PD+3gy1/lOqoLEwnPZ4kH8Qz5X3A1P Tn/CsNoWpego= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=cZgCTPmHy akjJxyf7O6tzUVFojHmrdVdSHtn/XqbqgbdetHptJYvbVKA8vjNmwMITJis7IgB3 j02S+qW3pqZPtbKNHpgx1B9VSeS75IsALciyueL92G9xOVMM8FOsjmPgWwpNFP1t rZyC0GOnadGlbUVPOZPhId/Rj+ZKQHSi00= Received: from [192.168.1.141] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us17.unix.fas.harvard.edu (Postfix) with ESMTPSA id A1C6941DFED; Thu, 2 Dec 2010 10:25:04 -0500 (EST) Message-ID: <4CF7BA4F.8050700@fas.harvard.edu> Date: Thu, 02 Dec 2010 10:25:03 -0500 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: Jean-Marc Valin References: <4CF78A1C.2090109@jmvalin.ca> In-Reply-To: <4CF78A1C.2090109@jmvalin.ca> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0557716E394665AF2A6D5191" Cc: "codec@ietf.org" Subject: Re: [codec] Naming the modes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:24:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0557716E394665AF2A6D5191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/02/2010 06:59 AM, Jean-Marc Valin wrote: > Any thoughts? I think the codec has _two_ modes, not three: Voice and Universal. Voice= mode operates at 8, 12, 16, 32, or 48 KHz. Universal mode operates at 8,= 16, 32, or 48 KHz. The available window sizes depend on the mode and sample rate... although perhaps it would be better to abstract this away and allow 40 and 60 ms frames at all samplerates in Voice mode. The exact manner in which these sample rates are implemented is a detail irrelevant to the user. --Ben --------------enig0557716E394665AF2A6D5191 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkz3uk8ACgkQUJT6e6HFtqQizQCfbyOZHxp1571mFLPHE1cyCE3c 0ccAn0irqT1Dh99naroionxIGLwN3jhP =8wEJ -----END PGP SIGNATURE----- --------------enig0557716E394665AF2A6D5191-- From jean-marc.valin@octasic.com Thu Dec 2 07:44:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6CD28C17B for ; Thu, 2 Dec 2010 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1YO5zQyXyPx for ; Thu, 2 Dec 2010 07:44:16 -0800 (PST) Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07-srv.bellnexxia.net [207.236.237.41]) by core3.amsl.com (Postfix) with ESMTP id 4D0E828C186 for ; Thu, 2 Dec 2010 07:44:11 -0800 (PST) Received: from toip55-bus.srvr.bell.ca ([67.69.240.141]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20101202154525.KQHU2484.toroondcbmts07-srv.bellnexxia.net@toip55-bus.srvr.bell.ca>; Thu, 2 Dec 2010 10:45:25 -0500 Received: from toip41-bus.srvr.bell.ca ([67.69.240.42]) by toip55-bus.srvr.bell.ca with ESMTP; 02 Dec 2010 10:45:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAKpA90zPPaAN/2dsb2JhbACVEI8CwkyFRwSEXokZBogG Received: from mail.octasic.com (HELO MAILEXCH.octasic.com) ([207.61.160.13]) by toip41-bus.srvr.bell.ca with ESMTP; 02 Dec 2010 10:45:13 -0500 Received: from [10.100.60.27] ([10.100.60.27]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Dec 2010 10:45:13 -0500 Message-ID: <4CF7BF09.4090408@octasic.com> Date: Thu, 02 Dec 2010 10:45:13 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: bens@alum.mit.edu References: <4CF78A1C.2090109@jmvalin.ca> <4CF7BA4F.8050700@fas.harvard.edu> In-Reply-To: <4CF7BA4F.8050700@fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2010 15:45:13.0152 (UTC) FILETIME=[E87C7C00:01CB9237] Cc: "codec@ietf.org" Subject: Re: [codec] Naming the modes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:44:21 -0000 Note that these modes names are meant to describe now the codec works, not necessarily the user-visible API. Jean-Marc On 10-12-02 10:25 AM, Benjamin M. Schwartz wrote: > On 12/02/2010 06:59 AM, Jean-Marc Valin wrote: >> Any thoughts? > > I think the codec has _two_ modes, not three: Voice and Universal. Voice > mode operates at 8, 12, 16, 32, or 48 KHz. Universal mode operates at 8, > 16, 32, or 48 KHz. The available window sizes depend on the mode and > sample rate... although perhaps it would be better to abstract this away > and allow 40 and 60 ms frames at all samplerates in Voice mode. > > The exact manner in which these sample rates are implemented is a detail > irrelevant to the user. > > --Ben > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Thu Dec 2 19:27:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2902228C121 for ; Thu, 2 Dec 2010 19:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGTtGl7CTxZO for ; Thu, 2 Dec 2010 19:27:23 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 472513A6A4C for ; Thu, 2 Dec 2010 19:27:22 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 7444516FD; Fri, 3 Dec 2010 04:28:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=VMiskRQC/pSo/Aue26KEG9Cf3PI= ; b=xRA+iVEy0Jfl0nl4Ew0E6lGhir5+rs8MkalypyuvUBG1zbevSroQY8hO3DJ1 DUeIktb6z1OcZhK1+Aa32HOInFv9xyVO7YZyHYfPP9POe3seOC8R4qlmQ+cT8UR3 mrCt58v6AhJHpRIHHPDVN0oZOiGzLyinWcXiRDBNu881kWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=gLOXaHPvSyvdsMQ1vclQnw bJNDelJTIHZ29bmdktLews2QocJnJoOjOxq0WVvoGpiNEXpdK8WWBCRnmVsSnBng Zd9tv2wkntt75rGfiXhBxt1u7d+Ab4G4jo7ddKerr9BZe2A4uiaYERUkLRtU09aJ mPaJpeDxjd1wPsQT7aSWs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 72C4D16F3; Fri, 3 Dec 2010 04:28:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 4FEDD1672687; Fri, 3 Dec 2010 04:28:38 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70UEF5HB+N9X; Fri, 3 Dec 2010 04:28:37 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 5A02B1672684; Fri, 3 Dec 2010 04:28:37 +0100 (CET) Date: Fri, 3 Dec 2010 04:28:37 +0100 (CET) From: Koen Vos To: Jean-Marc Valin Message-ID: <383045204.2301011.1291346917272.JavaMail.root@lu2-zimbra> In-Reply-To: <624869898.2301000.1291346763379.JavaMail.root@lu2-zimbra> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.6_GA_2330.UBUNTU8_64 (ZimbraWebClient - FF3.0 (Win)/6.0.6_GA_2330.UBUNTU8_64) Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] Naming the modes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 03:27:25 -0000 I like Voice and Universal as the API mode names. For the internal mode names, Speech/Audio/Hybrid could be confusing because they're similar to the API modes, and because Hybrid is really also a Speech mode. So maybe better with - LPC/MDCT/Hybrid - Predictive/Transform/Hybrid? About having 40 and 60 ms modes for all sampling rates in Voice mode: we allow this already by combining multiple frames per packet (even though the current implementation doesn't do it yet). Such multi-frame packets come with a few bytes overhead, but the assumption is that packets longer than 20 ms will be used mainly for lower bitrates where it's better to use the Predictive than the Hybrid mode. koen. ----- Original Message ----- From: "Jean-Marc Valin" To: bens@alum.mit.edu Cc: codec@ietf.org Sent: Thursday, December 2, 2010 7:45:13 AM Subject: Re: [codec] Naming the modes Note that these modes names are meant to describe now the codec works, not necessarily the user-visible API. Jean-Marc On 10-12-02 10:25 AM, Benjamin M. Schwartz wrote: > On 12/02/2010 06:59 AM, Jean-Marc Valin wrote: >> Any thoughts? > > I think the codec has _two_ modes, not three: Voice and Universal. > Voice mode operates at 8, 12, 16, 32, or 48 KHz. Universal mode > operates at 8, > 16, 32, or 48 KHz. The available window sizes depend on the mode and > sample rate... although perhaps it would be better to abstract this > away and allow 40 and 60 ms frames at all samplerates in Voice mode. > > The exact manner in which these sample rates are implemented is a > detail irrelevant to the user. > > --Ben > > > > > _______________________________________________ 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 From hoene@uni-tuebingen.de Fri Dec 3 02:11:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BE23A68D9 for ; Fri, 3 Dec 2010 02:11:08 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p6ILnSTMoO6 for ; Fri, 3 Dec 2010 02:11:06 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 075323A67EE for ; Fri, 3 Dec 2010 02:11:04 -0800 (PST) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id oB3ACKWD007124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 Dec 2010 11:12:20 +0100 From: "Christian Hoene" To: Date: Fri, 3 Dec 2010 11:12:27 +0100 Organization: =?utf-8?Q?Universit=C3=A4t_T=C3=BCbingen?= Message-ID: <000f01cb92d2$96d04490$c470cdb0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuS0pQ1qPinbi39R6KAd6QdOO+jfA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx05) Subject: [codec] Testing Codec Quality X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 10:11:09 -0000 Hi, one important question back to the days where iLBC was submitted to the = IETF was: how do we know whether iLBC is a technical sound contribution = to the IETF? The draft http://www.ietf.org/id/draft-hoene-codec-quality-00.pdf = addresses this question in the context of this WG. The first chapters = describe well established procedures on how to test a codec (and goes a = bit beyond that where needed). Finally, Chapter 10 suggests a procedure = on how to test IIAC (or Opus).=20 Timely feedback is welcomed as the testing shall start soon. With best regards, Christian=20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=C3=BCbingen=20 Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ From wwwrun@core3.amsl.com Wed Dec 1 11:13:37 2010 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 655243A6CBC; Wed, 1 Dec 2010 11:13:37 -0800 (PST) To: jean-marc.valin@octasic.com,koen.vos@skype.net From: IETF Secretariat Message-Id: <20101201191337.655243A6CBC@core3.amsl.com> Date: Wed, 1 Dec 2010 11:13:37 -0800 (PST) X-Mailman-Approved-At: Fri, 03 Dec 2010 08:03:43 -0800 Cc: housley@vigilsec.com, codec@ietf.org, gonzalo.camarillo@ericsson.com, ipr-announce@ietf.org Subject: [codec] IPR Disclosure: Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 19:13:37 -0000 Dear Jean-Marc Valin, Koen Vos: An IPR disclosure that pertains to your Internet-Draft entitled "Definition of the Opus Audio Codec" (draft-ietf-codec-opus) was submitted to the IETF Secretariat on 2010-11-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1447/). The title of the IPR disclosure is "Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)." The IETF Secretariat From henry.sinnreich@gmail.com Tue Dec 21 18:30:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A023A6953; Tue, 21 Dec 2010 18:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4s-MUMAegl; Tue, 21 Dec 2010 18:30:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 40D5B3A68EA; Tue, 21 Dec 2010 18:30:37 -0800 (PST) Received: by yxt33 with SMTP id 33so2207675yxt.31 for ; Tue, 21 Dec 2010 18:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=kM48DsyX88y7PK12iG2GmA7epaWKijnRwidB84Rfbd0=; b=PnPsq9Z2Mecz/c1PCDpEPDhMRhE/tCuY/2dj0qTY89FYhtjlhhTSzz8P6uJqWqk/IP e4KwKpXmlBBFzIg79FdoJBjoycP5EZ0VdYGT5dr/VMpCo0eSl0D7bso9povD6xSFCuQO JAg3K7KH4xgLjQPPRjocpxz5gChx3DXZaL4iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=ZF4nAhyigV7n8xJbmI23Z/mIlaDuGN8+cZS4hs/Z/CE6/uQrhpKigH60p2hAdfd72g oRkI33P846SfgoUkMdCfJn6qhm/2qded+YmWE/VC1BhaPGvB8l12zcepWcniVVYj7QtU c+ygai+TDdBFC4a9EsiiM307GIJDZE0S1ECXU= Received: by 10.100.190.3 with SMTP id n3mr3741520anf.150.1292985154181; Tue, 21 Dec 2010 18:32:34 -0800 (PST) Received: from [10.0.1.7] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id 35sm10475640ano.11.2010.12.21.18.32.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Dec 2010 18:32:33 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 21 Dec 2010 20:32:28 -0600 From: Henry Sinnreich To: , , , Message-ID: Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcuAy1RXtTh3Nt0jTE+h7SlrXOzekgdDJukAAN9ebfAACsQBig== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3375808351_4771304" X-Mailman-Approved-At: Wed, 22 Dec 2010 08:04:41 -0800 Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [codec] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 02:30:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3375808351_4771304 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free video codec is mirroring the opposition to the Internet audio codec. That opposition proved eventually futile and we have now a CODEC WG. I hope the AD=B9s will have now the same fortitude as was shown when the Internet audio codec WG was formed. I have taken the liberty to copy the CODEC WG and hope they can participate now in the video codec discussion as well. My apology for the double posting. Thanks, Henry=20 On 12/21/10 3:38 PM, "Markus.Isomaki@nokia.com" wrote: > Hi Peter, all, > =20 > About the video codec: Are there any arguments on why VP8 would not have = IPR > issues? It is available as an open source implementation, but that does n= ot > mean there are no IPR against it. My understanding is that the IPR situat= ion > wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as= far > as I know, the lack of a clear spec out of which independent interoperabl= e > implementations can be created. > =20 > So I don=B9t at least buy the argument that we should choose VP8 as mandato= ry to > implement video codec because of IPR reasons. > =20 > I=B9m working on a separate review on Harald=B9s drafts (thanks for putting t= hem > together) and will come back to the codec issue there in more detail, but= just > wanted to respond to Peter=B9s point here. > =20 > Regards, > Markus > =20 >=20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf > Of ext Peter Musgrave > Sent: 17 December, 2010 13:48 > To: Harald Alvestrand > Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie > Subject: Re: [dispatch] Fwd: New Version Notification for > draft-alvestrand-dispatch-rtcweb-protocols-00 > =20 >=20 > I'd also like to echo Alan's thanks for these drafts. >=20 > =20 >=20 > The protocol doc is very clear. [If you read only one dispatch draft this > Christmas, make it this one. ;-) ] >=20 > =20 >=20 > One observation to the group. The mandatory to implement video CODEC is V= P8 > (presumably since it does not have IPR issues - which some other choices = would > have).=20 >=20 > =20 >=20 > Regards,=20 >=20 > =20 >=20 > Peter Musgrave >=20 > =20 >=20 > =20 >=20 > Nits >=20 > Introduction >=20 > s/veichle/vehicle/ >=20 > =20 >=20 > Section 2 Para "Within each.." >=20 > s/implementaiton/implementation/ >=20 > =20 >=20 > Section 4 Para1 >=20 > "such as" (something missing here?) >=20 > =20 >=20 > Section 5 Para2 >=20 > "There is no third mandatory to implement" >=20 > ? Was there a mention of a third before. Not sure why this statement is t= here. >=20 > =20 > =20 >=20 > On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: >=20 >=20 > This is the overview document for the IETF-related RTC-WEB work. >=20 > -------- Original Message -------- > =20 > =20 --B_3375808351_4771304 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-di= spatch-rtcweb-protocols-00 It is interesting, almost funny (or sad depending on the perspective) how = the reaction to a _God Forbid_ IP-free video codec is mirroring the oppositi= on to the Internet audio codec. That opposition proved eventually futile and= we have now a CODEC WG.
I hope the AD’s will have now the same fortitude as was shown when th= e Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry


On 12/21/10 3:38 PM, "Markus.Isomak= i@nokia.com" <Markus.Isomaki@= nokia.com> wrote:

<= FONT COLOR=3D"#1F497D">Hi Peter, a= ll,
 
About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does no= t mean there are no IPR against it. My understanding is that the IPR situati= on wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as= far as I know, the lack of a clear spec out of which independent interopera= ble implementations can be created.
 
So I don’t at least buy the argument that we should choose VP8 as man= datory to implement video codec because of IPR reasons.
 
I’m working on a separate review on Harald’s drafts (thanks for= putting them together) and will come back to the codec issue there in more = detail, but just wanted to respond to Peter’s point here.
 
Regards,
            &nb= sp;   Markus
 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrav= e
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alve= strand-dispatch-rtcweb-protocols-00

I'd also like to echo Alan's thanks for these drafts.



The protocol doc is very clear. [If you read only one dispatch d= raft this Christmas, make it this one. ;-)  ]

One observation to the group. The mandatory to implement video C= ODEC is VP8 (presumably since it does not have IPR issues - which some other= choices would have).



Regards,



Peter Musgrave



Nits

Introduction

s/veichle/vehicle/

Section 2 Para "Within each.."

s/implementaiton/implementation/

Section 4 Para1

"such as" (something missing here?)

Section 5 Para2

"There is no third mandatory to implement"

? Was there a mention of a third before. Not sure why this = statement is there.
 

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

  
--B_3375808351_4771304-- From Markus.Isomaki@nokia.com Tue Dec 21 23:44:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575353A69A6; Tue, 21 Dec 2010 23:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPWHSulqvEBf; Tue, 21 Dec 2010 23:44:33 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 32C7A3A691F; Tue, 21 Dec 2010 23:44:32 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBM7kQbB032272; Wed, 22 Dec 2010 09:46:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 09:46:15 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 22 Dec 2010 08:46:14 +0100 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.98]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 22 Dec 2010 08:46:15 +0100 From: To: , , , Thread-Topic: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AQHLoYCJzA9cAQBb2Ee2VTvzg0kiIJOsD4uw Date: Wed, 22 Dec 2010 07:46:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2010 07:46:15.0843 (UTC) FILETIME=[4FFA1F30:01CBA1AC] X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 22 Dec 2010 08:04:46 -0800 Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Subject: Re: [codec] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 07:44:40 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The good thing about Opus codec is that as it has been developed through th= e IETF process, the ownership and change control issues are clear. This mak= es referencing and even mandating it by IETF or W3C more comfortable. Markus From: ext Henry Sinnreich [mailto:henry.sinnreich@gmail.com] Sent: 22 December, 2010 04:32 To: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; harald@= alvestrand.no; codec@ietf.org Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 It is interesting, almost funny (or sad depending on the perspective) how t= he reaction to a _God Forbid_ IP-free video codec is mirroring the oppositi= on to the Internet audio codec. That opposition proved eventually futile an= d we have now a CODEC WG. I hope the AD's will have now the same fortitude as was shown when the Inte= rnet audio codec WG was formed. I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well. My apology for the double posting. Thanks, Henry On 12/21/10 3:38 PM, "Markus.Isomaki@nokia.com" = wrote: Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does n= ot mean there are no IPR against it. My understanding is that the IPR situa= tion wrt. VP8 is still unclear and thus risky. The other issue with VP8 is,= as far as I know, the lack of a clear spec out of which independent intero= perable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory= to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting the= m together) and will come back to the codec issue there in more detail, but= just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-= dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this C= hristmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8= (presumably since it does not have IPR issues - which some other choices w= ould have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is the= re. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- --_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Hi,

 

The good thing about Opus codec is that as it has been devel= oped through the IETF process, the ownership and change control issues are clear= . This makes referencing and even mandating it by IETF or W3C more comfortable.

 

Markus

 

 

From: ext Henry Sin= nreich [mailto:henry.sinnreich@gmail.com]
Sent: 22 December, 2010 04:32
To: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; harald@alvestrand.no; codec@ietf.org
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

 

It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free vi= deo codec is mirroring the opposition to the Internet audio codec. That opposit= ion proved eventually futile and we have now a CODEC WG.
I hope the AD’s will have now the same fortitude as was shown when th= e Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate= now in the video codec discussion as well.
My apology for the double posting.

Thanks, Henry


On 12/21/10 3:38 PM, "Markus.Isom= aki@nokia.com" <Markus.Isomaki@nokia.com> w= rote:

Hi Peter, all,
 
About the video codec: Are there any arguments on why VP8 would not have IP= R issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situatio= n wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as f= ar as I know, the lack of a clear spec out of which independent interoperable implementations can be created.
 
So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.
 
I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.
 
Regards,
            &nb= sp;   Markus
 
=
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org<= /a>] On Behalf Of ext Peter Musgrave
Sent: 17 December, 2010 13:48
To: Harald Alvestrand
Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie
Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00


I'd also like to echo Alan's thanks for these drafts.



The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-)  ]



One observation to the group. The mandatory to implement video CODEC= is VP8 (presumably since it does not have IPR issues - which some other choice= s would have).



Regards,



Peter Musgrave





Nits
=
Introduction
=
s/veichle/vehicle/
=

=
Section 2 Para "Within each.."
=
s/implementaito= n/implementation/
=

=
Section 4 Para1=
=
"such as&q= uot; (something missing here?)
=

=
Section 5 Para2=
=
"There is = no third mandatory to implement"
=
? Was there a m= ention of a third before. Not sure why this statement is there.
=

 

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:


This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

  

--_000_DD8B10B86502AB488CB2D3DB4C546E3806DE66008AM1MPN1003mgdn_-- From jean-marc.valin@octasic.com Wed Dec 22 12:06:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD7D3A6A8D for ; Wed, 22 Dec 2010 12:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3U8jajtAkNA for ; Wed, 22 Dec 2010 12:06:19 -0800 (PST) Received: from toroondcbmts05-srv.bellnexxia.net (toroondcbmts05.bellnexxia.net [207.236.237.39]) by core3.amsl.com (Postfix) with ESMTP id 0F0D43A6A07 for ; Wed, 22 Dec 2010 12:06:18 -0800 (PST) Received: from toip55-bus.srvr.bell.ca ([67.69.240.141]) by toroondcbmts05-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20101222200815.TDFU29362.toroondcbmts05-srv.bellnexxia.net@toip55-bus.srvr.bell.ca> for ; Wed, 22 Dec 2010 15:08:15 -0500 Received: from toip41-bus.srvr.bell.ca ([67.69.240.42]) by toip55-bus.srvr.bell.ca with ESMTP; 22 Dec 2010 15:08:07 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHPlEU3PPaAN/2dsb2JhbACkH3PDbIVJBIRmiTsG Received: from mail.octasic.com ([207.61.160.13]) by toip41-bus.srvr.bell.ca with ESMTP; 22 Dec 2010 15:08:06 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL.octasic.com (10.100.10.35) with Microsoft SMTP Server (TLS) id 14.1.255.0; Wed, 22 Dec 2010 15:08:06 -0500 Message-ID: <4D125AA6.7000908@octasic.com> Date: Wed, 22 Dec 2010 15:08:06 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.60.27] Subject: [codec] Opus/CELT demo page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 20:06:27 -0000 Hi, I this demo written by Monty could be of interest many here: http://people.xiph.org/~xiphmont/demo/celt/demo.html It describes the development of CELT, so half of Opus, including the techniques currently used, the history, and the recent changes. There's also many samples comparing to other codecs like Vorbis and various flavours of AAC. Note that the demo is still a work-in-progress and more contents may be added in the future. Cheers, Jean-Marc