From jean-marc.valin@usherbrooke.ca Sat Jul 4 21:13:05 2009 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 7CA373A68F0 for ; Sat, 4 Jul 2009 21:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_40=-0.185] 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 dAcOvDyRwj2G for ; Sat, 4 Jul 2009 21:13:04 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 985E63A67F2 for ; Sat, 4 Jul 2009 21:13:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMA00BA9J80TUH0@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Sun, 05 Jul 2009 00:02:24 -0400 (EDT) Message-id: <4A502867.9090906@usherbrooke.ca> Date: Sun, 05 Jul 2009 00:13:27 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: "codec@ietf.org" X-Enigmail-Version: 0.95.2 Subject: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 04:13:05 -0000 Hi everyone, Here's a first codec proposal: http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt Cheers, Jean-Marc From stewe@stewe.org Sat Jul 4 21:54:17 2009 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 C08DB3A67F2 for ; Sat, 4 Jul 2009 21:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=1.312, 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 KfthBswJLg5A for ; Sat, 4 Jul 2009 21:54:15 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id CE9FC3A68AF for ; Sat, 4 Jul 2009 21:54:14 -0700 (PDT) Received: from [192.168.1.111] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 326516-1743317 for multiple; Sun, 05 Jul 2009 06:54:37 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sat, 04 Jul 2009 21:54:28 -0700 From: Stephan Wenger To: Jean-Marc Valin , "codec@ietf.org" Message-ID: Thread-Topic: [codec] Codec proposal: draft-valin-celt-codec-00.txt Thread-Index: Acn9LK0Fjj+sbkve5kSflNH9AKEkwA== In-Reply-To: <4A502867.9090906@usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 04:54:17 -0000 Hi, Three things that will hopefully be seen as constructive :-): First, posting reference code in text format, while quite common in speech standards, is not that overly helpful IMHO, especially considering the number of lines of code. At least during the I-D phase, a reference to an URL where one can retrieve a stable version of the code, plus a promise to copy-paste that code into a final RFC if that were the consensus, seems to suffice. Second, if you add code into your I-D, it would IMHO make sense if you would start using the required license---a BSD derivate. While I personally appreciate your very broad license, it is not directly compatible with the BSD license we require for code sections of RFCs. Third, it would be helpful if you would explicitly state what part of your I-D actually is the normative specification: source code, or textual description. I note that in most ITU and 3GPP speech codec standards, the code is actually setting the normative standard, and the textual description is informative. If I recall correctly, in the IETF's LBC effort the same holds (I didn't check this---too lazy). To me, using source code as the normative standard makes sense---for speech coding only. If that's what is intended here, please make sure that it is prominently advertised. Regards, Stephan On 7/4/09 9:13 PM, "Jean-Marc Valin" wrote: > Hi everyone, > > Here's a first codec proposal: > http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Sun Jul 5 05:16:55 2009 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 EDEE63A692A for ; Sun, 5 Jul 2009 05:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 A3Nk74UkxY8j for ; Sun, 5 Jul 2009 05:16:55 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 117853A683A for ; Sun, 5 Jul 2009 05:16:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMB00IKI64U4GJ1@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Sun, 05 Jul 2009 08:17:19 -0400 (EDT) Message-id: <4A5099CE.6060608@usherbrooke.ca> Date: Sun, 05 Jul 2009 08:17:18 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Stephan Wenger References: In-reply-to: X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 12:16:56 -0000 Stephan Wenger a écrit : > Three things that will hopefully be seen as constructive :-): > First, posting reference code in text format, while quite common in speech > standards, is not that overly helpful IMHO, especially considering the > number of lines of code. At least during the I-D phase, a reference to an > URL where one can retrieve a stable version of the code, plus a promise to > copy-paste that code into a final RFC if that were the consensus, seems to > suffice. I agree that the 72-column text format isn't great for source code (took me a while just to make it fit!). Right now, the source code in the RFC actually differs from the downloadable code in that it has been simplified to only support floating point (the main reference code can switch from float to fixed-point through macros). In any case if the consensus is to leave it out during drafting, that's what I'll do. > Second, if you add code into your I-D, it would IMHO make sense if you would > start using the required license---a BSD derivate. While I personally > appreciate your very broad license, it is not directly compatible with the > BSD license we require for code sections of RFCs. Not sure what you mean here. The license on the files I appended *is* the BSD license. > Third, it would be helpful if you would explicitly state what part of your > I-D actually is the normative specification: source code, or textual > description. I note that in most ITU and 3GPP speech codec standards, the > code is actually setting the normative standard, and the textual description > is informative. If I recall correctly, in the IETF's LBC effort the same > holds (I didn't check this---too lazy). To me, using source code as the > normative standard makes sense---for speech coding only. If that's what is > intended here, please make sure that it is prominently advertised. Actually, I couldn't find such a statement in iLBC (though I may have missed it). Unless there's a good reason not to do that that I'm unaware of, I agree that it's safer to make the C code normative. Cheers, Jean-Marc > On 7/4/09 9:13 PM, "Jean-Marc Valin" wrote: > >> Hi everyone, >> >> Here's a first codec proposal: >> http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt >> >> Cheers, >> >> Jean-Marc >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > > From stewe@stewe.org Sun Jul 5 12:11:02 2009 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 D74AE3A6A70 for ; Sun, 5 Jul 2009 12:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.831, 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 E6haoPoEjJ3o for ; Sun, 5 Jul 2009 12:11:02 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id B8C133A695F for ; Sun, 5 Jul 2009 12:11:01 -0700 (PDT) Received: from [192.168.1.111] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 327240-1743317 for multiple; Sun, 05 Jul 2009 21:11:26 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 05 Jul 2009 12:11:06 -0700 From: Stephan Wenger To: Jean-Marc Valin Message-ID: Thread-Topic: [codec] Codec proposal: draft-valin-celt-codec-00.txt Thread-Index: Acn9pFiePT62F1ul50yhHzGyNkri1w== In-Reply-To: <4A5099CE.6060608@usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 19:11:02 -0000 Hi Jean-Marc, Re point 2, the license to be used (once the I-D were to become an RFC) can be found here: http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. It's a BSD-style license, like yours, but the attribution is different. That's what I meant, and I'm sorry for having been unclear. Regards, Stephan P.s.: AFAIK, there is no formal requirement to have the correct license and attribution in an I-D, so there is nothing wrong with it for now. On 7/5/09 5:17 AM, "Jean-Marc Valin" wrote= : >=20 >=20 > Stephan Wenger a =E9crit : >> Three things that will hopefully be seen as constructive :-): >> First, posting reference code in text format, while quite common in spee= ch >> standards, is not that overly helpful IMHO, especially considering the >> number of lines of code. At least during the I-D phase, a reference to = an >> URL where one can retrieve a stable version of the code, plus a promise = to >> copy-paste that code into a final RFC if that were the consensus, seems = to >> suffice. >=20 > I agree that the 72-column text format isn't great for source code (took > me a while just to make it fit!). Right now, the source code in the RFC > actually differs from the downloadable code in that it has been > simplified to only support floating point (the main reference code can > switch from float to fixed-point through macros). In any case if the > consensus is to leave it out during drafting, that's what I'll do. >=20 >> Second, if you add code into your I-D, it would IMHO make sense if you w= ould >> start using the required license---a BSD derivate. While I personally >> appreciate your very broad license, it is not directly compatible with t= he >> BSD license we require for code sections of RFCs. >=20 > Not sure what you mean here. The license on the files I appended *is* > the BSD license. >=20 >> Third, it would be helpful if you would explicitly state what part of yo= ur >> I-D actually is the normative specification: source code, or textual >> description. I note that in most ITU and 3GPP speech codec standards, t= he >> code is actually setting the normative standard, and the textual descrip= tion >> is informative. If I recall correctly, in the IETF's LBC effort the sam= e >> holds (I didn't check this---too lazy). To me, using source code as the >> normative standard makes sense---for speech coding only. If that's what= is >> intended here, please make sure that it is prominently advertised. >=20 > Actually, I couldn't find such a statement in iLBC (though I may have > missed it). Unless there's a good reason not to do that that I'm unaware > of, I agree that it's safer to make the C code normative. >=20 > Cheers, >=20 > Jean-Marc >=20 >=20 >> On 7/4/09 9:13 PM, "Jean-Marc Valin" wr= ote: >>=20 >>> Hi everyone, >>>=20 >>> Here's a first codec proposal: >>> http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt >>>=20 >>> Cheers, >>>=20 >>> Jean-Marc >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 >>=20 >>=20 >=20 From gmaxwell@juniper.net Mon Jul 6 09:17:04 2009 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 6A88E3A6D1B for ; Mon, 6 Jul 2009 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 sUSqxLFzJd9q for ; Mon, 6 Jul 2009 09:17:03 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 785F93A6CF4 for ; Mon, 6 Jul 2009 09:17:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSlIjG46vqLhSH2SWPbohktSjUUWNRNSX@postini.com; Mon, 06 Jul 2009 09:17:29 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 6 Jul 2009 09:05:11 -0700 From: Gregory Maxwell To: Stephan Wenger , Jean-Marc Valin , "codec@ietf.org" Date: Mon, 6 Jul 2009 09:05:11 -0700 Thread-Topic: [codec] Codec proposal: draft-valin-celt-codec-00.txt Thread-Index: Acn9LK0Fjj+sbkve5kSflNH9AKEkwABJTirr Message-ID: References: <4A502867.9090906@usherbrooke.ca>, 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:17:04 -0000 Stephan Wenger [stewe@stewe.org] wrote: [snip] > number of lines of code. At least during the I-D phase, a reference to a= n > URL where one can retrieve a stable version of the code, plus a promise t= o > copy-paste that code into a final RFC if that were the consensus, seems t= o > suffice. [snip] > Third, it would be helpful if you would explicitly state what part of you= r > I-D actually is the normative specification: source code, or textual > description. =20 [snip] I'm strongly in favour of leaning heavily on the source code as the normati= ve specification: Some parts, specifically any parts involving precise inte= ger arithmetic, are very difficult to describe in english with the necessar= y precision without creating a difficult to understand convoluted mess. But at the same time, if the source is the normative specification I think = it would be inappropriate to leave it out of the draft even temporarily.=20 There is also the issue that not all of the source is expected to have the = same degree of mandatory compliance. A convention for distinguishing these= parts will probably need to be adopted. Currently the text denotes operati= ons which must be bit-exact, so perhaps that is sufficient.=20 = From Jean-Marc.Valin@USherbrooke.ca Mon Jul 6 09:35:03 2009 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 53FBD3A67CF for ; Mon, 6 Jul 2009 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[AWL=-2.228, BAYES_40=-0.185, FRT_ADOBE2=2.455] 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 23+qlY-nWMC3 for ; Mon, 6 Jul 2009 09:35:02 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.USherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id 7DE1D28C3C3 for ; Mon, 6 Jul 2009 09:34:33 -0700 (PDT) Received: from localhost (www05.USherbrooke.ca [132.210.244.140]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n66FSNxR009349; Mon, 6 Jul 2009 11:28:23 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Mon, 6 Jul 2009 11:28:23 -0400 Message-ID: <1246894103.4a5218171664e@www.usherbrooke.ca> Date: Mon, 6 Jul 2009 11:28:23 -0400 From: Jean-Marc Valin To: Henry Sinnreich References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n66FSNxR009349 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: "codec@ietf.org" Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:35:03 -0000 Hi Henry, Quoting Henry Sinnreich : > >It is primarily designed for transmission over packet networks > > ?? Were we not supposed to work on an Internet voice codec? > Maybe this intent should be reflected in the text as well? > > If other "packet networks" may be suitable, which would they be and why? > (Does this can of worms need to be opened here?) Sorry, I was being a bit too vague. Will change to "over the Internet" for the next version. Cheers, Jean-Marc > Thanks, Henry > > > On 7/4/09 11:13 PM, "Jean-Marc Valin" wrote: > > Hi everyone, > > Here's a first codec proposal: > http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From hsinnrei@adobe.com Mon Jul 6 09:38:43 2009 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 217C528C396 for ; Mon, 6 Jul 2009 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2jBXH7dKtJL for ; Mon, 6 Jul 2009 09:38:39 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 27C9B3A679F for ; Mon, 6 Jul 2009 09:38:39 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSlIocUMQthSV28TV5HG1fO4wn/AbbCEE@postini.com; Mon, 06 Jul 2009 09:39:05 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n66F4Dao017691; Mon, 6 Jul 2009 08:04:13 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n66FAXiq028986; Mon, 6 Jul 2009 08:10:33 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 6 Jul 2009 08:10:33 -0700 From: Henry Sinnreich To: Jean-Marc Valin , "codec@ietf.org" Date: Mon, 6 Jul 2009 08:10:29 -0700 Thread-Topic: [codec] Codec proposal: draft-valin-celt-codec-00.txt Thread-Index: Acn9Jvaj64XJSv6yQUOLYtbfqyD3DABJO9Fo Message-ID: In-Reply-To: <4A502867.9090906@usherbrooke.ca> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6777E15485Bhsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:38:43 -0000 --_000_C6777E15485Bhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Congratulations Jean-Marc for the so very promising start! Just one small humble nit: >It is primarily designed for transmission over packet networks ?? Were we not supposed to work on an Internet voice codec? Maybe this intent should be reflected in the text as well? If other "packet networks" may be suitable, which would they be and why? (Does this can of worms need to be opened here?) Thanks, Henry On 7/4/09 11:13 PM, "Jean-Marc Valin" wrot= e: Hi everyone, Here's a first codec proposal: http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt Cheers, Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6777E15485Bhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt Congratulations Jean-Marc for the so very promising start!

Just one small humble nit:

>It is primarily designed for transmission over packet networks

?? Were we not supposed to work on an Internet voice codec?
Maybe this intent should be reflected in the text as well?

If other “packet networks” may be suitable, which would they be= and why?
(Does this can of worms need to be opened here?)

Thanks, Henry


On 7/4/09 11:13 PM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> wrote:

Hi everyone,

Here's a first codec proposal:
http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt
Cheers,

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6777E15485Bhsinnreiadobecom_-- From koen.vos@skype.net Tue Jul 7 22:12:49 2009 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 05A6428C396 for ; Tue, 7 Jul 2009 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 V-KxUinl88Wm for ; Tue, 7 Jul 2009 22:12:48 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 5142128C2C5 for ; Tue, 7 Jul 2009 22:12:47 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 6DB652007A7FD for ; Wed, 8 Jul 2009 07:13:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=b/c74F5252wi 0pWS/oyYe+mqiGc=; b=aBAhZ3WfolWt4b9paa3c2cqQzQvJtClEJK7wWuq04n0V GmVfKkOhxlAoyzneaVPk1fov728H67OSz9fdh2h7wrG8Tu5Yg55XJOidp2Himb0g xSVj2KfTHemNzchkgq2/Xc1LSuCuSe3C5wHpAAs98TpWV61VZQeDX9Ky0Q6tadw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=QGFq5cNAUnq8x7wHMb2q Df897FCaVEI1q8Z5r2PSXytrGekaOC+EcJW5n/JJb67Jil4Z9mz/xtqxXtdNEEZt wmhl0O3CMe1jA1lxHYes/yY2VwH2reWtB5CsD2jU0jSHcbOCC+jPIR7yXLrIInEN EsL/qQRKFv21l5eHPZmWp5o= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 6C4432007A7F0 for ; Wed, 8 Jul 2009 07:13:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzQSt9E8jMpN for ; Wed, 8 Jul 2009 07:13:04 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id E433E2007A7C5; Wed, 8 Jul 2009 07:13:04 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Tue, 07 Jul 2009 22:13:04 -0700 Message-ID: <20090707221304.12956xsx9vot1azk@mail.skype.net> Date: Tue, 07 Jul 2009 22:13:04 -0700 From: Koen Vos To: codec@ietf.org References: <4A502867.9090906@usherbrooke.ca>, In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 05:12:49 -0000 Hi all, We have recently submitted two Internet Drafts (https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-vos-silk-00.txt and https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-spittka-silk-payload-format-00.txt). These were submitted manually since we had problems with the web submission and may take a few days to show up on the mailing list. We are proposing SILK as a candidate codec for the Internet Wideband Audio Codec BOF in Stockholm. We've submitted an initial description of the SILK codec as well as a payload format draft. Comments are welcome. best regards, Koen From hoene@uni-tuebingen.de Wed Jul 8 00:11:21 2009 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 5D56A3A67B7 for ; Wed, 8 Jul 2009 00:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 6UC5fcjvjure for ; Wed, 8 Jul 2009 00:11:20 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 02AD23A6D29 for ; Wed, 8 Jul 2009 00:11:19 -0700 (PDT) Received: from [134.2.172.132] (u-172-c132.cs.uni-tuebingen.de [134.2.172.132]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n687Bcud012140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 09:11:38 +0200 From: Christian Hoene To: Koen Vos In-Reply-To: <20090707221304.12956xsx9vot1azk@mail.skype.net> References: <4A502867.9090906@usherbrooke.ca> , <20090707221304.12956xsx9vot1azk@mail.skype.net> Content-Type: text/plain Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_T=FCbingen?= Date: Wed, 08 Jul 2009 09:03:44 +0200 Message-Id: <1247036624.25968.7.camel@hoene-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.204; VDF: 7.1.4.197; host: mx05); id=19237-VzTYa4 Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 07:11:21 -0000 Hello Koen, > We have recently submitted two Internet Drafts > (https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-vos-silk-00.txt and https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-spittka-silk-payload-format-00.txt). These were submitted manually since we had problems with the web submission and may take a few days to show up on the mailing list. We are proposing SILK as a candidate codec for the Internet Wideband Audio Codec BOF in Stockholm. We've submitted an initial description of the SILK codec as well as a payload format draft. Comments are > welcome. It is really a nice Internet speech codec design. I especially liked the controlling of encoding parameters on a per frame basis: 3.1.1. Control Parameters The encoder with control parameters specifying the operating point is depicted in Figure 1. All control parameters can be changed during regular operation of the codec, when inputting a frame of audio data, without interrupting the audio stream from encoder to decoder. The codec control parameters are described in Section 3.1.1.1 to Section 3.1.1.5. Sampling rate ---------------+ Bitrate -------------+ | Packet rate -----------+ | | Packet loss rate ---------+ | | | Complexity -------+ | | | | Use DTX -----+ | | | | | | | | | | | \/\/\/\/\/\/ +-------------+ Input signal -->| Encoder |--> Bitstream +-------------+ These is a quite useful feature for VoIP applications. I have a question regarding the variable packet rate: 3.1.1.3. Packet Rate SILK encodes frames of 20 milliseconds at a time and can combine 1, 2, 3, 4 or 5 of these frames in one payload, thus creating one packet every 20, 40, 60, 80 or 100 milliseconds. Why did you decide to implement a variable packet rate by combining multiple frames into one packet? Isn't it is better to define individual frame formats for different packet rates. Then you can quantized the frame parameters more fine grained, don't you? With best regards, Christian From Borilin@spiritdsp.com Wed Jul 8 00:18:37 2009 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 5596328C2C3 for ; Wed, 8 Jul 2009 00:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.763, 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 pIj4fCqhGPfK for ; Wed, 8 Jul 2009 00:18:36 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 1E5E228C3B6 for ; Wed, 8 Jul 2009 00:18:35 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n687IuIL079825; Wed, 8 Jul 2009 11:18:57 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jul 2009 11:18:50 +0400 Message-ID: In-Reply-To: <1247036624.25968.7.camel@hoene-desktop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec proposal: draft-vos-silk-00.txt Thread-Index: Acn/m2N7GDBvBbRaSvGQbDl0ob+eiQAANHNg References: <4A502867.9090906@usherbrooke.ca>, <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> From: "Slava Borilin" To: "Christian Hoene" , "Koen Vos" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 07:18:37 -0000 Putting several frames into one packet is useful for packet grouping, which in turn is very useful for bandwidth adaptation and network usage efficiency, I would say? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Wednesday, July 08, 2009 11:04 AM To: Koen Vos Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt Hello Koen, > We have recently submitted two Internet Drafts =20 > (https://developer.skype.com/silk?action=3DAttachFile&do=3Dget&target=3Dd= raft- vos-silk-00.txt and https://developer.skype.com/silk?action=3DAttachFile&do=3Dget&target=3Ddr= aft-s pittka-silk-payload-format-00.txt). These were submitted manually since we had problems with the web submission and may take a few days to show up on the mailing list. We are proposing SILK as a candidate codec for the Internet Wideband Audio Codec BOF in Stockholm. We've submitted an initial description of the SILK codec as well as a payload format draft. Comments are =20 > welcome. It is really a nice Internet speech codec design. I especially liked the controlling of encoding parameters on a per frame basis: 3.1.1. Control Parameters The encoder with control parameters specifying the operating point is depicted in Figure 1. All control parameters can be changed during regular operation of the codec, when inputting a frame of audio data, without interrupting the audio stream from encoder to decoder. The codec control parameters are described in Section 3.1.1.1 to Section 3.1.1.5. Sampling rate ---------------+ Bitrate -------------+ | Packet rate -----------+ | | Packet loss rate ---------+ | | | Complexity -------+ | | | | Use DTX -----+ | | | | | | | | | | | \/\/\/\/\/\/ +-------------+ Input signal -->| Encoder |--> Bitstream +-------------+ These is a quite useful feature for VoIP applications.=20 I have a question regarding the variable packet rate: 3.1.1.3. Packet Rate SILK encodes frames of 20 milliseconds at a time and can combine 1, 2, 3, 4 or 5 of these frames in one payload, thus creating one packet every 20, 40, 60, 80 or 100 milliseconds. Why did you decide to implement a variable packet rate by combining multiple frames into one packet? Isn't it is better to define individual frame formats for different packet rates. Then you can quantized the frame parameters more fine grained, don't you? With best regards, Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Wed Jul 8 01:21:41 2009 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 2BD863A6D66 for ; Wed, 8 Jul 2009 01:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 NJzL8nIZZo4J for ; Wed, 8 Jul 2009 01:21:40 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 9C7F63A68FF for ; Wed, 8 Jul 2009 01:21:38 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n687V1ci019141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 09:31:01 +0200 From: "Christian Hoene" To: "'Slava Borilin'" , "'Koen Vos'" References: <4A502867.9090906@usherbrooke.ca>, <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> In-Reply-To: Date: Wed, 8 Jul 2009 09:31:01 +0200 Message-ID: <001e01c9ff9e$0bebacc0$23c30640$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn/m2N7GDBvBbRaSvGQbDl0ob+eiQAANHNgAABEWgA= Content-language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:21:41 -0000 Hi Slava Borilin, yes, you are right. The question is one whether to make the packet grouping in RTP or whether to change the encoding. Latter should be more efficient because the encoder can what advantage of it by e.g. reducing all inter-subframe redundancies, better parameter compression and so on. I am just wondering, why where is no codec which does the frame concatenation by itself? Is the gain too small? With best regards, Christian > -----Original Message----- > From: Slava Borilin [mailto:Borilin@spiritdsp.com] > Sent: Wednesday, July 08, 2009 9:19 AM > To: Christian Hoene; Koen Vos > Cc: codec@ietf.org > Subject: RE: [codec] Codec proposal: draft-vos-silk-00.txt > > Putting several frames into one packet is useful for packet grouping, > which in turn is very useful for bandwidth adaptation and network usage > efficiency, I would say? > > best regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Wednesday, July 08, 2009 11:04 AM > To: Koen Vos > Cc: codec@ietf.org > Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt > > Hello Koen, > > > We have recently submitted two Internet Drafts > > > (https://developer.skype.com/silk?action=AttachFile&do=get&target=draft- > vos-silk-00.txt and > https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-s > pittka-silk-payload-format-00.txt). These were submitted manually since > we had problems with the web submission and may take a few days to show > up on the mailing list. We are proposing SILK as a candidate codec for > the Internet Wideband Audio Codec BOF in Stockholm. We've submitted an > initial description of the SILK codec as well as a payload format draft. > Comments are > > welcome. > > It is really a nice Internet speech codec design. I especially liked the > controlling of encoding parameters on a per frame basis: > > 3.1.1. Control Parameters > > The encoder with control parameters specifying the operating point is > depicted in Figure 1. All control parameters can be changed during > regular operation of the codec, when inputting a frame of audio data, > without interrupting the audio stream from encoder to decoder. The > codec control parameters are described in Section 3.1.1.1 to > Section 3.1.1.5. > > > Sampling rate ---------------+ > Bitrate -------------+ | > Packet rate -----------+ | | > Packet loss rate ---------+ | | | > Complexity -------+ | | | | > Use DTX -----+ | | | | | > | | | | | | > \/\/\/\/\/\/ > +-------------+ > Input signal -->| Encoder |--> Bitstream > +-------------+ > > > These is a quite useful feature for VoIP applications. > I have a question regarding the variable packet rate: > > 3.1.1.3. Packet Rate > > SILK encodes frames of 20 milliseconds at a time and can combine 1, > 2, 3, 4 or 5 of these frames in one payload, thus creating one packet > every 20, 40, 60, 80 or 100 milliseconds. > > Why did you decide to implement a variable packet rate by combining > multiple frames into one packet? Isn't it is better to define individual > frame formats for different packet rates. Then you can quantized the > frame parameters more fine grained, don't you? > > > With best regards, > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From xiphmont@gmail.com Wed Jul 8 01:34:13 2009 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 54EE23A684D for ; Wed, 8 Jul 2009 01:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 zP0IJj6ZE69o for ; Wed, 8 Jul 2009 01:34:12 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 4AE553A68EC for ; Wed, 8 Jul 2009 01:34:02 -0700 (PDT) Received: by yxe12 with SMTP id 12so8803808yxe.29 for ; Wed, 08 Jul 2009 01:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Bv+1LFgJqJik7Sb8LJXSxCHLFSNXG0NxUhXqOyXp2o=; b=FJ2jiipDi5QMZSn3UBlqFsBgEz5wGFgT2OGprQKsZdBojK5h4yNYMkseGljxxW0EBA mhP9skxrIVQ+K0rqeLbhRPvsgfpx3IjOiwLEZ3CHxDWrkkOYsQDxx7McteQFMUR8TURt LAqF0KROTQwe4ETUYzgMM9f4vLOQ78YH6hFPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UvspgEKzHfEU+k7G0Lh/bvsXobZXUyEADYRWNx97wT5nawyujjgw1TRF3P+KPjWVJx QtKMgHP9C7VL9abkl+OZZUbcVm6nJ3rS1K2juZqg3rc84liuKfQjfcdyaks0CymEYKn4 tLYEjiB1BgvUdhnzeqFgXXBIoahsZIQ7e8KBE= MIME-Version: 1.0 Received: by 10.231.38.140 with SMTP id b12mr3399067ibe.29.1247041900111; Wed, 08 Jul 2009 01:31:40 -0700 (PDT) In-Reply-To: <001e01c9ff9e$0bebacc0$23c30640$@de> References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> <001e01c9ff9e$0bebacc0$23c30640$@de> Date: Wed, 8 Jul 2009 04:31:40 -0400 Message-ID: <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> From: Christopher Montgomery To: Christian Hoene Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:34:13 -0000 On Wed, Jul 8, 2009 at 3:31 AM, Christian Hoene wro= te: > Hi Slava Borilin, > > yes, you are right. The question is one whether to make the packet groupi= ng > in RTP or whether to change the encoding. > =A0Latter should be more efficient because the encoder can what advantage= of > it by e.g. reducing all inter-subframe redundancies, better parameter > compression and so on. > > I am just wondering, why where is no codec which does the frame > concatenation by itself? Is the gain too small? In general, if you're going to send multiple frames grouped together anyway, the gain from having a single large frame is even larger than grouping multiple small frames post-facto, especially in codecs using a monolithic transform space. Monty From jean-marc.valin@usherbrooke.ca Wed Jul 8 04:29:16 2009 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 65DE93A6A03 for ; Wed, 8 Jul 2009 04:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 hfCYGTdYY39W for ; Wed, 8 Jul 2009 04:29:14 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 3F88F3A6F17 for ; Wed, 8 Jul 2009 04:28:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMG00FB7NW8L610@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Wed, 08 Jul 2009 07:28:57 -0400 (EDT) Message-id: <4A5482F8.90500@usherbrooke.ca> Date: Wed, 08 Jul 2009 07:28:56 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Christopher Montgomery References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> <001e01c9ff9e$0bebacc0$23c30640$@de> <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> In-reply-to: <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> X-Enigmail-Version: 0.95.2 Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:29:16 -0000 Christopher Montgomery a écrit : > On Wed, Jul 8, 2009 at 3:31 AM, Christian Hoene wrote: >> I am just wondering, why where is no codec which does the frame >> concatenation by itself? Is the gain too small? > > In general, if you're going to send multiple frames grouped together > anyway, the gain from having a single large frame is even larger than > grouping multiple small frames post-facto, especially in codecs using > a monolithic transform space. While this is obviously true of a transform codec like Vorbis where a larger frame means better frequency resolution (and already less so on CELT), the gain is much smaller on a time-domain codec like SILK, especially for > 20 ms frames. Making bigger frames instead of using multiple smaller frames is usually not worth the extra code size and memory required, both in the codec and for the client to deal with changing frame sizes. Also, there's a loss of flexibility because you can't re-packetize in the middle. Considering that: "The extent to which SILK exploits inter-frame dependencies can be adjusted on the fly to choose a trade-off between bitrate and amount of error propagation." I think it may even be possible to just make use of more inter-frame correlation for frames 2..N in a packet of N frames and get most of the benefits it would get from a larger frame size. Cheers, Jean-Marc From jean-marc.valin@usherbrooke.ca Wed Jul 8 04:33:11 2009 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 5D3EB28C56C for ; Wed, 8 Jul 2009 04:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 X35YfxQPXFi5 for ; Wed, 8 Jul 2009 04:33:10 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 6E5BA3A6F34 for ; Wed, 8 Jul 2009 04:33:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMG00N5ZNLH2W00@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Wed, 08 Jul 2009 07:22:29 -0400 (EDT) Message-id: <4A54840D.7000005@usherbrooke.ca> Date: Wed, 08 Jul 2009 07:33:33 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Koen Vos References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> In-reply-to: <20090707221304.12956xsx9vot1azk@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:33:11 -0000 Hi Koen, Not sure what problem you got, but for me I had to use the "experimental version" of xml2rfc ( http://xml.resource.org/experimental.html ), along with ipr="trust200902" in the tag before the system would accept my submission. Cheers, Jean-Marc Koen Vos a écrit : > We have recently submitted two Internet Drafts > (https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-vos-silk-00.txt > and > https://developer.skype.com/silk?action=AttachFile&do=get&target=draft-spittka-silk-payload-format-00.txt). > These were submitted manually since we had problems with the web > submission and may take a few days to show up on the mailing list. We > are proposing SILK as a candidate codec for the Internet Wideband Audio > Codec BOF in Stockholm. We've submitted an initial description of the > SILK codec as well as a payload format draft. Comments are welcome. > > best regards, > Koen > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From jean-marc.valin@usherbrooke.ca Wed Jul 8 04:43:32 2009 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 0858F3A6F40 for ; Wed, 8 Jul 2009 04:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 8EZREYPIfJb3 for ; Wed, 8 Jul 2009 04:43:31 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 4F4EE3A63C9 for ; Wed, 8 Jul 2009 04:43:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMG00NPTO162W10@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Wed, 08 Jul 2009 07:31:55 -0400 (EDT) Message-id: <4A548643.1010500@usherbrooke.ca> Date: Wed, 08 Jul 2009 07:42:59 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Jean-Marc Valin References: <4A502867.9090906@usherbrooke.ca> In-reply-to: <4A502867.9090906@usherbrooke.ca> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec proposal: draft-valin-celt-codec-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:43:32 -0000 Hi, I'd just like to point out that there is also an RTP payload format available for CELT: http://www.ietf.org/internet-drafts/draft-valin-celt-rtp-profile-01.txt Cheers, Jean-Marc Jean-Marc Valin a écrit : > Hi everyone, > > Here's a first codec proposal: > http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From Jean-Marc.Valin@USherbrooke.ca Wed Jul 8 06:17:20 2009 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 2D7B128C559 for ; Wed, 8 Jul 2009 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 lnX5SEKfoKC4 for ; Wed, 8 Jul 2009 06:17:18 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.usherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id B0BCD28C4E7 for ; Wed, 8 Jul 2009 06:17:18 -0700 (PDT) Received: from localhost (www05.USherbrooke.ca [132.210.244.140]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n68DHYJO017519; Wed, 8 Jul 2009 09:17:34 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Wed, 8 Jul 2009 09:17:34 -0400 Message-ID: <1247059054.4a549c6e885b3@www.usherbrooke.ca> Date: Wed, 8 Jul 2009 09:17:34 -0400 From: Jean-Marc Valin To: Christian Hoene References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> <001e01c9ff9e$0bebacc0$23c30640$@de> <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> <4A5482F8.90500@usherbrooke.ca> <007301c9ffc4$6bf9b690$43ed23b0$@de> In-Reply-To: <007301c9ffc4$6bf9b690$43ed23b0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n68DHYJO017519 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 13:17:20 -0000 Quoting Christian Hoene : > Hi all, I think you forgot to include the list in your original message, so I'm quoting your whole message for the benefit of others. > > While this is obviously true of a transform codec like Vorbis where a > > larger frame means better frequency resolution (and already less so on > > CELT), the gain is much smaller on a time-domain codec like SILK, > > especially for > 20 ms frames. > > Can this gain be quantified? Are their any scientific studies? There are no scientific studies, because it's too hard to measure (it depends on the implementation), but here's my experience from Speex (I have no reason to think it doesn't apply to SILK as well). There are mainly three types of parameters that CELP and other LP-based codecs transmit (from the biggest to the smallest): quantised residual (innovation), LSP coefficients, and pitch parameters. First, the quantised residual usually takes up at least 50% of the bits and in the case of Speex, it is transmitted based on intervals that are shorter than 5 ms anyway, so larger frames would have no impact whatsoever. In the case of SILK, it seems to be entropy coded one sample at a time, so presumably there would be no impact there either (maybe a negligible gain in the entropy coder, but probably not worth it). Then there's the LSP parameters. Those represent the speech spectrum and are usually considered stationary on 20 ms blocks. That's why a lot of speech algorithms (e.g. recognition) work on 20 ms blocks even when there's no coding and latency involved. Again, using 40 ms blocks, would mean having to code the LSPs twice, which means you don't gain much. The last is the pitch parameters. Those tend to be coded on 5-10 ms blocks, so again I don't see a point in having frames larger than 20 ms. > > Making bigger frames instead of using > > multiple smaller frames is usually not worth the extra code size and > > memory required, both in the codec and for the client to deal with > > changing frame sizes. > > Nowadays every device has gigabits of memory. Isn't the argumentation on > extra code size and memory a bit outdated? Not every device has gigabits of memory. Many low-power DSPs operate with very little internal (SRAM) memory (e.g. 64 kB for code and data) and transfers to/from external memory are expensive. > > Also, there's a loss of flexibility because you > > can't re-packetize in the middle. > > Sorry, JM, this argument is sooo "circuit-switched" ;-) Last I checked, circuit-switched networks didn't use packets :-) > In the Internet we have the end-to-end principle, which requires that the > transport layer is send transparently between two end nodes > (http://en.wikipedia.org/wiki/End-to-end_principle). If a codec is designed > for the Internet, then there will not be any transcoding or reframing of RTP > packets. That's assuming you're not trying to be compatible with legacy infrastructure. PSTN gateways will continue to exist for a while and saving two bits on an Internet codec is not a valid reason to make their lives more complicated. Cheers, Jean-Marc > > Considering that: > > "The extent to which SILK exploits inter-frame dependencies can be > > adjusted on the fly to choose a trade-off between bitrate and amount of > > error propagation." > > > > I think it may even be possible to just make use of more inter-frame > > correlation for frames 2..N in a packet of N frames and get most of the > > benefits it would get from a larger frame size. > > Yes, I agree. Setting the inter-frame correlation high for the frame within > a packet and low for frames between two packets considering, could give a > benefit. > > Cheers, > > Christian > > > > From jean-marc.valin@octasic.com Wed Jul 8 06:42:44 2009 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 E26B13A6B4A; Wed, 8 Jul 2009 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 9cO3baMj5DBT; Wed, 8 Jul 2009 06:42:43 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 918BA28C44A; Wed, 8 Jul 2009 06:42:42 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 09:42:35 -0400 Message-ID: <4A54A2C4.1090302@octasic.com> Date: Wed, 08 Jul 2009 09:44:36 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Stefan Sayer References: <49B52906.5000300@octasic.com> <49B58D1E.702@octasic.com> <4A088444.50403@octasic.com> <4A54643C.1050108@iptego.com> In-Reply-To: <4A54643C.1050108@iptego.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 13:42:35.0925 (UTC) FILETIME=[F3BCBC50:01C9FFD1] Cc: "codec@ietf.org" , avt@ietf.org Subject: Re: [codec] [AVT] Request for feedback on draft-valin-celt-rtp-profile-01.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 13:42:44 -0000 Hi Stefan, Thanks very much for taking the time to review this draft. Stefan Sayer wrote: > My suggestion is to remove the first diagram (anyway it is clear that > the payload follows the RTP header), or add the length bytes to it to > make clear that this is the usual mode of packetization. I have followed your suggestion and removed the diagram. > In 5.2. Low-Overhead Mode, the text says: > "One the a=fmtp: parameter low- > overhead: is defined and contains a single frame size, followed by a > '/', followed by a comma-separated list of the number of bytes per > frame for each stream defined in the channel mapping." > but the example gives: > a=fmtp:97 low-overhead=256/1/86,86,43,30;mapping=2,2,1,1/ > L,R,LR,RR,C,MLFE/ITU-RBS.775-1 > What is the extra /1 supposed to mean in 256/1/86,86,43,30 ? Sorry. The /1 was a left-over from a previous revision and is no longer necessary. I've removed it now. > Also, a simpler example (e.g. for mono and stereo streams) could be > illustrative. Thanks for the suggestion. I added a plain mono example. The next now reads: For example a low-overhead 64 kbit/s mono stream could be signaled as: m=audio 8008 RTP/AVP 97 a=ptime: 5 a=rtpmap:97 CELT/48000/1 a=fmtp:97 low-overhead=256/43 and a low-overhead 360 kbit/s 5.1 surround configuration could be signaled as: m=audio 8008 RTP/AVP 97 a=ptime: 5 a=rtpmap:97 CELT/48000/6 a=fmtp:97 low-overhead=256/86,86,43,25;mapping=2,2,1,1/ L,R,LR,RR,C,MLFE/ITU-RBS.775-1 Cheers, Jean-Marc From hoene@uni-tuebingen.de Wed Jul 8 07:10:25 2009 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 1100E3A6AC2 for ; Wed, 8 Jul 2009 07:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 V4ypY1M71WZX for ; Wed, 8 Jul 2009 07:10:24 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 857BD3A696B for ; Wed, 8 Jul 2009 07:10:21 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n68E9wOW026533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 16:09:59 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> <001e01c9ff9e$0bebacc0$23c30640$@de> <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> <4A5482F8.90500@usherbrooke.ca> <007301c9ffc4$6bf9b690$43ed23b0$@de> <1247059054.4a549c6e885b3@www.usherbrooke.ca> In-Reply-To: <1247059054.4a549c6e885b3@www.usherbrooke.ca> Date: Wed, 8 Jul 2009 16:09:58 +0200 Message-ID: <008601c9ffd5$c7d21280$57763780$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn/zo6/iqqiVy/fSIulus+sL5oWQAAAjXdQ Content-language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:10:25 -0000 Hi all > > > Making bigger frames instead of using > > > multiple smaller frames is usually not worth the extra code size and > > > memory required, both in the codec and for the client to deal with > > > changing frame sizes. > > > > Nowadays every device has gigabits of memory. Isn't the argumentation on > > extra code size and memory a bit outdated? > > Not every device has gigabits of memory. Many low-power DSPs operate with very > little internal (SRAM) memory (e.g. 64 kB for code and data) and transfers > to/from external memory are expensive. I just want to question whether such low-power DSPs will be used for high quality audio or superwide-speech transmissions over the Internet. If power needs to be saved, why not use narrow-band speech transmissions? Also, you must look at the entire system. If you can encode audio better with less bits, you save transmission energy. Do you agree with me that this question cannot be solved on a mailing list but must be analyzed scientifically? > > In the Internet we have the end-to-end principle, which requires that the > > transport layer is send transparently between two end nodes > > (http://en.wikipedia.org/wiki/End-to-end_principle). If a codec is designed > > for the Internet, then there will not be any transcoding or reframing of RTP > > packets. > > That's assuming you're not trying to be compatible with legacy infrastructure. I think we have to be precise on whether repacketization in a network is needed and where. Do you (or anybody else) know which kind of infrastructure requires repacketization? In TURN servers, MGCP media gateways? I am not aware of a VoIP gateway that does this and that is not coupled to a PSTN infrastructure. Also, how to stay compatible if a new codec is introduced? You have to run an update anyhow that will include the gateway, too. > PSTN gateways will continue to exist for a while Neither SBC, CELT nor SILK will be ever used in a PSTN network. Thus, a PSTN gateway has to transcode the speech stream anyhow. Repacketization does not matter then. My argumentation is the same as with open-source codecs: We are in a disruptive technology change. Some of the rules that used to be valid need to be questioned. To remain compatible with legacy infrastructure (especially PSTN circuit-switched based) should not be an important requirement for a codec proposed in an Internet standardization body. That's is the task of ITU or 3GPP. Prost, Christian From jean-marc.valin@octasic.com Wed Jul 8 07:28:21 2009 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 7A8723A6BA2 for ; Wed, 8 Jul 2009 07:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 YxYley7txWc7 for ; Wed, 8 Jul 2009 07:28:20 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 166583A6B72 for ; Wed, 8 Jul 2009 07:28:19 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 10:28:22 -0400 Message-ID: <4A54AD7F.1050509@octasic.com> Date: Wed, 08 Jul 2009 10:30:23 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Christian Hoene References: <4A502867.9090906@usherbrooke.ca> <20090707221304.12956xsx9vot1azk@mail.skype.net> <1247036624.25968.7.camel@hoene-desktop> <001e01c9ff9e$0bebacc0$23c30640$@de> <806dafc20907080131j5a43f342me3d02650f4a9e5d@mail.gmail.com> <4A5482F8.90500@usherbrooke.ca> <007301c9ffc4$6bf9b690$43ed23b0$@de> <1247059054.4a549c6e885b3@www.usherbrooke.ca> <008601c9ffd5$c7d21280$57763780$@de> In-Reply-To: <008601c9ffd5$c7d21280$57763780$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 14:28:22.0576 (UTC) FILETIME=[58DE6B00:01C9FFD8] Cc: codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Codec proposal: draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:28:21 -0000 Christian Hoene wrote: >> Not every device has gigabits of memory. Many low-power DSPs operate with > very >> little internal (SRAM) memory (e.g. 64 kB for code and data) and transfers >> to/from external memory are expensive. > > I just want to question whether such low-power DSPs will be used for high > quality audio or superwide-speech transmissions over the Internet. If power > needs to be saved, why not use narrow-band speech transmissions? Internet devices are no longer just PCs. There's more and more low-power portable devices equipped with DSPs. It would be a mistake to restrict these devices to narrowband just so you can save a few bits by increasing the code size. In the end, it's always a matter of trade-off and seeing what you can gain from an increase in code size or complexity. From what I've read about SILK so far (we'll see when there's more information and source code), I see no reason to question the trade-off that were made. > Also, you must look at the entire system. If you can encode audio better > with less bits, you save transmission energy. > > Do you agree with me that this question cannot be solved on a mailing list > but must be analyzed scientifically? I don't agree. These kinds of questions are related to the requirements and should eventually (now or later) be discussed on the list. These are not that much scientific issues, but issues about what we are trying to achieve, i.e. what is useful. Cheers, Jean-Marc From stefan.sayer@iptego.com Wed Jul 8 08:01:20 2009 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 D45503A6A22; Wed, 8 Jul 2009 08:01:20 -0700 (PDT) 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=[AWL=0.000, 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 YpckmoGVDiq6; Wed, 8 Jul 2009 08:01:20 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id A64B63A69CA; Wed, 8 Jul 2009 08:01:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 458C0115407D; Wed, 8 Jul 2009 17:01:45 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do4AsZB2ct2e; Wed, 8 Jul 2009 17:01:45 +0200 (CEST) Received: from [192.168.5.106] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id ED0FF1154038; Wed, 8 Jul 2009 17:01:44 +0200 (CEST) Message-ID: <4A54B4E8.6060402@iptego.com> Date: Wed, 08 Jul 2009 17:02:00 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Jean-Marc Valin References: <49B52906.5000300@octasic.com> <49B58D1E.702@octasic.com> <4A088444.50403@octasic.com> <4A54643C.1050108@iptego.com> <4A54A2C4.1090302@octasic.com> In-Reply-To: <4A54A2C4.1090302@octasic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" , avt@ietf.org Subject: Re: [codec] [AVT] Request for feedback on draft-valin-celt-rtp-profile-01.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:01:20 -0000 Hello Jean-Marc, thanks a lot for the quick response! o Jean-Marc Valin [07/08/09 15:44]: > Hi Stefan, > > Thanks very much for taking the time to review this draft. > > Stefan Sayer wrote: >> My suggestion is to remove the first diagram (anyway it is clear that >> the payload follows the RTP header), or add the length bytes to it to >> make clear that this is the usual mode of packetization. > > I have followed your suggestion and removed the diagram. If I have understood correctly, this is essentially two different modes of packetization, the default one (where frame size bytes are alway present, also if only one frame per packet), and the L-O mode (without frame size). May I additionally suggest a clarifying paragraph about this in "3.2. CELT payload" ? An RTP packet MAY contain CELT frames of the same bit rate or of varying bit rates, since the bitrate for the frames is explicitly conveyed in band with the signal. The encoding and decoding algorithm can change the bit rate at any frame boundary, with the bit rate change notification provided in-band. No out-of-band notification is required for the decoder to process changes in the bit rate sent by the encoder. + More than one frame may be encoded in the same RTP packet, and for + the decoder it is not possible to determine the size of each encoded + frame. Thus the frame size information MUST be explicitly trans- + mitted. There is two modes how this information may be conveyed: + Either the frame size(s) are encoded for each frame at the + beginning of the RTP payload (Section 3.3), or it is conveyed in the + signaling and then fixed for the duration of the session + (Low-Overhead Mode, Section 5.2). Note that the frame size + information must be present either way even if only single frames + are transmitted per RTP packet. It is RECOMMENDED that sampling rates 32000, 44100, or 48000 Hz be used for most applications, unless a specific reason exists -- such ... Maybe this is too verbose, but I think you get the idea what would make the busy reader, who may be unfamiliar with the codec and its requirements, understand it more quickly. I also have one further question about the Low-Overhead mode: Do you expect this to be the standard use case, or (possibly also due to the limitation of fixed bitrate) only the corner case where bandwidth saving wins over flexibility? I think it might make sense to give a recommendation about which mode to use, i.e. where the tradeoff really points in which direction. Thank You very much Stefan Sayer From jean-marc.valin@octasic.com Wed Jul 8 08:18:00 2009 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 BDAAA3A6AA7; Wed, 8 Jul 2009 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 DxiMtTZ5RHDC; Wed, 8 Jul 2009 08:17:55 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 206863A69CA; Wed, 8 Jul 2009 08:17:54 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 11:18:21 -0400 Message-ID: <4A54B936.9000606@octasic.com> Date: Wed, 08 Jul 2009 11:20:22 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Stefan Sayer References: <49B52906.5000300@octasic.com> <49B58D1E.702@octasic.com> <4A088444.50403@octasic.com> <4A54643C.1050108@iptego.com> <4A54A2C4.1090302@octasic.com> <4A54B4E8.6060402@iptego.com> In-Reply-To: <4A54B4E8.6060402@iptego.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 15:18:21.0449 (UTC) FILETIME=[54561F90:01C9FFDF] Cc: "codec@ietf.org" , avt@ietf.org Subject: Re: [codec] [AVT] Request for feedback on draft-valin-celt-rtp-profile-01.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:18:00 -0000 Stefan Sayer wrote: > o Jean-Marc Valin [07/08/09 15:44]: >> Hi Stefan, >> >> Thanks very much for taking the time to review this draft. >> >> Stefan Sayer wrote: >>> My suggestion is to remove the first diagram (anyway it is clear that >>> the payload follows the RTP header), or add the length bytes to it to >>> make clear that this is the usual mode of packetization. >> >> I have followed your suggestion and removed the diagram. > > If I have understood correctly, this is essentially two different modes > of packetization, the default one (where frame size bytes are alway > present, also if only one frame per packet), and the L-O mode (without > frame size). May I additionally suggest a clarifying paragraph about > this in "3.2. CELT payload" ? Thanks for the suggestion. I've slightly rephrased it (and changed frame size to compressed size to avoid confusion with the frame size that's in samples): More than one frame may be encoded in the same RTP packet, and for the decoder it is not possible to determine the compressed size (bit- rate) of each encoded frame. Thus the compressed size information MUST be explicitly transmitted. There are two modes for conveying this information: either the compressed size(s) are encoded for each frame at the beginning of the RTP payload Section 3.3, or it is conveyed in the signaling and then fixed for the duration of the session (Low-Overhead Mode, Section 5.2). Note that the compressed frame size information must be present either way even if only single frames are transmitted per RTP packet. > I also have one further question about the Low-Overhead mode: Do you > expect this to be the standard use case, or (possibly also due to the > limitation of fixed bitrate) only the corner case where bandwidth saving > wins over flexibility? I think it might make sense to give a > recommendation about which mode to use, i.e. where the tradeoff really > points in which direction. At this point, I do not know which of the two modes would be the most useful. I'm interested in opinions on this. Cheers, Jean-Marc From Borilin@spiritdsp.com Wed Jul 8 09:43:39 2009 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 348FB3A6BAA for ; Wed, 8 Jul 2009 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-1.358, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_KOI8R=0.67] 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 XJm1CY8w8qUU for ; Wed, 8 Jul 2009 09:43:38 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 145373A6B37 for ; Wed, 8 Jul 2009 09:43:37 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n68Gi1UV090553; Wed, 8 Jul 2009 20:44:02 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jul 2009 20:43:55 +0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <40525BF9-603F-4302-8ABD-623846857702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?koi8-r?Q?=5Bcodec=5D_RE=9A=3A_Codec_BOF_approved=2C_much_work_needed?= Thread-Index: Acn2ESbweTxNTuzSQqS7FV+cXwTmXgJ2ORvQ References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> <40525BF9-603F-4302-8ABD-623846857702@cisco.com> From: "Slava Borilin" To: "Cullen Jennings" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] =?koi8-r?b?UkWaOiBDb2RlYyBCT0YgYXBwcm92ZWQsIG11Y2ggd29y?= =?koi8-r?b?ayBuZWVkZWQ=?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:43:39 -0000 Cullen, Sorry for delayed answer. For codecs - most of ITU codecs are (were) not for IP networks, so I = believe they did not care at all and so there was no practice (only = G.718 may be the exception). However, it is always some simulation for every network type (very = common is radio network with errors, for example, when it comes to = codecs to be used in the=20 TIA-921 is nowadays used by carriers when they do judge/accept the = overall VoIP systems, so it sounds as good candidate for judging the = codec as well. Regards, Slava Borilin -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, June 26, 2009 7:50 AM To: Slava Borilin Cc: codec@ietf.org Subject: Re: [codec] RE=9A: Codec BOF approved, much work needed On Jun 18, 2009, at 6:56 , Slava Borilin wrote: > For congested networks - I assume that the way to judge the codec is =20 > to judge the MOS over TIA-921 network profiles (that's what we use) =20 > which covers realistic packet loss and congestion scenarios, and not =20 > just "average normally distributed XX% packet loss". Roni brought up and interesting point about looking at how other =20 groups doing codec design did the design and evaluation. Just out of =20 curiosity, are the TIA-921 profiles what folks doing codec design at =20 the ITU use as the basis of design for codecs to run over IP networks? From Borilin@spiritdsp.com Wed Jul 8 09:49:26 2009 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 061563A6F6C for ; Wed, 8 Jul 2009 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.788, 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 9nXzUPHU6EXq for ; Wed, 8 Jul 2009 09:49:24 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id D82AB3A69CA for ; Wed, 8 Jul 2009 09:49:14 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n68Gmx5A090658; Wed, 8 Jul 2009 20:49:00 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jul 2009 20:48:53 +0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4a447b45.06e2660a.7f72.7db8@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQAm8jFQA= References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com><945FAEF4-1515-4816-8A3A-9ED2475BA455@cisco.com> <4a447b45.06e2660a.7f72.7db8@mx.google.com> From: "Slava Borilin" To: "Roni Even" , "Cullen Jennings" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:49:26 -0000 Dear Roni, Cullen, Can you please advice on the procedure- there are some suggestions to agenda made on this list- how this should translate into the final agenda? Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, June 26, 2009 11:40 AM To: 'Cullen Jennings' Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Cullen, Thanks, If I may, I would like to suggest based on my observations on the list discussion that the agenda will also include the following topics. 1. Should the IETF work on codecs (speech/audio) 2. If yes, should the these codecs be standard track or informational. I am suggesting this item since as far as I understand after iLBC publication the conclusion was that the IETF cannot do expert review on codecs even for Informational status. 3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no agreement that the IETF can provide with high probability a RF codec. I think that only after these topics, which looks to me like ground rules, are addressed we can start discussing the content of the charter.=20 Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 9:09 AM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed >=20 >=20 > Roni, >=20 > The primary goal of this BOF should be collecting the information that > helps make an informed decision about if a WG should be formed or not. > I certainly did not mean to imply by the agenda that there was any > assumption that a WG would be formed. >=20 > I agree the charter below is far from ideal for collecting this > information. I'm expecting the agenda to change, based on the list > discussion, so we have time to talk about the key topics where > community input is needed to drive the decisions about if a WG should > be formed or not. >=20 > Cullen >=20 >=20 > On Jun 19, 2009, at 8:59 , Ron Even wrote: >=20 > > Cullen, > > I looked at the agenda > > > > 1. Administrative (Chairs, 5 min) > > - Note takers, Jabber scribes > > - Agenda bashing > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > 3. Proposed CODECs (TBD, 25 min) > > - Expect to have two or more drafts here > > > > 4. Charter Discussion (All, 40 min) > > > > 5. Decisions and HUMs (All, 5 min) > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > And it looks to me that it starts with assumption that we will have > > a new working group. > > > > I am not sure that that this was agreed and yet I see no time > > allocated to discuss the topic. I would expect that item 3 will be > > rational for doing codec at the IETF considering that this work is > > done also by other SDOs that the IETF is working with. > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should > > be done later. > > > > Roni Even > > > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > Of Cullen Jennings > > > Sent: Friday, June 12, 2009 8:32 PM > > > To: codec@ietf.org > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > > work to get ready. Various people on IESG/IAB were not comfortable > > > with the current charter and agenda so we need to work on theses > > > before the meeting. > > > > > > A draft agenda/charter Jason provided are at > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > bof/charter.txt > > > > > > After discussion with the IESG/IAB: > > > > > > I'd like to remove the "as Proposed Standard" from the charter text > > > for both milestones and see how the discussion goes in the BOF > > before > > > deciding which way this should go. > > > > > > I'd like to see more consideration around the issues of designing a > > > codec that did a good job of mapping a real time stream onto IP > > > packets. The way IP deals with packet loss and congestion has > > > implications for designing a codec that works well over IP. I know > > > some of the discussion I have had off list people talked about how > > we > > > wanted a codec that supported adaptive bit rates that could change > > on > > > the fly to be able to work well on an IP network. > > > > > > I will be working the folks to make sure the agenda has time to > > > directly address the key topics which include (more may be coming): > > > > > > Will we be able to get qualified people to do and review the work? > > > > > > Key design goals of a new codec? > > > > > > Do we need a new codec or are there already ones defined that meet > > the > > > needs? > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this > BOF. > > > > > > Thanks, > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Wed Jul 8 10:32:02 2009 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 1B6323A6C46 for ; Wed, 8 Jul 2009 10:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DHDeDBFlMYxQ for ; Wed, 8 Jul 2009 10:32:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C121B3A696B for ; Wed, 8 Jul 2009 10:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,369,1243814400"; d="scan'208";a="340013007" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2009 17:31:46 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n68HVktG025766; Wed, 8 Jul 2009 10:31:46 -0700 Received: from dhcp-171-68-21-101.cisco.com (dhcp-171-68-21-101.cisco.com [171.68.21.101]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n68HVk5h022106; Wed, 8 Jul 2009 17:31:46 GMT Message-Id: <9348B56A-DEAD-4F78-8C31-1C8D2EED019F@cisco.com> From: Cullen Jennings To: "Slava Borilin" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 10:31:49 -0700 References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com><945FAEF4-1515-4816-8A3A-9ED2475BA455@cisco.com> <4a447b45.06e2660a.7f72.7db8@mx.google.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6398; t=1247074306; x=1247938306; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[codec]=20Codec=20BOF=20approved,=20muc h=20work=20needed |Sender:=20; bh=bIyRs+dSduZzqx0YvtNXBT+2b3WlT04pLFdTAlp5PTs=; b=IJ9SIHUDJRpKBlyhjIVsjkkOLDk15U6N39eVeNFmZOsy9sGThxNVQxl27k j1Oo0LU98PyONDmyh0aJFKmBZcGeekfVvzSDbhbuf08nKe9zgkypWL+KbPzz 1BTR8O4jjC; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:32:02 -0000 I'm expecting some folks send a new version of the agenda out some time in the next few days or so that hopefully take into account the current comments. After that, more comments on the agenda can be collected and integrated into the agenda. Cullen On Jul 8, 2009, at 9:48 , Slava Borilin wrote: > Dear Roni, Cullen, > > Can you please advice on the procedure- there are some suggestions to > agenda made on this list- how this should translate into the final > agenda? > > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Friday, June 26, 2009 11:40 AM > To: 'Cullen Jennings' > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Cullen, > Thanks, > If I may, I would like to suggest based on my observations on the list > discussion that the agenda will also include the following topics. > > 1. Should the IETF work on codecs (speech/audio) > 2. If yes, should the these codecs be standard track or > informational. I > am > suggesting this item since as far as I understand after iLBC > publication > the > conclusion was that the IETF cannot do expert review on codecs even > for > Informational status. > > 3. If the IETF will do standard track, Is the prerequisite to qualify > for > approval is Royalty Free. The list discussion points that there is no > agreement that the IETF can provide with high probability a RF codec. > > > I think that only after these topics, which looks to me like ground > rules, > are addressed we can start discussing the content of the charter. > > Roni Even > > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, June 26, 2009 9:09 AM >> To: Ron Even >> Cc: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> >> Roni, >> >> The primary goal of this BOF should be collecting the information >> that >> helps make an informed decision about if a WG should be formed or >> not. >> I certainly did not mean to imply by the agenda that there was any >> assumption that a WG would be formed. >> >> I agree the charter below is far from ideal for collecting this >> information. I'm expecting the agenda to change, based on the list >> discussion, so we have time to talk about the key topics where >> community input is needed to drive the decisions about if a WG should >> be formed or not. >> >> Cullen >> >> >> On Jun 19, 2009, at 8:59 , Ron Even wrote: >> >>> Cullen, >>> I looked at the agenda >>> >>> 1. Administrative (Chairs, 5 min) >>> - Note takers, Jabber scribes >>> - Agenda bashing >>> >>> 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) >>> >>> 3. Proposed CODECs (TBD, 25 min) >>> - Expect to have two or more drafts here >>> >>> 4. Charter Discussion (All, 40 min) >>> >>> 5. Decisions and HUMs (All, 5 min) >>> >>> 6. Conclusions and Next Steps (Chairs/ADs, 5 min) >>> >>> >>> And it looks to me that it starts with assumption that we will have >>> a new working group. >>> >>> I am not sure that that this was agreed and yet I see no time >>> allocated to discuss the topic. I would expect that item 3 will be >>> rational for doing codec at the IETF considering that this work is >>> done also by other SDOs that the IETF is working with. >>> >>> Now even if there will be such a WG starting with proposed CODECS is >>> like having a solution before the requirements. In other standard >>> bodies requirements are not just names but they also have values. So >>> what is the purpose of proposing codecs, do we need to select at the >>> BOF which one will be standardize, to me it looks like this should >>> be done later. >>> >>> Roni Even >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>> Behalf >>>> Of Cullen Jennings >>>> Sent: Friday, June 12, 2009 8:32 PM >>>> To: codec@ietf.org >>>> Subject: [codec] Codec BOF approved, much work needed >>>> >>>> >>>> I have approved the CODEC BOF proposal. However, we need a bunch > of >>>> work to get ready. Various people on IESG/IAB were not > comfortable >>>> with the current charter and agenda so we need to work on theses >>>> before the meeting. >>>> >>>> A draft agenda/charter Jason provided are at >>>> >>>> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- >> bof/agenda.txt >>>> >>>> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>>> bof/charter.txt >>>> >>>> After discussion with the IESG/IAB: >>>> >>>> I'd like to remove the "as Proposed Standard" from the charter > text >>>> for both milestones and see how the discussion goes in the BOF >>> before >>>> deciding which way this should go. >>>> >>>> I'd like to see more consideration around the issues of designing > a >>>> codec that did a good job of mapping a real time stream onto IP >>>> packets. The way IP deals with packet loss and congestion has >>>> implications for designing a codec that works well over IP. I know >>>> some of the discussion I have had off list people talked about how >>> we >>>> wanted a codec that supported adaptive bit rates that could change >>> on >>>> the fly to be able to work well on an IP network. >>>> >>>> I will be working the folks to make sure the agenda has time to >>>> directly address the key topics which include (more may be > coming): >>>> >>>> Will we be able to get qualified people to do and review the work? >>>> >>>> Key design goals of a new codec? >>>> >>>> Do we need a new codec or are there already ones defined that meet >>> the >>>> needs? >>>> >>>> I have asked Jason Fischl and Jean-Marc Valin to co-chair this >> BOF. >>>> >>>> Thanks, >>>> >>>> Cullen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Wed Jul 8 10:44:46 2009 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 A75763A69DA for ; Wed, 8 Jul 2009 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.521 X-Spam-Level: * X-Spam-Status: No, score=1.521 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=1.81, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, SARE_RECV_BEZEQINT_B=0.763, SARE_SUB_ENC_WIN1255=0.647] 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 NdwGoUHQD5uV for ; Wed, 8 Jul 2009 10:44:46 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 7C2C33A69EB for ; Wed, 8 Jul 2009 10:44:45 -0700 (PDT) Received: by fxm18 with SMTP id 18so5850068fxm.37 for ; Wed, 08 Jul 2009 10:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=lbxZ7aVD0x8mloDQ4d5wHLoPKaj5341//LjJaumpo+I=; b=Fqjx29ErqRhUBUBB9nCBWNM2wZjjYCyxVnB4CK4hb4PX5BC/1PpXnLpsLIIbI0nose jdo8aH0UWKRgOgOSaRUCbrWZTMh+gsI8Fpczg1y2nWRw7SeoArgMCDv5FFbrQ1Mn6G0I NueFG0VxYzQhUYCeuhsqpExhUync6hWdVzVco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=kRjhNmB2AOhf0MJucstKe1hgSHppKKvGvNRqExoWAq2gCQ6/Tp7C1Y2j1wc4WaB7q/ 2/exZ+AgHgQXt8VlPgLM8U3ViRYg2/nGoN8gshWU3lg/9GVjfNj3h+zEWfTYXfSxAJDm 86SKkgs7ICKNaYITD3bcr6Jj5J/4O8c2lamjA= Received: by 10.103.160.9 with SMTP id m9mr4332346muo.53.1247075059114; Wed, 08 Jul 2009 10:44:19 -0700 (PDT) Received: from windows8d787f9 (bzq-82-81-43-179.red.bezeqint.net [82.81.43.179]) by mx.google.com with ESMTPS id j2sm47497912mue.12.2009.07.08.10.44.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 10:44:18 -0700 (PDT) From: "Roni Even" To: "'Slava Borilin'" , "'Cullen Jennings'" References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> <40525BF9-603F-4302-8ABD-623846857702@cisco.com> In-Reply-To: Date: Wed, 8 Jul 2009 20:44:16 +0300 Message-ID: <4a54daf2.02a1660a.3f9b.ffffe16d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2ESbweTxNTuzSQqS7FV+cXwTmXgJ2ORvQAAJEf/A= Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] =?windows-1255?q?RE=A0=3A_Codec_BOF_approved=2C_much_work?= =?windows-1255?q?_needed?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:44:46 -0000 Slava, As far as I understand TIA-921 is not addressing codec quality. It = addresses the transport and can give a model for packet loss.=20 The ITU cares for packet networks and design tests for testing the codec quality when packet loss occue=3Drs. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Slava Borilin > Sent: Wednesday, July 08, 2009 7:44 PM > To: Cullen Jennings > Cc: codec@ietf.org > Subject: Re: [codec] RE=A0: Codec BOF approved, much work needed >=20 > Cullen, >=20 > Sorry for delayed answer. >=20 > For codecs - most of ITU codecs are (were) not for IP networks, so I > believe they did not care at all and so there was no practice (only > G.718 may be the exception). >=20 > However, it is always some simulation for every network type (very > common is radio network with errors, for example, when it comes to > codecs to be used in the >=20 > TIA-921 is nowadays used by carriers when they do judge/accept the > overall VoIP systems, so it sounds as good candidate for judging the > codec as well. >=20 > Regards, > Slava Borilin >=20 >=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 7:50 AM > To: Slava Borilin > Cc: codec@ietf.org > Subject: Re: [codec] RE=A0: Codec BOF approved, much work needed >=20 >=20 > On Jun 18, 2009, at 6:56 , Slava Borilin wrote: >=20 > > For congested networks - I assume that the way to judge the codec is > > to judge the MOS over TIA-921 network profiles (that's what we use) > > which covers realistic packet loss and congestion scenarios, and not > > just "average normally distributed XX% packet loss". >=20 > Roni brought up and interesting point about looking at how other > groups doing codec design did the design and evaluation. Just out of > curiosity, are the TIA-921 profiles what folks doing codec design at > the ITU use as the basis of design for codecs to run over IP networks? >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Wed Jul 8 10:50:16 2009 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 6122F3A69D1 for ; Wed, 8 Jul 2009 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_KOI8R=0.67] 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 NTA3MhSSQK11 for ; Wed, 8 Jul 2009 10:50:15 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 3FC403A6B22 for ; Wed, 8 Jul 2009 10:50:15 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n68Hnr8E091639; Wed, 8 Jul 2009 21:49:54 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jul 2009 21:49:47 +0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4a54daf2.02a1660a.3f9b.ffffe16d@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?koi8-r?Q?=5Bcodec=5D=09RE=9A=3A_Codec_BOF_approved=2C_much_work_needed?= Thread-Index: Acn2ESbweTxNTuzSQqS7FV+cXwTmXgJ2ORvQAAJEf/AAADQsEA== References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> <40525BF9-603F-4302-8ABD-623846857702@cisco.com> <4a54daf2.02a1660a.3f9b.ffffe16d@mx.google.com> From: "Slava Borilin" To: "Roni Even" , "Cullen Jennings" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] =?koi8-r?b?UkWaOiBDb2RlYyBCT0YgYXBwcm92ZWQsIG11Y2ggd29y?= =?koi8-r?b?ayBuZWVkZWQ=?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:50:16 -0000 Roni, Sorry for possible confusion, and you are correct on TIA to be used as = model for packet loss. We have MOS, PESQMOS metrics for measuring the quality of the codec. My point however, was that such measurements should be done NOT on the = "pure" codec in the pure network, and, also, NOT in the fixed set of = "average distributed errors and losses", but the set of test cases = should be taken from TIA 921 model. We have seen a lot of codec comparison diagrams in the past which either = compared MOS at fixed and average distributed packet loss scenarios, = which I believe do not clearly reflect =D2=C5=D5 internet nature. So we need to create curves on how codec MOS are presented in all = TIA-921 network profiles. Slava -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Wednesday, July 08, 2009 9:44 PM To: Slava Borilin; 'Cullen Jennings' Cc: codec@ietf.org Subject: RE: [codec] RE=9A: Codec BOF approved, much work needed Slava, As far as I understand TIA-921 is not addressing codec quality. It = addresses the transport and can give a model for packet loss.=20 The ITU cares for packet networks and design tests for testing the codec quality when packet loss occue=3Drs. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Slava Borilin > Sent: Wednesday, July 08, 2009 7:44 PM > To: Cullen Jennings > Cc: codec@ietf.org > Subject: Re: [codec] RE=9A: Codec BOF approved, much work needed >=20 > Cullen, >=20 > Sorry for delayed answer. >=20 > For codecs - most of ITU codecs are (were) not for IP networks, so I > believe they did not care at all and so there was no practice (only > G.718 may be the exception). >=20 > However, it is always some simulation for every network type (very > common is radio network with errors, for example, when it comes to > codecs to be used in the >=20 > TIA-921 is nowadays used by carriers when they do judge/accept the > overall VoIP systems, so it sounds as good candidate for judging the > codec as well. >=20 > Regards, > Slava Borilin >=20 >=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 7:50 AM > To: Slava Borilin > Cc: codec@ietf.org > Subject: Re: [codec] RE=9A: Codec BOF approved, much work needed >=20 >=20 > On Jun 18, 2009, at 6:56 , Slava Borilin wrote: >=20 > > For congested networks - I assume that the way to judge the codec is > > to judge the MOS over TIA-921 network profiles (that's what we use) > > which covers realistic packet loss and congestion scenarios, and not > > just "average normally distributed XX% packet loss". >=20 > Roni brought up and interesting point about looking at how other > groups doing codec design did the design and evaluation. Just out of > curiosity, are the TIA-921 profiles what folks doing codec design at > the ITU use as the basis of design for codecs to run over IP networks? >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hsinnrei@adobe.com Wed Jul 8 11:41:29 2009 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 EB72B28C4A3 for ; Wed, 8 Jul 2009 11:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Hzn13PJF0G for ; Wed, 8 Jul 2009 11:41:27 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 3EDC028C4E8 for ; Wed, 8 Jul 2009 11:41:27 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSlTocAQ4Q5pv9JZPX1yLvCgfs1fMgBwk@postini.com; Wed, 08 Jul 2009 11:41:54 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n68IZUao020761; Wed, 8 Jul 2009 11:35:30 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n68Ifpiq012039; Wed, 8 Jul 2009 11:41:51 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 8 Jul 2009 11:41:51 -0700 From: Henry Sinnreich To: Roni Even , Cullen Jennings Date: Wed, 8 Jul 2009 11:41:51 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQAm8jFQAAAxt3qg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C67A4CB449C9hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:41:30 -0000 --_000_C67A4CB449C9hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni, It is now really hard to count how many times you have repeated these argum= ents. Henry -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, June 26, 2009 11:40 AM To: 'Cullen Jennings' Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Cullen, Thanks, If I may, I would like to suggest based on my observations on the list discussion that the agenda will also include the following topics. 1. Should the IETF work on codecs (speech/audio) 2. If yes, should the these codecs be standard track or informational. I am suggesting this item since as far as I understand after iLBC publication the conclusion was that the IETF cannot do expert review on codecs even for Informational status. 3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no agreement that the IETF can provide with high probability a RF codec. I think that only after these topics, which looks to me like ground rules, are addressed we can start discussing the content of the charter. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 9:09 AM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > > Roni, > > The primary goal of this BOF should be collecting the information that > helps make an informed decision about if a WG should be formed or not. > I certainly did not mean to imply by the agenda that there was any > assumption that a WG would be formed. > > I agree the charter below is far from ideal for collecting this > information. I'm expecting the agenda to change, based on the list > discussion, so we have time to talk about the key topics where > community input is needed to drive the decisions about if a WG should > be formed or not. > > Cullen > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > Cullen, > > I looked at the agenda > > > > 1. Administrative (Chairs, 5 min) > > - Note takers, Jabber scribes > > - Agenda bashing > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > 3. Proposed CODECs (TBD, 25 min) > > - Expect to have two or more drafts here > > > > 4. Charter Discussion (All, 40 min) > > > > 5. Decisions and HUMs (All, 5 min) > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > And it looks to me that it starts with assumption that we will have > > a new working group. > > > > I am not sure that that this was agreed and yet I see no time > > allocated to discuss the topic. I would expect that item 3 will be > > rational for doing codec at the IETF considering that this work is > > done also by other SDOs that the IETF is working with. > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should > > be done later. > > > > Roni Even > > > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > Of Cullen Jennings > > > Sent: Friday, June 12, 2009 8:32 PM > > > To: codec@ietf.org > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > > work to get ready. Various people on IESG/IAB were not comfortable > > > with the current charter and agenda so we need to work on theses > > > before the meeting. > > > > > > A draft agenda/charter Jason provided are at > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > bof/charter.txt > > > > > > After discussion with the IESG/IAB: > > > > > > I'd like to remove the "as Proposed Standard" from the charter text > > > for both milestones and see how the discussion goes in the BOF > > before > > > deciding which way this should go. > > > > > > I'd like to see more consideration around the issues of designing a > > > codec that did a good job of mapping a real time stream onto IP > > > packets. The way IP deals with packet loss and congestion has > > > implications for designing a codec that works well over IP. I know > > > some of the discussion I have had off list people talked about how > > we > > > wanted a codec that supported adaptive bit rates that could change > > on > > > the fly to be able to work well on an IP network. > > > > > > I will be working the folks to make sure the agenda has time to > > > directly address the key topics which include (more may be coming): > > > > > > Will we be able to get qualified people to do and review the work? > > > > > > Key design goals of a new codec? > > > > > > Do we need a new codec or are there already ones defined that meet > > the > > > needs? > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this > BOF. > > > > > > Thanks, > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ 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 --_000_C67A4CB449C9hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed
Roni,

It is now really hard to count how many times you have repeated these argum= ents.

Henry


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf
Of Roni Even
Sent: Friday, June 26, 2009 11:40 AM
To: 'Cullen Jennings'
Cc: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am
suggesting this item since as far as I understand after iLBC publication the
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify
for
approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.


I think that only after these topics, which looks to me like ground
rules,
are addressed we can start discussing the content of the charter.

Roni Even



> -----Original Message-----
> From: Cullen Jennings [mailto:fluf= fy@cisco.com]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Codec BOF approved, much work needed
>
>
> Roni,
>
> The primary goal of this BOF should be collecting the information that=
> helps make an informed decision about if a WG should be formed or not.=
> I certainly did not mean to imply by the agenda that there was any
> assumption that a WG would be formed.
>
> I agree the charter below is far from ideal for collecting this
> information. I'm expecting the agenda to change, based on the list
> discussion, so we have time to talk about the key topics where
> community input is needed to drive the decisions about if a WG should<= BR> > be formed or not.
>
> Cullen <RAI AD>
>
>
> On Jun 19, 2009, at 8:59 , Ron Even wrote:
>
> > Cullen,
> > I looked at the agenda
> >
> > 1. Administrative (Chairs, 5 min)
> >   - Note takers, Jabber scribes
> >   - Agenda bashing
> >
> > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
> >
> > 3. Proposed CODECs (TBD, 25 min)
> >   - Expect to have two or more drafts here
> >
> > 4. Charter Discussion (All, 40 min)
> >
> > 5. Decisions and HUMs (All, 5 min)
> >
> > 6. Conclusions and Next Steps (Chairs/ADs, 5 min)
> >
> >
> > And it looks to me that it starts with assumption that we will ha= ve
> > a new working group.
> >
> > I am not sure that that this was agreed and yet I see no time
> > allocated to discuss the topic. I would expect that item 3 will b= e
> > rational for doing codec at the IETF considering that this work i= s
> > done also by other SDOs that the IETF is working with.
> >
> > Now even if there will be such a WG starting with proposed CODECS= is
> > like having a solution before the requirements. In other standard=
> > bodies requirements are not just names but they also have values.= So
> > what is the purpose of proposing codecs, do we need to select at = the
> > BOF which one will be standardize, to me it looks like this shoul= d
> > be done later.
> >
> > Roni Even
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: codec-bounces@ietf.= org [mailto:codec-bounces@iet= f.org] On
> > Behalf
> > > Of Cullen Jennings
> > > Sent: Friday, June 12, 2009 8:32 PM
> > > To: codec@ietf.org
> > > Subject: [codec] Codec BOF approved, much work needed
> > >
> > >
> > > I have approved the CODEC BOF proposal. However, we need a b= unch
of
> > > work to get ready.  Various people on IESG/IAB were not=
comfortable
> > > with the current charter and agenda so we need to work on th= eses
> > > before the meeting.
> > >
> > > A draft agenda/charter Jason provided are at
> > >
> > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/agenda.txt
> > >
> > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> > > bof/charter.txt
> > >
> > > After discussion with the IESG/IAB:
> > >
> > > I'd like to remove the "as Proposed Standard" from= the charter
text
> > > for both milestones and see how the discussion goes in the B= OF
> > before
> > > deciding which way this should go.
> > >
> > > I'd like to see more consideration around the issues of desi= gning
a
> > > codec that did a good job of mapping a real time stream onto= IP
> > > packets. The way IP deals with packet loss and congestion ha= s
> > > implications for designing a codec that works well over IP. = I know
> > > some of the discussion I have had off list people talked abo= ut how
> > we
> > > wanted a codec that supported adaptive bit rates that could = change
> > on
> > > the fly to be able to work well on an IP network.
> > >
> > > I will be working the folks to make sure the agenda has time= to
> > > directly address the key topics which include (more may be coming):
> > >
> > > Will we be able to get qualified people to do and review the= work?
> > >
> > > Key design goals of a new codec?
> > >
> > > Do we need a new codec or are there already ones defined tha= t meet
> > the
> > > needs?
> > >
> > > I have asked Jason Fischl  and Jean-Marc Valin to co-ch= air this
> BOF.
> > >
> > > Thanks,
> > >
> > > Cullen <RAI AD>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > codec mailing list
> > > codec@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/codec
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C67A4CB449C9hsinnreiadobecom_-- From stewe@stewe.org Wed Jul 8 11:56:33 2009 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 49DDE3A6882 for ; Wed, 8 Jul 2009 11:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 79ki0kCfz435 for ; Wed, 8 Jul 2009 11:56:28 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5D0F03A6774 for ; Wed, 8 Jul 2009 11:56:27 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 331434-1743317 for multiple; Wed, 08 Jul 2009 20:56:54 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 08 Jul 2009 11:56:25 -0700 From: Stephan Wenger To: Henry Sinnreich , Roni Even , Cullen Jennings Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQAm8jFQAAAxt3qgABY/1G In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3329899012_403433" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:56:33 -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_3329899012_403433 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, I agree with Roni=B9s suggestions and arguments. We can cease repeating them if the BOF agenda adequately addresses them. As of this minute, it doesn=B9t= . Regards, Stephan On 7/8/09 11:41 AM, "Henry Sinnreich" wrote: >> Roni, >>=20 >> It is now really hard to count how many times you have repeated these >> arguments. >>=20 >> Henry=20 >>=20 >>=20 >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Roni Even >> Sent: Friday, June 26, 2009 11:40 AM >> To: 'Cullen Jennings' >> Cc: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >>=20 >> Cullen, >> Thanks, >> If I may, I would like to suggest based on my observations on the list >> discussion that the agenda will also include the following topics. >>=20 >> 1. Should the IETF work on codecs (speech/audio) >> 2. If yes, should the these codecs be standard track or informational. I >> am >> suggesting this item since as far as I understand after iLBC publication >> the >> conclusion was that the IETF cannot do expert review on codecs even for >> Informational status. >>=20 >> 3. If the IETF will do standard track, Is the prerequisite to qualify >> for >> approval is Royalty Free. The list discussion points that there is no >> agreement that the IETF can provide with high probability a RF codec. >>=20 >>=20 >> I think that only after these topics, which looks to me like ground >> rules, >> are addressed we can start discussing the content of the charter. >>=20 >> Roni Even >>=20 >>=20 >>=20 >>> > -----Original Message----- >>> > From: Cullen Jennings [mailto:fluffy@cisco.com] >>> > Sent: Friday, June 26, 2009 9:09 AM >>> > To: Ron Even >>> > Cc: codec@ietf.org >>> > Subject: Re: [codec] Codec BOF approved, much work needed >>> > >>> > >>> > Roni, >>> > >>> > The primary goal of this BOF should be collecting the information tha= t >>> > helps make an informed decision about if a WG should be formed or not= . >>> > I certainly did not mean to imply by the agenda that there was any >>> > assumption that a WG would be formed. >>> > >>> > I agree the charter below is far from ideal for collecting this >>> > information. I'm expecting the agenda to change, based on the list >>> > discussion, so we have time to talk about the key topics where >>> > community input is needed to drive the decisions about if a WG should >>> > be formed or not. >>> > >>> > Cullen >>> > >>> > >>> > On Jun 19, 2009, at 8:59 , Ron Even wrote: >>> > >>>> > > Cullen, >>>> > > I looked at the agenda >>>> > > >>>> > > 1. Administrative (Chairs, 5 min) >>>> > > - Note takers, Jabber scribes >>>> > > - Agenda bashing >>>> > > >>>> > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) >>>> > > >>>> > > 3. Proposed CODECs (TBD, 25 min) >>>> > > - Expect to have two or more drafts here >>>> > > >>>> > > 4. Charter Discussion (All, 40 min) >>>> > > >>>> > > 5. Decisions and HUMs (All, 5 min) >>>> > > >>>> > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) >>>> > > >>>> > > >>>> > > And it looks to me that it starts with assumption that we will hav= e >>>> > > a new working group. >>>> > > >>>> > > I am not sure that that this was agreed and yet I see no time >>>> > > allocated to discuss the topic. I would expect that item 3 will be >>>> > > rational for doing codec at the IETF considering that this work is >>>> > > done also by other SDOs that the IETF is working with. >>>> > > >>>> > > Now even if there will be such a WG starting with proposed CODECS = is >>>> > > like having a solution before the requirements. In other standard >>>> > > bodies requirements are not just names but they also have values. = So >>>> > > what is the purpose of proposing codecs, do we need to select at t= he >>>> > > BOF which one will be standardize, to me it looks like this should >>>> > > be done later. >>>> > > >>>> > > Roni Even >>>> > > >>>> > > >>>> > > >>>> > > >>>>> > > > -----Original Message----- >>>>> > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>>> > > Behalf >>>>> > > > Of Cullen Jennings >>>>> > > > Sent: Friday, June 12, 2009 8:32 PM >>>>> > > > To: codec@ietf.org >>>>> > > > Subject: [codec] Codec BOF approved, much work needed >>>>> > > > >>>>> > > > >>>>> > > > I have approved the CODEC BOF proposal. However, we need a bunc= h >> of >>>>> > > > work to get ready. Various people on IESG/IAB were not >> comfortable >>>>> > > > with the current charter and agenda so we need to work on these= s >>>>> > > > before the meeting. >>>>> > > > >>>>> > > > A draft agenda/charter Jason provided are at >>>>> > > > >>>>> > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>> > bof/agenda.txt >>>>> > > > >>>>> > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>>>> > > > bof/charter.txt >>>>> > > > >>>>> > > > After discussion with the IESG/IAB: >>>>> > > > >>>>> > > > I'd like to remove the "as Proposed Standard" from the charter >> text >>>>> > > > for both milestones and see how the discussion goes in the BOF >>>> > > before >>>>> > > > deciding which way this should go. >>>>> > > > >>>>> > > > I'd like to see more consideration around the issues of designi= ng >> a >>>>> > > > codec that did a good job of mapping a real time stream onto IP >>>>> > > > packets. The way IP deals with packet loss and congestion has >>>>> > > > implications for designing a codec that works well over IP. I k= now >>>>> > > > some of the discussion I have had off list people talked about = how >>>> > > we >>>>> > > > wanted a codec that supported adaptive bit rates that could cha= nge >>>> > > on >>>>> > > > the fly to be able to work well on an IP network. >>>>> > > > >>>>> > > > I will be working the folks to make sure the agenda has time to >>>>> > > > directly address the key topics which include (more may be >> coming): >>>>> > > > >>>>> > > > Will we be able to get qualified people to do and review the wo= rk? >>>>> > > > >>>>> > > > Key design goals of a new codec? >>>>> > > > >>>>> > > > Do we need a new codec or are there already ones defined that m= eet >>>> > > the >>>>> > > > needs? >>>>> > > > >>>>> > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this >>> > BOF. >>>>> > > > >>>>> > > > Thanks, >>>>> > > > >>>>> > > > Cullen >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > _______________________________________________ >>>>> > > > 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 >>=20 >> _______________________________________________ >> 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 >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3329899012_403433 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Hi Henry,
I agree with Roni’s suggestions and arguments.  We can cease rep= eating them if the BOF agenda adequately addresses them.  As of this mi= nute, it doesn’t.
Regards,
Stephan



On 7/8/09 11:41 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

Roni,

It is now really hard to count how many times you have repeated these argum= ents.

Henry


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf=
Of Roni Even
Sent: Friday, June 26, 2009 11:40 AM
To: 'Cullen Jennings'
Cc: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am
suggesting this item since as far as I understand after iLBC publication the
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify
for
approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.


I think that only after these topics, which looks to me like ground
rules,
are addressed we can start discussing the content of the charter.

Roni Even



> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy= @cisco.com]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Codec BOF approved, much work needed
>
>
> Roni,
>
> The primary goal of this BOF should be collecting the information that=
> helps make an informed decision about if a WG should be formed or not.=
> I certainly did not mean to imply by the agenda that there was any
> assumption that a WG would be formed.
>
> I agree the charter below is far from ideal for collecting this
> information. I'm expecting the agenda to change, based on the list
> discussion, so we have time to talk about the key topics where
> community input is needed to drive the decisions about if a WG should<= BR> > be formed or not.
>
> Cullen <RAI AD>
>
>
> On Jun 19, 2009, at 8:59 , Ron Even wrote:
>
> > Cullen,
> > I looked at the agenda
> >
> > 1. Administrative (Chairs, 5 min)
> >   - Note takers, Jabber scribes
> >   - Agenda bashing
> >
> > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
> >
> > 3. Proposed CODECs (TBD, 25 min)
> >   - Expect to have two or more drafts here
> >
> > 4. Charter Discussion (All, 40 min)
> >
> > 5. Decisions and HUMs (All, 5 min)
> >
> > 6. Conclusions and Next Steps (Chairs/ADs, 5 min)
> >
> >
> > And it looks to me that it starts with assumption that we will ha= ve
> > a new working group.
> >
> > I am not sure that that this was agreed and yet I see no time
> > allocated to discuss the topic. I would expect that item 3 will b= e
> > rational for doing codec at the IETF considering that this work i= s
> > done also by other SDOs that the IETF is working with.
> >
> > Now even if there will be such a WG starting with proposed CODECS= is
> > like having a solution before the requirements. In other standard=
> > bodies requirements are not just names but they also have values.= So
> > what is the purpose of proposing codecs, do we need to select at = the
> > BOF which one will be standardize, to me it looks like this shoul= d
> > be done later.
> >
> > Roni Even
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: codec-bounces@ietf.or= g [mailto:codec-bounces@ietf.org= ] On
> > Behalf
> > > Of Cullen Jennings
> > > Sent: Friday, June 12, 2009 8:32 PM
> > > To: codec@ietf.org
> > > Subject: [codec] Codec BOF approved, much work needed
> > >
> > >
> > > I have approved the CODEC BOF proposal. However, we need a b= unch
of
> > > work to get ready.  Various people on IESG/IAB were not=
comfortable
> > > with the current charter and agenda so we need to work on th= eses
> > > before the meeting.
> > >
> > > A draft agenda/charter Jason provided are at
> > >
> > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/agenda.txt
> > >
> > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> > > bof/charter.txt
> > >
> > > After discussion with the IESG/IAB:
> > >
> > > I'd like to remove the "as Proposed Standard" from= the charter
text
> > > for both milestones and see how the discussion goes in the B= OF
> > before
> > > deciding which way this should go.
> > >
> > > I'd like to see more consideration around the issues of desi= gning
a
> > > codec that did a good job of mapping a real time stream onto= IP
> > > packets. The way IP deals with packet loss and congestion ha= s
> > > implications for designing a codec that works well over IP. = I know
> > > some of the discussion I have had off list people talked abo= ut how
> > we
> > > wanted a codec that supported adaptive bit rates that could = change
> > on
> > > the fly to be able to work well on an IP network.
> > >
> > > I will be working the folks to make sure the agenda has time= to
> > > directly address the key topics which include (more may be coming):
> > >
> > > Will we be able to get qualified people to do and review the= work?
> > >
> > > Key design goals of a new codec?
> > >
> > > Do we need a new codec or are there already ones defined tha= t meet
> > the
> > > needs?
> > >
> > > I have asked Jason Fischl  and Jean-Marc Valin to co-ch= air this
> BOF.
> > >
> > > Thanks,
> > >
> > > Cullen <RAI AD>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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

_______________________________________________
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


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3329899012_403433-- From jean-marc.valin@octasic.com Wed Jul 8 11:59:25 2009 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 B46E73A6B7A for ; Wed, 8 Jul 2009 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 tGjgNNE8TFbY for ; Wed, 8 Jul 2009 11:59:24 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 0FB9A3A6ACE for ; Wed, 8 Jul 2009 11:59:11 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:59:38 -0400 Message-ID: <4A54ED14.8080507@octasic.com> Date: Wed, 08 Jul 2009 15:01:40 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jul 2009 18:59:38.0829 (UTC) FILETIME=[3E4587D0:01C9FFFE] Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:59:25 -0000 Stephan Wenger wrote: > Hi Henry, > I agree with Roni’s suggestions and arguments. We can cease repeating > them if the BOF agenda adequately addresses them. As of this minute, it > doesn’t. The agenda that's available is pretty old. There should be an updated one soon that should (hopefully!) address everyone's concerns. Jean-Marc > Regards, > Stephan > > > > On 7/8/09 11:41 AM, "Henry Sinnreich" wrote: > > Roni, > > It is now really hard to count how many times you have repeated > these arguments. > > Henry > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf > Of Roni Even > Sent: Friday, June 26, 2009 11:40 AM > To: 'Cullen Jennings' > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Cullen, > Thanks, > If I may, I would like to suggest based on my observations on > the list > discussion that the agenda will also include the following topics. > > 1. Should the IETF work on codecs (speech/audio) > 2. If yes, should the these codecs be standard track or > informational. I > am > suggesting this item since as far as I understand after iLBC > publication > the > conclusion was that the IETF cannot do expert review on codecs > even for > Informational status. > > 3. If the IETF will do standard track, Is the prerequisite to > qualify > for > approval is Royalty Free. The list discussion points that there > is no > agreement that the IETF can provide with high probability a RF > codec. > > > I think that only after these topics, which looks to me like ground > rules, > are addressed we can start discussing the content of the charter. > > Roni Even > > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Friday, June 26, 2009 9:09 AM > > To: Ron Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > Roni, > > > > The primary goal of this BOF should be collecting the > information that > > helps make an informed decision about if a WG should be formed > or not. > > I certainly did not mean to imply by the agenda that there was any > > assumption that a WG would be formed. > > > > I agree the charter below is far from ideal for collecting this > > information. I'm expecting the agenda to change, based on the list > > discussion, so we have time to talk about the key topics where > > community input is needed to drive the decisions about if a WG > should > > be formed or not. > > > > Cullen > > > > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > > > Cullen, > > > I looked at the agenda > > > > > > 1. Administrative (Chairs, 5 min) > > > - Note takers, Jabber scribes > > > - Agenda bashing > > > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > > > 3. Proposed CODECs (TBD, 25 min) > > > - Expect to have two or more drafts here > > > > > > 4. Charter Discussion (All, 40 min) > > > > > > 5. Decisions and HUMs (All, 5 min) > > > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > > > > And it looks to me that it starts with assumption that we > will have > > > a new working group. > > > > > > I am not sure that that this was agreed and yet I see no time > > > allocated to discuss the topic. I would expect that item 3 > will be > > > rational for doing codec at the IETF considering that this > work is > > > done also by other SDOs that the IETF is working with. > > > > > > Now even if there will be such a WG starting with proposed > CODECS is > > > like having a solution before the requirements. In other > standard > > > bodies requirements are not just names but they also have > values. So > > > what is the purpose of proposing codecs, do we need to > select at the > > > BOF which one will be standardize, to me it looks like this > should > > > be done later. > > > > > > Roni Even > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On > > > Behalf > > > > Of Cullen Jennings > > > > Sent: Friday, June 12, 2009 8:32 PM > > > > To: codec@ietf.org > > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a > bunch > of > > > > work to get ready. Various people on IESG/IAB were not > comfortable > > > > with the current charter and agenda so we need to work on > theses > > > > before the meeting. > > > > > > > > A draft agenda/charter Jason provided are at > > > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > bof/agenda.txt > > > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > > bof/charter.txt > > > > > > > > After discussion with the IESG/IAB: > > > > > > > > I'd like to remove the "as Proposed Standard" from the charter > text > > > > for both milestones and see how the discussion goes in the BOF > > > before > > > > deciding which way this should go. > > > > > > > > I'd like to see more consideration around the issues of > designing > a > > > > codec that did a good job of mapping a real time stream > onto IP > > > > packets. The way IP deals with packet loss and congestion has > > > > implications for designing a codec that works well over > IP. I know > > > > some of the discussion I have had off list people talked > about how > > > we > > > > wanted a codec that supported adaptive bit rates that > could change > > > on > > > > the fly to be able to work well on an IP network. > > > > > > > > I will be working the folks to make sure the agenda has > time to > > > > directly address the key topics which include (more may be > coming): > > > > > > > > Will we be able to get qualified people to do and review > the work? > > > > > > > > Key design goals of a new codec? > > > > > > > > Do we need a new codec or are there already ones defined > that meet > > > the > > > > needs? > > > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair > this > > BOF. > > > > > > > > Thanks, > > > > > > > > Cullen > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > _______________________________________________ > 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 stewe@stewe.org Wed Jul 8 12:08:40 2009 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 4131728C22A for ; Wed, 8 Jul 2009 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 YTgbEO+xnNLg for ; Wed, 8 Jul 2009 12:08:39 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 2AD533A68D4 for ; Wed, 8 Jul 2009 12:08:35 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 331463-1743317 for multiple; Wed, 08 Jul 2009 21:09:01 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 08 Jul 2009 12:08:52 -0700 From: Stephan Wenger To: Jean-Marc Valin Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn//4f8K5LWgdlGwk6nFagNVcx1Qg== In-Reply-To: <4A54ED14.8080507@octasic.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 19:08:40 -0000 Who is handling this? Do we have BOF chairs by now? Stephan On 7/8/09 12:01 PM, "Jean-Marc Valin" wrote: > Stephan Wenger wrote: >> Hi Henry, >> I agree with Roni=B9s suggestions and arguments. We can cease repeating >> them if the BOF agenda adequately addresses them. As of this minute, it >> doesn=B9t. >=20 > The agenda that's available is pretty old. There should be an updated one > soon that should (hopefully!) address everyone's concerns. >=20 > Jean-Marc >=20 >=20 >> Regards, >> Stephan >>=20 >>=20 >>=20 >> On 7/8/09 11:41 AM, "Henry Sinnreich" wrote: >>=20 >> Roni, >>=20 >> It is now really hard to count how many times you have repeated >> these arguments. >>=20 >> Henry >>=20 >>=20 >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf >> Of Roni Even >> Sent: Friday, June 26, 2009 11:40 AM >> To: 'Cullen Jennings' >> Cc: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >>=20 >> Cullen, >> Thanks, >> If I may, I would like to suggest based on my observations on >> the list >> discussion that the agenda will also include the following topic= s. >>=20 >> 1. Should the IETF work on codecs (speech/audio) >> 2. If yes, should the these codecs be standard track or >> informational. I >> am >> suggesting this item since as far as I understand after iLBC >> publication >> the >> conclusion was that the IETF cannot do expert review on codecs >> even for >> Informational status. >>=20 >> 3. If the IETF will do standard track, Is the prerequisite to >> qualify >> for >> approval is Royalty Free. The list discussion points that there >> is no >> agreement that the IETF can provide with high probability a RF >> codec. >>=20 >>=20 >> I think that only after these topics, which looks to me like gro= und >> rules, >> are addressed we can start discussing the content of the charter= . >>=20 >> Roni Even >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: Friday, June 26, 2009 9:09 AM >>> To: Ron Even >>> Cc: codec@ietf.org >>> Subject: Re: [codec] Codec BOF approved, much work needed >>>=20 >>>=20 >>> Roni, >>>=20 >>> The primary goal of this BOF should be collecting the >> information that >>> helps make an informed decision about if a WG should be formed >> or not. >>> I certainly did not mean to imply by the agenda that there was any >>> assumption that a WG would be formed. >>>=20 >>> I agree the charter below is far from ideal for collecting this >>> information. I'm expecting the agenda to change, based on the list >>> discussion, so we have time to talk about the key topics where >>> community input is needed to drive the decisions about if a WG >> should >>> be formed or not. >>>=20 >>> Cullen >>>=20 >>>=20 >>> On Jun 19, 2009, at 8:59 , Ron Even wrote: >>>=20 >>>> Cullen, >>>> I looked at the agenda >>>>=20 >>>> 1. Administrative (Chairs, 5 min) >>>> - Note takers, Jabber scribes >>>> - Agenda bashing >>>>=20 >>>> 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) >>>>=20 >>>> 3. Proposed CODECs (TBD, 25 min) >>>> - Expect to have two or more drafts here >>>>=20 >>>> 4. Charter Discussion (All, 40 min) >>>>=20 >>>> 5. Decisions and HUMs (All, 5 min) >>>>=20 >>>> 6. Conclusions and Next Steps (Chairs/ADs, 5 min) >>>>=20 >>>>=20 >>>> And it looks to me that it starts with assumption that we >> will have >>>> a new working group. >>>>=20 >>>> I am not sure that that this was agreed and yet I see no time >>>> allocated to discuss the topic. I would expect that item 3 >> will be >>>> rational for doing codec at the IETF considering that this >> work is >>>> done also by other SDOs that the IETF is working with. >>>>=20 >>>> Now even if there will be such a WG starting with proposed >> CODECS is >>>> like having a solution before the requirements. In other >> standard >>>> bodies requirements are not just names but they also have >> values. So >>>> what is the purpose of proposing codecs, do we need to >> select at the >>>> BOF which one will be standardize, to me it looks like this >> should >>>> be done later. >>>>=20 >>>> Roni Even >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: codec-bounces@ietf.org >> [mailto:codec-bounces@ietf.org] On >>>> Behalf >>>>> Of Cullen Jennings >>>>> Sent: Friday, June 12, 2009 8:32 PM >>>>> To: codec@ietf.org >>>>> Subject: [codec] Codec BOF approved, much work needed >>>>>=20 >>>>>=20 >>>>> I have approved the CODEC BOF proposal. However, we need a >> bunch >> of >>>>> work to get ready. Various people on IESG/IAB were not >> comfortable >>>>> with the current charter and agenda so we need to work on >> theses >>>>> before the meeting. >>>>>=20 >>>>> A draft agenda/charter Jason provided are at >>>>>=20 >>>>> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>> bof/agenda.txt >>>>>=20 >>>>> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>>>> bof/charter.txt >>>>>=20 >>>>> After discussion with the IESG/IAB: >>>>>=20 >>>>> I'd like to remove the "as Proposed Standard" from the charter >> text >>>>> for both milestones and see how the discussion goes in the BOF >>>> before >>>>> deciding which way this should go. >>>>>=20 >>>>> I'd like to see more consideration around the issues of >> designing >> a >>>>> codec that did a good job of mapping a real time stream >> onto IP >>>>> packets. The way IP deals with packet loss and congestion has >>>>> implications for designing a codec that works well over >> IP. I know >>>>> some of the discussion I have had off list people talked >> about how >>>> we >>>>> wanted a codec that supported adaptive bit rates that >> could change >>>> on >>>>> the fly to be able to work well on an IP network. >>>>>=20 >>>>> I will be working the folks to make sure the agenda has >> time to >>>>> directly address the key topics which include (more may be >> coming): >>>>>=20 >>>>> Will we be able to get qualified people to do and review >> the work? >>>>>=20 >>>>> Key design goals of a new codec? >>>>>=20 >>>>> Do we need a new codec or are there already ones defined >> that meet >>>> the >>>>> needs? >>>>>=20 >>>>> I have asked Jason Fischl and Jean-Marc Valin to co-chair >> this >>> BOF. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Cullen >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>=20 >> _______________________________________________ >> 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 >>=20 >>=20 >> --------------------------------------------------------------------= ---- >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >=20 From fluffy@cisco.com Wed Jul 8 12:46:34 2009 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 989FB3A684B for ; Wed, 8 Jul 2009 12:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 LEa-mgRQ828G for ; Wed, 8 Jul 2009 12:46:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C42093A6B79 for ; Wed, 8 Jul 2009 12:46:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,370,1243814400"; d="scan'208";a="184101033" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2009 19:46:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n68JkMB8031465; Wed, 8 Jul 2009 12:46:22 -0700 Received: from dhcp-171-68-21-101.cisco.com (dhcp-171-68-21-101.cisco.com [171.68.21.101]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n68JkMDm022552; Wed, 8 Jul 2009 19:46:22 GMT Message-Id: <2D9116E9-057D-47CF-A0B1-FC19DDBB4F3A@cisco.com> From: Cullen Jennings To: Stephan Wenger In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 12:46:26 -0700 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=240; t=1247082382; x=1247946382; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[codec]=20Codec=20BOF=20approved,=20muc h=20work=20needed |Sender:=20; bh=yFSrtDxWDIu+E09ALY2F0kDLMDSsU7MNbRS5uwiryfg=; b=h5EnQn5o6x+IUpMkC94ZOTN3GtmQbw2KWW96/c3B84JmWghxS/yQ1utwQq gVrO/OE1FG74IFrk7j8qYY7VTOYhhhfGy8YGwkG/vLSIK2hYj6crsZeYO37j jtlH/BHMYgefecPloifrgmPDeNsqJTqihVNdUcGdQ6krTB8CU5hp4=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 19:46:34 -0000 On Jul 8, 2009, at 12:08 , Stephan Wenger wrote: > Who is handling this? Do we have BOF chairs by now? Yes, Jason Fischl and Jean-Marc Valin. That should be in the email that started this thread - hope it made it to the list. From jason.fischl@skype.net Wed Jul 8 13:43:08 2009 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 CE9CF3A6FA9 for ; Wed, 8 Jul 2009 13:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=2.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 6hd04y5um7IV for ; Wed, 8 Jul 2009 13:43:08 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 05CC43A6FA8 for ; Wed, 8 Jul 2009 13:43:07 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.42,370,1243839600"; d="scan'208";a="52693272" Received: from unknown (HELO den-exb-01.corp.ebay.com) ([10.101.44.9]) by den-mipot-002.corp.ebay.com with ESMTP; 08 Jul 2009 13:43:28 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by den-exb-01.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:43:26 -0600 Received: from 69.181.180.22 ([69.181.180.22]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.25]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Jul 2009 20:43:27 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 08 Jul 2009 13:43:27 -0700 From: Jason Fischl To: Message-ID: Thread-Topic: Updated Agenda for Codec BOF Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZg== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2009 20:43:26.0801 (UTC) FILETIME=[BE6EA410:01CA000C] Subject: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:43:08 -0000 Based on the comments from the mailing list, Jean-Marc and I are proposing = a new agenda. Please let me know if we've missed any important topics. Regards Jason and Jean-Marc. AGENDA: 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Introduction and Scoping of BOF (Chairs/ADs, 10 min) 3. What do users want? Goals of the working group. What would success look like? (15 min) - What is special about an Internet codec 4. What type of engineering work would this be? ( 25 min ) Have presentations on the two proposed codecs. Focus is to make sure it looks feasible to do the technical =A0 work to meet the goals. This should also help clarify what type of work is being considered. - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt 5. Do we have the expertise to specify and review Internet-specific codecs? (15 min) 6. Is this work likely to succeed or fail? Reasons it would fail? (15 min) - Discussion of odds of success of royalty free 7. HUM on if the IETF should form this WG (All, 15 min) 8. Charter Discussion [Time permitting] (All, 15 min) 9. Conclusions and Next Steps (Chairs/ADs, 5 min) From fluffy@cisco.com Wed Jul 8 13:48:37 2009 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 EDE713A6FA8 for ; Wed, 8 Jul 2009 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 6NDeneh3pEp5 for ; Wed, 8 Jul 2009 13:48:37 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 448223A696B for ; Wed, 8 Jul 2009 13:48:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,370,1243814400"; d="scan'208";a="175529995" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2009 20:49:04 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n68Kn4HA019455 for ; Wed, 8 Jul 2009 13:49:04 -0700 Received: from dhcp-171-68-21-101.cisco.com (dhcp-171-68-21-101.cisco.com [171.68.21.101]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n68Kn4AI028115 for ; Wed, 8 Jul 2009 20:49:04 GMT Message-Id: From: Cullen Jennings To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 13:49:08 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=757; t=1247086144; x=1247950144; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Purpose=20of=20the=20CODEC=20BOF |Sender:=20; bh=VrNN3UJppPEzYzGvmJIL+nDo8rKMfXO7BPYGLNtYbnk=; b=f16heZvzBUzFJ+0Q3hF5OC+kanvCsJTSGkI6ofEWByjL7J5gqGlPGAhaHp AOD3IRFsTJjbkgdEP6TJOLqIW5mAG/0cqG+pfGhc2vQnAxVM7YJv3IyNUjJK +wHHgN9Kbp; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [codec] Purpose of the CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:48:38 -0000 Now that the new agenda is out, few comments on email threads so far ... BOFs get run for lots of reasons but the primary purpose of this BOF is to get input to help answer the question of if the IETF should form a WG to do this work or not. I hope the agenda provides time to talk about the important issues for making this decision. I expect many of the arguments made on the list (and repeated on the list) to be repeated again in the BOF. This is needed so that a broad range of people participating can hear the arguments and give input. Input from the mailing list, jabber chat room, and the people in the room will be considered. You do not need to be in the meeting room at IETF 75 to have input. Cullen From stewe@stewe.org Wed Jul 8 15:34:47 2009 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 63D9E3A6836 for ; Wed, 8 Jul 2009 15:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.897, 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 FLqGdOxIEojh for ; Wed, 8 Jul 2009 15:34:46 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 403793A694C for ; Wed, 8 Jul 2009 15:34:45 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 331707-1743317 for multiple; Thu, 09 Jul 2009 00:35:12 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 08 Jul 2009 15:35:01 -0700 From: Stephan Wenger To: Cullen Jennings , Message-ID: Thread-Topic: [codec] Purpose of the CODEC BOF Thread-Index: AcoAHFR8jP2UwE2czUaEsVA5VpWBWw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Purpose of the CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 22:34:47 -0000 Hi Cullen, You state in absolutely clear terms the main reason for a BOF. Why do I miss those clear terms in the updated agenda? Why is agenda item #3 not called "Should the IETF perform work towards an Internet Codec?" Let me also repeat my earlier suggestion: in order to be time-efficient, it would be helpful if we could avoid repeating known arguments over and over. One way to do this would be that you would summarize the state of discussion very early in the meeting---and ask not to repeat those known arguments. A final note on the chair selection: Jean-Marc and Jason are both glowing supporters of this, in my opinion, ill-conceived effort. While it is not entirely unusual for a BOF to be chaired by proponents, I wonder whether less involved chairs would not be a better choice in such a heavily contested BOF. Perhaps it would be good if a graybeard would run this show? Jason, Jean-Marc, please understand that I don't doubt that you would do your best to run the meeting as impartially as you can. I do doubt, though, that this would be enough. Speaking from own experience, if you will :-) Regards, Stephan On 7/8/09 1:49 PM, "Cullen Jennings" wrote: > > Now that the new agenda is out, few comments on email threads so far ... > > BOFs get run for lots of reasons but the primary purpose of this BOF > is to get input to help answer the question of if the IETF should form > a WG to do this work or not. I hope the agenda provides time to talk > about the important issues for making this decision. > > I expect many of the arguments made on the list (and repeated on the > list) to be repeated again in the BOF. This is needed so that a broad > range of people participating can hear the arguments and give input. > > Input from the mailing list, jabber chat room, and the people in the > room will be considered. You do not need to be in the meeting room at > IETF 75 to have input. > > Cullen > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Wed Jul 8 23:17:55 2009 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 3BEBD3A6927 for ; Wed, 8 Jul 2009 23:17:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZSGsks-yWwA for ; Wed, 8 Jul 2009 23:17:54 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 1DFC33A67DD for ; Wed, 8 Jul 2009 23:17:53 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-088-067-100-033.pools.arcor-ip.net [88.67.100.33]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n696I2l2011451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jul 2009 08:18:09 +0200 From: "Christian Hoene" To: "'Jason Fischl'" , References: In-Reply-To: Date: Thu, 9 Jul 2009 08:18:00 +0200 Message-ID: <000601ca005d$078f70c0$16ae5240$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5g Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.204; VDF: 7.1.4.205; host: mx05); id=29984-vuSOX1 Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:17:55 -0000 > 4. What type of engineering work would this be? ( 25 min ) > Have presentations on the two proposed codecs. Focus is to make sure it > looks feasible to do the technical > work to meet the goals. This should also help clarify what type of work is > being considered. > - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt > - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt I just like to remind the chairs that their is a third proposed codec which will fulfill the assumed goals of this WG. SBC has a much lower complexity than CELT and achieves nearly the some quality vs. rate performance tradeoff. And it has been standardized already. Christian From ron.even.tlv@gmail.com Wed Jul 8 23:55:45 2009 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 1617B3A69D2 for ; Wed, 8 Jul 2009 23:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 e8xuZI4TyKXZ for ; Wed, 8 Jul 2009 23:55:44 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id E7D9F3A69B2 for ; Wed, 8 Jul 2009 23:55:43 -0700 (PDT) Received: by bwz25 with SMTP id 25so3321578bwz.37 for ; Wed, 08 Jul 2009 23:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=BevBLM1Hn2y2U8kjRzz0jd5bVRUzpyHRZH6oozgrt8E=; b=BhFHQCOLqeNTWyVnMDDSVgvpiBcV1z+Cp+CjzLhZzKYbCsgULt3yE+0iY4AI1zms+h n+CEXw6yjHxs2AnWjjsDADM9V81OXCTRz3lS6A/zcT2ZssgVkTRtKJ5JEVeFJ045oc5P KQSfvF+fmYpR2vAhgucCnS/gPiapnwi9pP2bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=alj1d6T1wdTo/NEEMdvT1rCP6h+UYUjSjxJa9cVY9mnf0LAeFvhZLbRTkBXcGxh+Ba pGtuvl1O430t3obDRFxgOgkVjFzZhHPvqK6dUOnlugMtGqiZhI6guLtHvUMRDXtNbjO2 f/1twHkS9jDfToTPDIkOHA1pel6Q/zC+IhGVE= Received: by 10.103.160.3 with SMTP id m3mr218048muo.25.1247122568807; Wed, 08 Jul 2009 23:56:08 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-106-163.red.bezeqint.net [79.182.106.163]) by mx.google.com with ESMTPS id w5sm42958546mue.4.2009.07.08.23.56.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 23:56:08 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" , "'Jason Fischl'" , References: <000601ca005d$078f70c0$16ae5240$@de> In-Reply-To: <000601ca005d$078f70c0$16ae5240$@de> Date: Thu, 9 Jul 2009 09:56:08 +0300 Message-ID: <4a559488.05ae660a.141e.2000@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gAAElHQA= Content-Language: en-us Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:55:45 -0000 Hi, Seeing this comment is making me repeat my suggestion that we should not present codecs in the BOF. Instead I would like to see a presentation on the proposed work, will there be one codec from this WG or many codecs all addressing wideband, open source and RF requirements, I am sure that having many codecs will help developers choose the right one and achieve great interoperability, so probably we are talking about one codec. If you want to have one codec as the outcome than the proposed process should be presented in the BOF. What are the criteria to decide on requirements ( already saw some contradictions on the mailing list regarding algorithmic delay and complexity) and how to select one. Regards Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Thursday, July 09, 2009 9:18 AM > To: 'Jason Fischl'; codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > > 4. What type of engineering work would this be? ( 25 min ) > > Have presentations on the two proposed codecs. Focus is to make sure > it > > looks feasible to do the technical > > work to meet the goals. This should also help clarify what type of > work is > > being considered. > > - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt > > - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt > > I just like to remind the chairs that their is a third proposed codec > which > will fulfill the assumed goals of this WG. SBC has a much lower > complexity > than CELT and achieves nearly the some quality vs. rate performance > tradeoff. And it has been standardized already. > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ingemar.s.johansson@ericsson.com Thu Jul 9 06:43:25 2009 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 873BE3A6C41 for ; Thu, 9 Jul 2009 06:43:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 anGVFqNrKGN6 for ; Thu, 9 Jul 2009 06:43:24 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1247147005-3628-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F340D3A6892 for ; Thu, 9 Jul 2009 06:43:23 -0700 (PDT) Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AD.76.06791.614F55A4; Thu, 9 Jul 2009 15:43:50 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 15:43:49 +0200 Date: Thu, 9 Jul 2009 15:43:49 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40D4@esealmw109.eemea.ericsson.se> References: From: "Ingemar Johansson S" To: Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:43:25 -0000 This is a multi-part message in MIME format... ------------=_1247147005-3628-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1247147005-3628-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F340D3A6892 for ; Thu, 9 Jul 2009 06:43:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7be7ae000001a87-e9-4a55f416f504 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AD.76.06791.614F55A4; Thu, 9 Jul 2009 15:43:50 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 15:43:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA009B.49F76FA9" Subject: Re: [codec] Updated Agenda for Codec BOF Date: Thu, 9 Jul 2009 15:43:49 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40D4@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: <130EBB38279E9847BAAAE0B8F9905F8C6E40D4@esealmw109.eemea.ericsson.se> Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: Acn/31wHqrZcla1XSuakYuqR3vYiZwAuabBR References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 09 Jul 2009 13:43:49.0722 (UTC) FILETIME=[4A2303A0:01CA009B] X-Brightmail-Tracker: AAAAAA== This is a multi-part message in MIME format. ------_=_NextPart_001_01CA009B.49F76FA9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 I looked through the agenda and have some concerns with it: =20 I would like to see bullet 3 renamed to something like "should IETF do = this?" with sub-bullets that adresses the issues that have been brought = up on this list (IPR/royalty, area of expertice, maintenance, testing, = IETFs role...). I believe that this bullet will take the longest time to = go through and I expect something like 40 minutes or more for this. =20 As regards to the chairs, I would personally prefer that this was a more = balanced pick, why not have one "proponent" and one "opponent" as chairs = ?, possibly add a neutral "greybeard" who has the ability to see this = from the side ?. This is important as both proponents and opponents want = to make sure that the whole discussion is fair and that the discussion = does not exclude important subjects.=20 Please note that it is not to be interpreted as a negative opinion = against Jason or Jean-Marc. =20 Regards Ingemar ------_=_NextPart_001_01CA009B.49F76FA9 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjINAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKQAAAFJlOiBbY29kZWNdIFVwZGF0 ZWQgQWdlbmRhIGZvciBDb2RlYyBCT0YAag0BBYADAA4AAADZBwcACQAPACsAMQAEAF8BASCAAwAO AAAA2QcHAAkADwArADEABABfAQEJgAEAIQAAADFGRDlFMzMxMTUxMEIwNDE4OTA3Q0IxQ0NEMzZC QTQ0ABoHAQOQBgAMDgAAOAAAAAMANgAAAAAAQAA5AKlv90mbAMoBHgA9AAEAAAAFAAAAUmU6IAAA AAACAUcAAQAAADsAAABjPVNFO2E9NDAwbmV0O3A9RXJpY3Nzb247bD1FU0VBTE1XMTA5LTA5MDcw OTEzNDM0OVotMjA5OTUxAAAeAEkAAQAAAB0AAABjb2RlYyBEaWdlc3QsIFZvbCAyLCBJc3N1ZSA0 AAAAAEAATgCA2iVI3//JAR4AWgABAAAAFwAAAGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcAAAIBWwAB AAAASwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcAU01U UABjb2RlYy1ib3VuY2VzQGlldGYub3JnAAACAVwAAQAAABwAAABTTVRQOkNPREVDLUJPVU5DRVNA SUVURi5PUkcAHgBdAAEAAAAXAAAAY29kZWMtcmVxdWVzdEBpZXRmLm9yZwAAAgFeAAEAAABLAAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAY29kZWMtcmVxdWVzdEBpZXRmLm9yZwBTTVRQAGNvZGVj LXJlcXVlc3RAaWV0Zi5vcmcAAAIBXwABAAAAHAAAAFNNVFA6Q09ERUMtUkVRVUVTVEBJRVRGLk9S RwAeAGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAAFwAAAGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcA AB4AaAABAAAABQAAAFNNVFAAAAAAHgBpAAEAAAAXAAAAY29kZWMtcmVxdWVzdEBpZXRmLm9yZwAA HgBwAAEAAAAlAAAAW2NvZGVjXSBVcGRhdGVkIEFnZW5kYSBmb3IgQ29kZWMgQk9GAAAAAAIBcQAB AAAAGwAAAAHJ/99cB6q2XJWtV0rmpGLqkd72ImcALmmwUQAeAHQAAQAAAA8AAABjb2RlY0BpZXRm Lm9yZwAAHgAaDAEAAAAUAAAASW5nZW1hciBKb2hhbnNzb24gUwAeAB0OAQAAACUAAABbY29kZWNd IFVwZGF0ZWQgQWdlbmRhIGZvciBDb2RlYyBCT0YAAAAAAgEJEAEAAAD+BgAA+gYAALIVAABMWkZ1 0REiPwMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBzZXQwIAcTAoD/EAMA UARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2fkS72Y0EG8RdhHjCO8J97Y7Gr8OMDUR0gxgYwBQ MwsJAWQzNhFgC6U0IDkQAipcDrIBkA4QOSAAPEhUTUwgZGnEcj0gIHI+fR/jACFzAzAhMWRvAOAh MQqxXP5xGqAhMRDwAzAhlRFgH5vGMx9wIJBFQUQhYB+cBDc3IIBUSVRMRR8ljR9gDvAFoAWBIERp QmcHkHQsIFYG8CCaMikASQQQClAgNCWddDg1IIAvJs8gMgrjIBcrryy/DhA2DvA8TUUcVEEoMQIw CfB0PSKDBeAgozYuMDAuHtAYMDEuKuAfYDgiIARuYQeAPUdFTkXgUkFUT1Irny3/M49/IAQoESsg JU8n4TUPIDE1wRFgPEJPRFkljR7hETf/Zzk2IIBESVYQIGlkPTxQT1dBBFJlC1B5VGV4dO8ewC8g H3Ag/yAAACKVIzP/IvEjjzofOy88MD3PPt8/6n8fuT2QQ8pAHyAUMZAggEbgT05UIGYA0DIABxPq IACQejIAMkO7GDADslMB0D/5SGkfnDU74S//SWIhaSF3RgsBwCF3CqJPCOsKgB+cMCURLzwRTl9H //9Bb0J/Q49En08/Rr9UX0jff0nvSv9MCkzvTf9ULx/1OMEfcCZuYnNwAoAhiPwnYQFAWc9QP1FP Ul9Tb/9jb1WPVp9Xr1i/Zh9a32s/T1z/Xg9fH0v7SSAaUG8iawmAIHRoA2B1Z58jcHhwKdAgQAnw ZGF5INV5YCARAHYp0HMDcCnQfy/BdPAEoAQgA/B4cDxAdP46YP9iD08PZw9oH2kvaj//cu9sX21v bn9vj3Cfca9yv/9zz3Tfde9gD3u/fM+PH2RP/2Vffi9/P4BPgV+RX4N/hI//hZ+Gr4e/iM+J35o/ i/+NDyuOH3dodwhgbHhQbGmbeDB4YG+kIAngIGKm0OJsEUAgMyAawDHSeFEvp3F6QXhwC4BnpwQi c+popsNJL4BGnQCncKlRnHM/MbB7EymwYi2n1MsEIHhwYQVAYWQawAQQvweRePIEAQpQrGV542IJ 4cenwHiTBUB1cCACIKrzA6cBKOAgKElQUi9lA2B5B0B0eSkACsBlrXmAbyHwPTBwBJB0DeD+ZSkA AMALgC/xAHCyUi/wfyjgqXEpcaqRBCADYKgALrm0kCkud9GusKcQZXoBv6yDr+On1QPwp/B4YGGn Mn95ARpQqYAo0XhgB3GnUmffquJ4lHmid+Cx4mMFQKkd6jQRYG0LgHWzYa+gBcDfBGAawKNwBbGr Ai6Pr5C//32/lb+Wz5ffmO+hn5sPnB//nS+eP59PoF+hb6J/o4+kn/+Ov7zfve/QP5L/lA+/T8Bf /8Fvwn/Sf8Sfxa/Gv8fPyN9/ye/K/9tfzR/OL88/4rZB+bQxZWcLEaxhquJ6YREA/d5AcylxpqWy AXowMdCn8DZ56cAawGYTMbWYd2H3BCB5gLvTYgdAswLpsQ3gkmspAHdo6mBub65FXQIgZdOf1K/V uiLqgG/+cO4BAjAxsHmi7gGp8PFA5/FXBCDo1CA/KQDxUAQQ/mkCYOpgrNB4UHmA7hC7UOpy5SEi CcF5rrALEatR/6og7j/vT9W6EQCtRAGgAxD/eyDqYKdlqwL2P/dP1boDUt944wCQAQDzkLTQVK/y /tL+bfFQ16ANsKyxthHtgCNw//En67Hx4vJ163L/oadhspD/pzEpsLvxtZUp0PYBqADeIfhzY3Xz 8a+xsAHkoN5Af3mTAwcD+SJQu3Htcj0wY+8KQP5R/zirwWq5wbyQ0L//0c++z9bP19/Y79n/4q/c H//dL94/30/gX+Fv4n/jj+Sf++Wvz85QqADroCnQBvG1df97IP7yBvKnYa6wPEAv4SKw/+qQstD0 geuy7hDoALIw7dK97NBuBGI3oLKhsFFK66CLBnG7oUqxgG4tTRHw/mO8rwn/Cw8MHw0vDj8PT/8X /xFvEn8TjxSfFa8WvxfP//sf/C8v7yZfJ28ofymPMj9/K68svy3PLt807zD/OgVS/+f0NV82bzd/ OI85nzqvO7/fPM893z7vP/9BD0m3obKQ/nJCj0OfRK9Fv0bPUk9TXwtUb0hBMhliL05PU/xDUrCQ JEFHr0i/WGBHgE48WOR38P+QZ3V5MT1Wannw66BjGlBwHfFkej3oMHSr4P5AWU1bgmlcZij54LIA sbAoXbIp9CE9qfB1eWDqoKlweEAwIilce0owXcEoKfg7XH1ePliCWO9Z/01WQjVYgkJPRFleLjeh VdFIVE1MGwB9aBAAAB4ANRABAAAARgAAADwxMzBFQkIzODI3OUU5ODQ3QkFBQUUwQjhGOTkwNUY4 QzZFNDBENEBlc2VhbG13MTA5LmVlbWVhLmVyaWNzc29uLnNlPgAAAB4AORABAAAALwAAADxtYWls bWFuLjEzMDc2LjEyNDcwNjYyODEuNDkzNi5jb2RlY0BpZXRmLm9yZz4AAB4ARxABAAAADwAAAG1l c3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAXgAAAFIAZQAlADMAQQAgAFsAYwBvAGQAZQBj AF0AIABVAHAAZABhAHQAZQBkACAAQQBnAGUAbgBkAGEAIABmAG8AcgAgAEMAbwBkAGUAYwAgAEIA TwBGAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMKWWyAKZAMoBQAAIMGapEUqbAMoBAwDeP69vAAAD APE/HQQAAB4A+D8BAAAAFAAAAEluZ2VtYXIgSm9oYW5zc29uIFMAAgH5PwEAAABIAAAAAAAAANyn QMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUVSSUNTU09OL09VPVNFMi9DTj1SRUNJUElFTlRTL0NO PUVQTElKT0gAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAA AAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAAD AB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAIAAAARVBMSUpPSAAeADFAAQAAAAgAAABFUExJSk9IAB4A MkABAAAAFwAAAGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcAAB4AM0ABAAAAFwAAAGNvZGVjLXJlcXVl c3RAaWV0Zi5vcmcAAB4AOEABAAAACAAAAEVQTElKT0gAHgA5QAEAAAACAAAALgAAAAMAdkD///// CwApAAAAAAALACMAAAAAAAMABhD4V5B0AwAHEPQCAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABl AAAASElJTE9PS0VEVEhST1VHSFRIRUFHRU5EQUFOREhBVkVTT01FQ09OQ0VSTlNXSVRISVQ6SVdP VUxETElLRVRPU0VFQlVMTEVUM1JFTkFNRURUT1NPTUVUSElOR0xJS0UiU0hPVQAAAAACAX8AAQAA AEYAAAA8MTMwRUJCMzgyNzlFOTg0N0JBQUFFMEI4Rjk5MDVGOEM2RTQwRDRAZXNlYWxtdzEwOS5l ZW1lYS5lcmljc3Nvbi5zZT4AAADfkQ== ------_=_NextPart_001_01CA009B.49F76FA9-- ------------=_1247147005-3628-1-- From hsinnrei@adobe.com Thu Jul 9 07:22:46 2009 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 5A35F28C0E3 for ; Thu, 9 Jul 2009 07:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrMtIgN3ZAe0 for ; Thu, 9 Jul 2009 07:22:45 -0700 (PDT) Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id 2AF8E3A6B2D for ; Thu, 9 Jul 2009 07:22:37 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSlX9RRj1KVV4SGnnRD6cBj14T8xEO4JU@postini.com; Thu, 09 Jul 2009 07:23:05 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n69EMwWG019157; Thu, 9 Jul 2009 07:22:59 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n69EMwiq023478; Thu, 9 Jul 2009 07:22:58 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Thu, 9 Jul 2009 07:22:58 -0700 From: Henry Sinnreich To: Ingemar Johansson S , "codec@ietf.org" Date: Thu, 9 Jul 2009 07:22:57 -0700 Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAm1IxyvXE8nf2SemHB71Bad5MLAABW8II Message-ID: In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40D4@esealmw109.eemea.ericsson.se> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C67B67714A58hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:22:46 -0000 --_000_C67B67714A58hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All these efforts to kill the free Internet voice codec before it is even b= orn! There must be a very big stake to do this... Henry On 7/9/09 8:43 AM, "Ingemar Johansson S" = wrote: WARNING: contains banned part --_000_C67B67714A58hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Updated Agenda for Codec BOF All these efforts to kill the free Internet voice codec before it is = even born!

There must be a very big stake to do this...

Henry


On 7/9/09 8:43 AM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com> wrote:
WARNING: contains banned part

--_000_C67B67714A58hsinnreiadobecom_-- From gmaxwell@juniper.net Thu Jul 9 07:40:49 2009 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 664FB28C219 for ; Thu, 9 Jul 2009 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 fIhdI4gpfk+S for ; Thu, 9 Jul 2009 07:40:48 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6F1933A683A for ; Thu, 9 Jul 2009 07:40:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSlYBhWmsJ8YuSCWUYytoY/Il7XACYXl9@postini.com; Thu, 09 Jul 2009 07:41:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 9 Jul 2009 07:39:55 -0700 From: Gregory Maxwell To: Christian Hoene , "codec@ietf.org" Date: Thu, 9 Jul 2009 07:39:54 -0700 Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gABDqLsA= Message-ID: References: , <000601ca005d$078f70c0$16ae5240$@de> In-Reply-To: <000601ca005d$078f70c0$16ae5240$@de> 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 Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:40:49 -0000 Christian Hoene wrote: > I just like to remind the chairs that their is a third proposed codec whi= ch > will fulfill the assumed goals of this WG. SBC has a much lower complexit= y > than CELT and achieves nearly the some quality vs. rate performance > tradeoff. And it has been standardized already. You must have an odd definition of "almost equal" as your own publication (= http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/ hoene2008_itu.pdf) shows a >2:1 bitrate advantage for a year old version of= CELT vs SBC. Since, according to you, we're also a year out from the patents on SBC expi= ring there is still another year in which competing solutions can widen the= performance gap before SBC meets even the most basic of the proposed goals= . I'm also a little confused by your citation of complexity. Just a day or tw= o ago you seemed to be presenting complexity and size as irrelevant for the= internet. Thats not a position I agree with, but if we're going to talk co= mplexity we should have goals. I believe that CELT (at least in low comple= xity mode) is within the bounds of what reasonable even for low end mobile = devices and that going lower has few advantages, but this is a decision whi= ch is hard to navigate without some targets. What do you believe the requ= irements are for computational complexity as well as static and dynamic mem= ory? I also agree with the position that Roni has taken in the past that this wo= rking group would provide no value as a rubber-stamping venue. It's not at= all clear to me that SBC will meet the eventual requirements. For example,= independent coding of frames was considered to be an important 'internet o= ptimization' in iLBC. As far as I know SBC does not provide this. I'm not = sure that that should be an eventual requirement, and I'd prefer some kind = of criteria about robustness under loss since independence is only one way = to achieve that end ... I think it's the robustness under packet loss which= is actually the internet community requirement. But it could quite reason= ably be one. Of course, that doesn't mean that the IETF should ignore SBC, your RTP draf= t for SBC seems quite reasonable, I am just far from convinced that it has = much relevance here. From hoene@uni-tuebingen.de Thu Jul 9 08:00:00 2009 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 D8E3228C248 for ; Thu, 9 Jul 2009 08:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 UrSDDGdyxtIh for ; Thu, 9 Jul 2009 08:00:00 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id C218028C22C for ; Thu, 9 Jul 2009 07:59:59 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n69F0QLQ000473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jul 2009 17:00:26 +0200 From: "Christian Hoene" To: "'Gregory Maxwell'" , References: , <000601ca005d$078f70c0$16ae5240$@de> In-Reply-To: Date: Thu, 9 Jul 2009 17:00:24 +0200 Message-ID: <007a01ca00a5$fd1276d0$f7376470$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gABDqLsAAAQdvcA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.204; VDF: 7.1.4.211; host: mx05); id=29984-S2gcjS Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:00:00 -0000 > You must have an odd definition of "almost equal" as your own publication > (http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/ > hoene2008_itu.pdf) shows a >2:1 bitrate advantage for a year old version of > CELT vs SBC. I have to admit that these results were based on a buggy BlueZ implementation of SBC not on the reference implementation. The current results look much better with the reference and the corrected BlueZ implementation. At high rates SBC outperforms CELT 0.5. Currently the tests for CELT 0.6 are running. However, these results are based all on PEAQ and therefore are only an indication of quality. Christian From gmaxwell@juniper.net Thu Jul 9 08:12:49 2009 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 9AA9928C21E for ; Thu, 9 Jul 2009 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 HYhkT-1cQYGL for ; Thu, 9 Jul 2009 08:12:48 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id AC37C28C1FE for ; Thu, 9 Jul 2009 08:12:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSlYJBG2EkYxlDruhEKTcWcqxjUnMDrQ7@postini.com; Thu, 09 Jul 2009 08:13:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 9 Jul 2009 08:11:35 -0700 From: Gregory Maxwell To: Christian Hoene , "codec@ietf.org" Date: Thu, 9 Jul 2009 08:08:41 -0700 Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gABDqLsAAAQdvcAAAuvt4 Message-ID: References: , <000601ca005d$078f70c0$16ae5240$@de> , <007a01ca00a5$fd1276d0$f7376470$@de> In-Reply-To: <007a01ca00a5$fd1276d0$f7376470$@de> 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 Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:12:49 -0000 Christian Hoene [hoene@uni-tuebingen.de] wrote: > I have to admit that these results were based on a buggy BlueZ > implementation of SBC not on the reference implementation. The current > results look much better with the reference and the corrected BlueZ > implementation. At high rates SBC outperforms CELT 0.5. Currently the tes= ts > for CELT 0.6 are running. However, these results are based all on PEAQ an= d > therefore are only an indication of quality. If computational complexity is a consideration you should consider using th= e CELT encoder with complexity 1 (or otherwise without the long term predic= tor). It makes the computational load much closer to SBC's and at higher b= itrates it only makes a small difference in perceptual performance.=20 From ingemar.s.johansson@ericsson.com Thu Jul 9 10:15:58 2009 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 6AD873A6AA7 for ; Thu, 9 Jul 2009 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.914 X-Spam-Level: X-Spam-Status: No, score=-4.914 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_SE=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 7i8zcJXn1RYF for ; Thu, 9 Jul 2009 10:15:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 34DF73A67CF for ; Thu, 9 Jul 2009 10:15:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7bcbae0000053ea-3a-4a5625e7c8cd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F0.BC.21482.7E5265A4; Thu, 9 Jul 2009 19:16:23 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 19:16:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 19:16:22 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAm1IxyvXE8nf2SemHB71Bad5MLAABW8IIAAWlyTM= References: From: "Ingemar Johansson S" To: "Henry Sinnreich" , X-OriginalArrivalTime: 09 Jul 2009 17:16:23.0287 (UTC) FILETIME=[FBDA9870:01CA00B8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:15:58 -0000 Hi =20 This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is = not done I fear that this BoF will just end up in a verbal fist-fight = and nobody benefits from it, it will only make us all look like morons. =20 Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of = codecs is secondary and can be discussed once/if a formation of the WG = is decided.=20 =20 Personally I don't know what this "banned" stuff inserted by the server = is about... =20 Regards Ingemar ________________________________ Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] Skickat: to 2009-07-09 16:22 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Updated Agenda for Codec BOF All these efforts to kill the free Internet voice codec before it is = even born! There must be a very big stake to do this... Henry On 7/9/09 8:43 AM, "Ingemar Johansson S" = > wrote: WARNING: contains banned part =09 =09 From stephen.botzko@gmail.com Thu Jul 9 11:44:51 2009 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 F1C9C28C15D for ; Thu, 9 Jul 2009 11:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 IAiwBlzLC73S for ; Thu, 9 Jul 2009 11:44:49 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2F0523A67DF for ; Thu, 9 Jul 2009 11:44:49 -0700 (PDT) Received: by fxm18 with SMTP id 18so382984fxm.37 for ; Thu, 09 Jul 2009 11:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0vAHZCNyAHLqN6rOsVN23esevZ+SHTeJJmq4/PcheHA=; b=dGGfIgS7Ik7Bjvg6CauP5pznk0XYF8k3k1GZQZ2wGpVEbL5+FurBQ3dD07Lc4tcszT JtUyJgX60AFMvpaxRUzqbqKzKYpkDvjmQxmUka5insw60AVy08E434EOMVEFYtMrr7iF xingfXQi9yPGQ1fiAHO/XoFXpWnSM4qT2GTa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aNxwo+UyemtbSyxDbC3DZ/TlFm77BSDWPzUrsjNDAQ+HfNdDaGlndmu6FrSh46dr3/ a6ddNQlpH2ObqkweG4o0qaKm9zWYNkg3LZ+uEhGS4nS/RYxXxQa3NSEaw8UAUuE+EAh5 FQQtHqJ1isE+GePeWiSbHrIC7i+1sWuSEr77g= MIME-Version: 1.0 Received: by 10.103.168.12 with SMTP id v12mr605349muo.67.1247165112586; Thu, 09 Jul 2009 11:45:12 -0700 (PDT) In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> Date: Thu, 9 Jul 2009 14:45:12 -0400 Message-ID: <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> From: stephen botzko To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=0016367ed508831075046e4a410f Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:44:51 -0000 --0016367ed508831075046e4a410f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the goal of the BOF, the aim is for a moderated discussion of the merits (pro and con). So I agree that it would be prudent to have chairs who reflect the various views. It will make it easier to keep the meeting orderly and moving, since no one will feel that the chairs shut them down because they didn't agree with their views. "Success" here is not measured by whether a WG is created (or not). "Success" is providing quality input to the IESG on the merits from a broad range of participants. Please understand that I am *not* saying that I think Jean-Marc and Jason * would* be deliberately unfair. I *am* saying that we should anticipate a lively discussion without clear consensus. So moderating it is likely to be challenging. Also, it will not be easy for Jean-Marc and Jason to present their personal views while they are also acting as chairs. For these reasons, I think that if the chairs all hold one view, the BOF is unlikely to be successful (using my definition above). As far as codecs go, I think there is some value in having a couple of sample submissions to look at. However, time will be valuable in the BOF. I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing them. Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The propose= d charter's output is a single codec, not multiple codecs. There would need to be a common understanding of whether the working group is *selecting* a single codec from the candidates, or somehow *developing* a common codec from more than one candidate. There would also need to be some consensus o= n the basis for codec selection (and/or technology development), and some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision needed on the IPR rules. It will be very difficult to invent the process while we are simultaneously talking about codec technology. I'd think the WG (if it goes forward) woul= d need to spend some time hammering out a working process before it will be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, and to the WG (when and if).. IMHO we ought to refrain from accusing people of "killing", There is nothing to kill at this point. Polarizing the debate by labeling the participants is not a constructive way to proceed. The genuine areas of disagreement are hard enough. Stephen Botzko Polycom On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > This is yet another reason why I think it is best to select chairs for th= is > who reflect the different opinions around this subject. If this is not do= ne > I fear that this BoF will just end up in a verbal fist-fight and nobody > benefits from it, it will only make us all look like morons. > > Also I am not trying to kill any codec, I just don't see how it fits in t= he > IETF, thats why I wish to have all issues discussed. Selection of codecs = is > secondary and can be discussed once/if a formation of the WG is decided. > > Personally I don't know what this "banned" stuff inserted by the server i= s > about... > > Regards > Ingemar > > ________________________________ > > Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Skickat: to 2009-07-09 16:22 > Till: Ingemar Johansson S; codec@ietf.org > =C4mne: Re: [codec] Updated Agenda for Codec BOF > > > All these efforts to kill the free Internet voice codec before it is even > born! > > There must be a very big stake to do this... > > Henry > > > On 7/9/09 8:43 AM, "Ingemar Johansson S" https://rvi.se.ericsson.net/dana-cached/help/empty.html> > wrote: > > > > WARNING: contains banned part > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367ed508831075046e4a410f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the goal of the BOF, the aim is for a moderated discussion of the mer= its (pro and con).=A0 So I agree that it would be prudent to have chairs wh= o reflect the various views.=A0 It will make it easier to keep the meeting = orderly and moving, since no one will feel that the chairs shut them down b= ecause they didn't agree with their views.=A0 "Success" here = is not measured by whether a WG is created (or not).=A0 "Success" is providing quality input to the IESG on the merits fr= om a broad range of participants.

Please understand that I am not= saying that I think Jean-Marc and Jason would be deliberately u= nfair. I am saying that we should anticipate a lively discussion wit= hout clear consensus. So moderating it is likely to be challenging.=A0 Also= , it will not be easy for Jean-Marc and Jason to present their personal vie= ws while they are also acting as chairs.=A0 For these reasons, I think that= if the chairs all hold one view, the BOF is unlikely to be successful (usi= ng my definition above).

As far as codecs go, I think there is some value in having a couple of = sample submissions to look at.=A0 However, time will be valuable in the BOF= .=A0 I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing them.

Also, before anythin= g can move forward there needs to be (a) a chartered working group and (b) = an established set of working procedures. The proposed charter's output= is a single codec, not multiple codecs.=A0 There would need to be a common= understanding of whether the working group is selecting a single co= dec from the candidates, or somehow developing a common codec from m= ore than one candidate.=A0 There would also need to be some consensus on th= e basis for codec selection (and/or technology development), and some conse= nsus on how to measure the codec performance against the various requiremen= ts, and of course at some point there will be more precision needed on the = IPR rules.=A0

It will be very difficult to invent the process while we are simultaneo= usly talking about codec technology.=A0 I'd think the WG (if it goes fo= rward) would need to spend some time hammering out a working process before= it will be ready to accept candidates for consideration. Perhaps some more= focused discussion on these points ahead of time would be helpful to the I= ESG, and to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing",= =A0 There is nothing to kill at this point.=A0 Polarizing the debate by lab= eling the participants is not a constructive way to proceed.=A0 The genuine= areas of disagreement are hard enough.

Stephen Botzko
Polycom

On Thu, Jul= 9, 2009 at 1:16 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

This is yet another reason why I think it is best to select chairs for this= who reflect the different opinions around this subject. If this is not don= e I fear that this BoF will just end up in a verbal fist-fight and nobody b= enefits from it, it will only make us all look like morons.

Also I am not trying to kill any codec, I just don't see how it fits in= the IETF, thats why I wish to have all issues discussed. Selection of code= cs is secondary and can be discussed once/if a formation of the WG is decid= ed.

Personally I don't know what this "banned" stuff inserted by = the server is about...

Regards
Ingemar

________________________________

Fr=E5n: Henry Sinnreich [mailto:hsinn= rei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org=
=C4mne: Re: [codec] Updated Agenda for Codec BOF


All these efforts to kill the free Internet voice codec before it is even b= orn!

There must be a very big stake to do this...

Henry


On 7/9/09 8:43 AM, "Ingemar Johansson S" = <ingemar.s.johansson= @ericsson.com <https://rvi.se.ericsson.net/dana-cached/he= lp/empty.html> > wrote:



=A0 =A0 =A0 =A0WARNING: contains banned part



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

--0016367ed508831075046e4a410f-- From Borilin@spiritdsp.com Thu Jul 9 12:13:30 2009 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 6DFB63A6808 for ; Thu, 9 Jul 2009 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 Dp3as6JXQ-ji for ; Thu, 9 Jul 2009 12:13:22 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id B60913A67DF for ; Thu, 9 Jul 2009 12:13:21 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n69JDh6V019842; Thu, 9 Jul 2009 23:13:43 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA00C9.5C4DEE57" Date: Thu, 9 Jul 2009 23:13:36 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAxW8/m/aQ36kCRN+pJLkBylx7eAAAym3A References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> From: "Slava Borilin" To: "stephen botzko" , "Ingemar Johansson S" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:13:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA00C9.5C4DEE57 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Stephen that it would be better to EXCLUDE #4 from agenda - = as this may be time consuming. Instead I would like to get back the item "requirements for codec, as = they may look like from IETF perspective" (royalty-free, license-free = from legal, + technical (packet loss, MOS, performance)). =20 I do NOT think we (most of us) do not believe it's feasible - so not = much point of discussing if its feasible to select good IP codec. = Questions are criteria, and path to go (=3Dprocess). =20 Slava Borilin =20 ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Thursday, July 09, 2009 10:45 PM To: Ingemar Johansson S Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF =20 Given the goal of the BOF, the aim is for a moderated discussion of the = merits (pro and con). So I agree that it would be prudent to have = chairs who reflect the various views. It will make it easier to keep = the meeting orderly and moving, since no one will feel that the chairs = shut them down because they didn't agree with their views. "Success" = here is not measured by whether a WG is created (or not). "Success" is = providing quality input to the IESG on the merits from a broad range of = participants. Please understand that I am not saying that I think Jean-Marc and Jason = would be deliberately unfair. I am saying that we should anticipate a = lively discussion without clear consensus. So moderating it is likely to = be challenging. Also, it will not be easy for Jean-Marc and Jason to = present their personal views while they are also acting as chairs. For = these reasons, I think that if the chairs all hold one view, the BOF is = unlikely to be successful (using my definition above). As far as codecs go, I think there is some value in having a couple of = sample submissions to look at. However, time will be valuable in the = BOF. I think we should assume that the IESG will be able to assess the = sample contributions without our needing to spend a lot of time = discussing them. Also, before anything can move forward there needs to be (a) a chartered = working group and (b) an established set of working procedures. The = proposed charter's output is a single codec, not multiple codecs. There = would need to be a common understanding of whether the working group is = selecting a single codec from the candidates, or somehow developing a = common codec from more than one candidate. There would also need to be = some consensus on the basis for codec selection (and/or technology = development), and some consensus on how to measure the codec performance = against the various requirements, and of course at some point there will = be more precision needed on the IPR rules. =20 It will be very difficult to invent the process while we are = simultaneously talking about codec technology. I'd think the WG (if it = goes forward) would need to spend some time hammering out a working = process before it will be ready to accept candidates for consideration. = Perhaps some more focused discussion on these points ahead of time would = be helpful to the IESG, and to the WG (when and if).. IMHO we ought to refrain from accusing people of "killing", There is = nothing to kill at this point. Polarizing the debate by labeling the = participants is not a constructive way to proceed. The genuine areas of = disagreement are hard enough. Stephen Botzko Polycom On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S = wrote: Hi This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is = not done I fear that this BoF will just end up in a verbal fist-fight = and nobody benefits from it, it will only make us all look like morons. Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of = codecs is secondary and can be discussed once/if a formation of the WG = is decided. Personally I don't know what this "banned" stuff inserted by the server = is about... Regards Ingemar ________________________________ Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] Skickat: to 2009-07-09 16:22 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Updated Agenda for Codec BOF All these efforts to kill the free Internet voice codec before it is = even born! There must be a very big stake to do this... Henry On 7/9/09 8:43 AM, "Ingemar Johansson S" = > wrote: WARNING: contains banned part _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------_=_NextPart_001_01CA00C9.5C4DEE57 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with = Stephen that it would be better to EXCLUDE #4 from agenda – as this may be time consuming.

Instead I would = like to get back the item “requirements for codec, as they may look like = from IETF perspective” (royalty-free, license-free from legal, + = technical (packet loss, MOS, performance)).

 =

I do NOT think = we (most of us) do not believe it’s feasible – so not much point of discussing if its feasible to select good IP codec. Questions are = criteria, and path to go (=3Dprocess).

 =

Slava = Borilin

 =

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Thursday, July 09, = 2009 10:45 PM
To: Ingemar Johansson = S
Cc: codec@ietf.org
Subject: Re: [codec] = Updated Agenda for Codec BOF

 

Given the goal = of the BOF, the aim is for a moderated discussion of the merits (pro and = con).  So I agree that it would be prudent to have chairs who reflect the = various views.  It will make it easier to keep the meeting orderly and = moving, since no one will feel that the chairs shut them down because they = didn't agree with their views.  "Success" here is not measured by = whether a WG is created (or not).  "Success" is providing quality = input to the IESG on the merits from a broad range of participants.

Please understand that I am not saying that I think Jean-Marc and = Jason would be deliberately unfair. I am saying that we should anticipate a = lively discussion without clear consensus. So moderating it is likely to be challenging.  Also, it will not be easy for Jean-Marc and Jason to = present their personal views while they are also acting as chairs.  For = these reasons, I think that if the chairs all hold one view, the BOF is = unlikely to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of = sample submissions to look at.  However, time will be valuable in the = BOF.  I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing = them.

Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The = proposed charter's output is a single codec, not multiple codecs.  There = would need to be a common understanding of whether the working group is = selecting a single codec from the candidates, or somehow developing a common = codec from more than one candidate.  There would also need to be some = consensus on the basis for codec selection (and/or technology development), and = some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision = needed on the IPR rules. 

It will be very difficult to invent the process while we are = simultaneously talking about codec technology.  I'd think the WG (if it goes = forward) would need to spend some time hammering out a working process before it = will be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, = and to the WG (when and if)..

IMHO we ought to refrain from accusing people of = "killing",  There is nothing to kill at this point.  Polarizing the debate by = labeling the participants is not a constructive way to proceed.  The genuine = areas of disagreement are hard enough.

Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <ingemar.s.johansson@eric= sson.com> wrote:

Hi

This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is not done = I fear that this BoF will just end up in a verbal fist-fight and nobody = benefits from it, it will only make us all look like morons.

Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of codecs = is secondary and can be discussed once/if a formation of the WG is = decided.

Personally I don't know what this "banned" stuff inserted by = the server is about...

Regards
Ingemar

________________________________

Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org
=C4mne: Re: [codec] Updated Agenda for Codec = BOF



All these efforts to kill the free Internet voice codec before it is = even born!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 = AM, "Ingemar Johansson S" <ingemar.s.johansson@eric= sson.com <https://rvi.se.ericsson.net/dana-cached/help/empty.html= > > wrote:



       WARNING: contains banned part


_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------_=_NextPart_001_01CA00C9.5C4DEE57-- From jean-marc.valin@octasic.com Thu Jul 9 12:45:24 2009 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 14F7A28C1FD for ; Thu, 9 Jul 2009 12:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 cfEFQ+eXiQfM for ; Thu, 9 Jul 2009 12:45:23 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 466B328C1F4 for ; Thu, 9 Jul 2009 12:45:23 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 15:45:50 -0400 Message-ID: <4A56496D.4060807@octasic.com> Date: Thu, 09 Jul 2009 15:47:57 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Slava Borilin References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jul 2009 19:45:50.0709 (UTC) FILETIME=[DCDA9A50:01CA00CD] Cc: Ingemar Johansson S , codec@ietf.org, stephen botzko Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:45:24 -0000 Slava Borilin wrote: > I agree with Stephen that it would be better to EXCLUDE #4 from agenda – > as this may be time consuming. Just to clarify. This part of the agenda is intended to address the points that were raised about the feasibility of the work. It will also show what requirements are achievable in a short time frame. The presentations will be short and high level, not technical descriptions of the codecs internals. > Instead I would like to get back the item “requirements for codec, as > they may look like from IETF perspective” (royalty-free, license-free > from legal, + technical (packet loss, MOS, performance)). This should probably belong to the charter discussion, along with discussion of the process if (I hope) time permits. Cheers, Jean-Marc From Borilin@spiritdsp.com Thu Jul 9 12:53:32 2009 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 918763A6D0A for ; Thu, 9 Jul 2009 12:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.838, 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 H0w-YR9ThG7x for ; Thu, 9 Jul 2009 12:53:31 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 87FC43A6D00 for ; Thu, 9 Jul 2009 12:53:31 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n69JrthN020524; Thu, 9 Jul 2009 23:53:55 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 23:53:48 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4A56496D.4060807@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAzeI5/aOADrcVS+mXMUoB+HxXfwAAIPWg References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: Ingemar Johansson S , codec@ietf.org, stephen botzko Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:53:32 -0000 Jean-Marc (and mainly all others), Do we really have to prove that it is feasible to create IP codec (while some of them ALREADY EXISTS, like speex, CELT, IPMR, SILK)? Or people need to be convinced how much time/efforts it might take to create IP codec? I mean that if potential difficulties of creating the codec scares most of people, we should show that its not that scary. Otherwise- it will be a waste of time ("high-level only codec overview" parts seems to be the longest section (25m) in the agenda) Slava. -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: Thursday, July 09, 2009 11:48 PM To: Slava Borilin Cc: stephen botzko; Ingemar Johansson S; codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF Slava Borilin wrote: > I agree with Stephen that it would be better to EXCLUDE #4 from agenda -=20 > as this may be time consuming. Just to clarify. This part of the agenda is intended to address the points=20 that were raised about the feasibility of the work. It will also show what=20 requirements are achievable in a short time frame. The presentations will=20 be short and high level, not technical descriptions of the codecs internals. > Instead I would like to get back the item "requirements for codec, as=20 > they may look like from IETF perspective" (royalty-free, license-free=20 > from legal, + technical (packet loss, MOS, performance)). This should probably belong to the charter discussion, along with=20 discussion of the process if (I hope) time permits. Cheers, Jean-Marc From hsinnrei@adobe.com Thu Jul 9 13:30:10 2009 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 B816728C2A7 for ; Thu, 9 Jul 2009 13:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myGA-q4tAfbg for ; Thu, 9 Jul 2009 13:30:09 -0700 (PDT) Received: from psmtp.com (exprod6ob113.obsmtp.com [64.18.1.30]) by core3.amsl.com (Postfix) with ESMTP id D6F3528C2AB for ; Thu, 9 Jul 2009 13:30:08 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKSlZTYlpSy1qWNMNrcLs/8TIMxdunMcZf@postini.com; Thu, 09 Jul 2009 13:30:37 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n69KO3ao014254; Thu, 9 Jul 2009 13:24:04 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n69KUOiq024379; Thu, 9 Jul 2009 13:30:24 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 9 Jul 2009 13:30:24 -0700 From: Henry Sinnreich To: Christian Hoene , Jason Fischl , "codec@ietf.org" Date: Thu, 9 Jul 2009 13:30:20 -0700 Thread-Topic: Codec BOF agenda: Selection criteria and evaluation/testing Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gAB3oZho= Message-ID: In-Reply-To: <000601ca005d$078f70c0$16ae5240$@de> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C67BBD8C4A91hsinnreiadobecom_" MIME-Version: 1.0 Subject: [codec] Codec BOF agenda: Selection criteria and evaluation/testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:30:10 -0000 --_000_C67BBD8C4A91hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having the SBC as a 3rd candidate is good news, though I may have missed an= y email confirming it. Given the choice of several candidate codecs, would it make sense to add th= e following agenda items: 1. IETF policy of taking ownership and change control (by an A-D or IETF le= gal expert) 2. Selection criteria for the Internet voice codec 3. Testing and evaluation procedure Opinions? Thanks, Henry On 7/9/09 1:18 AM, "Christian Hoene" wrote: > 4. What type of engineering work would this be? ( 25 min ) > Have presentations on the two proposed codecs. Focus is to make sure it > looks feasible to do the technical > work to meet the goals. This should also help clarify what type of work i= s > being considered. > - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt > - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt I just like to remind the chairs that their is a third proposed codec which will fulfill the assumed goals of this WG. SBC has a much lower complexity than CELT and achieves nearly the some quality vs. rate performance tradeoff. And it has been standardized already. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C67BBD8C4A91hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Codec BOF agenda: Selection criteria and evaluation/testing Having the SBC as a 3rd candidate is good news, though I may have mis= sed any email confirming it.

Given the choice of several candidate codecs, would it make sense to add th= e following agenda items:

1. IETF policy of taking ownership and change control (by an A-D or IETF le= gal expert)
2. Selection criteria for the Internet voice codec
3. Testing and evaluation procedure

Opinions?

Thanks, Henry


On 7/9/09 1:18 AM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:

> 4. What type of engineering work would= this be? ( 25 min )
> Have presentations on the two proposed codecs. Focus is to make sure i= t
> looks feasible to do the technical
> work to meet the goals. This should also help clarify what type of wor= k is
> being considered.
> - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt
> - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt=

I just like to remind the chairs that their is a third proposed codec which=
will fulfill the assumed goals of this WG. SBC has a much lower complexity<= BR> than CELT and achieves nearly the some quality vs. rate performance
tradeoff. And it has been standardized already.

Christian


_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C67BBD8C4A91hsinnreiadobecom_-- From ron.even.tlv@gmail.com Thu Jul 9 13:41:14 2009 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 BE84B28C14F for ; Thu, 9 Jul 2009 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dibGfYlakOi for ; Thu, 9 Jul 2009 13:41:14 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id B124D3A6A11 for ; Thu, 9 Jul 2009 13:41:13 -0700 (PDT) Received: by bwz25 with SMTP id 25so446851bwz.37 for ; Thu, 09 Jul 2009 13:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=zlSiPp31bZhqLrHCwEyjJpn9pNy6ygBsMC46xWe7oyQ=; b=fKj2oH60bSt1IDWdrNlCButR1THYLgwxM9zeQQlJSPRpv12Xp2DBvOkwt+bwiDj06c JAoU1O6ddtZ7A60Dviz0/j2NV8kFhw/uJn33yCIiGh8nUJHhVFLLL2ecn8v+obuOE/I6 rJikxzx5p1p2sFE3YlwvvHH8vLbdH3QGxFxEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=TkldYKimf5sbYxD3zL/VOejBANFkLSNU8E3xnY5cTUWx7Xf/0M/FrsAHjbrfJ6V39V le0slPdoNDNNpFA+gqEdIisFja/t3mQORRuZTauexelSf4ZnZjFgrwYz4dsk+qXP3EEw uNBSGy+G10qXjPfJAZnarWtVmUkM0Pq1TiDmI= Received: by 10.103.6.14 with SMTP id j14mr660827mui.48.1247172097652; Thu, 09 Jul 2009 13:41:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id e10sm1402621muf.14.2009.07.09.13.41.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 13:41:36 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Slava Borilin'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> In-Reply-To: <4A56496D.4060807@octasic.com> Date: Thu, 9 Jul 2009 23:40:44 +0300 Message-ID: <4a565600.0ab6660a.1a5b.50ea@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoAzeABrjeRVTAORxGgG1IrSz7XPgABxmTg Content-Language: en-us Cc: 'Ingemar Johansson S' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:41:14 -0000 Jean-Marc, I do not think that by describing a codec you address the feasibility of the work. The feasibility of the work is to see what is the purpose of this group, what is the procedure for getting the work. The charter discussion should not be if time permit, this should be the objective of the BOF Please listen to the requests and take out item 4. This discussion is making people respond with concerns about the BOF chairs being biased. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, July 09, 2009 10:48 PM > To: Slava Borilin > Cc: Ingemar Johansson S; codec@ietf.org; stephen botzko > Subject: Re: [codec] Updated Agenda for Codec BOF > > Slava Borilin wrote: > > I agree with Stephen that it would be better to EXCLUDE #4 from > agenda - > > as this may be time consuming. > > Just to clarify. This part of the agenda is intended to address the > points > that were raised about the feasibility of the work. It will also show > what > requirements are achievable in a short time frame. The presentations > will > be short and high level, not technical descriptions of the codecs > internals. > > > Instead I would like to get back the item "requirements for codec, as > > they may look like from IETF perspective" (royalty-free, license-free > > from legal, + technical (packet loss, MOS, performance)). > > This should probably belong to the charter discussion, along with > discussion of the process if (I hope) time permits. > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Thu Jul 9 13:47:53 2009 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 560063A6D37 for ; Thu, 9 Jul 2009 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.806, 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 ZEZ8kg1sjGkC for ; Thu, 9 Jul 2009 13:47:52 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 361A73A6D41 for ; Thu, 9 Jul 2009 13:47:50 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n69KmFEE021483; Fri, 10 Jul 2009 00:48:15 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Jul 2009 00:48:07 +0400 Message-ID: In-Reply-To: <4a565600.0ab6660a.1a5b.50ea@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAzeABrjeRVTAORxGgG1IrSz7XPgABxmTgAABRHmA= References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <4a565600.0ab6660a.1a5b.50ea@mx.google.com> From: "Slava Borilin" To: "Roni Even" , "Jean-Marc Valin" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: Ingemar Johansson S , codec@ietf.org, stephen botzko Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:47:53 -0000 Its nothing about "being biased", really - but the time pressure to talk about=20 (at least from my perspective, I do not want to waste time to ensure that its feasible to create IP-codec, no need to make BoF to prove it, as I know for sure it is feasible already). So unless others want to get the evidence on this, I vote for removing the codec presentations for the sake of other discussions. Slava. -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Friday, July 10, 2009 12:41 AM To: 'Jean-Marc Valin'; Slava Borilin Cc: 'Ingemar Johansson S'; codec@ietf.org; 'stephen botzko' Subject: RE: [codec] Updated Agenda for Codec BOF Jean-Marc, I do not think that by describing a codec you address the feasibility of the work. The feasibility of the work is to see what is the purpose of this group, what is the procedure for getting the work. The charter discussion should not be if time permit, this should be the objective of the BOF Please listen to the requests and take out item 4. This discussion is making people respond with concerns about the BOF chairs being biased. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, July 09, 2009 10:48 PM > To: Slava Borilin > Cc: Ingemar Johansson S; codec@ietf.org; stephen botzko > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > Slava Borilin wrote: > > I agree with Stephen that it would be better to EXCLUDE #4 from > agenda - > > as this may be time consuming. >=20 > Just to clarify. This part of the agenda is intended to address the > points > that were raised about the feasibility of the work. It will also show > what > requirements are achievable in a short time frame. The presentations > will > be short and high level, not technical descriptions of the codecs > internals. >=20 > > Instead I would like to get back the item "requirements for codec, as > > they may look like from IETF perspective" (royalty-free, license-free > > from legal, + technical (packet loss, MOS, performance)). >=20 > This should probably belong to the charter discussion, along with > discussion of the process if (I hope) time permits. >=20 > Cheers, >=20 > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Thu Jul 9 13:49:16 2009 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 D08AE3A6D48 for ; Thu, 9 Jul 2009 13:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.776, 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 Tjgywk7z0kdO for ; Thu, 9 Jul 2009 13:49:15 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 0DF713A6D37 for ; Thu, 9 Jul 2009 13:48:44 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n69Kn9ZL021508; Fri, 10 Jul 2009 00:49:09 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA00D6.B10086F5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Jul 2009 00:49:01 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF agenda: Selection criteria and evaluation/testing Thread-Index: AcoADL6NDQYWlWNhYUCCNQajsOKOZgAT7O5gAB3oZhoAAKO9wA== References: <000601ca005d$078f70c0$16ae5240$@de> From: "Slava Borilin" To: "Henry Sinnreich" , "Christian Hoene" , "Jason Fischl" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec BOF agenda: Selection criteria and evaluation/testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:49:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA00D6.B10086F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do support all 3, or at least 1 and 2 =20 ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Friday, July 10, 2009 12:30 AM To: Christian Hoene; Jason Fischl; codec@ietf.org Subject: [codec] Codec BOF agenda: Selection criteria and evaluation/testing =20 Having the SBC as a 3rd candidate is good news, though I may have missed any email confirming it. Given the choice of several candidate codecs, would it make sense to add the following agenda items: 1. IETF policy of taking ownership and change control (by an A-D or IETF legal expert) 2. Selection criteria for the Internet voice codec 3. Testing and evaluation procedure Opinions? Thanks, Henry On 7/9/09 1:18 AM, "Christian Hoene" wrote: > 4. What type of engineering work would this be? ( 25 min ) > Have presentations on the two proposed codecs. Focus is to make sure it > looks feasible to do the technical > work to meet the goals. This should also help clarify what type of work is > being considered. > - http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt > - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt I just like to remind the chairs that their is a third proposed codec which will fulfill the assumed goals of this WG. SBC has a much lower complexity than CELT and achieves nearly the some quality vs. rate performance tradeoff. And it has been standardized already. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA00D6.B10086F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Codec BOF agenda: Selection criteria and = evaluation/testing

I do support all = 3, or at least 1 and 2

 =

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Friday, July 10, = 2009 12:30 AM
To: Christian Hoene; = Jason Fischl; codec@ietf.org
Subject: [codec] Codec = BOF agenda: Selection criteria and evaluation/testing

 

Having the SBC as a 3rd = candidate is good news, though I may have missed any email confirming it.

Given the choice of several candidate codecs, would it make sense to add = the following agenda items:

1. IETF policy of taking ownership and change control (by an A-D or IETF = legal expert)
2. Selection criteria for the Internet voice codec
3. Testing and evaluation procedure

Opinions?

Thanks, Henry


On 7/9/09 1:18 AM, "Christian Hoene" <hoene@uni-tuebingen.de> = wrote:

> 4. What type of = engineering work would this be? ( 25 min )
> Have presentations on the two proposed codecs. Focus is to make = sure it
> looks feasible to do the technical
> work to meet the goals. This should also help clarify what type of = work is
> being considered.
> - http:/= /www.ietf.org/internet-drafts/draft-vos-silk-00.txt
> - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt
I just like to remind the chairs that their is a third proposed codec = which
will fulfill the assumed goals of this WG. SBC has a much lower = complexity
than CELT and achieves nearly the some quality vs. rate performance
tradeoff. And it has been standardized already.

Christian


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

------_=_NextPart_001_01CA00D6.B10086F5-- From gmaxwell@juniper.net Thu Jul 9 14:17:26 2009 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 9E06E3A6923 for ; Thu, 9 Jul 2009 14:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 emgvQxkmvWXy for ; Thu, 9 Jul 2009 14:17:25 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 5DEE53A68DF for ; Thu, 9 Jul 2009 14:17:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSlZee0aay38Z+UmhKOmPn39HSp8g6Mne@postini.com; Thu, 09 Jul 2009 14:17:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 9 Jul 2009 14:16:12 -0700 From: Gregory Maxwell To: Slava Borilin , Jean-Marc Valin Date: Thu, 9 Jul 2009 14:16:12 -0700 Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAzeI5/aOADrcVS+mXMUoB+HxXfwAAIPWgAAH4/eQ= Message-ID: References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com>, 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ingemar Johansson S , "codec@ietf.org" , stephen botzko Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 21:17:26 -0000 Slava Borilin [Borilin@spiritdsp.com] wrote: > Do we really have to prove that it is feasible to create IP codec (while > some of them ALREADY EXISTS, like speex, CELT, IPMR, SILK)? > Or people need to be convinced how much time/efforts it might take to > create IP codec? Several people have argued that the IETF lacks the expertise required for c= odec development.=20 In fact the standing charter of the AVT working group states specifically "= the IETF does not have the ability to effectively review new codecs". It's been alleged that codec development is extremely difficult and entirel= y distinct from other kinds of protocol development. I don't believe this i= s a position many people who know much about codec internals would really a= gree with, but its easy to accept if you're used to treating codecs as blac= k boxes. It may be that this issue is now soundly dead, since other arguments have b= een advance more frequently as of late, but I don't see anything that has c= hanged in terms of expertise since that position has been advanced, so am n= ot certain that there is agreement on this point. Even if those opposed to the creation of this working group are willing to = concede that the available expertise is a non-issue we have participants wo= rking on codec development. It would be unreasonable to ask them to stop or= to stop cooperating simply because the IETF hasn't decided if it wants to = be involved in the effort yet and I think it's useful to people trying to d= ecide if they want to be involved to see what actually is involved. From stpeter@stpeter.im Thu Jul 9 14:46:23 2009 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 C734728C1CC for ; Thu, 9 Jul 2009 14:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 17FrnTSYFij8 for ; Thu, 9 Jul 2009 14:46:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A8F3A3A67FB for ; Thu, 9 Jul 2009 14:46:22 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2602F4007B for ; Thu, 9 Jul 2009 15:46:48 -0600 (MDT) Message-ID: <4A566547.6050402@stpeter.im> Date: Thu, 09 Jul 2009 15:46:47 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <4a565600.0ab6660a.1a5b.50ea@mx.google.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 21:46:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/9/09 2:48 PM, Slava Borilin wrote: > Its nothing about "being biased", really - Agreed. That kind of talk is unproductive. > but the time pressure to talk This is easily solved by having a well-run meeting. The chairs can *strictly* limit the time devoted to discussion about particular codecs. > about > (at least from my perspective, I do not want to waste time to ensure > that its feasible to create IP-codec, no need to make BoF to prove it, > as I know for sure it is feasible already). It's good that you know it is feasible, but others might not. :) > So unless others want to get the evidence on this, I vote for removing > the codec presentations for the sake of other discussions. If we place our trust in rough consensus and running code, then evidence is good, no? Some people seem to think that it is beyond the capabilities of the IETF to produce codecs. But it seems that we already have at least two existence proofs to the contrary, in the form of I-Ds submitted by active IETF contributors. Therefore I think it would be very helpful to discuss those existence proofs, albeit without getting into a long discussion about the merits of particular codecs (at least during the BoF!). Furthermore, discussion about particular codecs will help us ground the conversation in a way that abstract requirements will not. The longer-term challenge will be to avoid the fate of, say, the IMPP WG, which produced requirements documents but no protocols. If we can use the submitted I-Ds as input to the work of a Codec WG then we will already be quite far down the road to producing truly open codecs for the Internet. On a more personal note, I think that this work is extremely important. In the Jabber/XMPP community we have experienced first-hand the problems that arise when there is no one open codec that everyone can implement and deploy. Currently we recommend Speex for Jingle audio applications but it would be great to have more modern, Internet-friendly codecs going forward. Some say that only the ITU or some other SDO can get the job done. I say let's prove them wrong. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWZUYACgkQNL8k5A2w/vyJHQCZAZIF58Tn0UEWgFweX6M6euYI 2iYAn15Een2kidBl5rfc9wEMmezEhf9E =cdSp -----END PGP SIGNATURE----- From hoene@uni-tuebingen.de Thu Jul 9 15:31:31 2009 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 CA85328C2C7 for ; Thu, 9 Jul 2009 15:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 e+HDHtBR-XmE for ; Thu, 9 Jul 2009 15:31:30 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 2A0A428C2B0 for ; Thu, 9 Jul 2009 15:31:29 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-088-067-100-033.pools.arcor-ip.net [88.67.100.33]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n69MVdRp022707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jul 2009 00:31:54 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> In-Reply-To: <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> Date: Fri, 10 Jul 2009 00:31:35 +0200 Message-ID: <002a01ca00e5$0fbff6b0$2f3fe410$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoAxXQbIP57BLqSRbuxz74WL4EaWwAGcSwg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:31:31 -0000 Hello Stephen and all, thank you your very good statements on how to make this WG a success.=20 This mailing list has shown enough interest from various sides. The WG = will not die because of lack of interest. Also, beside internet guys also a sufficient number of =93open source=94 and =93traditional=94 coding = experts are participating in the discussions. I do not see a danger that this WG = will not be started. But I have to agree that I am missing somebody who plays the role of the moderator of the discussion. I just remember the talk with the chair of = a ITU Study Group 12 working group. He told me that he has an own proposal = but he cannot bring it into play because of his role as moderator. = Hopefully, some moderator can be found for this WG - with an own codec in his lab = or without it... I do not believe that a new codec standardization process should be invented. Having different requirements and excellent new codec designs should be enough innovations.=20 If so, what is the traditional process on codec standardization? Isn=92t = it something like this: 1.) Establishment of a set of working procedures=20 2.) Definition of requirements, objects (both including priorities), = quality parameters and procedures on how to measure these parameters. 3.) Developing codecs... 4.) Characterization and testing of the codec proposals.=20 5.) Selecting one, merging them or jump back to 2.) 6.) Standardization of the codec and definition of conformance tests. Both the ITU and 3GPP must have well defined procedures, which we should look at. Of course, they should be adopted only partly and carefully to = not hinder the goals of this WG. Regards, Christian ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Thursday, July 09, 2009 8:45 PM To: Ingemar Johansson S Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF Given the goal of the BOF, the aim is for a moderated discussion of the merits (pro and con).=A0 So I agree that it would be prudent to have = chairs who reflect the various views.=A0 It will make it easier to keep the = meeting orderly and moving, since no one will feel that the chairs shut them = down because they didn't agree with their views.=A0 "Success" here is not = measured by whether a WG is created (or not).=A0 "Success" is providing quality = input to the IESG on the merits from a broad range of participants. Please understand that I am not saying that I think Jean-Marc and Jason would be deliberately unfair. I am saying that we should anticipate a = lively discussion without clear consensus. So moderating it is likely to be challenging.=A0 Also, it will not be easy for Jean-Marc and Jason to = present their personal views while they are also acting as chairs.=A0 For these reasons, I think that if the chairs all hold one view, the BOF is = unlikely to be successful (using my definition above). As far as codecs go, I think there is some value in having a couple of sample submissions to look at.=A0 However, time will be valuable in the = BOF.=A0 I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing = them. Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The = proposed charter's output is a single codec, not multiple codecs.=A0 There would = need to be a common understanding of whether the working group is selecting a single codec from the candidates, or somehow developing a common codec = from more than one candidate.=A0 There would also need to be some consensus = on the basis for codec selection (and/or technology development), and some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision needed on the IPR rules.=A0=20 It will be very difficult to invent the process while we are = simultaneously talking about codec technology.=A0 I'd think the WG (if it goes forward) = would need to spend some time hammering out a working process before it will = be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, = and to the WG (when and if).. IMHO we ought to refrain from accusing people of "killing",=A0 There is nothing to kill at this point.=A0 Polarizing the debate by labeling the participants is not a constructive way to proceed.=A0 The genuine areas = of disagreement are hard enough. Stephen Botzko Polycom On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S wrote: Hi This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is not = done I fear that this BoF will just end up in a verbal fist-fight and nobody benefits from it, it will only make us all look like morons. Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of codecs = is secondary and can be discussed once/if a formation of the WG is decided. Personally I don't know what this "banned" stuff inserted by the server = is about... Regards Ingemar ________________________________ Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] Skickat: to 2009-07-09 16:22 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Updated Agenda for Codec BOF All these efforts to kill the free Internet voice codec before it is = even born! There must be a very big stake to do this... Henry On 7/9/09 8:43 AM, "Ingemar Johansson S" = > wrote: =A0 =A0 =A0 =A0WARNING: contains banned part _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Thu Jul 9 16:11:00 2009 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 9BA443A6B3D for ; Thu, 9 Jul 2009 16:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ALNPfr6tMNB7 for ; Thu, 9 Jul 2009 16:10:50 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 7CC5F3A6819 for ; Thu, 9 Jul 2009 16:10:49 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 333241-1743317 for multiple; Fri, 10 Jul 2009 01:11:15 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 09 Jul 2009 16:11:08 -0700 From: Stephan Wenger To: Slava Borilin , stephen botzko , Ingemar Johansson S Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAxW8/m/aQ36kCRN+pJLkBylx7eAAAym3AAAh8ZaI= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330000674_573463" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 23:11:00 -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_3330000674_573463 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, On 7/9/09 12:13 PM, "Slava Borilin" wrote: > I agree with Stephen that it would be better to EXCLUDE #4 from agenda =AD = as > this may be time consuming. > Instead I would like to get back the item =B3requirements for codec, as the= y may > look like from IETF perspective=B2 (royalty-free, license-free from legal, = + > technical (packet loss, MOS, performance)). >=20 I object in the strongest possible terms to the implied statement that a codec being =B3royalty-free and/or license-free from legal=B2 is a requirement from the IETF=B9s perspective. A statement like this, if it were correct (which it isn=B9t) may have legal implications that few, if any, of us here fully understand. Trust me on this (and/or ask your lawyer). I=B9m serious. Nowhere in the IETF=B9s legal framework there is a requirement for royalty-free designs, let alone unencumbered designs or designs relying exclusively on non-assert covenants. Nowhere in the IETF, except for the community consensus in certain, small, well-defined areas (such as baseline security), there is community consensus of such a requirement. Certainly, there is no community consensus on this list with respect to the codec issue. If you would have been writing something like =B3Requirement as viewed by the proponents of this BOF=B2, I would agree. If you would write =B3Desirable for the continued growth of Internet based multimedia communication=B2, I would agree. If you would write =B3Desirable from an IETF viewpoint=B2, I would agree. This is supported by policy language. If you would write, =B3Required for the future of the Internet=B2 I would disagree, but not object as noisily as in the statement you made. It=B9s abstract enough to be safe, as far as I can see. But please leave the IETF= , as an organization, out of this picture. In this discussion, we are touching the interface between engineering and legal. Let=B9s be careful; it=B9s easy to mess up things. Regards, Stephan >=20 > =20 > I do NOT think we (most of us) do not believe it=B9s feasible =AD so not much > point of discussing if its feasible to select good IP codec. Questions ar= e > criteria, and path to go (=3Dprocess). > =20 > Slava Borilin > =20 >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > stephen botzko > Sent: Thursday, July 09, 2009 10:45 PM > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > =20 > Given the goal of the BOF, the aim is for a moderated discussion of the m= erits > (pro and con). So I agree that it would be prudent to have chairs who ref= lect > the various views. It will make it easier to keep the meeting orderly an= d > moving, since no one will feel that the chairs shut them down because the= y > didn't agree with their views. "Success" here is not measured by whether= a WG > is created (or not). "Success" is providing quality input to the IESG on= the > merits from a broad range of participants. >=20 > Please understand that I am not saying that I think Jean-Marc and Jason w= ould > be deliberately unfair. I am saying that we should anticipate a lively > discussion without clear consensus. So moderating it is likely to be > challenging. Also, it will not be easy for Jean-Marc and Jason to presen= t > their personal views while they are also acting as chairs. For these rea= sons, > I think that if the chairs all hold one view, the BOF is unlikely to be > successful (using my definition above). >=20 > As far as codecs go, I think there is some value in having a couple of sa= mple > submissions to look at. However, time will be valuable in the BOF. I thi= nk we > should assume that the IESG will be able to assess the sample contributio= ns > without our needing to spend a lot of time discussing them. >=20 > Also, before anything can move forward there needs to be (a) a chartered > working group and (b) an established set of working procedures. The propo= sed > charter's output is a single codec, not multiple codecs. There would nee= d to > be a common understanding of whether the working group is selecting a sin= gle > codec from the candidates, or somehow developing a common codec from more= than > one candidate. There would also need to be some consensus on the basis f= or > codec selection (and/or technology development), and some consensus on ho= w to > measure the codec performance against the various requirements, and of co= urse > at some point there will be more precision needed on the IPR rules. >=20 > It will be very difficult to invent the process while we are simultaneous= ly > talking about codec technology. I'd think the WG (if it goes forward) wo= uld > need to spend some time hammering out a working process before it will be > ready to accept candidates for consideration. Perhaps some more focused > discussion on these points ahead of time would be helpful to the IESG, an= d to > the WG (when and if).. >=20 > IMHO we ought to refrain from accusing people of "killing", There is noth= ing > to kill at this point. Polarizing the debate by labeling the participant= s is > not a constructive way to proceed. The genuine areas of disagreement are= hard > enough. >=20 > Stephen Botzko > Polycom >=20 > On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S > wrote: > Hi >=20 > This is yet another reason why I think it is best to select chairs for th= is > who reflect the different opinions around this subject. If this is not do= ne I > fear that this BoF will just end up in a verbal fist-fight and nobody ben= efits > from it, it will only make us all look like morons. >=20 > Also I am not trying to kill any codec, I just don't see how it fits in t= he > IETF, thats why I wish to have all issues discussed. Selection of codecs = is > secondary and can be discussed once/if a formation of the WG is decided. >=20 > Personally I don't know what this "banned" stuff inserted by the server i= s > about... >=20 > Regards > Ingemar >=20 > ________________________________ >=20 > Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Skickat: to 2009-07-09 16:22 > Till: Ingemar Johansson S; codec@ietf.org > =C4mne: Re: [codec] Updated Agenda for Codec BOF >=20 >=20 >=20 > All these efforts to kill the free Internet voice codec before it is even > born! >=20 > There must be a very big stake to do this... >=20 > Henry >=20 > On 7/9/09 8:43 AM, "Ingemar Johansson S" > wrote: >=20 >=20 >=20 > WARNING: contains banned part >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3330000674_573463 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Updated Agenda for Codec BOF Hi,

On 7/9/09 12:13 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

I agree with Stephen that it would be be= tter to EXCLUDE #4 from agenda – as this may be time consuming.
Instead I would like to get back the item “requirements for codec, as= they may look like from IETF perspective” (royalty-free, license-free= from legal, + technical (packet loss, MOS, performance)).

= I object in the strongest possible terms to the= implied statement that a codec being “royalty-free and/or license-fre= e from legal” is a requirement from the IETF’s perspective. &nbs= p;A statement like this, if it were correct (which it isn’t) may have = legal implications that few, if any, of us here fully understand.  Trus= t me on this (and/or ask your lawyer).  I’m serious.  

Nowhere in the IETF’s legal framework there is a requirement for roya= lty-free designs, let alone unencumbered designs or designs relying exclusiv= ely on non-assert covenants.  Nowhere in the IETF, except for the commu= nity consensus in certain, small, well-defined areas (such as baseline secur= ity), there is community consensus of such a requirement.  Certainly, t= here is no community consensus on this list with respect to the codec issue.=

If you would have been writing something like “Requirement as viewed = by the proponents of this BOF”, I would agree.
If you would write “Desirable for the continued growth of Internet ba= sed multimedia communication”, I would agree.
If you would write “Desirable from an IETF viewpoint”, I would = agree.  This is supported by policy language.
If you would write, “Required for the future of the Internet” I= would disagree, but not object as noisily as in the statement you made. &nb= sp;It’s abstract enough to be safe, as far as I can see.  But ple= ase leave the IETF, as an organization, out of this picture.

In this discussion, we are touching the interface between engineering and l= egal.  Let’s be careful; it’s easy to mess up things.

Regards,
Stephan


I do NOT think we (most of us) do not believe it’s feasible – s= o not much point of discussing if its feasible to select good IP codec. Ques= tions are criteria, and path to go (=3Dprocess).
 
Slava Borilin
 

From: codec-bounces@= ietf.org [mailto:codec-bounces@i= etf.org] On Behalf Of stephen botzko
Sent: Thursday, July 09, 2009 10:45 PM
To: Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF
Given the goal of the BOF, the aim is for a moderated discussion of the mer= its (pro and con). So I agree that it would be prudent to have chairs who re= flect the various views.  It will make it easier to keep the meeting or= derly and moving, since no one will feel that the chairs shut them down beca= use they didn't agree with their views.  "Success" here is no= t measured by whether a WG is created (or not).  "Success" is= providing quality input to the IESG on the merits from a broad range of par= ticipants.

Please understand that I am not saying that I think Jean-Marc and Ja= son would be deliberately unfair. I am saying that we should a= nticipate a lively discussion without clear consensus. So moderating it is l= ikely to be challenging.  Also, it will not be easy for Jean-Marc and J= ason to present their personal views while they are also acting as chairs. &= nbsp;For these reasons, I think that if the chairs all hold one view, the BO= F is unlikely to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of samp= le submissions to look at.  However, time will be valuable in the BOF. = I think we should assume that the IESG will be able to assess the sample con= tributions without our needing to spend a lot of time discussing them.

Also, before anything can move forward there needs to be (a) a chartered wo= rking group and (b) an established set of working procedures. The proposed c= harter's output is a single codec, not multiple codecs.  There would ne= ed to be a common understanding of whether the working group is selecting= a single codec from the candidates, or somehow developing a comm= on codec from more than one candidate.  There would also need to be som= e consensus on the basis for codec selection (and/or technology development)= , and some consensus on how to measure the codec performance against the var= ious requirements, and of course at some point there will be more precision = needed on the IPR rules.  

It will be very difficult to invent the process while we are simultaneously= talking about codec technology.  I'd think the WG (if it goes forward)= would need to spend some time hammering out a working process before it wil= l be ready to accept candidates for consideration. Perhaps some more focused= discussion on these points ahead of time would be helpful to the IESG, and = to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing", There= is nothing to kill at this point.  Polarizing the debate by labeling t= he participants is not a constructive way to proceed.  The genuine area= s of disagreement are hard enough.

Stephen Botzko
Polycom

On = Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

This is yet another reason why I think it is best to select chairs for this= who reflect the different opinions around this subject. If this is not done= I fear that this BoF will just end up in a verbal fist-fight and nobody ben= efits from it, it will only make us all look like morons.

Also I am not trying to kill any codec, I just don't see how it fits in the= IETF, thats why I wish to have all issues discussed. Selection of codecs is= secondary and can be discussed once/if a formation of the WG is decided.
Personally I don't know what this "banned" stuff inserted by the = server is about...

Regards
Ingemar

________________________________

Från: Henry Sinnreich [mailto:hsi= nnrei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org
Ämne: Re: [codec] Updated Agenda for Codec BOF
All these efforts to kill the free Internet voice codec before it is even b= orn!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com <https://rvi.se.ericsso= n.net/dana-cached/help/empty.html> > wrote:



       WARNING: contains banned part


_______________________________________________
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
--B_3330000674_573463-- From dbogdanovic@counterpath.com Thu Jul 9 21:19:48 2009 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 D32B13A6CAF for ; Thu, 9 Jul 2009 21:19:48 -0700 (PDT) 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 dNrOWTI5uCo5 for ; Thu, 9 Jul 2009 21:19:48 -0700 (PDT) Received: from relay.ihostexchange.net (relay.ihostexchange.net [66.46.182.54]) by core3.amsl.com (Postfix) with ESMTP id E462D3A6932 for ; Thu, 9 Jul 2009 21:19:47 -0700 (PDT) Received: from [192.168.2.19] (24.218.221.216) by smtp.ihostexchange.net (66.46.182.50) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 10 Jul 2009 00:20:14 -0400 Message-ID: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> From: Dean Bogdanovic To: codec@ietf.org Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 00:20:14 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 04:54:44 -0000 After reading discussions on this topic, thought to add customer view on this one. In the last 12 month, I've participated in several customer projects in Asia, Africa and Europe. All of them were trying to add voip over their 3G data networks as service and were looking for low-latency royalty free codec. Two of the projects were interesting, as different carriers connected their voip networks and allowed traffic between voip UAs directly (no PSTN interconnect). The biggest problem ended up being codec, as the results of testing with different royalty free codecs weren't satisfying. In general, carrier groups are looking to use IP as primary communication mechanism among their group members and for them royalty free, adaptive/low latency is really important, as (Asia, Africa and part of Europe) their subs have low ARPU and many of them are traveling for work outside of their home countries. So you have carrier groups covering all those countries, but they don't have an (cheap) option to provide affordable service to their customers. this is commercial view why work of this BOF (and creation of WG) is valuable. It would be nice some positive results coming from this Dean From hoene@uni-tuebingen.de Thu Jul 9 21:54:55 2009 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 33E293A687F for ; Thu, 9 Jul 2009 21:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WE1gAnp4onT for ; Thu, 9 Jul 2009 21:54:45 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 72FC03A68FE for ; Thu, 9 Jul 2009 21:54:35 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-092-074-174-185.pools.arcor-ip.net [92.74.174.185]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6A4sqaZ008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jul 2009 06:54:58 +0200 From: "Christian Hoene" To: "'Stephan Wenger'" , "'Jean-Marc Valin'" , "'Jason Fischl'" References: In-Reply-To: Date: Fri, 10 Jul 2009 06:54:52 +0200 Message-ID: <003a01ca011a$94123880$bc36a980$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01CA012B.579B0880" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoAxW8/m/aQ36kCRN+pJLkBylx7eAAAym3AAAh8ZaIAC6a6AA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 04:54:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01CA012B.579B0880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good morning Slava and all, =20 to my understanding it is commonly understood on this mailing list that nobody can guaranty a codec to be royalty-free and license-free. But I = have to agree that the wording have to be selected carefully. We shall avoid = the impression, that royalty-free or license-free is a promised feature of = the codec. =20 BTW: Is someone collecting the arguments on this mailing list? =20 Maybe the chairs can request a Wiki/ Trac web page, which can be used as = a collaborative platform to collect the results of the discussions and the numerous contributions regarding the wording of requirements? =20 Thank you very much =20 Christian =20 =20 =20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Stephan Wenger Sent: Friday, July 10, 2009 1:11 AM To: Slava Borilin; stephen botzko; Ingemar Johansson S Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF =20 Hi, On 7/9/09 12:13 PM, "Slava Borilin" wrote: I agree with Stephen that it would be better to EXCLUDE #4 from agenda = =96 as this may be time consuming. Instead I would like to get back the item =93requirements for codec, as = they may look like from IETF perspective=94 (royalty-free, license-free from = legal, + technical (packet loss, MOS, performance)). I object in the strongest possible terms to the implied statement that a codec being =93royalty-free and/or license-free from legal=94 is a = requirement from the IETF=92s perspective. A statement like this, if it were = correct (which it isn=92t) may have legal implications that few, if any, of us = here fully understand. Trust me on this (and/or ask your lawyer). I=92m = serious. Nowhere in the IETF=92s legal framework there is a requirement for royalty-free designs, let alone unencumbered designs or designs relying exclusively on non-assert covenants. Nowhere in the IETF, except for = the community consensus in certain, small, well-defined areas (such as = baseline security), there is community consensus of such a requirement. = Certainly, there is no community consensus on this list with respect to the codec issue. If you would have been writing something like =93Requirement as viewed = by the proponents of this BOF=94, I would agree.=20 If you would write =93Desirable for the continued growth of Internet = based multimedia communication=94, I would agree.=20 If you would write =93Desirable from an IETF viewpoint=94, I would = agree. This is supported by policy language. If you would write, =93Required for the future of the Internet=94 I = would disagree, but not object as noisily as in the statement you made. = It=92s abstract enough to be safe, as far as I can see. But please leave the = IETF, as an organization, out of this picture. In this discussion, we are touching the interface between engineering = and legal. Let=92s be careful; it=92s easy to mess up things. Regards, Stephan I do NOT think we (most of us) do not believe it=92s feasible =96 so not = much point of discussing if its feasible to select good IP codec. Questions = are criteria, and path to go (=3Dprocess). =20 Slava Borilin =20 _____ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Thursday, July 09, 2009 10:45 PM To: Ingemar Johansson S Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF Given the goal of the BOF, the aim is for a moderated discussion of the merits (pro and con). So I agree that it would be prudent to have chairs = who reflect the various views. It will make it easier to keep the meeting orderly and moving, since no one will feel that the chairs shut them = down because they didn't agree with their views. "Success" here is not = measured by whether a WG is created (or not). "Success" is providing quality = input to the IESG on the merits from a broad range of participants. Please understand that I am not saying that I think Jean-Marc and Jason would be deliberately unfair. I am saying that we should anticipate a = lively discussion without clear consensus. So moderating it is likely to be challenging. Also, it will not be easy for Jean-Marc and Jason to = present their personal views while they are also acting as chairs. For these reasons, I think that if the chairs all hold one view, the BOF is = unlikely to be successful (using my definition above). As far as codecs go, I think there is some value in having a couple of sample submissions to look at. However, time will be valuable in the = BOF. I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing = them. Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The = proposed charter's output is a single codec, not multiple codecs. There would = need to be a common understanding of whether the working group is selecting a single codec from the candidates, or somehow developing a common codec = from more than one candidate. There would also need to be some consensus on = the basis for codec selection (and/or technology development), and some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision needed on the IPR rules. =20 It will be very difficult to invent the process while we are = simultaneously talking about codec technology. I'd think the WG (if it goes forward) = would need to spend some time hammering out a working process before it will = be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, = and to the WG (when and if).. IMHO we ought to refrain from accusing people of "killing", There is = nothing to kill at this point. Polarizing the debate by labeling the = participants is not a constructive way to proceed. The genuine areas of disagreement = are hard enough. Stephen Botzko Polycom On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S wrote: Hi This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is not = done I fear that this BoF will just end up in a verbal fist-fight and nobody benefits from it, it will only make us all look like morons. Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of codecs = is secondary and can be discussed once/if a formation of the WG is decided. Personally I don't know what this "banned" stuff inserted by the server = is about... Regards Ingemar ________________________________ Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] Skickat: to 2009-07-09 16:22 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Updated Agenda for Codec BOF All these efforts to kill the free Internet voice codec before it is = even born! There must be a very big stake to do this... Henry On 7/9/09 8:43 AM, "Ingemar Johansson S" = > wrote: WARNING: contains banned part _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 _____ =20 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_003B_01CA012B.579B0880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Updated Agenda for Codec BOF

Good morning Slava and all,

 

to my understanding it is commonly understood on this = mailing list that nobody can guaranty a codec to be royalty-free and = license-free. But I have to agree that the wording have to be selected carefully. We shall = avoid the impression, that royalty-free or license-free is a promised feature = of the codec.

 

BTW: Is someone collecting the arguments on this mailing = list?

 

Maybe the chairs can request a Wiki/ Trac web page, which = can be used as a collaborative platform to collect the results of the = discussions and the numerous contributions regarding the wording of = requirements?

 

Thank you very much

 

=A0Christian

 

 

 

-------------------------------------------------------- Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532

http://www.net.uni-tuebingen.de/

 

From:= = codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, July 10, 2009 1:11 AM
To: Slava Borilin; stephen botzko; Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec = BOF

 

Hi,

On 7/9/09 12:13 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

I agree with Stephen that = it would be better to EXCLUDE #4 from agenda – as this may be time = consuming.
Instead I would like to get back the item “requirements for codec, = as they may look like from IETF perspective” (royalty-free, license-free = from legal, + technical (packet loss, MOS, = performance)).

I object in the strongest possible = terms to the implied statement that a codec being “royalty-free and/or license-free from legal” is a requirement from the IETF’s perspective.  A statement like this, if it were correct (which it isn’t) may have legal implications that few, if any, of us here = fully understand.  Trust me on this (and/or ask your lawyer). =  I’m serious.  

Nowhere in the IETF’s legal framework there is a requirement for royalty-free designs, let alone unencumbered designs or designs relying exclusively on non-assert covenants.  Nowhere in the IETF, except = for the community consensus in certain, small, well-defined areas (such as = baseline security), there is community consensus of such a requirement. =  Certainly, there is no community consensus on this list with respect to the codec = issue.

If you would have been writing something like “Requirement as = viewed by the proponents of this BOF”, I would agree.
If you would write “Desirable for the continued growth of Internet = based multimedia communication”, I would agree.
If you would write “Desirable from an IETF viewpoint”, I = would agree.  This is supported by policy language.
If you would write, “Required for the future of the = Internet” I would disagree, but not object as noisily as in the statement you made.  It’s abstract enough to be safe, as far as I can see. =  But please leave the IETF, as an organization, out of this picture.

In this discussion, we are touching the interface between engineering = and legal.  Let’s be careful; it’s easy to mess up = things.

Regards,
Stephan


I do NOT think we (most of us) do not believe it’s feasible = – so not much point of discussing if its feasible to select good IP codec. = Questions are criteria, and path to go (=3Dprocess).
 
Slava Borilin
 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of stephen botzko
Sent: Thursday, July 09, 2009 10:45 PM
To: Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF

Given the goal of the BOF, the aim is for a moderated discussion of the = merits (pro and con). So I agree that it would be prudent to have chairs who = reflect the various views.  It will make it easier to keep the meeting = orderly and moving, since no one will feel that the chairs shut them down because = they didn't agree with their views.  "Success" here is not = measured by whether a WG is created (or not).  "Success" is = providing quality input to the IESG on the merits from a broad range of = participants.

Please understand that I am not saying that I think Jean-Marc and = Jason would be deliberately unfair. I am saying that we should anticipate a = lively discussion without clear consensus. So moderating it is likely to be challenging.  Also, it will not be easy for Jean-Marc and Jason to = present their personal views while they are also acting as chairs.  For = these reasons, I think that if the chairs all hold one view, the BOF is = unlikely to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of = sample submissions to look at.  However, time will be valuable in the BOF. = I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing = them.

Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The = proposed charter's output is a single codec, not multiple codecs.  There = would need to be a common understanding of whether the working group is = selecting a single codec from the candidates, or somehow developing a common = codec from more than one candidate.  There would also need to be some = consensus on the basis for codec selection (and/or technology development), and = some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision = needed on the IPR rules.  

It will be very difficult to invent the process while we are = simultaneously talking about codec technology.  I'd think the WG (if it goes = forward) would need to spend some time hammering out a working process before it = will be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, = and to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing", = There is nothing to kill at this point.  Polarizing the debate by labeling = the participants is not a constructive way to proceed.  The genuine = areas of disagreement are hard enough.

Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.co= m> wrote:
Hi

This is yet another reason why I think it is best to select chairs for = this who reflect the different opinions around this subject. If this is not done = I fear that this BoF will just end up in a verbal fist-fight and nobody = benefits from it, it will only make us all look like morons.

Also I am not trying to kill any codec, I just don't see how it fits in = the IETF, thats why I wish to have all issues discussed. Selection of codecs = is secondary and can be discussed once/if a formation of the WG is = decided.

Personally I don't know what this "banned" stuff inserted by = the server is about...

Regards
Ingemar

________________________________

Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org
=C4mne: Re: [codec] Updated Agenda for Codec BOF



All these efforts to kill the free Internet voice codec before it is = even born!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.co= m <https://= rvi.se.ericsson.net/dana-cached/help/empty.html> > wrote:



       WARNING: contains banned = part


_______________________________________________
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

------=_NextPart_000_003B_01CA012B.579B0880-- From Borilin@spiritdsp.com Thu Jul 9 22:11:13 2009 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 4BAA03A6C98 for ; Thu, 9 Jul 2009 22:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 KhqJnYjf5x-l for ; Thu, 9 Jul 2009 22:11:11 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 277B93A6ABA for ; Thu, 9 Jul 2009 22:11:09 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6A5BYKc029132; Fri, 10 Jul 2009 09:11:34 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA011C.E158814D" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Jul 2009 09:11:26 +0400 Message-ID: In-Reply-To: <003a01ca011a$94123880$bc36a980$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAxW8/m/aQ36kCRN+pJLkBylx7eAAAym3AAAh8ZaIAC6a6AAAAp5VQ References: <003a01ca011a$94123880$bc36a980$@de> From: "Slava Borilin" To: "Christian Hoene" , "Stephan Wenger" , "Jean-Marc Valin" , "Jason Fischl" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:11:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA011C.E158814D Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3RlcGhhbiwgQ2hyaXN0aWFuLA0KDQogDQoNCldlIGFyZSBpbiBhZ3JlZW1lbnQg4oCTIHJveWFs dHktZnJlZSBhbmQgbGljZW5zZS1mcmVlIGlzIHNlZW4gYXMgbm90IOKAnGxlZ2FsbHkgYmluZGlu ZyByZXF1aXJlbWVudHPigJ0uIEkgcHV0IOKAnGxlZ2Fs4oCdIGp1c3QgdG8gbmFtZSBzdWNoIGdy b3VwIG9mIHJlcXVpcmVtZW50cyBhbmQgc2VwYXJhdGUgdGhlbSBmcm9tIG90aGVyIChwZXJmb3Jt YW5jZSkgcmVxdWlyZW1lbnRzLg0KDQpJIGFtIG5vdCB0cnlpbmcgdG8gZ2V0IGFueSBndWFyYW50 aWVzLCBzcGVjaWZpY2FsbHkgaW4gdGhlIGFyZWEgb2YgSVBSLCBzbyBkZWZpbml0ZWx5IOKAnGRl c2lyYWJsZeKAnSBpcyBwcm9wZXIgd29yZCwgbm90IOKAnHJlcXVpcmVk4oCdIOKAk2FzIHdlIGhh dmUgbm8gbWVhbnMgdG8gdmVyaWZ5IDEwMCUgd2hldGhlciB3ZSBhY2hpZXZlZCB0aGUgZ29hbCBv ZiBiZWluZyByb3lhbHR5LWZyZWUsIGxpY2Vuc2UtZnJlZSwgb3Igbm90LiBBbmQgYXQgdGhpcyBz dGFnZSBhZnRlciBjb2RlYyBpcyBkb25lLCB3ZSBjYW4gb25seSBiZWxpZXZlIG1vcmUgb3IgbGVz cyB0aGF0IGl0IGlzIHJveWFsdHktZnJlZSwgcGF0ZW50LWZyZWUuDQoNCiANCg0KQWxzbywgd2hl biBJIHNheSDigJxsaWNlbnNlLWZyZWXigJ0gSSBkbyBub3QgbWVhbiDigJxwYXRlbnQtZnJlZeKA nSwgYnV0IOKAnGZyZWUgZnJvbSB0aGUgbmVlZCB0byBzaWduIGxpY2Vuc2luZyBhZ3JlZW1lbnQo cykgYmVmb3JlIHVzZeKAnS4NCg0KPSB0aGUgYWJpbGl0eSBmb3IgYW55IHVzZXIgdG8gZ2V0IHRo ZSBjb2RlYyBhbmQgdXNlIGl0IHdpdGhvdXQgc2lnbmluZyBhbnkgcGFwZXJ3b3JrIOKAkyB0aGlz IHdhcyBkaXNjdXNzZWQgYmVmb3JlIG9uINGA0LXRgyBsaXN0LCBhbmQgSmVhbi1NYXJjIG1hZGUg YSBzdHJvbmcgcG9pbnQgd2hpY2ggSSBzaGFyZS4NCg0KIA0KDQpTbGF2YSBCb3JpbGluDQoNCiAN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogY29kZWMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBD aHJpc3RpYW4gSG9lbmUNClNlbnQ6IEZyaWRheSwgSnVseSAxMCwgMjAwOSA4OjU1IEFNDQpUbzog J1N0ZXBoYW4gV2VuZ2VyJzsgJ0plYW4tTWFyYyBWYWxpbic7ICdKYXNvbiBGaXNjaGwnDQpDYzog Y29kZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29kZWNdIFVwZGF0ZWQgQWdlbmRhIGZvciBD b2RlYyBCT0YNCg0KIA0KDQpHb29kIG1vcm5pbmcgU2xhdmEgYW5kIGFsbCwNCg0KIA0KDQp0byBt eSB1bmRlcnN0YW5kaW5nIGl0IGlzIGNvbW1vbmx5IHVuZGVyc3Rvb2Qgb24gdGhpcyBtYWlsaW5n IGxpc3QgdGhhdCBub2JvZHkgY2FuIGd1YXJhbnR5IGEgY29kZWMgdG8gYmUgcm95YWx0eS1mcmVl IGFuZCBsaWNlbnNlLWZyZWUuIEJ1dCBJIGhhdmUgdG8gYWdyZWUgdGhhdCB0aGUgd29yZGluZyBo YXZlIHRvIGJlIHNlbGVjdGVkIGNhcmVmdWxseS4gV2Ugc2hhbGwgYXZvaWQgdGhlIGltcHJlc3Np b24sIHRoYXQgcm95YWx0eS1mcmVlIG9yIGxpY2Vuc2UtZnJlZSBpcyBhIHByb21pc2VkIGZlYXR1 cmUgb2YgdGhlIGNvZGVjLg0KDQogDQoNCkJUVzogSXMgc29tZW9uZSBjb2xsZWN0aW5nIHRoZSBh cmd1bWVudHMgb24gdGhpcyBtYWlsaW5nIGxpc3Q/DQoNCiANCg0KTWF5YmUgdGhlIGNoYWlycyBj YW4gcmVxdWVzdCBhIFdpa2kvIFRyYWMgd2ViIHBhZ2UsIHdoaWNoIGNhbiBiZSB1c2VkIGFzIGEg Y29sbGFib3JhdGl2ZSBwbGF0Zm9ybSB0byBjb2xsZWN0IHRoZSByZXN1bHRzIG9mIHRoZSBkaXNj dXNzaW9ucyBhbmQgdGhlIG51bWVyb3VzIGNvbnRyaWJ1dGlvbnMgcmVnYXJkaW5nIHRoZSB3b3Jk aW5nIG9mIHJlcXVpcmVtZW50cz8NCg0KIA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoDQoNCiANCg0K IENocmlzdGlhbg0KDQogDQoNCiANCg0KIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRHIuLUluZy4gQ2hyaXN0aWFuIEhvZW5lDQpJ bnRlcmFjdGl2ZSBDb21tdW5pY2F0aW9uIFN5c3RlbXMgKElDUyksIFVuaXZlcnNpdHkgb2YgVMO8 YmluZ2VuDQpTYW5kIDEzLCA3MjA3NiBUw7xiaW5nZW4sIEdlcm1hbnksIFBob25lICs0OSA3MDcx IDI5NzA1MzINCg0KaHR0cDovL3d3dy5uZXQudW5pLXR1ZWJpbmdlbi5kZS8gPGh0dHA6Ly93d3cu bmV0LnVuaS10dWViaW5nZW4uZGUvPiANCg0KIA0KDQpGcm9tOiBjb2RlYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86Y29kZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoYW4g V2VuZ2VyDQpTZW50OiBGcmlkYXksIEp1bHkgMTAsIDIwMDkgMToxMSBBTQ0KVG86IFNsYXZhIEJv cmlsaW47IHN0ZXBoZW4gYm90emtvOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQpDYzogY29kZWNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29kZWNdIFVwZGF0ZWQgQWdlbmRhIGZvciBDb2RlYyBCT0YN Cg0KIA0KDQpIaSwNCg0KT24gNy85LzA5IDEyOjEzIFBNLCAiU2xhdmEgQm9yaWxpbiIgPEJvcmls aW5Ac3Bpcml0ZHNwLmNvbT4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBTdGVwaGVuIHRoYXQgaXQg d291bGQgYmUgYmV0dGVyIHRvIEVYQ0xVREUgIzQgZnJvbSBhZ2VuZGEg4oCTIGFzIHRoaXMgbWF5 IGJlIHRpbWUgY29uc3VtaW5nLg0KSW5zdGVhZCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGJhY2sgdGhl IGl0ZW0g4oCccmVxdWlyZW1lbnRzIGZvciBjb2RlYywgYXMgdGhleSBtYXkgbG9vayBsaWtlIGZy b20gSUVURiBwZXJzcGVjdGl2ZeKAnSAocm95YWx0eS1mcmVlLCBsaWNlbnNlLWZyZWUgZnJvbSBs ZWdhbCwgKyB0ZWNobmljYWwgKHBhY2tldCBsb3NzLCBNT1MsIHBlcmZvcm1hbmNlKSkuDQoNCkkg b2JqZWN0IGluIHRoZSBzdHJvbmdlc3QgcG9zc2libGUgdGVybXMgdG8gdGhlIGltcGxpZWQgc3Rh dGVtZW50IHRoYXQgYSBjb2RlYyBiZWluZyDigJxyb3lhbHR5LWZyZWUgYW5kL29yIGxpY2Vuc2Ut ZnJlZSBmcm9tIGxlZ2Fs4oCdIGlzIGEgcmVxdWlyZW1lbnQgZnJvbSB0aGUgSUVURuKAmXMgcGVy c3BlY3RpdmUuICBBIHN0YXRlbWVudCBsaWtlIHRoaXMsIGlmIGl0IHdlcmUgY29ycmVjdCAod2hp Y2ggaXQgaXNu4oCZdCkgbWF5IGhhdmUgbGVnYWwgaW1wbGljYXRpb25zIHRoYXQgZmV3LCBpZiBh bnksIG9mIHVzIGhlcmUgZnVsbHkgdW5kZXJzdGFuZC4gIFRydXN0IG1lIG9uIHRoaXMgKGFuZC9v ciBhc2sgeW91ciBsYXd5ZXIpLiAgSeKAmW0gc2VyaW91cy4gIA0KDQpOb3doZXJlIGluIHRoZSBJ RVRG4oCZcyBsZWdhbCBmcmFtZXdvcmsgdGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3Igcm95YWx0 eS1mcmVlIGRlc2lnbnMsIGxldCBhbG9uZSB1bmVuY3VtYmVyZWQgZGVzaWducyBvciBkZXNpZ25z IHJlbHlpbmcgZXhjbHVzaXZlbHkgb24gbm9uLWFzc2VydCBjb3ZlbmFudHMuICBOb3doZXJlIGlu IHRoZSBJRVRGLCBleGNlcHQgZm9yIHRoZSBjb21tdW5pdHkgY29uc2Vuc3VzIGluIGNlcnRhaW4s IHNtYWxsLCB3ZWxsLWRlZmluZWQgYXJlYXMgKHN1Y2ggYXMgYmFzZWxpbmUgc2VjdXJpdHkpLCB0 aGVyZSBpcyBjb21tdW5pdHkgY29uc2Vuc3VzIG9mIHN1Y2ggYSByZXF1aXJlbWVudC4gIENlcnRh aW5seSwgdGhlcmUgaXMgbm8gY29tbXVuaXR5IGNvbnNlbnN1cyBvbiB0aGlzIGxpc3Qgd2l0aCBy ZXNwZWN0IHRvIHRoZSBjb2RlYyBpc3N1ZS4NCg0KSWYgeW91IHdvdWxkIGhhdmUgYmVlbiB3cml0 aW5nIHNvbWV0aGluZyBsaWtlIOKAnFJlcXVpcmVtZW50IGFzIHZpZXdlZCBieSB0aGUgcHJvcG9u ZW50cyBvZiB0aGlzIEJPRuKAnSwgSSB3b3VsZCBhZ3JlZS4gDQpJZiB5b3Ugd291bGQgd3JpdGUg 4oCcRGVzaXJhYmxlIGZvciB0aGUgY29udGludWVkIGdyb3d0aCBvZiBJbnRlcm5ldCBiYXNlZCBt dWx0aW1lZGlhIGNvbW11bmljYXRpb27igJ0sIEkgd291bGQgYWdyZWUuIA0KSWYgeW91IHdvdWxk IHdyaXRlIOKAnERlc2lyYWJsZSBmcm9tIGFuIElFVEYgdmlld3BvaW504oCdLCBJIHdvdWxkIGFn cmVlLiAgVGhpcyBpcyBzdXBwb3J0ZWQgYnkgcG9saWN5IGxhbmd1YWdlLg0KSWYgeW91IHdvdWxk IHdyaXRlLCDigJxSZXF1aXJlZCBmb3IgdGhlIGZ1dHVyZSBvZiB0aGUgSW50ZXJuZXTigJ0gSSB3 b3VsZCBkaXNhZ3JlZSwgYnV0IG5vdCBvYmplY3QgYXMgbm9pc2lseSBhcyBpbiB0aGUgc3RhdGVt ZW50IHlvdSBtYWRlLiAgSXTigJlzIGFic3RyYWN0IGVub3VnaCB0byBiZSBzYWZlLCBhcyBmYXIg YXMgSSBjYW4gc2VlLiAgQnV0IHBsZWFzZSBsZWF2ZSB0aGUgSUVURiwgYXMgYW4gb3JnYW5pemF0 aW9uLCBvdXQgb2YgdGhpcyBwaWN0dXJlLg0KDQpJbiB0aGlzIGRpc2N1c3Npb24sIHdlIGFyZSB0 b3VjaGluZyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gZW5naW5lZXJpbmcgYW5kIGxlZ2FsLiAgTGV0 4oCZcyBiZSBjYXJlZnVsOyBpdOKAmXMgZWFzeSB0byBtZXNzIHVwIHRoaW5ncy4NCg0KUmVnYXJk cywNClN0ZXBoYW4NCg0KDQoNCkkgZG8gTk9UIHRoaW5rIHdlIChtb3N0IG9mIHVzKSBkbyBub3Qg YmVsaWV2ZSBpdOKAmXMgZmVhc2libGUg4oCTIHNvIG5vdCBtdWNoIHBvaW50IG9mIGRpc2N1c3Np bmcgaWYgaXRzIGZlYXNpYmxlIHRvIHNlbGVjdCBnb29kIElQIGNvZGVjLiBRdWVzdGlvbnMgYXJl IGNyaXRlcmlhLCBhbmQgcGF0aCB0byBnbyAoPXByb2Nlc3MpLg0KIA0KU2xhdmEgQm9yaWxpbg0K IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBjb2RlYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y29kZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IHN0ZXBoZW4gYm90emtvDQpTZW50OiBUaHVyc2RheSwgSnVseSAwOSwgMjAwOSAxMDo0NSBQTQ0K VG86IEluZ2VtYXIgSm9oYW5zc29uIFMNCkNjOiBjb2RlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtjb2RlY10gVXBkYXRlZCBBZ2VuZGEgZm9yIENvZGVjIEJPRg0KDQpHaXZlbiB0aGUgZ29hbCBv ZiB0aGUgQk9GLCB0aGUgYWltIGlzIGZvciBhIG1vZGVyYXRlZCBkaXNjdXNzaW9uIG9mIHRoZSBt ZXJpdHMgKHBybyBhbmQgY29uKS4gU28gSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGJlIHBydWRlbnQg dG8gaGF2ZSBjaGFpcnMgd2hvIHJlZmxlY3QgdGhlIHZhcmlvdXMgdmlld3MuICBJdCB3aWxsIG1h a2UgaXQgZWFzaWVyIHRvIGtlZXAgdGhlIG1lZXRpbmcgb3JkZXJseSBhbmQgbW92aW5nLCBzaW5j ZSBubyBvbmUgd2lsbCBmZWVsIHRoYXQgdGhlIGNoYWlycyBzaHV0IHRoZW0gZG93biBiZWNhdXNl IHRoZXkgZGlkbid0IGFncmVlIHdpdGggdGhlaXIgdmlld3MuICAiU3VjY2VzcyIgaGVyZSBpcyBu b3QgbWVhc3VyZWQgYnkgd2hldGhlciBhIFdHIGlzIGNyZWF0ZWQgKG9yIG5vdCkuICAiU3VjY2Vz cyIgaXMgcHJvdmlkaW5nIHF1YWxpdHkgaW5wdXQgdG8gdGhlIElFU0cgb24gdGhlIG1lcml0cyBm cm9tIGEgYnJvYWQgcmFuZ2Ugb2YgcGFydGljaXBhbnRzLg0KDQpQbGVhc2UgdW5kZXJzdGFuZCB0 aGF0IEkgYW0gbm90IHNheWluZyB0aGF0IEkgdGhpbmsgSmVhbi1NYXJjIGFuZCBKYXNvbiB3b3Vs ZCBiZSBkZWxpYmVyYXRlbHkgdW5mYWlyLiBJIGFtIHNheWluZyB0aGF0IHdlIHNob3VsZCBhbnRp Y2lwYXRlIGEgbGl2ZWx5IGRpc2N1c3Npb24gd2l0aG91dCBjbGVhciBjb25zZW5zdXMuIFNvIG1v ZGVyYXRpbmcgaXQgaXMgbGlrZWx5IHRvIGJlIGNoYWxsZW5naW5nLiAgQWxzbywgaXQgd2lsbCBu b3QgYmUgZWFzeSBmb3IgSmVhbi1NYXJjIGFuZCBKYXNvbiB0byBwcmVzZW50IHRoZWlyIHBlcnNv bmFsIHZpZXdzIHdoaWxlIHRoZXkgYXJlIGFsc28gYWN0aW5nIGFzIGNoYWlycy4gIEZvciB0aGVz ZSByZWFzb25zLCBJIHRoaW5rIHRoYXQgaWYgdGhlIGNoYWlycyBhbGwgaG9sZCBvbmUgdmlldywg dGhlIEJPRiBpcyB1bmxpa2VseSB0byBiZSBzdWNjZXNzZnVsICh1c2luZyBteSBkZWZpbml0aW9u IGFib3ZlKS4NCg0KQXMgZmFyIGFzIGNvZGVjcyBnbywgSSB0aGluayB0aGVyZSBpcyBzb21lIHZh bHVlIGluIGhhdmluZyBhIGNvdXBsZSBvZiBzYW1wbGUgc3VibWlzc2lvbnMgdG8gbG9vayBhdC4g IEhvd2V2ZXIsIHRpbWUgd2lsbCBiZSB2YWx1YWJsZSBpbiB0aGUgQk9GLiBJIHRoaW5rIHdlIHNo b3VsZCBhc3N1bWUgdGhhdCB0aGUgSUVTRyB3aWxsIGJlIGFibGUgdG8gYXNzZXNzIHRoZSBzYW1w bGUgY29udHJpYnV0aW9ucyB3aXRob3V0IG91ciBuZWVkaW5nIHRvIHNwZW5kIGEgbG90IG9mIHRp bWUgZGlzY3Vzc2luZyB0aGVtLg0KDQpBbHNvLCBiZWZvcmUgYW55dGhpbmcgY2FuIG1vdmUgZm9y d2FyZCB0aGVyZSBuZWVkcyB0byBiZSAoYSkgYSBjaGFydGVyZWQgd29ya2luZyBncm91cCBhbmQg KGIpIGFuIGVzdGFibGlzaGVkIHNldCBvZiB3b3JraW5nIHByb2NlZHVyZXMuIFRoZSBwcm9wb3Nl ZCBjaGFydGVyJ3Mgb3V0cHV0IGlzIGEgc2luZ2xlIGNvZGVjLCBub3QgbXVsdGlwbGUgY29kZWNz LiAgVGhlcmUgd291bGQgbmVlZCB0byBiZSBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHdoZXRo ZXIgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgc2VsZWN0aW5nIGEgc2luZ2xlIGNvZGVjIGZyb20gdGhl IGNhbmRpZGF0ZXMsIG9yIHNvbWVob3cgZGV2ZWxvcGluZyBhIGNvbW1vbiBjb2RlYyBmcm9tIG1v cmUgdGhhbiBvbmUgY2FuZGlkYXRlLiAgVGhlcmUgd291bGQgYWxzbyBuZWVkIHRvIGJlIHNvbWUg Y29uc2Vuc3VzIG9uIHRoZSBiYXNpcyBmb3IgY29kZWMgc2VsZWN0aW9uIChhbmQvb3IgdGVjaG5v bG9neSBkZXZlbG9wbWVudCksIGFuZCBzb21lIGNvbnNlbnN1cyBvbiBob3cgdG8gbWVhc3VyZSB0 aGUgY29kZWMgcGVyZm9ybWFuY2UgYWdhaW5zdCB0aGUgdmFyaW91cyByZXF1aXJlbWVudHMsIGFu ZCBvZiBjb3Vyc2UgYXQgc29tZSBwb2ludCB0aGVyZSB3aWxsIGJlIG1vcmUgcHJlY2lzaW9uIG5l ZWRlZCBvbiB0aGUgSVBSIHJ1bGVzLiAgDQoNCkl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQgdG8g aW52ZW50IHRoZSBwcm9jZXNzIHdoaWxlIHdlIGFyZSBzaW11bHRhbmVvdXNseSB0YWxraW5nIGFi b3V0IGNvZGVjIHRlY2hub2xvZ3kuICBJJ2QgdGhpbmsgdGhlIFdHIChpZiBpdCBnb2VzIGZvcndh cmQpIHdvdWxkIG5lZWQgdG8gc3BlbmQgc29tZSB0aW1lIGhhbW1lcmluZyBvdXQgYSB3b3JraW5n IHByb2Nlc3MgYmVmb3JlIGl0IHdpbGwgYmUgcmVhZHkgdG8gYWNjZXB0IGNhbmRpZGF0ZXMgZm9y IGNvbnNpZGVyYXRpb24uIFBlcmhhcHMgc29tZSBtb3JlIGZvY3VzZWQgZGlzY3Vzc2lvbiBvbiB0 aGVzZSBwb2ludHMgYWhlYWQgb2YgdGltZSB3b3VsZCBiZSBoZWxwZnVsIHRvIHRoZSBJRVNHLCBh bmQgdG8gdGhlIFdHICh3aGVuIGFuZCBpZikuLg0KDQpJTUhPIHdlIG91Z2h0IHRvIHJlZnJhaW4g ZnJvbSBhY2N1c2luZyBwZW9wbGUgb2YgImtpbGxpbmciLCBUaGVyZSBpcyBub3RoaW5nIHRvIGtp bGwgYXQgdGhpcyBwb2ludC4gIFBvbGFyaXppbmcgdGhlIGRlYmF0ZSBieSBsYWJlbGluZyB0aGUg cGFydGljaXBhbnRzIGlzIG5vdCBhIGNvbnN0cnVjdGl2ZSB3YXkgdG8gcHJvY2VlZC4gIFRoZSBn ZW51aW5lIGFyZWFzIG9mIGRpc2FncmVlbWVudCBhcmUgaGFyZCBlbm91Z2guDQoNClN0ZXBoZW4g Qm90emtvDQpQb2x5Y29tDQoNCk9uIFRodSwgSnVsIDksIDIwMDkgYXQgMToxNiBQTSwgSW5nZW1h ciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0K SGkNCg0KVGhpcyBpcyB5ZXQgYW5vdGhlciByZWFzb24gd2h5IEkgdGhpbmsgaXQgaXMgYmVzdCB0 byBzZWxlY3QgY2hhaXJzIGZvciB0aGlzIHdobyByZWZsZWN0IHRoZSBkaWZmZXJlbnQgb3Bpbmlv bnMgYXJvdW5kIHRoaXMgc3ViamVjdC4gSWYgdGhpcyBpcyBub3QgZG9uZSBJIGZlYXIgdGhhdCB0 aGlzIEJvRiB3aWxsIGp1c3QgZW5kIHVwIGluIGEgdmVyYmFsIGZpc3QtZmlnaHQgYW5kIG5vYm9k eSBiZW5lZml0cyBmcm9tIGl0LCBpdCB3aWxsIG9ubHkgbWFrZSB1cyBhbGwgbG9vayBsaWtlIG1v cm9ucy4NCg0KQWxzbyBJIGFtIG5vdCB0cnlpbmcgdG8ga2lsbCBhbnkgY29kZWMsIEkganVzdCBk b24ndCBzZWUgaG93IGl0IGZpdHMgaW4gdGhlIElFVEYsIHRoYXRzIHdoeSBJIHdpc2ggdG8gaGF2 ZSBhbGwgaXNzdWVzIGRpc2N1c3NlZC4gU2VsZWN0aW9uIG9mIGNvZGVjcyBpcyBzZWNvbmRhcnkg YW5kIGNhbiBiZSBkaXNjdXNzZWQgb25jZS9pZiBhIGZvcm1hdGlvbiBvZiB0aGUgV0cgaXMgZGVj aWRlZC4NCg0KUGVyc29uYWxseSBJIGRvbid0IGtub3cgd2hhdCB0aGlzICJiYW5uZWQiIHN0dWZm IGluc2VydGVkIGJ5IHRoZSBzZXJ2ZXIgaXMgYWJvdXQuLi4NCg0KUmVnYXJkcw0KSW5nZW1hcg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcsOlbjogSGVucnkgU2lubnJl aWNoIFttYWlsdG86aHNpbm5yZWlAYWRvYmUuY29tXQ0KU2tpY2thdDogdG8gMjAwOS0wNy0wOSAx NjoyMg0KVGlsbDogSW5nZW1hciBKb2hhbnNzb24gUzsgY29kZWNAaWV0Zi5vcmcNCsOEbW5lOiBS ZTogW2NvZGVjXSBVcGRhdGVkIEFnZW5kYSBmb3IgQ29kZWMgQk9GDQoNCg0KDQpBbGwgdGhlc2Ug ZWZmb3J0cyB0byBraWxsIHRoZSBmcmVlIEludGVybmV0IHZvaWNlIGNvZGVjIGJlZm9yZSBpdCBp cyBldmVuIGJvcm4hDQoNClRoZXJlIG11c3QgYmUgYSB2ZXJ5IGJpZyBzdGFrZSB0byBkbyB0aGlz Li4uDQoNCkhlbnJ5DQoNCk9uIDcvOS8wOSA4OjQzIEFNLCAiSW5nZW1hciBKb2hhbnNzb24gUyIg PGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIDxodHRwczovL3J2aS5zZS5lcmljc3Nv bi5uZXQvZGFuYS1jYWNoZWQvaGVscC9lbXB0eS5odG1sPiA+IHdyb3RlOg0KDQoNCg0KICAgICAg IFdBUk5JTkc6IGNvbnRhaW5zIGJhbm5lZCBwYXJ0DQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvZGVjIG1haWxpbmcgbGlzdA0KY29kZWNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29kZWMNCiANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvZGVjIG1haWxpbmcgbGlzdA0KY29kZWNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29kZWMNCg0K ------_=_NextPart_001_01CA011C.E158814D Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIg0KeG1sbnM6bnM2PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5l cmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEt LVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Cm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9z dHlsZT4NCjwhW2VuZGlmXS0tPg0KPHRpdGxlPlJlOiBbY29kZWNdIFVwZGF0ZWQgQWdlbmRhIGZv ciBDb2RlYyBCT0Y8L3RpdGxlPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IlBsYWNlVHlwZSIv Pg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IlBsYWNlTmFtZSIvPg0KPG86U21hcnRUYWdUeXBl IG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdz Ig0KIG5hbWU9ImNvdW50cnktcmVnaW9uIi8+DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJp PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0icGxh Y2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJDaXR5Ii8+DQo8IS0tW2lmICFtc29dPg0K PHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS1hOmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5O30NCnNwYW4uTVNPSFlQRVJMSU5LDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTt9DQphOnZp c2l0ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5O30NCnNwYW4uTVNPSFlQRVJMSU5LRk9MTE9X RUQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 O30NCg0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy IDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1 cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KDQo8Ym9keSBsYW5nPVJVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9 U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBm YWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlN0ZXBoYW4sIENocmlzdGlhbiw8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5XZSBhcmUgaW4gYWdyZWVtZW50IOKAkw0Kcm95YWx0 eS1mcmVlIGFuZCBsaWNlbnNlLWZyZWUgaXMgc2VlbiBhcyBub3Qg4oCcbGVnYWxseSBiaW5kaW5n DQpyZXF1aXJlbWVudHPigJ0uIEkgcHV0IOKAnGxlZ2Fs4oCdIGp1c3QgdG8gbmFtZSBzdWNoIGdy b3VwIG9mIHJlcXVpcmVtZW50cw0KYW5kIHNlcGFyYXRlIHRoZW0gZnJvbSBvdGhlciAocGVyZm9y bWFuY2UpIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBs YW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpuYXZ5Jz5JIGFtIG5vdCB0cnlpbmcgdG8gZ2V0DQphbnkgZ3VhcmFudGllcywgc3BlY2lmaWNh bGx5IGluIHRoZSBhcmVhIG9mIElQUiwgc28gZGVmaW5pdGVseSDigJxkZXNpcmFibGXigJ0NCmlz IHByb3BlciB3b3JkLCBub3Qg4oCccmVxdWlyZWTigJ0g4oCTYXMgd2UgaGF2ZSBubyBtZWFucyB0 byB2ZXJpZnkNCjEwMCUgd2hldGhlciB3ZSBhY2hpZXZlZCB0aGUgZ29hbCBvZiBiZWluZyByb3lh bHR5LWZyZWUsIGxpY2Vuc2UtZnJlZSwgb3Igbm90LiBBbmQNCmF0IHRoaXMgc3RhZ2UgYWZ0ZXIg Y29kZWMgaXMgZG9uZSwgd2UgY2FuIG9ubHkgYmVsaWV2ZSBtb3JlIG9yIGxlc3MgdGhhdCBpdCBp cw0Kcm95YWx0eS1mcmVlLCBwYXRlbnQtZnJlZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh bD48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh biBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Jz5BbHNvLCB3aGVuIEkgc2F5IOKAnGxpY2Vuc2UtZnJlZeKAnQ0KSSBkbyBub3Qg bWVhbiDigJxwYXRlbnQtZnJlZeKAnSwgYnV0IOKAnGZyZWUgZnJvbSB0aGUgbmVlZCB0byBzaWdu DQpsaWNlbnNpbmcgYWdyZWVtZW50KHMpIGJlZm9yZSB1c2XigJ0uPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5 IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PSB0aGUgYWJpbGl0eSBmb3IgYW55DQp1c2VyIHRv IGdldCB0aGUgY29kZWMgYW5kIHVzZSBpdCB3aXRob3V0IHNpZ25pbmcgYW55IHBhcGVyd29yayDi gJMgdGhpcyB3YXMNCmRpc2N1c3NlZCBiZWZvcmUgb24g0YA8L3NwYW4+PC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPtC10YM8L3NwYW4+PC9mb250Pjxmb250DQpz aXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz4gbGlzdCwgYW5kIEpl YW4tTWFyYyBtYWRlIGEgc3Ryb25nIHBvaW50IHdoaWNoIEkgc2hhcmUuPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+U2xhdmEgQm9yaWxpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3 aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxz cGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9t YTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250DQpzaXplPTIg ZmFjZT1UYWhvbWE+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpUYWhvbWEnPg0KY29kZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvZGVjLWJv dW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuDQpzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+T24gQmVo YWxmIE9mIDwvc3Bhbj48L2I+Q2hyaXN0aWFuIEhvZW5lPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2Zv bnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gRnJpZGF5LCBKdWx5IDEwLCAyMDA5IDg6 NTUNCkFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48 L2I+ICdTdGVwaGFuIFdlbmdlcic7ICdKZWFuLU1hcmMNClZhbGluJzsgJ0phc29uIEZpc2NobCc8 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gY29k ZWNAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVj dDo8L3NwYW4+PC9iPiBSZTogW2NvZGVjXSBVcGRhdGVkDQpBZ2VuZGEgZm9yIENvZGVjIEJPRjwv c3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+R29vZCBtb3JuaW5n IFNsYXZhDQphbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3Bh biBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJy aT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOiMxRjQ5N0QnPnRvIG15IHVuZGVyc3RhbmRpbmcNCml0IGlzIGNvbW1vbmx5 IHVuZGVyc3Rvb2Qgb24gdGhpcyBtYWlsaW5nIGxpc3QgdGhhdCBub2JvZHkgY2FuIGd1YXJhbnR5 IGEgY29kZWMNCnRvIGJlIHJveWFsdHktZnJlZSBhbmQgbGljZW5zZS1mcmVlLiBCdXQgSSBoYXZl IHRvIGFncmVlIHRoYXQgdGhlIHdvcmRpbmcgaGF2ZQ0KdG8gYmUgc2VsZWN0ZWQgY2FyZWZ1bGx5 LiBXZSBzaGFsbCBhdm9pZCB0aGUgaW1wcmVzc2lvbiwgdGhhdCByb3lhbHR5LWZyZWUgb3INCmxp Y2Vuc2UtZnJlZSBpcyBhIHByb21pc2VkIGZlYXR1cmUgb2YgdGhlIGNvZGVjLjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPkJUVzog SXMgc29tZW9uZQ0KY29sbGVjdGluZyB0aGUgYXJndW1lbnRzIG9uIHRoaXMgbWFpbGluZyBsaXN0 PzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVO LVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMx RjQ5N0QnPk1heWJlIHRoZSBjaGFpcnMgY2FuDQpyZXF1ZXN0IGEgV2lraS8gVHJhYyB3ZWIgcGFn ZSwgd2hpY2ggY2FuIGJlIHVzZWQgYXMgYSBjb2xsYWJvcmF0aXZlIHBsYXRmb3JtIHRvDQpjb2xs ZWN0IHRoZSByZXN1bHRzIG9mIHRoZSBkaXNjdXNzaW9ucyBhbmQgdGhlIG51bWVyb3VzIGNvbnRy aWJ1dGlvbnMgcmVnYXJkaW5nDQp0aGUgd29yZGluZyBvZiByZXF1aXJlbWVudHM/PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+VGhh bmsgeW91IHZlcnkgbXVjaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3Bh biBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJy aT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOiMxRjQ5N0QnPiZuYnNwO0NocmlzdGlhbjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVO LVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMx RjQ5N0QnPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KRHIuLUluZy4gQ2hyaXN0aWFuIEhvZW5lPGJyPg0KSW50ZXJhY3RpdmUgQ29t bXVuaWNhdGlvbiBTeXN0ZW1zIChJQ1MpLCA8c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOlBsYWNl VHlwZQ0KIHc6c3Q9Im9uIj5Vbml2ZXJzaXR5PC9zdDE6UGxhY2VUeXBlPiBvZiA8c3QxOlBsYWNl TmFtZSB3OnN0PSJvbiI+VMO8YmluZ2VuPC9zdDE6UGxhY2VOYW1lPjwvc3QxOnBsYWNlPjxicj4N ClNhbmQgMTMsIDcyMDc2IDxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6Q2l0eSB3OnN0PSJvbiI+ VMO8YmluZ2VuPC9zdDE6Q2l0eT4sIDxzdDE6Y291bnRyeS1yZWdpb24NCiB3OnN0PSJvbiI+R2Vy bWFueTwvc3QxOmNvdW50cnktcmVnaW9uPjwvc3QxOnBsYWNlPiwgUGhvbmUgKzQ5IDcwNzEgMjk3 MDUzMjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPURFDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Qn PjxhDQpocmVmPSJodHRwOi8vd3d3Lm5ldC51bmktdHVlYmluZ2VuLmRlLyI+PHNwYW4gbGFuZz1F Ti1VUz5odHRwOi8vd3d3Lm5ldC51bmktdHVlYmluZ2VuLmRlLzwvc3Bhbj48L2E+PC9zcGFuPjwv Zm9udD48Zm9udA0Kc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJy aT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9t YT48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6VGFo b21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9 MiBmYWNlPVRhaG9tYT48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRhaG9tYSc+DQpjb2RlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29kZWMtYm91 bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4NCnN0eWxlPSdmb250LXdlaWdodDpib2xkJz5PbiBCZWhh bGYgT2YgPC9zcGFuPjwvYj5TdGVwaGFuIFdlbmdlcjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250 LXdlaWdodDpib2xkJz5TZW50Ojwvc3Bhbj48L2I+IEZyaWRheSwgSnVseSAxMCwgMjAwOSAxOjEx DQpBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9i PiBTbGF2YSBCb3JpbGluOyBzdGVwaGVuIGJvdHprbzsNCkluZ2VtYXIgSm9oYW5zc29uIFM8YnI+ DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gY29kZWNA aWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8 L3NwYW4+PC9iPiBSZTogW2NvZGVjXSBVcGRhdGVkDQpBZ2VuZGEgZm9yIENvZGVjIEJPRjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9 REUNCnN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48Zm9udCBzaXplPTIgZmFjZT1DYWxpYnJpPjxzcGFuDQpsYW5nPURFIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmknPkhpLDxicj4NCjxicj4NCk9uIDcvOS8wOSAx MjoxMyBQTSwgJnF1b3Q7U2xhdmEgQm9yaWxpbiZxdW90OyAmbHQ7PGENCmhyZWY9IkJvcmlsaW5A c3Bpcml0ZHNwLmNvbSI+Qm9yaWxpbkBzcGlyaXRkc3AuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFu PjwvZm9udD48c3Bhbg0KbGFuZz1ERT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxmb250IHNpemU9MiBjb2xv cj1uYXZ5DQpmYWNlPUFyaWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SQ0KYWdyZWUgd2l0aCBTdGVwaGVuIHRoYXQg aXQgd291bGQgYmUgYmV0dGVyIHRvIEVYQ0xVREUgIzQgZnJvbSBhZ2VuZGEg4oCTIGFzDQp0aGlz IG1heSBiZSB0aW1lIGNvbnN1bWluZy48YnI+DQpJbnN0ZWFkIEkgd291bGQgbGlrZSB0byBnZXQg YmFjayB0aGUgaXRlbSDigJxyZXF1aXJlbWVudHMgZm9yIGNvZGVjLCBhcw0KdGhleSBtYXkgbG9v ayBsaWtlIGZyb20gSUVURiBwZXJzcGVjdGl2ZeKAnSAocm95YWx0eS1mcmVlLCBsaWNlbnNlLWZy ZWUNCmZyb20gbGVnYWwsICsgdGVjaG5pY2FsIChwYWNrZXQgbG9zcywgTU9TLCBwZXJmb3JtYW5j ZSkpLjwvc3Bhbj48L2ZvbnQ+PHNwYW4NCmxhbmc9REU+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Zm9udCBz aXplPTIgZmFjZT1DYWxpYnJpPjxzcGFuDQpsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmknPkkgb2JqZWN0IGluIHRoZSBzdHJvbmdlc3QNCnBvc3NpYmxl IHRlcm1zIHRvIHRoZSBpbXBsaWVkIHN0YXRlbWVudCB0aGF0IGEgY29kZWMgYmVpbmcg4oCccm95 YWx0eS1mcmVlDQphbmQvb3IgbGljZW5zZS1mcmVlIGZyb20gbGVnYWzigJ0gaXMgYSByZXF1aXJl bWVudCBmcm9tIHRoZSBJRVRG4oCZcw0KcGVyc3BlY3RpdmUuICZuYnNwO0Egc3RhdGVtZW50IGxp a2UgdGhpcywgaWYgaXQgd2VyZSBjb3JyZWN0ICh3aGljaCBpdCBpc27igJl0KQ0KbWF5IGhhdmUg bGVnYWwgaW1wbGljYXRpb25zIHRoYXQgZmV3LCBpZiBhbnksIG9mIHVzIGhlcmUgZnVsbHkgdW5k ZXJzdGFuZC4NCiZuYnNwO1RydXN0IG1lIG9uIHRoaXMgKGFuZC9vciBhc2sgeW91ciBsYXd5ZXIp LiAmbmJzcDtJ4oCZbSBzZXJpb3VzLg0KJm5ic3A7PGJyPg0KPGJyPg0KTm93aGVyZSBpbiB0aGUg SUVURuKAmXMgbGVnYWwgZnJhbWV3b3JrIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9yDQpyb3lh bHR5LWZyZWUgZGVzaWducywgbGV0IGFsb25lIHVuZW5jdW1iZXJlZCBkZXNpZ25zIG9yIGRlc2ln bnMgcmVseWluZw0KZXhjbHVzaXZlbHkgb24gbm9uLWFzc2VydCBjb3ZlbmFudHMuICZuYnNwO05v d2hlcmUgaW4gdGhlIElFVEYsIGV4Y2VwdCBmb3IgdGhlDQpjb21tdW5pdHkgY29uc2Vuc3VzIGlu IGNlcnRhaW4sIHNtYWxsLCB3ZWxsLWRlZmluZWQgYXJlYXMgKHN1Y2ggYXMgYmFzZWxpbmUNCnNl Y3VyaXR5KSwgdGhlcmUgaXMgY29tbXVuaXR5IGNvbnNlbnN1cyBvZiBzdWNoIGEgcmVxdWlyZW1l bnQuICZuYnNwO0NlcnRhaW5seSwNCnRoZXJlIGlzIG5vIGNvbW11bml0eSBjb25zZW5zdXMgb24g dGhpcyBsaXN0IHdpdGggcmVzcGVjdCB0byB0aGUgY29kZWMgaXNzdWUuPGJyPg0KPGJyPg0KSWYg eW91IHdvdWxkIGhhdmUgYmVlbiB3cml0aW5nIHNvbWV0aGluZyBsaWtlIOKAnFJlcXVpcmVtZW50 IGFzIHZpZXdlZCBieQ0KdGhlIHByb3BvbmVudHMgb2YgdGhpcyBCT0bigJ0sIEkgd291bGQgYWdy ZWUuIDxicj4NCklmIHlvdSB3b3VsZCB3cml0ZSDigJxEZXNpcmFibGUgZm9yIHRoZSBjb250aW51 ZWQgZ3Jvd3RoIG9mIEludGVybmV0IGJhc2VkDQptdWx0aW1lZGlhIGNvbW11bmljYXRpb27igJ0s IEkgd291bGQgYWdyZWUuIDxicj4NCklmIHlvdSB3b3VsZCB3cml0ZSDigJxEZXNpcmFibGUgZnJv bSBhbiBJRVRGIHZpZXdwb2ludOKAnSwgSSB3b3VsZA0KYWdyZWUuICZuYnNwO1RoaXMgaXMgc3Vw cG9ydGVkIGJ5IHBvbGljeSBsYW5ndWFnZS48YnI+DQpJZiB5b3Ugd291bGQgd3JpdGUsIOKAnFJl cXVpcmVkIGZvciB0aGUgZnV0dXJlIG9mIHRoZSBJbnRlcm5ldOKAnSBJDQp3b3VsZCBkaXNhZ3Jl ZSwgYnV0IG5vdCBvYmplY3QgYXMgbm9pc2lseSBhcyBpbiB0aGUgc3RhdGVtZW50IHlvdSBtYWRl Lg0KJm5ic3A7SXTigJlzIGFic3RyYWN0IGVub3VnaCB0byBiZSBzYWZlLCBhcyBmYXIgYXMgSSBj YW4gc2VlLiAmbmJzcDtCdXQNCnBsZWFzZSBsZWF2ZSB0aGUgSUVURiwgYXMgYW4gb3JnYW5pemF0 aW9uLCBvdXQgb2YgdGhpcyBwaWN0dXJlLjxicj4NCjxicj4NCkluIHRoaXMgZGlzY3Vzc2lvbiwg d2UgYXJlIHRvdWNoaW5nIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBlbmdpbmVlcmluZyBhbmQNCmxl Z2FsLiAmbmJzcDtMZXTigJlzIGJlIGNhcmVmdWw7IGl04oCZcyBlYXN5IHRvIG1lc3MgdXAgdGhp bmdzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU3RlcGhhbjwvc3Bhbj48L2ZvbnQ+PHNwYW4g bGFuZz1ERT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPURFDQpzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9REUNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxicj4NCkkgZG8gTk9UIHRoaW5rIHdlIChtb3N0IG9m IHVzKSBkbyBub3QgYmVsaWV2ZSBpdOKAmXMgZmVhc2libGUg4oCTIHNvDQpub3QgbXVjaCBwb2lu dCBvZiBkaXNjdXNzaW5nIGlmIGl0cyBmZWFzaWJsZSB0byBzZWxlY3QgZ29vZCBJUCBjb2RlYy4g UXVlc3Rpb25zDQphcmUgY3JpdGVyaWEsIGFuZCBwYXRoIHRvIGdvICg9cHJvY2VzcykuPGJyPg0K Jm5ic3A7PGJyPg0KU2xhdmEgQm9yaWxpbjxicj4NCiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4g bGFuZz1ERT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFs aWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4N Cg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPg0KDQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KDQo8cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxmb250IHNpemU9 MiBmYWNlPVRhaG9tYT48c3BhbiBsYW5nPURFDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48 Zm9udA0Kc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gPGENCmhyZWY9ImNvZGVjLWJvdW5jZXNAaWV0Zi5v cmciPmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YQ0KaHJlZj0ibWFpbHRvOmNvZGVjLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjb2RlYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+PHNw YW4NCnN0eWxlPSdmb250LXdlaWdodDpib2xkJz5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5zdGVw aGVuIGJvdHprbzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwv c3Bhbj48L2I+IFRodXJzZGF5LCBKdWx5IDA5LCAyMDA5DQoxMDo0NSBQTTxicj4NCjxiPjxzcGFu IHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBJbmdlbWFyIEpvaGFuc3Nv biBTPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNjOjwvc3Bhbj48L2I+ IDxhIGhyZWY9ImNvZGVjQGlldGYub3JnIj5jb2RlY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3Bh biBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW2NvZGVj XSBVcGRhdGVkDQpBZ2VuZGEgZm9yIENvZGVjIEJPRjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHNwYW4g bGFuZz1ERT48YnI+DQpHaXZlbiB0aGUgZ29hbCBvZiB0aGUgQk9GLCB0aGUgYWltIGlzIGZvciBh IG1vZGVyYXRlZCBkaXNjdXNzaW9uIG9mIHRoZSBtZXJpdHMNCihwcm8gYW5kIGNvbikuIFNvIEkg YWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBwcnVkZW50IHRvIGhhdmUgY2hhaXJzIHdobyByZWZsZWN0 DQp0aGUgdmFyaW91cyB2aWV3cy4gJm5ic3A7SXQgd2lsbCBtYWtlIGl0IGVhc2llciB0byBrZWVw IHRoZSBtZWV0aW5nIG9yZGVybHkgYW5kDQptb3ZpbmcsIHNpbmNlIG5vIG9uZSB3aWxsIGZlZWwg dGhhdCB0aGUgY2hhaXJzIHNodXQgdGhlbSBkb3duIGJlY2F1c2UgdGhleQ0KZGlkbid0IGFncmVl IHdpdGggdGhlaXIgdmlld3MuICZuYnNwOyZxdW90O1N1Y2Nlc3MmcXVvdDsgaGVyZSBpcyBub3Qg bWVhc3VyZWQNCmJ5IHdoZXRoZXIgYSBXRyBpcyBjcmVhdGVkIChvciBub3QpLiAmbmJzcDsmcXVv dDtTdWNjZXNzJnF1b3Q7IGlzIHByb3ZpZGluZw0KcXVhbGl0eSBpbnB1dCB0byB0aGUgSUVTRyBv biB0aGUgbWVyaXRzIGZyb20gYSBicm9hZCByYW5nZSBvZiBwYXJ0aWNpcGFudHMuPGJyPg0KPGJy Pg0KUGxlYXNlIHVuZGVyc3RhbmQgdGhhdCBJIGFtIDx1Pm5vdDwvdT4gc2F5aW5nIHRoYXQgSSB0 aGluayBKZWFuLU1hcmMgYW5kIEphc29uIDx1PndvdWxkPC91Pg0KYmUgZGVsaWJlcmF0ZWx5IHVu ZmFpci4gSSA8dT5hbTwvdT4gc2F5aW5nIHRoYXQgd2Ugc2hvdWxkIGFudGljaXBhdGUgYSBsaXZl bHkNCmRpc2N1c3Npb24gd2l0aG91dCBjbGVhciBjb25zZW5zdXMuIFNvIG1vZGVyYXRpbmcgaXQg aXMgbGlrZWx5IHRvIGJlDQpjaGFsbGVuZ2luZy4gJm5ic3A7QWxzbywgaXQgd2lsbCBub3QgYmUg ZWFzeSBmb3IgSmVhbi1NYXJjIGFuZCBKYXNvbiB0byBwcmVzZW50DQp0aGVpciBwZXJzb25hbCB2 aWV3cyB3aGlsZSB0aGV5IGFyZSBhbHNvIGFjdGluZyBhcyBjaGFpcnMuICZuYnNwO0ZvciB0aGVz ZQ0KcmVhc29ucywgSSB0aGluayB0aGF0IGlmIHRoZSBjaGFpcnMgYWxsIGhvbGQgb25lIHZpZXcs IHRoZSBCT0YgaXMgdW5saWtlbHkgdG8NCmJlIHN1Y2Nlc3NmdWwgKHVzaW5nIG15IGRlZmluaXRp b24gYWJvdmUpLjxicj4NCjxicj4NCkFzIGZhciBhcyBjb2RlY3MgZ28sIEkgdGhpbmsgdGhlcmUg aXMgc29tZSB2YWx1ZSBpbiBoYXZpbmcgYSBjb3VwbGUgb2Ygc2FtcGxlDQpzdWJtaXNzaW9ucyB0 byBsb29rIGF0LiAmbmJzcDtIb3dldmVyLCB0aW1lIHdpbGwgYmUgdmFsdWFibGUgaW4gdGhlIEJP Ri4gSQ0KdGhpbmsgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IHRoZSBJRVNHIHdpbGwgYmUgYWJsZSB0 byBhc3Nlc3MgdGhlIHNhbXBsZQ0KY29udHJpYnV0aW9ucyB3aXRob3V0IG91ciBuZWVkaW5nIHRv IHNwZW5kIGEgbG90IG9mIHRpbWUgZGlzY3Vzc2luZyB0aGVtLjxicj4NCjxicj4NCkFsc28sIGJl Zm9yZSBhbnl0aGluZyBjYW4gbW92ZSBmb3J3YXJkIHRoZXJlIG5lZWRzIHRvIGJlIChhKSBhIGNo YXJ0ZXJlZA0Kd29ya2luZyBncm91cCBhbmQgKGIpIGFuIGVzdGFibGlzaGVkIHNldCBvZiB3b3Jr aW5nIHByb2NlZHVyZXMuIFRoZSBwcm9wb3NlZCBjaGFydGVyJ3MNCm91dHB1dCBpcyBhIHNpbmds ZSBjb2RlYywgbm90IG11bHRpcGxlIGNvZGVjcy4gJm5ic3A7VGhlcmUgd291bGQgbmVlZCB0byBi ZSBhDQpjb21tb24gdW5kZXJzdGFuZGluZyBvZiB3aGV0aGVyIHRoZSB3b3JraW5nIGdyb3VwIGlz IDx1PnNlbGVjdGluZzwvdT4gYSBzaW5nbGUNCmNvZGVjIGZyb20gdGhlIGNhbmRpZGF0ZXMsIG9y IHNvbWVob3cgPHU+ZGV2ZWxvcGluZzwvdT4gYSBjb21tb24gY29kZWMgZnJvbQ0KbW9yZSB0aGFu IG9uZSBjYW5kaWRhdGUuICZuYnNwO1RoZXJlIHdvdWxkIGFsc28gbmVlZCB0byBiZSBzb21lIGNv bnNlbnN1cyBvbg0KdGhlIGJhc2lzIGZvciBjb2RlYyBzZWxlY3Rpb24gKGFuZC9vciB0ZWNobm9s b2d5IGRldmVsb3BtZW50KSwgYW5kIHNvbWUNCmNvbnNlbnN1cyBvbiBob3cgdG8gbWVhc3VyZSB0 aGUgY29kZWMgcGVyZm9ybWFuY2UgYWdhaW5zdCB0aGUgdmFyaW91cw0KcmVxdWlyZW1lbnRzLCBh bmQgb2YgY291cnNlIGF0IHNvbWUgcG9pbnQgdGhlcmUgd2lsbCBiZSBtb3JlIHByZWNpc2lvbiBu ZWVkZWQNCm9uIHRoZSBJUFIgcnVsZXMuICZuYnNwOzxicj4NCjxicj4NCkl0IHdpbGwgYmUgdmVy eSBkaWZmaWN1bHQgdG8gaW52ZW50IHRoZSBwcm9jZXNzIHdoaWxlIHdlIGFyZSBzaW11bHRhbmVv dXNseQ0KdGFsa2luZyBhYm91dCBjb2RlYyB0ZWNobm9sb2d5LiAmbmJzcDtJJ2QgdGhpbmsgdGhl IFdHIChpZiBpdCBnb2VzIGZvcndhcmQpDQp3b3VsZCBuZWVkIHRvIHNwZW5kIHNvbWUgdGltZSBo YW1tZXJpbmcgb3V0IGEgd29ya2luZyBwcm9jZXNzIGJlZm9yZSBpdCB3aWxsIGJlDQpyZWFkeSB0 byBhY2NlcHQgY2FuZGlkYXRlcyBmb3IgY29uc2lkZXJhdGlvbi4gUGVyaGFwcyBzb21lIG1vcmUg Zm9jdXNlZA0KZGlzY3Vzc2lvbiBvbiB0aGVzZSBwb2ludHMgYWhlYWQgb2YgdGltZSB3b3VsZCBi ZSBoZWxwZnVsIHRvIHRoZSBJRVNHLCBhbmQgdG8NCnRoZSBXRyAod2hlbiBhbmQgaWYpLi48YnI+ DQo8YnI+DQpJTUhPIHdlIG91Z2h0IHRvIHJlZnJhaW4gZnJvbSBhY2N1c2luZyBwZW9wbGUgb2Yg JnF1b3Q7a2lsbGluZyZxdW90OywgVGhlcmUgaXMNCm5vdGhpbmcgdG8ga2lsbCBhdCB0aGlzIHBv aW50LiAmbmJzcDtQb2xhcml6aW5nIHRoZSBkZWJhdGUgYnkgbGFiZWxpbmcgdGhlDQpwYXJ0aWNp cGFudHMgaXMgbm90IGEgY29uc3RydWN0aXZlIHdheSB0byBwcm9jZWVkLiAmbmJzcDtUaGUgZ2Vu dWluZSBhcmVhcyBvZg0KZGlzYWdyZWVtZW50IGFyZSBoYXJkIGVub3VnaC48YnI+DQo8YnI+DQpT dGVwaGVuIEJvdHprbzxicj4NClBvbHljb208YnI+DQo8L3NwYW4+PGZvbnQgc2l6ZT0yIGZhY2U9 Q2FsaWJyaT48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1p bHk6Q2FsaWJyaSc+PGJyPg0KPC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPURFPk9uIFRodSwgSnVs IDksIDIwMDkgYXQgMToxNiBQTSwgSW5nZW1hciBKb2hhbnNzb24gUw0KJmx0OzxhIGhyZWY9Imlu Z2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbTwvYT4mZ3Q7DQp3cm90ZTo8YnI+DQpIaTxicj4NCjxicj4NClRoaXMgaXMgeWV0IGFu b3RoZXIgcmVhc29uIHdoeSBJIHRoaW5rIGl0IGlzIGJlc3QgdG8gc2VsZWN0IGNoYWlycyBmb3Ig dGhpcyB3aG8NCnJlZmxlY3QgdGhlIGRpZmZlcmVudCBvcGluaW9ucyBhcm91bmQgdGhpcyBzdWJq ZWN0LiBJZiB0aGlzIGlzIG5vdCBkb25lIEkgZmVhcg0KdGhhdCB0aGlzIEJvRiB3aWxsIGp1c3Qg ZW5kIHVwIGluIGEgdmVyYmFsIGZpc3QtZmlnaHQgYW5kIG5vYm9keSBiZW5lZml0cyBmcm9tDQpp dCwgaXQgd2lsbCBvbmx5IG1ha2UgdXMgYWxsIGxvb2sgbGlrZSBtb3JvbnMuPGJyPg0KPGJyPg0K QWxzbyBJIGFtIG5vdCB0cnlpbmcgdG8ga2lsbCBhbnkgY29kZWMsIEkganVzdCBkb24ndCBzZWUg aG93IGl0IGZpdHMgaW4gdGhlDQpJRVRGLCB0aGF0cyB3aHkgSSB3aXNoIHRvIGhhdmUgYWxsIGlz c3VlcyBkaXNjdXNzZWQuIFNlbGVjdGlvbiBvZiBjb2RlY3MgaXMNCnNlY29uZGFyeSBhbmQgY2Fu IGJlIGRpc2N1c3NlZCBvbmNlL2lmIGEgZm9ybWF0aW9uIG9mIHRoZSBXRyBpcyBkZWNpZGVkLjxi cj4NCjxicj4NClBlcnNvbmFsbHkgSSBkb24ndCBrbm93IHdoYXQgdGhpcyAmcXVvdDtiYW5uZWQm cXVvdDsgc3R1ZmYgaW5zZXJ0ZWQgYnkgdGhlDQpzZXJ2ZXIgaXMgYWJvdXQuLi48YnI+DQo8YnI+ DQpSZWdhcmRzPGJyPg0KSW5nZW1hcjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KPGJyPg0KRnLDpW46IEhlbnJ5IFNpbm5yZWljaCBbPGEgaHJlZj0ibWFp bHRvOmhzaW5ucmVpQGFkb2JlLmNvbSI+bWFpbHRvOmhzaW5ucmVpQGFkb2JlLmNvbTwvYT5dPGJy Pg0KU2tpY2thdDogdG8gMjAwOS0wNy0wOSAxNjoyMjxicj4NClRpbGw6IEluZ2VtYXIgSm9oYW5z c29uIFM7IDxhIGhyZWY9ImNvZGVjQGlldGYub3JnIj5jb2RlY0BpZXRmLm9yZzwvYT48YnI+DQrD hG1uZTogUmU6IFtjb2RlY10gVXBkYXRlZCBBZ2VuZGEgZm9yIENvZGVjIEJPRjxicj4NCjwvc3Bh bj48Zm9udCBzaXplPTIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz48YnI+DQo8L3NwYW4+PC9mb250PjxzcGFu IGxhbmc9REU+PGJyPg0KPGJyPg0KQWxsIHRoZXNlIGVmZm9ydHMgdG8ga2lsbCB0aGUgZnJlZSBJ bnRlcm5ldCB2b2ljZSBjb2RlYyBiZWZvcmUgaXQgaXMgZXZlbiBib3JuITxicj4NCjxicj4NClRo ZXJlIG11c3QgYmUgYSB2ZXJ5IGJpZyBzdGFrZSB0byBkbyB0aGlzLi4uPGJyPg0KPGJyPg0KSGVu cnk8YnI+DQo8YnI+DQpPbiA3LzkvMDkgODo0MyBBTSwgJnF1b3Q7SW5nZW1hciBKb2hhbnNzb24g UyZxdW90OyAmbHQ7PGENCmhyZWY9ImluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5p bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4NCiZsdDs8YSBocmVmPSJodHRwczov L3J2aS5zZS5lcmljc3Nvbi5uZXQvZGFuYS1jYWNoZWQvaGVscC9lbXB0eS5odG1sIj5odHRwczov L3J2aS5zZS5lcmljc3Nvbi5uZXQvZGFuYS1jYWNoZWQvaGVscC9lbXB0eS5odG1sPC9hPiZndDsN CiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V0FSTklORzogY29udGFpbnMgYmFubmVkIHBhcnQ8YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmNvZGVjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9ImNvZGVjQGlldGYub3JnIj5j b2RlY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvZGVjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvZGVjPC9hPjxicj4NCiZuYnNwOzwvc3Bhbj48Zm9udCBzaXplPTIgZmFjZT1DYWxpYnJpPjxz cGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJp Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBh bGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTINCmZhY2U9 Q2FsaWJyaT48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmknPg0KDQo8aHIgc2l6ZT0zIHdpZHRoPSI5NSUiIGFsaWduPWNlbnRlcj4NCg0KPC9z cGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNl PUNvbnNvbGFzPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh bWlseTpDb25zb2xhcyc+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpjb2RlYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJjb2RlY0BpZXRmLm9y ZyI+Y29kZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb2RlYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb2RlYzwvYT48L3NwYW4+PC9mb250PjxzcGFuDQpsYW5nPURFPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CA011C.E158814D-- From stewe@stewe.org Thu Jul 9 22:50:11 2009 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 6B7223A6869 for ; Thu, 9 Jul 2009 22:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 eAsvco0HhOFU for ; Thu, 9 Jul 2009 22:49:56 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id E75BC3A68FB for ; Thu, 9 Jul 2009 22:49:48 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 333612-1743317 for multiple; Fri, 10 Jul 2009 07:50:15 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 09 Jul 2009 22:50:05 -0700 From: Stephan Wenger To: Slava Borilin , Christian Hoene , Jean-Marc Valin , Jason Fischl Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoAxW8/m/aQ36kCRN+pJLkBylx7eAAAym3AAAh8ZaIAC6a6AAAAp5VQAAGglbg= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330024613_1190918" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:50:11 -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_3330024613_1190918 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Slava, All you write below is reasonable to me, and understood. My objection has been the close tie you have made between the terms =E2=80=9Croyalty-free /license free =E2=80=9D and =E2=80=9Crequirement from an IETF=E2=80=99s persp= ective=E2=80=9D. Neither in the IETF policy documents, nor in IETF practice, there is such a requirement. If such a requirement were in existence, the IETF would need to have a totally different set of policies, rules, and procedures---for example following the blueprint of the W3C patent policy. As a result, the IETF would most likely also be populated by a somewhat different set of people and companies. The IETF=E2=80=99s patent policy can be summarized as =E2=80=9Cobtain and make availabl= e as much information as possible on encumbrances, but don=E2=80=99t act on it as a body=E2=80=9D. If you wish to change this policy, I would suggest you attempt to= do so in an appropriate forum. Not in a random technical BOF. If you want to act within the policy framework we have, then please don=E2=80=99t attempt to bin= d your commercial preferences to a term like =E2=80=9Crequirement from an IETF=E2=80=99s perspective=E2=80=9D. Regards, Stephan =20 On 7/9/09 10:11 PM, "Slava Borilin" wrote: > Stephan, Christian, > =20 > We are in agreement =E2=80=93 royalty-free and license-free is seen as not =E2=80=9Cl= egally > binding requirements=E2=80=9D. I put =E2=80=9Clegal=E2=80=9D just to name such group of req= uirements > and separate them from other (performance) requirements. > I am not trying to get any guaranties, specifically in the area of IPR, s= o > definitely =E2=80=9Cdesirable=E2=80=9D is proper word, not =E2=80=9Crequired=E2=80=9D =E2=80=93as we ha= ve no means to > verify 100% whether we achieved the goal of being royalty-free, license-f= ree, > or not. And at this stage after codec is done, we can only believe more o= r > less that it is royalty-free, patent-free. > =20 > Also, when I say =E2=80=9Clicense-free=E2=80=9D I do not mean =E2=80=9Cpatent-free=E2=80=9D, but = =E2=80=9Cfree from > the need to sign licensing agreement(s) before use=E2=80=9D. > =3D the ability for any user to get the codec and use it without signing an= y > paperwork =E2=80=93 this was discussed before on =D1=80=D0=B5=D1=83 list, and Jean-Marc mad= e a strong > point which I share. >=20 > =20 > Slava Borilin > =20 >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Christian Hoene > Sent: Friday, July 10, 2009 8:55 AM > To: 'Stephan Wenger'; 'Jean-Marc Valin'; 'Jason Fischl' > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > =20 > Good morning Slava and all, > =20 > to my understanding it is commonly understood on this mailing list that n= obody > can guaranty a codec to be royalty-free and license-free. But I have to a= gree > that the wording have to be selected carefully. We shall avoid the impres= sion, > that royalty-free or license-free is a promised feature of the codec. > =20 > BTW: Is someone collecting the arguments on this mailing list? > =20 > Maybe the chairs can request a Wiki/ Trac web page, which can be used as = a > collaborative platform to collect the results of the discussions and the > numerous contributions regarding the wording of requirements? > =20 > Thank you very much > =20 > Christian > =20 > =20 > =20 >=20 > -------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=C3=BCbingen > Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > =20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Friday, July 10, 2009 1:11 AM > To: Slava Borilin; stephen botzko; Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > =20 > Hi, >=20 > On 7/9/09 12:13 PM, "Slava Borilin" wrote: > I agree with Stephen that it would be better to EXCLUDE #4 from agenda =E2=80= =93 as > this may be time consuming. > Instead I would like to get back the item =E2=80=9Crequirements for codec, as t= hey may > look like from IETF perspective=E2=80=9D (royalty-free, license-free from legal= , + > technical (packet loss, MOS, performance)). > I object in the strongest possible terms to the implied statement that a = codec > being =E2=80=9Croyalty-free and/or license-free from legal=E2=80=9D is a requirement = from the > IETF=E2=80=99s perspective. A statement like this, if it were correct (which i= t > isn=E2=80=99t) may have legal implications that few, if any, of us here fully > understand. Trust me on this (and/or ask your lawyer). I=E2=80=99m serious. >=20 > Nowhere in the IETF=E2=80=99s legal framework there is a requirement for royalt= y-free > designs, let alone unencumbered designs or designs relying exclusively on > non-assert covenants. Nowhere in the IETF, except for the community cons= ensus > in certain, small, well-defined areas (such as baseline security), there = is > community consensus of such a requirement. Certainly, there is no commun= ity > consensus on this list with respect to the codec issue. >=20 > If you would have been writing something like =E2=80=9CRequirement as viewed by= the > proponents of this BOF=E2=80=9D, I would agree. > If you would write =E2=80=9CDesirable for the continued growth of Internet base= d > multimedia communication=E2=80=9D, I would agree. > If you would write =E2=80=9CDesirable from an IETF viewpoint=E2=80=9D, I would agree.= This is > supported by policy language. > If you would write, =E2=80=9CRequired for the future of the Internet=E2=80=9D I would > disagree, but not object as noisily as in the statement you made. It=E2=80=99s > abstract enough to be safe, as far as I can see. But please leave the IE= TF, > as an organization, out of this picture. >=20 > In this discussion, we are touching the interface between engineering and > legal. Let=E2=80=99s be careful; it=E2=80=99s easy to mess up things. >=20 > Regards, > Stephan >=20 >=20 > I do NOT think we (most of us) do not believe it=E2=80=99s feasible =E2=80=93 so not = much > point of discussing if its feasible to select good IP codec. Questions ar= e > criteria, and path to go (=3Dprocess). > =20 > Slava Borilin > =20 >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > stephen botzko > Sent: Thursday, July 09, 2009 10:45 PM > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > Given the goal of the BOF, the aim is for a moderated discussion of the m= erits > (pro and con). So I agree that it would be prudent to have chairs who ref= lect > the various views. It will make it easier to keep the meeting orderly an= d > moving, since no one will feel that the chairs shut them down because the= y > didn't agree with their views. "Success" here is not measured by whether= a WG > is created (or not). "Success" is providing quality input to the IESG on= the > merits from a broad range of participants. >=20 > Please understand that I am not saying that I think Jean-Marc and Jason w= ould > be deliberately unfair. I am saying that we should anticipate a lively > discussion without clear consensus. So moderating it is likely to be > challenging. Also, it will not be easy for Jean-Marc and Jason to presen= t > their personal views while they are also acting as chairs. For these rea= sons, > I think that if the chairs all hold one view, the BOF is unlikely to be > successful (using my definition above). >=20 > As far as codecs go, I think there is some value in having a couple of sa= mple > submissions to look at. However, time will be valuable in the BOF. I thi= nk we > should assume that the IESG will be able to assess the sample contributio= ns > without our needing to spend a lot of time discussing them. >=20 > Also, before anything can move forward there needs to be (a) a chartered > working group and (b) an established set of working procedures. The propo= sed > charter's output is a single codec, not multiple codecs. There would nee= d to > be a common understanding of whether the working group is selecting a sin= gle > codec from the candidates, or somehow developing a common codec from more= than > one candidate. There would also need to be some consensus on the basis f= or > codec selection (and/or technology development), and some consensus on ho= w to > measure the codec performance against the various requirements, and of co= urse > at some point there will be more precision needed on the IPR rules. >=20 > It will be very difficult to invent the process while we are simultaneous= ly > talking about codec technology. I'd think the WG (if it goes forward) wo= uld > need to spend some time hammering out a working process before it will be > ready to accept candidates for consideration. Perhaps some more focused > discussion on these points ahead of time would be helpful to the IESG, an= d to > the WG (when and if).. >=20 > IMHO we ought to refrain from accusing people of "killing", There is noth= ing > to kill at this point. Polarizing the debate by labeling the participant= s is > not a constructive way to proceed. The genuine areas of disagreement are= hard > enough. >=20 > Stephen Botzko > Polycom >=20 > On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S > wrote: > Hi >=20 > This is yet another reason why I think it is best to select chairs for th= is > who reflect the different opinions around this subject. If this is not do= ne I > fear that this BoF will just end up in a verbal fist-fight and nobody ben= efits > from it, it will only make us all look like morons. >=20 > Also I am not trying to kill any codec, I just don't see how it fits in t= he > IETF, thats why I wish to have all issues discussed. Selection of codecs = is > secondary and can be discussed once/if a formation of the WG is decided. >=20 > Personally I don't know what this "banned" stuff inserted by the server i= s > about... >=20 > Regards > Ingemar >=20 > ________________________________ >=20 > Fr=C3=A5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Skickat: to 2009-07-09 16:22 > Till: Ingemar Johansson S; codec@ietf.org > =C3=84mne: Re: [codec] Updated Agenda for Codec BOF >=20 >=20 >=20 > All these efforts to kill the free Internet voice codec before it is even > born! >=20 > There must be a very big stake to do this... >=20 > Henry >=20 > On 7/9/09 8:43 AM, "Ingemar Johansson S" > wrote: >=20 >=20 >=20 > WARNING: contains banned part >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 --B_3330024613_1190918 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable Re: [codec] Updated Agenda for Codec BOF Hi Slava,

All you write below is reasonable to me, and understood.  

My objection has been the close tie you have made between the terms “= royalty-free /license free ” and “requirement from an IETF’= ;s perspective”.  Neither in the IETF policy documents, nor in IE= TF practice, there is such a requirement.  If such a requirement were i= n existence, the IETF would need to have a totally different set of policies= , rules, and procedures---for example following the blueprint of the W3C pat= ent policy.  As a result, the IETF would most likely also be populated = by a somewhat different set of people and companies.  

The IETF’s patent policy can be summarized as “obtain and make = available as much information as possible on encumbrances, but don’t a= ct on it as a body”.  If you wish to change this policy, I would = suggest you attempt to do so in an appropriate forum.  Not in a random = technical BOF.  If you want to act within the policy framework we have,= then please don’t attempt to bind your commercial preferences to a te= rm like “requirement from an IETF’s perspective”.

Regards,
Stephan
  

On 7/9/09 10:11 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Stephan, Christian,
 
We are in agreement – royalty-free and license-free is seen as not &#= 8220;legally binding requirements”. I put “legal” just to = name such group of requirements and separate them from other (performance) r= equirements.
I am not trying to get any guaranties, specifically in the area of IPR, so = definitely “desirable” is proper word, not “required”= ; –as we have no means to verify 100% whether we achieved the goal of = being royalty-free, license-free, or not. And at this stage after codec is d= one, we can only believe more or less that it is royalty-free, patent-free.<= BR>  
Also, when I say “license-free” I do not mean “patent-fre= e”, but “free from the need to sign licensing agreement(s) befor= e use”.
=3D the ability for any user to get the codec and use it without signing any = paperwork – this was discussed before on =D1=80=D0=B5=D1=83 list, and Jean-Marc ma= de a strong point which I share.
Slava Borilin
 


From: = codec-bounces@ietf.org [mailto:c= odec-bounces@ietf.org] On Behalf Of Christian Hoene
Sent: Friday, July 10, 2009 8:55 AM
To: 'Stephan Wenger'; 'Jean-Marc Valin'; 'Jason Fischl'
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF
Good morning Slava and all,
 
to my understanding it is commonly understood on this mailing list that nob= ody can guaranty a codec to be royalty-free and license-free. But I have to = agree that the wording have to be selected carefully. We shall avoid the imp= ression, that royalty-free or license-free is a promised feature of the code= c.
 
BTW: Is someone collecting the arguments on this mailing list?
 
Maybe the chairs can request a Wiki/ Trac web page, which can be used as a = collaborative platform to collect the results of the discussions and the num= erous contributions regarding the wording of requirements?
 
Thank you very much
 
 Christian
 
 
 

--= ------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/= <http://www.net.uni-tuebi= ngen.de/>


From: = codec-bounces@ietf.org [mailto:c= odec-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, July 10, 2009 1:11 AM
To: Slava Borilin; stephen botzko; Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF
Hi,

On 7/9/09 12:13 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I agree with Stephen that it would be better to EXCL= UDE #4 from agenda – as this may be time consuming.
Instead I would like to get back the item “requirements for codec, as= they may look like from IETF perspective” (royalty-free, license-free= from legal, + technical (packet loss, MOS, performance)).
I object in the strongest possible terms to th= e implied statement that a codec being “royalty-free and/or license-fr= ee from legal” is a requirement from the IETF’s perspective. &nb= sp;A statement like this, if it were correct (which it isn’t) may have= legal implications that few, if any, of us here fully understand.  Tru= st me on this (and/or ask your lawyer).  I’m serious.  

Nowhere in the IETF’s legal framework there is a requirement for roya= lty-free designs, let alone unencumbered designs or designs relying exclusiv= ely on non-assert covenants.  Nowhere in the IETF, except for the commu= nity consensus in certain, small, well-defined areas (such as baseline secur= ity), there is community consensus of such a requirement.  Certainly, t= here is no community consensus on this list with respect to the codec issue.=

If you would have been writing something like “Requirement as viewed = by the proponents of this BOF”, I would agree.
If you would write “Desirable for the continued growth of Internet ba= sed multimedia communication”, I would agree.
If you would write “Desirable from an IETF viewpoint”, I would = agree.  This is supported by policy language.
If you would write, “Required for the future of the Internet” I= would disagree, but not object as noisily as in the statement you made. &nb= sp;It’s abstract enough to be safe, as far as I can see.  But ple= ase leave the IETF, as an organization, out of this picture.

In this discussion, we are touching the interface between engineering and l= egal.  Let’s be careful; it’s easy to mess up things.

Regards,
Stephan
I do NOT think we (most of us) do not believe it’s feasible – s= o not much point of discussing if its feasible to select good IP codec. Ques= tions are criteria, and path to go (=3Dprocess).
 
Slava Borilin
 


From: = codec-bounces@ietf.org [mailto:c= odec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Thursday, July 09, 2009 10:45 PM
To: Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF

Given the goal of the BOF, the aim is for a moderated discussion of the mer= its (pro and con). So I agree that it would be prudent to have chairs who re= flect the various views.  It will make it easier to keep the meeting or= derly and moving, since no one will feel that the chairs shut them down beca= use they didn't agree with their views.  "Success" here is no= t measured by whether a WG is created (or not).  "Success" is= providing quality input to the IESG on the merits from a broad range of par= ticipants.

Please understand that I am not saying that I think Jean-Marc and Ja= son would be deliberately unfair. I am saying that we should a= nticipate a lively discussion without clear consensus. So moderating it is l= ikely to be challenging.  Also, it will not be easy for Jean-Marc and J= ason to present their personal views while they are also acting as chairs. &= nbsp;For these reasons, I think that if the chairs all hold one view, the BO= F is unlikely to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of samp= le submissions to look at.  However, time will be valuable in the BOF. = I think we should assume that the IESG will be able to assess the sample con= tributions without our needing to spend a lot of time discussing them.

Also, before anything can move forward there needs to be (a) a chartered wo= rking group and (b) an established set of working procedures. The proposed c= harter's output is a single codec, not multiple codecs.  There would ne= ed to be a common understanding of whether the working group is selecting= a single codec from the candidates, or somehow developing a comm= on codec from more than one candidate.  There would also need to be som= e consensus on the basis for codec selection (and/or technology development)= , and some consensus on how to measure the codec performance against the var= ious requirements, and of course at some point there will be more precision = needed on the IPR rules.  

It will be very difficult to invent the process while we are simultaneously= talking about codec technology.  I'd think the WG (if it goes forward)= would need to spend some time hammering out a working process before it wil= l be ready to accept candidates for consideration. Perhaps some more focused= discussion on these points ahead of time would be helpful to the IESG, and = to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing", There= is nothing to kill at this point.  Polarizing the debate by labeling t= he participants is not a constructive way to proceed.  The genuine area= s of disagreement are hard enough.

Stephen Botzko
Polycom

On = Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

This is yet another reason why I think it is best to select chairs for this= who reflect the different opinions around this subject. If this is not done= I fear that this BoF will just end up in a verbal fist-fight and nobody ben= efits from it, it will only make us all look like morons.

Also I am not trying to kill any codec, I just don't see how it fits in the= IETF, thats why I wish to have all issues discussed. Selection of codecs is= secondary and can be discussed once/if a formation of the WG is decided.
Personally I don't know what this "banned" stuff inserted by the = server is about...

Regards
Ingemar

________________________________

Från: Henry Sinnreich [mailto:hsi= nnrei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org
Ämne: Re: [codec] Updated Agenda for Codec BOF
All these efforts to kill the free Internet voice codec before it is even b= orn!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com <https://rvi.se.ericsso= n.net/dana-cached/help/empty.html> > wrote:



       WARNING: contains banned part


_______________________________________________
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

--B_3330024613_1190918-- From xiphmont@gmail.com Thu Jul 9 22:55:29 2009 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 242AA3A6D7B for ; Thu, 9 Jul 2009 22:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 kVf0BrEzgGmx for ; Thu, 9 Jul 2009 22:55:28 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 61EF43A6A57 for ; Thu, 9 Jul 2009 22:55:27 -0700 (PDT) Received: by gxk26 with SMTP id 26so1192235gxk.13 for ; Thu, 09 Jul 2009 22:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iy24qnzYH3LvJlVHRFh+qeVO+QZiLnJ0MgCGzG/LLKE=; b=GQObkqqt/Z1sguGtV6bZYzRUyl6KpAZxKmzIYbnUPndhCNHNf2Il0oP9EustMHWvgR ZCzrz3uQu9rnkr5JwlGic2IYqUtE4rA60aNLUzSSKfMCQ0PNc/7QH+eM6RBdkhsudvJi zOuGYMHLQROB2S1IdZiW5f6kEHzJDLE26sELc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XA576RvdmcNYncT88eeYQX9I96/a3dwq1EmCndNUFTfcNyCOLV2xBQLft8MSsdpo+O V8DnCPaqX4y0PXRAVClkruoBkTsXaLbkMOxOts8LUnJxuTkL7/VmZlaJj9zjl5m8YGMd qJA165ym+uCLHBVJv8WcfKyVeKGEbRTLrJWCg= MIME-Version: 1.0 Received: by 10.231.34.75 with SMTP id k11mr537361ibd.53.1247205351746; Thu, 09 Jul 2009 22:55:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2009 01:55:51 -0400 Message-ID: <806dafc20907092255v3e1dc18bwf42069f8fc313768@mail.gmail.com> From: Monty Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:55:29 -0000 >=A0If you wish to change this policy, I would suggest you attempt to do > so in an appropriate forum. =A0Not in a random technical BOF. This BOF is neither random nor is its stated aim purely technical. It is a royalty-free codecs BOF. I understand you wish to be very careful here. At the point that 'royalty free' is stricken, however, we've tossed the baby out with the bathwater. Monty From stewe@stewe.org Thu Jul 9 23:37:08 2009 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 113B13A6D6C for ; Thu, 9 Jul 2009 23:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 1X1Z20JgPFFo for ; Thu, 9 Jul 2009 23:37:07 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 4A5A73A6C76 for ; Thu, 9 Jul 2009 23:37:04 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 333651-1743317 for multiple; Fri, 10 Jul 2009 08:37:31 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 09 Jul 2009 23:37:02 -0700 From: Stephan Wenger To: Monty Montgomery Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoBKNUozhaW16m/uUiOJvHJ9wfw1Q== In-Reply-To: <806dafc20907092255v3e1dc18bwf42069f8fc313768@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 06:37:08 -0000 Hi Monty, I understand you guys don't want to remove the 'royalty-free' aspect. That's your choice. I will concede that such a choice could probably be formulated into a charter of a WG---if one were formed, which I continue to hope will not (for the numerous reasons that have already been discussed at length, not primarily for this IPR stuff). However, that formulation would need to be worded carefully. In a different environment (in JVT, which operated under the ITU's and ISO/IEC's patent policy) we actually did exactly that. =20 In my opinion, the word "requirement" in relation to licensing terms needs to be avoided. The IETF does not have such requirements; not even a requirement for a promise for RAND licensing. There are historic and structural reasons in the IETF's legal and policy framework that have led t= o this situation. Neither this mailing list, nor the BOF, are the right foru= m to discuss the legal reasons that make me so nervous about the term "requirement" and/or any automatic sanctions to an IETF document that would kick in if an incompatible IPR disclosure were received. (I'm not even going into the business of interpretation of those disclosures, which require a certain amount of expertise in their own right.) Set a "goal" or a "desire" for certain commercial terms, if you wish. That has worked well enough elsewhere. Regards, Stephan P.s.: actually, I don't think you really want "royalty-free". What you really want is open-source compatibility, right? Most RAND-Z license promises is not compatible with some of the more widely used open source licenses (those that allow derivative works). What you need for open-sourc= e compatibility is commonly known as a patent non-assert covenant. On 7/9/09 10:55 PM, "Monty Montgomery" wrote: >> =A0If you wish to change this policy, I would suggest you attempt to do >> so in an appropriate forum. =A0Not in a random technical BOF. >=20 > This BOF is neither random nor is its stated aim purely technical. >=20 > It is a royalty-free codecs BOF. I understand you wish to be very > careful here. At the point that 'royalty free' is stricken, however, > we've tossed the baby out with the bathwater. >=20 > Monty From ron.even.tlv@gmail.com Thu Jul 9 23:59:14 2009 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 C5A3C3A6D94 for ; Thu, 9 Jul 2009 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbECTtQVP1hy for ; Thu, 9 Jul 2009 23:59:14 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 66F383A6D7B for ; Thu, 9 Jul 2009 23:58:48 -0700 (PDT) Received: by bwz25 with SMTP id 25so661055bwz.37 for ; Thu, 09 Jul 2009 23:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=HJ5fw5BNkYmfVpEd7XI+AHfCeRoOPlH+Y4scLO67ido=; b=oqYl1QUZ23O0cv25drZ7xwPDQAY2pSrnWhZhoo/cC+PueA9gvBQ8++2YeQ5ijB+2dP IOamgGlPFzH0qv8l9tqgefC/S0j+tLE4ktrbREYdXbg70+M8TBAMDfo0ulIzdNpho2bq +a7qebdsDomst0JgS4pnawru7tST3awAMhwGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=QAadU+2Av0m/T3RZBoAOvAu3192UiN9nQBswW3P4RJfagXKeLC6xXD7cxzyRHU3FcV x+xZVVAMO2Z5ztcr3JtvOzkap4XEwr/GicFFKVVVt/YsCumd44/p8FuagPISBWbT/T82 lgT0bWYsjMQ6IhNKPh/PopqTw8NyCVb5l+Uo4= Received: by 10.103.165.18 with SMTP id s18mr887543muo.104.1247209146997; Thu, 09 Jul 2009 23:59:06 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id j10sm3563634muh.15.2009.07.09.23.59.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 23:59:06 -0700 (PDT) From: "Roni Even" To: "'Dean Bogdanovic'" , References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> In-Reply-To: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> Date: Fri, 10 Jul 2009 09:58:14 +0300 Message-ID: <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBGp5LIQ3+tmC3TqqaSLfmYfPbXQAEGKgw Content-Language: en-us Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 06:59:14 -0000 Dean, These carrier worry about their revenues, so they are looking for free codecs. That is understandable from their perspective but are they going to offer me as an enduser a free service as a result. I can understand a request for RF codec from non profit solution providers but I can not feel any obligation to support ones that care for their revenue stream by getting free product. They can also ask for free routers to connect their networks. As for the IETF work, I did not see that they are looking for standard codecs, they still could use celp or other free codecs if the quality is right Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Dean Bogdanovic > Sent: Friday, July 10, 2009 7:20 AM > To: codec@ietf.org > Subject: [codec] Customer demand for royalty-free internet codec > > After reading discussions on this topic, thought to add customer view > on this one. > > In the last 12 month, I've participated in several customer projects > in Asia, Africa and Europe. All of them were trying to add voip over > their 3G data networks as service and were looking for low-latency > royalty free codec. Two of the projects were interesting, as different > carriers connected their voip networks and allowed traffic between > voip UAs directly (no PSTN interconnect). The biggest problem ended up > being codec, as the results of testing with different royalty free > codecs weren't satisfying. > In general, carrier groups are looking to use IP as primary > communication mechanism among their group members and for them royalty > free, adaptive/low latency is really important, as (Asia, Africa and > part of Europe) their subs have low ARPU and many of them are > traveling for work outside of their home countries. So you have > carrier groups covering all those countries, but they don't have an > (cheap) option to provide affordable service to their customers. > > this is commercial view why work of this BOF (and creation of WG) is > valuable. It would be nice some positive results coming from this > > Dean > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From xiphmont@gmail.com Fri Jul 10 00:55:39 2009 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 2F0353A6DEF for ; Fri, 10 Jul 2009 00:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 wK65B0XaS41T for ; Fri, 10 Jul 2009 00:55:38 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 675B53A6DCC for ; Fri, 10 Jul 2009 00:55:38 -0700 (PDT) Received: by gxk26 with SMTP id 26so1267835gxk.13 for ; Fri, 10 Jul 2009 00:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gPegmx7FVAi4861c85N+xdkVCGH6G/RdOegXVXA5cwQ=; b=BfqUj+R6F+APAv6IbIdLB7xVkz0MplQ3GOlSDgS6Lu7NXlDPwqq0bvuZngkMpqWGIz ZPuh0oGJVembRT2asy7rKoaA+kU6vHxABxf7IQ6ejzfoVfRSnQoBtLcTb13IwC0j9hmw py60Qu9mUPNUIDZ3Cf9shQIPS5E5lLtjzfqQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f8F6SZers93x1CfPqSLeYhhfuY8nHhPaHN/4Puu+iuvQW7iFDbyFOtqCJlHEyuetpe OepDD6k/Z7FC/eeU1r3+JDcr1IMC/WI1RfnsMTVY7pgDokW/GOaV1qaqSKeyxOLy07GD dvTu5QzzP8q+LLqUOPMiZ9YUT7oMjrRYeSHy0= MIME-Version: 1.0 Received: by 10.231.34.68 with SMTP id k4mr571917ibd.6.1247212564643; Fri, 10 Jul 2009 00:56:04 -0700 (PDT) In-Reply-To: References: <806dafc20907092255v3e1dc18bwf42069f8fc313768@mail.gmail.com> Date: Fri, 10 Jul 2009 03:56:04 -0400 Message-ID: <806dafc20907100056j4682feacr410cad36d19a282d@mail.gmail.com> From: Monty Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 07:55:39 -0000 > P.s.: actually, I don't think you really want "royalty-free". =A0What you > really want is open-source compatibility, right? This is a more accurate label, yes. I'm not trying to dismiss your argument that a warranty is something the IETF could never offer. I was trying to push back against using that assertion to state something much stronger ('...so we should not even be trying to operate outside of a RAND system'). The patent situation today has put all of us in a bind where we can be sued as individuals or organizations at any time and for nearly any reason. And yet, day to day, we still manage to muddle through in a practically satisfactory way. Just because an exact solution is NP hard doesn't mean that a working solution isn't acheivable. Monty From xiphmont@gmail.com Fri Jul 10 01:14:58 2009 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 4E06E28C267 for ; Fri, 10 Jul 2009 01:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 mGUZl0sMQvi2 for ; Fri, 10 Jul 2009 01:14:57 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id 76EF228C1C4 for ; Fri, 10 Jul 2009 01:14:57 -0700 (PDT) Received: by yxe10 with SMTP id 10so1387529yxe.29 for ; Fri, 10 Jul 2009 01:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lcHOJrVKG2O1yM/9v5b1v+cOmyKnKFkoMPfJmLZDvAc=; b=XyvExiHeZEOBvB6rbSR1WAsxndcYonW0KXgY4Xj04SEfUvr6kHACWTnvj+Nb+4HW74 BLya7uHQvxgpzvcShtLEEeXZ7a+2FD0vjDUnJqT0azbX45G6BQKk+vNXTtrmzixgBU22 yFXiCDYqjfcNJtBTpWZPiCdqMrExryVdXbM3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j+snvF3g0uM2FIyOVGKy2ukXTuGZs+rNoW2NCi0yJGUT0C8Ige6STMaXqBH/djW9tf tZ79BuX5wgbXcBJC5Zx7k2PKhzu2Ez5DLNudozU8g0QtuvJ39KPq8zT+CS2rv9vGKNRX aLd3UpdSJH4ffyPcR3TqcQd0fK/SvLvXPzRMo= MIME-Version: 1.0 Received: by 10.231.35.3 with SMTP id n3mr566319ibd.30.1247213723503; Fri, 10 Jul 2009 01:15:23 -0700 (PDT) In-Reply-To: <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> Date: Fri, 10 Jul 2009 04:15:23 -0400 Message-ID: <806dafc20907100115u3c9de436o6a76111811da2629@mail.gmail.com> From: Monty Montgomery To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 08:14:58 -0000 On Fri, Jul 10, 2009 at 2:58 AM, Roni Even wrote: > I can understand a request for RF codec from non profit solution providers > but I can not feel any obligation to support ones that care for their > revenue stream by getting free product. They can also ask for free routers > to connect their networks. How is this relevant to conversation? What do free codecs have to do with free hardware? You seem to be arguing that commodity codecs are a patent absurdity (no pun intended or implied) and yet here we have three offered within the scope of the WG. For the record, I care very much about for-profit ventures using my free work to enhance their bottom lines-- I want very much for them to do so. If they want my direct personal development support time, then we can discuss a reasonable fee. Monty From ron.even.tlv@gmail.com Fri Jul 10 02:07:31 2009 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 C39C93A6FF1 for ; Fri, 10 Jul 2009 02:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeNuH72mCAOo for ; Fri, 10 Jul 2009 02:07:31 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id C34473A6768 for ; Fri, 10 Jul 2009 02:07:30 -0700 (PDT) Received: by bwz25 with SMTP id 25so721611bwz.37 for ; Fri, 10 Jul 2009 02:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=2VSni/eheHXonh04fU55NJprgYDdGoLAvVsI0QWFUOc=; b=BwQfxCzccnU3PSFGJ2FLszKSy9d4JlWAVsS77NkimAeebavCPITMwUSr0EmGB9gFTv m/ySsOYUkOM8LHbwL8G+dpisepQjwDF/wyO5bCng+wtTiGGFUJJofOCwJDGeZ6PefllA jK+k2C5s1P2FuJhIdaFWizqAJbLHQGmeoGvrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=aQ7ttsD/wRNS3Da3dDkIAMoF/Ap67rr/BpA+0bZw2Ba9etCyJEsrt06MftStVy4r/u P3t32QWgFkOnD4GEzwF+qIB+ZX0K426runqy9Q3pqOOytSQil1gIBT0GC6E8dJ3bY/8I Uf9ueDf8y8nt39zAqUJ2o6LgrnLcGQDRC0fcc= Received: by 10.204.119.76 with SMTP id y12mr1731312bkq.114.1247216874944; Fri, 10 Jul 2009 02:07:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id 26sm1629065fks.1.2009.07.10.02.07.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 02:07:54 -0700 (PDT) From: "Roni Even" To: "'Monty Montgomery'" References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> <806dafc20907100115u3c9de436o6a76111811da2629@mail.gmail.com> In-Reply-To: <806dafc20907100115u3c9de436o6a76111811da2629@mail.gmail.com> Date: Fri, 10 Jul 2009 12:07:02 +0300 Message-ID: <4a5704ea.1a135e0a.52bd.74fe@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBNpMG+3FD19U/RIeS7Y4oPR9cUgABuu0A Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 09:07:31 -0000 Monty, I was responding to the customer demand. They can go and ask you for a RF codec but to go to a standard body and ask for RF codec so that they can make more profit is not a relevant input. Roni > -----Original Message----- > From: Monty Montgomery [mailto:xiphmont@gmail.com] > Sent: Friday, July 10, 2009 11:15 AM > To: Roni Even > Cc: Dean Bogdanovic; codec@ietf.org > Subject: Re: [codec] Customer demand for royalty-free internet codec > > On Fri, Jul 10, 2009 at 2:58 AM, Roni Even > wrote: > > > I can understand a request for RF codec from non profit solution > providers > > but I can not feel any obligation to support ones that care for their > > revenue stream by getting free product. They can also ask for free > routers > > to connect their networks. > > How is this relevant to conversation? What do free codecs have to do > with free hardware? > > You seem to be arguing that commodity codecs are a patent absurdity > (no pun intended or implied) and yet here we have three offered within > the scope of the WG. > > For the record, I care very much about for-profit ventures using my > free work to enhance their bottom lines-- I want very much for them to > do so. If they want my direct personal development support time, then > we can discuss a reasonable fee. > > Monty From xiphmont@gmail.com Fri Jul 10 03:01:13 2009 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 7BDCE3A6E37 for ; Fri, 10 Jul 2009 03:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 o8YpUEaY2WDX for ; Fri, 10 Jul 2009 03:01:12 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id A7F243A6E24 for ; Fri, 10 Jul 2009 03:01:12 -0700 (PDT) Received: by yxe10 with SMTP id 10so1461119yxe.29 for ; Fri, 10 Jul 2009 03:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U2RVIHRQkrxPKhHuZl6ScI6Hyc+yYdJtMaD/ErpalQc=; b=JkINpYJdLpTaCJdUlVfCLIEjyX8jPNVQuMxIfTb4qCI1QCNvfRz7pqLubM7x9/CySy AccnfocmMLKzOQzFDXgJl3TP1nNsFbnmSfx9RboH2UOFKyZpWvVzArB9lSarBXhp7k8m 9N0byenIqIUU5Gc4Ongl+/HfWM27bSf7gxJZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vgSFK0otxqiqnuAqPQXkehb1sDKtEuh8pj8RNTatMMQwy2vyq8rd5PQH/nm7wW/1gZ PJXNnW0CqTrMyV/ckDDdxifilsgEc+691nMRiMaWWrSCsYtUFRu71RyG5CFGtEcAiiko QjcpUa+hcqoN8nMpW1j2UAgPOLDgIr4G5JNVI= MIME-Version: 1.0 Received: by 10.231.10.137 with SMTP id p9mr580684ibp.18.1247220083097; Fri, 10 Jul 2009 03:01:23 -0700 (PDT) In-Reply-To: <4a5704ea.1a135e0a.52bd.74fe@mx.google.com> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> <806dafc20907100115u3c9de436o6a76111811da2629@mail.gmail.com> <4a5704ea.1a135e0a.52bd.74fe@mx.google.com> Date: Fri, 10 Jul 2009 06:01:23 -0400 Message-ID: <806dafc20907100301r44d33251y586fbac0a8291c67@mail.gmail.com> From: Monty Montgomery To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 10:01:13 -0000 On Fri, Jul 10, 2009 at 5:07 AM, Roni Even wrote: > Monty, > I was responding to the customer demand. They can go and ask you for a RF > codec but to go to a standard body and ask for RF codec so that they can > make more profit is not a relevant input. Sure they can. Forgive the flippant tone below. I'm quite serious. How dare a for-profit company send packets using free TCP/IP over the public network! People worked long and hard on that. Taxpayer dollars went into it. It's just wrong. How dare a company make a profit offering client interoperable email services based on free standards! The IETF obviously erred badly with RFC 822..2822/etc. There could have been a ton of money in email. How dare a company make money off of the web where all the standards are free? Especially a company using the web to increase profits. The W3C are a bunch of suckers. ...so how is audio (and for that matter, video) fundamentally [conceptually/morally] different? It is not rare and precious science despite occasional claims to the contrary. Or, we could just agree this was a completely irrelevant tanget and not get distracted by spurious moral outrage at upstart companies attempting to [gasp] compete more effectively. "Does this WG belong in the IETF" is a valid debate. "No, because companies just want to undercut the current stakeholders" is not a compelling argument even if it's a rather breathtaking one. Monty [too much?] From stephen.botzko@gmail.com Fri Jul 10 03:24:46 2009 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 6D4433A7051 for ; Fri, 10 Jul 2009 03:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.564, 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 68NN2bLnTook for ; Fri, 10 Jul 2009 03:24:45 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id EDC1E3A6E39 for ; Fri, 10 Jul 2009 03:24:38 -0700 (PDT) Received: by fxm18 with SMTP id 18so770633fxm.37 for ; Fri, 10 Jul 2009 03:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=COvvzU5rbTFx8uvAFElxKnz5h9uxpb20OTMaTTBvG6g=; b=Wtm9j4eH/ZY7UCgEoYSe02IYcsREUF2HBoZ2xERsOsty4S6J0xxMOf7ZrZfOyL0vAW x092Lfo0k6fTOx9wtzjimysd6a/osKSmhmG+6bzCSw7SOgHgBsz1Sgq6LlJ1/YkTcCo0 3pttGQT92r7wMolQdIztghj4g9Gx8Ndw6/Jro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lu5o8KtUwnpYQbW1HP/KSLcvSqkovdA6/mXDoCk3kslzz9xfmwKn6Dbkv8KahYhc// x/p3KhzaMKBY3TmxbFt9Ix8JVhMIGcNQfA9tQSBdb+Gaz9gpzpIVPmLuWwwv09QYbJSO 3G/fyItjdyvyXoMVqow+lCIyA+qBBtRXNd9SI= MIME-Version: 1.0 Received: by 10.103.181.2 with SMTP id i2mr1003239mup.20.1247221503413; Fri, 10 Jul 2009 03:25:03 -0700 (PDT) In-Reply-To: <806dafc20907100301r44d33251y586fbac0a8291c67@mail.gmail.com> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <4a56e6ba.0aec660a.45bb.ffffc8e7@mx.google.com> <806dafc20907100115u3c9de436o6a76111811da2629@mail.gmail.com> <4a5704ea.1a135e0a.52bd.74fe@mx.google.com> <806dafc20907100301r44d33251y586fbac0a8291c67@mail.gmail.com> Date: Fri, 10 Jul 2009 06:25:03 -0400 Message-ID: <6e9223710907100325v66305dbfiac780950972a39a1@mail.gmail.com> From: stephen botzko To: Monty Montgomery Content-Type: multipart/alternative; boundary=001636417bcdaacfa6046e57626c Cc: codec@ietf.org Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 10:24:46 -0000 --001636417bcdaacfa6046e57626c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> ... Or, we could just agree this was a completely irrelevant tanget and not get distracted... >>> That would be my vote. Regards, Stephen Botzko Polycom On Fri, Jul 10, 2009 at 6:01 AM, Monty Montgomery wrote: > On Fri, Jul 10, 2009 at 5:07 AM, Roni Even wrote: > > Monty, > > I was responding to the customer demand. They can go and ask you for a RF > > codec but to go to a standard body and ask for RF codec so that they can > > make more profit is not a relevant input. > > Sure they can. Forgive the flippant tone below. I'm quite serious. > > How dare a for-profit company send packets using free TCP/IP over the > public network! People worked long and hard on that. Taxpayer > dollars went into it. It's just wrong. > > How dare a company make a profit offering client interoperable email > services based on free standards! The IETF obviously erred badly with > RFC 822..2822/etc. There could have been a ton of money in email. > > How dare a company make money off of the web where all the standards > are free? Especially a company using the web to increase profits. > The W3C are a bunch of suckers. > > ...so how is audio (and for that matter, video) fundamentally > [conceptually/morally] different? It is not rare and precious science > despite occasional claims to the contrary. > > Or, we could just agree this was a completely irrelevant tanget and > not get distracted by spurious moral outrage at upstart companies > attempting to [gasp] compete more effectively. "Does this WG belong > in the IETF" is a valid debate. "No, because companies just want to > undercut the current stakeholders" is not a compelling argument even > if it's a rather breathtaking one. > > Monty > [too much?] > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636417bcdaacfa6046e57626c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
... Or, we could just agree this was a completely irrelevan= t tanget and
not get distracted...
>>>

That would be my vote.

= Regards,
Stephen Botzko
Polycom

On = Fri, Jul 10, 2009 at 6:01 AM, Monty Montgomery <xiphmont@gmail.com> wrote:
On Fri, Jul 10, 2009 at 5:07 AM, Roni Even<ron.even.tlv@gmail.com> wrote:
> Monty,
> I was responding to the customer demand. They can go and ask you for a= RF
> codec but to go to a standard body and ask for RF codec so that they c= an
> make more profit is not a relevant input.

Sure they can. =A0Forgive the flippant tone below. =A0I'm quite s= erious.

How dare a for-profit company send packets using free TCP/IP over the
public network! =A0People worked long and hard on that. =A0Taxpayer
dollars went into it. =A0It's just wrong.

How dare a company make a profit offering client interoperable email
services based on free standards! =A0The IETF obviously erred badly with RFC 822..2822/etc. =A0There could have been a ton of money in email.

How dare a company make money off of the web where all the standards
are free? =A0Especially a company using the web to increase profits.
The W3C are a bunch of suckers.

...so how is audio (and for that matter, video) fundamentally
[conceptually/morally] different? =A0It is not rare and precious science despite occasional claims to the contrary.

Or, we could just agree this was a completely irrelevant tanget and
not get distracted by spurious moral outrage at upstart companies
attempting to [gasp] compete more effectively. =A0"Does this WG belong=
in the IETF" is a valid debate. =A0"No, because companies just wa= nt to
undercut the current stakeholders" is not a compelling argument even if it's a rather breathtaking one.

Monty
[too much?]
_________________________________________= ______
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636417bcdaacfa6046e57626c-- From stephen.botzko@gmail.com Fri Jul 10 03:58:36 2009 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 E05143A6DC3 for ; Fri, 10 Jul 2009 03:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 EtCL+fDc6R9V for ; Fri, 10 Jul 2009 03:58:35 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C3A7E3A6D3F for ; Fri, 10 Jul 2009 03:58:34 -0700 (PDT) Received: by fxm18 with SMTP id 18so790232fxm.37 for ; Fri, 10 Jul 2009 03:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=B3Zj0bZ8F0gZrhq9AbBaZT0HaYnlSr0j8n0fcpxHz0g=; b=LVxVVOBhgxV9g+rcAjY+favuuMRHZFQOSWOS/D2bO8pj+X/h2FIN/nwJ6sQ/yOanvz WEovsyoakE7STNNh3b+XPRsdHdQd4BI2y36dyvmCTv7WKkTsDAIR3idX3fsMDpK+mUhX EToNJBnBx5D2zCGOfpyaxftDL1VgKDwDipsVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vNqzVkF6pc1d1qjt0Y3Of9ARJTp4yH6l1YUIUQW/EP3RGokAdKdKj2p/YeWm/sIbV0 nFZpxmYcGQFoZqBGzHyICUOmTB02fPEFvD+YMGd/RnM3M0Uupbcvzp72O9rxOLs0hGMg ehmB8xKINHOdTi2p8grspz+dtf1n6TQkYMu0o= MIME-Version: 1.0 Received: by 10.103.24.11 with SMTP id b11mr987473muj.133.1247223540467; Fri, 10 Jul 2009 03:59:00 -0700 (PDT) In-Reply-To: <002a01ca00e5$0fbff6b0$2f3fe410$@de> References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <002a01ca00e5$0fbff6b0$2f3fe410$@de> Date: Fri, 10 Jul 2009 06:59:00 -0400 Message-ID: <6e9223710907100359n42cab8c3wbac5daece4a37993@mail.gmail.com> From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e65a0dc415c7c2046e57dc6d Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 10:58:37 -0000 --0016e65a0dc415c7c2046e57dc6d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments in-line Stephen Botzko Polycom On Thu, Jul 9, 2009 at 6:31 PM, Christian Hoene wro= te: > Hello Stephen and all, > > thank you your very good statements on how to make this WG a success. > > This mailing list has shown enough interest from various sides. The WG wi= ll > not die because of lack of interest. Also, beside internet guys also a > sufficient number of =93open source=94 and =93traditional=94 coding exper= ts are > participating in the discussions. I do not see a danger that this WG will > not be started. > > But I have to agree that I am missing somebody who plays the role of the > moderator of the discussion. I just remember the talk with the chair of a > ITU Study Group 12 working group. He told me that he has an own proposal > but > he cannot bring it into play because of his role as moderator. Hopefully, > some moderator can be found for this WG - with an own codec in his lab or > without it... Yes, I still have this concern. I am not so worried about the working grou= p (when and if). I am concerned about the BOF discussion. It's difficult to moderate a discussion like this when you are a stakeholder, and still be perceived as fair. > > > I do not believe that a new codec standardization process should be > invented. Having different requirements and excellent new codec designs > should be enough innovations. > > If so, what is the traditional process on codec standardization? Isn=92t = it > something like this: > 1.) Establishment of a set of working procedures > 2.) Definition of requirements, objects (both including priorities), > quality > parameters and procedures on how to measure these parameters. > 3.) Developing codecs... > 4.) Characterization and testing of the codec proposals. > 5.) Selecting one, merging them or jump back to 2.) > 6.) Standardization of the codec and definition of conformance tests. > > Both the ITU and 3GPP must have well defined procedures, which we should > look at. Of course, they should be adopted only partly and carefully to n= ot > hinder the goals of this WG. I agree that it would be most efficient to start with existing procedures, and see how they fit. I would also include the process used by JVT for vide= o as another possible model. > > > Regards, > Christian > > ________________________________ > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > stephen botzko > Sent: Thursday, July 09, 2009 8:45 PM > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > Given the goal of the BOF, the aim is for a moderated discussion of the > merits (pro and con). So I agree that it would be prudent to have chairs > who reflect the various views. It will make it easier to keep the meetin= g > orderly and moving, since no one will feel that the chairs shut them down > because they didn't agree with their views. "Success" here is not measur= ed > by whether a WG is created (or not). "Success" is providing quality inpu= t > to the IESG on the merits from a broad range of participants. > > Please understand that I am not saying that I think Jean-Marc and Jason > would be deliberately unfair. I am saying that we should anticipate a > lively > discussion without clear consensus. So moderating it is likely to be > challenging. Also, it will not be easy for Jean-Marc and Jason to presen= t > their personal views while they are also acting as chairs. For these > reasons, I think that if the chairs all hold one view, the BOF is unlikel= y > to be successful (using my definition above). > > As far as codecs go, I think there is some value in having a couple of > sample submissions to look at. However, time will be valuable in the BOF= . > I think we should assume that the IESG will be able to assess the sample > contributions without our needing to spend a lot of time discussing them. > > Also, before anything can move forward there needs to be (a) a chartered > working group and (b) an established set of working procedures. The > proposed > charter's output is a single codec, not multiple codecs. There would nee= d > to be a common understanding of whether the working group is selecting a > single codec from the candidates, or somehow developing a common codec fr= om > more than one candidate. There would also need to be some consensus on t= he > basis for codec selection (and/or technology development), and some > consensus on how to measure the codec performance against the various > requirements, and of course at some point there will be more precision > needed on the IPR rules. > > It will be very difficult to invent the process while we are simultaneous= ly > talking about codec technology. I'd think the WG (if it goes forward) > would > need to spend some time hammering out a working process before it will be > ready to accept candidates for consideration. Perhaps some more focused > discussion on these points ahead of time would be helpful to the IESG, an= d > to the WG (when and if).. > > IMHO we ought to refrain from accusing people of "killing", There is > nothing to kill at this point. Polarizing the debate by labeling the > participants is not a constructive way to proceed. The genuine areas of > disagreement are hard enough. > > Stephen Botzko > Polycom > On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S > wrote: > Hi > > This is yet another reason why I think it is best to select chairs for th= is > who reflect the different opinions around this subject. If this is not do= ne > I fear that this BoF will just end up in a verbal fist-fight and nobody > benefits from it, it will only make us all look like morons. > Also I am not trying to kill any codec, I just don't see how it fits in t= he > IETF, thats why I wish to have all issues discussed. Selection of codecs = is > secondary and can be discussed once/if a formation of the WG is decided. > > Personally I don't know what this "banned" stuff inserted by the server i= s > about... > > Regards > Ingemar > > ________________________________ > > Fr=E5n: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Skickat: to 2009-07-09 16:22 > Till: Ingemar Johansson S; codec@ietf.org > =C4mne: Re: [codec] Updated Agenda for Codec BOF > > > All these efforts to kill the free Internet voice codec before it is even > born! > > There must be a very big stake to do this... > > Henry > > On 7/9/09 8:43 AM, "Ingemar Johansson S" > wrote: > > > > WARNING: contains banned part > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --0016e65a0dc415c7c2046e57dc6d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments in-line

Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 6:31 PM, Christian Hoene = <hoene@uni-tuebingen.de>= ; wrote:
Hello Stephen and= all,

thank you your very good statements on how to make this WG a success.

This mailing list has shown enough interest from various sides. The WG will=
not die because of lack of interest. Also, beside internet guys also a
sufficient number of =93open source=94 and =93traditional=94 coding experts= are
participating in the discussions. I do not see a danger that this WG will not be started.

But I have to agree that I am missing somebody who plays the role of the moderator of the discussion. I just remember the talk with the chair of a ITU Study Group 12 working group. He told me that he has an own proposal bu= t
he cannot bring it into play because of his role as moderator. Hopefully, some moderator can be found for this WG - with an own codec in his lab or without it...
=A0
Yes, I still have this concern= .=A0 I am not so worried about the working group (when and if).=A0 I am con= cerned about the BOF discussion.=A0 It's difficult to moderate a discus= sion like this when you are a stakeholder, and still be perceived as fair.<= br> =A0


I do not believe that a new codec standardization process should be
invented. Having different requirements and excellent new codec designs
should be enough innovations.

If so, what is the traditional process on codec standardization? Isn=92t it=
something like this:
1.) Establishment of a set of working procedures
2.) Definition of requirements, objects (both including priorities), qualit= y
parameters and procedures on how to measure these parameters.
3.) Developing codecs...
4.) Characterization and testing of the codec proposals.
5.) Selecting one, merging them or jump back to 2.)
6.) Standardization of the codec and definition of conformance tests.


Both the ITU and 3GPP must have well defined procedures, which we should look at. Of course, they should be adopted only partly and carefully to not=
hinder the goals of this WG.

I agree that it would be = most efficient to start with existing procedures, and see how they fit. I would also include the process used by JVT for video as another possible model.=A0


Regards,
=A0Christian

________________________________

From: codec-bounces@ietf.org = [mailto:codec-bounces@ietf.org] On Behalf Of
stephen botzko
Sent: Thursday, July 09, 2009 8:45 PM
To: Ingemar Johansson S
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec BOF

Given the goal of the BOF, the aim is for a moderated discussion of the
merits (pro and con).=A0 So I agree that it would be prudent to have chairs=
who reflect the various views.=A0 It will make it easier to keep the meetin= g
orderly and moving, since no one will feel that the chairs shut them down because they didn't agree with their views.=A0 "Success" here= is not measured
by whether a WG is created (or not).=A0 "Success" is providing qu= ality input
to the IESG on the merits from a broad range of participants.

Please understand that I am not saying that I think Jean-Marc and Jason
would be deliberately unfair. I am saying that we should anticipate a livel= y
discussion without clear consensus. So moderating it is likely to be
challenging.=A0 Also, it will not be easy for Jean-Marc and Jason to presen= t
their personal views while they are also acting as chairs.=A0 For these
reasons, I think that if the chairs all hold one view, the BOF is unlikely<= br> to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of
sample submissions to look at.=A0 However, time will be valuable in the BOF= .=A0
I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing them.
Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The propose= d
charter's output is a single codec, not multiple codecs.=A0 There would= need
to be a common understanding of whether the working group is selecting a single codec from the candidates, or somehow developing a common codec from=
more than one candidate.=A0 There would also need to be some consensus on t= he
basis for codec selection (and/or technology development), and some
consensus on how to measure the codec performance against the various
requirements, and of course at some point there will be more precision
needed on the IPR rules.=A0

It will be very difficult to invent the process while we are simultaneously=
talking about codec technology.=A0 I'd think the WG (if it goes forward= ) would
need to spend some time hammering out a working process before it will be ready to accept candidates for consideration. Perhaps some more focused
discussion on these points ahead of time would be helpful to the IESG, and<= br> to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing",=A0 Th= ere is
nothing to kill at this point.=A0 Polarizing the debate by labeling the
participants is not a constructive way to proceed.=A0 The genuine areas of<= br> disagreement are hard enough.

Stephen Botzko
Polycom
On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S
<ingemar.s.johansson= @ericsson.com> wrote:
Hi

This is yet another reason why I think it is best to select chairs for this=
who reflect the different opinions around this subject. If this is not done=
I fear that this BoF will just end up in a verbal fist-fight and nobody
benefits from it, it will only make us all look like morons.
Also I am not trying to kill any codec, I just don't see how it fits in= the
IETF, thats why I wish to have all issues discussed. Selection of codecs is=
secondary and can be discussed once/if a formation of the WG is decided.
Personally I don't know what this "banned" stuff inserted by = the server is
about...

Regards
Ingemar

________________________________

Fr=E5n: Henry Sinnreich [mailto:hsinn= rei@adobe.com]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; codec@ietf.org=
=C4mne: Re: [codec] Updated Agenda for Codec BOF


All these efforts to kill the free Internet voice codec before it is even born!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com
<https://rvi.se.ericsson.net/dana-cached/help/empty.html&= gt; > wrote:



=A0 =A0 =A0 =A0WARNING: contains banned part


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



--0016e65a0dc415c7c2046e57dc6d-- From stephen.botzko@gmail.com Fri Jul 10 04:26:55 2009 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 CB3283A6E4B for ; Fri, 10 Jul 2009 04:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.568, 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 eMClaHikkQVN for ; Fri, 10 Jul 2009 04:26:55 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 4F7C93A6E14 for ; Fri, 10 Jul 2009 04:26:54 -0700 (PDT) Received: by bwz25 with SMTP id 25so797104bwz.37 for ; Fri, 10 Jul 2009 04:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Kr4zRqJjYvDvtDPIRu8bYHhafDD5slovdLwAE0i8fS0=; b=xMurd6hzJ4Taq5kjPxdBepa77oKDvT/kojFoRcSlKL21Zi3rDn+VQ8wP8DtPnuCRgS BnolEFpS5p6FXIwlsOpQ3Ag974qzFAsvtOeMDg382QOuZxsV5gndJw3ca7xpPuRoiya1 bnp8wg8JMRXHQkC35vGHGAFVSxFcTc5dJf5uM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m3PSNkoe/TXFJXLMguUQecDhlJfryoKI3cdBotcNvj7XKVo4rOI95QkiiRdzz/fFb4 g0fnXLhaF/SwiOFuYLwcPRADfFb6oHasP7WL84FeG/rLflOBTotrLrYOBEVrUqzrK1RT 9WcqaumOvB1p639E0qFajc7YHbAdSVqppUiEs= MIME-Version: 1.0 Received: by 10.103.131.13 with SMTP id i13mr1044019mun.64.1247225188854; Fri, 10 Jul 2009 04:26:28 -0700 (PDT) In-Reply-To: <4A56496D.4060807@octasic.com> References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> Date: Fri, 10 Jul 2009 07:26:28 -0400 Message-ID: <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> From: stephen botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001636416adf562add046e583e6a Cc: Ingemar Johansson S , Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:26:55 -0000 --001636416adf562add046e583e6a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry to disagree on this. - A 25 minute presentation is not "short" in a 2 hour meeting. 5 minutes would be short. - SILK and CELT are well known, and can be studied/reviewed by anyone interested off-line. The net effect of a 25 minute codec presentation by WG proponents is to remove 25 minutes of discussoin time. A second effect is that it biases th= e time allotment in favor of proponents, which acts to skew the input to IESG in that direction. Arguments against are just as important as arguments for at this point in the process. Perhaps a compromise is possible? Move item 4 to the *end* of the agenda, and make it the "time permits" activity? Or (IMHO better still) create a *separate* informal session (perhaps during the lunch break) where you present SILK and CELT to anyone interested in more information about them? Then you can go into more detail. Regards Stephen Botzko Polycom On Thu, Jul 9, 2009 at 3:47 PM, Jean-Marc Valin wrote: > Slava Borilin wrote: > >> I agree with Stephen that it would be better to EXCLUDE #4 from agenda = =96 >> as this may be time consuming. >> > > Just to clarify. This part of the agenda is intended to address the point= s > that were raised about the feasibility of the work. It will also show wha= t > requirements are achievable in a short time frame. The presentations will= be > short and high level, not technical descriptions of the codecs internals. > > Instead I would like to get back the item =93requirements for codec, as = they >> may look like from IETF perspective=94 (royalty-free, license-free from = legal, >> + technical (packet loss, MOS, performance)). >> > > This should probably belong to the charter discussion, along with > discussion of the process if (I hope) time permits. > > Cheers, > > Jean-Marc > --001636416adf562add046e583e6a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry to disagree on this.

- A 25 minute presentation is not "s= hort" in a 2 hour meeting.=A0 5 minutes would be short.
- SILK and = CELT are well known, and can be studied/reviewed by anyone interested off-l= ine.

The net effect of a 25 minute codec presentation by WG proponents is to= remove 25 minutes of discussoin time.=A0 A second effect is that it biases= the time allotment in favor of proponents, which acts to skew the input to= IESG in that direction. Arguments against are just as important as argumen= ts for at this point in the process.

Perhaps a compromise is possible?=A0 Move item 4 to the end of t= he agenda, and make it the "time permits" activity?=A0

Or= (IMHO better still) create a separate informal session (perhaps dur= ing the lunch break) where you present SILK and CELT to anyone interested i= n more information about them?=A0 Then you can go into more detail.

Regards
Stephen Botzko
Polycom

= On Thu, Jul 9, 2009 at 3:47 PM, Jean-Marc Valin <jean-marc.valin@octasic.com&g= t; wrote:
Slava Borilin wrote:
I agree with Stephen that it would be better to EXCLUDE #4 from agenda =96 = as this may be time consuming.

Just to clarify. This part of the agenda is intended to address the points = that were raised about the feasibility of the work. It will also show what = requirements are achievable in a short time frame. The presentations will b= e short and high level, not technical descriptions of the codecs internals.=


Instead I would like to get back the item =93requirements for codec, as the= y may look like from IETF perspective=94 (royalty-free, license-free from l= egal, + technical (packet loss, MOS, performance)).

This should probably belong to the charter discussion, along with discussio= n of the process if (I hope) time permits.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

--001636416adf562add046e583e6a-- From stpeter@stpeter.im Fri Jul 10 08:04:56 2009 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 E9F853A69D5 for ; Fri, 10 Jul 2009 08:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Kh2alQn0lQKJ for ; Fri, 10 Jul 2009 08:04:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9D21828C33A for ; Fri, 10 Jul 2009 08:04:40 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C7414007B; Fri, 10 Jul 2009 09:05:08 -0600 (MDT) Message-ID: <4A575430.8050906@stpeter.im> Date: Fri, 10 Jul 2009 08:46:08 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: stephen botzko References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> In-Reply-To: <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ingemar Johansson S , Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:04:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/09 5:26 AM, stephen botzko wrote: > Sorry to disagree on this. > > - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > minutes would be short. > - SILK and CELT are well known, and can be studied/reviewed by anyone > interested off-line. > > The net effect of a 25 minute codec presentation by WG proponents is to > remove 25 minutes of discussoin time. A second effect is that it biases > the time allotment in favor of proponents, which acts to skew the input > to IESG in that direction. Arguments against are just as important as > arguments for at this point in the process. > > Perhaps a compromise is possible? Move item 4 to the _end_ of the > agenda, and make it the "time permits" activity? How about 5 minutes to discuss each of the codec I-Ds at a high level? Allotting 10 minutes out of 2 hours to existence proofs and what they imply for the work of the Codec WG (if approved) seems helpful to me. Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can productively talk about how these codecs could be used as input to a working group. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV =bx98 -----END PGP SIGNATURE----- From rjesup@wgate.com Fri Jul 10 08:39:46 2009 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 A6E3B3A6A4B for ; Fri, 10 Jul 2009 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 0KIqHTiM4oEt for ; Fri, 10 Jul 2009 08:39:46 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 7A53A3A690E for ; Fri, 10 Jul 2009 08:39:45 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 11:40:13 -0400 To: Dean Bogdanovic References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> From: Randell Jesup Date: Fri, 10 Jul 2009 11:41:53 -0400 In-Reply-To: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> (Dean Bogdanovic's message of "Fri\, 10 Jul 2009 00\:20\:14 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jul 2009 15:40:13.0621 (UTC) FILETIME=[B7472E50:01CA0174] Cc: codec@ietf.org Subject: Re: [codec] Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:39:46 -0000 Dean Bogdanovic writes: >After reading discussions on this topic, thought to add customer view on >this one. > >In the last 12 month, I've participated in several customer projects in >Asia, Africa and Europe. All of them were trying to add voip over their 3G >data networks as service and were looking for low-latency royalty free >codec. Two of the projects were interesting, as different carriers >connected their voip networks and allowed traffic between voip UAs >directly (no PSTN interconnect). The biggest problem ended up being codec, >as the results of testing with different royalty free codecs weren't >satisfying. What was the result of testing with iLBC? Did they test that? Was the issue the lack of adaptive capability, or was wideband required? >In general, carrier groups are looking to use IP as primary communication >mechanism among their group members and for them royalty free, >adaptive/low latency is really important, as (Asia, Africa and part of >Europe) their subs have low ARPU and many of them are traveling for work >outside of their home countries. So you have carrier groups covering all >those countries, but they don't have an (cheap) option to provide >affordable service to their customers. The cheaper they can obtain the codecs (especially when they can avoid the PSTN network), the cheaper they can provide service, and the more people who can afford their service. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From fluffy@cisco.com Fri Jul 10 09:42:43 2009 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 6677628C29B for ; Fri, 10 Jul 2009 09:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1wK85gZ7fEUw for ; Fri, 10 Jul 2009 09:42:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5B71D3A6C82 for ; Fri, 10 Jul 2009 09:42:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,379,1243814400"; d="scan'208";a="341481182" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2009 16:43:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6AGh9lR024727; Fri, 10 Jul 2009 09:43:09 -0700 Received: from [192.168.1.75] ([10.21.77.167]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6AGh8PE006960; Fri, 10 Jul 2009 16:43:08 GMT Message-Id: <6A5F01E3-F9C3-4C97-AC3D-8B4FA6992689@cisco.com> From: Cullen Jennings To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 09:43:08 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2878; t=1247244189; x=1248108189; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Selection=20of=20BOF=20Chairs |Sender:=20; bh=JvR9M0ZFrOFJYKJxeFYb6zJC4gM0i/QGQ40I4Ke3byg=; b=JukPuscsy0p37j0a29sXv/lfjhmOVnCBiuEZJaYW0ja+XKS0rQc88sENju j/MGQ0KM6CpU218Eo9LSLOefiJ459lWN4C3zOvL0HNtk6BXMObvaD7qsz5A+ zlmyJPXkKn; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [codec] Selection of BOF Chairs X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:42:43 -0000 There has been a bunch of discussion on if the BOF chairs are biased or not. The key question this BOF is devoting nearly all it's time to is the questions of should the IETF form a WG to do this work. Let's be 100% clear here - both chairs are clearly in favor of a YES answer to this. Everyone involved was well aware of this when they were chosen as BOF chairs. It takes a lot of energy to arrange and facilitate the discussion to make a complicated BOF happen (and this one is complicated). Both of theses people are deeply involved with leading groups that are building some of the widely used codecs on the internet today. They have a lot of energy and passion about it and also significant experience in the business environment these would be used it, the needs of the users, and the types of networks they are deployed on. It's easy to find other people around that also have lots of experience in this but it's hard to find ones that have the time and energy to run a BOF. This situation is not unusual, the bulk of the WG BOFs I have been at were nearly all chaired by people who were proponents of the work moving forward. The information presented at a BOF is not controlled by the chairs and I fully expect to hears the Pros and the Cons for this work in the BOF meeting. It's not like the chairs have any control over who decides to talk up to the microphone in the meeting. As a practical matter, we have enough problems to deal with in this BOF. Lets deal with real problems as they come up and not worry about hypothetical ones. Lets make sure the discussion is going to give the right opportunities for all view to be represented on topics that are important input for the IESG making a decision about this. If you think the chairs are doing the wrong thing - by all means - make Robert and I aware of that and it we will get to the bottom of it. I'm sure that mistakes will be made along the way but IETF process is good at fixing mistakes and getting the right thing to happen. I'm easy to reach: emails works, for IM I am cullenfluffyjennings@gmail.com, my work phone is +1 408 902 3341 and if you really need me right away my mobile is +1 408 421 9990. I'm glad to help get problems sort out such that we can have discussion of all the useful points at the BOF. I am not keen on changing horses mid stream but if that was required to have a BOF that represented all sides of the debate, I would do it. Cullen PS. It is worth mentioning that if a WG was formed, the criteria for selection of WG chairs is very different than BOF chairs and thought sometimes it ends up being the same people, Robert and I have not even started thinking about who could chair a WG. We would be considering a wide range of candidates From ron.even.tlv@gmail.com Fri Jul 10 09:44:45 2009 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 D99B03A67AE for ; Fri, 10 Jul 2009 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgGeqr4NCHhv for ; Fri, 10 Jul 2009 09:44:44 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 6B56928C28E for ; Fri, 10 Jul 2009 09:44:04 -0700 (PDT) Received: by fxm18 with SMTP id 18so1012393fxm.37 for ; Fri, 10 Jul 2009 09:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=hEKU+0OLodRa+iI9zMIP1nqUey0YRrDgVh781LOg5A0=; b=pdTxfqYwflEHgMxQYYbapLbrMM9XPoDggpOxOAguX1aP1w8uTh2rcCd6Iu2Q3WN9QN DvwmwWVW6kAxmzHPK3VBERhheP1G+vH04iorH2PlX5Ec1yJd7U7WYtCMYO2iT1TScush amlVKXOWcTYvgrrL1LyNVTTlBHRa/dwbNdup0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=YF3JimHYFuy61TbSEUeKofiYX5UQZb+E+KIb9Of/UaAiR5m5Oj2oDNLZOpTP6grrxo 9lvfVKbOfgjKXXNAOhdmI2wfqX0PJmrb/e9xH9JQPppJAwijFEQWxmgjL2DQRuHr57HU +/PUtiNVKrlgib4bUPGW1GN/Old5v79Z3MyEA= Received: by 10.103.193.13 with SMTP id v13mr1186574mup.136.1247244270354; Fri, 10 Jul 2009 09:44:30 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id e8sm6884150muf.36.2009.07.10.09.44.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 09:44:29 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" , "'stephen botzko'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> In-Reply-To: <4A575430.8050906@stpeter.im> Date: Fri, 10 Jul 2009 19:43:37 +0300 Message-ID: <4a576fed.08b6660a.449e.4bc7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBb9y/7WwG21mETUqqqQ2f/WM5tgAC7uBg Content-Language: en-us Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:44:45 -0000 Hi, I still fail to see what is the value in presenting one, two or three codecs. I saw that there was a request to present a third one. I can agree that there are people who can present codecs as a suggested solution including existing ones. Since there is no charter yet under which the codecs are to be specified it may serve as a tutorial on codecs. So if we open to codec presentation in the BOF let allow everyone to present their codecs including ITU and MPEG ones and spend the whole BOF of the different codecs technologies. If the idea behind this presentation is to show specific functionality than instead it will be more fruitful to present requirements, since I could see from the list discussion that there is no consensus even between the current proponents what the requirements are. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, July 10, 2009 5:46 PM > To: stephen botzko > Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/10/09 5:26 AM, stephen botzko wrote: > > Sorry to disagree on this. > > > > - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > > minutes would be short. > > - SILK and CELT are well known, and can be studied/reviewed by anyone > > interested off-line. > > > > The net effect of a 25 minute codec presentation by WG proponents is > to > > remove 25 minutes of discussoin time. A second effect is that it > biases > > the time allotment in favor of proponents, which acts to skew the > input > > to IESG in that direction. Arguments against are just as important as > > arguments for at this point in the process. > > > > Perhaps a compromise is possible? Move item 4 to the _end_ of the > > agenda, and make it the "time permits" activity? > > How about 5 minutes to discuss each of the codec I-Ds at a high level? > Allotting 10 minutes out of 2 hours to existence proofs and what they > imply for the work of the Codec WG (if approved) seems helpful to me. > Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can > productively talk about how these codecs could be used as input to a > working group. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 > TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV > =bx98 > -----END PGP SIGNATURE----- > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Fri Jul 10 10:10:32 2009 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 DE97A28C1D3 for ; Fri, 10 Jul 2009 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.626 X-Spam-Level: ** X-Spam-Status: No, score=2.626 tagged_above=-999 required=5 tests=[AWL=-3.695, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_KOI8R=0.67] 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 0ZBeANrpbqvK for ; Fri, 10 Jul 2009 10:10:32 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id AE96B3A6858 for ; Fri, 10 Jul 2009 10:10:31 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6AHAtsX043162; Fri, 10 Jul 2009 21:10:56 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Received: from 192.168.125.5 ([192.168.125.5]) by mail-srv.spiritcorp.com ([192.168.125.3]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Jul 2009 17:10:49 +0000 MIME-Version: 1.0 Content-class: From: "Slava Borilin" Message-ID: <001501ca0181$5f6fcc70$057da8c0@spiritcorp.com> Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2009 21:10:01 +0400 Importance: normal X-Priority: 3 To: "Roni Even" , "'Peter Saint-Andre'" , "'stephen botzko'" thread-topic: RE: [codec] Updated Agenda for Codec BOF thread-index: AcoBb9y/7WwG21mETUqqqQ2f/WM5tgAC7uBgAAFxzAA= X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org Subject: [codec] =?koi8-r?b?7uE6IFJFOiAgVXBkYXRlZCBBZ2VuZGEgZm9yIENvZGVj?= =?koi8-r?b?IEJPRg==?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:10:33 -0000 Free tutorial on codecs during the IETF but outside BoF sounds to be = good workaround. Is there a place for it on Wed or Thu? (it better be = before BoF imho) Slava Borilin ----- =E9=D3=C8=CF=C4=CE=CF=C5 =D3=CF=CF=C2=DD=C5=CE=C9=C5 ----- =EF=D4: Roni Even =EF=D4=D0=D2=C1=D7=CC=C5=CE=CF: 10 =C9=C0=CC=D1 2009 =C7. 20:44 =EB=CF=CD=D5: 'Peter Saint-Andre' ; 'stephen botzko' = =EB=CF=D0=C9=D1: 'Ingemar Johansson S' = ; 'Slava Borilin' = ; codec@ietf.org =F4=C5=CD=C1: RE: [codec] Updated Agenda for Codec BOF Hi, I still fail to see what is the value in presenting one, two or three codecs. I saw that there was a request to present a third one.=20 I can agree that there are people who can present codecs as a suggested solution including existing ones. Since there is no charter yet under = which the codecs are to be specified it may serve as a tutorial on codecs. So = if we open to codec presentation in the BOF let allow everyone to present = their codecs including ITU and MPEG ones and spend the whole BOF of the = different codecs technologies.=20 If the idea behind this presentation is to show specific functionality = than instead it will be more fruitful to present requirements, since I could = see from the list discussion that there is no consensus even between the = current proponents what the requirements are. Roni Even=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, July 10, 2009 5:46 PM > To: stephen botzko > Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 7/10/09 5:26 AM, stephen botzko wrote: > > Sorry to disagree on this. > > > > - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > > minutes would be short. > > - SILK and CELT are well known, and can be studied/reviewed by = anyone > > interested off-line. > > > > The net effect of a 25 minute codec presentation by WG proponents is > to > > remove 25 minutes of discussoin time. A second effect is that it > biases > > the time allotment in favor of proponents, which acts to skew the > input > > to IESG in that direction. Arguments against are just as important = as > > arguments for at this point in the process. > > > > Perhaps a compromise is possible? Move item 4 to the _end_ of the > > agenda, and make it the "time permits" activity? >=20 > How about 5 minutes to discuss each of the codec I-Ds at a high level? > Allotting 10 minutes out of 2 hours to existence proofs and what they > imply for the work of the Codec WG (if approved) seems helpful to me. > Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can > productively talk about how these codecs could be used as input to a > working group. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 > TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV > =3Dbx98 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stpeter@stpeter.im Fri Jul 10 10:17:53 2009 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 833AB3A693A for ; Fri, 10 Jul 2009 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Me5snAP40AyL for ; Fri, 10 Jul 2009 10:17:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5C56A3A6858 for ; Fri, 10 Jul 2009 10:17:52 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6C6CE4007B; Fri, 10 Jul 2009 11:18:20 -0600 (MDT) Message-ID: <4A5777DB.4080400@stpeter.im> Date: Fri, 10 Jul 2009 11:18:19 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Roni Even References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> In-Reply-To: <4a576fed.08b6660a.449e.4bc7@mx.google.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:17:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/09 10:43 AM, Roni Even wrote: > Hi, > I still fail to see what is the value in presenting one, two or three > codecs. Present them as existence proofs (yes, we can!) and provide lessons learned as input to the kind of work that a Codec WG would pursue. We need to know that it is within the realm of possibility for a Codec WG to be successful. > I saw that there was a request to present a third one. Which? > I can agree that there are people who can present codecs as a suggested > solution including existing ones. No. As far as I can see these are *not* suggested solutions. The point is show that we have the expertise within the IETF to pursue this work, to learn how those codecs were developed, and to judge whether we think even better codecs could be developed by a Codec WG. > Since there is no charter yet under which > the codecs are to be specified it may serve as a tutorial on codecs. Given that the IETF has not traditionally been home to codec work, I think that a very brief tutorial on what's involved in such work would be quite beneficial. > So if > we open to codec presentation in the BOF let allow everyone to present their > codecs including ITU and MPEG ones and spend the whole BOF of the different > codecs technologies. Don't be ridiculous. Two or three proof points should be plenty. > If the idea behind this presentation is to show specific functionality I don't think that's the idea. > than > instead it will be more fruitful to present requirements, since I could see > from the list discussion that there is no consensus even between the current > proponents what the requirements are. Discussion of existence proofs and lessons learned from previous codec work is not at odds with discussion of requirements. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXd9sACgkQNL8k5A2w/vzbdwCgxU2s6pjxTWp67WE30oJd/s1F L6AAn3s7EmSR3aDYrX0Pz79Rnjc36oVm =8ctr -----END PGP SIGNATURE----- From jason.fischl@skype.net Fri Jul 10 10:37:16 2009 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 04C5928C1D3 for ; Fri, 10 Jul 2009 10:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=2.222, 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 5zW77L+B2Ycr for ; Fri, 10 Jul 2009 10:37:14 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 71AF328C31B for ; Fri, 10 Jul 2009 10:37:14 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 421B9200772E9; Fri, 10 Jul 2009 19:37:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=cc:message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; s=mail; bh=ZV+/zvfLBa4A3X 79K1kl0IssOkY=; b=K3GSFAlVX5MqqHcDqPWllootcCcjm0lVAS8+LtMm8t/i9Y 1UWnSo0zqakpFHFBSGXoUiT7XjGxa7vf5Lknvi9KYTx+A59dZSYSNYlKHiFiqyc6 v6pCbknvX6moMyyY//Gvm5kVs+2NxW7VRfWAgsrY5bWWnuH4drZtPznSn/V60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=cc:message-id:from :to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s=mail; b=bHOEFjAm 2uQbKqcQHkH/+7c+5n824Fih7Li9fTXgu9l38U9/yrqkznpN8IJ0Tpb9lKGEQpsB 1be1SSDaYxB9T1g4ve0i5tXqhRYfeejGca3uurHR35lnufoM1/J80KtYV7ruSCwr zoJD44BBY50b0AOAm3lQVZUlEVOzB3iiSE4= Received: from [10.0.1.28] (c-69-181-180-22.hsd1.ca.comcast.net [69.181.180.22]) by mail.skype.net (Postfix) with ESMTPSA id AEF352007A7FD; Fri, 10 Jul 2009 19:37:40 +0200 (CEST) Message-Id: <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> From: Jason Fischl To: "Roni Even" In-Reply-To: <4a576fed.08b6660a.449e.4bc7@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 10:37:37 -0700 References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> X-Mailer: Apple Mail (2.935.3) Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:37:16 -0000 The point of briefly presenting a few codecs is to show the type of work that would be done in the working group and to address the feasibility of the goal. It is not to present the issues with the particular codecs or even the details of the codecs. There have been assertions on the list that the IETF lacks the expertise to do this work. This agenda item attempts to address that concern. I'd also like to encourage other people to post to the list with their opinions on whether or not agenda item 4 (codecs) should be included. As Stephen suggests, Jean-Marc and I will arrange for a lunch codec tutorial session prior to the BOF on Wednesday or Thursday. Jason On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > Hi, > I still fail to see what is the value in presenting one, two or three > codecs. I saw that there was a request to present a third one. > I can agree that there are people who can present codecs as a > suggested > solution including existing ones. Since there is no charter yet > under which > the codecs are to be specified it may serve as a tutorial on codecs. > So if > we open to codec presentation in the BOF let allow everyone to > present their > codecs including ITU and MPEG ones and spend the whole BOF of the > different > codecs technologies. > If the idea behind this presentation is to show specific > functionality than > instead it will be more fruitful to present requirements, since I > could see > from the list discussion that there is no consensus even between the > current > proponents what the requirements are. > > Roni Even > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf >> Of Peter Saint-Andre >> Sent: Friday, July 10, 2009 5:46 PM >> To: stephen botzko >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org >> Subject: Re: [codec] Updated Agenda for Codec BOF >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/10/09 5:26 AM, stephen botzko wrote: >>> Sorry to disagree on this. >>> >>> - A 25 minute presentation is not "short" in a 2 hour meeting. 5 >>> minutes would be short. >>> - SILK and CELT are well known, and can be studied/reviewed by >>> anyone >>> interested off-line. >>> >>> The net effect of a 25 minute codec presentation by WG proponents is >> to >>> remove 25 minutes of discussoin time. A second effect is that it >> biases >>> the time allotment in favor of proponents, which acts to skew the >> input >>> to IESG in that direction. Arguments against are just as important >>> as >>> arguments for at this point in the process. >>> >>> Perhaps a compromise is possible? Move item 4 to the _end_ of the >>> agenda, and make it the "time permits" activity? >> >> How about 5 minutes to discuss each of the codec I-Ds at a high >> level? >> Allotting 10 minutes out of 2 hours to existence proofs and what they >> imply for the work of the Codec WG (if approved) seems helpful to me. >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can >> productively talk about how these codecs could be used as input to a >> working group. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV >> =bx98 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 stpeter@stpeter.im Fri Jul 10 10:42:29 2009 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 3D6D028C28E for ; Fri, 10 Jul 2009 10:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 V3UEzdugN44w for ; Fri, 10 Jul 2009 10:42:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C5B0B28C31F for ; Fri, 10 Jul 2009 10:42:26 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5830D4007B; Fri, 10 Jul 2009 11:42:55 -0600 (MDT) Message-ID: <4A577D94.7020202@stpeter.im> Date: Fri, 10 Jul 2009 11:42:44 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Slava Borilin References: <001501ca0181$5f6fcc70$057da8c0@spiritcorp.com> In-Reply-To: <001501ca0181$5f6fcc70$057da8c0@spiritcorp.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] =?utf-8?q?=D0=9D=D0=90=3A_RE=3A__Updated_Agenda_for_Codec?= =?utf-8?q?_BOF?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:42:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/09 11:10 AM, Slava Borilin wrote: > Free tutorial on codecs during the IETF but outside BoF sounds to be > good workaround. I'm all in favor of a tutorial on codecs. But why make it free? I think it would be better to charge for entry. ;-) In all seriousness, I think that the brief presentations on SILK, CELT, etc. would not provide a tutorial on codec design -- that topic is too big to cover in 5 or 10 minutes. But I do think it would be helpful for the designers of codecs like SILK and CELT to describe *briefly* how they designed their codecs, the lessons they learned, whether they think an even better codec could be designed within the IETF, etc. I would assume that these people (and people like them) would be the ones doing the work of a Codec WG (if approved), so I think it would be good for them to describe their thought processes and experiences, the major issues they see in performing such work within the IETF, etc. OK, I'll be quiet now. :) > Is there a place for it on Wed or Thu? (it better be > before BoF imho) Most definitely before. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXfZQACgkQNL8k5A2w/vzKBQCeN3R1mkIRWaepCSY5MJYt5ztv zagAoLUUDRMswVF1C0BbxUh01U5AYpiE =2sKx -----END PGP SIGNATURE----- From jason.fischl@skype.net Fri Jul 10 11:15:33 2009 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 494D628C361 for ; Fri, 10 Jul 2009 11:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.117 X-Spam-Level: X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[AWL=1.482, 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 WFg5C91w6bQR for ; Fri, 10 Jul 2009 11:15:32 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id E98B728C331 for ; Fri, 10 Jul 2009 11:15:31 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 001872007AB36; Fri, 10 Jul 2009 20:15:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=cc:message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; s=mail; bh=Uw0ZmQGV0PpnPC JyAtAe1BFdKtU=; b=DQUI/xvVhyHBqdYC0pS5ZYl/9v7jpzzJYCKTN8qaFzzbtA OrgWLE2mwYnV7dL4FNrhIzR7CUh/lsgf+zwVzOUhgt66FJqaQVacAKQuWMEFdYLT j+o+GQeDqR+fG3jRiSbTl1lY/YzIUdCbF/Mb8PHu31rp+pUIQf+BVFDz2XSks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=cc:message-id:from :to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s=mail; b=PNqIO22b Y3BPLvgbY3axmcFDOOBhSQY8VMuz586k9HQ0XBS/yaBGSs6S4KiCJ4E73lusLhBo LhvGqIwiPtXWgY4HjA0tqR93B/iKhOkFx1BrQFnJ2FLT6mE2rJ6wBqvxGP7gP7Hq g8/crFyvtXMZJobIcfN3LOVoOdrDmNh7B1k= Received: from [10.0.1.28] (c-69-181-180-22.hsd1.ca.comcast.net [69.181.180.22]) by mail.skype.net (Postfix) with ESMTPSA id 3B9AA2007AB41; Fri, 10 Jul 2009 20:15:59 +0200 (CEST) Message-Id: From: Jason Fischl To: Stephan Wenger In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 11:15:56 -0700 References: X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Purpose of the CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:15:33 -0000 On Jul 8, 2009, at 3:35 PM, Stephan Wenger wrote: > Hi Cullen, > > You state in absolutely clear terms the main reason for a BOF. Why > do I > miss those clear terms in the updated agenda? Why is agenda item #3 > not > called "Should the IETF perform work towards an Internet Codec?" > The intention with the revised agenda was that items 3 to 6 were addressing the issues that will help the BOF decide the answer to the question, "Should the IETF perform work towards an Internet Codec?" Agenda item 7 asks the question after we've had the discussion. I'd also like to ask the participants on the list to contribute any additional agenda items that are missing to help answer the above question. > Let me also repeat my earlier suggestion: in order to be time- > efficient, it > would be helpful if we could avoid repeating known arguments over > and over. > One way to do this would be that you would summarize the state of > discussion > very early in the meeting---and ask not to repeat those known > arguments. > I think it is a good suggestion to summarize the arguments made on the list at the start of the meeting. I will put together a list of these arguments and circulate them as new topics on the mailing list. However, I do think that we need to have these arguments in the meeting again to help make an informed decision. From dbogdanovic@counterpath.com Fri Jul 10 13:30:01 2009 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 335E628C361 for ; Fri, 10 Jul 2009 13:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 QjBbjovVoIXj for ; Fri, 10 Jul 2009 13:30:00 -0700 (PDT) Received: from relay.ihostexchange.net (relay.ihostexchange.net [66.46.182.54]) by core3.amsl.com (Postfix) with ESMTP id 3F2F728C34A for ; Fri, 10 Jul 2009 13:30:00 -0700 (PDT) Received: from [192.168.2.19] (24.218.221.216) by smtp.ihostexchange.net (66.46.182.50) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 10 Jul 2009 16:30:20 -0400 From: Dean Bogdanovic To: Randell Jesup In-Reply-To: X-Priority: 5 References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> Message-ID: <3D5D3109-CB97-4303-821A-0AF3411055FD@counterpath.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 16:30:19 -0400 X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" , Dean Bogdanovic Subject: Re: [codec] [SPAM?] Re: Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:30:01 -0000 yes, they tested iLBC. In tonal languages they need wide band codec, as it gives them better quality and iLBC didn't do a good job on that one. Regarding the adaptiveness, it ended up being pretty good, but again the problem was with tonal languages, as the quality degraded with packetloss. Dean On Jul 10, 2009, at 11:41 AM, Randell Jesup wrote: > Dean Bogdanovic writes: >> After reading discussions on this topic, thought to add customer >> view on >> this one. >> >> In the last 12 month, I've participated in several customer >> projects in >> Asia, Africa and Europe. All of them were trying to add voip over >> their 3G >> data networks as service and were looking for low-latency royalty >> free >> codec. Two of the projects were interesting, as different carriers >> connected their voip networks and allowed traffic between voip UAs >> directly (no PSTN interconnect). The biggest problem ended up >> being codec, >> as the results of testing with different royalty free codecs weren't >> satisfying. > > What was the result of testing with iLBC? Did they test that? Was > the > issue the lack of adaptive capability, or was wideband required? > >> In general, carrier groups are looking to use IP as primary >> communication >> mechanism among their group members and for them royalty free, >> adaptive/low latency is really important, as (Asia, Africa and >> part of >> Europe) their subs have low ARPU and many of them are traveling >> for work >> outside of their home countries. So you have carrier groups >> covering all >> those countries, but they don't have an (cheap) option to provide >> affordable service to their customers. > > The cheaper they can obtain the codecs (especially when they can avoid > the PSTN network), the cheaper they can provide service, and the more > people who can afford their service. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of > the weapons > provided for defence against real, pretended, or imaginary dangers > from abroad." > - James Madison, 4th US president (1751-1836) From ron.even.tlv@gmail.com Fri Jul 10 13:56:39 2009 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 CF41028C36A for ; Fri, 10 Jul 2009 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN-5Ovg6hTM4 for ; Fri, 10 Jul 2009 13:56:37 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 6BC7A28C2F7 for ; Fri, 10 Jul 2009 13:56:37 -0700 (PDT) Received: by fxm18 with SMTP id 18so1139085fxm.37 for ; Fri, 10 Jul 2009 13:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Ij5+89Y0CoEN4hMOlmXCtQfLTg5MiP0MjAIady+rHFs=; b=gHOo8o3H3ApnsD5CqKizMpMrIwKU1Ki9CAqYx34qcD4v/LRYo1/SNFhvj1aa1SSgr1 ryMdfhURW+zaSNv98050qNHyMNbRX0UvB5ekRjdv35r+Z/pkC1qg1WDr6tExwsgSTpqj QLn5V9e5pfYPUqTuEujlSRhwSi5KLNyzuxbYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=PloclNKmO1MOXjUEGTQM2nqOBk86DkJJsaxRNpuvlrRPw6zDZQUpaCjG5WEznShzab Ne5rew6WhVwo8phohiPYGcHanEfTG82bnxkWPOS17eYloRdk8/Yzjh9ixdNVzSZbL+MG 6FxTsx2RQQaaBKvevc+L2dclT0MJCtG7UGIFQ= Received: by 10.103.252.17 with SMTP id e17mr1331123mus.14.1247259422683; Fri, 10 Jul 2009 13:57:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id t10sm5344718muh.30.2009.07.10.13.57.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 13:57:02 -0700 (PDT) From: "Roni Even" To: "'Jason Fischl'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> In-Reply-To: <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> Date: Fri, 10 Jul 2009 23:56:10 +0300 Message-ID: <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBhSGhNgAeM30ISqW2+O2pt0hSbwAGWBKg Content-Language: en-us Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:56:39 -0000 Jason, If you want to describe the type of work that will be done in the working group it will be better to have a presentation on how you will define requirements, test the quality and select a codec, how it is done in other bodies and why should the IETF do it. My current view based on the lack of any agreed requirements is that every wide band codec is a good candidate including ones that were done by other standard bodies. So to present just two do not have any value and may have some bias, mostly since it is the ones suggested by the BOF chairs. If you want to present codecs, I can probably present the list of all existing codecs based on a list that is kept by the ITU. As for showing that there are people capable of evaluating codecs in the IETF, note that I did not say design but evaluate the process by which a codec will be selected and evaluate the maturity of the proposal, I am not sure that except for the proponent there are any others who have enough experience in codec design and quality testing. I think that this is one of the topics to be discussed since one of the conclusion of the iLBC work that there is not enough such expertise. Roni Even > -----Original Message----- > From: Jason Fischl [mailto:jason.fischl@skype.net] > Sent: Friday, July 10, 2009 8:38 PM > To: Roni Even > Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S'; > 'Slava Borilin'; codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > The point of briefly presenting a few codecs is to show the type of > work that would be done in the working group and to address the > feasibility of the goal. It is not to present the issues with the > particular codecs or even the details of the codecs. There have been > assertions on the list that the IETF lacks the expertise to do this > work. This agenda item attempts to address that concern. > > I'd also like to encourage other people to post to the list with their > opinions on whether or not agenda item 4 (codecs) should be included. > > As Stephen suggests, Jean-Marc and I will arrange for a lunch codec > tutorial session prior to the BOF on Wednesday or Thursday. > > Jason > > > On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > > > Hi, > > I still fail to see what is the value in presenting one, two or three > > codecs. I saw that there was a request to present a third one. > > I can agree that there are people who can present codecs as a > > suggested > > solution including existing ones. Since there is no charter yet > > under which > > the codecs are to be specified it may serve as a tutorial on codecs. > > So if > > we open to codec presentation in the BOF let allow everyone to > > present their > > codecs including ITU and MPEG ones and spend the whole BOF of the > > different > > codecs technologies. > > If the idea behind this presentation is to show specific > > functionality than > > instead it will be more fruitful to present requirements, since I > > could see > > from the list discussion that there is no consensus even between the > > current > > proponents what the requirements are. > > > > Roni Even > > > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > >> Behalf > >> Of Peter Saint-Andre > >> Sent: Friday, July 10, 2009 5:46 PM > >> To: stephen botzko > >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org > >> Subject: Re: [codec] Updated Agenda for Codec BOF > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 7/10/09 5:26 AM, stephen botzko wrote: > >>> Sorry to disagree on this. > >>> > >>> - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > >>> minutes would be short. > >>> - SILK and CELT are well known, and can be studied/reviewed by > >>> anyone > >>> interested off-line. > >>> > >>> The net effect of a 25 minute codec presentation by WG proponents > is > >> to > >>> remove 25 minutes of discussoin time. A second effect is that it > >> biases > >>> the time allotment in favor of proponents, which acts to skew the > >> input > >>> to IESG in that direction. Arguments against are just as important > >>> as > >>> arguments for at this point in the process. > >>> > >>> Perhaps a compromise is possible? Move item 4 to the _end_ of the > >>> agenda, and make it the "time permits" activity? > >> > >> How about 5 minutes to discuss each of the codec I-Ds at a high > >> level? > >> Allotting 10 minutes out of 2 hours to existence proofs and what > they > >> imply for the work of the Codec WG (if approved) seems helpful to > me. > >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can > >> productively talk about how these codecs could be used as input to a > >> working group. > >> > >> Peter > >> > >> - -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.8 (Darwin) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 > >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV > >> =bx98 > >> -----END PGP SIGNATURE----- > >> > >> _______________________________________________ > >> 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 ron.even.tlv@gmail.com Fri Jul 10 13:58:36 2009 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 72DF73A69B4 for ; Fri, 10 Jul 2009 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyrtghyN+7b6 for ; Fri, 10 Jul 2009 13:58:35 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 355C13A6834 for ; Fri, 10 Jul 2009 13:58:35 -0700 (PDT) Received: by bwz25 with SMTP id 25so1132613bwz.37 for ; Fri, 10 Jul 2009 13:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=9nX+YTbPvC0bUMn7mJVRZAR6bYj70OCUbAyAynl3st4=; b=dxBbwSjMXEwFHmiQw71mOk3oKAqMQlfN1YCuLGNDOA9chyknJu9GGoEUY5Ddfq88q6 cvR801YkS7ZbZcfhymmSOsh5WRjwr85V+C/MCFebGU9Z59LsrJ2+QADSB3Zyf+vBzbvt pgw4XFVQkOLQDjfcuFLbkjLlXYC2xaGA2CkOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=NkkabdxYecbK8v0V36/722s0BpSI0RcXxp2oZOZoPtkh5DWsuVDr1lO4BVek9oKipD y1Nbe/GWAd0yYTw5Dt9Pra2C8y6ppvw2vOAP+l9y8khpTXAQS/r4InzND6kWBY8m7cZR SV/ZDn4yXHqfw2s3RbEh3MdmkJoozoqGWKpiY= Received: by 10.103.12.2 with SMTP id p2mr1311611mui.70.1247259540635; Fri, 10 Jul 2009 13:59:00 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id 12sm7995020muq.23.2009.07.10.13.58.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 13:58:59 -0700 (PDT) From: "Roni Even" To: "'Dean Bogdanovic'" , "'Randell Jesup'" References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <3D5D3109-CB97-4303-821A-0AF3411055FD@counterpath.com> In-Reply-To: <3D5D3109-CB97-4303-821A-0AF3411055FD@counterpath.com> Date: Fri, 10 Jul 2009 23:58:09 +0300 Message-ID: <4a57ab93.0c11660a.481c.7d0b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBnUaiu3EF1GLZThy7gXljYsrBXQAA68Ow Content-Language: en-us Cc: codec@ietf.org, 'Dean Bogdanovic' Subject: Re: [codec] [SPAM?] Re: Customer demand for royalty-free internet codec X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:58:36 -0000 Hi, This is relevant to the testing requirements. BTW: the ITU-T testing is done in more than one language and I mentioned it in previous message to the list Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Dean Bogdanovic > Sent: Friday, July 10, 2009 11:30 PM > To: Randell Jesup > Cc: codec@ietf.org; Dean Bogdanovic > Subject: Re: [codec] [SPAM?] Re: Customer demand for royalty-free > internet codec > Importance: Low > > yes, they tested iLBC. In tonal languages they need wide band codec, > as it gives them better quality and iLBC didn't do a good job on that > one. Regarding the adaptiveness, it ended up being pretty good, but > again the problem was with tonal languages, as the quality degraded > with packetloss. > > Dean > On Jul 10, 2009, at 11:41 AM, Randell Jesup wrote: > > > Dean Bogdanovic writes: > >> After reading discussions on this topic, thought to add customer > >> view on > >> this one. > >> > >> In the last 12 month, I've participated in several customer > >> projects in > >> Asia, Africa and Europe. All of them were trying to add voip over > >> their 3G > >> data networks as service and were looking for low-latency royalty > >> free > >> codec. Two of the projects were interesting, as different carriers > >> connected their voip networks and allowed traffic between voip UAs > >> directly (no PSTN interconnect). The biggest problem ended up > >> being codec, > >> as the results of testing with different royalty free codecs > weren't > >> satisfying. > > > > What was the result of testing with iLBC? Did they test that? Was > > the > > issue the lack of adaptive capability, or was wideband required? > > > >> In general, carrier groups are looking to use IP as primary > >> communication > >> mechanism among their group members and for them royalty free, > >> adaptive/low latency is really important, as (Asia, Africa and > >> part of > >> Europe) their subs have low ARPU and many of them are traveling > >> for work > >> outside of their home countries. So you have carrier groups > >> covering all > >> those countries, but they don't have an (cheap) option to provide > >> affordable service to their customers. > > > > The cheaper they can obtain the codecs (especially when they can > avoid > > the PSTN network), the cheaper they can provide service, and the more > > people who can afford their service. > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > > Amiga OS team > > rjesup@wgate.com > > "The fetters imposed on liberty at home have ever been forged out of > > the weapons > > provided for defence against real, pretended, or imaginary dangers > > from abroad." > > - James Madison, 4th US president (1751-1836) > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Fri Jul 10 14:03:30 2009 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 3BF013A6E8F for ; Fri, 10 Jul 2009 14:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbDjdGDxQ6Ev for ; Fri, 10 Jul 2009 14:03:29 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 949EA3A67B6 for ; Fri, 10 Jul 2009 14:03:28 -0700 (PDT) Received: by bwz25 with SMTP id 25so1134684bwz.37 for ; Fri, 10 Jul 2009 14:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=MjcP10ou92bFQwXcPkKzXpYV91zZpfLn1QuH5gXoOJg=; b=MGvItHSg4S9mJFiwzvM2JlMu70+JW7Ul6DzXYkFaS4f+32geSB5PTXyETHouKRnUt/ cv2427/mmqE6lzgRoii5i9BaE01PzO2GJslTwlqLkrmVW7NxKRLcvJGG8FPb/7d8o6kb pM6jeGdgrk32YJpZOwoLruvGKwbgfsD9mlyo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=BBtLIYK7Xl1MqG0TINJJhkas0Mo0rUpRUb7is002lOo/MnyQ5k213cSYdFWcRK1HBi CgKk19mP8P0DSw/xuHXwFBi3X5aTExYHtjZy5Wcxk2QlpN5L65vsGfFCu4E2lekYsGTX Dbq0guuFoHhNda8v+CVHvSICoDyToLXBBhMIs= Received: by 10.103.246.1 with SMTP id y1mr1311020mur.72.1247259834384; Fri, 10 Jul 2009 14:03:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id y2sm8096693mug.13.2009.07.10.14.03.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 14:03:53 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> In-Reply-To: <4A5777DB.4080400@stpeter.im> Date: Sat, 11 Jul 2009 00:03:03 +0300 Message-ID: <4a57acb9.02e2660a.5453.7e56@mx.google.com> 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: AcoBgm2fw+csROk+QsCzIv1kyPdoDgAHuA7Q Content-Language: en-us Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 21:03:30 -0000 Peter, Presenting the codecs does not supply proof. Presenting quality tests = done by independent labs is a proof on the quality of the work suggested = here. I do not except to see this at this stage of the work so = presenting the codec will not give any proof except that there are = proponent who want to approve their codecs. Many of the people coming to = the IETF and attending the BOF see a codec as a black box and evaluate = it based on the quality results Roni Even > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Friday, July 10, 2009 8:18 PM > To: Roni Even > Cc: 'stephen botzko'; 'Ingemar Johansson S'; 'Slava Borilin'; > codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 7/10/09 10:43 AM, Roni Even wrote: > > Hi, > > I still fail to see what is the value in presenting one, two or = three > > codecs. >=20 > Present them as existence proofs (yes, we can!) and provide lessons > learned as input to the kind of work that a Codec WG would pursue. We > need to know that it is within the realm of possibility for a Codec WG > to be successful. >=20 > > I saw that there was a request to present a third one. >=20 > Which? >=20 > > I can agree that there are people who can present codecs as a > suggested > > solution including existing ones. >=20 > No. As far as I can see these are *not* suggested solutions. The point > is show that we have the expertise within the IETF to pursue this = work, > to learn how those codecs were developed, and to judge whether we = think > even better codecs could be developed by a Codec WG. >=20 > > Since there is no charter yet under which > > the codecs are to be specified it may serve as a tutorial on codecs. >=20 > Given that the IETF has not traditionally been home to codec work, I > think that a very brief tutorial on what's involved in such work would > be quite beneficial. >=20 > > So if > > we open to codec presentation in the BOF let allow everyone to > present their > > codecs including ITU and MPEG ones and spend the whole BOF of the > different > > codecs technologies. >=20 > Don't be ridiculous. Two or three proof points should be plenty. >=20 > > If the idea behind this presentation is to show specific > functionality >=20 > I don't think that's the idea. >=20 > > than > > instead it will be more fruitful to present requirements, since I > could see > > from the list discussion that there is no consensus even between the > current > > proponents what the requirements are. >=20 > Discussion of existence proofs and lessons learned from previous codec > work is not at odds with discussion of requirements. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkpXd9sACgkQNL8k5A2w/vzbdwCgxU2s6pjxTWp67WE30oJd/s1F > L6AAn3s7EmSR3aDYrX0Pz79Rnjc36oVm > =3D8ctr > -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Jul 10 14:13:24 2009 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 29B823A6C5F for ; Fri, 10 Jul 2009 14:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 9RnUceYgSZcf for ; Fri, 10 Jul 2009 14:13:23 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2797C3A6899 for ; Fri, 10 Jul 2009 14:13:23 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 260DE4007B; Fri, 10 Jul 2009 15:13:51 -0600 (MDT) Message-ID: <4A57AF0E.9010004@stpeter.im> Date: Fri, 10 Jul 2009 15:13:50 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Roni Even References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> <4a57acb9.02e2660a.5453.7e56@mx.google.com> In-Reply-To: <4a57acb9.02e2660a.5453.7e56@mx.google.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 21:13:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/09 3:03 PM, Roni Even wrote: > Peter, Presenting the codecs does not supply proof. Presenting > quality tests done by independent labs is a proof on the quality of > the work suggested here. I said that having presentations about SILK and CELT would provide an existence proof that at least some people at the BoF have the ability to develop codecs, not a proof of the quality of the future codec that those people and others might produce within a possible Codec WG. > I do not except to see this at this stage of > the work so presenting the codec will not give any proof except that > there are proponent who want to approve their codecs. On on what basis do you assert that people want to use a Codec WG as a rubber stamp for existing codecs that they designed before the BoF was even proposed? As I understand it, the focus of a Codec WG would be to design a new codec, not give its blessing to any existing codec. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXrw0ACgkQNL8k5A2w/vyq4gCfVxO32c/fPCVV/nMXTuHzOaZo L2cAnjZV/lc2DPKTGE/5f0DyaxCAqWA5 =AO55 -----END PGP SIGNATURE----- From stephen.botzko@gmail.com Fri Jul 10 14:14:59 2009 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 26C153A6899 for ; Fri, 10 Jul 2009 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.544, 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 RaVi0YeuVC+2 for ; Fri, 10 Jul 2009 14:14:57 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 02DB03A6834 for ; Fri, 10 Jul 2009 14:14:56 -0700 (PDT) Received: by fxm18 with SMTP id 18so1147146fxm.37 for ; Fri, 10 Jul 2009 14:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=28TeqnBISh/s11SY1DRdfMwS5zLER/IohZLmOPLU7AE=; b=vobTVntzZTqKgtN5K9n4f+88oLox9UR8Ts4PZhJrpDIUnWJ1DU+2XyRMRVnkpDC08B NE1bmWWVfAIgvnrV8tUeqfSmCAnDEly0eLp0ulleqZt462N4nIFrRDHaf+fzjXN1/r44 B/IFHfvSTnt8L90kj4sPcr0S0q1ARsn/uGYRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lFQhVIuxufUjxowI2nZVOWjk8rS6EeNKVa3/k9L1m94gN1FTKkILTKpGFcFz0LRXiQ ph4gM6EDaLLDbGn+dIxK98f4TJtGkZkfnZVN/muZ4ByJsiKZHrkyGAWosLTwlETU3C6L ZUP7Q9siIoXNrweR6vL0QuVHvatXaPypByzYU= MIME-Version: 1.0 Received: by 10.102.253.3 with SMTP id a3mr1334605mui.134.1247260521693; Fri, 10 Jul 2009 14:15:21 -0700 (PDT) In-Reply-To: <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> Date: Fri, 10 Jul 2009 17:15:21 -0400 Message-ID: <6e9223710907101415n3fea1de1gb2572de1d77bd825@mail.gmail.com> From: stephen botzko To: Roni Even Content-Type: multipart/alternative; boundary=0016364166e9568690046e60785b Cc: Ingemar Johansson S , Slava Borilin , codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 21:14:59 -0000 --0016364166e9568690046e60785b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think this presentation concept is better than a codec description. It would naturally form a framework for the following discussion. Though I still think it needs to be short (no more than 10 minutes), and it should be clear to all that it represents just one view of how it might be done. As far as codec developers goes, it is hopefully obvious to everyone (pro and con) that there are quite a few individuals and organizations participating in the IETF that have considerable expertise in codec development. I'm sure several also have experience with the codec characterization/quality testing Roni mentions. Though I think getting this kind of testing in place will require quite a bit of work - my assessment is that it is probably more work than standardizing the first codec. Getting agreement on the methodologies, the speech samples to use, etc. will take time and effort. Regards, Stephen Botzko Polycom On Fri, Jul 10, 2009 at 4:56 PM, Roni Even wrote: > Jason, > If you want to describe the type of work that will be done in the working > group it will be better to have a presentation on how you will define > requirements, test the quality and select a codec, how it is done in other > bodies and why should the IETF do it. > My current view based on the lack of any agreed requirements is that every > wide band codec is a good candidate including ones that were done by other > standard bodies. So to present just two do not have any value and may have > some bias, mostly since it is the ones suggested by the BOF chairs. If you > want to present codecs, I can probably present the list of all existing > codecs based on a list that is kept by the ITU. > > As for showing that there are people capable of evaluating codecs in the > IETF, note that I did not say design but evaluate the process by which a > codec will be selected and evaluate the maturity of the proposal, I am not > sure that except for the proponent there are any others who have enough > experience in codec design and quality testing. I think that this is one of > the topics to be discussed since one of the conclusion of the iLBC work > that > there is not enough such expertise. > > Roni Even > > > > > -----Original Message----- > > From: Jason Fischl [mailto:jason.fischl@skype.net] > > Sent: Friday, July 10, 2009 8:38 PM > > To: Roni Even > > Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S'; > > 'Slava Borilin'; codec@ietf.org > > Subject: Re: [codec] Updated Agenda for Codec BOF > > > > The point of briefly presenting a few codecs is to show the type of > > work that would be done in the working group and to address the > > feasibility of the goal. It is not to present the issues with the > > particular codecs or even the details of the codecs. There have been > > assertions on the list that the IETF lacks the expertise to do this > > work. This agenda item attempts to address that concern. > > > > I'd also like to encourage other people to post to the list with their > > opinions on whether or not agenda item 4 (codecs) should be included. > > > > As Stephen suggests, Jean-Marc and I will arrange for a lunch codec > > tutorial session prior to the BOF on Wednesday or Thursday. > > > > Jason > > > > > > On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > > > > > Hi, > > > I still fail to see what is the value in presenting one, two or three > > > codecs. I saw that there was a request to present a third one. > > > I can agree that there are people who can present codecs as a > > > suggested > > > solution including existing ones. Since there is no charter yet > > > under which > > > the codecs are to be specified it may serve as a tutorial on codecs. > > > So if > > > we open to codec presentation in the BOF let allow everyone to > > > present their > > > codecs including ITU and MPEG ones and spend the whole BOF of the > > > different > > > codecs technologies. > > > If the idea behind this presentation is to show specific > > > functionality than > > > instead it will be more fruitful to present requirements, since I > > > could see > > > from the list discussion that there is no consensus even between the > > > current > > > proponents what the requirements are. > > > > > > Roni Even > > > > > >> -----Original Message----- > > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > >> Behalf > > >> Of Peter Saint-Andre > > >> Sent: Friday, July 10, 2009 5:46 PM > > >> To: stephen botzko > > >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org > > >> Subject: Re: [codec] Updated Agenda for Codec BOF > > >> > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> On 7/10/09 5:26 AM, stephen botzko wrote: > > >>> Sorry to disagree on this. > > >>> > > >>> - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > > >>> minutes would be short. > > >>> - SILK and CELT are well known, and can be studied/reviewed by > > >>> anyone > > >>> interested off-line. > > >>> > > >>> The net effect of a 25 minute codec presentation by WG proponents > > is > > >> to > > >>> remove 25 minutes of discussoin time. A second effect is that it > > >> biases > > >>> the time allotment in favor of proponents, which acts to skew the > > >> input > > >>> to IESG in that direction. Arguments against are just as important > > >>> as > > >>> arguments for at this point in the process. > > >>> > > >>> Perhaps a compromise is possible? Move item 4 to the _end_ of the > > >>> agenda, and make it the "time permits" activity? > > >> > > >> How about 5 minutes to discuss each of the codec I-Ds at a high > > >> level? > > >> Allotting 10 minutes out of 2 hours to existence proofs and what > > they > > >> imply for the work of the Codec WG (if approved) seems helpful to > > me. > > >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can > > >> productively talk about how these codecs could be used as input to a > > >> working group. > > >> > > >> Peter > > >> > > >> - -- > > >> Peter Saint-Andre > > >> https://stpeter.im/ > > >> > > >> > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG v1.4.8 (Darwin) > > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > >> > > >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 > > >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV > > >> =bx98 > > >> -----END PGP SIGNATURE----- > > >> > > >> _______________________________________________ > > >> 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 > > --0016364166e9568690046e60785b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this presentation concept is better than a codec description.=A0 It= would naturally form a framework for the following discussion.=A0 Though I= still think it needs to be short (no more than 10 minutes), and it should = be clear to all that it represents just one view of how it might be done.
As far as codec developers goes, it is hopefully obvious to everyone (p= ro and con) that there are quite a few individuals and organizations partic= ipating in the IETF that have considerable expertise in codec development.= =A0 I'm sure several also have experience with the codec characterizati= on/quality testing Roni mentions.=A0 Though I think getting this kind of te= sting in place will require quite a bit of work - my assessment is that it = is probably more work than standardizing the first codec.=A0 Getting agreem= ent on the methodologies, the speech samples to use, etc. will take time an= d effort.

Regards,
Stephen Botzko
Polycom




On Fri, Jul 10, 2009 at 4:56 PM, Roni Even <= span dir=3D"ltr"><ron.even.tlv@gmail.com> wrote:
Jason,
If you want to describe the type of work that will be done in the working group it will be better to have a presentation on how you will define
requirements, test the quality and select a codec, how it is done in other<= br> bodies and why should the IETF do it.
My current view based on the lack of any agreed requirements is that every<= br> wide band codec is a good candidate including ones that were done by other<= br> standard bodies. So to present just two do not have any value and may have<= br> some bias, mostly since it is the ones suggested by the BOF chairs. If you<= br> want to present codecs, I can probably present the list of all existing
codecs based on a list that is kept by the ITU.

As for showing that there are people capable of evaluating codecs in the IETF, note that I did not say design but evaluate the process by which a codec will be selected and evaluate the maturity of the proposal, I am not<= br> sure that except for the proponent there are any others who have enough
experience in codec design and quality testing. I think that this is one of=
the topics to be discussed since one of the conclusion of the iLBC work tha= t
there is not enough such expertise.

Roni Even



> -----Original Message-----
> From: Jason Fischl [mailto:jason.fischl@skype.net]
> Sent: Friday, July 10, 2009 8:38 PM
> To: Roni Even
> Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingema= r Johansson S';
> 'Slava Borilin'; codec@ietf.org
> Subject: Re: [codec] Updated Agenda for Codec BOF
>
> The point of briefly presenting a few codecs is to show the type of > work that would be done in the working group and to address the
> feasibility of the goal. It is not to present the issues with the
> particular codecs or even the details of the codecs. There have been > assertions on the list that the IETF lacks the expertise to do this > work. This agenda item attempts to address that concern.
>
> I'd also like to encourage other people to post to the list with t= heir
> opinions on whether or not agenda item 4 (codecs) should be included.<= br> >
> As Stephen suggests, Jean-Marc and I will arrange for a lunch codec > tutorial session prior to the BOF on Wednesday or Thursday.
>
> Jason
>
>
> On Jul 10, 2009, at 9:43 AM, Roni Even wrote:
>
> > Hi,
> > I still fail to see what is the value in presenting one, two or t= hree
> > codecs. I saw that there was a request to present a third one. > > I can agree that there are people who can present codecs as a
> > suggested
> > solution including existing ones. Since there is no charter yet > > under which
> > the codecs are to be specified it may serve as a tutorial on code= cs.
> > So if
> > we open to codec presentation in the BOF let allow everyone to > > present their
> > codecs including ITU and MPEG ones and spend the whole BOF of the=
> > different
> > codecs technologies.
> > If the idea behind this presentation is to show specific
> > functionality than
> > instead it will be more fruitful to present requirements, since I=
> > could see
> > from the list discussion that there is no consensus even between = the
> > current
> > proponents what the requirements are.
> >
> > Roni Even
> >
> >> -----Original Message-----
> >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On
> >> Behalf
> >> Of Peter Saint-Andre
> >> Sent: Friday, July 10, 2009 5:46 PM
> >> To: stephen botzko
> >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org
> >> Subject: Re: [codec] Updated Agenda for Codec BOF
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 7/10/09 5:26 AM, stephen botzko wrote:
> >>> Sorry to disagree on this.
> >>>
> >>> - A 25 minute presentation is not "short" in a = 2 hour meeting. =A05
> >>> minutes would be short.
> >>> - SILK and CELT are well known, and can be studied/review= ed by
> >>> anyone
> >>> interested off-line.
> >>>
> >>> The net effect of a 25 minute codec presentation by WG pr= oponents
> is
> >> to
> >>> remove 25 minutes of discussoin time. =A0A second effect = is that it
> >> biases
> >>> the time allotment in favor of proponents, which acts to = skew the
> >> input
> >>> to IESG in that direction. Arguments against are just as = important
> >>> as
> >>> arguments for at this point in the process.
> >>>
> >>> Perhaps a compromise is possible? =A0Move item 4 to the _= end_ of the
> >>> agenda, and make it the "time permits" activity= ?
> >>
> >> How about 5 minutes to discuss each of the codec I-Ds at a hi= gh
> >> level?
> >> Allotting 10 minutes out of 2 hours to existence proofs and w= hat
> they
> >> imply for the work of the Codec WG (if approved) seems helpfu= l to
> me.
> >> Clearly anyone can read the I-Ds ahead of time, but IMHO the = BoF can
> >> productively talk about how these codecs could be used as inp= ut to a
> >> working group.
> >>
> >> Peter
> >>
> >> - --
> >> Peter Saint-Andre
> >> https://stp= eter.im/
> >>
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.8 (Darwin)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>
> >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MAR= PE2
> >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV
> >> =3Dbx98
> >> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> codec mailing list
> >> codec@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/codec
> >
> > _______________________________________________
> > codec mailing list
> > codec@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/codec


--0016364166e9568690046e60785b-- From ron.even.tlv@gmail.com Fri Jul 10 14:44:26 2009 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 0A82528C278 for ; Fri, 10 Jul 2009 14:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMq6lfuuxN20 for ; Fri, 10 Jul 2009 14:44:25 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id A275128C1BA for ; Fri, 10 Jul 2009 14:44:24 -0700 (PDT) Received: by bwz25 with SMTP id 25so1151918bwz.37 for ; Fri, 10 Jul 2009 14:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=K1AlYVaDwnjMWWkjOizhurR6j1Axo86PhRGDIK3idSQ=; b=LlQyHOSj913eMMFOh+yfDDfdIELDJZe3AAesDRWCoFMl1xn2cNhkNFrofhT7uOgesi YsKxbJ+1O3HJ+b2SsvJ1Yxu57k5zGet9cJbhp0iXonpbBi3opYHIGCqcdiL3cFMtyX5q tTvapzL+B9MTwWNqLsUIDgy54byy89TNBgRKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=KXlCkvyIxa69NlgWrxDmv7Nt83JPk6+AIuIEkQZTqK4GAmzE8mJQ68zXqRn09Z9VLb hq6xcp0lmczEyl2jtUV30DpNb0r5BA4F051NI920PA83jDjzjeq3916YnKXxkWq1I8k4 isfxxqVVHhGiA8JsO7YCkw4hCRFA9ntx81Ewk= Received: by 10.103.247.17 with SMTP id z17mr1329373mur.84.1247262290432; Fri, 10 Jul 2009 14:44:50 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by mx.google.com with ESMTPS id u26sm8214675mug.22.2009.07.10.14.44.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 14:44:49 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> <4a57acb9.02e2660a.5453.7e56@mx.google.com> <4A57AF0E.9010004@stpeter.im> In-Reply-To: <4A57AF0E.9010004@stpeter.im> Date: Sat, 11 Jul 2009 00:43:59 +0300 Message-ID: <4a57b651.1ade660a.41f6.ffff8254@mx.google.com> 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: AcoBo1Ra74TDoOItRzK+NRa3YPCqyAABBq4A Content-Language: en-us Cc: 'Ingemar Johansson S' , 'Slava Borilin' , codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 21:44:26 -0000 Peter, The purpose of the BOF is to find if there is a need for such work. = Existing codecs is important input Roni > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Saturday, July 11, 2009 12:14 AM > To: Roni Even > Cc: 'stephen botzko'; 'Ingemar Johansson S'; 'Slava Borilin'; > codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 7/10/09 3:03 PM, Roni Even wrote: > > Peter, Presenting the codecs does not supply proof. Presenting > > quality tests done by independent labs is a proof on the quality of > > the work suggested here. >=20 > I said that having presentations about SILK and CELT would provide an > existence proof that at least some people at the BoF have the ability > to > develop codecs, not a proof of the quality of the future codec that > those people and others might produce within a possible Codec WG. >=20 > > I do not except to see this at this stage of > > the work so presenting the codec will not give any proof except that > > there are proponent who want to approve their codecs. >=20 > On on what basis do you assert that people want to use a Codec WG as a > rubber stamp for existing codecs that they designed before the BoF was > even proposed? As I understand it, the focus of a Codec WG would be to > design a new codec, not give its blessing to any existing codec. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkpXrw0ACgkQNL8k5A2w/vyq4gCfVxO32c/fPCVV/nMXTuHzOaZo > L2cAnjZV/lc2DPKTGE/5f0DyaxCAqWA5 > =3DAO55 > -----END PGP SIGNATURE----- From koen.vos@skype.net Fri Jul 10 17:10:57 2009 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 829CC3A69FD for ; Fri, 10 Jul 2009 17:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 1Mgcly6WmURD for ; Fri, 10 Jul 2009 17:10:56 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 2E6213A6896 for ; Fri, 10 Jul 2009 17:10:56 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id DF2EB2007AB1F for ; Sat, 11 Jul 2009 02:11:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=9lsqhoOrTPSX eA111w+DY0iASUA=; b=VT517yyebgLlUyPw1FkLzB45TU0Wb7z+RUydlWnH4kWF Je/2AaxLnd8t3gjzgWdMoVDdb+VMI+AWxwaP3dTPfKfAHolP1SAuohbPX0URDSbJ UWoAb4l7jTM2l0ZCHIzd1qO6eUPocPcieEqQXJkw8UcMYw/uFhUSP6XzfeAZNJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=hGo0AWo21U+RbbxwqIBn ttIHRAa4EYZjLxVpb4LwqdsYz6MfwbUa/T93M2iQxbbWGZhRRXSolzQJGRStG7Kr 0CTBYvcendo8cGLvvjECK59AmGLQ1Qzvp01Zeaca6nBMwePIoSom/nqiG3Jvxuzn ff6hmWbYcimN4B0le3jbLQE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id DDC512007AAB4 for ; Sat, 11 Jul 2009 02:11:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE50ezD1oZFJ for ; Sat, 11 Jul 2009 02:11:23 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 041C62007AB24; Sat, 11 Jul 2009 02:11:23 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Fri, 10 Jul 2009 17:11:22 -0700 Message-ID: <20090710171122.11627kc26xuafhka@mail.skype.net> Date: Fri, 10 Jul 2009 17:11:22 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> In-Reply-To: <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 00:10:57 -0000 Quoting Roni Even: > My current view based on the lack of any agreed requirements is that every > wide band codec is a good candidate including ones that were done by other > standard bodies. Right, some of us with (associations to) employers that earn royalties on codecs don't agree with the goal of a royalty-free codec. But isn't the ITU the better place to standardize royalty-bearing codecs? Why develop a codec with ITU-style licensing terms here at IETF? Besides that I haven't seen any controversy. The charter states basic requirements. We agreed on some technical details (like time scale modification), and test scenarios (clean speech, noisy speech, hands-free speech, a diversity of languages, and music - especially at higher rates). A next step is to settle on the test specs. So *my* current view based on the stated goals and requirements is that very few codecs fulfill them. For example, as we've discussed before, ITU codecs are expensive and/or perform so poorly that they are unsuitable for limited bandwidth applications (such as with mobile networks). > If you want to present codecs, I can probably present the list of > all existing codecs based on a list that is kept by the ITU. Great idea Roni, that will keep us busy for some time... koen. From hoene@uni-tuebingen.de Fri Jul 10 23:56:33 2009 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 94DF63A6A74 for ; Fri, 10 Jul 2009 23:56:33 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfCgm90NhQ32 for ; Fri, 10 Jul 2009 23:56:32 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 3DF9A3A6981 for ; Fri, 10 Jul 2009 23:56:31 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-171.pools.arcor-ip.net [94.218.222.171]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6B6uopu013571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Jul 2009 08:56:57 +0200 From: "Christian Hoene" To: References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> In-Reply-To: <20090710171122.11627kc26xuafhka@mail.skype.net> Date: Sat, 11 Jul 2009 08:56:46 +0200 Message-ID: <001f01ca01f4$c5d74d30$5185e790$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBvCf/icQtkkXiTF2gFC9OiEe73wAM0McQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 06:56:33 -0000 Hello, Recent comments suggested that there is a lack of experience in testing = and characterizing a codec proposal. I just like to comment that the process = of testing and selecting a codec in an IETF working group might be quite different as compared to the ITU/3GPP because of the open source and = royalty free nature of the codec proposals. First of all, the codec proposals can be made public at a very early = stage. Nobody has to wait that the algorithms of the codecs need to be filled = as patents.=20 Second, many users can download the codecs and test them. In fact, CELT = was open source from the beginning and is part of the Debian Linux = distribution since April 2008. As a consequence, it is tested and used by many Linux = uses on a day to day basis. For example, I introduced Alexander Carot, a = musician and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it = for distributed ensemble performances. In fact, he figured out some = weaknesses in CELT, which have been corrected then. Third, the process of selecting one out of multiple codec proposal is = much easier because no one has to lose earnings from patent fees. The codec developers might only lose or win reputation. Thus, the process of = selecting the best codec does not have to as perfect as in the ITU. The decision = can be made by rough consensus and must not be correct beyond any reasonable doubts. Overall, the process of codec assessment and selecting becomes easier = and less expensive. Instead of a few real (and expensive) experts on codec testing, the coding tests can be done over larger period of time by many (thousands) of users. Also, how cares which codec will make it if they perform nearly identical. Nobody has to lose a lot in the end. With best regards, Christian PS: It is out of question that Jean-Marc, Jason and many other on this = mailing list are experts on coding design. They have my full support as chairs = of this BOF (but of course not as chairs of a future WG codec). -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From herve.taddei@huawei.com Sat Jul 11 02:09:53 2009 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 9C90E3A68EC for ; Sat, 11 Jul 2009 02:09:53 -0700 (PDT) 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 Y5nXmzsOA8YW for ; Sat, 11 Jul 2009 02:09:52 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 8E2C43A67E4 for ; Sat, 11 Jul 2009 02:09:52 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMM00EOM1H5FJ@lhrga02-in.huawei.com> for codec@ietf.org; Sat, 11 Jul 2009 10:10:18 +0100 (BST) Received: from huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMM008021H57K@lhrga02-in.huawei.com> for codec@ietf.org; Sat, 11 Jul 2009 10:10:17 +0100 (BST) Received: from [172.24.1.6] (Forwarded-For: [77.4.59.208]) by lhrms01-in.huawei.com (mshttpd); Sat, 11 Jul 2009 11:10:17 +0200 Date: Sat, 11 Jul 2009 11:10:17 +0200 From: Herve Marcel Taddei 00900001 In-reply-to: <001f01ca01f4$c5d74d30$5185e790$@de> To: Christian Hoene Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 09:09:53 -0000 Hello, > Recent comments suggested that there is a lack of experience in > testing and I dont think it is recent comments but based an AVT charter:"The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs." So it would be nice that in the agenda the following topics are added: - overlap with other standard bodies - capacity to effectively review new codecs. - why do we need to change decisions taken a few years? What is new? What has changed? > Nobody has to wait that the algorithms of the codecs need to be > filled as patents. Do you think that in 3GPP/ITU-T people first make a patent free baseline and then add their own IPRs? A bit strange view on how the work is done. BTW, in ITU-T and 3GPP, we first study the need of having the new codec (applications targeted) and it should be supported by many companies. So far I have understood that the application is RF codec. As pointed out many times, there are already many RF codecs. If they dont fit your needs, please explain what your special needs are? I have not seen that so far. That is why some people are concerned that this activity just consists in rubberstamping some codecs. > Second, many users can download the codecs and test them. In fact, > CELT was > open source from the beginning and is part of the Debian Linux > distributionsince April 2008. As a consequence, it is tested and > used by many Linux uses > on a day to day basis. How do you keep interoperability if you keep changing the codec. I could understand that the encoder is changed, but the decoder must be stable otherwise the interoperability with previous version is gone. Standards are supposed to help interoperability and should be stable. > For example, I introduced Alexander Carot, > a musician > and scientist, to Jean-Marc Valin. Alex tested CELT on stage using > it for > distributed ensemble performances. In fact, he figured out some > weaknessesin CELT, which have been corrected then. If as soon as one person tries to work on a codec and finds weaknesses, it is not a very good sign for the stability of the codec... > Third, the process of selecting one out of multiple codec proposal > is much > easier because no one has to lose earnings from patent fees. The codec The selection of a codec should be made on the basis of the quality and more important on the need of having this new codec (applications, requirements, targetted bitrates, complexity, ...). > developers might only lose or win reputation. Thus, the process of > selectingthe best codec does not have to as perfect as in the ITU. If you enter a competition process, the selection has to be perfect otherwise the process would be unfair and that would create many problems. Who are the quality experts in IETF who would be able to say if a codec is good enough to be a standard and that it addressed all requirements? > The decision can > be made by rough consensus and must not be correct beyond any > reasonabledoubts. The selection should be made on consensus and must be perfect. > Overall, the process of codec assessment and selecting becomes > easier and > less expensive. Easier and cheaper are obviously good if it leads to the best decision achievable, I dont feel it will be the case. So to the agenda we should have a section on the selection process. > PS: > It is out of question that Jean-Marc, Jason and many other on this > mailinglist are experts on coding design. They have my full > support as chairs of > this BOF (but of course not as chairs of a future WG codec). On my side, I would support the comments made by some persons that we should have more neutral chairs for the BOF. Best regards Herve From hoene@uni-tuebingen.de Sat Jul 11 02:36:07 2009 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 C7CCB3A6946 for ; Sat, 11 Jul 2009 02:36:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JofFdqEGuPjo for ; Sat, 11 Jul 2009 02:36:07 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 9A2113A67E5 for ; Sat, 11 Jul 2009 02:36:06 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-171.pools.arcor-ip.net [94.218.222.171]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6B9a6V5021954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jul 2009 11:36:12 +0200 From: "Christian Hoene" To: "'Herve Marcel Taddei 00900001'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> In-Reply-To: Date: Sat, 11 Jul 2009 11:36:02 +0200 Message-ID: <002001ca020b$05680780$10381680$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoCB2/3NP7LL2N8StesWQqdgt7w/QAAIpVQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 09:36:07 -0000 Hi Herve Marcel Taddei, I found it difficult to follow your arguments because you were mixing the different stages of the codec standardization. In my email I was discussing the period in which the codecs are developed, implemented, tested and selected. This period of time is after the requirements definition and before standardization. > > developers might only lose or win reputation. Thus, the process of > > selectingthe best codec does not have to as perfect as in the ITU. > If you enter a competition process, the selection has to be perfect otherwise > the process would be unfair and that would create many problems. I would really like to understand this argument. Could you please be more precise on what kind of problems would occur if the selection process is not done "beyond any doubts"? Of course, all codec developers have invested a lot of time into their codec. But most of this development times are lost anyhow, because only one proposal could win. But then again, after one proposal has won, their developer will not ear money with it... (at least not from the IPRs) > The selection should be made on consensus and must be perfect. Again, why? Please, please give me more arguments. Are they all still valid? I don't believe that. Does the ITU-T have some documents on why the selection process should be 100% perfect? Thank you Christian From herve.taddei@huawei.com Sat Jul 11 03:59:15 2009 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 46DC528C238 for ; Sat, 11 Jul 2009 03:59:15 -0700 (PDT) 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 kUp5RI1C80-a for ; Sat, 11 Jul 2009 03:59:14 -0700 (PDT) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id 976E83A6C89 for ; Sat, 11 Jul 2009 03:59:06 -0700 (PDT) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMM00BS76J8OU@lhrga01-in.huawei.com> for codec@ietf.org; Sat, 11 Jul 2009 11:59:32 +0100 (BST) Received: from PCHERVE (mnch-4d043bd0.pool.mediaWays.net [77.4.59.208]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMM002NW6J4P6@lhrga01-in.huawei.com> for codec@ietf.org; Sat, 11 Jul 2009 11:59:32 +0100 (BST) Date: Sat, 11 Jul 2009 12:59:07 +0200 From: Herve Taddei In-reply-to: To: 'Christian Hoene' Message-id: <001801ca0216$9e96f5f0$2201a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoCB2/3NP7LL2N8StesWQqdgt7w/QAAIpVQAANEuiAAAGBwIA== References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <002001ca020b$05680780$10381680$@de> Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 10:59:15 -0000 Hi Christian Hoene, > > I would really like to understand this argument. Could you please be more > > precise on what kind of problems would occur if the selection process is not > > done "beyond any doubts"? > You don't select the best one, which should be in the end the goal of a technical > group. You run the risk to select a solution not based on their technical merit and > you could enter in very subjective decision. To be very basic, you could have a > decision on whether or not you like the proposal or the people it comes from. That is > why your selection process needs to be crystal clear. > > > Again, why? Please, please give me more arguments. Are they all still valid? > > I don't believe that. Does the ITU-T have some documents on why the > > selection process should be 100% perfect? > We have selection process, requirements and objectives. You select the one that > achieve those requirements and standardize it. > > BTW, I think it has been mentioned many times that we should not have codec > presentations in the agenda as long we have not understood what are the > requirements and as long as the decision to start this activity has not really been > taken. > > Best regards > > Herve From stephen.botzko@gmail.com Sat Jul 11 04:06:06 2009 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 111683A6A26 for ; Sat, 11 Jul 2009 04:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.521, 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 mcw2-o26cl-X for ; Sat, 11 Jul 2009 04:06:04 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 0155A3A6818 for ; Sat, 11 Jul 2009 04:06:03 -0700 (PDT) Received: by fxm18 with SMTP id 18so1355345fxm.37 for ; Sat, 11 Jul 2009 04:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VDJtoyhCPeT4YgaJofxSVMbE/naE7V9LLc35SF7XIv8=; b=LV9HLA8Fm11HzclAFl1MigBDWeFzzbrjhOLCd2A+IkcqYuq/n+VvQtiTiJx+d4HHrA Ga4WaQB+csFJRpgyiFr6g/+E7ObnH9cpTddH7QCdToGQytg7vquCOJSzGDfD/4MDmArk YJHmyR6eaHYcD1Os1bGgUGouRGm0r/Gf512TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NI7YIlJLSutYTJ2t8srvZfDQ9iG8pRYFy5f2P3RPf7db9C6ngKptj7/HpUfBzKTaga iQ4Jy2Wn7vOyIvMtuPsOsU7Osd6vDBegI2W8gjN2bfEE51aHPK2scW71ehz3cND/uAPL TbYGlTgTpYgzJo1VCGhTMzjeO2XMCLh9nf4sQ= MIME-Version: 1.0 Received: by 10.103.225.15 with SMTP id c15mr1600709mur.115.1247310389185; Sat, 11 Jul 2009 04:06:29 -0700 (PDT) In-Reply-To: <001f01ca01f4$c5d74d30$5185e790$@de> References: <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> Date: Sat, 11 Jul 2009 07:06:29 -0400 Message-ID: <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636765baeac0b6b046e6c14e3 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 11:06:06 -0000 --001636765baeac0b6b046e6c14e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Obviously informal feedback on codec issues is useful, and I think most codec developers would use it to correct flaws in the design. However, I was not referring to that, I was referring to scientific listening tests which provide reliable assessments on codec performance. Other SDOs use those tests both to validate that the codec candidates meet the requirements as well as in codec selection. They may also use other objective tests to certify that the floating point version of the algorithm sounds identical to the fixed point version, or to validate that a small change in design does not substantially change the codec performance. Designing and administering such tests is a skill in its own right, the folks who do that generally are not codec developers. >>> Also, how cares which codec will make it if they perform nearly identical. Nobody has to lose a lot in the end. >>> I think the assessment process is multidimensional, not one dimensional. I don't think you're likely to have two codecs that "perform nearly identical" under all conditions (clean speech, noisy speech, reverberant speech, various languages, various network conditions). The final tradeoff will be more complicated - you'd want clear assurance that all candidates t= o meet or exceed all requirements, and you'd also find each candidate (though perhaps meeting the requirements) has its own weaknesses. Some might perform bettern on reverberant speech, others might perform better with packet loss. The WG would then need to decide which requirements are most important in making the final selection. Using anecdotal evidence from uncontrolled experiments to determine how candidate codecs perform in a multidimensional space does not seem very likely to bring a good result to me. I agree the IETF might use a different test methods from other SDOs. Since I happen to think that reliable, reproducible codec assessment is needed fo= r the IETF to authoritatively review/recommend/standardize codecs, that makes the IETF WG task more difficult, not less - there needs to be both agreemen= t on and development of suitable test methodolgy. Regards, Stephen Botzko Polycom On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene wr= ote: > Hello, > > Recent comments suggested that there is a lack of experience in testing a= nd > characterizing a codec proposal. I just like to comment that the process = of > testing and selecting a codec in an IETF working group might be quite > different as compared to the ITU/3GPP because of the open source and > royalty > free nature of the codec proposals. > First of all, the codec proposals can be made public at a very early stag= e. > Nobody has to wait that the algorithms of the codecs need to be filled as > patents. > Second, many users can download the codecs and test them. In fact, CELT w= as > open source from the beginning and is part of the Debian Linux distributi= on > since April 2008. As a consequence, it is tested and used by many Linux > uses > on a day to day basis. For example, I introduced Alexander Carot, a > musician > and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for > distributed ensemble performances. In fact, he figured out some weaknesse= s > in CELT, which have been corrected then. > Third, the process of selecting one out of multiple codec proposal is muc= h > easier because no one has to lose earnings from patent fees. The codec > developers might only lose or win reputation. Thus, the process of > selecting > the best codec does not have to as perfect as in the ITU. The decision ca= n > be made by rough consensus and must not be correct beyond any reasonable > doubts. > Overall, the process of codec assessment and selecting becomes easier and > less expensive. Instead of a few real (and expensive) experts on codec > testing, the coding tests can be done over larger period of time by many > (thousands) of users. Also, how cares which codec will make it if they > perform nearly identical. Nobody has to lose a lot in the end. > > With best regards, > > Christian > > > PS: > It is out of question that Jean-Marc, Jason and many other on this mailin= g > list are experts on coding design. They have my full support as chairs of > this BOF (but of course not as chairs of a future WG codec). > > > > > -------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636765baeac0b6b046e6c14e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Obviously informal feedback on codec issues is useful, and I think most cod= ec developers would use it to correct flaws in the design.

However,= I was not referring to that, I was referring to scientific listening tests= which provide reliable assessments on codec performance.=A0 Other SDOs use= those tests both to validate that the codec candidates meet the requiremen= ts as well as in codec selection.=A0 They may also use other objective test= s to certify that the floating point version of the algorithm sounds identi= cal to the fixed point version, or to validate that a small change in desig= n does not substantially change the codec performance.=A0 Designing and adm= inistering such tests is a skill in its own right, the folks who do that ge= nerally are not codec developers.

>>>
Also, how cares which codec will make it if they perfor= m nearly identical. Nobody has to lose a lot in the end.
>>>I think the assessment process is multidimensional, not one dimensional.= =A0 I don't think you're likely to have two codecs that=A0 "pe= rform nearly identical" under all conditions (clean speech, noisy spee= ch, reverberant speech, various languages, various network conditions). The= final tradeoff will be more complicated - you'd want clear assurance t= hat all candidates to meet or exceed all requirements, and you'd also f= ind each candidate (though perhaps meeting the requirements) has its own we= aknesses.=A0 Some might perform bettern on reverberant speech, others might= perform better with packet loss. The WG would then need to decide which re= quirements are most important in making the final selection. =A0 Using anec= dotal evidence from uncontrolled experiments to determine how candidate cod= ecs perform in a multidimensional space does not seem very likely to bring = a good result to me.

I agree the IETF might use a different test methods from other SDOs.=A0= Since I happen to think that reliable, reproducible codec assessment is ne= eded for the IETF to authoritatively review/recommend/standardize codecs, t= hat makes the IETF WG task more difficult, not less - there needs to be bot= h agreement on and development of suitable test methodolgy.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
Hello,

Recent comments suggested that there is a lack of experience in testing and=
characterizing a codec proposal. I just like to comment that the process of=
testing and selecting a codec in an IETF working group might be quite
different as compared to the ITU/3GPP because of the open source and royalt= y
free nature of the codec proposals.
First of all, the codec proposals can be made public at a very early stage.=
Nobody has to wait that the algorithms of the codecs need to be filled as patents.
Second, many users can download the codecs and test them. In fact, CELT was=
open source from the beginning and is part of the Debian Linux distribution=
since April 2008. As a consequence, it is tested and used by many Linux use= s
on a day to day basis. For example, I introduced Alexander Carot, a musicia= n
and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for distributed ensemble performances. In fact, he figured out some weaknesses<= br> in CELT, which have been corrected then.
Third, the process of selecting one out of multiple codec proposal is much<= br> easier because no one has to lose earnings from patent fees. The codec
developers might only lose or win reputation. Thus, the process of selectin= g
the best codec does not have to as perfect as in the ITU. The decision can<= br> be made by rough consensus and must not be correct beyond any reasonable doubts.
Overall, the process of codec assessment and selecting becomes easier and less expensive. Instead of a few real (and expensive) experts on codec
testing, the coding tests can be done over larger period of time by many (thousands) of users. Also, how cares which codec will make it if they
perform nearly identical. Nobody has to lose a lot in the end.

With best regards,

=A0Christian


PS:
It is out of question that Jean-Marc, Jason and many other on this mailing<= br> list are experts on coding design. They have my full support as chairs of this BOF (but of course not as chairs of a future WG codec).




--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/


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

--001636765baeac0b6b046e6c14e3-- From hoene@uni-tuebingen.de Sat Jul 11 04:37:23 2009 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 598FB3A6849 for ; Sat, 11 Jul 2009 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1g6zDiGnTeI for ; Sat, 11 Jul 2009 04:37:21 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 201F63A68B3 for ; Sat, 11 Jul 2009 04:37:20 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-171.pools.arcor-ip.net [94.218.222.171]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6BBbafm015130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jul 2009 13:37:44 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> In-Reply-To: <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> Date: Sat, 11 Jul 2009 13:37:33 +0200 Message-ID: <000a01ca021b$ffcb5a50$ff620ef0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CA022C.C3542A50" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoCF6uaUnE8OqGgQkyA6aUzKJpQ3gAAUegg Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.204; VDF: 7.1.4.219; host: mx05); id=29984-sq4mlp Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 11:37:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01CA022C.C3542A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to clarify my argument. I meant that the listening-only tests must = not be perfectly precise in a sense that the confidence interval of the = results of different codecs must not overlap. The larger the number of tests, = the smaller the confidence interval. If we allow for overlapping confidence intervals (meaning that we cannot distinguish the audio quality of two codecs in a particular situation), then fewer tests must be conduct. If = we have fewer tests, we have less costs. =20 But again, I would not underestimate the usefulness of a large group of users to find bugs and weaknesses in a codec. CELT has its users and I = bet that different versions of SILK were tested in different versions of the Skype softphone. (Sometimes after a call the Skype Softphone ask users = for their quality impression.) =20 With best regards, =20 Christian =20 =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Saturday, July 11, 2009 1:06 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF =20 Obviously informal feedback on codec issues is useful, and I think most codec developers would use it to correct flaws in the design.=20 However, I was not referring to that, I was referring to scientific listening tests which provide reliable assessments on codec performance. Other SDOs use those tests both to validate that the codec candidates = meet the requirements as well as in codec selection. They may also use other objective tests to certify that the floating point version of the = algorithm sounds identical to the fixed point version, or to validate that a small change in design does not substantially change the codec performance. Designing and administering such tests is a skill in its own right, the folks who do that generally are not codec developers. >>> Also, how cares which codec will make it if they perform nearly = identical. Nobody has to lose a lot in the end. >>> I think the assessment process is multidimensional, not one dimensional. = I don't think you're likely to have two codecs that "perform nearly identical" under all conditions (clean speech, noisy speech, reverberant speech, various languages, various network conditions). The final = tradeoff will be more complicated - you'd want clear assurance that all = candidates to meet or exceed all requirements, and you'd also find each candidate = (though perhaps meeting the requirements) has its own weaknesses. Some might perform bettern on reverberant speech, others might perform better with packet loss. The WG would then need to decide which requirements are = most important in making the final selection. Using anecdotal evidence from uncontrolled experiments to determine how candidate codecs perform in a multidimensional space does not seem very likely to bring a good result = to me. I agree the IETF might use a different test methods from other SDOs. = Since I happen to think that reliable, reproducible codec assessment is needed = for the IETF to authoritatively review/recommend/standardize codecs, that = makes the IETF WG task more difficult, not less - there needs to be both = agreement on and development of suitable test methodolgy. Regards, Stephen Botzko Polycom On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene = wrote: Hello, Recent comments suggested that there is a lack of experience in testing = and characterizing a codec proposal. I just like to comment that the process = of testing and selecting a codec in an IETF working group might be quite different as compared to the ITU/3GPP because of the open source and = royalty free nature of the codec proposals. First of all, the codec proposals can be made public at a very early = stage. Nobody has to wait that the algorithms of the codecs need to be filled = as patents. Second, many users can download the codecs and test them. In fact, CELT = was open source from the beginning and is part of the Debian Linux = distribution since April 2008. As a consequence, it is tested and used by many Linux = uses on a day to day basis. For example, I introduced Alexander Carot, a = musician and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it = for distributed ensemble performances. In fact, he figured out some = weaknesses in CELT, which have been corrected then. Third, the process of selecting one out of multiple codec proposal is = much easier because no one has to lose earnings from patent fees. The codec developers might only lose or win reputation. Thus, the process of = selecting the best codec does not have to as perfect as in the ITU. The decision = can be made by rough consensus and must not be correct beyond any reasonable doubts. Overall, the process of codec assessment and selecting becomes easier = and less expensive. Instead of a few real (and expensive) experts on codec testing, the coding tests can be done over larger period of time by many (thousands) of users. Also, how cares which codec will make it if they perform nearly identical. Nobody has to lose a lot in the end. With best regards, Christian PS: It is out of question that Jean-Marc, Jason and many other on this = mailing list are experts on coding design. They have my full support as chairs = of this BOF (but of course not as chairs of a future WG codec). -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_000B_01CA022C.C3542A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just to clarify my argument. I meant that the = listening-only tests must not be perfectly precise in a sense that the confidence = interval of the results of different codecs must not overlap. The larger the number = of tests, the smaller the confidence interval. If we allow for overlapping = confidence intervals (meaning that we cannot distinguish the audio quality of two = codecs in a particular situation), then fewer tests must be conduct. If we have = fewer tests, we have less costs.

 

But again, I would not underestimate the usefulness of a = large group of users to find bugs and weaknesses in a codec. CELT has its = users and I bet that different versions of SILK were tested in different versions of = the Skype softphone. (Sometimes after a call the Skype Softphone ask users for = their quality impression.)

 

With best regards,

 

=A0Christian

 

 

 

From:= stephen = botzko [mailto:stephen.botzko@gmail.com]
Sent: Saturday, July 11, 2009 1:06 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] Updated Agenda for Codec = BOF

 

Obviously informal = feedback on codec issues is useful, and I think most codec developers would use it = to correct flaws in the design.

However, I was not referring to that, I was referring to scientific = listening tests which provide reliable assessments on codec performance.  = Other SDOs use those tests both to validate that the codec candidates meet the requirements as well as in codec selection.  They may also use = other objective tests to certify that the floating point version of the = algorithm sounds identical to the fixed point version, or to validate that a small = change in design does not substantially change the codec performance.  = Designing and administering such tests is a skill in its own right, the folks who = do that generally are not codec developers.

>>>
Also, how cares which codec will make it if they perform nearly = identical. Nobody has to lose a lot in the end.
>>>
I think the assessment process is multidimensional, not one = dimensional.  I don't think you're likely to have two codecs that  "perform = nearly identical" under all conditions (clean speech, noisy speech, = reverberant speech, various languages, various network conditions). The final = tradeoff will be more complicated - you'd want clear assurance that all candidates to = meet or exceed all requirements, and you'd also find each candidate (though = perhaps meeting the requirements) has its own weaknesses.  Some might = perform bettern on reverberant speech, others might perform better with packet loss. The = WG would then need to decide which requirements are most important in = making the final selection.   Using anecdotal evidence from uncontrolled = experiments to determine how candidate codecs perform in a multidimensional space = does not seem very likely to bring a good result to me.

I agree the IETF might use a different test methods from other = SDOs.  Since I happen to think that reliable, reproducible codec assessment is = needed for the IETF to authoritatively review/recommend/standardize codecs, = that makes the IETF WG task more difficult, not less - there needs to be both = agreement on and development of suitable test methodolgy.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene = <hoene@uni-tuebingen.de> = wrote:

Hello,

Recent comments suggested that there is a lack of experience in testing = and
characterizing a codec proposal. I just like to comment that the process = of
testing and selecting a codec in an IETF working group might be = quite
different as compared to the ITU/3GPP because of the open source and = royalty
free nature of the codec proposals.
First of all, the codec proposals can be made public at a very early = stage.
Nobody has to wait that the algorithms of the codecs need to be filled = as
patents.
Second, many users can download the codecs and test them. In fact, CELT = was
open source from the beginning and is part of the Debian Linux = distribution
since April 2008. As a consequence, it is tested and used by many Linux = uses
on a day to day basis. For example, I introduced Alexander Carot, a = musician
and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it = for
distributed ensemble performances. In fact, he figured out some = weaknesses
in CELT, which have been corrected then.
Third, the process of selecting one out of multiple codec proposal is = much
easier because no one has to lose earnings from patent fees. The = codec
developers might only lose or win reputation. Thus, the process of = selecting
the best codec does not have to as perfect as in the ITU. The decision = can
be made by rough consensus and must not be correct beyond any = reasonable
doubts.
Overall, the process of codec assessment and selecting becomes easier = and
less expensive. Instead of a few real (and expensive) experts on = codec
testing, the coding tests can be done over larger period of time by = many
(thousands) of users. Also, how cares which codec will make it if = they
perform nearly identical. Nobody has to lose a lot in the end.

With best regards,

 Christian


PS:
It is out of question that Jean-Marc, Jason and many other on this = mailing
list are experts on coding design. They have my full support as chairs = of
this BOF (but of course not as chairs of a future WG = codec).





--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------=_NextPart_000_000B_01CA022C.C3542A50-- From koen.vos@skype.net Sat Jul 11 06:05:22 2009 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 7991D3A6818 for ; Sat, 11 Jul 2009 06:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 yB8ALaiXcQxI for ; Sat, 11 Jul 2009 06:05:21 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id B8C463A6A81 for ; Sat, 11 Jul 2009 06:05:20 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BC2782007C1DA for ; Sat, 11 Jul 2009 15:05:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=aSm05POjEpc0 4PxO86BXxeVyK5E=; b=kve4QIinoKNN2SoW3e2Pv1DoIJnm6CvwptZLQhi1mISo EnkuSI3AXtU+MdpHq82NKF9Qgn2rnsbCfR0AiobyWRUlnev0BA/oaCQYupcRa/oL z/YJQA6f3xVutoMYsZEQ/2oyqSq7Q3IFthtD0YNZv2sv8fEBLE/jwiz43/ZdxnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=AarQ6hMA/rTGkXoMNACL +VH9F9gv96NS7rNOacigQ1EDdanyYCPOiDvBrePGqDdaRMWFJ5KH1NQf5AzVlk5Y nXUaVBRs2f0DE9zNjln+oMrNhJhQ1Rz9Ae7jK0IU6rlqDCr6GBh9P3pd+u/n5wzc BWtb03CMpuHp5p/L99G7PoE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BA9FE2007C1D7 for ; Sat, 11 Jul 2009 15:05:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4ol3A8VKENu for ; Sat, 11 Jul 2009 15:05:38 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 53F7D2007C204; Sat, 11 Jul 2009 15:05:38 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 11 Jul 2009 06:05:38 -0700 Message-ID: <20090711060538.14002ddiitcbqcrm@mail.skype.net> Date: Sat, 11 Jul 2009 06:05:38 -0700 From: Koen Vos To: codec@ietf.org References: <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> In-Reply-To: <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:05:22 -0000 Stephen, The two elements that worry you seem to be: 1. It's hard to validate an individual codec - how good is good enough? Good codecs have been developed without an expensive process involving third parties to design and administer rigorous tests. In fact, we have several people here at IETF who have done this with previous codecs. Incidentally, both the CELT and SILK proposals are already being used in the real-world today (tens of billions of minutes of calls have been made through SILK for example). This exposes these codecs to a rigorous testing in its own right. 2. It's hard to compare two candidates. Well, so far the number of candidates is so small that the differences between candidates may well be clear even without rigorous testing. If we do end up with candidates that are close calls, we can always design more rigorous test plans to determine which is the preferred one. Let's be pragmatic about it. So I agree with Christian that the IETF WG can succeed in standardizing an ultra-useful codec even if the validation and selection process is different from, and in some aspects less rigorous than that of e.g. the ITU. We do need, of course, a list of test specifications and requirements. You have already made great suggestions in this area, and I don't see much controversy around it. koen Quoting stephen botzko : > Obviously informal feedback on codec issues is useful, and I think most > codec developers would use it to correct flaws in the design. > > However, I was not referring to that, I was referring to scientific > listening tests which provide reliable assessments on codec performance. > Other SDOs use those tests both to validate that the codec candidates meet > the requirements as well as in codec selection. They may also use other > objective tests to certify that the floating point version of the algorith= m > sounds identical to the fixed point version, or to validate that a small > change in design does not substantially change the codec performance. > Designing and administering such tests is a skill in its own right, the > folks who do that generally are not codec developers. > >>>> > Also, how cares which codec will make it if they perform nearly identical. > Nobody has to lose a lot in the end. >>>> > I think the assessment process is multidimensional, not one dimensional. = I > don't think you're likely to have two codecs that "perform nearly > identical" under all conditions (clean speech, noisy speech, reverberant > speech, various languages, various network conditions). The final tradeoff > will be more complicated - you'd want clear assurance that all candidates = to > meet or exceed all requirements, and you'd also find each candidate (thoug= h > perhaps meeting the requirements) has its own weaknesses. Some might > perform bettern on reverberant speech, others might perform better with > packet loss. The WG would then need to decide which requirements are most > important in making the final selection. Using anecdotal evidence from > uncontrolled experiments to determine how candidate codecs perform in a > multidimensional space does not seem very likely to bring a good result to > me. > > I agree the IETF might use a different test methods from other SDOs. Sinc= e > I happen to think that reliable, reproducible codec assessment is needed f= or > the IETF to authoritatively review/recommend/standardize codecs, that make= s > the IETF WG task more difficult, not less - there needs to be both agreeme= nt > on and development of suitable test methodolgy. > > Regards, > Stephen Botzko > Polycom > > On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene =20 > wrote: > >> Hello, >> >> Recent comments suggested that there is a lack of experience in testing a= nd >> characterizing a codec proposal. I just like to comment that the process = of >> testing and selecting a codec in an IETF working group might be quite >> different as compared to the ITU/3GPP because of the open source and >> royalty >> free nature of the codec proposals. >> First of all, the codec proposals can be made public at a very early stag= e. >> Nobody has to wait that the algorithms of the codecs need to be filled as >> patents. >> Second, many users can download the codecs and test them. In fact, CELT w= as >> open source from the beginning and is part of the Debian Linux distributi= on >> since April 2008. As a consequence, it is tested and used by many Linux >> uses >> on a day to day basis. For example, I introduced Alexander Carot, a >> musician >> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for >> distributed ensemble performances. In fact, he figured out some weaknesse= s >> in CELT, which have been corrected then. >> Third, the process of selecting one out of multiple codec proposal is muc= h >> easier because no one has to lose earnings from patent fees. The codec >> developers might only lose or win reputation. Thus, the process of >> selecting >> the best codec does not have to as perfect as in the ITU. The decision ca= n >> be made by rough consensus and must not be correct beyond any reasonable >> doubts. >> Overall, the process of codec assessment and selecting becomes easier and >> less expensive. Instead of a few real (and expensive) experts on codec >> testing, the coding tests can be done over larger period of time by many >> (thousands) of users. Also, how cares which codec will make it if they >> perform nearly identical. Nobody has to lose a lot in the end. >> >> With best regards, >> >> Christian >> >> >> PS: >> It is out of question that Jean-Marc, Jason and many other on this mailin= g >> list are experts on coding design. They have my full support as chairs of >> this BOF (but of course not as chairs of a future WG codec). >> >> >> >> >> -------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From stephen.botzko@gmail.com Sat Jul 11 09:52:43 2009 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 395243A687A for ; Sat, 11 Jul 2009 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 G+zsBxJDsIi1 for ; Sat, 11 Jul 2009 09:52:41 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 86C833A6AAA for ; Sat, 11 Jul 2009 09:52:40 -0700 (PDT) Received: by bwz23 with SMTP id 23so124043bwz.37 for ; Sat, 11 Jul 2009 09:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9TJ2Y7x9G/y0NIyfZsSU0IX+ZIUmP6qDoo/WMRvAzmA=; b=ieK31gwpDjVxPN9WfCv6nbonuEawFpM4zj8baLWvgJzPXl6YdVNXoho5Aoyp/CIkTX pb0oCb73ueXHWQ70ap3CluChRL0LypGqU5Rs/cFTU+9cc6WRXOBox4G25rAVJXZuYWk3 lcK4YVuyRV9C6KpVaOZwQsZxk24FzAEz8PdEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nLyJkJKqh8Q5FRJ4knrSKJOyKdX+FKa2hvlrPoHH6fKIB7VvJ96xC5Jd/ASlEm4cjH eaBwHgiov2ULPQMLFHB7BefsCwcyfWBIveUdE6XoXj2uVuQMiGCFVlVSOaMe6hoskd+b 2eqJi0JwY3a3Gwrxg9MF9C+Ao2NWTBOM5aY1A= MIME-Version: 1.0 Received: by 10.103.160.9 with SMTP id m9mr1716697muo.96.1247331185952; Sat, 11 Jul 2009 09:53:05 -0700 (PDT) In-Reply-To: <20090711060538.14002ddiitcbqcrm@mail.skype.net> References: <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> <20090711060538.14002ddiitcbqcrm@mail.skype.net> Date: Sat, 11 Jul 2009 12:53:05 -0400 Message-ID: <6e9223710907110953n4e88bdb2ide41272be9972262@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016e65b41a04188ba046e70ec99 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 16:52:43 -0000 --0016e65b41a04188ba046e70ec99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've also deployed non-standardized codecs reasonably successfully without such testing. Though when we did test Siren rigorously (as part of the ITU process for G.722./ G.722.1C) we did uncover some issues that we didn't kno= w about before. Ten years ago or so, I might have agreed with the view that this testing is not particularly useful. Now I have a different perspective. I think an SDO standardizing a new codec is in a different place from a company or consortium that is "just" rolling out a codec, and that the IETF (or any SDO really) does need to provide accurate information that characterizes any codec that they standardize. We really don't want companies interested in deployment to have to do their own listening tests in order to make sure that an IETF codec works with tonal languages. I wasn't meaning to be controversial, or to state that the IETF processes would need to be identical with other SDOs. I think that we do need to take startup costs (like developing and agreeing to test methods) into account a= s we consider this proposed working group. And even in the charter discussions we probably would need to address what level of "recommendation= " if any the IETF is making when it standardizes a codec. Other SDOs are making fairly strong statements when they standardize a codec, and do quite a bit of testing to ensure that a new codec meets its stated performance goasl. In fact, arguably such certification is one of the main benefits of their standardization work. BTW, I suspect that most comments about what the IETF can/can't do today ar= e *not* grounded in the skill sets of the participating members and the organizations they represent. Rather, they are references to this kind of question - what would it take to put the participants expertise to work in creating standards, and whether enough people who have the relevent expertise are interesting in participanting. Regards, Stephen Botzko Polycom On Sat, Jul 11, 2009 at 9:05 AM, Koen Vos wrote: > Stephen, > > The two elements that worry you seem to be: > > 1. It's hard to validate an individual codec - how good is good enough? > > Good codecs have been developed without an expensive process involving > third > parties to design and administer rigorous tests. In fact, we have several > people here at IETF who have done this with previous codecs. > > Incidentally, both the CELT and SILK proposals are already being used in > the > real-world today (tens of billions of minutes of calls have been made > through SILK for example). This exposes these codecs to a rigorous testin= g > in its own right. > > 2. It's hard to compare two candidates. > > Well, so far the number of candidates is so small that the differences > between candidates may well be clear even without rigorous testing. If we > do end up with candidates that are close calls, we can always design more > rigorous test plans to determine which is the preferred one. Let's be > pragmatic about it. > > So I agree with Christian that the IETF WG can succeed in standardizing a= n > ultra-useful codec even if the validation and selection process is > different > from, and in some aspects less rigorous than that of e.g. the ITU. > > We do need, of course, a list of test specifications and requirements. Yo= u > have already made great suggestions in this area, and I don't see much > controversy around it. > > koen > > > > Quoting stephen botzko : > > Obviously informal feedback on codec issues is useful, and I think most >> codec developers would use it to correct flaws in the design. >> >> However, I was not referring to that, I was referring to scientific >> listening tests which provide reliable assessments on codec performance. >> Other SDOs use those tests both to validate that the codec candidates me= et >> the requirements as well as in codec selection. They may also use other >> objective tests to certify that the floating point version of the >> algorithm >> sounds identical to the fixed point version, or to validate that a small >> change in design does not substantially change the codec performance. >> Designing and administering such tests is a skill in its own right, the >> folks who do that generally are not codec developers. >> >> >>>>> Also, how cares which codec will make it if they perform nearly >> identical. >> Nobody has to lose a lot in the end. >> >>> >>>>> I think the assessment process is multidimensional, not one >> dimensional. I >> don't think you're likely to have two codecs that "perform nearly >> identical" under all conditions (clean speech, noisy speech, reverberant >> speech, various languages, various network conditions). The final tradeo= ff >> will be more complicated - you'd want clear assurance that all candidate= s >> to >> meet or exceed all requirements, and you'd also find each candidate >> (though >> perhaps meeting the requirements) has its own weaknesses. Some might >> perform bettern on reverberant speech, others might perform better with >> packet loss. The WG would then need to decide which requirements are mos= t >> important in making the final selection. Using anecdotal evidence from >> uncontrolled experiments to determine how candidate codecs perform in a >> multidimensional space does not seem very likely to bring a good result = to >> me. >> >> I agree the IETF might use a different test methods from other SDOs. >> Since >> I happen to think that reliable, reproducible codec assessment is needed >> for >> the IETF to authoritatively review/recommend/standardize codecs, that >> makes >> the IETF WG task more difficult, not less - there needs to be both >> agreement >> on and development of suitable test methodolgy. >> >> Regards, >> Stephen Botzko >> Polycom >> >> On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene > >wrote: >> >> Hello, >>> >>> Recent comments suggested that there is a lack of experience in testing >>> and >>> characterizing a codec proposal. I just like to comment that the proces= s >>> of >>> testing and selecting a codec in an IETF working group might be quite >>> different as compared to the ITU/3GPP because of the open source and >>> royalty >>> free nature of the codec proposals. >>> First of all, the codec proposals can be made public at a very early >>> stage. >>> Nobody has to wait that the algorithms of the codecs need to be filled = as >>> patents. >>> Second, many users can download the codecs and test them. In fact, CELT >>> was >>> open source from the beginning and is part of the Debian Linux >>> distribution >>> since April 2008. As a consequence, it is tested and used by many Linux >>> uses >>> on a day to day basis. For example, I introduced Alexander Carot, a >>> musician >>> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it f= or >>> distributed ensemble performances. In fact, he figured out some >>> weaknesses >>> in CELT, which have been corrected then. >>> Third, the process of selecting one out of multiple codec proposal is >>> much >>> easier because no one has to lose earnings from patent fees. The codec >>> developers might only lose or win reputation. Thus, the process of >>> selecting >>> the best codec does not have to as perfect as in the ITU. The decision >>> can >>> be made by rough consensus and must not be correct beyond any reasonabl= e >>> doubts. >>> Overall, the process of codec assessment and selecting becomes easier a= nd >>> less expensive. Instead of a few real (and expensive) experts on codec >>> testing, the coding tests can be done over larger period of time by man= y >>> (thousands) of users. Also, how cares which codec will make it if they >>> perform nearly identical. Nobody has to lose a lot in the end. >>> >>> With best regards, >>> >>> Christian >>> >>> >>> PS: >>> It is out of question that Jean-Marc, Jason and many other on this >>> mailing >>> list are experts on coding design. They have my full support as chairs = of >>> this BOF (but of course not as chairs of a future WG codec). >>> >>> >>> >>> >>> -------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> _______________________________________________ >>> 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 > --0016e65b41a04188ba046e70ec99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've also deployed non-standardized codecs reasonably successfully wit= hout such testing.=A0 Though when we did test Siren rigorously (as part of = the ITU process for G.722./ G.722.1C) we did uncover some issues that we di= dn't know about before.=A0 Ten years ago or so, I might have agreed wit= h the view that this testing is not particularly useful.=A0 Now I have a di= fferent perspective.=A0

I think an SDO standardizing a new codec is in a different place from a= company or consortium that is "just" rolling out a codec, and th= at the IETF (or any SDO really) does need to provide accurate information t= hat characterizes any codec that they standardize.=A0 We really don't w= ant companies interested in deployment to have to do their own listening te= sts in order to make sure that an IETF codec works with tonal languages.
I wasn't meaning to be controversial, or to state that the IETF pro= cesses would need to be identical with other SDOs. I think that we do need = to take startup costs (like developing and agreeing to test methods) into a= ccount as we consider this proposed working group.=A0 And even in the chart= er discussions we probably would need to address what level of "recomm= endation" if any the IETF is making when it standardizes a codec.=A0 O= ther SDOs are making fairly strong statements when they standardize a codec= , and do quite a bit of testing to ensure that a new codec meets its stated= performance goasl. In fact, arguably such certification is one of the main= benefits of their standardization work.

BTW, I suspect that most comments about what the IETF can/can't do = today are not grounded in the skill sets of the participating member= s and the organizations they represent.=A0 Rather, they are references to t= his kind of question - what would it take to put the participants expertise= to work in creating standards, and whether enough people who have the rele= vent expertise are interesting in participanting.=A0

Regards,
Stephen Botzko
Polycom



On Sat, Jul 11, 2009 at 9:05 AM, Koen Vos <koen.vos@skype.net> wrote= :
Stephen,

The two elements that worry you seem to be:

1. It's hard to validate an individual codec - how good is good enough?=

Good codecs have been developed without an expensive process involving thir= d
parties to design and administer rigorous tests. In fact, we have several people here at IETF who have done this with previous codecs.

Incidentally, both the CELT and SILK proposals are already being used in th= e
real-world today (tens of billions of minutes of calls have been made
through SILK for example). This exposes these codecs to a rigorous testing<= br> in its own right.

2. It's hard to compare two candidates.

Well, so far the number of candidates is so small that the differences
between candidates may well be clear even without rigorous testing. If we do end up with candidates that are close calls, we can always design more rigorous test plans to determine which is the preferred one. Let's be pragmatic about it.

So I agree with Christian that the IETF WG can succeed in standardizing an<= br> ultra-useful codec even if the validation and selection process is differen= t
from, and in some aspects less rigorous than that of e.g. the ITU.

We do need, of course, a list of test specifications and requirements. You<= br> have already made great suggestions in this area, and I don't see much<= br> controversy around it.

koen



Quoting stephen botzko <stephen.botzko@gmail.com>:

Obviously informal feedback on codec issues is useful, and I think most
codec developers would use it to correct flaws in the design.

However, I was not referring to that, I was referring to scientific
listening tests which provide reliable assessments on codec performance. Other SDOs use those tests both to validate that the codec candidates meet<= br> the requirements as well as in codec selection. =A0They may also use other<= br> objective tests to certify that the floating point version of the algorithm=
sounds identical to the fixed point version, or to validate that a small change in design does not substantially change the codec performance.
Designing and administering such tests is a skill in its own right, the
folks who do that generally are not codec developers.


Also, how cares which codec will make it if they perform nearly identical.<= br> Nobody has to lose a lot in the end.

I think the assessment process is multidimensional, not one dimensional. = =A0I
don't think you're likely to have two codecs that =A0"perform = nearly
identical" under all conditions (clean speech, noisy speech, reverbera= nt
speech, various languages, various network conditions). The final tradeoff<= br> will be more complicated - you'd want clear assurance that all candidat= es to
meet or exceed all requirements, and you'd also find each candidate (th= ough
perhaps meeting the requirements) has its own weaknesses. =A0Some might
perform bettern on reverberant speech, others might perform better with
packet loss. The WG would then need to decide which requirements are most important in making the final selection. =A0 Using anecdotal evidence from<= br> uncontrolled experiments to determine how candidate codecs perform in a
multidimensional space does not seem very likely to bring a good result to<= br> me.

I agree the IETF might use a different test methods from other SDOs. =A0Sin= ce
I happen to think that reliable, reproducible codec assessment is needed fo= r
the IETF to authoritatively review/recommend/standardize codecs, that makes=
the IETF WG task more difficult, not less - there needs to be both agreemen= t
on and development of suitable test methodolgy.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene <hoene@uni-tuebingen.de>wrote:<= br>
Hello,

Recent comments suggested that there is a lack of experience in testing and=
characterizing a codec proposal. I just like to comment that the process of=
testing and selecting a codec in an IETF working group might be quite
different as compared to the ITU/3GPP because of the open source and
royalty
free nature of the codec proposals.
First of all, the codec proposals can be made public at a very early stage.=
Nobody has to wait that the algorithms of the codecs need to be filled as patents.
Second, many users can download the codecs and test them. In fact, CELT was=
open source from the beginning and is part of the Debian Linux distribution=
since April 2008. As a consequence, it is tested and used by many Linux
uses
on a day to day basis. For example, I introduced Alexander Carot, a
musician
and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for distributed ensemble performances. In fact, he figured out some weaknesses<= br> in CELT, which have been corrected then.
Third, the process of selecting one out of multiple codec proposal is much<= br> easier because no one has to lose earnings from patent fees. The codec
developers might only lose or win reputation. Thus, the process of
selecting
the best codec does not have to as perfect as in the ITU. The decision can<= br> be made by rough consensus and must not be correct beyond any reasonable doubts.
Overall, the process of codec assessment and selecting becomes easier and less expensive. Instead of a few real (and expensive) experts on codec
testing, the coding tests can be done over larger period of time by many (thousands) of users. Also, how cares which codec will make it if they
perform nearly identical. Nobody has to lose a lot in the end.

With best regards,

=A0Christian


PS:
It is out of question that Jean-Marc, Jason and many other on this mailing<= br> list are experts on coding design. They have my full support as chairs of this BOF (but of course not as chairs of a future WG codec).




--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/


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



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

--0016e65b41a04188ba046e70ec99-- From jmh@joelhalpern.com Sat Jul 11 12:21:52 2009 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 90AF43A6ABD for ; Sat, 11 Jul 2009 12:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYaHJjsXPpti for ; Sat, 11 Jul 2009 12:21:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 304743A6890 for ; Sat, 11 Jul 2009 12:21:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9561437E4A for ; Sat, 11 Jul 2009 12:22:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.19.0.62] (oh-69-34-180-224.sta.embarqhsd.net [69.34.180.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3A5D5437E20 for ; Sat, 11 Jul 2009 12:22:20 -0700 (PDT) Message-ID: <4A58E66A.3000909@joelhalpern.com> Date: Sat, 11 Jul 2009 15:22:18 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: codec@ietf.org References: <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <6e9223710907110406h6cd38835r5a9c4aa10a715f62@mail.gmail.com> <20090711060538.14002ddiitcbqcrm@mail.skype.net> In-Reply-To: <20090711060538.14002ddiitcbqcrm@mail.skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 19:21:52 -0000 It should be noted that the IETF has frequently had bad luck deciding between two close competitors as solutions. Sometimes, our process works very well for developing compromises and workable single interoperable solutions. However, in cases where the comparisons are complex, the evaluation criteria unclear, and the possibilities close enough for argument, we frequently have trouble. So, unless you really want to see multiple, non-interoperable, codecs from this (in which case why bother?) do not count on the IETF to be particularly better at resolving the disputes. An unbiased forum we can provide. resolving a widely split WG is much harder. (I could cite multiple very unpleasant working groups where getting to a decision was extremely painful, and sometimes did not happen. I don 't think the history lesson would actually add more than my summary.) I would also re-iterate one other point. One of the aspects of the IETF process is the community and IESG review. This works well when at least a noticeable portion of the community outside of the WG understands the space well enough to tell whether a good job has been done. And it helps if some IESG members understand the details of the space. If the work can be evaluated well, then the IETF probably is not the place to do the work. (This is a judgment call, and something on which reasonable people have been known to disagree. What I have written is how I understand things.) Yours, Joel Koen Vos wrote: > Stephen, > > The two elements that worry you seem to be: > > 1. It's hard to validate an individual codec - how good is good enough? > > Good codecs have been developed without an expensive process involving > third > parties to design and administer rigorous tests. In fact, we have several > people here at IETF who have done this with previous codecs. > > Incidentally, both the CELT and SILK proposals are already being used in > the > real-world today (tens of billions of minutes of calls have been made > through SILK for example). This exposes these codecs to a rigorous testing > in its own right. > > 2. It's hard to compare two candidates. > > Well, so far the number of candidates is so small that the differences > between candidates may well be clear even without rigorous testing. If we > do end up with candidates that are close calls, we can always design more > rigorous test plans to determine which is the preferred one. Let's be > pragmatic about it. > > So I agree with Christian that the IETF WG can succeed in standardizing an > ultra-useful codec even if the validation and selection process is > different > from, and in some aspects less rigorous than that of e.g. the ITU. > > We do need, of course, a list of test specifications and requirements. You > have already made great suggestions in this area, and I don't see much > controversy around it. > > koen > > > Quoting stephen botzko : > >> Obviously informal feedback on codec issues is useful, and I think most >> codec developers would use it to correct flaws in the design. >> >> However, I was not referring to that, I was referring to scientific >> listening tests which provide reliable assessments on codec performance. >> Other SDOs use those tests both to validate that the codec candidates >> meet >> the requirements as well as in codec selection. They may also use other >> objective tests to certify that the floating point version of the >> algorithm >> sounds identical to the fixed point version, or to validate that a small >> change in design does not substantially change the codec performance. >> Designing and administering such tests is a skill in its own right, the >> folks who do that generally are not codec developers. >> >>>>> >> Also, how cares which codec will make it if they perform nearly >> identical. >> Nobody has to lose a lot in the end. >>>>> >> I think the assessment process is multidimensional, not one >> dimensional. I >> don't think you're likely to have two codecs that "perform nearly >> identical" under all conditions (clean speech, noisy speech, reverberant >> speech, various languages, various network conditions). The final >> tradeoff >> will be more complicated - you'd want clear assurance that all >> candidates to >> meet or exceed all requirements, and you'd also find each candidate >> (though >> perhaps meeting the requirements) has its own weaknesses. Some might >> perform bettern on reverberant speech, others might perform better with >> packet loss. The WG would then need to decide which requirements are most >> important in making the final selection. Using anecdotal evidence from >> uncontrolled experiments to determine how candidate codecs perform in a >> multidimensional space does not seem very likely to bring a good >> result to >> me. >> >> I agree the IETF might use a different test methods from other SDOs. >> Since >> I happen to think that reliable, reproducible codec assessment is >> needed for >> the IETF to authoritatively review/recommend/standardize codecs, that >> makes >> the IETF WG task more difficult, not less - there needs to be both >> agreement >> on and development of suitable test methodolgy. >> >> Regards, >> Stephen Botzko >> Polycom >> >> On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene >> wrote: >> >>> Hello, >>> >>> Recent comments suggested that there is a lack of experience in >>> testing and >>> characterizing a codec proposal. I just like to comment that the >>> process of >>> testing and selecting a codec in an IETF working group might be quite >>> different as compared to the ITU/3GPP because of the open source and >>> royalty >>> free nature of the codec proposals. >>> First of all, the codec proposals can be made public at a very early >>> stage. >>> Nobody has to wait that the algorithms of the codecs need to be >>> filled as >>> patents. >>> Second, many users can download the codecs and test them. In fact, >>> CELT was >>> open source from the beginning and is part of the Debian Linux >>> distribution >>> since April 2008. As a consequence, it is tested and used by many Linux >>> uses >>> on a day to day basis. For example, I introduced Alexander Carot, a >>> musician >>> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it >>> for >>> distributed ensemble performances. In fact, he figured out some >>> weaknesses >>> in CELT, which have been corrected then. >>> Third, the process of selecting one out of multiple codec proposal is >>> much >>> easier because no one has to lose earnings from patent fees. The codec >>> developers might only lose or win reputation. Thus, the process of >>> selecting >>> the best codec does not have to as perfect as in the ITU. The >>> decision can >>> be made by rough consensus and must not be correct beyond any reasonable >>> doubts. >>> Overall, the process of codec assessment and selecting becomes easier >>> and >>> less expensive. Instead of a few real (and expensive) experts on codec >>> testing, the coding tests can be done over larger period of time by many >>> (thousands) of users. Also, how cares which codec will make it if they >>> perform nearly identical. Nobody has to lose a lot in the end. >>> >>> With best regards, >>> >>> Christian >>> >>> >>> PS: >>> It is out of question that Jean-Marc, Jason and many other on this >>> mailing >>> list are experts on coding design. They have my full support as >>> chairs of >>> this BOF (but of course not as chairs of a future WG codec). >>> >>> >>> >>> >>> -------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of Tübingen >>> Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> _______________________________________________ >>> 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 stewe@stewe.org Sat Jul 11 13:41:17 2009 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 C16983A677D for ; Sat, 11 Jul 2009 13:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, SARE_PRODUCT=0.333] 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 i6msE5FUYgHs for ; Sat, 11 Jul 2009 13:41:16 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 8F5323A6B2A for ; Sat, 11 Jul 2009 13:41:15 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 335891-1743317 for ; Sat, 11 Jul 2009 22:41:44 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sat, 11 Jul 2009 13:41:34 -0700 From: Stephan Wenger To: "codec@ietf.org" Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoBvCf/icQtkkXiTF2gFC9OiEe73wAM0McQAB4j1Y0= In-Reply-To: <001f01ca01f4$c5d74d30$5185e790$@de> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:41:17 -0000 Hi Christian, I have two remarks to your post. The first is that it is IMHO unrealistic to assume that there is any difference in the timing of a proposal publication due to patent issues. You (and, believe it or not, me as well) may not like that speech coding is a heavily encumbered area. But it is. In such an environment, it would be outright stupid for any entity with the resources and knowledge to file for patents not to do so when the opportunity arises, if only to build up an defensive portfolio. That's completely independent from the future licensing terms or revenues. We have evidence that such filings did happen= , see https://datatracker.ietf.org/ipr/1164/ (related to silk) or https://datatracker.ietf.org/ipr/319/ (related to iLBC and its payload format). Once you have decided that you need a portfolio, defensive or otherwise, you are down to the timing requirements as imposed by patent law= . The secrecy around the internal design of speech codecs in other bodies, as far as I understand, is not so much related to patent issues, but more to avoid the analysis of your work by others in order to identify weaknesses i= n that design, with the intention to argue towards selection criteria that would make your codec look bad. (Arguably, we have already seen some of this discussion happening on this very list---which would actually speak in favor of keeping designs closed...) The second remark is that there can very well be serious commercial competition between codecs, even assuming that the main proponents have promised to license them for free (or making their relevant patents available under an open-source friendly non-assert). There have been small companies in the codec business that built there whole business model on th= e success of a certain codec technology, and, as part of their corporate strategy, decided to forego the licensing revenue opportunity in favor of growing the market and making their product offerings indispensible. (My own career included a tenure in one of those companies.) That's only one example why there's much more than reputation at stake here, even if you folks were able to establish a royalty free ecosystem for a certain class o= f speech codecs. Which I don't think you are, based on my limited knowledge of the patent landscape in this area, but that's another issue, and one where there will hardly be a lot of discussion due to the legal environment= . Both aspects suggests to me that there is value in a reasonably well developed process to select (or integrate, as the case may be) technologies from the various proponents, which may very well include characterization and testing in multiple languages. I agree with you that this process does not necessarily need to be as formalized as it is in some other SDOs. However, that agreement does not stem from a major difference in the commercial environment, but results mostly from my personal opinion that those folks over-formalize their processes. However, I also think that the IETF's rather informal processes---while absolutely appropriate for collaborative work on protocols, as shown by several hundreds of successful examples---are suboptimal in this case. Something new is needed if this WG would be established, perhaps less formal and expensive as in the ITU or 3GPP, but very different from what we have elsewhere in the IETF. Regards, Stephan On 7/10/09 11:56 PM, "Christian Hoene" wrote: > Hello, >=20 > Recent comments suggested that there is a lack of experience in testing a= nd > characterizing a codec proposal. I just like to comment that the process = of > testing and selecting a codec in an IETF working group might be quite > different as compared to the ITU/3GPP because of the open source and roya= lty > free nature of the codec proposals. > First of all, the codec proposals can be made public at a very early stag= e. > Nobody has to wait that the algorithms of the codecs need to be filled as > patents.=20 > Second, many users can download the codecs and test them. In fact, CELT w= as > open source from the beginning and is part of the Debian Linux distributi= on > since April 2008. As a consequence, it is tested and used by many Linux u= ses > on a day to day basis. For example, I introduced Alexander Carot, a music= ian > and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for > distributed ensemble performances. In fact, he figured out some weaknesse= s > in CELT, which have been corrected then. > Third, the process of selecting one out of multiple codec proposal is muc= h > easier because no one has to lose earnings from patent fees. The codec > developers might only lose or win reputation. Thus, the process of select= ing > the best codec does not have to as perfect as in the ITU. The decision ca= n > be made by rough consensus and must not be correct beyond any reasonable > doubts. > Overall, the process of codec assessment and selecting becomes easier and > less expensive. Instead of a few real (and expensive) experts on codec > testing, the coding tests can be done over larger period of time by many > (thousands) of users. Also, how cares which codec will make it if they > perform nearly identical. Nobody has to lose a lot in the end. >=20 > With best regards, >=20 > Christian >=20 >=20 > PS: > It is out of question that Jean-Marc, Jason and many other on this mailin= g > list are experts on coding design. They have my full support as chairs of > this BOF (but of course not as chairs of a future WG codec). >=20 >=20 >=20 >=20 > -------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From tme@americafree.tv Sat Jul 11 13:44:45 2009 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 999A33A6938 for ; Sat, 11 Jul 2009 13:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 Xuqwsz4Ff6Hn for ; Sat, 11 Jul 2009 13:44:44 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id CA92C28C0D7 for ; Sat, 11 Jul 2009 13:44:23 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 30440436590E; Sat, 11 Jul 2009 16:44:52 -0400 (EDT) Message-Id: <832F91CD-42B2-4FDA-8473-F3FF7E525FC6@americafree.tv> From: Marshall Eubanks To: Stephan Wenger In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 16:44:49 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:44:45 -0000 Dear Stephan; Would you regard ISMA as a possible template for this work ? Regards Marshall On Jul 11, 2009, at 4:41 PM, Stephan Wenger wrote: > Hi Christian, > > I have two remarks to your post. > > The first is that it is IMHO unrealistic to assume that there is any > difference in the timing of a proposal publication due to patent =20 > issues. > You (and, believe it or not, me as well) may not like that speech =20 > coding is > a heavily encumbered area. But it is. In such an environment, it =20 > would be > outright stupid for any entity with the resources and knowledge to =20 > file for > patents not to do so when the opportunity arises, if only to build =20 > up an > defensive portfolio. That's completely independent from the future > licensing terms or revenues. We have evidence that such filings did =20= > happen, > see https://datatracker.ietf.org/ipr/1164/ (related to silk) or > https://datatracker.ietf.org/ipr/319/ (related to iLBC and its payload > format). Once you have decided that you need a portfolio, defensive =20= > or > otherwise, you are down to the timing requirements as imposed by =20 > patent law. > The secrecy around the internal design of speech codecs in other =20 > bodies, as > far as I understand, is not so much related to patent issues, but =20 > more to > avoid the analysis of your work by others in order to identify =20 > weaknesses in > that design, with the intention to argue towards selection criteria =20= > that > would make your codec look bad. (Arguably, we have already seen =20 > some of > this discussion happening on this very list---which would actually =20 > speak in > favor of keeping designs closed...) > > The second remark is that there can very well be serious commercial > competition between codecs, even assuming that the main proponents =20 > have > promised to license them for free (or making their relevant patents > available under an open-source friendly non-assert). There have =20 > been small > companies in the codec business that built there whole business =20 > model on the > success of a certain codec technology, and, as part of their corporate > strategy, decided to forego the licensing revenue opportunity in =20 > favor of > growing the market and making their product offerings =20 > indispensible. (My > own career included a tenure in one of those companies.) That's =20 > only one > example why there's much more than reputation at stake here, even if =20= > you > folks were able to establish a royalty free ecosystem for a certain =20= > class of > speech codecs. Which I don't think you are, based on my limited =20 > knowledge > of the patent landscape in this area, but that's another issue, and =20= > one > where there will hardly be a lot of discussion due to the legal =20 > environment. > > Both aspects suggests to me that there is value in a reasonably well > developed process to select (or integrate, as the case may be) =20 > technologies > from the various proponents, which may very well include =20 > characterization > and testing in multiple languages. I agree with you that this =20 > process does > not necessarily need to be as formalized as it is in some other SDOs. > However, that agreement does not stem from a major difference in the > commercial environment, but results mostly from my personal opinion =20= > that > those folks over-formalize their processes. However, I also think =20 > that the > IETF's rather informal processes---while absolutely appropriate for > collaborative work on protocols, as shown by several hundreds of =20 > successful > examples---are suboptimal in this case. Something new is needed if =20= > this WG > would be established, perhaps less formal and expensive as in the =20 > ITU or > 3GPP, but very different from what we have elsewhere in the IETF. > > > Regards, > Stephan > > > On 7/10/09 11:56 PM, "Christian Hoene" wrote: > >> Hello, >> >> Recent comments suggested that there is a lack of experience in =20 >> testing and >> characterizing a codec proposal. I just like to comment that the =20 >> process of >> testing and selecting a codec in an IETF working group might be quite >> different as compared to the ITU/3GPP because of the open source =20 >> and royalty >> free nature of the codec proposals. >> First of all, the codec proposals can be made public at a very =20 >> early stage. >> Nobody has to wait that the algorithms of the codecs need to be =20 >> filled as >> patents. >> Second, many users can download the codecs and test them. In fact, =20= >> CELT was >> open source from the beginning and is part of the Debian Linux =20 >> distribution >> since April 2008. As a consequence, it is tested and used by many =20 >> Linux uses >> on a day to day basis. For example, I introduced Alexander Carot, a =20= >> musician >> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using =20= >> it for >> distributed ensemble performances. In fact, he figured out some =20 >> weaknesses >> in CELT, which have been corrected then. >> Third, the process of selecting one out of multiple codec proposal =20= >> is much >> easier because no one has to lose earnings from patent fees. The =20 >> codec >> developers might only lose or win reputation. Thus, the process of =20= >> selecting >> the best codec does not have to as perfect as in the ITU. The =20 >> decision can >> be made by rough consensus and must not be correct beyond any =20 >> reasonable >> doubts. >> Overall, the process of codec assessment and selecting becomes =20 >> easier and >> less expensive. Instead of a few real (and expensive) experts on =20 >> codec >> testing, the coding tests can be done over larger period of time by =20= >> many >> (thousands) of users. Also, how cares which codec will make it if =20 >> they >> perform nearly identical. Nobody has to lose a lot in the end. >> >> With best regards, >> >> Christian >> >> >> PS: >> It is out of question that Jean-Marc, Jason and many other on this =20= >> mailing >> list are experts on coding design. They have my full support as =20 >> chairs of >> this BOF (but of course not as chairs of a future WG codec). >> >> >> >> >> -------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> _______________________________________________ >> 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 > Regards Marshall Eubanks email : tme@americafree.tv twitter : @TMEubanks Cut the Cord with AmericaFree.TV From stewe@stewe.org Sat Jul 11 13:53:35 2009 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 9B4EF3A695F for ; Sat, 11 Jul 2009 13:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, SARE_PRODUCT=0.333] 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 cjMTrmZet6vc for ; Sat, 11 Jul 2009 13:53:34 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id B83683A6B34 for ; Sat, 11 Jul 2009 13:53:33 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 335901-1743317 for multiple; Sat, 11 Jul 2009 22:54:02 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sat, 11 Jul 2009 13:53:53 -0700 From: Stephan Wenger To: Marshall Eubanks Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoCabLqiAMvbqexvUOkTJNJGID12Q== In-Reply-To: <832F91CD-42B2-4FDA-8473-F3FF7E525FC6@americafree.tv> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:53:35 -0000 Hi Marshall, I'm not so familiar with ISMA. However, my vague recollection is that they are as committed to MPEG codecs as they are to IETF protocol technologies (plus/minus ultravox, which they are doing on their own AFAIK). That suggests, that the hard codecc selection work has already been done once th= e integration work hits ISMA. I may be wrong. Regards, Stephan =20 On 7/11/09 1:44 PM, "Marshall Eubanks" wrote: > Dear Stephan; >=20 > Would you regard ISMA as a possible template for this work ? >=20 > Regards > Marshall >=20 > On Jul 11, 2009, at 4:41 PM, Stephan Wenger wrote: >=20 >> Hi Christian, >>=20 >> I have two remarks to your post. >>=20 >> The first is that it is IMHO unrealistic to assume that there is any >> difference in the timing of a proposal publication due to patent >> issues. >> You (and, believe it or not, me as well) may not like that speech >> coding is >> a heavily encumbered area. But it is. In such an environment, it >> would be >> outright stupid for any entity with the resources and knowledge to >> file for >> patents not to do so when the opportunity arises, if only to build >> up an >> defensive portfolio. That's completely independent from the future >> licensing terms or revenues. We have evidence that such filings did >> happen, >> see https://datatracker.ietf.org/ipr/1164/ (related to silk) or >> https://datatracker.ietf.org/ipr/319/ (related to iLBC and its payload >> format). Once you have decided that you need a portfolio, defensive >> or >> otherwise, you are down to the timing requirements as imposed by >> patent law. >> The secrecy around the internal design of speech codecs in other >> bodies, as >> far as I understand, is not so much related to patent issues, but >> more to >> avoid the analysis of your work by others in order to identify >> weaknesses in >> that design, with the intention to argue towards selection criteria >> that >> would make your codec look bad. (Arguably, we have already seen >> some of >> this discussion happening on this very list---which would actually >> speak in >> favor of keeping designs closed...) >>=20 >> The second remark is that there can very well be serious commercial >> competition between codecs, even assuming that the main proponents >> have >> promised to license them for free (or making their relevant patents >> available under an open-source friendly non-assert). There have >> been small >> companies in the codec business that built there whole business >> model on the >> success of a certain codec technology, and, as part of their corporate >> strategy, decided to forego the licensing revenue opportunity in >> favor of >> growing the market and making their product offerings >> indispensible. (My >> own career included a tenure in one of those companies.) That's >> only one >> example why there's much more than reputation at stake here, even if >> you >> folks were able to establish a royalty free ecosystem for a certain >> class of >> speech codecs. Which I don't think you are, based on my limited >> knowledge >> of the patent landscape in this area, but that's another issue, and >> one >> where there will hardly be a lot of discussion due to the legal >> environment. >>=20 >> Both aspects suggests to me that there is value in a reasonably well >> developed process to select (or integrate, as the case may be) >> technologies >> from the various proponents, which may very well include >> characterization >> and testing in multiple languages. I agree with you that this >> process does >> not necessarily need to be as formalized as it is in some other SDOs. >> However, that agreement does not stem from a major difference in the >> commercial environment, but results mostly from my personal opinion >> that >> those folks over-formalize their processes. However, I also think >> that the >> IETF's rather informal processes---while absolutely appropriate for >> collaborative work on protocols, as shown by several hundreds of >> successful >> examples---are suboptimal in this case. Something new is needed if >> this WG >> would be established, perhaps less formal and expensive as in the >> ITU or >> 3GPP, but very different from what we have elsewhere in the IETF. >>=20 >>=20 >> Regards, >> Stephan >>=20 >>=20 >> On 7/10/09 11:56 PM, "Christian Hoene" wrote: >>=20 >>> Hello, >>>=20 >>> Recent comments suggested that there is a lack of experience in >>> testing and >>> characterizing a codec proposal. I just like to comment that the >>> process of >>> testing and selecting a codec in an IETF working group might be quite >>> different as compared to the ITU/3GPP because of the open source >>> and royalty >>> free nature of the codec proposals. >>> First of all, the codec proposals can be made public at a very >>> early stage. >>> Nobody has to wait that the algorithms of the codecs need to be >>> filled as >>> patents. >>> Second, many users can download the codecs and test them. In fact, >>> CELT was >>> open source from the beginning and is part of the Debian Linux >>> distribution >>> since April 2008. As a consequence, it is tested and used by many >>> Linux uses >>> on a day to day basis. For example, I introduced Alexander Carot, a >>> musician >>> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using >>> it for >>> distributed ensemble performances. In fact, he figured out some >>> weaknesses >>> in CELT, which have been corrected then. >>> Third, the process of selecting one out of multiple codec proposal >>> is much >>> easier because no one has to lose earnings from patent fees. The >>> codec >>> developers might only lose or win reputation. Thus, the process of >>> selecting >>> the best codec does not have to as perfect as in the ITU. The >>> decision can >>> be made by rough consensus and must not be correct beyond any >>> reasonable >>> doubts. >>> Overall, the process of codec assessment and selecting becomes >>> easier and >>> less expensive. Instead of a few real (and expensive) experts on >>> codec >>> testing, the coding tests can be done over larger period of time by >>> many >>> (thousands) of users. Also, how cares which codec will make it if >>> they >>> perform nearly identical. Nobody has to lose a lot in the end. >>>=20 >>> With best regards, >>>=20 >>> Christian >>>=20 >>>=20 >>> PS: >>> It is out of question that Jean-Marc, Jason and many other on this >>> mailing >>> list are experts on coding design. They have my full support as >>> chairs of >>> this BOF (but of course not as chairs of a future WG codec). >>>=20 >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>>=20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 > Regards > Marshall Eubanks > email : tme@americafree.tv > twitter : @TMEubanks > Cut the Cord with AmericaFree.TV >=20 >=20 >=20 >=20 >=20 From tme@americafree.tv Sat Jul 11 13:56:51 2009 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 8EDAA3A6A73 for ; Sat, 11 Jul 2009 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, SARE_PRODUCT=0.333] 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 1TOkTt-ZUvFZ for ; Sat, 11 Jul 2009 13:56:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 4705E3A695F for ; Sat, 11 Jul 2009 13:56:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id F416543659D8; Sat, 11 Jul 2009 16:57:18 -0400 (EDT) Message-Id: <31BF463D-485C-4192-A76A-FEE5A59F6F00@americafree.tv> From: Marshall Eubanks To: Stephan Wenger In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 16:57:11 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:56:51 -0000 On Jul 11, 2009, at 4:53 PM, Stephan Wenger wrote: > Hi Marshall, > I'm not so familiar with ISMA. However, my vague recollection is =20 > that they > are as committed to MPEG codecs as they are to IETF protocol =20 > technologies > (plus/minus ultravox, which they are doing on their own AFAIK). That > suggests, that the hard codecc selection work has already been done =20= > once the > integration work hits ISMA. I may be wrong. Yes, they picked certain specific codec profiles from the already =20 published set for solidification. In my recollection they were - pretty light weight and - focused on interoperation I mentioned them because they were a little more formal than the IETF, =20= but not that much. Regards Marshall > > Regards, > Stephan > > > > On 7/11/09 1:44 PM, "Marshall Eubanks" wrote: > >> Dear Stephan; >> >> Would you regard ISMA as a possible template for this work ? >> >> Regards >> Marshall >> >> On Jul 11, 2009, at 4:41 PM, Stephan Wenger wrote: >> >>> Hi Christian, >>> >>> I have two remarks to your post. >>> >>> The first is that it is IMHO unrealistic to assume that there is any >>> difference in the timing of a proposal publication due to patent >>> issues. >>> You (and, believe it or not, me as well) may not like that speech >>> coding is >>> a heavily encumbered area. But it is. In such an environment, it >>> would be >>> outright stupid for any entity with the resources and knowledge to >>> file for >>> patents not to do so when the opportunity arises, if only to build >>> up an >>> defensive portfolio. That's completely independent from the future >>> licensing terms or revenues. We have evidence that such filings did >>> happen, >>> see https://datatracker.ietf.org/ipr/1164/ (related to silk) or >>> https://datatracker.ietf.org/ipr/319/ (related to iLBC and its =20 >>> payload >>> format). Once you have decided that you need a portfolio, defensive >>> or >>> otherwise, you are down to the timing requirements as imposed by >>> patent law. >>> The secrecy around the internal design of speech codecs in other >>> bodies, as >>> far as I understand, is not so much related to patent issues, but >>> more to >>> avoid the analysis of your work by others in order to identify >>> weaknesses in >>> that design, with the intention to argue towards selection criteria >>> that >>> would make your codec look bad. (Arguably, we have already seen >>> some of >>> this discussion happening on this very list---which would actually >>> speak in >>> favor of keeping designs closed...) >>> >>> The second remark is that there can very well be serious commercial >>> competition between codecs, even assuming that the main proponents >>> have >>> promised to license them for free (or making their relevant patents >>> available under an open-source friendly non-assert). There have >>> been small >>> companies in the codec business that built there whole business >>> model on the >>> success of a certain codec technology, and, as part of their =20 >>> corporate >>> strategy, decided to forego the licensing revenue opportunity in >>> favor of >>> growing the market and making their product offerings >>> indispensible. (My >>> own career included a tenure in one of those companies.) That's >>> only one >>> example why there's much more than reputation at stake here, even if >>> you >>> folks were able to establish a royalty free ecosystem for a certain >>> class of >>> speech codecs. Which I don't think you are, based on my limited >>> knowledge >>> of the patent landscape in this area, but that's another issue, and >>> one >>> where there will hardly be a lot of discussion due to the legal >>> environment. >>> >>> Both aspects suggests to me that there is value in a reasonably well >>> developed process to select (or integrate, as the case may be) >>> technologies >>> from the various proponents, which may very well include >>> characterization >>> and testing in multiple languages. I agree with you that this >>> process does >>> not necessarily need to be as formalized as it is in some other =20 >>> SDOs. >>> However, that agreement does not stem from a major difference in the >>> commercial environment, but results mostly from my personal opinion >>> that >>> those folks over-formalize their processes. However, I also think >>> that the >>> IETF's rather informal processes---while absolutely appropriate for >>> collaborative work on protocols, as shown by several hundreds of >>> successful >>> examples---are suboptimal in this case. Something new is needed if >>> this WG >>> would be established, perhaps less formal and expensive as in the >>> ITU or >>> 3GPP, but very different from what we have elsewhere in the IETF. >>> >>> >>> Regards, >>> Stephan >>> >>> >>> On 7/10/09 11:56 PM, "Christian Hoene" =20 >>> wrote: >>> >>>> Hello, >>>> >>>> Recent comments suggested that there is a lack of experience in >>>> testing and >>>> characterizing a codec proposal. I just like to comment that the >>>> process of >>>> testing and selecting a codec in an IETF working group might be =20 >>>> quite >>>> different as compared to the ITU/3GPP because of the open source >>>> and royalty >>>> free nature of the codec proposals. >>>> First of all, the codec proposals can be made public at a very >>>> early stage. >>>> Nobody has to wait that the algorithms of the codecs need to be >>>> filled as >>>> patents. >>>> Second, many users can download the codecs and test them. In fact, >>>> CELT was >>>> open source from the beginning and is part of the Debian Linux >>>> distribution >>>> since April 2008. As a consequence, it is tested and used by many >>>> Linux uses >>>> on a day to day basis. For example, I introduced Alexander Carot, a >>>> musician >>>> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using >>>> it for >>>> distributed ensemble performances. In fact, he figured out some >>>> weaknesses >>>> in CELT, which have been corrected then. >>>> Third, the process of selecting one out of multiple codec proposal >>>> is much >>>> easier because no one has to lose earnings from patent fees. The >>>> codec >>>> developers might only lose or win reputation. Thus, the process of >>>> selecting >>>> the best codec does not have to as perfect as in the ITU. The >>>> decision can >>>> be made by rough consensus and must not be correct beyond any >>>> reasonable >>>> doubts. >>>> Overall, the process of codec assessment and selecting becomes >>>> easier and >>>> less expensive. Instead of a few real (and expensive) experts on >>>> codec >>>> testing, the coding tests can be done over larger period of time by >>>> many >>>> (thousands) of users. Also, how cares which codec will make it if >>>> they >>>> perform nearly identical. Nobody has to lose a lot in the end. >>>> >>>> With best regards, >>>> >>>> Christian >>>> >>>> >>>> PS: >>>> It is out of question that Jean-Marc, Jason and many other on this >>>> mailing >>>> list are experts on coding design. They have my full support as >>>> chairs of >>>> this BOF (but of course not as chairs of a future WG codec). >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------- >>>> Dr.-Ing. Christian Hoene >>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>> http://www.net.uni-tuebingen.de/ >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> Regards >> Marshall Eubanks >> email : tme@americafree.tv >> twitter : @TMEubanks >> Cut the Cord with AmericaFree.TV >> >> >> >> >> > > > Regards Marshall Eubanks email : tme@americafree.tv twitter : @TMEubanks Cut the Cord with AmericaFree.TV From stewe@stewe.org Sat Jul 11 15:29:17 2009 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 AC0403A6B12 for ; Sat, 11 Jul 2009 15:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, SARE_PRODUCT=0.333] 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 IJYbHN9jRJuy for ; Sat, 11 Jul 2009 15:29:16 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 1377F3A6846 for ; Sat, 11 Jul 2009 15:28:44 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 335992-1743317 for multiple; Sun, 12 Jul 2009 00:29:13 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sat, 11 Jul 2009 15:28:58 -0700 From: Stephan Wenger To: Marshall Eubanks Message-ID: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoCdvtcomnXr1pGlUqcuztdoIN0UA== In-Reply-To: <31BF463D-485C-4192-A76A-FEE5A59F6F00@americafree.tv> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 22:29:17 -0000 Hi Marshall, all of the committees I'm aware of that handle international speech standardization from scratch (that is, without starting from an already standardized approach) operate under essentially similar rules and procedures. Those include the ITU-T, MPEG (not a great example with their rather unsuccessful speech codec work in MPEG-4, but there is also their rather successful audio codec work), 3GPP, and 3GPP2 (and their respective parent organizations as well as their predecessors, GSM, TIA, you name it). Of course, all of those are also RAND-type SDOs. Whether the procedures used are a direct result of their RAND-type licensing requirements, or a logical result of a procedure development process independent from the licensing requirements, is subject to debate here. However, one argument I have made just recently is that, licensing revenue or not, there is quite a bit at stake here, which may suggest that, at the end of a rules developmen= t process, we may end up with comparable results. There are a number of organizations that handled speech codec design (and arguably, standardization, though the application of this term is disputed by many) on a national level. In the US, that would include the DoD stuff like FS-1015 (LPC-10e), CELP, MELP, and STANAG. Similar efforts have been ongoing at least in Japan and in Korea, and perhaps elsewhere as well. My understanding is that their approach was/is roughly equivalent to the one o= f the international bodies, just with less commercial competition and more control by the "customer" (which also ran the standardization efforts). Whether that necessarily speaks in favor of the procedures of these bodies is another question. However, there's certainly quite a bit of "running code" out there, in the sense of experience. (I do not want to ignore the speech codec work by the open source people completely in this email. However, what they have done, so far, hardly qualifies as an international standardization effort for a number of reason= s I could name---which, I assume, is the reason we have this discussion in th= e first place.) Regards, Stephan On 7/11/09 1:57 PM, "Marshall Eubanks" wrote: >=20 > On Jul 11, 2009, at 4:53 PM, Stephan Wenger wrote: >=20 >> Hi Marshall, >> I'm not so familiar with ISMA. However, my vague recollection is >> that they >> are as committed to MPEG codecs as they are to IETF protocol >> technologies >> (plus/minus ultravox, which they are doing on their own AFAIK). That >> suggests, that the hard codecc selection work has already been done >> once the >> integration work hits ISMA. I may be wrong. >=20 > Yes, they picked certain specific codec profiles from the already > published set for solidification. >=20 > In my recollection they were >=20 > - pretty light weight and > - focused on interoperation >=20 > I mentioned them because they were a little more formal than the IETF, > but not that much. >=20 > Regards > Marshall >=20 >=20 >>=20 >> Regards, >> Stephan >>=20 >>=20 >>=20 >> On 7/11/09 1:44 PM, "Marshall Eubanks" wrote: >>=20 >>> Dear Stephan; >>>=20 >>> Would you regard ISMA as a possible template for this work ? >>>=20 >>> Regards >>> Marshall >>>=20 >>> On Jul 11, 2009, at 4:41 PM, Stephan Wenger wrote: >>>=20 >>>> Hi Christian, >>>>=20 >>>> I have two remarks to your post. >>>>=20 >>>> The first is that it is IMHO unrealistic to assume that there is any >>>> difference in the timing of a proposal publication due to patent >>>> issues. >>>> You (and, believe it or not, me as well) may not like that speech >>>> coding is >>>> a heavily encumbered area. But it is. In such an environment, it >>>> would be >>>> outright stupid for any entity with the resources and knowledge to >>>> file for >>>> patents not to do so when the opportunity arises, if only to build >>>> up an >>>> defensive portfolio. That's completely independent from the future >>>> licensing terms or revenues. We have evidence that such filings did >>>> happen, >>>> see https://datatracker.ietf.org/ipr/1164/ (related to silk) or >>>> https://datatracker.ietf.org/ipr/319/ (related to iLBC and its >>>> payload >>>> format). Once you have decided that you need a portfolio, defensive >>>> or >>>> otherwise, you are down to the timing requirements as imposed by >>>> patent law. >>>> The secrecy around the internal design of speech codecs in other >>>> bodies, as >>>> far as I understand, is not so much related to patent issues, but >>>> more to >>>> avoid the analysis of your work by others in order to identify >>>> weaknesses in >>>> that design, with the intention to argue towards selection criteria >>>> that >>>> would make your codec look bad. (Arguably, we have already seen >>>> some of >>>> this discussion happening on this very list---which would actually >>>> speak in >>>> favor of keeping designs closed...) >>>>=20 >>>> The second remark is that there can very well be serious commercial >>>> competition between codecs, even assuming that the main proponents >>>> have >>>> promised to license them for free (or making their relevant patents >>>> available under an open-source friendly non-assert). There have >>>> been small >>>> companies in the codec business that built there whole business >>>> model on the >>>> success of a certain codec technology, and, as part of their >>>> corporate >>>> strategy, decided to forego the licensing revenue opportunity in >>>> favor of >>>> growing the market and making their product offerings >>>> indispensible. (My >>>> own career included a tenure in one of those companies.) That's >>>> only one >>>> example why there's much more than reputation at stake here, even if >>>> you >>>> folks were able to establish a royalty free ecosystem for a certain >>>> class of >>>> speech codecs. Which I don't think you are, based on my limited >>>> knowledge >>>> of the patent landscape in this area, but that's another issue, and >>>> one >>>> where there will hardly be a lot of discussion due to the legal >>>> environment. >>>>=20 >>>> Both aspects suggests to me that there is value in a reasonably well >>>> developed process to select (or integrate, as the case may be) >>>> technologies >>>> from the various proponents, which may very well include >>>> characterization >>>> and testing in multiple languages. I agree with you that this >>>> process does >>>> not necessarily need to be as formalized as it is in some other >>>> SDOs. >>>> However, that agreement does not stem from a major difference in the >>>> commercial environment, but results mostly from my personal opinion >>>> that >>>> those folks over-formalize their processes. However, I also think >>>> that the >>>> IETF's rather informal processes---while absolutely appropriate for >>>> collaborative work on protocols, as shown by several hundreds of >>>> successful >>>> examples---are suboptimal in this case. Something new is needed if >>>> this WG >>>> would be established, perhaps less formal and expensive as in the >>>> ITU or >>>> 3GPP, but very different from what we have elsewhere in the IETF. >>>>=20 >>>>=20 >>>> Regards, >>>> Stephan >>>>=20 >>>>=20 >>>> On 7/10/09 11:56 PM, "Christian Hoene" >>>> wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> Recent comments suggested that there is a lack of experience in >>>>> testing and >>>>> characterizing a codec proposal. I just like to comment that the >>>>> process of >>>>> testing and selecting a codec in an IETF working group might be >>>>> quite >>>>> different as compared to the ITU/3GPP because of the open source >>>>> and royalty >>>>> free nature of the codec proposals. >>>>> First of all, the codec proposals can be made public at a very >>>>> early stage. >>>>> Nobody has to wait that the algorithms of the codecs need to be >>>>> filled as >>>>> patents. >>>>> Second, many users can download the codecs and test them. In fact, >>>>> CELT was >>>>> open source from the beginning and is part of the Debian Linux >>>>> distribution >>>>> since April 2008. As a consequence, it is tested and used by many >>>>> Linux uses >>>>> on a day to day basis. For example, I introduced Alexander Carot, a >>>>> musician >>>>> and scientist, to Jean-Marc Valin. Alex tested CELT on stage using >>>>> it for >>>>> distributed ensemble performances. In fact, he figured out some >>>>> weaknesses >>>>> in CELT, which have been corrected then. >>>>> Third, the process of selecting one out of multiple codec proposal >>>>> is much >>>>> easier because no one has to lose earnings from patent fees. The >>>>> codec >>>>> developers might only lose or win reputation. Thus, the process of >>>>> selecting >>>>> the best codec does not have to as perfect as in the ITU. The >>>>> decision can >>>>> be made by rough consensus and must not be correct beyond any >>>>> reasonable >>>>> doubts. >>>>> Overall, the process of codec assessment and selecting becomes >>>>> easier and >>>>> less expensive. Instead of a few real (and expensive) experts on >>>>> codec >>>>> testing, the coding tests can be done over larger period of time by >>>>> many >>>>> (thousands) of users. Also, how cares which codec will make it if >>>>> they >>>>> perform nearly identical. Nobody has to lose a lot in the end. >>>>>=20 >>>>> With best regards, >>>>>=20 >>>>> Christian >>>>>=20 >>>>>=20 >>>>> PS: >>>>> It is out of question that Jean-Marc, Jason and many other on this >>>>> mailing >>>>> list are experts on coding design. They have my full support as >>>>> chairs of >>>>> this BOF (but of course not as chairs of a future WG codec). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------------------------------------------------------- >>>>> Dr.-Ing. Christian Hoene >>>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>>> http://www.net.uni-tuebingen.de/ >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>>=20 >>>=20 >>> Regards >>> Marshall Eubanks >>> email : tme@americafree.tv >>> twitter : @TMEubanks >>> Cut the Cord with AmericaFree.TV >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > Regards > Marshall Eubanks > email : tme@americafree.tv > twitter : @TMEubanks > Cut the Cord with AmericaFree.TV >=20 >=20 >=20 >=20 >=20 From koen.vos@skype.net Sat Jul 11 17:26:06 2009 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 C5BED3A697A for ; Sat, 11 Jul 2009 17:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 Cdsv4q1VZ6sA for ; Sat, 11 Jul 2009 17:26:05 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id BA4233A689D for ; Sat, 11 Jul 2009 17:26:03 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 990962007AB11 for ; Sun, 12 Jul 2009 02:26:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=g/9dQVTWXUmO 3CoMkFlH7yhd7zE=; b=LNyEmgn4fxNK5XL+WKTGtg54F9VlOc8fifZiGdKy9hWY 9Q6o2czFfgmbPV/j1YLBpyoFPG8JIGjRryVHUYc4dulfMp0QTuTbPTLshBIv0XOI pFDoPY7h5+MVSTtQzV511GAkK+UVQz+4xJ2rGPEF5RKenXU+XocXS6DWQQgFdAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=g1gTfZfLczTqsdv/xFDZ nZcvVchbA5UoQglFKghVPXL0ftibGosylOBR7dm5k7SuLNlDzezdRCiqAWW49Wb6 p7PsHFKrO9dfH4eWCEfFQ4NIpPPFgcvtUXCKNFX+ZPGiXQlZ6c7brLwszjyh0NnO WOl9eeM2zC0K0G0tJzR5aMU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 979442007A955 for ; Sun, 12 Jul 2009 02:26:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuYrVGsfJdig for ; Sun, 12 Jul 2009 02:26:30 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C01812007AADE; Sun, 12 Jul 2009 02:26:30 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 11 Jul 2009 17:26:30 -0700 Message-ID: <20090711172630.19485o99spktohx2@mail.skype.net> Date: Sat, 11 Jul 2009 17:26:30 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 00:26:07 -0000 Herve, I would argue that the ITU-style testing process is expensive and ineffective. The ITU model stems from a time when codecs were part of firmware that was rolled out on a large scale. Since firmware is not easily updated by end-users, it had to work for every user from day one. Any bugs or weaknesses had serious consequences. Today, speech and audio codecs have moved from the firmware space to the software space. In contrast to firmware, software brings flexibility in the form of gradual roll-out and simple upgrade mechanisms. This has brought about a new testing method: beta testing. Products are being used in the real-world while still under development. Beta testing has become the norm in virtually all software development (except ITU codecs..), and it's widely recognized as being more likely to find weaknesses and bugs, at a fraction of the cost. To be clear: software development also involves a lot of in-house testing. Quoting Herve Marcel: > If as soon as one person tries to work on a codec and finds > weaknesses, it is not a very good sign for the stability of the > codec... 1. CELT is still under development. No official (1.0) release has been made. The first thing the web page tells you is that it's in an experimental phase. 2. When ITU's "rigorous testing" finds a weakness in a codec, is that a better sign for the stability? 3. ITU codecs frequently get amended after becoming standardized. How do you feel about that? 4. I personally trust a codec with millions of hours of real-world usage more than a codec with a few hours of lab testing. koen. From koen.vos@skype.net Sat Jul 11 20:03:09 2009 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 4B4913A67FE for ; Sat, 11 Jul 2009 20:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 fShMrfuY5pUA for ; Sat, 11 Jul 2009 20:03:08 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 1B0593A6AB9 for ; Sat, 11 Jul 2009 20:03:07 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9501C2007AB29 for ; Sun, 12 Jul 2009 05:03:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=n884TSa6Q1/i RpgAiw7Uj5x8Bak=; b=udMyjlXU9fIKXxGla9I1nAMp6KCYPq4dJQAnZMA3MGj9 ll2pK1Jz+HDv8yGJyqXFK8pHeMrreM04QBVU/ZJsjIdKGcveQWFPoizyzY/qhbfX xjsvoKYhVc60gD5D89/+F/erJ6BpwRrNefr2wBPdFJ5mt7jv8xmqFah7U8ECNi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=gLOt79Ffyzon2Xok7pxT Zv9CfR3H2v5uJ3p8e9MAox38cifiDMrV3Sca03f4Awyqh5ddlJhElwiFB3P2FYNI DcoNvjAvNDpgki2BU834heKNfbrDTbZKXjIPUO9jNgXzJMDjTEPnT1IIQ/Tsiwcz hEWtOy8x2iHz9LrQonya7Tk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 939772007AB20 for ; Sun, 12 Jul 2009 05:03:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqntlmn1xHUq for ; Sun, 12 Jul 2009 05:03:26 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id D75B42007AB24; Sun, 12 Jul 2009 05:03:26 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 11 Jul 2009 20:03:26 -0700 Message-ID: <20090711200326.20306jfm3voo762m@mail.skype.net> Date: Sat, 11 Jul 2009 20:03:26 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <20090711172630.19485o99spktohx2@mail.skype.net> In-Reply-To: <20090711172630.19485o99spktohx2@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 03:03:09 -0000 Herve, In particular I would like to point out that G.718, an ITU codec for which your employer receives royalties, has already been corrected twice AFTER being standardized less than a year ago: http://www.itu.int/rec/T-REC-G.718/en Perhaps a beta program could have prevented this..? koen. >> If as soon as one person tries to work on a codec and finds >> weaknesses, it is not a very good sign for the stability of the >> codec... > > 1. CELT is still under development. No official (1.0) release has been > made. The first thing the web page tells you is that it's in an > experimental phase. > > 2. When ITU's "rigorous testing" finds a weakness in a codec, is that > a better sign for the stability? > > 3. ITU codecs frequently get amended after becoming standardized. How > do you feel about that? > > 4. I personally trust a codec with millions of hours of real-world usage > more than a codec with a few hours of lab testing. > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From koen.vos@skype.net Sat Jul 11 20:18:19 2009 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 427423A6895 for ; Sat, 11 Jul 2009 20:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 uIVHek1NMtsx for ; Sat, 11 Jul 2009 20:18:18 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 2D00C3A6ACC for ; Sat, 11 Jul 2009 20:18:18 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 459632007AB53 for ; Sun, 12 Jul 2009 05:18:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=rxra0BWPlnwV AAC++WalYtPPEo4=; b=UdUSwvjNgCoN4viGWd7Q1mM6tu64LZncsCwRB3yhxK9q us+Wo3GsYMKsAuoE6w08/lBsr8HMfiIqEHB7dxKlWwxtFCMJ0vXXGRBPgH5MhfJI YOGGwwRMBbpLCfYa+AkrjmWKjMEkDcw4D1p39CfN3m9k8xJRKvYciSbSgUjC9dA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=tB95AcZ7YaBb0Qq6VALd MwjV1iXfwnXcCN8b/UKwUNX1UhBt+PfafSmfcFq4K5p4OX2kXEA6K3K9qKTDAy56 NdehD1s0pzhRJIHCbkZqsBPZFILv5mSQZiGuxV2kqM0uIZHuy3Rvzfk1He1Mctak YgB4pzsDjXcHMzKYqrtBCw4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 441D62007AB4C for ; Sun, 12 Jul 2009 05:18:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYrgQtHiW9g for ; Sun, 12 Jul 2009 05:18:37 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C12462007AB48; Sun, 12 Jul 2009 05:18:37 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 11 Jul 2009 20:18:37 -0700 Message-ID: <20090711201837.17645uhvmeb74bgt@mail.skype.net> Date: Sat, 11 Jul 2009 20:18:37 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <20090711172630.19485o99spktohx2@mail.skype.net> <20090711200326.20306jfm3voo762m@mail.skype.net> In-Reply-To: <20090711200326.20306jfm3voo762m@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 03:18:19 -0000 Let me take that back - G.718 is still in pre-published phase, only a recommendation so far. And clearly not very stable given all the corrections being made. koen. > Herve, > > In particular I would like to point out that G.718, an ITU codec for which > your employer receives royalties, has already been corrected twice AFTER > being standardized less than a year ago: > http://www.itu.int/rec/T-REC-G.718/en > > Perhaps a beta program could have prevented this..? > > koen. > > >>> If as soon as one person tries to work on a codec and finds >>> weaknesses, it is not a very good sign for the stability of the >>> codec... >> >> 1. CELT is still under development. No official (1.0) release has been >> made. The first thing the web page tells you is that it's in an >> experimental phase. >> >> 2. When ITU's "rigorous testing" finds a weakness in a codec, is that >> a better sign for the stability? >> >> 3. ITU codecs frequently get amended after becoming standardized. How >> do you feel about that? >> >> 4. I personally trust a codec with millions of hours of real-world usage >> more than a codec with a few hours of lab testing. >> >> koen. >> _______________________________________________ >> 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 stephen.botzko@gmail.com Sun Jul 12 03:57:59 2009 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 AE79B3A6944 for ; Sun, 12 Jul 2009 03:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 XJMLwJi8SuNV for ; Sun, 12 Jul 2009 03:57:58 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 34C603A68E8 for ; Sun, 12 Jul 2009 03:57:58 -0700 (PDT) Received: by fxm18 with SMTP id 18so1685235fxm.37 for ; Sun, 12 Jul 2009 03:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=krYG63uXw6PplxtHtI6C+CODVfSFu4/UTWv37ZfqnOg=; b=LiOyyKaYKWKk4ke+JNX47FCf99R5CbM6Rsd614bLhlG6bJgz2V4F+HiS98HcRH7jRg 4cfMPpT89KZvYqQa7wNe0pm1+OlA+Jy0JxP/keyHqg9gjtn+SSiRggPQtKOAU2dOL62t Op8aO42uJsg4hIgCOJ3/i/WbmosR291xTUWlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NXIBdVmf3L7SykQH8ZAoAFwWOSps4dmOE+S6UeItwceUUrfwaYlvEims8R2/HSmNMB wm2Ldj01I7RAr3HoTzFR+0XEmW1MXDI65o/zzl4Cea869Le/8TmMx9rKIXcSOAvVh3Fg eldCM30zRAlxoEZHF1ka+MfMn9w9SGnrXVxSg= MIME-Version: 1.0 Received: by 10.103.182.1 with SMTP id j1mr2041554mup.119.1247396305742; Sun, 12 Jul 2009 03:58:25 -0700 (PDT) In-Reply-To: <20090711172630.19485o99spktohx2@mail.skype.net> References: <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <20090711172630.19485o99spktohx2@mail.skype.net> Date: Sun, 12 Jul 2009 06:58:25 -0400 Message-ID: <6e9223710907120358i74c59f31tbab4d15d4809fb9f@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016364d238db2ad27046e801554 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 10:57:59 -0000 --0016364d238db2ad27046e801554 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Perhaps the ITU process could be streamlined and made more efficient. I didn't see anyone arguing that the IETF group would use another SDO's process as-is anyway. With all due respect, I think your arguments really apply to Skype, not to an IETF WG. There is no assurance that the best candidate for the internet codec will be submitted by a group that already has an application with millions of users to test it. Or that the WG itself can guarantee that all viable candidates (or the final candidate) will have that advantage, unless it makes that a requirement for selection. Hopefully you are not arguing for that. Certainly there are lots of internet-connected devices that run firmware, and which are inconvenient to (and not automatic to) upgrade. Infrastructure devices (gateways, conference servers, etc) are one obvious example. And surely the publication of the RFC means that the project is finished, so we are not talking about a never-ending continuous improvement development effort. BTW, I do not see how changes to G.718 software really matter much to this discussion. The fact that the ITU has folks who review/fix the code seems to be a good thing. I don't think those changes had any interoperability impact when used with the initial source version. Even if they did, in your view the IETF WG codec source would be similarly revised. Regards Stephen Botzko Polycom On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos wrote: > Herve, > > I would argue that the ITU-style testing process is expensive and > ineffective. The ITU model stems from a time when codecs were part of > firmware that was rolled out on a large scale. Since firmware is not > easily updated by end-users, it had to work for every user from day one. > Any bugs or weaknesses had serious consequences. > > Today, speech and audio codecs have moved from the firmware space to the > software space. In contrast to firmware, software brings flexibility in > the form of gradual roll-out and simple upgrade mechanisms. This has > brought about a new testing method: beta testing. Products are being used > in the real-world while still under development. Beta testing has become > the norm in virtually all software development (except ITU codecs..), and > it's widely recognized as being more likely to find weaknesses and bugs, > at a fraction of the cost. > > To be clear: software development also involves a lot of in-house testing. > > > Quoting Herve Marcel: > >> If as soon as one person tries to work on a codec and finds weaknesses, it >> is not a very good sign for the stability of the codec... >> > > 1. CELT is still under development. No official (1.0) release has been > made. The first thing the web page tells you is that it's in an > experimental phase. > > 2. When ITU's "rigorous testing" finds a weakness in a codec, is that > a better sign for the stability? > > 3. ITU codecs frequently get amended after becoming standardized. How > do you feel about that? > > 4. I personally trust a codec with millions of hours of real-world usage > more than a codec with a few hours of lab testing. > > koen. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016364d238db2ad27046e801554 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps the ITU process could be streamlined and made more efficient. I did= n't see anyone arguing that the IETF group would use another SDO's = process as-is anyway.

With all due respect, I think your arguments r= eally apply to Skype, not to an IETF WG.=A0 There is no assurance that the = best candidate for the internet codec will be submitted by a group that alr= eady has an application with millions of users to test it.=A0 Or that the W= G itself can guarantee that all viable candidates (or the final candidate) = will have that advantage, unless it makes that a requirement for selection.= =A0 Hopefully you are not arguing for that.

Certainly there are lots of internet-connected devices that run firmwar= e, and which are inconvenient=A0 to (and not automatic to) upgrade.=A0 Infr= astructure devices (gateways, conference servers, etc) are one obvious exam= ple.

And surely the publication of the RFC means that the project is finishe= d, so we are not talking about a never-ending continuous improvement develo= pment effort.

BTW, I do not see how changes to G.718 software really= matter much to this discussion.=A0 The fact that the ITU has folks who rev= iew/fix the code seems to be a good thing.=A0 I don't think those chang= es had any interoperability impact when used with the initial source versio= n.=A0 Even if they did, in your view the IETF WG codec source would be simi= larly revised.

Regards
Stephen Botzko
Polycom


On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos <koen.vos@skype.net> wrote:
=
Herve,

I would argue that the ITU-style testing process is expensive and
ineffective. The ITU model stems from a time when codecs were part of
firmware that was rolled out on a large scale. Since firmware is not
easily updated by end-users, it had to work for every user from day one. Any bugs or weaknesses had serious consequences.

Today, speech and audio codecs have moved from the firmware space to the software space. In contrast to firmware, software brings flexibility in
the form of gradual roll-out and simple upgrade mechanisms. This has
brought about a new testing method: beta testing. Products are being used in the real-world while still under development. Beta testing has become the norm in virtually all software development (except ITU codecs..), and it's widely recognized as being more likely to find weaknesses and bugs= ,
at a fraction of the cost.

To be clear: software development also involves a lot of in-house testing.<= div class=3D"im">


Quoting Herve Marcel:
If as soon as one person tries to work on a codec and finds weaknesses, it = is not a very good sign for the stability of the codec...

1. CELT is still under development. No official (1.0) release has been
made. The first thing the web page tells you is that it's in an
experimental phase.

2. When ITU's "rigorous testing" finds a weakness in a codec,= is that
a better sign for the stability?

3. ITU codecs frequently get amended after becoming standardized. How
do you feel about that?

4. I personally trust a codec with millions of hours of real-world usage more than a codec with a few hours of lab testing.

koen.

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

--0016364d238db2ad27046e801554-- From koen.vos@skype.net Sun Jul 12 15:10:08 2009 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 1788C3A68AE for ; Sun, 12 Jul 2009 15:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 o1cpoz7C-BRD for ; Sun, 12 Jul 2009 15:10:06 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 5ADFF3A657C for ; Sun, 12 Jul 2009 15:10:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 787392007452B; Mon, 13 Jul 2009 00:10:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=oGsinNGIfASc XiDtsJiDbwF6bJw=; b=mgs67NQtECwRMoB5sRzmrjjG+QsvxCX3kmp0Uqz+APRR DcFIKG7S3b0BXbllySYoVoLgsY1/7nvgORHjUU3QbCEqiylNaVc7XjONln0EDvqY U2OkDe4nd8L+NFeLQcZ9+8FMeb4Fym/6nERhNCzOIXnD0sBXDhxTPfd5pniptVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=RWnwspCwmfifJB2sJThK P16kQUxXkMxQlq4B1JyAACwcCBlUrUQnLLfIYtecjG5nVbmj7vpY6xREdY0v/Ov6 ociXL4G4CSlLzXiWIBaH/vLxQfn7uyLsTiKNNfZhtcMoY9etHFAt8X41W88vxaqV bwltpay/Cfa358vdzveXIvM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 76BE52007456E; Mon, 13 Jul 2009 00:10:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq+eS0EbTsbX; Mon, 13 Jul 2009 00:10:25 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 9801420075BE4; Mon, 13 Jul 2009 00:10:25 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sun, 12 Jul 2009 15:10:25 -0700 Message-ID: <20090712151025.10284e9e5ipw9w7l@mail.skype.net> Date: Sun, 12 Jul 2009 15:10:25 -0700 From: Koen Vos To: stephen botzko References: <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <20090711172630.19485o99spktohx2@mail.skype.net> <6e9223710907120358i74c59f31tbab4d15d4809fb9f@mail.gmail.com> In-Reply-To: <6e9223710907120358i74c59f31tbab4d15d4809fb9f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 22:10:08 -0000 A beta testing phase is perhaps not simple to incorporate in the IETF process, but it's worth considering in my mind. It has worked for both CELT and SILK. Agree that it should not be a requirement for proposals. Even when a codec ends up as firmware, my argument about the benefit of beta testing holds if that codec started its life as software. koen Quoting stephen botzko : > Perhaps the ITU process could be streamlined and made more efficient. I > didn't see anyone arguing that the IETF group would use another SDO's > process as-is anyway. > > With all due respect, I think your arguments really apply to Skype, not to > an IETF WG. There is no assurance that the best candidate for the internet > codec will be submitted by a group that already has an application with > millions of users to test it. Or that the WG itself can guarantee that all > viable candidates (or the final candidate) will have that advantage, unless > it makes that a requirement for selection. Hopefully you are not arguing > for that. > > Certainly there are lots of internet-connected devices that run firmware, > and which are inconvenient to (and not automatic to) upgrade. > Infrastructure devices (gateways, conference servers, etc) are one obvious > example. > > And surely the publication of the RFC means that the project is finished, so > we are not talking about a never-ending continuous improvement development > effort. > > BTW, I do not see how changes to G.718 software really matter much to this > discussion. The fact that the ITU has folks who review/fix the code seems > to be a good thing. I don't think those changes had any interoperability > impact when used with the initial source version. Even if they did, in your > view the IETF WG codec source would be similarly revised. > > Regards > Stephen Botzko > Polycom > > > On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos wrote: > >> Herve, >> >> I would argue that the ITU-style testing process is expensive and >> ineffective. The ITU model stems from a time when codecs were part of >> firmware that was rolled out on a large scale. Since firmware is not >> easily updated by end-users, it had to work for every user from day one. >> Any bugs or weaknesses had serious consequences. >> >> Today, speech and audio codecs have moved from the firmware space to the >> software space. In contrast to firmware, software brings flexibility in >> the form of gradual roll-out and simple upgrade mechanisms. This has >> brought about a new testing method: beta testing. Products are being used >> in the real-world while still under development. Beta testing has become >> the norm in virtually all software development (except ITU codecs..), and >> it's widely recognized as being more likely to find weaknesses and bugs, >> at a fraction of the cost. >> >> To be clear: software development also involves a lot of in-house testing. >> >> >> Quoting Herve Marcel: >> >>> If as soon as one person tries to work on a codec and finds weaknesses, it >>> is not a very good sign for the stability of the codec... >>> >> >> 1. CELT is still under development. No official (1.0) release has been >> made. The first thing the web page tells you is that it's in an >> experimental phase. >> >> 2. When ITU's "rigorous testing" finds a weakness in a codec, is that >> a better sign for the stability? >> >> 3. ITU codecs frequently get amended after becoming standardized. How >> do you feel about that? >> >> 4. I personally trust a codec with millions of hours of real-world usage >> more than a codec with a few hours of lab testing. >> >> koen. >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From stephen.botzko@gmail.com Mon Jul 13 06:39:35 2009 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 A7F6828C30D for ; Mon, 13 Jul 2009 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 eKS4TaYWCb5l for ; Mon, 13 Jul 2009 06:39:34 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 2B2E83A6D44 for ; Mon, 13 Jul 2009 06:39:29 -0700 (PDT) Received: by bwz28 with SMTP id 28so157193bwz.37 for ; Mon, 13 Jul 2009 06:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IC3Xyd3pdvJf0bIaCB4V4ghmu1MDUI1Roy3V3mvT1CE=; b=X/mUq3yrawR3bT/65ofUH9xCAJ3t8h6g2Y9aqqluoAXtTSR9+wxb1vst4JL3ESaeO6 UevH0eUWB+KuDLFcpPhK/zUIxT7RPJH57IDqeZ/hyx8IupVPZ34BbnfKRWHceus6L3W9 Qwd8ylGx7CdOfKwE3WquJt7ZB12VXu5uiVZms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rX21JhokLEyrOqO9wjYHjNywdJtk+7vYTKgQFcvDFpernyQcCqpRqZxTXysZwxHuqx 68A1zQhiO0vppw7udIqPO6RAxYnaHCDdGPMEVsv4G8IPKSzeQxwlMoCIdHo9RsfW8Mf2 oXufI9qTVxeuTxcZr/5YXl0pwxWQMedNot0NA= MIME-Version: 1.0 Received: by 10.103.2.14 with SMTP id e14mr2674936mui.41.1247492397898; Mon, 13 Jul 2009 06:39:57 -0700 (PDT) In-Reply-To: <20090712151025.10284e9e5ipw9w7l@mail.skype.net> References: <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4a57ab1e.0af6660a.2ef5.ffffd7e6@mx.google.com> <20090710171122.11627kc26xuafhka@mail.skype.net> <001f01ca01f4$c5d74d30$5185e790$@de> <20090711172630.19485o99spktohx2@mail.skype.net> <6e9223710907120358i74c59f31tbab4d15d4809fb9f@mail.gmail.com> <20090712151025.10284e9e5ipw9w7l@mail.skype.net> Date: Mon, 13 Jul 2009 09:39:56 -0400 Message-ID: <6e9223710907130639t44c93439sd51082e4bca15c25@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016e65a0f643cb021046e96757e Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:39:35 -0000 --0016e65a0f643cb021046e96757e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Koen I see some merit to a beta testing phase, as long as it does not replace codec characterization testing and is not used to evaluate proposals. It could certainly expose problems that were not caught in previous phases, and provides some assurance that the codec works as intended "in the wild". Perhaps I don't understand where you were trying to go with your software/firmware comments. I suspect it doesn't really matter, though feel free to clarify it (on or off the list) if you think there is something important at stake that I'm not getting. Stephen Botzko Polycom On Sun, Jul 12, 2009 at 6:10 PM, Koen Vos wrote: > A beta testing phase is perhaps not simple to incorporate in the IETF > process, but it's worth considering in my mind. It has worked for both CELT > and SILK. Agree that it should not be a requirement for proposals.Hi > > Even when a codec ends up as firmware, my argument about the benefit of > beta testing holds if that codec started its life as software. > > koen > > > Quoting stephen botzko : > > Perhaps the ITU process could be streamlined and made more efficient. I >> didn't see anyone arguing that the IETF group would use another SDO's >> process as-is anyway. >> >> With all due respect, I think your arguments really apply to Skype, not to >> an IETF WG. There is no assurance that the best candidate for the >> internet >> codec will be submitted by a group that already has an application with >> millions of users to test it. Or that the WG itself can guarantee that >> all >> viable candidates (or the final candidate) will have that advantage, >> unless >> it makes that a requirement for selection. Hopefully you are not arguing >> for that. >> >> Certainly there are lots of internet-connected devices that run firmware, >> and which are inconvenient to (and not automatic to) upgrade. >> Infrastructure devices (gateways, conference servers, etc) are one obvious >> example. >> >> And surely the publication of the RFC means that the project is finished, >> so >> we are not talking about a never-ending continuous improvement development >> effort. >> >> BTW, I do not see how changes to G.718 software really matter much to this >> discussion. The fact that the ITU has folks who review/fix the code seems >> to be a good thing. I don't think those changes had any interoperability >> impact when used with the initial source version. Even if they did, in >> your >> view the IETF WG codec source would be similarly revised. >> >> Regards >> Stephen Botzko >> Polycom >> >> >> On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos wrote: >> >> Herve, >>> >>> I would argue that the ITU-style testing process is expensive and >>> ineffective. The ITU model stems from a time when codecs were part of >>> firmware that was rolled out on a large scale. Since firmware is not >>> easily updated by end-users, it had to work for every user from day one. >>> Any bugs or weaknesses had serious consequences. >>> >>> Today, speech and audio codecs have moved from the firmware space to the >>> software space. In contrast to firmware, software brings flexibility in >>> the form of gradual roll-out and simple upgrade mechanisms. This has >>> brought about a new testing method: beta testing. Products are being used >>> in the real-world while still under development. Beta testing has become >>> the norm in virtually all software development (except ITU codecs..), and >>> it's widely recognized as being more likely to find weaknesses and bugs, >>> at a fraction of the cost. >>> >>> To be clear: software development also involves a lot of in-house >>> testing. >>> >>> >>> Quoting Herve Marcel: >>> >>> If as soon as one person tries to work on a codec and finds weaknesses, >>>> it >>>> is not a very good sign for the stability of the codec... >>>> >>>> >>> 1. CELT is still under development. No official (1.0) release has been >>> made. The first thing the web page tells you is that it's in an >>> experimental phase. >>> >>> 2. When ITU's "rigorous testing" finds a weakness in a codec, is that >>> a better sign for the stability? >>> >>> 3. ITU codecs frequently get amended after becoming standardized. How >>> do you feel about that? >>> >>> 4. I personally trust a codec with millions of hours of real-world usage >>> more than a codec with a few hours of lab testing. >>> >>> koen. >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >> > > --0016e65a0f643cb021046e96757e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Koen

I see some merit to a beta testing phase, as long as it does= not replace codec characterization testing and is not used to evaluate pro= posals.=A0 It could certainly expose problems that were not caught in previ= ous phases, and provides some assurance that the codec works as intended &q= uot;in the wild".

Perhaps I don't understand where you were trying to go with your so= ftware/firmware comments.=A0 I suspect it doesn't really matter, though= feel free to clarify it (on or off the list) if you think there is somethi= ng important at stake that I'm not getting.

Stephen Botzko
Polycom

On Sun, Jul= 12, 2009 at 6:10 PM, Koen Vos <koen.vos@skype.net> wrote:
A beta testing phase is perhaps not simple to incorporate in the IETF proce= ss, but it's worth considering in my mind. =A0It has worked for both CE= LT and SILK. =A0Agree that it should not be a requirement for proposals.Hi =

Even when a codec ends up as firmware, my argument about the benefit of bet= a testing holds if that codec started its life as software.


koen


Quoting stephen botzko <stephen.botzko@gmail.com>:

Perhaps the ITU process could be streamlined and made more efficient. I
didn't see anyone arguing that the IETF group would use another SDO'= ;s
process as-is anyway.

With all due respect, I think your arguments really apply to Skype, not to<= br> an IETF WG. =A0There is no assurance that the best candidate for the intern= et
codec will be submitted by a group that already has an application with
millions of users to test it. =A0Or that the WG itself can guarantee that a= ll
viable candidates (or the final candidate) will have that advantage, unless=
it makes that a requirement for selection. =A0Hopefully you are not arguing=
for that.

Certainly there are lots of internet-connected devices that run firmware, and which are inconvenient =A0to (and not automatic to) upgrade.
Infrastructure devices (gateways, conference servers, etc) are one obvious<= br> example.

And surely the publication of the RFC means that the project is finished, s= o
we are not talking about a never-ending continuous improvement development<= br> effort.

BTW, I do not see how changes to G.718 software really matter much to this<= br> discussion. =A0The fact that the ITU has folks who review/fix the code seem= s
to be a good thing. =A0I don't think those changes had any interoperabi= lity
impact when used with the initial source version. =A0Even if they did, in y= our
view the IETF WG codec source would be similarly revised.

Regards
Stephen Botzko
Polycom


On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos <koen.vos@skype.net> wrote:

Herve,

I would argue that the ITU-style testing process is expensive and
ineffective. The ITU model stems from a time when codecs were part of
firmware that was rolled out on a large scale. Since firmware is not
easily updated by end-users, it had to work for every user from day one. Any bugs or weaknesses had serious consequences.

Today, speech and audio codecs have moved from the firmware space to the software space. In contrast to firmware, software brings flexibility in
the form of gradual roll-out and simple upgrade mechanisms. This has
brought about a new testing method: beta testing. Products are being used in the real-world while still under development. Beta testing has become the norm in virtually all software development (except ITU codecs..), and it's widely recognized as being more likely to find weaknesses and bugs= ,
at a fraction of the cost.

To be clear: software development also involves a lot of in-house testing.<= br>

Quoting Herve Marcel:

If as soon as one person tries to work on a codec and finds weaknesses, it<= br> is not a very good sign for the stability of the codec...


1. CELT is still under development. No official (1.0) release has been
made. The first thing the web page tells you is that it's in an
experimental phase.

2. When ITU's "rigorous testing" finds a weakness in a codec,= is that
a better sign for the stability?

3. ITU codecs frequently get amended after becoming standardized. How
do you feel about that?

4. I personally trust a codec with millions of hours of real-world usage more than a codec with a few hours of lab testing.

koen.

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





--0016e65a0f643cb021046e96757e-- From fluffy@cisco.com Mon Jul 13 14:22:44 2009 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 151C328C5F2 for ; Mon, 13 Jul 2009 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 VKds9bj7iCVl for ; Mon, 13 Jul 2009 14:22:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 33EA628C491 for ; Mon, 13 Jul 2009 14:22:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAtDW0qrR7O6/2dsb2JhbAC4RIgjjw4FhAk X-IronPort-AV: E=Sophos;i="4.42,392,1243814400"; d="scan'208";a="345904155" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2009 21:23:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6DLNEU9017164; Mon, 13 Jul 2009 14:23:14 -0700 Received: from dhcp-171-68-21-42.cisco.com (dhcp-171-68-21-42.cisco.com [171.68.21.42]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6DLNEgN027680; Mon, 13 Jul 2009 21:23:14 GMT Message-Id: From: Cullen Jennings To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 14:23:14 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=404; t=1247520194; x=1248384194; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Welcome=20to=20Greg=20 |Sender:=20; bh=j2XM3anF++pBH8YQnOjegXhDAZ2fa78/ss6kzpzzfqE=; b=dfiHCYvQ6B17ZPhMHvaBFLdPrQyRdDqdnXXG79VNelKHCB7Qq733/Iv72E mPC5IS8/V53bh7n4Ezvw2usTTQdCdQQu9oYjrKt3lhTS9UkM4DeVBqabza04 A5OD8zs81k; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Gregory Lebovitz Subject: [codec] Welcome to Greg X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:22:44 -0000 Greg Lebovitz has kindly volunteered to be the IAB shepherd for this BOF. Greg is on the IAB and has plenty of experience in "complicated" topics. I also believe that he brings a very neutral view to the topic of codecs. Just wanted to let folks know that Greg would be helping and tell him thanks. Cullen PS. Greg, I assume you will be sporting a large grey beard by IETF 75 :-) From fluffy@cisco.com Tue Jul 14 09:38:29 2009 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 51C4E3A6EF0 for ; Tue, 14 Jul 2009 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 JKEaV-KaCgfh for ; Tue, 14 Jul 2009 09:38:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DD78E3A6CD7 for ; Tue, 14 Jul 2009 09:38:28 -0700 (PDT) X-Files: None : None X-IronPort-AV: E=Sophos;i="4.42,398,1243814400"; d="doc'32?scan'32,208,32,217?xls'32,208,32,217,32?pdf'32,208,32,217,32"; a="185918620" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2009 16:38:05 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6EGc5Xq027110; Tue, 14 Jul 2009 09:38:05 -0700 Received: from dhcp-171-68-21-42.cisco.com (dhcp-171-68-21-42.cisco.com [171.68.21.42]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n6EGc58s001771; Tue, 14 Jul 2009 16:38:05 GMT Message-Id: <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> From: Cullen Jennings To: codec@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-7-846830943 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 09:38:06 -0700 References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=305637; t=1247589485; x=1248453485; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20COM=2016-LS=2071=20-=20Outgoing=20LS=2 0from=20ITU-T=20WP3=20meeting=20(10=20July=202009) |Sender:=20; bh=ukTO2EPtZuRHDbz/PAhxN42ayKljb+5h1UWxkgxmRrM=; b=UPFYq4klbYxoa9h1qNzICQjGofieKqWOvumiYTCkzm1dxCr2kgBVPx3jhz USElS4+/c7SJWIxOZiHXlisBientol6k9I6Lvtj9Rso0v7YhoLpBwNZyUMRY jnHJIyg7mf; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Gregory Lebovitz Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 16:38:29 -0000 --Apple-Mail-7-846830943 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I just received this Liaison from the ITU. I wanted to forward it on =20 so people could see it ASAP. If there are problems with attachments, =20 let me know and I will get them posted to a site where people can get =20= them. Cullen Begin forwarded message: > From: > Date: July 14, 2009 7:51:01 AM PDT > To: , , > Cc: , > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July =20= > 2009) > > > > Kindly find attached the Liaison Statement COM16 - LS 71 on =20 > "information on ITU-T Speech and audio coding standardisation" =20 > addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting =20 > (10 July 2009). > > Please take note that we are sending herewith the word version as =20 > well as the pdf version of the LS. In addition, there is an =20 > attachment, which is in excel. Since it is quite complex with =20 > different sheets, we preferred to keep the excel file in the =20 > original version. > > > > <> <> < Database-V20081003.xls>> > > > Best regards, > Rosa Angeles-Le=F3n de Vivero > Assistant for ITU-T Study Group 16 > ITU - Telecommunication Standardization Bureau (TSB) > SG 16 e-mail: tsbsg16@itu.int > Tel. 41-22 730 5445 > Fax 41-22 730 5853 > > --Apple-Mail-7-846830943 Content-Type: multipart/mixed; boundary=Apple-Mail-8-846830944 --Apple-Mail-8-846830944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I just received = this Liaison from the ITU. I wanted to&= nbsp;forward it on so people could see = it ASAP. If there are problems with attachments, let me know = and I will get them posted to a site where people can get = them. 

Cullen


Begin = forwarded message:

From: = <tsbsg16@itu.int>
Date: = July 14, 2009 7:51:01 AM PDT
To: <housley@vigilsec.com>, = <fluffy@cisco.com>, <statements@ietf.org>
Subject: COM 16-LS 71 - Outgoing = LS from ITU-T WP3 meeting (10 July 2009)



Kindly find attached the Liaison Statement = COM16 - LS 71 on "information on ITU-T Speech and audio coding = standardisation" addressed to IESG and IETF-RAI agreed at the ITU-T = WP2/16 meeting (10 July 2009).

Please take note that we = are sending herewith the word version as well as the pdf version of the = LS.  In addition, there is an attachment, which is in excel.  = Since it is quite complex with different sheets, we preferred to keep = the excel file in the original version.


=

    <<ls071-16.doc>> = <<ls071-16.pdf>> <<ls071_Att.1_Copy of = MCSD-Database-V20081003.xls>>

=

Best = regards,
Rosa Angeles-Le=F3n de = Vivero
Assistant for ITU-T Study = Group 16
ITU - Telecommunication = Standardization Bureau (TSB)
SG 16 = e-mail: tsbsg16@itu.int
Tel.  41-22 730 5445 =
Fax 41-22 730 5853


=
= --Apple-Mail-8-846830944 Content-Disposition: attachment; filename=ls071-16.doc Content-Type: application/msword; x-unix-mode=0666; name="ls071-16.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAdAAAAAAAAAAA EAAAdgAAAAEAAAD+////AAAAAHMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJ2AJBAAA+BK/AAAAAAAAMAAAAAAABgAAwycAAA4AYmpiauvI68gAAAAAAAAAAAAAAAAAAAAA AAAJBBYAO1wAAImiAACJogAA9h0AAAAAAADMAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAABIIAAAAAAAAEggAABII AAAAAAAAEggAAAAAAAASCAAAAAAAABIIAAAAAAAAEggAABQAAAAAAAAAAAAAACYIAAAAAAAAtiQA AAAAAAC2JAAAAAAAALYkAAA4AAAA7iQAACwAAAAaJQAApAAAACYIAAAAAAAADDoAAAYCAADKJQAA OgAAAAQmAAAWAAAAGiYAAAAAAAAaJgAAAAAAABomAAAAAAAA+SYAABgBAAARKAAAdAAAAIUoAAA8 AAAAizkAAAIAAACNOQAAAAAAAI05AAAAAAAAjTkAAAAAAACNOQAAAAAAAI05AAAAAAAAjTkAACQA AAASPAAAaAIAAHo+AAAAAQAAsTkAABUAAAAAAAAAAAAAAAAAAAAAAAAAEggAAAAAAADoKwAAAAAA AAAAAAAAAAAAAAAAAAAAAAD1JgAABAAAAPkmAAAAAAAA6CsAAAAAAADoKwAAAAAAALE5AAAAAAAA AAAAAAAAAAASCAAAAAAAABIIAAAAAAAAGiYAAAAAAAAAAAAAAAAAABomAADbAAAAxjkAABYAAAA+ LgAAAAAAAD4uAAAAAAAAPi4AAAAAAADoKwAAiAAAABIIAAAAAAAAGiYAAAAAAAASCAAAAAAAABom AAAAAAAAizkAAAAAAAAAAAAAAAAAAD4uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA6CsAAAAAAACLOQAAAAAAAAAAAAAAAAAAPi4AAAAAAAA+LgAA VgAAAOM1AABAAAAAEggAAAAAAAASCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApzYAAAAAAAAaJgAAAAAAAL4lAAAMAAAAoOs8EmkE ygEAAAAAAAAAALYkAAAAAAAAcCwAAGQAAAAjNgAADAAAAAAAAAAAAAAAFzcAAHQCAADcOQAAMAAA AAw6AAAAAAAALzYAAHgAAAB6PwAAAAAAANQsAAASAQAAej8AABgAAACnNgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHo/AAAAAAAAAAAAAAAAAAASCAAAAAAAAKc2AABwAAAAwSgAAK4AAABvKQAAfAAAAD4u AAAAAAAA6ykAAGQAAABPKgAAmQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwSgA AAAAAADBKAAAAAAAAMEoAAAAAAAAsTkAAAAAAACxOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA5i0AAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMEoAAAA AAAAwSgAAAAAAADBKAAAAAAAAAw6AAAAAAAA6CsAAAAAAADoKwAAAAAAAOgrAAAAAAAA6CsAAAAA AAAAAAAAAAAAACYIAABEAAAAaggAAIQAAADuCAAAZA4AAFIXAABkDQAAJggAAAAAAABqCAAAAAAA AO4IAAAAAAAAUhcAAAAAAAAmCAAAAAAAACYIAAAAAAAAJggAAAAAAAASCAAAAAAAABIIAAAAAAAA EggAAAAAAAASCAAAAAAAABIIAAAAAAAAEggAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHSU5U RVJOQVRJT05BTCBURUxFQ09NTVVOSUNBVElPTiBVTklPTgdDT00gMTYgliBMUyA3MSCWIEUHBwdU RUxFQ09NTVVOSUNBVElPTgtTVEFOREFSRElaQVRJT04gU0VDVE9SDVNUVURZIFBFUklPRCAyMDA5 LTIwMTIHBwcHB0VuZ2xpc2ggb25seQ1PcmlnaW5hbDogRW5nbGlzaAcHUXVlc3Rpb24ocyk6Bzgs IDksIDEwLzE2B0dlbmV2YSwgMTAgSnVseSAyMDA5BwdMSUFJU09OIFNUQVRFTUVOVAcHU291cmNl OgdJVFUtVCBTRyAxNiCWIFE4LCA5LCAxMC8xNgcHVGl0bGU6B0xTIHRvIElFU0cgYW5kIElFVEYt UkFJIG9uIGluZm9ybWF0aW9uIG9uIElUVS1UIFNwZWVjaCBhbmQgYXVkaW8gY29kaW5nIHN0YW5k YXJkaXNhdGlvbgcHTElBSVNPTiBTVEFURU1FTlQHB0ZvciBhY3Rpb24gdG86By0HB0ZvciBjb21t ZW50IHRvOgctBwdGb3IgaW5mb3JtYXRpb24gdG86B0lFU0csIElFVEYtUkFJBwdBcHByb3ZhbDoH SVRVLVQgV1AgMy8xNiBtZWV0aW5nIChHZW5ldmEsIDEwIEp1bHkgMjAwOSkHB0RlYWRsaW5lOgdO L0EHB0NvbnRhY3Q6B01zIENsYXVkZSBMYW1ibGluC0ZyYW5jZSBUZWxlY29tIE9yYW5nZQtGcmFu Y2UgB1RlbDogCSszMyAyIDk2IDA1IDEzIDAzC0ZheDogCSszMyAyIDk2IDA1IDM1IDMwC0VtYWls OgkTIEhZUEVSTElOSyAibWFpbHRvOmNsYXVkZS5sYW1ibGluQG9yYW5nZS1mdGdyb3VwLmNvbSIg ARRjbGF1ZGUubGFtYmxpbkBvcmFuZ2UtZnRncm91cC5jb20VBwcHB0ludHJvZHVjdGlvbg1JdCBo YXMgYmVlbiBicm91Z2h0IHRvIG91ciBhdHRlbnRpb24gdGhhdCB3aXRoaW4gSUVURiwgdGhlIGNy ZWF0aW9uIG9mIGEgbmV3IElFVEYgd29ya2luZyBncm91cCB0byBkZWZpbmUgYSB3aWRlYmFuZCBh dWRpbyBjb2RlYyBzcGVjaWZpY2FsbHkgZm9yIHVzZSB3aXRoIHRoZSBJbnRlcm5ldCBoYXMgYmVl biByZWNlbnRseSBwcm9wb3NlZC4gV2Ugb2JzZXJ2ZWQgdGhhdCB0aGUgaW5pdGlhbCBwcm9wb3Nh bCB3YXMgZm9sbG93ZWQgYnkgZGlzY3Vzc2lvbnMgb24gdGhlIElFVEYgZW1haWwgcmVmbGVjdG9y IBMgSFlQRVJMSU5LICJtYWlsdG86Y29kZWNAaWV0Zi5vcmciIAEUY29kZWNAaWV0Zi5vcmcVIGFu ZCB0aGF0IGR1cmluZyB0aGVzZSBkaXNjdXNzaW9ucywgcmVmZXJlbmNlcyB0byBJVFUtVCBzcGVl Y2ggYW5kIGF1ZGlvIGNvZGluZyB3b3JrIHdlcmUgb2Z0ZW4gbWFkZS4gDURlc3BpdGUgdGhlIGlu dGVydmVudGlvbiBvZiBzb21lIGluZGl2aWR1YWxzIGZhbWlsaWFyIHdpdGggSVRVLVQgc3RhbmRh cmRpc2F0aW9uIHdvcmssIHdlIHJlZ3JldHRhYmx5IG9ic2VydmUgdGhhdCB0aGVyZSBhcmUgc3Rp bGwgc2V2ZXJhbCBtaXNjb25jZXB0aW9ucyBhbmQgb3V0LW9mLWRhdGUgdW5kZXJzdGFuZGluZyBv ZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgc3BlZWNoIGFuZCBhdWRpbyBjb2Rpbmcgd29yayBp biBJVFUtVC4gV2Ugc2VlIGFzIHBhcmFtb3VudCB0aGF0IGFueSBkZWNpc2lvbnMgdG8gYmUgdGFr ZW4gaW4gdGhlIHVwY29taW5nIElFVEYgbWVldGluZyBiZSB0YWtlbiBvbiBhIHNvdW5kIGJhc2lz LCB0aGVyZWZvcmUgSVRVLVQgV1AzLzE2IHdvdWxkIGxpa2UgdG8gb2ZmZXIgdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbiBvbiBJVFUtVCBzcGVlY2ggYW5kIGF1ZGlvIGNvZGVycyBhbmQgaXRzIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBpbiBvcmRlciB0byBoZWxwIGFsbGF5IHNvbWUgb2YgdGhl IG9ic2VydmVkIG1pc2NvbmNlcHRpb25zLg1TcGVlY2ggYW5kIEF1ZGlvIENvZGluZyBTdGFuZGFy ZHMNVGhlIElUVS1UIGF1ZGlvL3NwZWVjaCBjb2RlY3MgcG9ydGZvbGlvIChzZWUgdGFibGUgYmVs b3cpIGlzIHF1aXRlIHNpZ25pZmljYW50IGNvdmVyaW5nIGEgd2lkZSByYW5nZSBvZiBhdWRpbyBi YW5kd2lkdGhzIGFuZCBiaXQgcmF0ZXMsIG9mZmVyaW5nIGRpZmZlcmVudCB0cmFkZS1vZmZzIHRv IGFkZHJlc3MgdmFyaW91cyBhcHBsaWNhdGlvbnMgd2l0aCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRz IChvbiBxdWFsaXR5LCBiaXQgcmF0ZXMsIGNvbXBsZXhpdHksIHJvYnVzdG5lc3MsIGRlbGF5KS4N QXVkaW8gQmFuZHdpZHRoIFtrSHpdB1NhbXBsaW5nIGZyZXF1ZW5jeSBbSHpdB0JpdCByYXRlcyBb a2JpdC9zXQdJVFUtVCBHLjd4eC1zZXJpZXMHBzMwMC0zNDAwIChuYXJyb3diYW5kKQc4MDAwBzUu MyAoIDgwB0cuNzExLCBHLjcyNiwgRy43MjcsIEcuNzI4LCBHLjcyOSwgRy43MjMuMSwgRy43Mjku MSwgRy43MTEuMSwgRy43MTgHBzUwLTcwMDAgKHdpZGViYW5kKQcxNjAwMAc2LjYgKCA5NgdHLjcy MiwgRy43MjIuMSwgRy43MjIuMiwgRy43MjkuMSwgRy43MTEuMSwgRy43MTgHBzUwLTE0MDAwIChz dXBlcndpZGViYW5kKQczMjAwMAcyNCAoIDQ4B0cuNzIyLjFDBwcyMC0yMDAwMCAoZnVsbGJhbmQp BzQ4MDAwBzMyICggMTI4B0cuNzE5BwdDb252ZXJzYXRpb25hbCBhcHBsaWNhdGlvbnMgYXJlIHRo ZSBwcmltYXJ5IGFwcGxpY2F0aW9ucyBhbmQgdGhlcmUgaGFzIGJlZW4gYW4gZXZvbHV0aW9uIGZy b20gY2lyY3VpdC1zd2l0Y2hlZCB2b2ljZSBhcHBsaWNhdGlvbnMgKGUuZy4gUFNUTiBhbmQgY2ly Y3VpdCBtdWx0aXBsaWNhdGlvbiBlcXVpcG1lbnQpIHRvIHBhY2tldC1iYXNlZCBtdWx0aW1lZGlh IChub3RhYmx5IElQKS4gDUlUVS1UIGNvZGVycyBhcmUgZXh0ZW5zaXZlbHkgZGVwbG95ZWQgYW5k IHRoZWlyIG1vZGVybiBhcHBsaWNhdGlvbnMgZ28gYmV5b25kIHRoZSBjb25zdHJhaW50cyBmb3Ig d2hpY2ggdGhlIGNvZGVjcyB3ZXJlIGluaXRpYWxseSB0YXJnZXRlZC4gVGhlcmVmb3JlLCBJVFUt VCBoYXMgZXh0ZW5kZWQgdGhlc2UgY29kZXJzIHdpdGggbmV3IGZlYXR1cmVzIHRvIHByb3ZpZGUg cXVpY2sgcmVzcG9uc2VzIHRvIGN1c3RvbWVyIGRlbWFuZHMgYW5kIHRvIGNvcGUgd2l0aCBuZXcg Y29uc3RyYWludHMgb2YgdGhvc2UgbW9kZXJuIGFwcGxpY2F0aW9ucy4gRm9yIGluc3RhbmNlLCBB cHBlbmRpY2VzIHRvIEcuNzExIGFuZCBHLjcyMiCWIGNvZGVycyBpbml0aWFsbHkgZGVzaWduZWQg Zm9yIFBTVE4gYW5kIElTRE4sIHJlc3BlY3RpdmVseSwgcHJvdmlkZSBQYWNrZXQgTG9zcyBDb25j ZWFsbWVudCAoUExDKSBwcm9jZWR1cmVzIHRvIGNvcGUgd2l0aCBwYWNrZXQgbG9zc2VzIHRoYXQg Y2FuIG9jY3VyIGR1cmluZyB0cmFuc21pc3Npb24gb3ZlciBJUCBhbmQgb3RoZXIgcGFja2V0IG5l dHdvcmtzLiAgT3RoZXIgZnVuY3Rpb25hbGl0aWVzIGhhdmUgYmVlbiBhbmQgYXJlIGJlaW5nIGRl dmVsb3BlZCBzdWNoIGFzIHdpZGVyIGF1ZGlvIGJhbmR3aWR0aCBhbmQgc3RlcmVvIHJlbmRlcmlu ZyBjYXBhYmlsaXR5LiANQXMgdGhlIGNvbGxlY3Rpb24gb2Ygc3BlZWNoIGFuZCBhdWRpbyBjb2Rp bmcgc3RhbmRhcmRzIJYgZnJvbSBJVFUgYW5kIG90aGVyIHN0YW5kYXJkcyBkZXZlbG9wbWVudCBv cmdhbml6YXRpb25zIChTRE9zKSCWIGlzIGNvbnNpZGVyYWJsZSwgYmVmb3JlIGxhdW5jaGluZyB0 aGUgc3RhbmRhcmRpemF0aW9uIG9mIGEgbmV3IGNvZGVjIGxlYWRpbmcgdG8gaW50ZXJvcGVyYWJp bGl0eSBwcm9ibGVtcywgSVRVLVQgV1AzLzE2IGNoZWNrcyB3aGV0aGVyIHRoZSBkZXNpcmVkIGNv ZGVjIHJlcXVpcmVtZW50cyBhcmUgbm90IG1ldCBieSBleGlzdGluZyBzdGFuZGFyZHMuICBJVFUt VCBXUDMvMTYgcmVndWxhcmx5IHVwZGF0ZXMgYSBNZWRpYSBDb2RpbmcgU3VtbWFyeSBEYXRhIGJh c2UgKE1DU0QpIHdoaWNoIHByb3ZpZGVzIGFuIGF1dGhvcml0YXRpdmUgc3VtbWFyeSBvZiBtZWRp YSBjb2Rpbmcgc3RhbmRhcmRzIG9mIElUVS1UIGFuZCBvZiBvdGhlciBTRE9zIHN1Y2ggYXMgM0dQ UCwgM0dQUDIsIElTTy9JRUMgTVBFRywgRVRTSSwgZXRjLiANSVRVLVQgU3RhbmRhcmRpemF0aW9u IFByb2Nlc3MgDUlmIG1hcmtldCBuZWVkcyBmb3IgYSBuZXcgY29kZWMgYXJlIGlkZW50aWZpZWQs IHRoZSBJVFUtVCBzcGVlY2ggYW5kIGF1ZGlvIGNvZGluZyBzdGFuZGFyZGlzYXRpb24gcHJvY2Vz cyBoYXMgc2V2ZXJhbCB3ZWxsLWRlZmluZWQgc3RhZ2VzIGZyb20gdGhlIHNwZWNpZmljYXRpb24g b2YgdGhlIFRlcm1zIG9mIFJlZmVyZW5jZSB1bnRpbCB0aGUgYXBwcm92YWwgb2YgdGhlIFJlY29t bWVuZGF0aW9uLiBXZSBoYXZlIGZvdW5kIG92ZXIgdGhlIHllYXJzIHRoYXQgdGhpcyBwaGFzZWQg YXBwcm9hY2ggaXMgbmVjZXNzYXJ5IHRvIGVuc3VyZSBhIHRyYW5zcGFyZW50IHByb2Nlc3MgYW5k IHRoZSBiZXN0IHBvc3NpYmxlIGNob2ljZSBvZiB0ZWNobm9sb2d5IGZvciBhIHBhcnRpY3VsYXIg cHVycG9zZS4gVGhlIFRlcm1zIG9mIFJlZmVyZW5jZSBjb250YWluIHRoZSB0YXJnZXRlZCBhcHBs aWNhdGlvbnMsIHRoZWlyIGFzc29jaWF0ZWQgZGVzaWduIGNvbnN0cmFpbnRzIGFuZCByZXF1aXJl ZCBwZXJmb3JtYW5jZSAoZGVsYXksIGNvbXBsZXhpdHksIGF1ZGlvIGJhbmR3aWR0aCwgYml0IHJh dGUsIHF1YWxpdHksIGV0YykuIFRoZSBhcHByb3ZhbCBvZiB0aGUgUmVjb21tZW5kYXRpb24gaXMg YmFzZWQgb24gdGhlIHJldmlldyBvZiBhIGxpc3Qgb2YgZGVsaXZlcmFibGVzOiB0ZXh0IG9mIHRo ZSBwcm9wb3NlZCByZWNvbW1lbmRhdGlvbiBhbmQgQy1jb2RlLCBwZXJmb3JtYW5jZSBpbiB0ZXJt cyBvZiBxdWFsaXR5LCBjb21wbGV4aXR5LCBkZWxheSwgYW5kIElQUiBwb2xpY3kgKFJBTkQgb3Ig UkYsIHNlZSBiZWxvdykuIA1JbiB0aGUgbWVhbnRpbWUsIHRoZXJlIGFyZSBzZXZlcmFsIHN0YWdl cyB0byB0aG9yb3VnaGx5IGFzc2VzcyB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIGNhbmRpZGF0ZXMs IHRoZSBxdWFsaXR5IHBlcmZvcm1hbmNlIGJlaW5nIHBlcmZvcm1lZCBpbiBjbG9zZSBjb2xsYWJv cmF0aW9uIHdpdGggU0egMTIsIHdoaWNoIHNlbGVjdHMgdGhlIGJlc3Qgc3VpdGFibGUgdGVzdGlu ZyBtZXRob2RvbG9naWVzLCBkZXNpZ25zIHRoZSB0ZXN0IHBsYW4gYW5kIGFuYWx5c2VzIHRoZSBy ZXN1bHRzIGZyb20gdGhlIGludGVybmF0aW9uYWwgbGFicyBhcHBvaW50ZWQgYnkgU0cgMTIgdG8g cnVuIHRoZSBxdWFsaXR5IHRlc3RzLiAgQ3VycmVudGx5LCB0aGUgZXhwZXJ0cyBpbiBTRzEyIGNv bnNpZGVyIHRoYXQgc3ViamVjdGl2ZSBxdWFsaXR5IGFzc2Vzc21lbnQgYmFzZWQgdXBvbiBmb3Jt YWwgbGlzdGVuaW5nIHRlc3RzIGluIGF0IGxlYXN0IHR3byBsYW5ndWFnZXMgcmVtYWlucyB0aGUg bW9zdCBhcHByb3ByaWF0ZSBtYW5uZXIgaW4gd2hpY2ggdG8gZXZhbHVhdGUgY29kZWMgcGVyZm9y bWFuY2UgYW5kIHRvIGd1YXJhbnRlZSBzdWl0YWJpbGl0eSBvZiBjb2RlY3MgdG8gaW50ZXJuYXRp b25hbCB1c2UuICBPYmplY3RpdmUgcXVhbGl0eSBhc3Nlc3NtZW50IG1ldGhvZG9sb2dpZXMgYXJl IG9ubHkgY29uc2lkZXJlZCBhcHByb3ByaWF0ZSB0byBjb21wYXJlIGFsdGVybmF0aXZlIGltcGxl bWVudGF0aW9ucyBvZiB0aGUgc2FtZSBjb2RlYy4gDUJlc2lkZXMgcmlnb3JvdXMgdGVzdGluZywg c2luY2UgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBHLjcyOSBhbmQgRy43MjMuMSwgSVRVLVQgc3Bl ZWNoIGFuZCBhdWRpbyBjb2RlYyBSZWNvbW1lbmRhdGlvbiBzcGVjaWZpY2F0aW9ucyB1c2UgQy1z b3VyY2UgY29kZSBpbiBmaXhlZCBwb2ludCBhcml0aG1ldGljIGFzIHRoZSBub3JtYXRpdmUgYWxn b3JpdGhtIGRlc2NyaXB0aW9uIG1ldGhvZCAoYWx0ZXJuYXRpdmUgZmxvYXRpbmcgcG9pbnQgaW1w bGVtZW50YXRpb25zIGFyZSBhbHNvIHByb3ZpZGVkKS4gRm9yIG9sZGVyIHN0YW5kYXJkcywgcmVm ZXJlbmNlIEMtc291cmNlIGNvZGUgY2FuIGJlIGZvdW5kIGluIHRoZSBJVFUtVCBTb2Z0d2FyZSB0 b29sIGxpYnJhcnkgKEcuMTkxIEFubmV4IEEpLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGFwcGxpZXMg bm90IG9ubHkgdG8gdGhlIGVuY29kZXIgYW5kIGRlY29kZXIgYnV0IGFsc28gdG8gZXhhbXBsZSBz b2x1dGlvbnMgKGUuZy4gQXBwZW5kaWNlcyBkZXNjcmliaW5nIHBhY2tldCBsb3NzIGNvbmNlYWxt ZW50IHByb2NlZHVyZXMpLiANT25jZSBwdWJsaXNoZWQsIElUVS1UIHNwZWVjaCBhbmQgYXVkaW8g Y29kaW5nIFJlY29tbWVuZGF0aW9ucyB3aXRoIGludGVncmF0ZWQgQy1zb3VyY2UgY29kZSBhcmUg ZnJlZWx5IGRvd25sb2FkYWJsZS4NSVBSIEFzcGVjdHMNV2l0aCByZWdhcmQgdG8gdGhlIHByZXNl bmNlIG9mIGludGVsbGVjdHVhbCBwcm9wZXJ0eSByaWdodHMgaW4gb3VyIHN0YW5kYXJkcywgdGhl IElQUiBwb2xpY3kgYWRvcHRlZCBpcyBjb25zaXN0ZW50IHdpdGggdGhvc2Ugb2Ygb3RoZXIgU0RP cywgd2hlcmUgb25lIG11c3QgZW5zdXJlIHRoYXQgdGhlIHN0YW5kYXJkcyBjYW4gYmUgaW1wbGVt ZW50ZWQgdW5kZXIgZWl0aGVyIHJveWFsdHkgZnJlZSAoUkYpIG9yIHJlYXNvbmFibGUgYW5kIG5v bi1kaXNjcmltaW5hdG9yeSB0ZXJtcyAoUkFORCkuIEV4dGVuc2l2ZWx5IGRlcGxveWVkIElUVS1U IGNvZGVjcyBlbmNvbXBhc3MgYm90aCBSRiBhbmQgUkFORCBwb2xpY2llcy4gV2hlbiB0aGUgcHJl ZmVyZW5jZSBpcyBSRiB0aGVyZSBhcmUgSVRVLVQgY29kZWNzIHRvIGFkZHJlc3MgdGhpcyBzb21l IG9mIHdoaWNoIGFyZSBhbHJlYWR5IHVzZWQgaW4gSW50ZXJuZXQuDVBhcnRpY2lwYXRpb24gaW4g SVRVLVQgV29yaw1BcyBhIGZpbmFsIG9ic2VydmF0aW9uLCB3ZSB3b3VsZCBsaWtlIHRvIGluZm9y bSB5b3UgdGhhdCAxOTEgY291bnRyaWVzIChNZW1iZXIgU3RhdGVzKSBhbmQgb3ZlciA3MDAgY29t cGFuaWVzIG9mIGFsbCBzaXplcyBhcmUgbWVtYmVycyBvZiBJVFUuIFRoZXJlIGFyZSBtYW55IG1l YW5zIHRvIGVuYWJsZSBwYXJ0aWNpcGF0aW9uIG9mIG5vbi1JVFUgbWVtYmVycyBpbiBvdXIgc3Rh bmRhcmRpemF0aW9uIHdvcmsuIE9uZSB0b29sIGlzIHRoZSBwYXJ0aWNpcGF0aW9uIHNwb25zb3Jl ZCBieSBleGlzdGluZyBtZW1iZXJzLCBzdWNoIGFzIGEgTWVtYmVyIFN0YXRlOyB3ZSBjb3VsZCBj aXRlIHRoZSBleGFtcGxlIG9mIGEgdW5pdmVyc2l0eSBhbmQgbGF0ZXIgaXRzIHNwaW4tb2ZmIGNv bXBhbnkgaW4gTm9ydGgtQW1lcmljYSB0aGF0IGZvciBtYW55IHllYXJzIHVzZWQgdGhhdCBtZWNo YW5pc20gYmVmb3JlIGJlY29taW5nIGEgbWVtYmVyLCBhbmQgd2FzIGFibGUgdG8gc3VjY2Vzc2Z1 bGx5IGNvbnRyaWJ1dGUgdG8gdGhlIGRldmVsb3BtZW50IG9mIHZhcmlvdXMgZXhpc3RpbmcgUmVj b21tZW5kYXRpb25zLiAgQW5vdGhlciBwb3NzaWJpbGl0eSBjb21tb25seSB1c2VkIGlzIHBhcnRp Y2lwYXRpb24gYXQgbWVldGluZ3MgYXMgaW52aXRlZCBleHBlcnRzLiBUaGUgc2VjcmV0YXJpYXQg YXQgEyBIWVBFUkxJTksgIm1haWx0bzp0c2JzZzE2QGl0dS5pbnQiIAEUdHNic2cxNkBpdHUuaW50 FSBpcyBhdmFpbGFibGUgdG8gcHJvdmlkZSBkZXRhaWxzIHRvIGludGVyZXN0ZWQgcGFydGllcy4N UHJvcG9zYWwNSW4gY29uY2x1c2lvbiwgd2Ugd291bGQgYmUgdmVyeSBoYXBweSB0byB3b3JrIHdp dGggeW91LCB3ZSB3aWxsIGJlIGdsYWQgdG8gcmV2aWV3IGFueSByZXF1aXJlbWVudHMgeW91IG1p Z2h0IGRldmVsb3AgZm9yIGFuIJNJbnRlcm5ldCB3aWRlYmFuZCBjb2RlY5QgYW5kIGRpc2N1c3Mg cG9zc2libGUgd2F5cyB0byBtZWV0IHRoZW0uDUF0dGFjaG1lbnQ6DU1DU0QgdmVyc2lvbiAyMDA4 LTEwLTAzDV9fX19fX19fX19fX19fX19fXw0NAw0NBA0NAw0NBA0NLSATIFBBR0UgIFwqIE1FUkdF Rk9STUFUIBQyFSAtDUNPTSAxNiCWIExTIDcxIJYgRQ0NSVRVLVRcQ09NLVRcQ09NMTZcTFNcNzFF LkRPQw0NQXR0ZW50aW9uOiBTb21lIG9yIGFsbCBvZiB0aGUgbWF0ZXJpYWwgYXR0YWNoZWQgdG8g dGhpcyBsaWFpc29uIHN0YXRlbWVudCBtYXkgYmUgc3ViamVjdCB0byBJVFUgY29weXJpZ2h0LiBJ biBzdWNoIGEgY2FzZSB0aGlzIHdpbGwgYmUgaW5kaWNhdGVkIGluIHRoZSBpbmRpdmlkdWFsIGRv Y3VtZW50LiANU3VjaCBhIGNvcHlyaWdodCBkb2VzIG5vdCBwcmV2ZW50IHRoZSB1c2Ugb2YgdGhl IG1hdGVyaWFsIGZvciBpdHMgaW50ZW5kZWQgcHVycG9zZSwgYnV0IGl0IHByZXZlbnRzIHRoZSBy ZXByb2R1Y3Rpb24gb2YgYWxsIG9yIHBhcnQgb2YgaXQgaW4gYSBwdWJsaWNhdGlvbiB3aXRob3V0 IHRoZSBhdXRob3JpemF0aW9uIG9mIElUVS4HBw0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAAACCAAAKAgAADoIAAA7 CAAAPQgAAGYIAABzCAAAfAgAAH0IAAB+CAAAgAgAAIEIAACfCAAAoAgAAKEIAACuCAAA0AgAAOsI AAADCQAABQkAAAcJAAANCQAAZwkAAHoJAACJCQAAiwkAAJwJAACeCQAAswkAAMIJAADkCQAA+AkA APkJAADx6uHa0OrE4b60qurEoZXqquqqkYrqquqCeHF4cXhpeFx4AAAAAAAAAAAAABgVaNhgtwAW aGkiPgA1CIFCKgFwaAAAAAAADxVoGyE0ABZoaSI+AFwIgQwVaNhgtwAWaGkiPgAAEhVo2GC3ABZo aSI+ADUIgVwIgQAPFWjYYLcAFmhpIj4ANQiBDBVoVz8IABZot0FqAAAGFmi3QWoAABYVaGkiPgAW aGkiPgA1CIFDShwAXAiBABAWaGkiPgA1CIFDShwAXAiBABIVaGkiPgAWaGkiPgA1CIFcCIEAExVo aSI+ABZoaSI+ADoIgUNKFAAKFmhpIj4AQ0oUAAAWFWhpIj4AFmhpIj4ANQiBQ0oaAFwIgQATFWhp Ij4AFmhpIj4ANQiBQ0ocAA0WaGkiPgA1CIFDShwAEBVoaSI+ABZoaSI+AENKFAAADBVoaSI+ABZo aSI+AAAcA2oAAAAAFWhpIj4AFmhpIj4ANQiBQ0okAFUIASIABgAAAggAACgIAAA7CAAAPAgAAD0I AABmCAAAfQgAAH4IAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAACOAAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6gAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbAABrZCAYAAAWJAEXJAFJZgEAAAAC ljkAAzQBCNZGAAPH/1AFeRmKJmAGiQUAAAAAAAAAAAAAAAAAAAAAAAYpFAAAAAAAAAAAAAAAAAAA AAAABhENAAAAAAAAAAAAAAAAAAAAABT2A8MmGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/ HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEMAAADJAIWJAFJ ZgEAAABhJAJnZGkiPgAJAAAWJAFJZgEAAABnZGkiPgAACAAGAAD2JQAAwicAAP39AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQECfggAAH8IAACACAAAgQgAAI4IAACgCAAA oQAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAAAIwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkAhYkAUlmAQAAAGEkAmdkaSI+AAkAABYk AUlmAQAAAGdkaSI+AABdAABrZKkYAAAWJAEXJAFJZgEAAAACljkAAzQBB5RjAQjWRgADx/9QBRgV iiYgBokFAAAAAAAAAAAAAAAAAAAAAGAGyA8AAAAAAAAAAAAAAAAAAAAAAAZyEQAAAAAAAAAAAAAA AAAAAAAU9gPDJhrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3W DAAAAP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAWgCAAAoQgAAK4IAAC6CAAAzwgAANAIAACh AAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAALgAAAAAA AAAAAAAAAAAAAABdAABrZOEZAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWRgADx/8YBjgTiiYA BlEGAAAAAAAAAAAAAAAAAAAAAAAGIA0AAAAAAAAAAAAAAAAAAAAAAAZSEwAAAAAAAAAAAAAAAAAA AAAU9gPDJhrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAA AP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBDAAAAyQCFiQBSWYBAAAAYSQCZ2RpIj4ACQAAFiQB SWYBAAAAZ2RpIj4AAF0AAGtkOxkAABYkARckAUlmAQAAAAKWOQADNAEHlAwDCNZGAAPH/1AFGBWK JiAGiQUAAAAAAAAAAAwBAAAAAAAAIAbIDwAAAAAAAAAADAEAAAAAAACABnIRAAAAAAAAAAAMAQAA AAAAABT2A8MmGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYM AAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEABdAIAADiCAAA4wgAAOsIAAAGCQAABwkAAA4J AABmCQAA8wAAAAAAAAAAAAAAALsAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA AGcAAAAAAAAAAAAAAABcAAAAAAAAAAAAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAUpHgAFiQBSWYB AAAAZ2RpIj4AAEoAAGtkxRoAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEG AAAAAAAAAAAAAAAAAAAAAAAGciAAAAAAAAAAAAAAAAAAAAAAFPYDwyYa1ggAAAD/AAAA/xvWCAAA AP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBCQAAFiQBSWYBAAAA Z2RpIj4AADcAAGtkaRoAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYaAAHH/4omAAbDJgAAAAAA AAAAAAAAAAAAAAAU9gPDJhrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQoDOQBh9gMA AGY0AQwAAAMkARYkAUlmAQAAAGEkAWdkaSI+AAAHZgkAAGcJAAB5CQAAegkAAIkJAACLCQAAtAAA AAAAAAAAAAAAAKgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAFYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkgmdfAAkAABYkAUlm AQAAAGdkgmdfAAA/AABrZLcbAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWGgABx/+KJgAGwyYM AQAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA /zTWBgABCgM5AGH2AwAAZjQBeXSCZ18ADAAAAyQBFiQBSWYBAAAAYSQBZ2SCZ18AAEoAAGtkNxsA ABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAMAQAAAAAAAAAG ciAAAAAAAAAAAAwBAAAAAAAAFPYDwyYa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d 1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAWLCQAAjAkAAJwJAACeCQAAnwkAALMJAADCCQAA rAAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAKMAAAAA AAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRcAFiQBSWYBAAAAZ2SCZ18A AFIAAGtknxwAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/08IiiYABogIAAAAAAAAAAAA AAAAAAAAAAAGOx4AAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggA AAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0gmdfAAkYABYk AUlmAQAAAGdkgmdfAAkAABYkAUlmAQAAAGdkgmdfAABSAABrZCccAAAWJAEXJAFJZgEAAAACljkA AzQBB5RlAQjWMAACx/9PCIomAAaICAAAAAAAAAAAAAAAAAAAAAAABjseAAAAAAAAAAAAAAAAAAAA ABT2A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A AAD/NNYGAAEKAzkAYfYDAABmNAF5dIJnXwAABsIJAADDCQAAzQkAAPoJAAD7CQAABQoAAAkKAACs AAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAowAAAAAA AAAAAAAAAEcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ EwAWJAFJZgEAAABnZIJnXwAAUgAAa2SPHQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/ TwiKJgAGiAgAAAAAAAAAAAAAAAAAAAAAAAY7HgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYD AAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2 AwAAZjQBeXSCZ18ACQAAFiQBSWYBAAAAZ2SCZ18AAFIAAGtkFx0AABYkARckAUlmAQAAAAKWOQAD NAEHlGUBCNYwAALH/08IiiYABogIAAAAAAAAAAAAAAAAAAAAAAAGOx4AAAAAAAAAAAAAAAAAAAAA FPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAA AP801gYAAQoDOQBh9gMAAGY0AXl0gmdfAAAG+QkAAPoJAAAFCgAACQoAABMKAAB6CgAAewoAALEK AACyCgAAswoAANQKAADVCgAA1goAANcKAADZCgAA5goAACoLAABGCwAAZwsAAI0LAACOCwAAqAsA ALwLAAAIDAAACQwAACwMAAAtDAAALgwAADwMAAA9DAAAxQwAANAMAAD37eXt3M3CsM3Czdztp5+Y jZiNmI2YjX6NbH5dfo1QABgVaG4eQgAWaGkiPgAwShsAQ0oYAGFKGAAAHBVo2GC3ABZoaSI+ADBK GQBhShgAbkgMBHRIDAQAIwIIgQNqpCAAAAYIARVo2GC3ABZoaSI+AFUIAW5IDAR0SAwEHQNqAAAA ABVo2GC3ABZoaSI+AFUIAW5IDAR0SAwEFBVo2GC3ABZoaSI+AG5IDAR0SAwEAAwVaNhgtwAWaGki PgAADxVo2GC3ABZoaSI+ADUIgRAVaNhgtwAWaGkiPgBDShIAACMCCIEDao0eAAAGCAEVaNhgtwAW aGkiPgAwShkAVQgBYUoYABQVaNhgtwAWaGkiPgAwShkAYUoYAAAdA2oAAAAAFWjYYLcAFmhpIj4A MEoZAFUIAWFKGAAQFWjYYLcAFmhpIj4AYUoYAAAPFWgbITQAFmhpIj4AXAiBEhVo2GC3ABZoaSI+ ADUIgVwIgQAPFWjYYLcAFmhpIj4AXAiBAB8JCgAACgoAABMKAABDCgAA1goAANcKAACsAAAAAAAA AAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlAABrZJgfAAAWJAEXJAFJZgEAAAAC ljkAAzQBB5TMAAjWRgADx/8YBmITiiYABlEGDAEAAAAAAAAAAAAAAAAAAAAGSg0MAQAAAAAAAAAA AAAAAAAAAAYoEwwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1gwAAAD/AAAA/wAAAP8b 1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/AAAA/wAAAP801gYAAQoDOQBh9gMA AGY0AXl0gmdfAAkAABYkAUlmAQAAAGdkgmdfAABSAABrZAceAAAWJAEXJAFJZgEAAAACljkAAzQB B5RlAQjWMAACx/9PCIomAAaICAAAAAAAAAAADAEAAAAAAAAABjseAAAAAAAAAAAMAQAAAAAAABT2 A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/ NNYGAAEKAzkAYfYDAABmNAF5dIJnXwAABdcKAADYCgAA2QoAAOYKAACkDAAAzQ4AAO8OAAAJEAAA HxAAADcQAABKEAAAXRAAAPQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAJoA AAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACAAAAAAAAA AAAAAAAAgAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhEA FiQBSWYBAAAAZ2SCZ18AbMYQGgAAAP8IAAAAEAAAAQAAAAAGAAAUpHgAZ2RpIj4AAAQAAGdkaSI+ ABUAAAomAAtGAgANxgcBGgMBqgHAD4SqARGEVv5ehKoBYIRW/mdkaSI+AAA/AABrZDQgAAAWJAEX JAFJZgEAAAACljkAAzQBB5TMAAjWGgABx/+KJgAGwyYMAQAAAAAAAAAAAAAAAAAAFPYDwyYX9gMA ABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgABCgM5AGH2AwAAZjQBeXSCZ18A CwAAE6QAABYkAUlmAQAAAGdkgmdfAAAL0AwAAJUNAACdDQAAqw0AAL0OAADMDgAAzQ4AAO8OAAA+ DwAAtA8AANEPAAAJEAAAShAAAF0QAABeEAAAfRAAAH4QAADGEAAAxxAAAOQQAADlEAAAGhEAABsR AAA9EQAAPhEAAEsRAABMEQAAaREAAGoRAAB1EQAAdhEAACwSAABEEgAAUxIAAOoSAABSEwAAmBMA ALYTAAD7EwAAPhQAAGIUAACGFAAA/RQAAP4UAAAUFwAAMxcAAFMXAABWFwAABhkAAPXp9eL14tbM w8zD4rir4qHiw+Kh4sPioeLD4qHiw+L14sOU4sPiw+LD4sPijOKE4gAAAAAAAAAAAAAAAAAAAAAA AAAADxVo2GC3ABZoaSI+ADYIgQ8VaNhgtwAWaGkiPgA1CIEYFWjYYLcAFmhpIj4AYUoYAG5IEQR0 SBEEABIJagEArvAVaNhgtwAWaGkiPgAAGBVoaSI+ABZoaSI+AGFKGABtSAwEc0gMBAAUFWhpIj4A FmhpIj4AbUgMBHNIDAQAEBVo2GC3ABZoaSI+AGFKGAAAExVo2GC3ABZoaSI+AFwIgWFKGAAXFWjY YLcAFmhpIj4ANQiBbkgMBHRIDAQMFWjYYLcAFmhpIj4AABcVaNhgtwAWaGkiPgBuSAwEbygBdEgM BBQVaNhgtwAWaGkiPgBuSAwEdEgMBDBdEAAAXhAAAHQQAABAAAAAAAAAAAAAAAAALQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EhIAFiQBSWYBAAAAZ2SCZ18AbMYQGgAAAP8IAAAAEAAAAQAAAAC+AABrZGMhAAAWJAEXJAFJZgEA AAAAVAEAApZGAAQ0AQXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAElP8sCLUNIxJgJQAG mAgMAQAAAAAAAAwBAAAAAAAAAAaJBQwBAAAAAAAADAEAAAAAAAAABm4EDAEAAAAAAAAMAQAAAAAA AAAGPRMMAQAAAAAAAAwBAAAAAAAACnQAAOABE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA /wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDzCUVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA /xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA /zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAHl0gmdfAIpUAQAAAnQQAAB5EAAAghAAAMYQAADpAAAAAAAAAAAAAAAA1gAAAAAA AAAAAAAAANYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABISABYk AUlmAQAAAGdkgmdfAGzGEBoAAAD/CAAAABAAAAEAAAAAFRIAAyQBFiQBSWYBAAAAYSQBZ2SCZ18A bMYQGgAAAP8IAAAAEAAAAQAAAAADxhAAAMcQAADaEAAAQgAAAAAAAAAAAAAAAC8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASEgAWJAFJZgEAAABnZIJnXwBsxhAaAAAA/wgAAAAQAAABAAAAvQAAa2RnIgAAFiQBFyQBSWYB AAAAAFQBAAKWRgAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABJT/LAi1DSMSYCUABpgI DAEAAAAAAAAAAAAAAAAAAAAGiQUMAQAAAAAAAAAAAAAAAAAAAAZuBAwBAAAAAAAAAAAAAAAAAAAA Bj0TDAEAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M AQAAAAAA/wQBAAAAAAD/BAEAABT2A8wlFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b 1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP80 1gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAB5dIJnXwCKVAEAAALaEAAA4BAAAOkQAAAaEQAA6QAAAAAAAAAAAAAAANYAAAAAAAAA AAAAAADWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASEgAWJAFJ ZgEAAABnZIJnXwBsxhAaAAAA/wgAAAAQAAABAAAAABUSAAMkARYkAUlmAQAAAGEkAWdkgmdfAGzG EBoAAAD/CAAAABAAAAEAAAAAAxoRAAAbEQAANBEAAEIAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EhIAFiQBSWYBAAAAZ2SCZ18AbMYQGgAAAP8IAAAAEAAAAQAAAL0AAGtkaCMAABYkARckAUlmAQAA AABUAQAClkYABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAASU/ywItQ0jEmAlAAaYCAAA AAAAAAAAAAAAAAAAAAAABokFAAAAAAAAAAAAAAAAAAAAAAAGbgQAAAAAAAAAAAAAAAAAAAAAAAY9 EwAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA AAAAAP8EAQAAAAAA/wQBAAAU9gPMJRU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQ AAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYG AAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAeXSCZ18AilQBAAACNBEAADoRAABCEQAASxEAAOkAAAAAAAAAAAAAAADWAAAAAAAAAAAA AAAA1gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhIAFiQBSWYB AAAAZ2SCZ18AbMYQGgAAAP8IAAAAEAAAAQAAAAAVEgADJAEWJAFJZgEAAABhJAFnZIJnXwBsxhAa AAAA/wgAAAAQAAABAAAAAANLEQAATBEAAGARAABCAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIS ABYkAUlmAQAAAGdkgmdfAGzGEBoAAAD/CAAAABAAAAEAAAC9AABrZFskAAAWJAEXJAFJZgEAAAAA VAEAApZGAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAElP8sCLUNIxJgJQAGmAgAAAAA AAAAAAAAAAAAAAAAAAaJBQAAAAAAAAAAAAAAAAAAAAAABm4EAAAAAAAAAAAAAAAAAAAAAAAGPRMA AAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA AAD/BAEAAAAAAP8EAQAAFPYDzCUVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAA AP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAHl0gmdfAIpUAQAAAmARAABmEQAAbxEAAHURAADpAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAA ANYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABISABYkAUlmAQAA AGdkgmdfAGzGEBoAAAD/CAAAABAAAAEAAAAAFRIAAyQBFiQBSWYBAAAAYSQBZ2SCZ18AbMYQGgAA AP8IAAAAEAAAAQAAAAADdREAAHYRAABTEgAA/hQAABQXAABCAAAAAAAAAAAAAAAAPQAAAAAAAAAA AAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RpIj4AvQAAa2ROJQAAFiQBFyQBSWYBAAAAAFQB AAKWRgAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABJT/LAi1DSMSYCUABpgIAAAAAAAA AAAAAAAAAAAAAAAGiQUAAAAAAAAAAAAAAAAAAAAAAAZuBAAAAAAAAAAAAAAAAAAAAAAABj0TAAAA AAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA /wQBAAAAAAD/BAEAABT2A8wlFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/ AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUD AAA01gYAAQoDbABh9gMAAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dIJnXwCKVAEAAAQUFwAAMxcAAFgaAABLHQAAeB8AAO0fAAD5HwAAyCEAAOQhAAD3JAAAACUA AL4lAADKJQAA4iUAAPUlAAD2JQAA+CUAAPklAAD7JQAA/CUAAP4lAAD/JQAAASYAAAImAADqAAAA AAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAA AAAAAOoAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADq AAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA1QAAAAAA AAAAAAAAAOUAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAA AADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABwAAAyQBYSQBZ2RpIj4A CAAACiYAC0YBAGdkBFB8AAAEAABnZGkiPgAVAAAKJgALRgIADcYHARoDAaoBwA+EqgERhFb+XoSq AWCEVv5nZGkiPgAAFwYZAAAHGQAAZR0AAMEdAADiHQAA/B0AACseAAAMHwAADx8AAO0fAAD5HwAA FSEAACAhAADIIQAA5CEAAIgkAACJJAAArSQAAK4kAACvJAAAviQAAL8kAAD3JAAAACUAAL4lAADK JQAAziUAAPUlAAD2JQAA9yUAAPklAAD6JQAA/CUAAP0lAAD/JQAAACYAAAImAAAEJgAABSYAABsm AAAcJgAAHSYAAB4mAAA0JgAA9/Dn8Ofw593n0/Dn8MvwwPCywKnA8Mvwy6LwnpaSlpKWkpaSiXyJ fHF8iQAAAAAAAAAVFmgbITQAQ0oSAG1IAARuSAAEdQgBGQNqAAAAABVoaSI+ABZoaSI+AENKEgBV CAEQFWhpIj4AFmhpIj4AQ0oSAAAGFmh9Fe4AAA8DagAAAAAWaH0V7gBVCAEGFmhxUAoAAAwVaARQ fAAWaGkiPgAAEBVo2GC3ABZoaSI+ADBKGQAAGwIIgQNqQSYAAAYIARVo2GC3ABZoaSI+AFUIARUD agAAAAAVaNhgtwAWaGkiPgBVCAEPFWjYYLcAFmhpIj4ANQiBExVo2GC3ABZoaSI+ADUIgWFKGAAT FWjYYLcAFmhpIj4APioBYUoYABAVaNhgtwAWaGkiPgBhShgAAAwVaNhgtwAWaGkiPgAAEBVo2GC3 ABZoaSI+AE5IAQArAiYAACEmAAA0JgAANSYAAFImAABTJgAAAScAAL4nAAC/JwAAwCcAAMEnAADC JwAAwycAAPcAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAACdAAAAAAAAAAAAAAAAlgAA AAAAAAAAAAAAAI8AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAigAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAGdkaSI+AAAGEAATpAAAZ2RpIj4AAAYAABOkAABnZGkiPgA+AABrZBwnAAAWJAEXJAFJ ZgEAAAAAVAEAApZsAAM0AQjWGgABx/+KJgAGwyYEAQAABAEAAAQBAAAEAQAAFPYDwyYa1gQAAAD/ G9YEAAAA/xzWBAAAAP8d1gQAAAD/MtYGAAEKAzkANNYGAAEKA2wAYfYDAABmNAGKVAEACwAAE6QA ABYkAUlmAQAAAGdkaSI+AAAEEABnZGkiPgAAAQAAAAkPAAMkARSk8ABhJAFnZGkiPgAABw8AAyQB YSQBZ2RpIj4AAAw0JgAANSYAAFImAABTJgAAXSYAAMAnAADBJwAAwicAAMMnAAD87/zj2vzW0gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmhxUAoAAAYWaH0V7gAAEBVoaSI+ABZo aSI+AENKEgAAFhVoaSI+ABZoaSI+ADUIgUNKEgBcCIEAGBVoaSI+ABZoaSI+AENKEABtSAwEc0gM BAAGFmiCZ18ACDkACjABJlAJADGQaAE6cGkiPgAfsH0uILDIQSGwbgQisG4EI5CJBSSQiQUlsAAA F7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIBgAAEQAZAAAAAAAAAAIAAAAAAAAAAAAAAAAAEUGCAfxAuECAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwTAAAALIECvAIAAAAAQQAAAAKAABDAAvwKAAAAARBAQAA AAXBEAAAAAYBAgAAAP8BAAAIAGkAdAB1AC0AbwBsAGQAAAAAABDwBAAAAAAAAIBiAAfwgBcAAAYG AUBiTRU7jpmGIdjQWNlMW/8AXBcAAAEAAABEAAAAAAAbDQBuHvBUFwAAAUBiTRU7jpmGIdjQWNlM W/+JUE5HDQoaCgAAAA1JSERSAAAAawAAAHgIAwAAAMIj/AsAAAMAUExURaLE2YeVxOzx8oq20sTW 37zT3dzm6dXh5ZiEp2SOvKzK2pG61Rs3j/r6+qWyz+pnhfLF0ChElpajyeRUdnWlyLHN23eJu/Hz +DhTnml8tPT19sbZ4K1ojsPL4oejxs3d4mqXwe+xwNDe5J3B2Upgp7jS4+jt71lureTr7ODo6u2R p4Szz+Tu9N7n6uvv8LO92OLq7FV+tOQmUvKfstjj5tPY6csqV8ja4fP09cDW37rM2t0NPefX3rbQ 3O/y8+br7aS30Ja91/b3+Oc/ZqQMS+MQQPvg5l11r5qvyy5MmlyFt0NaoTldorPG18rU3+p+l051 r9bk6r5GcGMcaOLl8Zm/2ERipt/r8n6Tvs+Zr8isvazD1rzH2kduq8aAncvc4+Pm7T9lp1Fqqc/g 6tgYR5Kvzc7e5r03ZbvF1e/j59nf6rLA1cnc5cre66m90p6tzMfc6c/a4/Hz86fH2v3w89HX56Ww 0/3v8qfJ3ePs72BXmOEAM3+xzg4rif///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAM25c8QAAACAdFJOU/////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////8AOAVLZwAAAAFiS0dEf0i/ceUA AAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAABNNSURBVGhDvZrtQ9rYEsYDCFQgahDDiciLQImIICou UgsivTWGRCpdtdytrCu+tFddbXHXyhrCv37nJAESxLb3g3ewQgPyyzMzZ86ckxAd1bYmtBfP+ERo 302ubD0jRf3qLqvz+h353LAeq/NuVn5mWJ+19ebb/40lv5t8Zi/2dXUm3q48rzAdSx5/+7y5qGN1 vj08rxf1rM67h5XnzEUDa2v5Wb1oYMnzD2/+er78MLA6W6cP88/nRSMLIvbwfEV4gPVt+TteJElv yvzHHlgq5ZVL/7OzB1jyysPD+DAvbmz4b0wMy3Isyzbwb5q+81/8b7gBVgeEPQwUYZK8WKxFBZY2 uYuHn/2Vr5XDz5djbppuCNGa/2/ypyvbIKsz+/CwrC8fqQs3y7Omy9WNmLnZNJvNsVgshX9a8UyF bgsCY7qY/jl9j1jf3jzoysfeIsu76Mp0qQDfD7YxB5ZOx8GSNls8zrGHgUaUOyz8DO0RSwZhWuKX 9kxRqs2uNpsqSKUBToEl062Y2SaYCvZX4GHTxo9d+YjVIUHYW5z4q6YowyB3qbS21lxrNpvw1GwW CqkUprViMf9YwBSouV61bEn7dkNw7/1I22NWZ2IdQvYt5UZM5VIYu6jcmGo0BwapV3OP+b9mzNPN pj0QRXAqDEtRDfoyvJApNpB7+vt1YAhLHgcvTtbZSuyzi2KFKMvUgFEsKkzIvQZbKxYFdiwD8pLx MCDRgcmXDG4LDf93HTmE1dl6C7CZj7TgargvK3+QMjxKJBi8aMYrn9200G7Tl/a5VMtmS28L9hGT gEzBqo9Gte85chiriYU9/GOihTmyNA0hAoNQNQv4ZXO6VCoIpkM6KnA32dScLdOotWzBbXRwXQ1/ FITK09KGsMia61/AWt6qu0uplFnhrCmGU6NgTk1fCxupZuzQ1EBc0WYuokomDKKo2tHJUY1ffLJ4 PWbFuDb1Hgv7FK02VRRgpsG0RDSTNN2E1Dc3459pJAS+sjVbOFxtXYtMLngyhkzeJxLyEetCaDMj c5D3Dw/vSbOCmlZICg0rM8ucu4lHdTo9F7PfRAUBhVvBy+0A10Zso4HajdjwfBxkVXjqGurPLOT9 w/pKCVBYU0k1DUbStWYspgzpdKw0d4Pa0Yag5CtPBc4C26wwvIwMsCpUYzU1F2+ZlfRYnyiZdagu jHSz00q5ipnTOwGucYDaLs5qD56fWAUanqycMNSNRtbfPB1vxePpdPo1zvuH5dekqgpnPEkqsLXC 2ioKm1MF89wlLSDWdP01LNANFDgJZ893qMBVznpVHqrMwLrga7F4Elhzc+Z5zHp4kyr1URqsWSix tJw6pA8EZiycTKVtczRXdfONS3v2JICsOWsuxwqxxwmiZ8UEJh23KaxWSk2Ph3EcJ1VVV1izQFaQ iUVMMW2GymHLZDJ+tJMcYaiaLzgi1M6t1nyeYx9PNDoW2UAZm01lzW14JxQvPrwraTVDVlil6TWS tNdcbfdFszkH9d4GLLuNpW326jYSPlYDQi4HLIdgejSo+yyZdh3GAZaEcM3NtRbU9ID5RVEkg6kw +YJG3CLLrKUwClgAs40hXzhYzTFU4JVwDaypfIRaHMz8PuuwTafhrzRWLDVdxNUDbEXHIhWSnyQz iEmleqzMV2GsGswenQR4Ttj2AWsqH+BXB0LWY11QVAWfYdeHqcJXFx5kkPmzWJEiSy6YEFcpkVCn KgKbTCm6wIf2FsPZg9ls1r5z0D67wizHSwYNZH6XRTIuJm3vs2Ix80bjvRqy0wnMwbhF1PDLJeg6 UqlCkkOH5jnoBDArWRSywPL5gjsuqujL56cc9w6xZhTWZRUFNGbrsj6YF6CJIQNLk6oX3yow+Q8O FUlyrQnlN5WKFVI1nrab4wrLHhaKYYW1LTDUmU9hnbn+NsA0VgGZDip2jdV6vTIx8fo///n8z2/Q wanKQNQdojdkaAhwqccNyEbzsIFMmZgNs2wcUwUfBnOIPqnxtdyU4/b2fjRqqPkqS65x2w34C+xD WzKdWV4/XQZbP1WdiJUtcOizTE7D9K+xNuZgeI1FUe1VJh2v2twH1XP7ybXQyPmyAVfNCiyCQHd6 YSprj7cGmDBmASweX1CLht5O/6FTslZ8FRdC7YXim0qOsahRu9mpvOKvX21zFJPz5ay+ABXKA+o+ ZCgfCktmmBbNgC5FGIxlm+Y7PW0F+0+bLbELAYWbxLnYKzcnRBFy8dCXFo9GclawABWYIsAO3Dph CmuP32kxNHa7logL0NY/snelkjIva9FSukSchsm07av18yuGtebOgyNQNaBsWGuugIOIEB6ka0Aw S4bSaWPoKjhRg32wqdXQaOMFmM8wCmRBtNSRDG63Z+xhOwQse+Tzaax8fpS33EYi+8d3/eqBWXvo 8qha4+AP+sKUyXLQJl/DTK2herKUjA8H7R/RTo8FQ3lqF+0TkUhI6JdFYMl3bDBbNXHhsAJTym9y QauGRtzyBHQ7Sr4r0VJcqLFOXqHrI1UWlA2Hw0GgOhHZd6LFXsSAZY6ehbN2d0NjYVg83no9JD2g Xs2bvQva/G9ABY/sjUAQs3CVB9btvZMaJTb3y4yetYpGYBDuIKsCU9Ie5pUhea9onHxtVpYPBlXh YPCoyjDBETVc4EIYXfc1Soo4JdQrwaCrRtt9vmxQ2Aa3KxFTi31LK1CDQVteWVhQFyp9D4aDR1l7 jVV0YVnAgoS/30WbTiffcyLRIaPbENPsCRQZnReT8Q8Tp0PSQ5WmqeoGC6Oy4cABDC5NFmZFIk5+ CVhct9wTHb+Qs0Gn4v16WGo2vbD68cYzMS+e+SdWhtv8BFlKJZNmrT/1Fppes/kke42U0ZW3LbRa rQ+KjYxVCdGV0iJGdIqcbwHPun3bsDeNB4b8b9pmKxkOV32v0A7UJ2veazjuOG53qz0hc4FcTHbj tb368Mtpe0F/oPtG/5l1y2uYVcP7AvjBVuTqiA8RmDVVInvHGxfyfd3VncaIvWhxZEFm2z27kdPh gv5A/63eqwawMtMy6h1YxCzhLItbjRLJ94775YAocl0frjamrAsyM8jSHRjKamaABcswze7kTG4k 6s7ihC+R/eOHcsNVRlrpIPwHVmtML+PuJ3SxcjNjN+qyj/gO3NDV5B0lsq/XL3MuSfSrwggT47O2 jLriwYLMDVHTPySoLL0uO9alsfS6aJdUv9FYdMiXbxl1xY/M8g3LMhw8GKbv/DZilCMccyMX7IO6 crloADc190ZdjXa5TGusRiAHLEO8MAuWxvgH/pn6ckxKR6ocV1gGXVZg5aBk3Orj5Zfpulg2aazo mXVqQJctOOe/S8E6D5qpkkzrWWuFC/dNjDQX0uGwMV4nGstx6zXEi/DwS6yaHAQq5oFl0GU7OkK0 LYiLYzgm1/SsuP3rDaz57TaonWsGXSdWK+jCldCYh4QkHjeUKnVBIGLqkS67SQjDl+FSHDPqitvt 6bAbaCM2+5phfJ3kgWWFtpAwxouQlvio0ggsYpYjbtSVHEFuexCzwuGUUdcH3ABV7e4DxHw0xus8 bz0IWGHeIryG8UVIIVdD2WhcBZYDWLq6cSeba4IvCAao4ICu2eoJPgNbGFo1v0HXeT6PtvG8FTHq ikiSS1A3NQkUcdwmjbqyKGDPHik0YBni9Wb8T4AFg+fV8KukIV7nU1N8ceoWWNNGXR4LxWss6sxx O6CLEUZgPsoeHR0FjzaM8XrzMFk5CcI78AGvMV65InJAajyOV0JEGstVmyIGdEVRLugDGOCyrQFd sIT+fILPJOvzGnRdB2j+7CzgqbF7uuOHMuFJ1LusdhmzDPGCRbcVpmoFlx7UBZsDv/2JVyS+gkEX LVKUANsqYn3POL4kYKkNKUEd30YGdF3mBAGUYZjvsS5YSPz7zyuFpa8bV1PcbsRZ3CegRunrIeha iqpdACG4nIO6qr4RUIZhPt8QXdBxjPuufCPGeH3JR0chWETEOVA3pESvbjDtEFE15qHd6oMNimvo rjDLmIdauzP5+QvM5lHd/JUlUOAWms99YBl0SVLdpPbZBO2qR6rGeEFp811x/Fh4xDdi1EXCNRDV ln/7op9haXnhTG3gnffyhat3DhekU0rsduv8HeKlAV1Q2qwjVzQVgJ45btSV+b0LW//9g24KcO3J l8ebkf1N571XDvRQVKxkgdzozl8X4nH9g1EXlBuwKzdFj/iSxjy0+37vLSrGZX+/LHMl2XwCDXZS lg/7R1n5gyRJQndeXo2GqJfGeJ1PKTDfNTrYWTDqOsl9+a0LO93SJXdbOFRbtT1T34Ntt/xSkjy8 tl1EeBsewW3UdTSVh9Va3urLc/yiUdc5bGx1F+wP72S3vlMQaPeNiaV0hxBJWiRLudHto+Tarmds oB5CrcG4fC5XCxh1wb6W9cu1toRZ3vpBa7cof5GkhKilBtwPsHjg/NOoK3vrwDRFXcao6wifgnVH W1aMy3t6GYPtkEk2Q2Z4+n0vrCo9A3noA5ZKm5qyGXVdYdZU3jGjpuOKvNd4quFyuWUSJpTEMdVd MsOaiC1XZd1f3Mg5AqYGjAOrGnVlMR/OI6+m4zpsDtzoGi0dl1mVSwSgRttMd0MFWHfoBPbzXJRm d8AiMO1eZZl678CZ+rRTcNz/W10xjX+TS4cMr8s94LngQo4s2zYh3yW+vailBr5/Y4F/aVyI5CIq DMTdVgfegm0mxz2cB3F/84sCO53fgo9c3MEFxihYg6Pdfmj55A8OTAIP9ncdgFXiAt4F8/mqF+94 XeyZzS8jGIbtlvgC6zFYX8FP0r/aJHPKKeBFI3F/rVwxgLI/OT8xsGqyvYRIKShUp3ubDnjPoYKk hHOU8mw6N51iiNjfj4BpNFUflkiM8mItMgWlXDH4xMeZ7rBef/tmfP5PvLqrfsk59hMKSEpIx7wH aUUD11745xXKiYSlzktOZ0IMRTY3N/dVXg+oaHREaJ5fOru9h3KumaZM1ffLC6gR8OiaJcQjqXzQ 32pT9oiu+YSUSIh8ArP2nU4dzcC7j3gOqIOQhbgn4Fy2X3zqFmL1ef2TqQeSLNKuqy4l+DHjvk2n hEYBJomiJYEwC8M290FdRJXXM4jSWRnxx6HEvntmyNJ9/X1A9V5CWqL4kCVR1m3bqPcRyXe84l5e lMSQ02IBmsrDzhywyH1E4tCvv/TKvVHb6UwAohWqU/wofGEC6mk347v3LJEQMYB5EEKYBTQdr89U 2E73zLCNsR7ydIYTqeMQ1mYpi/pNem1fdJGCs8BubIeckCeqKfIMtul+8f4pRX1967/WLGoq8od9 Vb17sWS2blHdSIGXe7RB3OZMd1PW6LmB/52+wF8GEzI3ZL8XFixUCJ8KjHNqFE4K47ryFI8qD0C/ eGozRyfrPQ4ZLoW88Uppd89cDuD0gMmmXKZ2sT8xTidQc6vFeWYYU4/lrb9/AZFSfeQ2XuXoXXco NbAXLfW6M0SJCgx/XAWqTOUZjvSqxRA/rr83aUUDXNQYuHrTv56yR5Vhwt49hnQU+VHF4X1TOZqZ 1Kr72E5nXvQ+ZCnz3X0oXZ3XXsp+CBlkKZazhIe8kaYHS8Ok/fIealTPLCHKkINKL9pPStnNe6CG eQBi8fAg7WmaNFCe1j/NvDCcXMLDBx5djNVf1yvRIIpX81HapeqeAUcapRkS8sXgiVH9qaSnxnC9 0sscW8QlLS9CIrX0PUcGDAk5Y4iuhJghl+oNLNhmFpdETU0iMUqhMtTrp8zyj74mflKrrpq+Yq/H GFI3uoe8LE/1ZiBcrGEGeCJsliVqVF/rT7s5CAOL/onryx25wLSXnP1s8uxSYhmX0UFLJJZcoUTC pMvIddWPCQ81VJUhD1VtJRoqYt8dFs8STMaewdAnErsUzHlgpvd9T/4CAxkyufbEnQ7GeCmwOxe0 BH0d4EkEc4RuLCudBNXN0oSpnySnM9Iu737qDo7HrA5cqT42pLtFCh1T/G5IgjKlnAMefngYdnNB p+1f/zwawsNzvnv0ghlIiYTFUz7m0e4o4CB6owNlJSEFtMuo0C++e/JG0CG6sB/HQJoxIyyAE3lK 3PV46lTZiSVq5VwpzFLtk3Y5+mF54gnacBbMZzS/OzC2EpAyoSWx7WqjpdFRDx4aUPyhT/OEynVR pFy/vtFm0smJoXdMPsXqkH4WT2TGbE9YQsd8ubwrQmPCg4miCL8RL9Z3RZ67ImfHVdryUEc+yerI Xriku+TBaro5kPAc4yqJ1XhATWh0aakcCoHC0K7ILpbkDklOvFtWxgC0+fqSobx+moUb4kNOEKH3 wurgF2RjP4raPIpDNSqKjL9XKbZmJ5WyvDw7SPsuC2h/wybo7ijExgOjrA6jTDfwICckz2idj5r2 9KOX/LaliHv7ZpY0zCs/YIE4smKKHoh8G6IH3Y2uJ5BC5WPxIGq6GHILCojDTeTkrP5+8h+zAGde LdKsyIvHu+XyaAjiVF7aPYaMYN03F0/dVLa1Na/cFzdruDb6KIbDDsDNKYdwxyjNNKLRA5ZmTHeH F96S/L175Uhyax5GQX8A/JSunzqboR/agrx8Oz6hevKZWZ3OX3/Nji+Pz/4FWfLsLCwIMmUesuT/ wgJ1W7Ozf/0XvHEVdKRHia0AAAAASUVORK5CYIKHABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUA AQOJBTXWBQECAykUNdYFAgMDEQ0jdgABiQUjdgECKRQjdgIDEQ06VgsAApY5AAM0ART2A8MmF/YA AAAr1gIAAzXWBQABA4kFNdYFAQIDKRQ11gUCAwMRDTTWBgABBQAAADTWBgABCgM5AGY0AZAAFiQB FyQBSWYBAAAAAZYAACF2AANoATXWBQABA4kFNdYFAQIDyA811gUCAwNyESN2AAGJBSN2AQLIDyN2 AgNyETpWCwACljkAAzQBB5RjART2A8MmF/YAAAAr1gIAASvWAgEDNdYFAAEDiQU11gUBAgPIDzXW BQIDA3IRNNYGAAEFAAAANNYGAAEKAzkAZjQBpAAWJAEXJAFJZgEAAAABlgAAIXYAA2gBNdYFAAED iQU11gUBAgPIDzXWBQIDA3IRI3YAAYkFI3YBAsgPI3YCA3IROlYLAAKWOQADNAEHlAwDFPYDwyYX 9gAAACvWAgABK9YCAQEs1gMCAwE11gUAAQOJBTXWBQECA8gPNdYFAgMDchEv1gsAAwQAAAD/DAEA ADTWBgABBQAAADTWBgABCgM5AGY0AYYAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA1EGNdYF AQIDIA011gUCAwNSEyN2AAFRBiN2AQIgDSN2AgNSEzpWCwACljkAAzQBB5RlART2A8MmF/YAAAA1 1gUAAQNRBjXWBQECAyANNdYFAgMDUhM01gYAAQUAAAA01gYAAQoDOQBmNAFaABYkARckAUlmAQAA AAGWAAAhdgABaAE11gUAAQPDJiN2AAHDJjpWCwACljkAAzQBB5RlART2A8MmF/YAAAA11gUAAQPD JjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA1EGNdYF AQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhf2AAAANdYFAAEDUQY11gUBAgNy IDTWBgABBQAAADTWBgABCgM5AGY0AX4AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA1EGNdYF AQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhf2AAAANdYFAAEDUQY11gUBAgNy IC/WCwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBbgAWJAEXJAFJZgEAAAABlgAAIXYA AWgBNdYFAAEDwyYjdgABwyY6VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDwyYv1gsAAQEA AAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdfAHYAFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdfAHYAFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdfAHYAFiQBFyQBSWYB AAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0AQeUZQEU 9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdfAHYAFiQB FyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0 AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdf AIQAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsA ApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7Hi/WCwACBAAAAP8MAQAANNYGAAEF AAAANNYGAAEKAzkAZjQBeXSCZ18ACwEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAA IgAAAGMAbABhAHUAZABlAC4AbABhAG0AYgBsAGkAbgBAAG8AcgBhAG4AZwBlAC0AZgB0AGcAcgBv AHUAcAAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupC1IAAABtAGEAaQBsAHQAbwA6AGMAbABhAHUA ZABlAC4AbABhAG0AYgBsAGkAbgBAAG8AcgBhAG4AZwBlAC0AZgB0AGcAcgBvAHUAcAAuAGMAbwBt AAAAmgAWJAEXJAFJZgEAAAABlgAAIXYAA2gBNdYFAAEDUQY11gUBAgNKDTXWBQIDAygTI3YAAVEG I3YBAkoNI3YCAygTOlYLAAKWOQADNAEHlMwAFPYDwyYY9gMAADXWBQABA1EGNdYFAQIDSg011gUC AwMoEy/WCwADAQAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBeXSCZ18AbgAWJAEXJAFJZgEA AAABlgAAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsAApY5AAM0AQeUzAAU9gPDJhj2AwAANdYFAAED wyYv1gsAAQEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0gmdfAL8AAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ 6nn5us4RjIIAqgBLqQsCAAAAFwAAAA8AAABjAG8AZABlAGMAQABpAGUAdABmAC4AbwByAGcAAADg yep5+brOEYyCAKoAS6kLLAAAAG0AYQBpAGwAdABvADoAYwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8A cgBnAAAAAgEWJAEXJAFJZgEAAAABltr/IXYABGgBNdYFAAEDmAg11gUBAgOJBTXWBQIDA24ENdYF AwQDPRMjdgABmAgjdgECiQUjdgIDbgQjdgMEPRM6VhoAApZGAAQ0AQp0AADgARPWMAAAAP8MAQAA AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8wlFTYBGPYDAAA11gUA AQOYCDXWBQECA4kFNdYFAgMDbgQ11gUDBAM9Ey/WCwAEBQAAAP8MAQAAcNYoAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0gmdfAIpUAQD/ABYkARckAUlmAQAAAAGW2v8h dgAEaAE11gUAAQOYCDXWBQECA4kFNdYFAgMDbgQ11gUDBAM9EyN2AAGYCCN2AQKJBSN2AgNuBCN2 AwQ9EzpWGgAClkYACnQAAOABE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/ BAEAAAAAAP8EAQAAFPYDzCUVNgEY9gMAADXWBQABA5gINdYFAQIDiQU11gUCAwNuBDXWBQMEAz0T L9YLAAQBAAAA/wwBAABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXSCZ18AilQBAPEAFiQBFyQBSWYBAAAAAZba/yF2AARoATXWBQABA5gINdYFAQIDiQU11gUCAwNu BDXWBQMEAz0TI3YAAZgII3YBAokFI3YCA24EI3YDBD0TOlYaAAKWRgAKdAAA4AET1jAAAAD/DAEA AAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPMJRU2ARj2AwAANdYF AAEDmAg11gUBAgOJBTXWBQIDA24ENdYFAwQDPRNw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXSCZ18AilQBAPEAFiQBFyQBSWYBAAAAAZba/yF2AARoATXWBQABA5gI NdYFAQIDiQU11gUCAwNuBDXWBQMEAz0TI3YAAZgII3YBAokFI3YCA24EI3YDBD0TOlYaAAKWRgAK dAAA4AET1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gPMJRU2ARj2AwAANdYFAAEDmAg11gUBAgOJBTXWBQIDA24ENdYFAwQDPRNw1igAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXSCZ18AilQBAPEAFiQBFyQBSWYBAAAAAZba /yF2AARoATXWBQABA5gINdYFAQIDiQU11gUCAwNuBDXWBQMEAz0TI3YAAZgII3YBAokFI3YCA24E I3YDBD0TOlYaAAKWRgAKdAAA4AET1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA AP8EAQAAAAAA/wQBAAAU9gPMJRU2ARj2AwAANdYFAAEDmAg11gUBAgOJBTXWBQIDA24ENdYFAwQD PRNw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXSCZ18AilQBANsA AABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABAAAAB0AHMAYgBzAGcAMQA2AEAAaQB0 AHUALgBpAG4AdAAAAODJ6nn5us4RjIIAqgBLqQtGAAAAbQBhAGkAbAB0AG8AOgB0AHMAYgBzAGcA MQA2AEAAaQB0AHUALgBpAG4AdAAAAHlYgfQ7HX9IryyCXcSFJ2MAAAAApasAAGgAFiQBFyQBSWYB AAAAAZYzACF2AAFoATXWBQABA8MmI3YAAcMmOlYLAAKWbAADNAEU9gPDJhf2AAAANdYFAAEDwyYv 1gsAAQ8AAAD/BAEAADLWBgABCgM5ADTWBgABBQAAAGY0AYpUAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCHQASAAEAnAAP AAQAAAADAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGYAAEDx/wIAZgAMEAAAaSI+AAAABgBOAG8AcgBtAGEAbAAAACcAAAANxg4ABBoD pwQ0BsEHwMDAwBOkeAA1JAA3JAA4JAA5RAIASCQAABgAQ0oYAFBKBABfSAEEbUgJCHNICQh0SAkE UgABQAEAAgBSAAwEAABpIj4AAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwA QCYAFgA1CIFDSiAAS0ggAFwIgV5KAgBhSiAAAAAAAAAAAAAAAAAAAAAAAEQAQUDy/6EARAAMAQAA AAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABW AGlA8/+zAFYADAUAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMA ADTWBgABBQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrAPT/wQAoAAAFAAAAAAAAAAAHAE4AbwAg AEwAaQBzAHQAAAACAAwAAAAAADQAH0ABAPIANAAMAAAAAAAAAAAABgBIAGUAYQBkAGUAcgAAAA0A DwANxggAAl8SviQBAgAAADQAIEABAAIBNAAMAAAAAAAAAAAABgBGAG8AbwB0AGUAcgAAAA0AEAAN xggAAl8SviQBAgAAAHwA/k8BAAIAfAAMAAAAaSI+AAAACgBUAGEAYgBsAGUAXwBoAGUAYQBkAAAA RQARAAMkAQYkAQ3GLwMaA6cENAYNHAE3AlMDbgSKBaUG3Aj4CRMLLwxKDWYOgQ/AwMDAwMDAwMDA wMDAE6RQABSkUABhJAEABwA1CIFDShYAAHIA/k8BACIBcgAMAAAAaSI+AAAACgBUAGEAYgBsAGUA XwB0AGUAeAB0AAAAPwASAA3GMgMaA6cENAYOHAE3AlMDbgSKBaUGwQfcCPgJEwsvDEoNZg6BD0BA QEBAQEBAQEBAQEBAE6QoABSkKAAABABDShYAOgD+TwEAMgE6AAwAAABpIj4AAAAKAEwAUwBEAGUA YQBkAGwAaQBuAGUAAAACABMACgA1CIFQSgUAXAiBPAD+TwEAQgE8AAwAAABpIj4AAAALAEwAUwBG AG8AcgBBAGMAdABpAG8AbgAAAAIAFAAKADUIgVBKBQBcCIE2AP5PAQBSATYADAAAAGkiPgAAAAgA TABTAFMAbwB1AHIAYwBlAAAAAgAVAAoANQiBUEoFAFwIgTQA/k8BAGIBNAAMAAAAaSI+AAAABwBM AFMAVABpAHQAbABlAAAAAgAWAAoANQiBUEoFAFwIgS4A/k9BAXIBLgAMAAAAaSI+AAAACQBMAFMA RgBvAHIASQBuAGYAbwAAAAIAFwAAADQA/k9BAYIBNAAMAAAAaSI+AAAADABMAFMARgBvAHIAQwBv AG0AbQBlAG4AdAAAAAIAGAAAADYAVUCiAJEBNgAMBAAAaSI+AAAACQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioCcGgAAP8AlACaQLMAowGUAAwEAABpIj4AAAAKAFQAYQBiAGwAZQAgAEcAcgBp AGQAAAA3ADpWGgAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAJwAaAA3GDgAEGgOnBDQGwQfAwMDAE6R4ADUkADckADgkADlEAgBIJAAABABQSgQALgD+ T6IAsQEuAAwAAABpIj4AAAAEAGUAeABiADEAAAAOAENKEgBhShIAcGgAAAAARgBWQKIAwQFGAAwE AAAEUHwAAAARAEYAbwBsAGwAbwB3AGUAZABIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioOcGhg ZCAAAAAAAMMfAAAGAABcAAAAAP////8AAAAA9R0AAMQfAACaQAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAgAAHCgAAAAAwAAAAAAAAAAAAAAAABjDpHgAAAAAABwAAAABDAgAA1gIAAPUdAADEHwAAq0AA AAAwAAAAAAAAAIAAAACAAQAAAAAAAAAgB6tAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAIAeaQAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAgAAHCgAAAAAwAAAAAAAAAAAAAAAABjDpHgAAAAAABwAAAAAC AAAAKAAAADsAAAA8AAAAPQAAAGYAAAB9AAAAfgAAAH8AAACAAAAAgQAAAI4AAACgAAAAoQAAAK4A AAC6AAAAzwAAANAAAADiAAAA4wAAAOsAAAAGAQAABwEAAA4BAABmAQAAZwEAAHkBAAB6AQAAiQEA AIsBAACMAQAAnAEAAJ4BAACfAQAAswEAAMIBAADDAQAAzQEAAPoBAAD7AQAABQIAAAkCAAAKAgAA EwIAAEMCAADWAgAA1wIAANgCAADZAgAA5gIAAKQEAADNBgAA7wYAAAkIAAAfCAAANwgAAEoIAABd CAAAXggAAHQIAAB5CAAAgggAAMYIAADHCAAA2ggAAOAIAADpCAAAGgkAABsJAAA0CQAAOgkAAEIJ AABLCQAATAkAAGAJAABmCQAAbwkAAHUJAAB2CQAAUwoAAP4MAAAUDwAAMw8AAFgSAABLFQAAeBcA AO0XAAD5FwAAyBkAAOQZAAD3HAAAAB0AAL4dAADKHQAA4h0AAPUdAAD2HQAA+B0AAPkdAAD7HQAA /B0AAP4dAAD/HQAAAR4AAAIeAAAhHgAANB4AADUeAABSHgAAUx4AAAEfAAC+HwAAvx8AAMAfAADE HwAAqQAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAA oACpAAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAmQAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAg AKkgAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACpAAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAIAA qQAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACZ AAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqSAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKkg AAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACpAAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAIAAqQAA AAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAJkAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACpAAAA ADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAqQAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKkAAAAA MAAAAAAAAACAAAAAgAEAAAAAAAAAoACZAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqQAAAAAw AAAAAAAAAIAAAACAAQAAAAAAAACgAJkAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACpAAAAADAA AAAAAAAAgAAAAIABAAAAAAAAAKAAqQAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAJkAAAAAMAAA AAAAAACAAAAAgAEAAIQAAAAAoACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAGDAAAAAAAAAA gAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAFzAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAA AACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAEzAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA 1AAAAAAgAJgAAiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAEAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAABEwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAARMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAETAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAABEwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAA IACpAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAA mQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAA ABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA EjAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABIw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAEjAA AAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAIAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAwAwAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAEAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAUAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAASAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAHnIADAAMAAAAAAAAAEAAAAA AAAAAAAAAAAAoAeIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAKQHecgAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAACgB4iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAApAd5yAAwADAAAAAAAAABAAAAAAAA AAAAAAAAAKAHiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACkB3nIADAAMAAAAAAAAAEAAAAAAAAA AAAAAAAAoAeIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAKQHmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAB5hAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACI0QAwCDAAAAAAAAABAAAACAAAAAkA AADcT5UHmEAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAIjRADAJMAAAAAAAAAIAAAACAAAACgAA AEwglQepQAAAADAAAAAAAAAAgAAAAIABAADQAAAAAAAAqUAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAJlAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAcAqkBwAAAAACAAAAKAAAADsAAAA8AAAAPQAAAGYA AAB9AAAAfgAAAH8AAACAAAAAgQAAAI4AAACgAAAAoQAAAK4AAAC6AAAAzwAAANAAAADiAAAA4wAA AOsAAAAGAQAABwEAAA4BAABmAQAAZwEAAHkBAAB6AQAAiQEAAIsBAACMAQAAnAEAAJ4BAACfAQAA swEAAMIBAADDAQAAzQEAAPoBAAD7AQAABQIAAAkCAAAKAgAAEwIAAEMCAADWAgAA1wIAANgCAADZ AgAA5gIAAKQEAADNBgAA7wYAAAkIAAAfCAAANwgAAEoIAABdCAAAXggAAHQIAAB5CAAAgggAAMYI AADHCAAA2ggAAOAIAADpCAAAGgkAABsJAAA0CQAAOgkAAEIJAABLCQAATAkAAGAJAABmCQAAbwkA AHUJAAB2CQAAUwoAAP4MAAAUDwAAMw8AAFgSAABLFQAAeBcAAO0XAAD5FwAAyBkAAOQZAAD3HAAA AB0AAL4dAADKHQAA4h0AAPUdAAD2HQAAIR4AADQeAAA1HgAAUh4AAFMeAAABHwAAvh8AAL8fAADA HwAAxB8AAKsAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAerAAAAADAAAAAAAAAAgAAAAIABAAAA AAAAAKAHqwAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgB5sAAAAAMAAAAAAAAACAAAAAgAEAAAQA AAAAoAerIAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHqwAAAAAwAAAAAAAAAIAAAACAAQAAAAAA AACAB6sAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAerAAAAADAAAAAAAAAAgAAAAIABAAAAAAAA AKAHmwAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgB6sgAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAA oAerIAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHqwAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACA B6sAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAebAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAH qwAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgB6sAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAer AAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHmwAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgB6sA AAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAebAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAHqwAA AAAwAAAAAAAAAIAAAACAAQAAAAAAAACgB6sAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAebAAAA ADAAAAAAAAAAgAAAAIABAAAEAAAAAKAHqwAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgB6sAAAAA MAAAAAAAAACAAAAAgAEAAAAAAAAAoAebAAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAHqwAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIAerAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAHqwAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAA AAAAAACAAAAAgAEAANQAAAAAIAerAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAAABgwAAAA AAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIAerAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAHqwAAABcwAAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAA AACAAAAAgAEAANQAAAAAIAerAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIAerAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAHqwAAABMwAAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACA AAAAgAEAANQAAAAAIAerAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgB6sAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAebAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAHqwAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACAAAAA gAEAANQAAAAAIAeaAAIgADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAIgADABAAAAAAAAgAAAAIAA AAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB6sAAAARMAAAAAAAAACAAAAAgAEA ANAAAAAAIAerAAAAETAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAAABEwAAAAAAAAAIAAAACAAQAA 0AAAAAAgB6sAAAARMAAAAAAAAACAAAAAgAEAANAAAAAAIAebAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAHqwAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgB6sAAAASMAAAAAAAAACAAAAAgAEAANAA AAAAIAerAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAAABIwAAAAAAAAAIAAAACAAQAA0AAA AAAgB5sAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIAerAAAAEjAAAAAAAAAAgAAAAIABAADQAAAA ACAHqwAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgB6sAAAASMAAAAAAAAACAAAAAgAEAANAAAAAA IAerAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAHmwAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAg B6sAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIAerAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAH qwAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgB6sAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIAeb AAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAHqwAAABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgB6sA AAASMAAAAAAAAACAAAAAgAEAANAAAAAAIAerAAAAEjAAAAAAAAAAgAAAAIABAADQAAAAACAHqwAA ABIwAAAAAAAAAIAAAACAAQAA0AAAAAAgB5sAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIAeaAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAIgADACAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAiAAMAMA AAAAAACAAAAAgAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgACIAAwBAAA AAAAAIAAAACAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAIgADAFAAAA AAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAeaAAEgADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAABwoAAAAAMAAAAAAAAAAAAAAAACUwywEAAAAAAAeK0QAwADAAAAAAAAAC AAAABQAAAAAAAAAAAIAHitEAMAAwAAAAAAAAAgAAAAUAAAAAAAAAAACAB4rRADADMAAAAAAAAAEA AAAHAAAABAAAABhXEgerQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHitEAMAAwAAAAAAAAAgAA AAUAAAABAAAARACVB6tAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgAerQAAAADAAAAAAAAAAgAAA AIABAAAAAAAAAKAHm0AAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgB5pAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAgAcKAAAAADAAAAAAAAAAAAAAAAAlMMsBAAAAAAAHAAAAAAMAAAAGAAAABgAAAAkA AAAMAAAADAAAAAwAAAA/AAAAPwAAAF0AAABdAAAAywEAAM4BAAAABgAA+QkAANAMAAAGGQAANCYA AMMnAAAUAAAAHQAAACAAAAArAAAALQAAAAAGAAB+CAAAoAgAANAIAABmCQAAiwkAAMIJAAAJCgAA 1woAAF0QAAB0EAAAxhAAANoQAAAaEQAANBEAAEsRAABgEQAAdREAABQXAAACJgAAwycAABUAAAAX AAAAGAAAABkAAAAaAAAAGwAAABwAAAAeAAAAHwAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcA AAAoAAAAKQAAACoAAAAsAAAAAAYAAMInAAAWAAAAegIAALICAADUAgAACAQAAC0EAAA8BAAAiBwA AK4cAAC+HAAAwx8AABNYFP8VhBNYFP8VhBNYFP8VhA4AAAAlAAAAJwAAAM4BAAATIRT/lYAPAADw OAAAAAAABvAYAAAAAggAAAIAAAADAAAAAQAAAAEAAAAEAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3 AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAwQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAADDHwAA//8OAAAACABk AHQAYQBiAGwAZQBhAHUACgBJAG4AcwBlAHIAdABMAG8AZwBvAAQAZABuAHUAbQAFAGQAZABhAHQA ZQAHAGQAbwByAGwAYQBuAGcACABkAG0AZQBlAHQAaQBuAGcACQBkAGIAbAB1AGUAcABpAG4AawAG AGQAdABpAHQAbABlAAcAZABzAG8AdQByAGMAZQAHAGQAdABpAHQAbABlADEADQBfAFQAbwBjADIA MwA1ADAAMAA0ADEAMgA3AA0AXwBUAG8AYwAyADMANQAwADAANAAxADIAOAANAF8AVABvAGMAMgAz ADUAMAAwADQAMQAyADkADQBfAFQAbwBjADIAMwA1ADAAMAA0ADEAMwAwAAAAAAAAAAAAAAAAADwA AAB/AAAAoQAAAKEAAADQAAAA4wAAAAcBAACJAQAAnAEAALMBAAAFAgAAxB8AAAgAAAAAAAAAAQAC gwIAAoMDAAKDBAACgwUAAYIGAACBBwABggkAAYIKAAAACwAAAAwAAAANAAAAAAAAADwAAAB/AAAA oQAAANAAAADQAAAA4wAAAAcBAABnAQAAZwEAAIoBAACdAQAAwQEAAAgCAADEHwAA//8MAAAABgCd d7oYEAABAJQATwoGAJ53uhgQAAEARAQZDQYAn3e6GBEAAQCEBBkNBgCgd7oYEAABAMQEGQ0GAKF3 uhgRAAEABAUZDQYAone6GBEAAQBEBRkNBgCjd7oYEAABAIQFGQ0GAKR3uhgRAAEAxAUZDQYApXe6 GBAAAQAEBhkNBgCmd7oYEAABAEQGGQ0GAKd3uhgRAAEAhAYZDQYAqHe6GBEAAQDEBhkNIgAAALoA AAC6AAAA5AEAAOQBAAAlAgAAOwIAADsCAABMGQAAFxsAABcbAAAeGwAAxB8AAAAAAAABAAEAAAAC AAIAAAACAAMAAAACAAQAAAACAAUAAAABAAYAAAACAAcAAAACAAgAAAABAAoAAAACAAkAAAACAAsA AAACACcAAADAAAAAwAAAAOoBAADqAQAAKwIAAEECAABBAgAAUBkAAB0bAAAjGwAAIxsAAMQfAAAA AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAKAAEACQAAAAsAAAAFAAAAQgAAAAcA AAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncw6AY291bnRyeS1y ZWdpb24AgDkAAAAMAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRh Z3MFgHBsYWNlAIA9AAAAAgAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h cnR0YWdzCYBQbGFjZU5hbWUAgD0AAAABAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MJgFBsYWNlVHlwZQCAOAAAAAoAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncwSAQ2l0eQCADAAAAaSODg0AAAAADAAAAAAADAAAAAAACgAA AAAADAAAAAAACgAAAAAABwAAAAAADAAAAAAABwAAAAAADAAAAAAADAAAAAAAAgAAAAAAAQAAAAAA AAAAAFYIAABcCAAAbw0AAHMNAADgDgAA5A4AAIAYAACEGAAA9h0AAPYdAAD4HQAA+B0AAPkdAAD5 HQAA+x0AAPwdAAD+HQAA/x0AAAEeAAACHgAAwR8AAMQfAAAHABwABwAcAAcAHAAHABwABwAEAAcA BAACAAQABwAEAAcABAAHAAQABwACAAAAAAAYGgAAHBoAAPYdAAD2HQAA+B0AAPgdAAD5HQAA+R0A APsdAAD8HQAA/h0AAP8dAAABHgAAAh4AAMEfAADEHwAABwAzAAcABAAHAAQAAgAEAAcABAAHAAQA BwAEAAcAAgAAAAAAAgAAAD0AAACBAAAADgEAAGcBAADNAQAA+wEAAHkCAACzAgAA1wIAANkCAADm AgAAzQYAAO8GAAAJCAAASggAAF4IAAB2CQAAFA8AADMPAADtFwAA+RcAAMgZAADkGQAA9xwAAAAd AAC+HQAA9R0AAPYdAAD2HQAA+B0AAPgdAAD5HQAA+R0AAPsdAAD8HQAA/h0AAP8dAAABHgAAAh4A AAQeAAAeHgAAMx4AAMEfAADEHwAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAQABwAEAAIABAAHAAQABwAEAAcABAAFAAcABQAHAAIAAAAA APYdAAD2HQAA+B0AAPgdAAD5HQAA+R0AAPsdAAD8HQAA/h0AAP8dAAABHgAAAh4AAMEfAADEHwAA BwAEAAcABAACAAQABwAEAAcABAAHAAQABwACAAMAx0PDEPytYLj/D/8P/w//D/8P/w//D/8P/w8Q AF53/hzU/l5U/w//D/8P/w//D/8P/w//D/8PEADZX+AdeABO2f8P/w//D/8P/w//D/8P/w//DxAA AQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhJj+XoTQAmCEmP5vKAACAAAALgABAAAA BIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4SgBRGEmP5ehKAFYISY/odoAAAAAIhIAAACAAEALgAB AAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4RwCBGETP9ehHAIYIRM/4doAAAAAIhIAAACAAIA LgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4RACxGEmP5ehEALYISY/odoAAAAAIhIAAAC AAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4QQDhGEmP5ehBAOYISY/odoAAAAAIhI AAACAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4TgEBGETP9ehOAQYIRM/4doAAAA AIhIAAACAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4SwExGEmP5ehLATYISY/odo AAAAAIhIAAACAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4SAFhGEmP5ehIAWYISY /odoAAAAAIhIAAACAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4RQGRGETP9ehFAZ YIRM/4doAAAAAIhIAAACAAgALgBHAAAAABAKAAAAAAAAAAAAAAAAAAAAAAANGAAAD4RoARGEmP4V xgUAAWgBBl6EaAFghJj+bygAh2gAAAAAiEgAAAsAQwBPAE0AMQA2AC0ATABTAC0AAAAuAAEAAAAE kAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP6HaAAAAACISAAA AgABAC4AAQAAAAKSAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM /4doAAAAAIhIAAACAAIALgABAAAAAJABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RACxGEmP4VxgUA AUALBl6EQAtghJj+h2gAAAAAiEgAAAIAAwAuAAEAAAAEkAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAP hBAOEYSY/hXGBQABEA4GXoQQDmCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKSAQAAAAAAAAAAAAAA AAAAAAAAChgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/4doAAAAAIhIAAACAAUALgABAAAAAJAB AAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+h2gAAAAAiEgAAAIA BgAuAAEAAAAEkAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP6H aAAAAACISAAAAgAHAC4AAQAAAAKSAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EUBkRhEz/FcYFAAFQ GQZehFAZYIRM/4doAAAAAIhIAAACAAgALgABAAAAFxAAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQAt8AEAAAAXkAAAAAAA AAAAAAAAAAAAAAAAABkYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgYAUUoGAF5KBgBvKACH aAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgG XoRwCGCEmP5PSgcAUUoHAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAA FRgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAA F5AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oGAFFKBgBe SgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4TgEBGEmP4V xgUAAeAQBl6E4BBghJj+T0oHAFFKBwBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAAAA AAAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAAB ALfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9K BgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E UBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBwBRSgcAbygAh2gAAAAAiEgAAAEAp/ADAAAA2V/gHQAA AAAAAAAAAAAAAMdDwxAAAAAAAAAAAAAAAABed/4cAAAAAAAAAAAAAAAA//////////////////8D AAAAAAAAAAAA//8DAAAAEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSADKQ amEZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIA//////////////////////////// ////////////////////FgAAAAQAAAAIAAAA5QAAAAAAAAAVAAAA7wsDAHFQCgAjcSAAGyE0AGki PgBuHkIAUzZLAD1lVwCCZ18ADC9qALdBagASWncABFB8AM4zfgBSLZUAdGSfAEVxowC2DKcArn/W APgj4AB9Fe4AcxD5AAAAAAACAAAAKAAAADsAAAA8AAAAPQAAAH0AAAB+AAAAfwAAAIAAAACBAAAA oAAAAKEAAACuAAAAugAAAM8AAADQAAAA4gAAAOMAAADrAAAABgEAAAcBAAAOAQAAZgEAAGcBAAB5 AQAAegEAAIkBAACLAQAAjAEAAJwBAACeAQAAnwEAALMBAADCAQAAwwEAAM0BAAD6AQAA+wEAAAUC AAAJAgAACgIAABMCAABDAgAA1gIAANcCAADYAgAA2QIAAAkIAAAfCAAANwgAAEoIAABdCAAAXggA AHQIAAB5CAAAgggAAMYIAADHCAAA2ggAAOAIAADpCAAAGgkAABsJAAA0CQAAOgkAAEIJAABLCQAA TAkAAGAJAABmCQAAbwkAAHUJAAB2CQAA9h0AAFMeAAC+HwAAvx8AAMQfAAAAAAAAAgEAAAIBAAAC AQAAngEABAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAngEABAIB AACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAJ4BAAQCAQAAAgEAAJ4BAAQCAQAAAgEA AJ4BAAQCAQAAAgEAAJ4BAAQCAQAAAgEAAJ4BAAQCAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAACeAQAE AgEAAJYBAAQIAAAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAlgEAAAAA AAAIAAAAAgEAAJYBAAT/QA8AAQAFAgAACAIAAJQuowsBAAEABQIAAAAAAAAFAgAAAAAAAAIQAAAA AAAAAMMfAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8B AAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAIAAAARxaQAQAAAgIGAwUEBQIDBIc6ACAAAAAA AAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUB AgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAIC AgICBIc6ACAAAAAAAAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADsGkAGGBwIBBgADAQEBAQED AAAAAAAOCBAAAAAAAAAAAQAEAAAAAABTAGkAbQBTAHUAbgAAAItbU08AAEc1kAGACgICBgkEAgUI AwS/AgCg+/zHaBAAAAAAAAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcA AE8+kAGBDgILBQMCAAACAASvAgCQ+3zXCRIAAAAAAAAAAQAIAAAAAABNAGEAbABnAHUAbgAgAEcA bwB0AGgAaQBjAAAARABvAHQAdQBtAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/ AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAA AAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABAAxCIwYAPDQAuQEaAEAAAAAm3LX RvZy10aZGjtmBQAkAAAAeAQAAH4ZAAABAA8AAAAEAAMQNgAAAHgEAAB+GQAAAQAPAAAANgAAAAAA AACxJADwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABuBIkFeAC0AIGCEjQAABAAGQBkAAAA GQAAAOcdAADnHQAAAAAAAOluBukAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAEECAAAAAAgyg3EA8BAACNwDAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAASFgAAAAACfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f////3////9/aSI+ AAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAVwBMAFMAIAB0AG8AIABJAEUAUwBHACAA YQBuAGQAIABJAEUAVABGAC0AUgBBAEkAIABvAG4AIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABv AG4AIABJAFQAVQAtAFQAIABTAHAAZQBlAGMAaAAgAGEAbgBkACAAYQB1AGQAaQBvACAAYwBvAGQA aQBuAGcAIABzAHQAYQBuAGQAYQByAGQAaQBzAGEAdABpAG8AbgAAAAsAOAAsACAAOQAsACAAMQAw AC8AMQA2AAAABgBXAFAAMwAvADEANgADAEkAVABVAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAYA AAADAAAAAAAMAAEADAACAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez 2TAAAABAAgAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAAAEAAAQAAAAMAQAABQAAABwBAAAGAAAA MAEAAAcAAACkAQAACAAAALgBAAAJAAAAxAEAABIAAADQAQAACgAAAPABAAALAAAA/AEAAAwAAAAI AgAADQAAABQCAAAOAAAAIAIAAA8AAAAoAgAAEAAAADACAAATAAAAOAIAAAIAAADkBAAAHgAAAFgA AABMUyB0byBJRVNHIGFuZCBJRVRGLVJBSSBvbiBpbmZvcm1hdGlvbiBvbiBJVFUtVCBTcGVlY2gg YW5kIGF1ZGlvIGNvZGluZyBzdGFuZGFyZGlzYXRpb24AHgAAAAQAAAAAAAAAHgAAAAgAAABXUDMv MTYAAB4AAAAMAAAAOCwgOSwgMTAvMTYAHgAAAGwAAABDT00gMTYgliBMUyA3MSCWIEUgIEZvcjog R2VuZXZhLCAxMCBKdWx5IDIwMDkNRG9jdW1lbnQgZGF0ZTogDVNhdmVkIGJ5IFJBLTEwNjk2OSBh dCAxMDoyNzo1NCBvbiAxNC4wNy4yMDA5AAAeAAAADAAAAE5vcm1hbC5kb3QAAB4AAAAEAAAASVRV AB4AAAAEAAAANQAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAADYdQcFAAAA QAAAAAAWQ+vUJb8BQAAAAABihttcBMoBQAAAAAAs4wJpBMoBAwAAAAEAAAADAAAAeAQAAAMAAAB+ GQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN 1ZwuGxCTlwgAKyz5rtQBAACQAQAADgAAAAEAAAB4AAAADgAAAIAAAAAPAAAAkAAAAAQAAADEAAAA BQAAAMwAAAAGAAAA1AAAABEAAADcAAAAFwAAAOQAAAALAAAA7AAAABAAAAD0AAAAEwAAAPwAAAAW AAAABAEAAA0AAAAMAQAADAAAAHABAAACAAAA5AQAAB4AAAAIAAAASVRVLVQAAAAeAAAALAAAAElu dGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24gKElUVSkAAwAAAFNRAAADAAAANgAA AAMAAAAPAAAAAwAAAOcdAAADAAAADycLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAEAAABYAAAATFMgdG8gSUVTRyBhbmQgSUVURi1SQUkgb24gaW5mb3JtYXRpb24gb24gSVRV LVQgU3BlZWNoIGFuZCBhdWRpbyBjb2Rpbmcgc3RhbmRhcmRpc2F0aW9uAAwQAAACAAAAHgAAAAYA AABUaXRsZQADAAAAAQAAAAAAxAIAAAkAAAAAAAAAUAAAAAEAAADPAAAAAgAAANcAAAADAAAALwIA AAQAAABLAgAABQAAAFcCAAAGAAAAfwIAAAcAAACTAgAACAAAALMCAAAHAAAAAgAAAAwAAABfUElE X0hMSU5LUwADAAAABwAAAERvY251bQAEAAAACAAAAERvY2RhdGUABQAAAAoAAABEb2NvcmxhbmcA BgAAAAwAAABEb2NibHVlcGluawAHAAAACAAAAERvY2Rlc3QACAAAAAoAAABEb2NhdXRob3IAAgAA AOQEAABBAAAAUAEAABIAAAADAAAADwAkAAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAXAAAA bQBhAGkAbAB0AG8AOgB0AHMAYgBzAGcAMQA2AEAAaQB0AHUALgBpAG4AdAAAAAAAHwAAAAEAAAAA APkNAwAAAGwARwADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFgAAAG0AYQBpAGwAdABvADoA YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAAAAHwAAAAEAAAAAAPkNAwAAAEMAaQADAAAAAAAA AAMAAAAAAAAAAwAAAAUAAAAfAAAAKQAAAG0AYQBpAGwAdABvADoAYwBsAGEAdQBkAGUALgBsAGEA bQBiAGwAaQBuAEAAbwByAGEAbgBnAGUALQBmAHQAZwByAG8AdQBwAC4AYwBvAG0AAAAAAB8AAAAB AAAAAAD5DR4AAAAUAAAAQ09NIDE2IJYgTFMgNzEgliBFAAAeAAAABAAAAAAAAAAeAAAAIAAAAEVu Z2xpc2ggb25seSBPcmlnaW5hbDogRW5nbGlzaAAAHgAAAAwAAAA4LCA5LCAxMC8xNgAeAAAAGAAA AEdlbmV2YSwgMTAgSnVseSAyMDA5AAAAAB4AAAAIAAAAV1AzLzE2AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAs AAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAP7///9EAAAARQAAAEYAAABHAAAASAAA AEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAA VwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAA/v///2QAAABl AAAAZgAAAGcAAABoAAAAaQAAAGoAAAD+////bAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAP7/ ///9////dQAAAP7////+/////v//////////////////////////////////////////////UgBv AG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAoFw/EmkEygF3 AAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAC8AAACGJwAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAAAJI/AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO1wAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAawAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQA CgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --Apple-Mail-8-846830944 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-8-846830944 Content-Disposition: inline; filename=ls071-16.pdf Content-Type: application/pdf; x-unix-mode=0666; name="ls071-16.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjM5IDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDQ1MzU0L08gNDIvRSAy OTY5NC9OIDMvVCA0NDUyNy9IIFsgMTc3NiAzNzFdPj4NZW5kb2JqDSAgICAgICAgICAgICAgICAg DQp4cmVmDQozOSA3NA0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAyMTQ3IDAwMDAwIG4NCjAw MDAwMDIzMjUgMDAwMDAgbg0KMDAwMDAwMjM1OCAwMDAwMCBuDQowMDAwMDAyNTY1IDAwMDAwIG4N CjAwMDAwMDI2ODMgMDAwMDAgbg0KMDAwMDAwMjgwMCAwMDAwMCBuDQowMDAwMDAzNDIwIDAwMDAw IG4NCjAwMDAwMDM5NDkgMDAwMDAgbg0KMDAwMDAwNDQ4NCAwMDAwMCBuDQowMDAwMDA0NTI3IDAw MDAwIG4NCjAwMDAwMDQ1NzAgMDAwMDAgbg0KMDAwMDAwNDYxMyAwMDAwMCBuDQowMDAwMDA0NjU2 IDAwMDAwIG4NCjAwMDAwMDQ2OTkgMDAwMDAgbg0KMDAwMDAwNDc0MyAwMDAwMCBuDQowMDAwMDA0 Nzg3IDAwMDAwIG4NCjAwMDAwMDUwMzEgMDAwMDAgbg0KMDAwMDAwNTI2OSAwMDAwMCBuDQowMDAw MDA1MzQ1IDAwMDAwIG4NCjAwMDAwMDU5OTMgMDAwMDAgbg0KMDAwMDAwNjU1NCAwMDAwMCBuDQow MDAwMDA2OTc0IDAwMDAwIG4NCjAwMDAwMDc2MjkgMDAwMDAgbg0KMDAwMDAwNzc4MCAwMDAwMCBu DQowMDAwMDA3ODE0IDAwMDAwIG4NCjAwMDAwMDgwMjUgMDAwMDAgbg0KMDAwMDAwODY2MyAwMDAw MCBuDQowMDAwMDA5MzIzIDAwMDAwIG4NCjAwMDAwMDk5NDcgMDAwMDAgbg0KMDAwMDAxMDU0OSAw MDAwMCBuDQowMDAwMDEzMjE4IDAwMDAwIG4NCjAwMDAwMTM0NjMgMDAwMDAgbg0KMDAwMDAxNTY0 OSAwMDAwMCBuDQowMDAwMDE1ODk4IDAwMDAwIG4NCjAwMDAwMTYxODkgMDAwMDAgbg0KMDAwMDAx NjU1MSAwMDAwMCBuDQowMDAwMDE2OTE1IDAwMDAwIG4NCjAwMDAwMTcyODYgMDAwMDAgbg0KMDAw MDAxNzY2NSAwMDAwMCBuDQowMDAwMDE4MDQ5IDAwMDAwIG4NCjAwMDAwMTg0MTkgMDAwMDAgbg0K MDAwMDAxODc2MSAwMDAwMCBuDQowMDAwMDE5MTEzIDAwMDAwIG4NCjAwMDAwMTk1NzUgMDAwMDAg bg0KMDAwMDAyMDA0MSAwMDAwMCBuDQowMDAwMDIwNDgxIDAwMDAwIG4NCjAwMDAwMjA3NjkgMDAw MDAgbg0KMDAwMDAyMTExMCAwMDAwMCBuDQowMDAwMDIxNTI2IDAwMDAwIG4NCjAwMDAwMjE3Njkg MDAwMDAgbg0KMDAwMDAyMjE0NiAwMDAwMCBuDQowMDAwMDIyNjIwIDAwMDAwIG4NCjAwMDAwMjI3 NTMgMDAwMDAgbg0KMDAwMDAyMzA5MiAwMDAwMCBuDQowMDAwMDIzMjI1IDAwMDAwIG4NCjAwMDAw MjM1NjggMDAwMDAgbg0KMDAwMDAyMzcwMSAwMDAwMCBuDQowMDAwMDI0MDU1IDAwMDAwIG4NCjAw MDAwMjQ2MDYgMDAwMDAgbg0KMDAwMDAyNDkzMCAwMDAwMCBuDQowMDAwMDI1MzIyIDAwMDAwIG4N CjAwMDAwMjU1MzkgMDAwMDAgbg0KMDAwMDAyNTgxNiAwMDAwMCBuDQowMDAwMDI2MjE2IDAwMDAw IG4NCjAwMDAwMjY1MTIgMDAwMDAgbg0KMDAwMDAyNjc5MiAwMDAwMCBuDQowMDAwMDI3MTM2IDAw MDAwIG4NCjAwMDAwMjczNjcgMDAwMDAgbg0KMDAwMDAyOTMzNyAwMDAwMCBuDQowMDAwMDI5NDE2 IDAwMDAwIG4NCjAwMDAwMjk0NzYgMDAwMDAgbg0KMDAwMDAyOTUzMiAwMDAwMCBuDQowMDAwMDAx Nzc2IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMTEzL1ByZXYgNDQ1MTYvUm9vdCA0MCAwIFIv SW5mbyAzOCAwIFIvSURbPDAzNzU0MDJDMUVGQ0VEMjlCODU4NEYzNkQ1NTFCNkQwPjw4N0RFOEQz QTdCQkREQTQ2OEUwN0MyQkNGNDQyMUUzOD5dPj4NCnN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgICAg ICAgICAgIA0KMTEyIDAgb2JqPDwvTGVuZ3RoIDI3MS9FIDI3OC9GaWx0ZXIvRmxhdGVEZWNvZGUv SSAzMTAvTCAyOTQvTyAyNjIvUyAxMTQ+PnN0cmVhbQ0KeNpiYGBgYWBgX8TAzsDA48/Az4AA/Ays QFEWBo4mBoG9JkJbGBia4xhQgIxIRZKQ0qlemZ2RyocFZER2Bl1MdetXijwAkXbxgFAODEpKYWlp GRBDgICbgaH/GpB2BWIfsIgiAw8DwzrWgBCVjR/kE7gYFoDRBm5eg7NMm9IVGZvVHpQxCGxSvVSs 8slyyYErbRNuCCh6imwMEl0YLypoKvxxrbTgdP6PJuIfLok27mRzNGJzNGNzdFRIVBYr2MHvmC9Q 8F244FilgB7jxkCBAFXNB8u4AwpQ/JLHwFC4EUgzAfEtIBZiYJi+EEgLMDAwPwPSSgwMs9uh8tZA rMbAsFobSDMCkRtAgAEA19hC5Q0KZW5kc3RyZWFtDWVuZG9iag00MCAwIG9iajw8L1BhZ2VNb2Rl L1VzZU91dGxpbmVzL05hbWVzIDQxIDAgUi9PdXRsaW5lcyAxMTAgMCBSL01ldGFkYXRhIDM3IDAg Ui9QYWdlcyAzNiAwIFIvUGFnZUxheW91dC9PbmVDb2x1bW4vT3BlbkFjdGlvbltudWxsL0ZpdEgg ODUwXS9UeXBlL0NhdGFsb2cvUGFnZUxhYmVscyAzNCAwIFI+Pg1lbmRvYmoNNDEgMCBvYmo8PC9E ZXN0cyAxOCAwIFI+Pg1lbmRvYmoNNDIgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9B bm5vdHNbNDMgMCBSIDQ0IDAgUl0vUGFyZW50IDM2IDAgUi9Db250ZW50c1s1OCAwIFIgNTkgMCBS IDYwIDAgUiA2MSAwIFIgNjUgMCBSIDY2IDAgUiA2NyAwIFIgNjggMCBSXS9Sb3RhdGUgMC9NZWRp YUJveFswIDAgNTk1LjIyIDg0Ml0vUmVzb3VyY2VzIDQ1IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoN NDMgMCBvYmo8PC9SZWN0WzM0NiA0MTMgNTI1IDQyOV0vU3VidHlwZS9MaW5rL0E8PC9GIDEwOCAw IFIvUy9MYXVuY2g+Pi9DWzAgMCAwXS9IL0kvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5k b2JqDTQ0IDAgb2JqPDwvUmVjdFs1NSAzMjAgMTMwIDMzNl0vU3VidHlwZS9MaW5rL0E8PC9GIDEw OSAwIFIvUy9MYXVuY2g+Pi9DWzAgMCAwXS9IL0kvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4N ZW5kb2JqDTQ1IDAgb2JqPDwvWE9iamVjdDw8L0ltMzggNzEgMCBSL0ltMzkgNzAgMCBSL0ltNDAg NzMgMCBSL0ltNDEgNzQgMCBSL0ltNDIgNzUgMCBSL0ltNDMgNzYgMCBSL0ltNDQgNzcgMCBSL0lt NDUgNzggMCBSL0ltNDYgNzkgMCBSL0ltNDcgODAgMCBSL0ltNDggODEgMCBSL0ltNDkgODIgMCBS L0ltNTAgODMgMCBSL0ltNTEgODQgMCBSL0ltNTIgODYgMCBSL0ltNTMgODcgMCBSL0ltNTQgODkg MCBSL0ltNTUgOTAgMCBSL0ltNTYgOTEgMCBSL0ltNTcgOTIgMCBSL0ltNTggOTMgMCBSL0ltNTkg OTQgMCBSL0ltNjAgOTUgMCBSL0ltNjEgOTcgMCBSL0ltNjIgOTkgMCBSL0ltNjMgMTAxIDAgUi9J bTY0IDEwMiAwIFIvSW02NSAxMDMgMCBSL0ltNjYgMTA1IDAgUi9JbTEwNiAxMDYgMCBSL0ltMTA3 IDEwNyAwIFI+Pi9Db2xvclNwYWNlPDwvQ3M2IDYzIDAgUi9DczggNDggMCBSL0NzOSA0OSAwIFIv Q3MxMCA1MCAwIFIvQ3MxMSA1MSAwIFIvQ3MxMiA1MiAwIFIvQ3MxMyA1MyAwIFIvQ3MxNCA1NCAw IFI+Pi9Gb250PDwvVFQyIDQ2IDAgUi9UVDQgNDcgMCBSL1RUNiA2MiAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzEgNTcgMCBSPj4+Pg1lbmRvYmoN NDYgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDU1IDAgUi9MYXN0Q2hh ciAxNTAvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3 OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDAgNTAwIDMzMyAwIDAgMCAwIDAgMCA3 MjIgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzc4IDM4OSA1MDAgMCA2NjcgOTQ0IDcyMiA3Nzgg NjExIDc3OCA3MjIgNTU2IDY2NyA3MjIgMCAxMDAwIDAgMCA2NjcgMzMzIDAgMzMzIDAgMCAwIDUw MCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCA1 NTYgNTU2IDQ0NCAzODkgMzMzIDU1NiA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMF0vQmFzZUZvbnQvVGlt ZXNOZXdSb21hbixCb2xkL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlw ZS9Gb250Pj4NZW5kb2JqDTQ3IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRv ciA1NiAwIFIvTGFzdENoYXIgMTUwL1dpZHRoc1syNTAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAg NTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgMjc4IDI3OCAwIDAgMCAwIDkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgMCAzMzMg Mzg5IDAgNjExIDg4OSA3MjIgNzIyIDU1NiA3MjIgNjY3IDU1NiA2MTEgNzIyIDAgOTQ0IDAgNzIy IDAgMCAyNzggMCAwIDUwMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3 OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAw IDUwMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NDQ0IDQ0NCAwIDUwMF0vQmFzZUZvbnQvVGltZXNOZXdSb21hbi9GaXJzdENoYXIgMzIvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag00OCAwIG9ialsvSW5kZXhlZCA2 MyAwIFIgNTQgNzIgMCBSXQ1lbmRvYmoNNDkgMCBvYmpbL0luZGV4ZWQgNjMgMCBSIDY3IDg1IDAg Ul0NZW5kb2JqDTUwIDAgb2JqWy9JbmRleGVkIDYzIDAgUiA1MiA4OCAwIFJdDWVuZG9iag01MSAw IG9ialsvSW5kZXhlZCA2MyAwIFIgODkgOTYgMCBSXQ1lbmRvYmoNNTIgMCBvYmpbL0luZGV4ZWQg NjMgMCBSIDc5IDk4IDAgUl0NZW5kb2JqDTUzIDAgb2JqWy9JbmRleGVkIDYzIDAgUiA0MyAxMDAg MCBSXQ1lbmRvYmoNNTQgMCBvYmpbL0luZGV4ZWQgNjMgMCBSIDY0IDEwNCAwIFJdDWVuZG9iag01 NSAwIG9iajw8L1N0ZW1WIDE2MC9Gb250TmFtZS9UaW1lc05ld1JvbWFuLEJvbGQvRm9udFN0cmV0 Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTIxNi9Gb250QkJveFst NTU4IC0zMDcgMjAwMCAxMDI2XS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFu KS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTU0Ni9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0Fu Z2xlIDA+Pg1lbmRvYmoNNTYgMCBvYmo8PC9TdGVtViA4Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFu L0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzNC9EZXNjZW50IC0yMTYv Rm9udEJCb3hbLTU2OCAtMzA3IDIwMDAgMTAwN10vQXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVz IE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRv ci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTU3IDAgb2JqPDwvT1BNIDEvT1AgZmFsc2Uvb3AgZmFs c2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4wMj4+DWVuZG9iag01OCAwIG9iajw8L0xl bmd0aCA1NzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJZFNNj5swEL3zK+aIpcYLxuGj t1atqu019LTqgYCTuAKMwGyU/vo+22w2bYWE7LHnzXvzxk/fDimdl+hzHT3VtaCU6lNUUYKvor3g maAy4alIMqqHKKFztEt4kiQF1S229TV6iT9Zq9gu4/t4tNqMH9nP+rtDkwFN8qzMCwDWXyKXm+59 rluVAYAOZlBkZmI5z+OmZ3nckzmxgpcx2Ytie57FNCDc+KVVs3abfkuw1u3aCyu5iFUXotb4LfL1 EiK9Dul6MSMtdsNiEFTEoYYroUZLXoGQXFZZ9kBc3olXgfiArMqTEvGNjsovaFmPv1Tr15Y8jTSm 5/pHYNGayUduLOUynvX5YjmToEDPYLV6FbgfQCnANGznLi8KavwxJF113/vy97qe9U6UvCwJ99M9 yG/UnX2BehaY67HTbWNVx1BYj+6PRpMLv+puRWs7064DS1PYipZwCvCJR5bw8w05f0MWRYA+QAM1 72ILNPbGdjloO7V+bwGvFhqNpWlWrz6mxu3IhjuKVgg2p81OsPOLoXH2g+DJzAhAv7ZLMAwWlsGu FyfKqrFzAt3wTOs8mUV9oONqkfBXVZebCp7nj1P6X8fs8k5kVtNsuhVda93EhwMwbXrM7ex3oV1o X5q/g4ptbqZmtm7Ac2c72DgDvOmbh7LiIgGbf12s7r2WG9B67J2PIAEEVL1q3z2wWbdGYqK3Z7La i5n1b387PC/h55KHql/ryNWlEs8GbeQy/DDt0BudHg9lBUDxeEx/BBgANWIT7A0KZW5kc3RyZWFt DWVuZG9iag01OSAwIG9iajw8L0xlbmd0aCA0OTIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJbJNNbxMxEIbv/hVz3EXK1B/jr2MIOQS1qQBXHBCnqpGKFBBc+k/4vbz27rq7oopkO/Y88/HO 7EV58eyEUmKbSLPEnNuetDb050ldlGS2JKFa1XsSw1n+e5Ic2MiWnH13tvle4W++bzy8LyqTxi+T DxzJJTZJOypXpak81uVFDTSWH8po1rbZTidjI/tA0XvOYUYYjm3jcKp3L+rbcDqXMbIbjqPB+vk8 CqdhX07Y83Df/p33tzCxA5XjdDgepoc7rGZeH86nw5jZD/txZ2AzeZ3dTF7pYXI3GWwi0Pi9fFQ3 pSBzKhdlHFcxajntJNZxrcayXlcTajW7erSxaXG4vyPc/qXbLxQN9mMV51jUb2XomVSTMQaPxgVI bWkXIH+ocn99Rz9hhqYGdCKHFt1q9hbeyWfODteZYmubds7S41XdnK5GR/rwS32qcECyTduWOgeE QcqVSwBRKt68zKDoziXWvhlVDjGFgmHvO2dRtfELZ1ZcQLi58wunDTiUKY6jRaJx4WznMqa15/kG hzGzCD1zbuG8ZjsZvXLT5EKvKJYDhFl0EVlhsdbiX7FFT98wg1Skc75zGEm9TXPNQSHIgteZCysu 1fJkw7mlDagUstguZ28fxsvFbXlrrn2bTrqcieifAAMAURDfBQ0KZW5kc3RyZWFtDWVuZG9iag02 MCAwIG9iajw8L0xlbmd0aCAzNTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJjJM9bsMw DIV3nUInYPgjUuJaZOkYwDco0C0oev+llBMpdhCjsQcLgj896vHx/JMu6TepQFF314zxEmDL2qD1 rZqrOBREkfx1TafPa/F8npj3x3aY0LpVJZaMQoNTnFwBlfXsl1wFLihqg6PJGZAhYrlzxlnj535U C05jA6cabyjzJ7W5VSVqCbVSBieTm0d3jqHuMIIWmPDAygar9cnLDYdQLUzRwengMOpYkXVBFExX 9xeMvdZawb0WhyFSB1ff0toz7T0tdrCGHGbdOf9f65kxfK1VbtHwnZ6ChCc6/Dc6ahvZjhPgyDKN +9lhTHq4NhyBNhSeenIUyt7vRyg5bh16OHpnj5xo/Bocb/x8DAE5eNyPZ516NDy9zg0Xy20ubWbF EEqdw8phTAx1ZGp47dk86o5LypgFuTf/kj6WdFqWaF9evhPdSo4PUYX4mLd1GvJyTflPgAEAklXj VQ0KZW5kc3RyZWFtDWVuZG9iag02MSAwIG9iajw8L0xlbmd0aCA1ODYvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJbJPLbtswEEX3+opZUkDEkBRJUd6pthoo8KOx6EXrdGHYsqPCkQo/WuRH +r0lqZddFNoMCM3cew+HBPTWI6B/ewh8/cN71JoBBb33aIgJA2K+pqIswkJCFBIccxKCfvcCggkh yo5AOp2m48Vstppn40Rni7kbRyCgmPJIgJ60v1P7uysptbprlOtkPkmWk+ybTyNMUeKbJo7ckDwd 68US/O/62XrjrTfSeyM33mSsrMLgjTEXz1Rh1GmtJn7AsURf4Uu69KXRy3yKBVo0xxPfagMjxA8E ZigO7LlAjNDmgPVmBlCx6kCZikcMKwPKWKOqMeOCx31w5nin1eFYnt+gro4fllXAMKUitsREFHNL zFFyeBen8lBWm+MI2jbbQVsGDITEEUgpcXirqPrLXaOXa3G+lHXlR+gVnV/90b9MzQQOpo12woT1 hhvHa6QeIH4wzB+pBD9gRCmCnoqq+LWxp/B8PX5YcrEbnWpPcIMApAqx4MBjgbkCkw5Ohbf3Pulb iH0UFkaYM5BcYqFu90x2d2kr62aaJVlud8TekNkXd3OJTmfpXDfpAiqw+dsQlaKPJYaVz+vraVuM us3/LwmHP9OrQEP+BCb4H3i543D3agLXbAXlsPKieSHl5ViM7qUYDkNhcvdCbpxJY3o6B2iaw6WG LDXym2pnCv05WCaZWRwoq319ene7wHEct5OsJh+eWbNuG3v7tqfN8rMotm9u4Oa6K2vY1ruyOjj9 oBlmn+6AjQ7YzhfTtjntynMz1PbAXwEGAAYl+ikNCmVuZHN0cmVhbQ1lbmRvYmoNNjIgMCBvYmo8 PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDY0IDAgUi9MYXN0Q2hhciAzMi9XaWR0 aHNbMjc4XS9CYXNlRm9udC9BcmlhbCxCb2xkL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTYzIDAgb2JqWy9JQ0NCYXNlZCA2OSAwIFJdDWVu ZG9iag02NCAwIG9iajw8L1N0ZW1WIDEzMy9Gb250TmFtZS9BcmlhbCxCb2xkL0ZvbnRTdHJldGNo L05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzMi9EZXNjZW50IC0yMTEvRm9udEJCb3hbLTYy OCAtMzc2IDIwMDAgMTAxMF0vQXNjZW50IDkwNS9Gb250RmFtaWx5KEFyaWFsKS9DYXBIZWlnaHQg MC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNNjUgMCBvYmo8PC9M ZW5ndGggNTY5L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXRTy24aQRC8z1f0cTbxNvNc ZjmFYGxh2TgKE+WAc1ivB7TRPhBgJ/n7zL6J5AgJZlB3VXV1zcRaARzsjhiUAkKBwmiw1yRkyBiL wKakP/0iW3q/mq82j2vYBKFCRW3A/ffcLh+WawvBD3tHlpZoiUaANhKZAiOQeQrUcHRkRzhkQLjU aJSvUKgVFESrGKOov+fjvUHIx/ruviOfLeECmP/4Hx3hFLSKkBkmwRZk1B5eir+pjpCk56wq4VzN IAgl45qGrW4GIceomb3u4Xxor499e1oVhQsUxrQ8dyA8MqwHsR9abjlyy7E5K3fVsUguBGjO6Gq5 ub2C1dLehF/nqwFnS+eHw7F6S/K6UKnIV9pvoYXvX0BOeASFc+esDCLUdA9P9NaV7i25As7g7jX/ A4Kx+Clo0CbWqnbJIkZpvGn1kM1qa3EUAvuzLuqSELZVgx0Kp1K3U1y75CXPSjeD9WR+4dt0OhjX ZaYBXlTl2Rs+6wk6FX5dCnwtH3pGv4RpmR5OsMiT1xcH90kRGOT0OWAoqWe/4OUjLe+jKlTn+DEp UwfW5c5vLZj6ncGj/2/vLgHUiGDGpTUieoRGPVfI/ZD+fcT6Hdl9RjzbDOpQePvR0I9SgoA4AqaB S/AN/9ce9sdGfPK7xWGS/YPiNyHZ+wPweHB+S5dFEOOUJlkdnyYEi1ME6al9M3BKSyJR8i4LNbOq u7c0bVzHvHFd0Gdv+KeqsS3cnffH6vWAtZ3dU4e/AgwAGmP8kw0KZW5kc3RyZWFtDWVuZG9iag02 NiAwIG9iajw8L0xlbmd0aCA1OTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJdJNBb6Mw EIXv/Io5gtR4bQMGbqvdbaXuGWkPVQ8ETOJdake2WdR/v2M7adMqqygKCp7P772ZKauGVFAxQXgF rGmIEECJoJQysDKbs299xjhQ/OBPzWtC667DgpYwQUvoXzIKB/z2Y5ZD0f/O7vusLknLoRKcNMju atIim9RvwC7yOqgFaaCiNR5LqM8EVpLuFuBL33Ng0M/X2gKsbAUpz7pyRgINz4p0lpKmxrP9j/M9 VxRC+fkVJehdBDtP+aP21kzr6JUpaiJyXTDSYu1z/zMUV6l4x0iDYPwR1RuBB8Lu8rhl+aOH4+Bg L6WGvTXr4ejBGzCrhcF7qX1QxHhEvQth7xgWME+5Mhr8cfCwKX9UGh7vUVqX9w93+LeE0crBq6gQ YWV7gQUOjUKw3swwgJYbFvcPsBn7R+kDHFDVKWgKSnbYaSaCKVbfMtVF1iRnpSXCNjXJ/aAnGNZJ GRjNJEdwJzmqWY3DsrzCbCysTkY4p6TqrlxWb1y8MnCDt2gHOyCtlpfsQnF35epjRKyJxRiwlSMm ireerDkZJycCv+TZV0fa1K3PxnKzd9L+lVPKN1yvtPJqWM4YfNhQxmyWxWxRC24BZ9diyjQ4E+xf YVJuXJ3DhjmITZMpb/lS4PLkg1pQ57zI0WM0aaa+OwGjSxMNbtQ4W+mGG3JTN2PSX5X0MzH2cNme uAq8xFWApiKY7/9XmpU0bGmJ/ebt+0KnQNPIQWhszGRabZgUf8SZ47nEdp5NFhWpclXsOI6Xu4tv gzlZPMM/AQYAfDgcaw0KZW5kc3RyZWFtDWVuZG9iag02NyAwIG9iajw8L0xlbmd0aCA1NTUvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFNNb6MwEL3nV8zRSMWLHSDk3l2pPe2BVQ/VHhwY Gm8ojmyTqP9+x3ZI0pW6Jwxi3rwvt88rUfGyrqCA9nFV8KIoBLTdKl+O5xWzOHXowBt4an/lLbgj YrcHNfWg5l4b6EyvpzfI2j+rXAperyvIBRfVFVLeIGWAfGVnYw9wRotgBo8TvGcNU1kuWI8cIPvd Pq+KAFLfQLZXELlNII/ojtoj+D2CnjzaE05ZxbfMazMRcLamMzhD4HzDMKPhNaM/e33S/axGlxaJ hjDvHahvdOu0KUDVgWBBjwBXMj1qlZV0sHDWfk/eZDW9RYM8eaNsnOmzMKKdipxIdvx6eCDxaXt+ WX91LP8nBbGk8GbRe7UbP8DsXBBLwpUP6slGWkf2C8k3YpFyQ7iYjsRMjyM4PKFVI5m+4Q3TWS65 ZK4zFPMx0HSgkjGSl+v/VoMqYGafmyHvFQUxTz3aqD70wQwxmVSLKqj7shVNROtmS13zwT+Py/hX bQsNipK3vGnuOJY31DLJpsRTczm8EB6SWQ6OyqoQpGRmnnxyUk0fSyYR9HMkch1J9thpF02iC7Gj DNSB+ksrFq2CpsQdoUtZ52MXiyhYYP/0vf0B6RXRhy9XqGQ9tWSbQD5poQ4pajQZDTvltHtI8Q+x koZ6kK5oUiFLfifilb38XH8TNTk3jz2M+kB3paRSkA4Tj8OANsoYzDiac2Clp8HY91QHSUTkfR2q YDX8FWAAbLUnhA0KZW5kc3RyZWFtDWVuZG9iag02OCAwIG9iajw8L0xlbmd0aCA1MzMvRmlsdGVy L0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJbJNBc5swEIXv/Io9wkxQBAZsHzttD+019NT0INBiq0MQ kWS76a/vSiLG43SGGWQLvf327VPOGefFFtpL8jN1Sk9Az7f2R96CnRH7I4hJgjhJpaHXWc3qVKKx 4V/lLGS/2u9JXpJKWUNesKKG9kviRXkBbZ/kQb/w+ql1dEoYqf6KUGk2ukdrH0BRVUOy4DQccZyz 9ndS1Gy/r4Ff5cqrnF96XBDjKN7A6hcEPYA70quzaM4o4SXbpSrLy9T2eupx9gUti7iPbVsCIQ1J vlQh8KYJlXwRHmhL5jHo2yZ+y9l2wUlh2VlUitB82Ip8m6CyrDzp02rlp2DlZy2JbktuTgd4Wnyx V7zqHY9tt5GuWtVXX3mYW9pS43FkYU6Py+B6LbG3MGvjBj1S0efUIoIT3ej5aWZlcWvwqls2QReh w1FfnjNQFl5PyiFYdZiUP71ju8374dWzQfViclT5jEZRZwIuSmKwKy/3jN9HZHMfESOmQxhmTFxH xpCCO8bAdcqBESEdlR/YWj5qRGyHFCk9DBFBKr9ConJGSMxpwwagomR7/v/+eYShNAopDUUUzsIo fSKKeR6px5CmpS0aYnPf18esXpQ73rAYJD8N+pTST0ujofvwehKjcm8P0IUcFA2rb/mqq2hVRNFg R2i31yTFynTOOKvSEf8EHaO7k3VTuGMS6a48Z8sV+Nom8E+AAQDTHBgJDQplbmRzdHJlYW0NZW5k b2JqDTY5IDAgb2JqPDwvTGVuZ3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5h dGUvRGV2aWNlUkdCPj5zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkI ARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3 d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyL nl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved8 5jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZ D2e6PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRa o5NpGwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re2 0i0AjK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/Jg ccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/ UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NW rZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAd dIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflD YigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vB vrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV 6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBF CCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF 8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVB aaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gc uiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElh ujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifn A84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+ H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623 WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4 DpEOaocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4 uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUe Wz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S30 3eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauC Tgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0Cw QLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBIm WSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06h p2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc 7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdv WjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUD igfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxt pfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqG C42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/ In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW /riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCk AVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPm pFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw 6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74K voS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bM Ncy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp2 2vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp 0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4 +cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBv Ymo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCA2MC9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1hZ2VN YXNrIHRydWUvQml0c1BlckNvbXBvbmVudCAxL1dpZHRoIDExMy9EZWNvZGVQYXJtczw8L0sgLTEv Q29sdW1ucyAxMTM+Pi9IZWlnaHQgNDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCsuB4an99e1q9r2r Wr2rVhWtQ1atQw7DhuGDsODIMng4YTcGCNYPBkGkIHBhAw52JB4fc7KBYeOACACACg0KZW5kc3Ry ZWFtDWVuZG9iag03MSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIwMjAvRmlsdGVyL0Zs YXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9NYXNrIDcwIDAg Ui9XaWR0aCAxMTMvSGVpZ2h0IDQyL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIieyXz29UVRTH/QOU sDSRtTGSuHGBLkxJIJKgMcEfIRJJCMgPWRA31Y3pbGhIXWCQ8EMSSaCUSSOkQIkkShHSam0rFilC W8HR0loZaMpMEyUagp/p1x5v3nvz5r3pmw41c3Py8n7ed8/nfu8556ZStVaR1nsl89xrB1Mnv9/e 3r/rix/f3nn2qeV761u+3dtxjUsdn197eOu+C4e7hj75ahD79MKQa9wPtHT3cKAd6x3mKT965uUD 9Iw17D5HPycv/pTuuRHYlf3oWOfV41t23njshV8feTbQeHRz4dLxuk3ZzY0Tu9K9P9/O3M6bXR3N dl+/df5qhjHgCC7juN90v25jmhGCAj6dfSNYRJ41pNGRRqFaQ5o40tzUPay14zLfqh+OGG7qDjx1 CVLGwKU4y0Q4kHM47f+w99zAeJORL19/lNnkyL8+/Pyynmoe1duBtr7929MdSzYW41kMMp/s2NMV SM+MP2KcvFLf9sSSj1Zs+0w04NByqv/BTIuy9v/48x7GRCAbo8pR+uEvXPLURepSNbZGGN+LES5m hvfjtotvNZ7hdziCSPgpfy903tyDOAcfXxELpgfsuRff3dH8jV+Q8veNhtMYc8qvNafcZzDL1hz6 a7rVkCaOlBaFJ03weZ9v6cHCCycKIzL+AkmtDpldGudA2h7yHvM/KvQwDZB4WDbAcGNq6H9tfRua gaHmzkMYv6DBC3El6lJt7xikf1OpK9cFi5uEVH90wXogl2cFqs09xEmE1Pf06pDsk6Dxlw2LtpAZ JUh/dEWuZ7uHsVgSdZHS3tx2nLCsKO1SpXNo23IIB1sGW5AiGzL1HJD0yJV5dP01r+GAjBUVsVg8 XapDmazQubPGOUuD+xjx1ubU2ApvSciBR3cK8G420TKuRBVa/frkjgq8kbEcVjZSGjxrSP1IsfJ4 mlCZkVVbW93lzwmXGF5DG7BEVzfk+otkl7bHDKP/kX0YXszPFuOermIVvukHAuVlJX+TyJkXuJHv RJUj1S8/sjJAGwEp1h+IQszPsJjhOHkqwZjJNLEKQn4qX/Aa125P3sXKyEohWmXnZRHAyglXh5Rw 2mLYLiM62IjwOc5SrkwKsoRkyd/hI85qDSrLi+rseaac7E9Vox2ufqdzQ8dNLrkpc2NsshZ3B6rt pzQZca619OQI0TXW3jMWVSLA+01fmji1p/CkLZ0QFphc5Cr+FZJr9MyluijW/DJ+nMUeOC1BpKmZ oJqbuvfOB6eJoowQtiz2YikJ2tqJ8E5EbcQFi35YxRGpMgXR54u9IW7arrMSPNXgid3J5VeuS4sn x2IiVLph+UOVERJ7U9PBIVmwdLhu9f6I0ZXlzyyU5IlT8JSEjGoleKrBEwMsuyptoFjaJQcJfIGF cMnMHouneqbbiHFAm6OQYg+nWOwSj1GtHE81rYLJ/BRTuWBxE05RnZb0HfIKsGhAip0NW32rGkPx vBAH9nRFqQd4wR8ElI8YnulTVCsN04NU2UqVVckVrdKLYcNBmZQTJa+4YAVQEyTZu08BS4CFWzhb qimr8K2Aadh9Tjxns+Usm6r9t+XEAFJBeBFVZ6GAOAATMp3JLPrnfKWYEziVUqzYlqz2U9P1CTwp ERU2556nNQs1vVcy8MFN+RglB+kdYAoOHuEXl6mZPUsgYbf0dUviEP4m2mJgjzz6EglOxfwcJKOS TQMA6VAmSxRSAoqegywaIHLYAooeYIvRiRiqH6sftEFLRa7K9JrKrZsLlxaTa7Zh39+//GZWRaSi Ck+sEARO9cPEFBs9AUmZYkv+wlROcAJe7mOQ5A4vkA1dGXt+4U6BpswWDqGSOgpZBoIdffLV/NeX jOr9u1PVBftvXD3VL7ykLa3lVJxaVATskjig0pe6AnFyZLK4o4Ugzp5JMbx6itEJs8B0aKaYFLra sGjLeN2mQNGOvv4eYOEpqzpV8cSQbmffCLUrLghs3JJJeBVsmR2wYHQFFi0ETEFVJmKSt5ne4SZI 9S2Xa+vbeq6PMcLJk+ezmxv9YJGrJw5UNxSIpzZx1HXE/FVbW6UuhYJw0dqC5WVlLmhY1jMduiLE EC39Y2DXHXtBahdPpri9Y5CpVx2ocaJJAILRk8IIsBO70thDAlZjFlId0cayNYfwS3nHUzXZpWQp mOEB2RMz/ZET41+SLqmTVWN7Ij9ScCFaVr1/CwZtHhlVfVstqnLBwP5wbZzaD7BK64qHFvqsUkWW mBWrJeODkVQ/dMvnWvgr16UpokbGcu6GCPMgFSvO70/mOfGLluBA7AWsVl8VqaqZI0KqogtP8Xf5 +qOKb6Qei7okdOV0S+t+c9WoBISk6YoOhVEh/feJScyQimrgIIXXkJpoMWC6yYv7vCarbgUrpFbH 4vWdXH5g8NaRM5coD4hyYstRCx+8SkmoTuFRMZM76JmnvGPZh8+ZrIPHvwMjADEXKRZlQ2RIZe5i J6KSyDxgbV9Q9cJASOFpSLUH5Eh8IOJBBoM5qImBZDeEJ0mDTjd52nJigPfhZuFRDgqpqIpnGYP0 pHv1LLZWfXnKLaYjaVSxm5BqtAkiFdVERujyNKQcrUiALeotgJ0JBVUPs2rJIq3QCIVUZuJUZVuo Yzc3FmLs3amHIXnNu6a9ag1pss2D1MoDwoJbD1R7mPOsGVIrD7jUic5l1R7mfG0WCmpIk21+pNUe 0f+2/SPAANUzKBUKDQplbmRzdHJlYW0NZW5kb2JqDTcyIDAgb2JqPDwvTGVuZ3RoIDE4MC9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkApQBa/////3eJuxs3j7zH2uDo6tjj5tzm6d7n6uLq 7OTr7OPs7+Tu9Ozx8upnheEAM+2Rp/r6+vb3+Nnf6jhTnl11r7O92FlurWl8tPP09evv8KWyz8bZ 4NDe5M3d4tbk6sDW3yhEloejxrrM2kNaoam90rzT3bbQ3LHN253B2Q4riejt7/T19qS30KQMS/Kf ssPL4s/a48ja4cvc48/g6i5Mmpqvy9PY6QIMAIGhesEKDQplbmRzdHJlYW0NZW5kb2JqDTczIDAg b2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTQwL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVy Q29tcG9uZW50IDgvQ29sb3JTcGFjZSA0OCAwIFIvV2lkdGggODcvSGVpZ2h0IDMvVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCkiJtMxZFoIgAEBRSCCwCUIjNAei0Gwua/9LC+2cagO9n/d3ARwECBMyRJQy Foaj8WTaN+NdwNddCAHmUEbxQi01owgh4sOYJDJdZXmhSrO2m2LrKlfXZQzAf9hgByn+sE2j94fj 2z39srxHz5xjqbT+svhikzy73u6mjewj9WzlnGmfLwEGAL7SEdEKDQplbmRzdHJlYW0NZW5kb2Jq DTc0IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjExL0ZpbHRlci9GbGF0ZURlY29kZS9C aXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA2MyAwIFIvV2lkdGggODkvSGVpZ2h0IDEvVHlw ZS9YT2JqZWN0Pj5zdHJlYW0NCkiJunn/lYbLNCA6deX+nWcvbzx+BkRABhDde/7qwQsQevTqzZPX IPTs9Vsgev3+w/tPn8/feixt3n+X1/YhgzEyAoq833jg////v2DgPxj8QgJALtCE9qlHLILnxZau B1r97fsPoPibj5+Ahn/5+g0o4hy1MDJvLdANQBGIM4AI4jCII4Ho6sOnQPT4zfvMmi1Ac4Dss3cf nbj1EIKA3M3HrrskLePT7py0/uzJO0/3XL677cKdjWdvA9GaU7eAaMelx0C9QGd8/PwDIMAA4WbP TgoNCmVuZHN0cmVhbQ1lbmRvYmoNNzUgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyMTMv RmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9X aWR0aCA5MC9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn69etXZs0WafN+IPno1Zur D5/eePwMiO48ewlE956/evAChIBST16D0Iu37yHozcdPz16/Dcxauc+t4LGAw0MGY2R0Q8L909EL /////4UK/sPA5r03LILnAbUfPv0IyP32/cfHz5+BZgLR6/cfgOj9p89A22NL1wOV7Tl+CygOtB0o AnEYxJFABHQwEAHFl2y/4By18MSth2fvPgKSQHTs5gMgAnI3H7sO9KCGyzSgGqDItgt3gGjj2dtr Tt0CouUn7wJJy9hFdZP3AQQYAGCN0SUKDQplbmRzdHJlYW0NZW5kb2JqDTc2IDAgb2JqPDwvU3Vi dHlwZS9JbWFnZS9MZW5ndGggMjIwL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50 IDgvQ29sb3JTcGFjZSA2MyAwIFIvV2lkdGggOTEvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCkiJWrL9gnPUQovgeUs3nb/z7OXVh09vPH4GREA2EN17/urBCxC6//rTm4+fnrz7AiTh6Nev X+2Lj4XWbXkSUvaQwRgNPRZw+HT0wv///3/BAJD9+Nnb2NL1QAS0ccn2CxDxz1++fvz8+f2nz0Az X7//AEEv3r4HigAZdZP36fnMKu/cDXQbUAHQMUCHQRwJREBBCLpw7wnQI0AzgYwTtx4C0bGbD4Do 7N1Hs9afBkpl1mzRcJk2af1ZoOC2C3c2nr295tQtIFp+8i6QBIpLm/dfvP4cIMAAQyPQZAoNCmVu ZHN0cmVhbQ1lbmRvYmoNNzcgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyMjgvRmlsdGVy L0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9XaWR0aCA5 My9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIl6/+mzRfC89qlHXJKWnbpy/+rDp0B0 4/EzILrz7CUQ3Xv+6sGLV4/fvH9+/d6n+Zs+Hb0AQUDu+8fPgWj30asJ4TNOrNn7RC3oIYMxGroh 4Q5U/OvXr/9gsHTDZaB15Z27gejZ67dAkW/ff3z+8hWI3n/6DERvPn56/f4DEL14+x6CgMo+fv68 5/itwKyVEKcC3QYUhzgPyIa4GYiA3NjS9Zk1W649eXXi1kMIOnv30YFr9yGWnn/wqm7yPj2fWUAS KLjx7O01p24B0fLjYHTybkrfHq+E5UAnAQQYAJrr0rgKDQplbmRzdHJlYW0NZW5kb2JqDTc4IDAg b2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjMzL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVy Q29tcG9uZW50IDgvQ29sb3JTcGFjZSA2MyAwIFIvV2lkdGggOTQvSGVpZ2h0IDEvVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCkiJ+v//f93kfbGl62etPx2YtfLqw6cQdOPxMyC68+wlBN17/urRqzdAkSdq QXd5bW9IuAMRkA1HEMHHAg4PGYwxEVD809ELT959AVpkETxv99Gr/8Hg169fX75+A6KPnz8D0ftP IPTm46fX7z8A0Yu374Ho2eu3T16/AdoOFAcylm4675WwHGgI0Nm7ztwCIqCrgLIPXry69uQV0KnT Fp90SVoGZJ+79wzokfMPXq3ce8k5aiHQdweu3T9288GJWw/bFx+TNu8HmrDn8t01p24B0fLjILTo yE0gAhq+dMNlgAADAAnryB4KDQplbmRzdHJlYW0NZW5kb2JqDTc5IDAgb2JqPDwvU3VidHlwZS9J bWFnZS9MZW5ndGggMjE5L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29s b3JTcGFjZSA2MyAwIFIvV2lkdGggOTUvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ evT0o57PrD2X77YvPpZZs+XCvSdXHz4FohuPn0HQnWcvgejBi1dA9OTdl7cTlz9kMCYD3ZBwTwif Ud65+/X7D//////2/QcQffn6DYg+f/n68fNnIHr/6fObj5+ACiDoxdv3QPTk9RsIevQKhIDi956/ WrrpfGTeWovgeUAUmLWybvK+eWvPbD52/dSV+7vO3AL6aOXeS0DGrPWnY0vXa7hMA3rtwLX7x24+ AJJAzwIZQP8CxbOmH9x24Q4QLT9+a9GRm0C0/ORdoKBz1EKg1QABBgCxrsQZCg0KZW5kc3RyZWFt DWVuZG9iag04MCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDE5MS9GaWx0ZXIvRmxhdGVE ZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNjMgMCBSL1dpZHRoIDk2L0hlaWdo dCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIifr//39mzRYgevzmfXnnbiDj6sOncHTj8TMguvPs JRA9ePEKiB69egNkP1ELeshgTB76NH/T////v33/8fnLVwj6+PkzEL3/BEVvPn56/f4DEL14+x6C nrx+A0RAqyFuuPf8FcgNr98ApXaduQVE0xafjC1d7xy10CthuUXwPCCSNu/X85kFFAEioKeWbL9w +s7jI9fuH7h2f8/lu3DUvviYhss0IAlEG8/eXnTkJhy5JC0DGgsQYAA21sXYCg0KZW5kc3RyZWFt DWVuZG9iag04MSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIwMS9GaWx0ZXIvRmxhdGVE ZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNjMgMCBSL1dpZHRoIDk3L0hlaWdo dCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiXr09KOez6zNx64/fvM+s2ZLeefuG4+fXX34FIKA bCC68+wlEN17/urBCxB68u7Lp/mbHjIYk41e1U3/9v0HBH38/Pn9Jyh68/ETEL1+/wGIXrx9D0HP Xr998vrNo1cgBHEA0CUQJwHdBmQDEVAKyD1/6/Gey3d3H72668wtoF8i89YCuQeu3T9379nZu4+O XLt/AIyAgkC07cIdIAIy6ibvkzbvB6L2xcfWnLq16MjNuQdvAsnSpScsguc9evoRIMAAVmvRhQoN CmVuZHN0cmVhbQ1lbmRvYmoNODIgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAzMTEvRmls dGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9XaWR0 aCA5OS9IZWlnaHQgMi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6//9/eefu2NL11568uvPsZWbN FiAXyL5w78nVh08h6MbjZ0AElAWie89fPXjx6v7rT0D2c/s0IHrIYEweepXe+v7TZyD69v0HhPHm 4ycgev3+AwS9ePseiJ69fvvk9ZtHr0AIaDUEQRwDcRgEQdwJJCEuB8pOW3zSJWnZiVsPT995fOzm AyA6cu3+ATDac/kuEG27cAeOUvr2AJGez6yubZeWH7819+BNIJq5/4Z96vKlGy7/////0dOPFsHz Nh24CjQNGD51k/cBAw1uHa6AAqIn776833gAiO7y2pIdVk9CyoDo+fV7v379whNKaAEFdANyQMHd CXE2EJ29+wjIXnP4GtBrm49dxxNQG8/eBqI1p25BGH6l64FagOGz6MhNSFhlTT/oHLUQ6DyAAAMA g2mt1woNCmVuZHN0cmVhbQ1lbmRvYmoNODMgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAz MTQvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAg Ui9XaWR0aCAxMDAvSGVpZ2h0IDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ+v///9INlyPz1p69 ++jErYfXnrxqn3oktnT9hXtPIOjqw6cQdOPxszvPXkLQveevHrx4BSSfvPsCRK/SWx8yGFOCnqgF fTp64dv3H6/ff4CgF2/fQ9Cz12+fvH4DRI9evQFaCkFAqyEuAboKiOCOBCKIs4HeOf/g1a4ztyyC 563ce+n0ncfHbj44cu3+ATDac/kuBG27cGfj2dtrTt2Co0VHbgK1uOetBjLmHrw5c/+NibuuAkU2 773x5uMnr4Tlk9afBZoPDCugXdMWnwzMWok1rJCDC+Lmx2/eA9Hz6/eAnqUwuO7y2r6duBzono+f fwDDHxJQ8FAiNaCACBg+QBGgX9oXHwNykcMKElzAgEIOq+XHwejkXWDgaLhMS+nbAwyuaXuvA4Mr pnV7Zs0WgAADAGgMq40KDQplbmRzdHJlYW0NZW5kb2JqDTg0IDAgb2JqPDwvU3VidHlwZS9JbWFn ZS9MZW5ndGggMjg4L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JT cGFjZSA2MyAwIFIvV2lkdGggMTAxL0hlaWdodCAyL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiayR P0vDQBiH/TTi5OLirqM4qIt+Axe31kV0dixCh4JKXbIopa04qBWFUv+USiG0SWoSm+aamjRVLH4A H7xySEEQFJ7h7h3u/f2e081wdvmg3Hy+a3lQczrFisHkUnfqrpA0vC6YfiCxgxDcXtR+GSFePwYp zZuY+TtiJdkz3Ph9GPQHIPoxdKJY7WKvDCDDyGwSFZgWULX9pojWt06BKx3h+gvawVndztee4Pih pd2OOCpb2r2zvXc1NZ/eyT/u31ip8wYHnOhmyHxz94JdFasN0tjcWjaTq6oAKs9Pxqjjx280/R9j k0vDwwJfALw85uqXunBFF4YUXN04YUK777pwNaYLUQqMLSZyKEqXDHTB9EKmWDI/BRgAotOoIwoN CmVuZHN0cmVhbQ1lbmRvYmoNODUgMCBvYmo8PC9MZW5ndGggMjE5L0ZpbHRlci9GbGF0ZURlY29k ZT4+c3RyZWFtDQpIiQDMADP/+vr6SmCnmq/Ly9zjxtngyNrhz+DqXXWvaXy01uTq0N7k1eHl2OPm 3Obp3ufq4Ojq3+vy8sXQ2BhH4QAz5FR259fe4urszd3ih6PGRGKmxNbfwNbfvNPdttDcsc3brMra p8faosTZncHZkbrVLkyaVX608fP4w8viQ1qh7PHy6+/w7/Lzz9rjvMfa9vf48fPz8/T16O3v8p+y 7ZGn9PX2qb3SOFOe5O704+zvpbLPOV2iGzePpLfQ////5uvtuszas8bXP2WnDiuJ0dfnAgwAB6eZ IAoNCmVuZHN0cmVhbQ1lbmRvYmoNODYgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxODkv RmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDQ5IDAgUi9X aWR0aCAxMDQvSGVpZ2h0IDMvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJhM9JEoIwEAVQlCASMoiz gCCCQUCJAwoqzve/k7FcsaB8y+7/q6slqdGUAVBaaluDEOq6jhDGmBDaMbq9Gv3BkFJKRA4h0RA9 OJIVBY4nsmlZtj11HNedeZ43n/vBwvcDlYXh0sJRnLDVOuWc8Q1nFG1ZKkjGrsbekNKYkCgTNqLB Es6iqKUcjqPvnSnOi6Lo/JgnzTtf4rJUQX6tuOn8+l+GcVqdaOB+fIDvO6y6cJ+v90eAAQBgdS1D Cg0KZW5kc3RyZWFtDWVuZG9iag04NyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDI2NC9G aWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNjMgMCBSL1dp ZHRoIDEwNS9IZWlnaHQgMi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6//9/bOl6IGpffOzAtfsv 3r7/////tMUnA7NWRuatBYpjJQ+ffgRU9ujVm6sPn77/9BmihaAugiQuKSACGg605fOXr3eevQSi b99/ALl1k/dBZNEUwxmnrtwHKrv25NWRa/eP3XxgETxv0ZGbQAbQp3su3wWijWdvA4369esXmlFo ZgL9dfP+K6BRy0/edc9bLW3eD1T/6OlHr4TlQLRk+wWg+U/efQEqACrm0+7Eg+atPQMJugv3nkCC DmIdfl2UIKDj4UF34/GzL1+/AbnAoMCva/PeG8hB5xy1cNL6syduPYQE3bYLd+BBp+czC79RkNQC TGCWsYuACBikAAEGANZsV/oKDQplbmRzdHJlYW0NZW5kb2JqDTg4IDAgb2JqPDwvTGVuZ3RoIDE3 NC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkAnwBg/9PY6VFqqbHN27zT3eTu9P///2l8 tA4riZ6tzOLq7NDe5O/y8/Hz89jj5vT19kNaoaWw08DW38TW30pgp5ajycja4bbQ3Pb3+Pr6+rzH 2hs3j1yFtzhTnsPL4kRipujt71lurdXh5bO92MbZ4KzK2l11r3+xzjldooeVxOPs7+Do6s3d4neJ u0duq2qXwcvc4+zx8i5MmoejxqfJ3afH2gIMAFvhcc4KDQplbmRzdHJlYW0NZW5kb2JqDTg5IDAg b2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjI1L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVy Q29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MCAwIFIvV2lkdGggMTA2L0hlaWdodCA1L1R5cGUvWE9i amVjdD4+c3RyZWFtDQpIiXyPbVfCIACFA7qIrWmo4dqbLEJRp9Xq//+22Oo0ME8X+HLv4TznuSGE slvwyW8EpncJeNBcC8F9ms4wH5sHpHKxXD0ypug6C4YnkLwos6quGdtAhz96kg6aa9Ge1MxQjs0z moWpV4Yp9bLOgqGCzbe7ynFu2D52OhwTWPs/af5Nipya3umHFDm1+fYk2vPZqH3sdHh9gxBac+sP 5+/jVpZ8qCwXSJo/TlIuO6MU/bhwIpOiaEnXSXXp5ElANlz/3Lg5h6Hqh4EUOzFPkorSz8ipQnva Fe5LgAEAqWcbogoNCmVuZHN0cmVhbQ1lbmRvYmoNOTAgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xl bmd0aCAzMjIvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNl IDYzIDAgUi9XaWR0aCAxMDcvSGVpZ2h0IDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJjJGxSwJh GIf/g/6RoLmmhjZpiWgoCFwaamiLlrBRXIsaGoQ0OYKkJKkhiyDJyi4PpMjrTLuzsPPi0lOTW64H PnA8hd/w8t3ve473+QJBaetYJpliOSW/GZbted78anJkNOKTxEmRmvb1LZf1WsO6yeuckIb9azVb xG45YiDdvx7l9ciFPzO8kyU0nXaH66WKuRu/jyYf6z+267qCqZuW8l4j7U6X5vhs1J95evlKrVA1 2e76pRIISuH4LcOZorHs0YMq5dSm04M/EMWOoGLZ0lribmx6by6UxpK4eHCuEMEUApc30v409hIC 85pBgOCHCKUs+PzxKcKMAcqh7ashBVbrJhcLqsFfphb2gXPOCXABJEimyddhHloIJH2BbNoXyPvi YSAqk1OFwM3U08RibHJJmlk5RP6/AAMAzT92nwoNCmVuZHN0cmVhbQ1lbmRvYmoNOTEgMCBvYmo8 PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCA0L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYz IDAgUi9XaWR0aCAxL0hlaWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQrZ3+oKDQplbmRzdHJl YW0NZW5kb2JqDTkyIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTg3L0ZpbHRlci9GbGF0 ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA2MyAwIFIvV2lkdGggMTA3L0hl aWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIibIInrfoyE0g2nj2NhA9fvP+////kXlr+bQ7 8aClGy4Dld159vLqw6ftU484Ry28cO8JEAG5EAacC0Qv3oLMLO/cjd9MoDlABFT54MUriMZHr94A DZm2+CTQfIvgeUDZI9fuQyz9/OUrUCVQEL+Zm/feACo7/+DVtgt39ly+65WwvH3xMSAD6NM1p24t P3kX6PFv33/8+vWLoFGHTz8CGgVUX7/xXGjdFj2fWUDTHj39CBBgAMlHt+wKDQplbmRzdHJlYW0N ZW5kb2JqDTkzIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggNC9CaXRzUGVyQ29tcG9uZW50 IDgvQ29sb3JTcGFjZSA2MyAwIFIvV2lkdGggMS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVh bQ0Ks73YCg0KZW5kc3RyZWFtDWVuZG9iag05NCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3Ro IDE5MS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNjMg MCBSL1dpZHRoIDEwNy9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSImyCJ636MhNINp4 9vaaU7cevHj1////zJotfNqdeNC8tWeAyu49f3Xk2n2L4HnTFp+8+vApEJ29++jCvSdo6PX7D0DF dZP34TezfeoRIAKqvP/6E8Q0CLr25BWQBFrhkrQMaBfQbWsOX/vy9RtQpXPUQvxmLt1wGajs3L1n 2y7c2XP5LtCE9sXHgAygT4Fo+fFbQI9//Pzj169fBI3ac/wW0Cig+vqN57KmH5Q27w/MWnnz/iuA AAMAjVS3QwoNCmVuZHN0cmVhbQ1lbmRvYmoNOTUgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0 aCA0L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9XaWR0aCAxL0hlaWdodCAx L1R5cGUvWE9iamVjdD4+c3RyZWFtDQrT2OkKDQplbmRzdHJlYW0NZW5kb2JqDTk2IDAgb2JqPDwv TGVuZ3RoIDI4NS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkADgHx/jhTnqLE2azK2uDo 6v///1lurQ4riaWw0+zx8n6TvkNaocbZ4M3d4tDe5Ojt73eJu4eVxO+xwNbk6s/g6tzm6aWyz8PL 4rO92M7e5rbQ3Jqvy7HN26fH2p3B2fb3+Pr6+n+xzhs3j9nf6t7n6ml8tJ6tzMja4YejxtXh5cvc 4+c/Zupnhcre67rM2i5MmqS30PT19rzH2nWlyIq20ihElpKvzcTW3+br7eEAM+RUdsrU3/Hz+MDW 36fJ3YSzzzldokpgp+Ps77vF1am90uLl8Uduq1yFt0RiprzT3eLq7OQmUsisve/y8z9lp7LA1eMQ QM+Zr8nc5V11r051r5G61Zm/2FV+tMfc6WSOvGqXwQIMAE4lvl4KDQplbmRzdHJlYW0NZW5kb2Jq DTk3IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMzk5L0ZpbHRlci9GbGF0ZURlY29kZS9C aXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MSAwIFIvV2lkdGggMTA3L0hlaWdodCA4L1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIiWzRa1OCQBSA4V1aLHYhTMs0QAENRE3L0DBRyXsXK8tL/f8/ 0qozKavnI4eZd585AEKOO0J85H+O0YmAibgaSZLEUyRvd9EoOovF6WfpXLrgQQKB7e4SJVMpcKVw qqqlMzuLBNJ03cAm0DROzaLcdnONLGDnLctZx2hKCKUKxRJtiWIyJt1kEd59YlJRyhVFpanbzM7i DsHqvVs23VqNUxlVDtcdi47jOKLzwKgKXuMxLtIV/aUZVsX9CuAUhWtBRgX1dgeYhiAokFEFwBcJ sdY164lVeV6hG18/hTTDqp4tl2s1uyrwfcSo2gNgRobDVSqkkkd47DhkU3veU3ney2uJhgh5C6vk jutijEFn0N9TDUDfnUxUjVG9+xj7KxhtkQMqz/v4LE3XqZBqqnx9a7PKHLbS7K3ai6CJDWPGqmKk PsJ4vGoRckhFp0impM7capkKfuihoDZr7qkWfIZyfmEsrMqPic/zuJffpA6o6DS6S/8UBbtPtCCw VajN5zQVVun6IIr+BBgAQthEFQoNCmVuZHN0cmVhbQ1lbmRvYmoNOTggMCBvYmo8PC9MZW5ndGgg MjU1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiQDwAA//d4m7GzePR26rncHZ1uTq//// WW6tDiuJpbDTz+DqvNPdwNbfxtngydzlXXWvLkyapbLP0N7kxNbf4ursh5XE+vr66n6X4QAz5CZS yKy9x9zp5O70aXy0kq/NirbSp8famb/YkbrVp8nd2d/qf7HOhLPPTnWvOFOenq3MKESWh6PGy9zj 4OjqfpO+2OPmxoCd3Q093+vy4uXxssDVP2Wnlr3X8fP46O3v9vf4OV2izt7mttDclqPJ3ufq1eHl 6meFw8vi7PHyvMfaQ1qh09jpSmCnapfBuNLjsc3bqb3SRGKms8bX2BhH++DmdaXI9PX2AgwA9qqo aQoNCmVuZHN0cmVhbQ1lbmRvYmoNOTkgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyNDAv RmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDUyIDAgUi9X aWR0aCAxMDYvSGVpZ2h0IDQvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJXJBrV4JAFEUH8Igwg9QE lVImMobYAzEtNU3TzN79/3/Tk2bofLx73bvXuUTTdKOEsvmXCiybMsepulvbnPEdEMk8z9/d+81+ rR7gQDKC4NBtHBlGM2wh0iSI/FC0j0kljl1RUjc6nybb5twhSfeE8VOcqSacp7mql2bwJNP6uBgM jeYwbF2iK+fJ1agh2nonGo8HelbsNLm2v+JME8LZrNgJNyzt5a45FpKZ1RFuLUrpDFgq4zIyIcRq cbde3yebYqfJw4+KPcZPz8G/That13LVy6sfKzdXS3yn7ym/M6fYCPHmvn8IMABQwB+cCg0KZW5k c3RyZWFtDWVuZG9iag0xMDAgMCBvYmo8PC9MZW5ndGggMTQ3L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiQCEAHv/8fP4UWqpdaXIQ1qhlqPJ////WW6tDiuJpbDTy9zjsc3bttDcvNPdxtng XXWvLkyas73Yd4m7h5XEzt7mwNbfyKy95CZS4QAz6n6Xnq3MKESWOFOe+vr6irbSf7HOXIW3fpO+ TnWvpbLPaXy0yNrhrMrah6PGx9zpqb3S++DmhLPPOV2iAgwAWgpWawoNCmVuZHN0cmVhbQ1lbmRv YmoNMTAxIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTI0L0ZpbHRlci9GbGF0ZURlY29k ZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MyAwIFIvV2lkdGggMTA1L0hlaWdodCAz L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIibzOyxKCMBBEUQJpQDIqiRFFIUZ5Kv//f2BBSaxy7VlO L+54jPkBRxh9xNgkYkKCtmK3TyHXTSkcNOljdpqdwSNXIHmuwot7uhZFacob8/4VgrV3/4FqXXLU TTJ5x7S2Lex3iIi6fillT/fFn1J0xrwGOQowAJ0WDykKDQplbmRzdHJlYW0NZW5kb2JqDTEwMiAw IG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDI0Ny9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1Bl ckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNjMgMCBSL1dpZHRoIDEwNC9IZWlnaHQgMi9UeXBlL1hP YmplY3Q+PnN0cmVhbQ0KSInavPfG5r03XJKWTdx19dS91////4/MW8un3YkHLd1wGajsxK2Hy4/f WnMKhDaevY2Mtl24A0F7Lt+98fgZUHF55278ZrZPPQJEQJWn7zyGa4eYsPnY9SchZQ8ZjNHQq/RW oPpHTz9quEzDbzjZCOKkNx8/dW27VL/xXMvm86VLTwDFL15/DrQXiCyC5wFFrj15BVSWWbMFv2nz 1p4BKjt28wE83OAILQCB6M6zl0DFdZP3ERluJ+88RQ43SCwATV6b0YcZdJ/mb4IEXWDWSuqGmLR5 /7TFJ4GG//r1a+7Bm8BAg4SbfepyYDQBbQQIMAClpDmDCg0KZW5kc3RyZWFtDWVuZG9iag0xMDMg MCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxNDMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQ ZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9XaWR0aCAxMDIvSGVpZ2h0IDEvVHlwZS9Y T2JqZWN0Pj5zdHJlYW0NCkiJisxbG9O6/dqTV////w/MWsmn3YkHzVt7BqjswLX7i47cXH78Fhyt OYUFQcws79yN38z2qUeACKjyxK2HG8/ehiOIIUDGtgt3jjXMvctr+5DBGI6A3E/zNwF1ffv+A+gq PZ9ZQITfIoIos2YLEF2+8RJiLNCP9RvPAVHL5vMpfXsgCoDiAAEGAEwDn1MKDQplbmRzdHJlYW0N ZW5kb2JqDTEwNCAwIG9iajw8L0xlbmd0aCAyMTAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJAMMAPP+lsNM4U57P4Or///93ibsbN48oRJbA1t+ixNmnx9qnyd2sytrW5OqHlcSWo8nG2eDP ma/YGEfhADPqZ4X97/L29/i8x9ppfLQuTJoOK4lDWqHi5fHc5umWvdd/sc6zvdjk7vS40uOdwdme rczLKlftkaf74ObZ3+pZbq1KYKdRaqldda/Dy+Ls8fLf6/KEs88/ZaeHo8bx8/jO3ubT2OnH3Onz 9PXx8/Pv8vPe5+r6+vqpvdK+RnDjEEDkVHbyxdBHbqsCDAD6XIhdCg0KZW5kc3RyZWFtDWVuZG9i ag0xMDUgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxOTEvRmlsdGVyL0ZsYXRlRGVjb2Rl L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDU0IDAgUi9XaWR0aCAxMDEvSGVpZ2h0IDMv VHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJXM7bFoFAGIbh8jeaZpJtKpGKhIxNInvu/6pMo2XRs+Zo voP3l+QaKAjVSxKoGGONI5TTofGdkGFAk5ZIq90pdHtgmn3LRs4vNDBcABiOPM52xr4dwB81xGVG o5oOlZHyNuEXYDKZiko7ms34EEsNa77glolirBj/Wa9pkdhs67JrJrvUZ/ssZT5jsctYEIqKKOHD MU9P4p1XWZ5fVBHXipFcb6LSud8f0bNyzDAIPe/TkF8KvAUYAMJ5FpkKDQplbmRzdHJlYW0NZW5k b2JqDTEwNiAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDQ3L0ZpbHRlci9DQ0lUVEZheERl Y29kZS9JbWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29tcG9uZW50IDEvV2lkdGggOTMvRGVjb2RlUGFy bXM8PC9LIC0xL0NvbHVtbnMgOTM+Pi9IZWlnaHQgMzkvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCsvb 3bvv292773e2VAMbIwC+yGGpcIO2EHsED6diDt7sOnToOtOnQdOn44AIAIAKDQplbmRzdHJlYW0N ZW5kb2JqDTEwNyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDE4MDMvRmlsdGVyL0ZsYXRl RGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDYzIDAgUi9NYXNrIDEwNiAwIFIv V2lkdGggOTMvSGVpZ2h0IDM5L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiezXzYtXdRTH8f6AipZB +wiCNi2sRRQkCdWmB4giQYIeF9Km2oSuRNwUFWq0UEpNJMXSSMgUQZ3yKafMp0HHcWac0VEbnVET Q+r186Nfbndm1HTGGfD35XC5v+/vPpzz/n7OOd87c2ZzjDj+7ugZ2NzKxtuRCTQwKViaZMq4cGkM LFwVPmy8PZoQI1h697b3zZh/4coYb6cmxMAkWPq/2/DPlTHeTk2IgUkTy9ARFMh0v/h+M5XKCBad qOueJ5Tf2Hg7NSHGZcG8OQuZZlcqI1gu9g8cvuPhZipVByZMhUFGEjXLbxlpSU0stREOJz9Zikzv 429cPDUYG2+/xnkEi2K7794pyODT1ExGelBSqZFNo/0VWYr56cHzx/tPnTg90NVzsvPI6WImmX+t xbm/zrPRevVNjtTe7vufH61U6jl+km3c1nmhMq4fC9t/qI+NYow3MC7v7hauimBsZv5vKiVwgaxe ty9MgmXBiu2z5256+8Pv2cvTV7Cp763MCXvunWXVmQ/mrGVLvt3lxmBhzn/b21vFO5Yk/jPKHiaC Ydf/uWShi8PBMuOz9U9PW/rkK18mUljmLdrCFq9p/enntrWbd4t06x+HdrZ1OWZm1YbdS1btdE3I wOV2D/GooViMM2fP3RIwl/MIjWDB55pb36J/NEQEwkPPfuGIgzB37TtGMEdP9sua04ODMecx8zG3 V0+6TvR3HO3b19WDGD53PzgHH0ZsHsu8C5NY/8Ct6Jgho7ZcJjPC1lfil7JAG6Fx36SPRSEW3rqA wyXeqgHVffxEsc6+huFQrL2370DPMZafyS+Kmr2ohYQYCZk04xWxsc6spEwRzLD9OvUQEAvHwwcm z7OgPKeN6GFYGkPhFD41MrD4STORGT6k4l3C3334CPtxe1tJUvOeM9Y1J+F7fhGMr8jSr8UrdhYg qaKPvLBA+oTV4JmzDJkcY2WyWJY42VeFExRMMVFnyKORNYtaQCBFNFzAgIIOny9WbksJ4kBR7xjt uIIdhIN3PVaKTJJLFBzAAQ3Jonpwif+S3c90HCFIJSIvVvoL868nuEXg6q0CQg+SLrhECgLgXlGw p3/RJEsSeY5Xt7Z3d/95xhOUcZNZHY8au71oHqtHl1RSZNiU6d/wEAELqndYQa6aSctwIgSBl9g5 zAquQqx0mXRn87kyncuNgi0SIgyZBUJYBZfzya997bEt+ztcsONgJ+W43QOrO6WxwKIByaBChq14 66PlG/cIjQOY8EH4Fg4o2zNuJAFzlFPVflrS05EwROoubNORPVCBYlEC2WBCnEkZhk8CZ/7dtOcQ Js7xcQLLnu4+iNxuBueSU6MLJ6quCiY27aXPuZFAeJ7wkwWlL8RqxaRaVfIzDSs9K8VTc/Hk1FKi IrNf2g6D40XIkFCSSNTBFZFEOcvW/Y4MUVm40IN9dGWTR6XQLb7zmSqWbGZkU8psyqb6UEORMlu1 Wr1l7nIvOCIShdp7af8/KEMb7XjuplQMfOQXCK5PrpkUMkogFJFIZw5vO9C1s6PP0bk9g81D+ZS4 SSbpBZwhae9a/9S7NcGsm/S6BeVPenGNSeFQdlxsJDjuxT/V2GTp2tn+STRZlrxoyGlRiyrNUo6A giVkiAfbR6d+pexs2HOIisBRo5JiPrViN1yH8w2STPcKKczJ0qyLYSWcbFarTEKgCqRmhUzBwlVL QHvRSW0z48SkYiKhklwx8QKCBgJqkVQCLUvpr3xqRWxmnHjIDXcoymS0RyTgl6243Z1mXfo1c+6j MmUhTKoKKbqt2khkoharHyystsdzNOkJJsFhCTaNLJSqfTD+o/Tpyh2OiKVXluS9ASbZG9iwpdDx ChZrqvbWym+DzOZW3vr3mkxqcKpkYMnHlPna10F2ubCsbtkbMUQDCmzIKH2Nr4BdB8mJbH5t75E7 foIAdZk04zKTJZuuk4nvU4azpwVF9uFZMta7t53V+rXya1JcQ5lcGDKGkmGwOFqFJEWKcJILFtmR lpe8UCVomCkvLk7syZRG2elotCGdCwcYI5gtB44oNbA4eXXWmqpmML86k9QTTCjQxfkqKViycCkj vo9qRUbZEUiCvQqTGpyqZnhoJjthie9padMkIQp5oXKKl0v+yhoptlzKzlC9JTbO45MNDzIQYQIX IMHiyJJN1U+zkZjk3ziQXM4XRxUL8aQRD1t+JVc1Ta7CZCQs5uVvugbP83GhEXt7ZJO9brYuxexm XUkY/tIa3JIerV/LHTOC8jNJxH5oPcDyMZKcjQ1lElejQy/KfnIoFpbWKSvVk1oqNcjMmB8gI+1s h00lWDJpibNHUi4sPemm8gRIPIljhYlb/IzGnPhJNtnaoWFH5yfBOI9OCpblW9tSpS3BSJu9JpZh sYTMbY7lmv3odh7/CjAAeFR7XwoNCmVuZHN0cmVhbQ1lbmRvYmoNMTA4IDAgb2JqPDwvRihtYWls dG86Y2xhdWRlLmxhbWJsaW5Ab3JhbmdlLWZ0Z3JvdXAuY29tKS9UeXBlL0ZpbGVzcGVjPj4NZW5k b2JqDTEwOSAwIG9iajw8L0YobWFpbHRvOmNvZGVjQGlldGYub3JnKS9UeXBlL0ZpbGVzcGVjPj4N ZW5kb2JqDTExMCAwIG9iajw8L0ZpcnN0IDExMSAwIFIvQ291bnQgMS9MYXN0IDExMSAwIFI+Pg1l bmRvYmoNMTExIDAgb2JqPDwvUGFyZW50IDExMCAwIFIvRGVzdFs0MiAwIFIvWFlaIG51bGwgNzY4 IG51bGxdL1RpdGxlKExTIHRvIElFU0cgYW5kIElFVEYtUkFJIG9uIGluZm9ybWF0aW9uIG9uIElU VS1UIFNwZWVjaCBhbmQgYXVkaW8gY29kaW5nIHN0YW5kYXJkaXNhdGlvbik+Pg1lbmRvYmoNMSAw IG9iajw8L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCAzNiAwIFIvQ29udGVudHMgMyAw IFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1Jlc291cmNlcyAyIDAgUi9UeXBl L1BhZ2U+Pg1lbmRvYmoNMiAwIG9iajw8L0ZvbnQ8PC9UVDIgNDYgMCBSL1RUNCA0NyAwIFIvVFQ2 IDYyIDAgUi9UVDggMTUgMCBSL0YxIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3Rh dGU8PC9HUzEgNTcgMCBSPj4+Pg1lbmRvYmoNMyAwIG9iajw8L0xlbmd0aCAzNzkxL0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIibRXW2/cuhEG+uhfwUeqsGiJuj/m2DlpivjEwG7RB28eZIm7 VrOWtpLWjvND8nvPxyF12YvdAkUROCtpyOFcvvlmePVp4bNNd/Hb8uJquQyZz5bri4x5+JcxmWYi S1mS+SINvYAtny48trnwhOd5ki0Legqw5eWCu0wylznLf124gQjDOGEudvkBdt1c3PPrr7fMj9kv 9mXBEicWGfcdT0iOLx+Z823594tEH6XPpYcoFgkL8GjPdenQhA7V593zz8t/OC4WcNfxRcSXq9X1 V/Ph1nXcmD44ru+JkOO7JwJ+6ztuiKWx+VmtIBY+/7JYrRLzyS746Ojv4saos1qhTOLHGItYSRMr HGDtNk9xKlKELIxElNqQwXJ/iJYXUrQ+7MuqYb/ldflSlf0jxU2KKMmkDpsfJpEOG+2MZz7ff//b TyeFK9+GmIXSS9nRDkoNX+RPu21Vb0xOPOF7QXqs3Ito6bpV/96runiltViSmfT5UTCsJJ0wgM5P +DdEKLGxCEUmgRURkLobm6rRYz8ij3+retbmveroDKQ+zeLz5pCvcPWh6q+6b8YkrNPRPFoeDGfE 5gxAwl2yTyL58cPtVFvZwz4uL6IQCGZJlAkdrYj+WnWxPhCEaQSzZrIgFbF8Z5cf6B/9FemGOyTz 40gE8SAE/NK5VAaxkPJNaQaIzaVJlh0sGEw6e/JBDZ/g0hdIYuIBCPGESxnO0IUEuoETAfqh55nc ekcwoKzyFa/ztm1eHoDflTNkKAkDyQ5BQ/XKU0+rw6JQJDIGCCFL4jGNxgaOqNGiq99964GIvFTC Ab2OlvyF5KOL2q/MtwvG4wh+OIVcYql1RIo4BqgPT/ajcYPnmw0Aj+9fagw5IehJaoqQYAz9cgnG 8rmWyUQvQahinkiSpbRHZmbhtD8Q/iWteyOe6WRBOFogM7Mr41YRmMmff8I2Ujch20f9hacIJmGc BsKL6Ss0Qz7HqRUSEmdSi9O3pAank5RwOltgcXr+ZOD0PDrjBKo8g857Hnlu4pHzgM+KgyjpRQ2o cwNPm8GBZ7vMBMWPRRhn2XmYGXKJRfx/wBrq8B2sTRu0g0Om5YCVkLDGJT0KR/crg0PzRQqsRP6j OT5SPm4e8JGex0ecoruMDDckbI4RoMFmyk9EJA8xYoSEgpl0wMgbUouRUUpHzhYMGDl78tsYieSI kRMGA2T8kBjMe5PBpKWwbr9TLUClDlkszJLgHIuBHiVwFiHW3tj3QARzmHEYcwQrGcXpfwkrwoY/ 9jR9LMEqTDGV8AFamZ8eI2uaEAykhH992PfiOPwP2Q80+75BECR7ix/OC23qB+Fb7HDu1LcTD8fi cJZ4fyooGyrpuVJTQUrpX/G1k4CD91vMmwnfTryBIQKFFKaeXfw+b0xDJyDwP+R3QqtrWyml1ye8 yvSdBGcHCcbrYXYD/Mj3sutHwwCT6UieihDnSE5tY8g86jE4qetRqHeCsNN42jig4uzGUag30nw/ 7bOAGfYdU8Uo11slRp7kZEo77+SJbNilYSYNxqQxJsow2M5GIzNdzgibXzf1s2q7vK+aOt+yfIf5 uqC3juWtYv0jcUggAGyT8nuu2K6tnjAz+zxvX4/21CX2KOx8zDv2oFSNT0w9N9u9XsDWbWN2Gmi4 VjPx2TgDJydVUFRtsQeoEl7p6SXivdu9VH3xqEr23FSFghUktqYY8KM/xBNOvRlO7VyiLV5xJTaC 3S2Wf5D1w1Ehx3SvbUW1OfrGte0raDeaQ6QjmlHc0P5MGBiuHtXO+KnqHgXaN2yXF99V7xq3ZQzy OnY7m9zOjLqHvIODT3Q90UZk2gjzqsoqh+110+cP21f2+W7lCDZrD1Opef7RRGjvFEVTIvOUZfWj V3VXPStoKtVu27ziWJvKqjVtJBNxGs2iKSetkrQ+aX31IRw2DTDw2hhNOLHu+jav6r5j68boda3i w1BMI6S0qXp5rIpHq4VmglIVHXvRSKtq+lD1Vb6FA33ebuiD6lUp2FKjcW3ShipK5j6cRKZp1SUz 4dH4pbiUiAVFwJt2u0chMIDiMK9TQ2CBz0dWqxfjpp5v5l5OW0301irv9y1udxoqbfOMJs6AouI7 arvbIXCqIyNC4fvHmAbjYlex7/rGAFa1SKN5zB2ckvK6tLWJdc1OmXCg9rxTh2YpnXyYp65ZIw8N HDWOJaDv4/ydBPYMOAT7HRiooDevyTU9Yx6Yc9wNeYHsfNjtkBOUPIWK7jbkGY0J7JdJFdpGMmth 7jBTaB0mO1U94KVUXbWpkeQRknApOyGlY5fu+UgZnxc3f1xSnlTRUxVdjjm8o7JnX+ie09Btq+ts X0RB+yclNeBfnwB2LlS+RSa50pN03aPk775cg1Ggv1DlgBidU5Msyy9G9aEH8VRUsdFvOIltm67T eh7znhWg66Yo9kDQvh1oNM5G8q/qDQMQ6k7DCxzZdZrwGjQRcBBFo+mHbWFyli9ssaAuLSkCYf1L 034HJNhX3T1sGjBExDMn5mSz3teF6VlII2x/zJ/V0G7KYe7NwmgGAjNsaLp7UNqLUiFTiFvJuj2o JdcVC2iwfF9WoC3owTsiqhV2PUiksYRlFB/G9qSxtpo4Wn1Oke/yhwp2vmqChoYZP89wPiuWD50l uu1WkZe65AAuVRhrjIUAckWOxhjaT/zEwbqwyrxF5f+ivquJzWZIx3gSG7dIzfte3XMbtLG3sabd 5HX10/L9ii9uvnaA5y9WdUQaOqToUIZxJKbe9MTUSyQEtafYNkdWHwlhcH+wzyrXMchnfEqq3uoa nu0autgLhtNDEfO8tJ1io0sGVKZaTYVa1NoMsR0taPWQIXnzQG9botKYd47Hh+7wTwdti985kgdX IBYMIsV3AOhRwXKjkXwAtziRmVlCaA0EFbKeJkpzsTUGUnCWfz2g9FYPEa1lcWVZvDf9Gl2fHQh6 9vCKblV1fTVPvGBD3/Pj9/oeGsjgVgqaunN8EcAxx02QZbjXqs1+m7cgy/2uzHvUW85uaQK5Bghx oh3mssOCveeL/dMTLiwZDYo3eZ8zPdIAJrfXixvAxHR1y5W6Q40Gj/PmNBpNJH7P8z1akA5ohr6f I+IJB/MSyQI5+lQ9JOlTmzWtsoo9Ped77wDcIluHNePaw8J4OKsWw7CZyLLjhm7wDKCaaFKtrW25 6cIYmca28jR4bxgJPt3dXTL9vwTsFl+vPn+8Zrd3Hz9dso/LxedLpvrCUgpuZ9LczlyjVjNMfGRX IOzSeLjIDeMMP1LiT+Pt2Vnv3o6Qi6FEgRT+00GaqVLvdG9ClzOhmm6OMCpJKGZxeJgCeoqs6jWz lwuThNZ0CFWaoTG388hYN9CfWrOD2Xw3sP3h5RXADs7M7Qzwq/tqXanykgrX+HfAuQBXwAfi1YgA 6nAR0bUNxykOtKQyt6mhJkIResdNzPSwnQ2TnjQ78GqLC9iL2m7dUq2repg6A33BPB6K5qULZG5Q O3Sz+pPwatlt2wqi+34FlzSgCHqRkroL0iTIJi2c7NoNLd3YLBiS4MOK/r7nzMwlL/VwFwZoWead OzPnBS8Ws/6HdykqYf0HXOowEKhX5u0+GO9yRMHS+sEWfHcNbrgGIvY0LQQSf40enT44MTPQOaSv Hs0rGBZ5rIuGkLMwE7JJ3tglmEIQAC4vxtLhgEP18yf0U8qek2vV/qjK/6h64up1kJQ0RPRocpY7 FWJ559lljTmc7iUXK72dp1dOOhCPOKpfJH5JeRnWIG8HK7+6VMpkPFatauk4WxIQtAbhCk4NqyvO qcZWese729+2SBonIr8ilsUglC0+hF3LIanRwV6y3V6YeLqrChZZOooNLquiej4bfHB8lx/I54PN QgfvXcejsu4bnOskT3E1CNG1bAUXwukaQPA7ZAQpFazsM9cmdPW2Yc0z41kYCACeBBqLL63jmSXP rG2rQ57xm2rTR6VZXHmw1cXoKf9jamELTVOPUe0aNIO+OvNRKJlY8QASic7zQNk6uiKDucd+1gXk tsOzt4sG1kXyZsA0UwnLk3dRg4vNkPJoYs9C5/88zG0o6Tz5fzfGWdxGj/kzhRA390l2udLZeOQk u3Bx9jYZ95q7E6gkidVzFbAVfMLl81d1c+3v2KtfnT/T8C4vvLDrZsRQI9eHIwjBLVP58I5sPhuH orGV/ohdh2mTclfzRQj0AHHGIygpXMuhrzhQPq1BWEns53aUfROh38YyVYlyfz3628h5dzOgNauu sL5nbMbj+69/wAxHj59mUAYUv40d8VpUJw5VXxo4/zsw+6ID0oJdBlq1R0EEOQQ/XiyM+UEwYoa8 1VtfpZ6/46p/foF9yxj0NF34bm/nBIH43dIYg9kDzcjF6s2CCdvb78XKhZkz67wcIc5Zp7pRRU/l HM1g48g3HAWYKD5i4NEBkZR04u+02V9JoI5eUVUU2VPV6EadcmS2b5+jJUzT6UVQCYc8QeUV1dOE to5hqx1pVnC4BhttbmVQs6NGNG0PF0pKRsPEgrOvqagWbobpHMnAObupPKYXSygkN+uy9dJyOmH9 IlO4ZAi959bpnxrX9kVn6k/gyKeSbUrpB9bEZpdMVWv0hWheSxqp+G9HJglpH/eq6XUf/URZSSs2 EkOZ+BIFYRxFH/oGYtAVZ10c9wsz7lQ5McfNTXI0zcTgv33Gi3xuVL1WPtxdi9Q1H7b9078YIlhq qFg3fuLqkVqVDfsa+4L9o1vamvNHv8B3yjjY1TSULj/tzpUSUtkMbiuKLFyGGXWnCiG2fO4Flz68 ZZrR8nLIDvriyW2WU+1XC8b/38XVA+xXp0RfNznTDhKf/6u8Hdgt0S/UIonqIY3FdkAWejzbVzpP /DjlLThQN+muL/iYPEnkihephjyVLkK6UXurkok2wO50joGM8MhlIHShhqw0ueSS9SWypRKhuOlO 97Qi0Z/TccteQrdW4dD8nSa7sII2dpE96XgCkArJViX40m8izbiiSF8/rXo7Vr0PLC1nhZ53lSlQ IgrEVIomFnYb1A6KNzYYnNKducB0DNVLJ1rP1202uYzmIy87H7//9p8AAwCxmdhnCg0KZW5kc3Ry ZWFtDWVuZG9iag00IDAgb2JqPDwvU3RlbVYgMC9Gb250TmFtZS9UaW1lc05ld1JvbWFuLEl0YWxp Yy9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgOTgvRGVzY2VudCAtMjE2 L0ZvbnRCQm94Wy00OTggLTMwNyAxMTIwIDEwMjNdL0FzY2VudCA4OTEvRm9udEZhbWlseShUaW1l cyBOZXcgUm9tYW4pL0NhcEhlaWdodCAwL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUg LTE1Pj4NZW5kb2JqDTUgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9Bbm5vdHNbNiAw IFJdL1BhcmVudCAzNiAwIFIvQ29udGVudHMgOCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5 NS4yMiA4NDJdL1Jlc291cmNlcyA3IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNNiAwIG9iajw8L1Jl Y3RbNTUgNDExIDEzMyA0MjddL1N1YnR5cGUvTGluay9BPDwvRiAxMCAwIFIvUy9MYXVuY2g+Pi9D WzAgMCAwXS9IL0kvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTcgMCBvYmo8PC9D b2xvclNwYWNlPDwvQ3M2IDYzIDAgUj4+L0ZvbnQ8PC9UVDIgNDYgMCBSL1RUNCA0NyAwIFIvVFQ2 IDYyIDAgUi9GMSAxNCAwIFIvVFQxMCAxNyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0 YXRlPDwvR1MxIDU3IDAgUj4+Pj4NZW5kb2JqDTggMCBvYmo8PC9MZW5ndGggMjQwNS9GaWx0ZXIv RmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcV8mS28gRvfMr6lhwiBjsIO2Le7RMtGM0UnTTMQfR4QCB YhMWGgWjwKY4n+CrHf5ev8wqEGRvcoykELEUqnJ5+fLlDz/dhuLOzH5czX5YrRIRitV2thQB/i5F tFj6y4XIl6G/SIJYrO5ngbibBX4QBJFYlXwV45PDTM5FLObCW/1jNo/9JMlyMcdXYYyv3s2+yLef PoowE/8VP9+K3Mv8pQy9wI8knrwX3t9Wf5nldBSdyxdp5ucixqU7d86H5nwonfdFXq/+6s2xQM69 0E/lar1++8k++Dj35hk/8OZh4CcSzwM/lh9Db55gaWZ/1mu89kP58+16ndtHbsF7j5777+x2blds FuHHGhtGbCp+2NA8hS+ZixAZGpKh8/ES4flRmbpSRvT1ne713ohBmaFu794IU7cUtTD0I/If0Zri yztEOe9QKjHslDBD0VZFX9W/FUOtW474wl9mqf12Ph0/nf5F6q34yc+jpSgQGoSirfg+9sM3AoGc r4TplCp3ApuLYl/V2vo5j+BYklIuw/RkWzp5l9r9S12pUtyoUnspAnh/r2Ak24d9y3pbl3TH71oj 9kaJt3Oj9/ygpzSk5F/JZ0a4i9KzUCSn48LRnUqJuhXb+puqRKfrdhBFXw+7e28BTClK90IOdSkK w0FrdW9fFeOrBzU6aE/7noNFg7y5E2IpkMqyrzv20D7iQ3M57HQl1lg+qL61UEn8bHnmTT4lNnZ7 sznbRheECOdPTdumsmuUvVDtUDjo+Wl+Hp54MpY3lGSVQUCUKBqjRdfrB2CvWnu++KB7W6NRDsA+ dnvCnAWtbirVnxBn3ohebVWv2tKlr6ecUS7KohUbxTBe+mHsjJvsyng7sdV7wAuJo5xY2N3q7XAg UwetG9HUm77ojwjgT364DK2pdstLSyefQ+vzVduqb+KKfBSrXW0ucNcC9mQbIpe6yMmua2rUY6sH odvmiPPZKjinyWm4TJ+8X83iNPKzhciWKBbwY+7HiQj8jHHZq9mWqHOigziHURFWp37gCOELwcXu utkPNic4TX0rKLMhpXjEYuYD4ZeePmESo5u9zfBaKv/OF1ddh2qrS3hjYblhFLHHqZ+fk8piwp6D XvlVDaLRxkul8QKJdCK7RUOWZYQ5Qk+pKqrUha1U1JfhMFub7RF4nqWvFOwnwky33zS18VAPcqeq F4kHoSIHmEwcH+QXgJ9gOrox8Y0RB1QpMDaou74YQA/nSIUXTA+hnKqf9r4M+WQ+XXKYANBtrxRw UhGLJfLQolyrYtMon+/tfmihkW2hAYckO9UBNy2Z+JQVrMrcKn90TAr3xn0fAkWvUbq8/nwjrgjk gxk/dd17fvIpS17x6VdviWBQsHp1h/IeK6DrleESR8+gMDYNztgXDSGhU5aCln6cPZ+QBRvXD0fq dDvYhmpH+M9JhIsf1ne6qcujKCrdUZ7GWsfOz1SAREkDm6Y2A6GSkwyuNWymxpa9uH33CbsfcMnQ z/1FfGZj+gST+LRVjr33ECOogAH1b/bERrtiuGi3xnHciHre/XuwqW3TQYF7c6of155achdMCJtV zab3+oiOcWSMoaxvPqw9QUzNwUYlxq93914VRrcERi6jVrfzqiYmuPdy9KTa7hP6cfRsHwpyu01b DBrki85lWw4xzM3VL++o2l25QA+mL5dL6Px+/w1JMmhqVC+qa/QRDl+vIPsiSSXPasEw17oIeSTT CmPEBrkUY9nHiwu/Xbu8+cBekmUWQ+BxXxCcQ7nzSOipdkTy2K5O1U5bnsy/8B4Aw86UDsW907JT acud7UWBFFXF970HkQsiJHlBzUbfMxAPu5qojDsvklIdIXWY7xS3veuWPyZpoAb//6OM9PdQxth0 LUwcSj4XPSQRzElk3Tk5lsmWDWNff9X915NRr5HJk3q/gtyAGmvBEnpjVP/AXIxiVOKg902Fxv6V WjzO2kKKCacUougVGfNFHvXeFiJJgRLaYeipZa/lR2U754aqfgDLoyExJvSD6scK5e0vkZo94YA8 CIQFYcIgzGTR0hnIZdE00Oa/Kauk7BKu40zamw0NC3jW83KE0IfysNAFmVwgN3OM46B1X7THccei ZWApJxYD6J7XaJ+LvONM2iS2dLgduwCN5DvqAUUOcoCtgqhhSQ5Bc8j7DXnxiKrHCeMAWPjiE7hy eKEww0dUIknL1VZ6X9pqOnC47lEOmyMUUM0zkFOkj4rzBSF+UtvQHdZujFB7qjrCoEVGjNwQn4/w +JM4MBE6jU5YAibLeji1s8uBY5JJ4cKearWhVWwZKzZCCEgcJNebMXXBudZaTlrLhb4GwxNKmwJF mBMNiHogpVoTL2CQ1VvQylLa/yfKzYLHYXnK3RbEKYM4l4QvZPMX3Q+7+ZUbIHo7+kESwxuPwofS QjkK+55HI4xnR3FURc9DWmXLz31PIceYtkOFGPsI/RDfK/yMx9d2lkNOi8vPKFNvrEurPzyJ8jhk ITgHyiOBHEWBvJaWPo2hoCzkvkFLgQ5gOTrQYeDiesO31MPxUFkhY3OSY/Z6fpQce7RCh0Kj0t2p OVNqHzBO6r2ZIHqjxl51MWOOqnOSw/bEF+eqxE0rVrJ02hjI9YaQgf3veRLhwEMnW/0eRa/b/6jA XLpgoCK7DZXFqf9fqOipaN0I1T7UJEzUt071gyEyg/xRZa8GBAP74h83nLcmE+iGPPAIU7Y8tyyf qOh46mGD2Zi7MPtzPex9SEo3WKWZn4skTIi18oyGKztWhc+MVWEc+YsEqzN0SDtWBeLuhaGGqKd4 KGqus0w6MHXnI4x+qCu+5zwmNKENdnXdGNuoUJ6KxiKHMkSmsysQbhIcj7o31VaSPtvCs9/dwjmG 8jOEtzbora/r/Iveed3yKNew/nB1uZTU8mN53pihaMFgR7ErOn7XHcl7onyrsdGD7eoa7RCL73hV Y7creGjo1QM/dGeogyD64fCwpAmT5/g8jEft+s993asTrRN9tWBFav72Ie+bS0wTY6kya0GO//u6 tVpKjDyencI3hf9QV2pD1MKy8z9MwSSP91BvtgABkENx5LyPUwhtdIHncOJzurStaElNRfGkYG9e FXWnArZ2XQ1DUe4wuQ5/tJn9EJ59k7ujGQH/cpkPgxFB6WMEJeObke/kx7e37yi5hnghQp3Mw2AO fDCxJH6QWezwMfLvT/64UIC8LxYKV73/E2AADDbU8QoNCmVuZHN0cmVhbQ1lbmRvYmoNOSAwIG9i ajw8L1N0ZW1WIDAvRm9udE5hbWUvQXJpYWwvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQg NDAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9B c2NlbnQgOTA1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCAwL1R5cGUvRm9udERlc2NyaXB0 b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xMCAwIG9iajw8L0YobWFpbHRvOnRzYnNnMTZAaXR1 LmludCkvVHlwZS9GaWxlc3BlYz4+DWVuZG9iag0xMSAwIG9iajw8L1N1YnR5cGUvVHlwZTFDL0xl bmd0aCAyODYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJYmRgYWJgZGTkc3X2dPP11g6u zE3KzwGJqP+QYfwhzvJDlkfst8fvnb+u/WpjlWVgWP6F97sn//cAge+hgjO+rxNiYGZk5E7LSSwq yi8vykzPKHHOL6gEMxQ0kjUVDC0tTHVApDmYtASRlgZg0lzBMSU/KVUhuLK4JDW3WMEzLzm/qCC/ KLEkNUVPwTEnRwFsTLFCUWpxalEZUBDqOCBgZFjG2M7ArKC7joGFkZGFXSboex8fEP3Y+b32EOO0 HwuYp32vFf2x4NCfBWx8v/Inln2vP8y455cS857vBaI/17OlpJqrRvuvy5B49OnixZdPdZ+6XjT5 lJEhsdv/vuqmVI6/69n4Kub9NJ31O3YG23OuB9wAAQYAjUlugQoNCmVuZHN0cmVhbQ1lbmRvYmoN MTIgMCBvYmo8PC9MZW5ndGggMjI1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVSQPW/E IAyGd36Fxzt1IDC1EmK5qlKGXqvm2p0DJ0VqADlkyL8vcNFVHbDwx2O/Nj/1z33wGfg7RTtghtEH R7jElSzCFScfQEhw3ubda9bOJgEv8LAtGec+jBGUYvyjJJdMGxxexEN3BP5GDsmHCQ4X8flVAsOa 0g/OGDJ0oDU4HBk/vZp0NjMCr9hf7LIlBNl8sQ+ODpdkLJIJE4LqpAb1aDRgcP9zTN6I62i/DbFb pRRPUrMGKClF+Rdur6gd6lp3MXYlKjrb7k1OFeID3s+TYqpz62O/AgwADYxrBgoNCmVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmo8PC9EaWZmZXJlbmNlc1syL2Fycm93cmlnaHQgMTM4L21pbnVzXS9U eXBlL0VuY29kaW5nPj4NZW5kb2JqDTE0IDAgb2JqPDwvU3VidHlwZS9UeXBlMS9Gb250RGVzY3Jp cHRvciAxNiAwIFIvTGFzdENoYXIgMTM4L1dpZHRoc1s5ODcgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUw IDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUw IDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgNTQ5XS9CYXNlRm9udC9FQ0lGTUsrU3ltYm9sL0ZpcnN0Q2hhciAyL1RvVW5pY29kZSAx MiAwIFIvRW5jb2RpbmcgMTMgMCBSL1R5cGUvRm9udD4+DWVuZG9iag0xNSAwIG9iajw8L1N1YnR5 cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgNCAwIFIvTGFzdENoYXIgMTE0L1dpZHRoc1s1MDAg MCAwIDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDM4OV0vQmFzZUZvbnQvVGltZXNOZXdS b21hbixJdGFsaWMvRmlyc3RDaGFyIDk3L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0Zv bnQ+Pg1lbmRvYmoNMTYgMCBvYmo8PC9TdGVtViA4NS9Gb250TmFtZS9FQ0lGTUsrU3ltYm9sL0Zv bnRGaWxlMyAxMSAwIFIvRmxhZ3MgNC9EZXNjZW50IDAvRm9udEJCb3hbLTE4MCAtMjkzIDEwOTAg MTAxMF0vQXNjZW50IDAvQ2FwSGVpZ2h0IDAvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmds ZSAwL1N0ZW1IIDkyL0NoYXJTZXQoL3NwYWNlL2Fycm93cmlnaHQvbWludXMpPj4NZW5kb2JqDTE3 IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA5IDAgUi9MYXN0Q2hhciAz Mi9XaWR0aHNbMjc4XS9CYXNlRm9udC9BcmlhbC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0xOCAwIG9iajw8L0tpZHNbMTkgMCBSXT4+DWVu ZG9iag0xOSAwIG9iajw8L0xpbWl0c1soSW5zZXJ0TG9nbykoZHRpdGxlMSldL05hbWVzWyhJbnNl cnRMb2dvKTIwIDAgUihfVG9jMjM1MDA0MTI3KTIxIDAgUihfVG9jMjM1MDA0MTI4KTIyIDAgUihf VG9jMjM1MDA0MTI5KTIzIDAgUihfVG9jMjM1MDA0MTMwKTI0IDAgUihkYmx1ZXBpbmspMjUgMCBS KGRkYXRlKTI2IDAgUihkbWVldGluZykyNyAwIFIoZG51bSkyOCAwIFIoZG9ybGFuZykyOSAwIFIo ZHNvdXJjZSkzMCAwIFIoZHRhYmxlYXUpMzEgMCBSKGR0aXRsZSkzMiAwIFIoZHRpdGxlMSkzMyAw IFJdPj4NZW5kb2JqDTIwIDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNzY1IG51bGxdPj4NZW5k b2JqDTIxIDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNTU4IG51bGxdPj4NZW5kb2JqDTIyIDAg b2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNTM3IG51bGxdPj4NZW5kb2JqDTIzIDAgb2JqPDwvRFs0 MiAwIFIvWFlaIG51bGwgNTE4IG51bGxdPj4NZW5kb2JqDTI0IDAgb2JqPDwvRFs0MiAwIFIvWFla IG51bGwgNDc4IG51bGxdPj4NZW5kb2JqDTI1IDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNjc4 IG51bGxdPj4NZW5kb2JqDTI2IDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNzQ4IG51bGxdPj4N ZW5kb2JqDTI3IDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNjg0IG51bGxdPj4NZW5kb2JqDTI4 IDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNzcwIG51bGxdPj4NZW5kb2JqDTI5IDAgb2JqPDwv RFs0MiAwIFIvWFlaIG51bGwgNzI4IG51bGxdPj4NZW5kb2JqDTMwIDAgb2JqPDwvRFs0MiAwIFIv WFlaIG51bGwgNjQzIG51bGxdPj4NZW5kb2JqDTMxIDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwg NzY1IG51bGxdPj4NZW5kb2JqDTMyIDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNjYzIG51bGxd Pj4NZW5kb2JqDTMzIDAgb2JqPDwvRFs0MiAwIFIvWFlaIG51bGwgNjIzIG51bGxdPj4NZW5kb2Jq DTM0IDAgb2JqPDwvTnVtc1swIDM1IDAgUl0+Pg1lbmRvYmoNMzUgMCBvYmo8PC9TL0Q+Pg1lbmRv YmoNMzYgMCBvYmo8PC9Db3VudCAzL1R5cGUvUGFnZXMvS2lkc1s0MiAwIFIgMSAwIFIgNSAwIFJd Pj4NZW5kb2JqDTM3IDAgb2JqPDwvU3VidHlwZS9YTUwvTGVuZ3RoIDM4MDQvVHlwZS9NZXRhZGF0 YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEt NzAxIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAg ICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAg ICAgPHBkZjpLZXl3b3Jkcz44LCA5LCAxMC8xNjwvcGRmOktleXdvcmRzPgogICAgICAgICA8cGRm OlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDcuMC41IChXaW5kb3dzKTwvcGRmOlByb2R1Y2Vy PgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv Ij4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5JbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0 aW9uIFVuaW9uPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA5 LTA3LTE0VDE2OjM1OjMwKzAyOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhhcDpDcmVh dGVEYXRlPjIwMDktMDctMTRUMTY6MzU6MzArMDI6MDA8L3hhcDpDcmVhdGVEYXRlPgogICAgICA8 L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAg ICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAg ICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRj OnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6 bGFuZz0ieC1kZWZhdWx0Ij5MUyB0byBJRVNHIGFuZCBJRVRGLVJBSSBvbiBpbmZvcm1hdGlvbiBv biBJVFUtVCBTcGVlY2ggYW5kIGF1ZGlvIGNvZGluZyBzdGFuZGFyZGlzYXRpb248L3JkZjpsaT4K ICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6 Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+V1Az LzE2PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9y PgogICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAg ICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAgICAgPC9yZGY6 QWx0PgogICAgICAgICA8L2RjOmRlc2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4K ICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFw TU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9j dW1lbnRJRD51dWlkOjRjNTRhNWEyLTlhNTEtNDMzZS04ODYxLTQ4ZDk2NTkzMDhhZjwveGFwTU06 RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVpZDpjNjBkNmI4MS1hZDA0 LTQzNjctYTc3ZC05NWZlOWU2ZGQ0NDc8L3hhcE1NOkluc3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRl c2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVu ZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmo8PC9DcmVhdGlvbkRhdGUoRDoyMDA5MDcxNDE2MzUzMCsw MicwMCcpL1N1YmplY3QoKS9BdXRob3IoV1AzLzE2KS9DcmVhdG9yKEludGVybmF0aW9uYWwgVGVs ZWNvbW11bmljYXRpb24gVW5pb24pL0tleXdvcmRzKDgsIDksIDEwLzE2KS9Qcm9kdWNlcihBY3Jv YmF0IERpc3RpbGxlciA3LjAuNSBcKFdpbmRvd3NcKSkvTW9kRGF0ZShEOjIwMDkwNzE0MTYzNTMw KzAyJzAwJykvVGl0bGUoTFMgdG8gSUVTRyBhbmQgSUVURi1SQUkgb24gaW5mb3JtYXRpb24gb24g SVRVLVQgU3BlZWNoIGFuZCBhdWRpbyBjb2Rpbmcgc3RhbmRhcmRpc2F0aW9uKT4+DWVuZG9iag14 cmVmDQowIDM5DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMjk2OTQgMDAwMDAgbg0KMDAwMDAy OTgyNiAwMDAwMCBuDQowMDAwMDI5OTUyIDAwMDAwIG4NCjAwMDAwMzM4MTIgMDAwMDAgbg0KMDAw MDAzNDA0MiAwMDAwMCBuDQowMDAwMDM0MTg4IDAwMDAwIG4NCjAwMDAwMzQzMDMgMDAwMDAgbg0K MDAwMDAzNDQ1NiAwMDAwMCBuDQowMDAwMDM2OTMwIDAwMDAwIG4NCjAwMDAwMzcxMzMgMDAwMDAg bg0KMDAwMDAzNzE5MyAwMDAwMCBuDQowMDAwMDM3NTYzIDAwMDAwIG4NCjAwMDAwMzc4NTcgMDAw MDAgbg0KMDAwMDAzNzkyNyAwMDAwMCBuDQowMDAwMDM4NjMwIDAwMDAwIG4NCjAwMDAwMzg4Mjkg MDAwMDAgbg0KMDAwMDAzOTA0MyAwMDAwMCBuDQowMDAwMDM5MTg4IDAwMDAwIG4NCjAwMDAwMzky MjEgMDAwMDAgbg0KMDAwMDAzOTUxNCAwMDAwMCBuDQowMDAwMDM5NTYyIDAwMDAwIG4NCjAwMDAw Mzk2MTAgMDAwMDAgbg0KMDAwMDAzOTY1OCAwMDAwMCBuDQowMDAwMDM5NzA2IDAwMDAwIG4NCjAw MDAwMzk3NTQgMDAwMDAgbg0KMDAwMDAzOTgwMiAwMDAwMCBuDQowMDAwMDM5ODUwIDAwMDAwIG4N CjAwMDAwMzk4OTggMDAwMDAgbg0KMDAwMDAzOTk0NiAwMDAwMCBuDQowMDAwMDM5OTk0IDAwMDAw IG4NCjAwMDAwNDAwNDIgMDAwMDAgbg0KMDAwMDA0MDA5MCAwMDAwMCBuDQowMDAwMDQwMTM4IDAw MDAwIG4NCjAwMDAwNDAxODYgMDAwMDAgbg0KMDAwMDA0MDIyMSAwMDAwMCBuDQowMDAwMDQwMjQ1 IDAwMDAwIG4NCjAwMDAwNDAzMDkgMDAwMDAgbg0KMDAwMDA0NDE5MCAwMDAwMCBuDQp0cmFpbGVy DQo8PC9TaXplIDM5Pj4NCnN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K --Apple-Mail-8-846830944 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-8-846830944 Content-Disposition: attachment; filename="ls071_Att.1_Copy of MCSD-Database-V20081003.xls" Content-Type: application/vnd.ms-excel; x-unix-mode=0666; name="ls071_Att.1_Copy of MCSD-Database-V20081003.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA1AAAAAAAAAAA EAAA/v///wAAAAD+////AAAAANIAAADTAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAHMgzQfZwAEABgMAAOEAAgCwBMEAAgAAAOIAAABcAHAAAwAASVRVICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQwA BAABAAIAAwAGAAUAugEPAAwAAFRoaXNXb3JrYm9va5wAAgAOABkAAgAAABIAAgAAABMAAgAAAK8B AgAAALwBAgAAAD0AEgBLAJ8GeTt8GjgAAQAAAAEAhwJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3 AQIAAADaAAIAAAAxABoAyAAAAP9/kAEAAAACADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAC ADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAACADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAACADsFAUEAcgBpAGEAbAAxABoAyAABAP9/vAIAAAACADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/ kAEAAAACADsFAUEAcgBpAGEAbAAxABoAoAAAAP9/kAEAAAACADsFAUEAcgBpAGEAbAAxABoA8AAD AP9/vAIAAAACADsFAUEAcgBpAGEAbAAxABoAyAAFAP9/vAIAAAECADsFAUEAcgBpAGEAbAAxABoA yAAEAAwAkAEAAAECADsFAUEAcgBpAGEAbAAxABoAyAAEACQAkAEAAAECADsFAUEAcgBpAGEAbAAx ABoAtAABAP9/vAIAAAACADsFAUEAcgBpAGEAbAAxABoAtAAAAP9/kAEAAAACADsFAUEAcgBpAGEA bAAxABoAyAABAP9/vAIAAAACADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAACADsFAUEAcgBp AGEAbAAxABoAyAAAAAgAkAEAAAACADsFAUEAcgBpAGEAbAAxABoAyAAAAAoAkAEAAAACADsFAUEA cgBpAGEAbAAxABoAyAAEAAwAkAEAAAECADsFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAACADsF AUEAcgBpAGEAbAAxABwAoAAAAFEAkAEAAAACADsGAVQAYQBoAG8AbQBhADEAHACgAAEAUQC8AgAA AAIAOwYBVABhAGgAbwBtAGEAMQAaAMgAAAAKAJABAAAAAgA7BQFBAHIAaQBhAGwAMQAeAGgBAQA+ ALwCAAAAAgA7BwFDAGEAbQBiAHIAaQBhADEAHgAsAQEAPgC8AgAAAAIAOwcBQwBhAGwAaQBiAHIA aQAxAB4ABAEBAD4AvAIAAAACADsHAUMAYQBsAGkAYgByAGkAMQAeANwAAQA+ALwCAAAAAgA7BwFD AGEAbABpAGIAcgBpADEAHgDcAAAAEQCQAQAAAAIAOwcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAAA4A kAEAAAACADsHAUMAYQBsAGkAYgByAGkAMQAeANwAAAA8AJABAAAAAgA7BwFDAGEAbABpAGIAcgBp ADEAHgDcAAAAPgCQAQAAAAIAOwcBQwBhAGwAaQBiAHIAaQAxAB4A3AABAD8AvAIAAAACADsHAUMA YQBsAGkAYgByAGkAMQAeANwAAQA0ALwCAAAAAgA7BwFDAGEAbABpAGIAcgBpADEAHgDcAAAANACQ AQAAAAIAOwcBQwBhAGwAaQBiAHIAaQAxAB4A3AABAAkAvAIAAAACADsHAUMAYQBsAGkAYgByAGkA MQAeANwAAAAKAJABAAAAAgA7BwFDAGEAbABpAGIAcgBpADEAHgDcAAIAFwCQAQAAAAIAOwcBQwBh AGwAaQBiAHIAaQAxAB4A3AABAAgAvAIAAAACADsHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAJAJAB AAAAAgA7BwFDAGEAbABpAGIAcgBpADEAHgDcAAAACACQAQAAAAIAOwcBQwBhAGwAaQBiAHIAaQAe BCIABQAdAAAiU0ZyLiJcICMsIyMwOyJTRnIuIlwgXC0jLCMjMB4EJwAGACIAACJTRnIuIlwgIywj IzA7W1JlZF0iU0ZyLiJcIFwtIywjIzAeBCgABwAjAAAiU0ZyLiJcICMsIyMwLjAwOyJTRnIuIlwg XC0jLCMjMC4wMB4ELQAIACgAACJTRnIuIlwgIywjIzAuMDA7W1JlZF0iU0ZyLiJcIFwtIywjIzAu MDAeBEYAKgBBAABfICJTRnIuIlwgKiAjLCMjMF8gO18gIlNGci4iXCAqIFwtIywjIzBfIDtfICJT RnIuIlwgKiAiLSJfIDtfIEBfIB4ELgApACkAAF8gKiAjLCMjMF8gO18gKiBcLSMsIyMwXyA7XyAq ICItIl8gO18gQF8gHgROACwASQAAXyAiU0ZyLiJcICogIywjIzAuMDBfIDtfICJTRnIuIlwgKiBc LSMsIyMwLjAwXyA7XyAiU0ZyLiJcICogIi0iPz9fIDtfIEBfIB4ENgArADEAAF8gKiAjLCMjMC4w MF8gO18gKiBcLSMsIyMwLjAwXyA7XyAqICItIj8/XyA7XyBAXyAeBBwApAAXAAAiJCIjLCMjMF8p O1woIiQiIywjIzBcKR4EIQClABwAACIkIiMsIyMwXyk7W1JlZF1cKCIkIiMsIyMwXCkeBCIApgAd AAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwCnACIAACIkIiMsIyMwLjAwXyk7W1Jl ZF1cKCIkIiMsIyMwLjAwXCkeBDcAqAAyAABfKCIkIiogIywjIzBfKTtfKCIkIiogXCgjLCMjMFwp O18oIiQiKiAiLSJfKTtfKEBfKR4ELgCpACkAAF8oKiAjLCMjMF8pO18oKiBcKCMsIyMwXCk7Xygq ICItIl8pO18oQF8pHgQ/AKoAOgAAXygiJCIqICMsIyMwLjAwXyk7XygiJCIqIFwoIywjIzAuMDBc KTtfKCIkIiogIi0iPz9fKTtfKEBfKR4ENgCrADEAAF8oKiAjLCMjMC4wMF8pO18oKiBcKCMsIyMw LjAwXCk7XygqICItIj8/Xyk7XyhAXykeBBoArAAVAABcJCMsIyMwXyk7XChcJCMsIyMwXCkeBB8A rQAaAABcJCMsIyMwXyk7W1JlZF1cKFwkIywjIzBcKR4EIACuABsAAFwkIywjIzAuMDBfKTtcKFwk IywjIzAuMDBcKR4EJQCvACAAAFwkIywjIzAuMDBfKTtbUmVkXVwoXCQjLCMjMC4wMFwpHgQYALAA EwAAIqMiIywjIzA7XC0ioyIjLCMjMB4EHQCxABgAACKjIiMsIyMwO1tSZWRdXC0ioyIjLCMjMB4E HgCyABkAACKjIiMsIyMwLjAwO1wtIqMiIywjIzAuMDAeBCMAswAeAAAioyIjLCMjMC4wMDtbUmVk XVwtIqMiIywjIzAuMDAeBDUAtAAwAABfLSKjIiogIywjIzBfLTtcLSKjIiogIywjIzBfLTtfLSKj IiogIi0iXy07Xy1AXy0eBCwAtQAnAABfLSogIywjIzBfLTtcLSogIywjIzBfLTtfLSogIi0iXy07 Xy1AXy0eBD0AtgA4AABfLSKjIiogIywjIzAuMDBfLTtcLSKjIiogIywjIzAuMDBfLTtfLSKjIiog Ii0iPz9fLTtfLUBfLR4ENAC3AC8AAF8tKiAjLCMjMC4wMF8tO1wtKiAjLCMjMC4wMF8tO18tKiAi LSI/P18tO18tQF8tHgQzALgAFwABIwAsACMAIwAwAFwAIAAiAKwgIgA7AFwALQAjACwAIwAjADAA XAAgACIArCAiAB4EPQC5ABwAASMALAAjACMAMABcACAAIgCsICIAOwBbAFIAZQBkAF0AXAAtACMA LAAjACMAMABcACAAIgCsICIAHgQ/ALoAHQABIwAsACMAIwAwAC4AMAAwAFwAIAAiAKwgIgA7AFwA LQAjACwAIwAjADAALgAwADAAXAAgACIArCAiAB4ESQC7ACIAASMALAAjACMAMAAuADAAMABcACAA IgCsICIAOwBbAFIAZQBkAF0AXAAtACMALAAjACMAMAAuADAAMABcACAAIgCsICIAHgRxALwANgAB XwAtACoAIAAjACwAIwAjADAAXAAgACIArCAiAF8ALQA7AFwALQAqACAAIwAsACMAIwAwAFwAIAAi AKwgIgBfAC0AOwBfAC0AKgAgACIALQAiAFwAIAAiAKwgIgBfAC0AOwBfAC0AQABfAC0AHgRrAL0A MwABXwAtACoAIAAjACwAIwAjADAAXAAgAF8ArCBfAC0AOwBcAC0AKgAgACMALAAjACMAMABcACAA XwCsIF8ALQA7AF8ALQAqACAAIgAtACIAXAAgAF8ArCBfAC0AOwBfAC0AQABfAC0AHgSBAL4APgAB XwAtACoAIAAjACwAIwAjADAALgAwADAAXAAgACIArCAiAF8ALQA7AFwALQAqACAAIwAsACMAIwAw AC4AMAAwAFwAIAAiAKwgIgBfAC0AOwBfAC0AKgAgACIALQAiAD8APwBcACAAIgCsICIAXwAtADsA XwAtAEAAXwAtAB4EewC/ADsAAV8ALQAqACAAIwAsACMAIwAwAC4AMAAwAFwAIABfAKwgXwAtADsA XAAtACoAIAAjACwAIwAjADAALgAwADAAXAAgAF8ArCBfAC0AOwBfAC0AKgAgACIALQAiAD8APwBc ACAAXwCsIF8ALQA7AF8ALQBAAF8ALQAeBCQAwAAfAAAiRVVSIlwgIywjIzBfKTtcKCJFVVIiXCAj LCMjMFwpHgQpAMEAJAAAIkVVUiJcICMsIyMwXyk7W1JlZF1cKCJFVVIiXCAjLCMjMFwpHgQqAMIA JQAAIkVVUiJcICMsIyMwLjAwXyk7XCgiRVVSIlwgIywjIzAuMDBcKR4ELwDDACoAACJFVVIiXCAj LCMjMC4wMF8pO1tSZWRdXCgiRVVSIlwgIywjIzAuMDBcKR4EQwDEAD4AAF8oIkVVUiJcICogIywj IzBfKTtfKCJFVVIiXCAqIFwoIywjIzBcKTtfKCJFVVIiXCAqICItIl8pO18oQF8pHgRLAMUARgAA XygiRVVSIlwgKiAjLCMjMC4wMF8pO18oIkVVUiJcICogXCgjLCMjMC4wMFwpO18oIkVVUiJcICog Ii0iPz9fKTtfKEBfKR4EKwDGABMAASMALAAjACMAMAAiAKwgIgA7AFwALQAjACwAIwAjADAAIgCs ICIAHgQ1AMcAGAABIwAsACMAIwAwACIArCAiADsAWwBSAGUAZABdAFwALQAjACwAIwAjADAAIgCs ICIAHgQ3AMgAGQABIwAsACMAIwAwAC4AMAAwACIArCAiADsAXAAtACMALAAjACMAMAAuADAAMAAi AKwgIgAeBEEAyQAeAAEjACwAIwAjADAALgAwADAAIgCsICIAOwBbAFIAZQBkAF0AXAAtACMALAAj ACMAMAAuADAAMAAiAKwgIgAeBGUAygAwAAFfAC0AKgAgACMALAAjACMAMAAiAKwgIgBfAC0AOwBc AC0AKgAgACMALAAjACMAMAAiAKwgIgBfAC0AOwBfAC0AKgAgACIALQAiACIArCAiAF8ALQA7AF8A LQBAAF8ALQAeBF8AywAtAAFfAC0AKgAgACMALAAjACMAMABfAKwgXwAtADsAXAAtACoAIAAjACwA IwAjADAAXwCsIF8ALQA7AF8ALQAqACAAIgAtACIAXwCsIF8ALQA7AF8ALQBAAF8ALQAeBHUAzAA4 AAFfAC0AKgAgACMALAAjACMAMAAuADAAMAAiAKwgIgBfAC0AOwBcAC0AKgAgACMALAAjACMAMAAu ADAAMAAiAKwgIgBfAC0AOwBfAC0AKgAgACIALQAiAD8APwAiAKwgIgBfAC0AOwBfAC0AQABfAC0A HgRvAM0ANQABXwAtACoAIAAjACwAIwAjADAALgAwADAAXwCsIF8ALQA7AFwALQAqACAAIwAsACMA IwAwAC4AMAAwAF8ArCBfAC0AOwBfAC0AKgAgACIALQAiAD8APwBfAKwgXwAtADsAXwAtAEAAXwAt AB4EJADOAB8AAFskLTQwOV1kZGRkXCxcIG1tbW1cIGRkXCxcIHl5eXkeBBUAzwAQAAAiWWVzIjsi WWVzIjsiTm8iHgQaANAAFQAAIlRydWUiOyJUcnVlIjsiRmFsc2UiHgQUANEADwAAIk9uIjsiT24i OyJPZmYiHgRdANIALAABWwAkAKwgLQAyAF0AXAAgACMALAAjACMAMAAuADAAMABfACkAOwBbAFIA ZQBkAF0AXAAoAFsAJACsIC0AMgBdAFwAIAAjACwAIwAjADAALgAwADAAXAApAB4EGQDTABQAACJW cmFpIjsiVnJhaSI7IkZhdXgiHgQeANQAGQAAIkFjdGlmIjsiQWN0aWYiOyJJbmFjdGlmIh4EEQDV AAwAACMsIyMwLjAwMDAwMB4EDwDWAAoAACMsIyMwLjAwMDAeBAwA1wAHAAAjLCMjMC4w4AAUAAAA AAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1 /yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAU AAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUACcAAAD1/yAAALQAAAAAAAAA BIkg4AAUACcAAAD1/yAAALQAAAAAAAAABK8g4AAUACcAAAD1/yAAALQAAAAAAAAABJog4AAUACcA AAD1/yAAALQAAAAAAAAABIkg4AAUACcAAAD1/yAAALQAAAAAAAAABJsg4AAUACcAAAD1/yAAALQA AAAAAAAABK8g4AAUACcAAAD1/yAAALQAAAAAAAAABJYg4AAUACcAAAD1/yAAALQAAAAAAAAABJ0g 4AAUACcAAAD1/yAAALQAAAAAAAAABKsg4AAUACcAAAD1/yAAALQAAAAAAAAABJYg4AAUACcAAAD1 /yAAALQAAAAAAAAABKwg4AAUACcAAAD1/yAAALQAAAAAAAAABK8g4AAUACYAAAD1/yAAALQAAAAA AAAABLEg4AAUACYAAAD1/yAAALQAAAAAAAAABJ0g4AAUACYAAAD1/yAAALQAAAAAAAAABKsg4AAU ACYAAAD1/yAAALQAAAAAAAAABJYg4AAUACYAAAD1/yAAALQAAAAAAAAABLEg4AAUACYAAAD1/yAA ALQAAAAAAAAABK8g4AAUACYAAAD1/yAAALQAAAAAAAAABLEg4AAUACYAAAD1/yAAALQAAAAAAAAA BJMg4AAUACYAAAD1/yAAALQAAAAAAAAABJMg4AAUACYAAAD1/yAAALQAAAAAAAAABLYg4AAUACYA AAD1/yAAALQAAAAAAAAABLEg4AAUACYAAAD1/yAAALQAAAAAAAAABLUg4AAUAB8AAAD1/yAAAJQR Eb8fvx8ABIkg4AAUACAAAAD1/yAAAJQREZcLlwsABIkg4AAUAAEAqwD1/yAAAPgAAAAAAAAAAMAg 4AAUAAEAqQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAqgD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAqAD1 /yAAAPgAAAAAAAAAAMAg4AAUAB4AAAD1/yAAAJQREZcLlwsABK8g4AAUACUAAAD1/yAAANQAYQAA sRgAAMAg4AAUACQAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAsAAAD0/wAAAPQAAAAAAAAAAMAg4AAU ABsAAAD1/yAAALQAAAAAAAAABKog4AAUAAoAAAD0/wAAAPQAAAAAAAAAAMAg4AAUAB0AAAD1/yAA ALQAAAAAAAAABKsg4AAUAAYAAAD1/yAAAJwRERYLFgsABJog4AAUAAEACQD1/yAAAPgAAAAAAAAA AMAg4AAUABwAAAD1/yAAALQAAAAAAAAABK0g4AAUABcAAAD1/yAAAPQAAAAAAAAAAMAg4AAUABgA AAD1/yAAANQAUAAAgBgAAMAg4AAUABkAAAD1/yAAANQAUAAAAAsAAMAg4AAUABoAAAD1/yAAANQA IAAAgBgAAMAg4AAUABoAAAD1/yAAAPQAAAAAAAAAAMAg4AAUACEAAAD1/yAAANQAYAAAABoAAMAg 4AAUACMAAAD1/yAAAPQAAAAAAAAAAMAg4AAUACIAAAD1/yAAAJRmZr8fvx8ABLcg4AAUAAUAAAAB ACAAAAgAAAAAAAAAAMAg4AAUAAYAAAABACAAAAgAAAAAAAAAAMAg4AAUAAgAAAABACAAAAgAAAAA AAAAAMAg4AAUAAUAAAABACIAABgAAAAAAAAAAMAg4AAUAAUAAAABACEAABgAAAAAAAAAAMAg4AAU AAYAAAAJACAAAAgAAAAAAAAAAMAg4AAUAAYADgAJACAAAAwAAAAAAAAAAMAg4AAUAAYAAAABACEA ABgAAAAAAAAAAMAg4AAUAAYAAAABACIAABgAAAAAAAAAAMAg4AAUAAAAAAABACIAABAAAAAAAAAA AMAg4AAUAAUAAAABACoAABgAAAAAAAAAAMAg4AAUAAUAAAABACsAABgAAAAAAAAAAMAg4AAUAAUA AAABACkAABgAAAAAAAAAAMAg4AAUAAkAAAABACAAAAgAAAAAAAAAAMAg4AAUAAkAAAABACIAABgA AAAAAAAAAMAg4AAUAAwAAAABACEAABgAAAAAAAAAAMAg4AAUAA0AAAABACAAAAgAAAAAAAAAAMAg 4AAUAA0AAAABACIAABgAAAAAAAAAAMAg4AAUAA0AAAABACAAABgAAAAAAAAAAMAg4AAUAAEAAAAB ACAAAAgAAAAAAAAAAMAg4AAUAAYAAAABACAAABgAAAAAAAAAAMAg4AAUAAUAAAABACEAAFgAAAAA AAAAAMAg4AAUAAYAAAABACAAAEgAAAAAAAAAAMAg4AAUAAYAAAABACIAAFgAAAAAAAAAAMAg4AAU AAAAAAABACAAAEAAAAAAAAAAAMAg4AAUAAAAAAABACIAAFAAAAAAAAAAAMAg4AAUAA0AAAABACAA AFgAAAAAAAAAAMAg4AAUAAUAAAABACIAAFgAAAAAAAAAAMAg4AAUAAYAAAABACAAAEgAAAAAAAAA BA8g4AAUAAUAAAABAAsAABgAAAAAAAAAAMAg4AAUAAUAAAABAAkAABgAAAAAAAAAAMAg4AAUAAUA AAABAAoAABgAAAAAAAAAAMAg4AAUAAAAAAABAAgAABAAAAAAAAAAAMAg4AAUAAAAAAABAAAAABAA AAAAAAAAAMAg4AAUAAAAAAABAAIAABAAAAAAAAAAAMAg4AAUAAAAEAABAAIAABQAAAAAAAAAAMAg 4AAUAAAAAAABAAoAABAAAAAAAAAAAMAg4AAUAAUAAAABAAMAABgAAAAAAAAAAMAg4AAUAAUAAAAB AAEAABgAAAAAAAAAAMAg4AAUAAAAAAAJAAIAABQAAAAAAAAAAMAg4AAUAAUAAAABAAAAABgAAAAA AAAAAMAg4AAUAAYAAAABAAIAABgAAAAAAAAAAMAg4AAUAA4AAAABAAoAABgAAAAAAAAAAMAg4AAU AAUAAAABAAoAAFgAAAAAAAAAAMAg4AAUAAoAAAAxAwoAAJAAAAAAAAAAAMAg4AAUAA8AAAABAAIA ABgAAAAAAAAAAMAg4AAUAAAAAAABAAIAAFAAAAAAAAAAAMAg4AAUAAYAAAABAAoAABgAAAAAAAAA AMAg4AAUAA8AAAABAAoAABgAAAAAAAAAAMAg4AAUAAYAAAABAAIAAFgAAAAAAAAAAMAg4AAUAAYA AAABAAoAAFgAAAAAAAAAAMAg4AAUAAYAAAABAAoAAFgAAAAAAAAABA8g4AAUAAAAAAABAAoAAFAA AAAAAAAAAMAg4AAUAAYAMQAJAAIAABwAAAAAAAAAAMAg4AAUAAYAMQABAAIAABwAAAAAAAAAAMAg 4AAUAAYAAAABAAIAAFwAAAAAAAAAAMAg4AAUAA8AAwABAAIAABwAAAAAAAAAAMAg4AAUAAYAAwAB AAIAABwAAAAAAAAAAMAg4AAUAA8AAAABAAIAAFgAAAAAAAAAAMAg4AAUAAAAAAABAAAAAFAAAAAA AAAAAMAg4AAUAAYAAAABAAEAAFgAAAAAAAAAAMAg4AAUAAAAAAABACAAACAAAAAAAAAAAMAg4AAU AAAAAAABAAAAADAAAAAAAAAAAMAg4AAUAAUAAAABAAIAABgAAAAAAAAAAMAg4AAUAAAAAAABAAgA AHAAAAAAAAAAAMAg4AAUAAkAAAABACAAAEgAAAAAAAAAAMAg4AAUAAYAAAABACEAAFgAAAAAAAAA AMAg4AAUAAUAAAABACkAAFgAAAAAAAAAAMAg4AAUAAwAAAABACEAAFgAAAAAAAAAAMAg4AAUAA0A AAABACAAAEgAAAAAAAAAAMAg4AAUAA0AAAABACIAAFgAAAAAAAAAAMAg4AAUAAUAAAABACAAAEgA AAAAAAAAAMAg4AAUAAAAAAABACAAAGAAAAAAAAAAAMAg4AAUAAgAAAABACAAAEgAAAAAAAAAAMAg 4AAUAAUAAAABAAsAAFgAAAAAAAAAAMAg4AAUAAYAAAABAAkAAFgAAAAAAAAAAMAg4AAUAAYAAAAB AAAAAFgAAAAAAAAAAMAg4AAUABAAAAABAAoAAFgAAAAAAAAAAMAg4AAUABIAAAAxAwoAANgAAAAA AAAAAMAg4AAUAAYAAAABAAoAAHgAAAAAAAAAAMAg4AAUAAAAAwABAAoAAFQAAAAAAAAAAMAg4AAU AAAAAwABAAIAAFQAAAAAAAAAAMAg4AAUAAEAAwABAAIAAFwAAAAAAAAAAMAg4AAUAAAAAAABAAgA AHAREUAgQCAAAMAg4AAUAAAAAAABAAgAAFAAAAAAAAAAAMAg4AAUAAAAAAABAAkAAFAAAAAAAAAA AMAg4AAUAAYAAAABAAIAAHgAAAAAAAAAAMAg4AAUAAAAAwABAAoAAHQAAAAAAAAAAMAg4AAUAAAA AwABAAIAAHQAAAAAAAAAAMAg4AAUAAAAAAABAAoAAFQAAAAAAAAAAMAg4AAUAAAAAAABAAoAAHQA AAAAAAAAAMAg4AAUAAAAAAABAAIAAHAAAAAAAAAAAMAg4AAUAAAAAAABAAoAAHAAAAAAAAAAAMAg 4AAUAAAAAAABAAIAAFQAAAAAAAAAAMAg4AAUAAAAAAABAAIAAHQAAAAAAAAAAMAg4AAUAAAAEAAB AAoAAHQAAAAAAAAAAMAg4AAUAAUAAAABAAoAAHgAAAAAAAAAAMAg4AAUAAEAAAABACAAAEgAAAAA AAAAAMAg4AAUAAUAAAABAAkAAFgAAAAAAAAAAMAg4AAUAAYAAAABAAgAAFgAAAAAAAAAAMAg4AAU AA4AAAABAAoAAFgAAAAAAAAAAMAg4AAUAA8AAAABAAoAAFgAAAAAAAAAAMAg4AAUAAAAAwABAAgA AFQAAAAAAAAAAMAg4AAUAAUAAAABAAEAAFgAAAAAAAAAAMAg4AAUAA8AAwABAAIAAFwAAAAAAAAA AMAg4AAUAAAAAAAJAAAAAFAAAAAAAAAAAMAg4AAUAAAAAAABAAEAAFAAAAAAAAAAAMAg4AAUAAUA AAABAAAAAFgAAAAAAAAAAMAg4AAUAAEAAAABAAEAAFgAAAAAAAAAAMAg4AAUAAUAAAABACsAAFgA AAAAAAAAAMAg4AAUAAUAAAABACoAAFgAAAAAAAAAAMAg4AAUAAAAAAABACoAAFAAAAAAAAAAAMAg 4AAUAAAAAAABACoAAFQAAAAAAAAAAMAg4AAUAAAAAAAJACIAAFAAAAAAAAAAAMAg4AAUAAUAAAAB AAMAAFgAAAAAAAAAAMAg4AAUAAYAAAABACAAAEgAAAAAAAAABA0g4AAUAAUAAwABAAIAAFwAAAAA AAAAAMAg4AAUAAAA1gABAAIAAFQAAAAAAAAAAMAg4AAUAAAABAABAAoAAFQAAAAAAAAAAMAg4AAU AAUAAAABAAoAAHgQAAAgAAAAAMAg4AAUABMAAAABAAoAAHgAAAAAAAAAAMAg4AAUABMAAAABAAoA AFgAAAAAAAAAAMAg4AAUABMAAAABAAIAAHgAAAAAAAAAAMAg4AAUABMAAAABAAIAAFgAAAAAAAAA AMAg4AAUAAAAEAABAAIAAFQAAAAAAAAAAMAg4AAUAAAAAAABAAAAAHAAAAAAAAAAAMAg4AAUAAEA AAABAAIAAFgAAAAAAAAAAMAg4AAUAAAAAAAJAAIAAFAAAAAAAAAAAMAg4AAUAAAAEQABAAoAAFQA AAAAAAAAAMAg4AAUAAUAAwABAAoAAFwAAAAAAAAAAMAg4AAUABYAAwABAAIAAFwAAAAAAAAAAMAg 4AAUAAEA1wABAAIAAFwAAAAAAAAAAMAg4AAUAAAA1wABAAIAAFQAAAAAAAAAAMAg4AAUAAEAAAAB AAoAAFgAAAAAAAAAAMAg4AAUAAAAAAABACAAAEAAAAAAAAAABA0g4AAUAAgAAAABACAAAEgAAAAA AAAABA0g4AAUAAUAAAABAAoAAFgAAAAAAAAABA0g4AAUAAEAAAABAAoAAFgAAAAAAAAABA0g4AAU AAEAAAABAAIAAFgAAAAAAAAABA0g4AAUAAAAAwABAAIAAFQAAAAAAAAABA0g4AAUAAAAAAABAAIA AFAAAAAAAAAABA0g4AAUAAAAAAABAAAAAFAAAAAAAAAABA0g4AAUAAAAAAABAAgAAHAREUAgQCAA BA0g4AAUAAAAAAABAAgAAFAAAAAAAAAABA0g4AAUAAAAAAABAAkAAFAAAAAAAAAABA0g4AAUAAEA EQABAAIAAFwAAAAAAAAABA0g4AAUAAAAAwABAAoAAFQAAAAAAAAABA0g4AAUAAAAAAABAAIAAFQA AAAAAAAABA0g4AAUAAAAAAABAAoAAFQAAAAAAAAABA0g4AAUAAAAAAABAAoAAFAAAAAAAAAABA0g 4AAUAAUAAAABACAAAEgAAAAAAAAABA0g4AAUAAAAAAABACIAAFAAAAAAAAAABA0g4AAUAAAAAAAB ACAAAGAAAAAAAAAABA0g4AAUAAEAAAABACAAAEgAAAAAAAAABA0g4AAUAAEAEQABAAoAAFwAAAAA AAAABA0g4AAUAAEAAAABAAAAAFgAAAAAAAAABA0g4AAUAAAAAAABAAIAAFAAAAAAAAAABDAg4AAU AAEAAAABAAIAAFgAAAAAAAAABDAg4AAUAAAAAAABAAkAAFAAAAAAAAAAAMAg4AAUAAAAAAABAAkA AHAAEAAAACAAAMAg4AAUAAAAAAABAAkAAHAREUAgQCAAAMAg4AAUAAAAAAABAAgAAHAREUAgQCAA AMAg4AAUAAAAAAABAAEAAFAAAAAAAAAAAMAg4AAUAAYAAAABAAEAAFgAAAAAAAAAAMAgkwISABAA DQAAMjAlIC0gQWt6ZW50MZMCEgARAA0AADIwJSAtIEFremVudDKTAhIAEgANAAAyMCUgLSBBa3pl bnQzkwISABMADQAAMjAlIC0gQWt6ZW50NJMCEgAUAA0AADIwJSAtIEFremVudDWTAhIAFQANAAAy MCUgLSBBa3plbnQ2kwISABYADQAANDAlIC0gQWt6ZW50MZMCEgAXAA0AADQwJSAtIEFremVudDKT AhIAGAANAAA0MCUgLSBBa3plbnQzkwISABkADQAANDAlIC0gQWt6ZW50NJMCEgAaAA0AADQwJSAt IEFremVudDWTAhIAGwANAAA0MCUgLSBBa3plbnQ2kwISABwADQAANjAlIC0gQWt6ZW50MZMCEgAd AA0AADYwJSAtIEFremVudDKTAhIAHgANAAA2MCUgLSBBa3plbnQzkwISAB8ADQAANjAlIC0gQWt6 ZW50NJMCEgAgAA0AADYwJSAtIEFremVudDWTAhIAIQANAAA2MCUgLSBBa3plbnQ2kwIMACIABwAA QWt6ZW50MZMCDAAjAAcAAEFremVudDKTAgwAJAAHAABBa3plbnQzkwIMACUABwAAQWt6ZW50NJMC DAAmAAcAAEFremVudDWTAgwAJwAHAABBa3plbnQ2kwIMACgABwAAQXVzZ2FiZZMCDwApAAoAAEJl cmVjaG51bmeTAgQAKoAD/5MCBAArgAb/kwIEACyABP+TAgQALYAH/5MCDAAuAAcAAEVpbmdhYmWT Ag0ALwAIAABFcmdlYm5pc5MCFQAwABAAAEVya2zkcmVuZGVyIFRleHSTAgQAMYAJ/5MCCAAyAAMA AEd1dJMCBAAzgAj/kwIMADQABwAATmV1dHJhbJMCBAAAgAD/kwIKADUABQAATm90aXqTAgQANoAF /5MCDQA3AAgAAFNjaGxlY2h0kwIQADgACwAA3GJlcnNjaHJpZnSTAhIAOQANAADcYmVyc2Nocmlm dCAxkwISADoADQAA3GJlcnNjaHJpZnQgMpMCEgA7AA0AANxiZXJzY2hyaWZ0IDOTAhIAPAANAADc YmVyc2NocmlmdCA0kwIVAD0AEAAAVmVya278cGZ0ZSBaZWxsZZMCEwA+AA4AAFdhcm5lbmRlciBU ZXh0kwIVAD8AEAAAWmVsbGUg/GJlcnBy/GZlbpIA4gA4AAAAAAD///8A3QgGAB+3FAAAANQA/PMF APIIhAAAq+oAkAAAAABkEQAAAJAAkHE6AEYApQAAgIAAwMDAAICAgACZmf8AmTNmAP//zADM//8A ZgBmAP+AgAAAZswAzMz/AAAAgAD/AP8A//8AAAD//wCAAIAAgAAAAACAgAAAAP8AAMz/AMz//wDM /8wA//+ZAJnM/wD/mcwAzJn/AP/MmQAzZv8AM8zMAJnMAAD/zAAA/5kAAP9mAABmZpkAlpaWAAAz ZgAzmWYAADMAADMzAACZMwAAmTNmADMzmQAzMzMAXBAOAAMAAAAAAP///wAAAAAAYAECAAAAhQAV AMCiAAAAAA0AS2V5IGFuZCBOb3Rlc4UADQAcwAAAAAAFAEFVRElPhQANAMA3AQAAAAUAVklERU+F ABMAhFQBAAAACwBTVElMTCBJTUFHRYUADwBqaQEAAAAHAEdSQVBISUOFABEA2XMBAAAACQBDSEFS QUNURVKMAAQAAQApAK4BBAAGAAEEFwAIAAEAAAAAAAAAwQEIAMEBAAAivgEA6wBaAA8AAPBSAAAA AAAG8BgAAAABCAAAAgAAAAMAAAABAAAAAQAAAAoAAAAzAAvwEgAAAL8ACAAIAIEBQQAACMABQAAA CEAAHvEQAAAADQAACAwAAAgXAAAI9wAAEPwAHCAqBgAA0wIAAJEAAFBsZWFzZSBhbHNvIGluY2x1 ZGUgYW4gaW5zdGl0dXRpb25hbCBjb250YWN0IChzdGFuZGFyZGl6YXRpb24gb3JnYW5pemF0aW9u LCBldGMuLCBub3Qgb25seSBhIHBlcnNvbiwgd2hvc2UgcmVzcG9uc2liaWxpdGllcyBtYXkgY2hh bmdlIG92ZXIgdGltZSk7AABJZiB0aGVyZSBpcyBhIHN0YWJsZSBXZWIgYWRkcmVzcywgcGxlYXNl IGFsc28gaW5jbHVkZSB0aGlzLmMAAFBsZWFzZSBsaXN0IGRhdGUgb2YgZmlyc3QgYXBwcm92YWwg KG9yIHNjaGVkdWxlZCBmaXJzdCBhcHByb3ZhbCksIHZlcnNpb24gb3IgcmV2aXNpb24gbmFtZSAo aWYgYW55KWMAAFBsZWFzZSBsaXN0IGRhdGUgb2YgbW9zdCByZWNlbnQgYXBwcm92YWwgKG9yIHNj aGVkdWxlZCBhcHByb3ZhbCksIHZlcnNpb24gb3IgcmV2aXNpb24gbmFtZSAoaWYgYW55KY4AAFBs ZWFzZSB1c2UgSVNPIDg2MDEgZm9ybWF0LCBZWVlZLU1NLURELCBhcyB0aGlzIGlzIHNvcnRhYmxl IChleGFtcGxlOiAxOTY5LTA3LTIwIGlzIDIwIEp1bHkgMTk2OSkuICBQcmVmaXggd2l0aCAnIGlu IEV4Y2VsIHRvIGZvcmNlIHRleHQgbW9kZS4FAABHLjcyOAcAAEcuNzIzLjEFAABHLjcyOQUAAEcu NzIyAQAATgYAAEFNUi1XQggAAENDSVIgNjAxFwAAUywgU0IsIFcsIERWRCwgVFYsIEhEVFYIAABB LCBTLCBTQgsAAFkgKE5vdGUgMTUpCAAATm90ZSAxNTrJAABUaGUgZGVjb2RlciBiZWhhdmlvciBp biBjYXNlIG9mIGZyYW1lIGxvc3NlcyBpcyBub3Qgbm9ybWF0aXZlIGJ1dCBpcyBsZWZ0IG9wZW4g dG8gdGhlIGFwcGxpY2F0aW9uLiBQcm9wZXIgZnJhbWUgbG9zcyBjb25jZWFsbWVudCBzdHJhdGVn aWVzIGNhbiBiZSBlYXNpbHkgYWRvcHRlZCwgYXMgZWcuIGRvbmUgZm9yIDNHUFAgRW5oYW5jZWQg YWFjUGx1cy4IAAA3LDEzLCAxNQgAAE5vdGUgMTY6HgAAMipmcmFtZXMgKyBiaXRyZXMgKE5vdGUx MywgMTYpDAAANywxMywgMTUsIDE2FQAARW1iZWRkZWQgU2NhbGFiaWxpdHk/BwAAMTAgTUlQUwkA ADwgMTUgTUlQUxQAAFEuMTAvMTYgUmFwcC4sIElUVS1UEwAAUS45LzE2IFJhcHAuLCBJVFUtVAkA AChzZWUga2V5KQcAADE5ODgtMTEHAAAxOTk5LTA5BwAAMTk5Ni0wMwcAADE5OTAtMTIHAAAxOTky LTA5BwAAMTk5OC0wOQwAADYuNCwgOCwgMTEuOAcAADAgb3IgMj8BAABUCQAAVCwgUk4sIFRDAgAA VkMCAABWVAQAAFQsIEQBAABQZgAATUlQUyA9IE1pbGxpb24gaW5zdHJ1Y3Rpb25zIHBlciBzZWNv bmQsIFdNT1BTID0gV2VpZ2h0ZWQgTWlsbGlvbiBPcGVyYXRpb25zIHBlciBTZWNvbmQgKHBlciBJ VFUtVCB4eHgpEQAASW50ZXJsYWNlIGNvZGluZz8XAABPcHRpbWl6ZWQgQml0cmF0ZSBSYW5nZQsA AElUVS1UIEguMjYxBgAATVBFRy0yEwAAUHJvZ3Jlc3NpdmUgY29kaW5nPxAAAFRyYW5zZm9ybSBj b2RpbmcMAABNb3Rpb24gQ29tcC4WAABDb21wcmVzc2lvbiBjYXBhYmlsaXR5DAAAKHN1YmplY3Rp dmUpCwAASVRVLVQgSC4xMjAPAABJU08vSUVDIDE0NDk2LTILAABJVFUtVCBILjI2Mx0AAElUVS1U IEguMjY0LCBJU08vSUVDIDE0NDk2LTEwDAAAQVVESU8gQ09ESU5HDAAAVklERU8gQ09ESU5HEgAA U1RJTEwgSU1BR0UgQ09ESU5HEAAAQ0hBUkFDVEVSIENPRElORw4AAEdSQVBISUMgQ09ESU5HBAAA SlBFRwMAAEdJRgMAAFBORwQAAFRJRkYIAABOaWNrbmFtZQsAAEZvcm1hbCBuYW1lBQAAKFkvTikK AAAoQSwgRCwgTlMpAQAARAQAAChIeikGAAAobXNlYykHAABDb250YWN0BQAASC4yNjEGAABNUEVH LTEFAABILjI2MwkAAEguMjY0L0FWQwwAAElUVS1SIEJULjYwMQYAAE1QRUctNCQAAFBsZWFzZSBh bHNvIGluY2x1ZGUgYW4gZW1haWwgYWRkcmVzc4UAAFBsZWFzZSBpbmNsdWRlIGludGVybmF0aW9u YWwgdGVsZXBob25lIG51bWJlciAoaW4gRS4xNjQgZm9ybWF0OiArPGNvdW50cnkgY29kZT4gPGlu dGVybmF0aW9uYWwgbnVtYmVyPiAtIGZvciBleGFtcGxlICs0MSAyMiA3MzAgNTExMSkBAABBKwAA QXBwcm92ZWQgKGxpc3QgZGF0ZSBvZiBmaXJzdCBhcHByb3ZhbCBkYXRlKSQAAERyYWZ0IChsaXN0 IHNjaGVkdWxlZCBhcHByb3ZhbCBkYXRlKQIAAE5TNgAATm9uLXN0YW5kYXJkaXplZCBidXQgcHVi bGljIChsaXN0IGRhdGUgb2YgZmlyc3QgaXNzdWUpAQAAMAEAADEBAAAyAQAAMwUAAG90aGVygAAA UGxlYXNlIGVudGVyIGEgY29udGFjdCB3aXRoIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgdGVjaG5p Y2FsIGNvbnRlbnQgb2YgdGhlIHN0YW5kYXJkIChSYXBwb3J0ZXVyLCBDb252ZW5lciwgQ2hhaXIs IEVkaXRvciwgZXRjLikmAABObyBrbm93biBhcHBsaWNhYmxlLCBpbi1mb3JjZSwgcGF0ZW50cwcA AHVua25vd25WAABQYXRlbnQgc3RhdHVzIGlzIHVua25vd24gLSBwbGVhc2UgcHJvdmlkZSBhcyBt dWNoIGV4cGxhbmF0aW9uIGFzIHBvc3NpYmxlIGluIHRoaXMgY2FzZYAAAFBsZWFzZSBkZXNjcmli ZSAtIGhvd2V2ZXIgdGhpcyB0YWJsZSBpcyBhIHN1bW1hcnk7IGlmIHN0YXR1cyBmYWxscyBnZW5l cmFsbHkgaW50byBhIG51bWJlcmVkIGNhdGVnb3J5LCBwbGVhc2UgdXNlIHRoYXQgY2F0ZWdvcnku UAAARXF1aXZhbGVudCB0byBJVFUtVCBwYXRlbnQgcG9saWN5IDIuMSAocm95YWx0eS1mcmVlIG9u IGNvbmRpdGlvbiBvZiByZWNpcHJvY2l0eSlmAABFcXVpdmFsZW50IHRvIElUVS1UIHBhdGVudCBw b2xpY3kgMi4yIChsaWNlbnNhYmxlIG9uIFJlYXNvbmFibGUgYW5kIE5vbi1EaXNjcmltaW5hdG9y eSB0ZXJtcyAiUkFORCIpICB1AABFcXVpdmFsZW50IHRvIElUVS1UIHBhdGVudCBwb2xpY3kgMi4z IChJUCBub3Qgb2ZmZXJlZCBhcyBhYm92ZTsgImluIHN1Y2ggY2FzZSwgbm8gUmVjb21tZW5kYXRp b24gY2FuIGJlIGVzdGFibGlzaGVkIikIAAFFAG4AZwBsAGkAcwBoACYgAwAAQWxsFgAATm9uLUNv bXByZXNzaW9uIENvZGluZxIAAENvbXByZXNzaW9uIENvZGluZ1wAAEEgc2hvcnQgbGlzdCBvZiBw cmltYXJ5IGFwcGxpY2F0aW9ucyBmb3IgdGhlIGNvZGluZyBzdGFuZGFyZC4gIFRoZSBmb2xsb3dp bmcgY29kZXMgYXJlIHVzZWQ6eAAAVGhlIGZvcm1hbCBpZGVudGlmaWNhdGlvbiBvZiB0aGUgc3Rh bmRhcmQgLSBmb3IgZXhhbXBsZSwgSVRVIFJlYy4gbnVtYmVyLCBvciBJU08gc3RhbmRhcmQgbnVt YmVyIChub3QgdGhlIGZvcm1hbCB0aXRsZSkuSQAAVGhlIHNob3J0LCBpbmZvcm1hbCBuYW1lIGJ5 IHdoaWNoIHRoZSBzdGFuZGFyZCBpcyBtb3N0IG9mdGVuIHJlZmVycmVkIHRvLhcAAEFVRElPLVNQ RUNJRklDIEhFQURJTkdTEAAAR0VORVJBTCBIRUFESU5HUyQAAEluZGljYXRlcyBpZiBhIHNwZWVj aCBtb2RlbCBpcyB1c2VkLiwAAEluZGljYXRlcyByYW5nZSAobWluLW1heCkgb2YgYXVkaW8gcGFz c2JhbmQuaQAATGlzdCBvZiAxIG9yIG1vcmUgcmF0ZXMgYXQgd2hpY2ggY29kZWMgY2FuIG9wZXJh dGUuICBJZiBpbiBmb3JtYXQgKHgteSkgdGhpcyBpbmRpY2F0ZXMgdGhlIG1pbi1tYXggcmFuZ2Uu FwAARnJhbWUgbG9zcyBjb25jZWFsbWVudD8BAABZBAAAMSwgMgMAAFJBTQEAAD8CAAB+MAIAAH4x CAAAKGtieXRlcykFAAA8PCAxIAMAADwgMgcAAGxvZy1QQ00LAABJVFUtVCBHLjcyMg0AAElUVS1U IEcuNzIyLjELAABJVFUtVCBHLjcyOA0AAElUVS1UIEcuNzIzLjELAABJVFUtVCBHLjcyOQsAAElU VS1UIEcuNzExCwAAKGtiaXRzL3NlYykKAABCaXRyYXRlKHMpCgAANDgsIDU2LCA2NAYAADI0LCAz MggAADUuMywgNi40AwAAVEJEBQAAKGtIeikFAABULjEyeAgAADMwMC0zNDAwBwAANTAtNzAwMA8A AEF1ZGlvIEJhbmR3aWR0aA8AAEFwcHJvdmFsIFN0YXR1cw0AAFNwZWVjaCBNb2RlbD8RAABPcmln aW5hbCBBcHByb3ZhbA8AAExhdGVzdCBBcHByb3ZhbJMAAFBsZWFzZSB1c2UgSVNPIDg2MDEgZGF0 ZSBmb3JtYXQsIFlZWVktTU0tREQsIGFzIHRoaXMgaXMgc29ydGFibGUgKGV4YW1wbGU6IDE5Njkt MDctMjAgaXMgMjAgSnVseSAxOTY5KS4gIFByZWZpeCB3aXRoICcgaW4gRXhjZWwgdG8gZm9yY2Ug dGV4dCBtb2RlLgsAAFNhbXBsZSBSYXRlDAAARnJhbWUgTGVuZ3RoCgAAMzUtNDAgTUlQUwoAADE4 LTIwIE1JUFMJAAAwLjAxIE1JUFMeAAB+RmxvYXRpbmcgcHQuIENvbXAuIENvbXBsZXhpdHkdAAB+ Rml4ZWQgcG9pbnQgQ29tcC4gQ29tcGxleGl0eQoAAElQUiBTdGF0dXMIAAEoADAALAAxACwAMgAm ICkACwAAUHJvZ3JhbSBST00VAABDaGFpciwgM0dQUDIgVFNHLUMxLjEJAABUYWJsZSBST00QAABD b250YWN0cyBsaXN0ZWQ67AAAUmFwcG9ydGV1ciwgSVRVLVQgUS4xMC8xNiAtIE1zLiBDbGF1ZGUg TGFtYmxpbiwgRnJhbmNlIFRlbGVjb20gUiZEIC9ESUgsIFRlY2hub3BvbGUgQW50aWNpcGEsIDIg YXZlbnVlIFBpZXJyZSBNYXJ6aW4sIDIyMzA3IExBTk5JT04gQ2VkZXgKRnJhbmNlLCBUZWw6ICsz MyAyIDk2IDA1IDEzIDAzLCBGYXg6ICszMyAyIDk2IDA1IDM1IDMwLCBFbWFpbDogY2xhdWRlLmxh bWJsaW5AcmQuZnJhbmNldGVsZWNvbS5jb20HAAAyMDAzLTAyCwAASVRVLVQgRy43MjYLAABJVFUt VCBHLjcyNwUAAEFEUENNBwAAMTk5NC0xMQ4AADE2LCAyNCwgMzIsIDQwCwAAVkFEL0RUWC9DTkcP AAAoWS9OLCBZL04sIFkvTikFAABOL04vThMAAFByaW1hcnkgQXBwbGljYXRpb24FAABZL1kvWQsA AChkYXRlLCB2ZXIpDAAAKGdpdmUgdW5pdHMpEQAAQWxnb3JpdGhtaWMgRGVsYXkHAAAyMDAyLTAx OgAANi42LCA4Ljg1LCAxMi42NSwgMTQuMjUsIDE1Ljg1LCAxOC4yNSwgMTkuODUsIDIzLjA1LCAy My44NYoAAFRoZSBtaW5pbXVtIHRpbWUgYmV0d2VlbiBhY3F1aXNpdGlvbiBvZiBhIGdpdmVuIGlu cHV0IHNhbXBsZSBhdCB0aGUgZW5jb2RlciBhbmQgcmVjb25zdHJ1Y3Rpb24gb2YgdGhlIHNhbWUg b3V0cHV0IHNhbXBsZSBhdCB0aGUgZGVjb2Rlci4gIJYAAFRoaXMgdmFsdWUgYXNzdW1lcyBpbnN0 YW50YW5lb3VzIHByb2Nlc3NpbmcgYW5kIHplcm8gcHJvcGFnYXRpb24gZGVsYXkgYmV0d2VlbiBl bmNvZGVyIGFuZCBkZWNvZGVyLiAgVXN1YWxseSBjYWxjdWxhdGVkIGFzIEZyYW1lIExlbmd0aCAr IExvb2stQWhlYWQuIK4AAEFwcHJveGltYXRlIGNvbXB1dGF0aW9uYWwgY29tcGxleGl0eSBvZiBl bmNvZGVyICsgZGVjb2Rlci4gIFVuaXRzIHZhcnkuICBUaGlzIGlzIG9ubHkgYSByb3VnaCBhcHBy b3hpbWF0aW9uLCBhcyB0aGlzIHZhbHVlIGlzIGhpZ2hseSBkZXBlbmRlbnQgb24gaW1wbGVtZW50 YXRpb24gYXJjaGl0ZWN0dXJlLqwAAFByb2dyYW0gbWVtb3J5IG5lY2Vzc2FyeSB0byBzdG9yZSBl eGVjdXRhYmxlIGNvZGVjIHRvIGltcGxlbWVudCBjb2RlYy4gVGhpcyBpcyBvbmx5IGEgcm91Z2gg YXBwcm94aW1hdGlvbiwgYXMgdGhpcyB2YWx1ZSBpcyBoaWdobHkgZGVwZW5kZW50IG9uIGltcGxl bWVudGF0aW9uIGFyY2hpdGVjdHVyZS4cAABJVFUtVCBILjI2MiwgSVNPL0lFQyAxMzgxOC0yCQAA ZGlmZmljdWx0CgAAKGJpdHMvc2VjKQQAADY0aysFAAAxTS0yTQYAADRNLTIwTQcAADEuNU0tMk0K AAAyMTZNLCAyODhNeQAAVGhlIGVuY29kZWQgYml0c3RyZWFtIGNhbiBiZSByZWR1Y2VkIGluIGJp dHJhdGUgYnkgdGhlIG5ldHdvcmsgd2l0aCBncmFjZWZ1bCBkZWdyYWRhdGlvbiBpbiBxdWFsaXR5 LCB3aXRob3V0IHRyYW5zY29kaW5nLgwAADIxNi0yODggTUlQUwQAAFZDRUcEAABNUEVHCgAAVkNF RywgTVBFRwoAAE1QRUcsIFZDRUcQAABDaGFpciBTRzYsIElUVS1SAwAAVkNEBwAAVFYsIERWRBQA AFByaW1hcnkgQXBwbGljYXRpb25zCQAARFZELXZpZGVvAQAAUwIAAFRWBQAAMjAwMT8HAAAxNzJ4 MTQ0BwAAMzUyeDI4OAUAADRreDRrBwAANjRreDY0axEAAE1heC4gUGljdHVyZSBTaXplBQAAMTZ4 MTYJAAAyMDQ4eDExNTIJAAA0MDk2eDIwNDgHAAA3MjB4NTc2BwAANzIweDQ4MA8AACh3aWR0aCwg aGVpZ2h0KQcAADEyOHgxNDMGAAA+PSAxMGsUAABWYXJpYWJsZSBmcmFtZSByYXRlPwwAAFZDLCBW VCwgUywgTQcAAFMsIFcsIE0VAABWQywgVlQsIFRWLCBEVkQsIFcsIE0SAAA0OjI6MCBDaHJvbWlu YW5jZT8SAAA0OjQ6NCBDaHJvbWluYW5jZT8SAAA0OjI6MiBDaHJvbWluYW5jZT8WAABWYXJpYWJs ZSBhc3BlY3QgcmF0aW8/DAAAVCwgRCwgU1ZELCBWCwAAVm9pY2Ugb24gSVABAABNAwAARFZEAQAA VwEAAFYTAABUZWxlcGhvbnkgKGdlbmVyYWwpAgAAUk4KAABSYWRpbyBuZXdzAgAAVEMQAABUZWxl Y29uZmVyZW5jaW5nAwAAU1ZEGQAAU2ltdWx0YW5lb3VzIHZvaWNlICYgZGF0YS8AAERpZ2l0YWwg Q2lyY3VpdCBNdWx0aXBsaWNhdGlvbiBFcXVpcG1lbnQgKERDTUUpLgAAUGFja2V0IENpcmN1aXQg TXVsdGlwbGljYXRpb24gRXF1aXBtZW50IChQQ01FKQYAAE1vYmlsZQ8AAFZpZGVvIHRlbGVwaG9u eQkAAFN0cmVhbWluZwwAAFdpcmVsZXNzIExBTgoAAFRlbGV2aXNpb24SAABWaWRlbyBjb25mZXJl bmNpbmcDAABGQVgHAABKUEVHLUxTCQAASlBFRy0yMDAwCwAAQ29sb3IgZGVwdGgOAAAoYml0cy9j aGFubmVsKQYAAENvbG9yPwsAAElUVS1UIFQuMTJ4BQAAQVNDSUkIAABJU08gNjQ2PwcAAExhdGlu LTEGAABFQkNESUMHAABVbmljb2RlDgAAQml0cy9jaGFyYWN0ZXIGAAAoYml0cykGAAAobGlzdCkV AABTdXBwb3J0ZWQgTGFuZ3VhZ2UocymEAABDb2xvciBzYW1wbGluZyBzeXN0ZW0gdXNlcyA2NCBj b2xvciBkaWZmZXJlbmNlIHNhbXBsZXMgcGVyIGxpbmUsIGFsdGVybmF0ZSBjb21wb25lbnQgYnkg bGluZSBhZ2FpbnN0IDI1NiBsdW1pbmFuY2Ugc2FtcGxlcyBwZXIgbGluZS4PAABILjEyMCBQYXJ0 cyAxJjIHAAAyNTZ4Mjg2CQAAWSAoNDoxOjApEgAAQml0cmF0ZXMgc3VwcG9ydGVkCQAAKGtiaXRz L3MpAwAAYW55FQAANzY4LCAxMTUyLCAxNTM2LCAyMDAwTAAATGlzdCBvZiBiaXRyYXRlcyBzdXBw b3J0ZWQgLSBpZiBjb2RlYyBjYW4gYmUgb3BlcmF0ZWQgYXQgYW55IGJpdHJhdGUsICJhbnkiLg8A AElTTy9JRUMgMTExNzItMhQAAEFubm91bmNlZCBJUFIgU3RhdHVzFQAAUHJhY3RpY2UgLSBJUFIg U3RhdHVzCgAATVBFRy0yIEFBQwQAAEFDLTMPAABJU08vSUVDIDExMTcyLTMPAABJU08vSUVDIDEz ODE4LTMPAABJU08vSUVDIDEzODE4LTcMAABBVFNDIEEvNTIvMTAPAABJU08vSUVDIDE0NDk2LTMH AABTLCBWLCBXCQAARFZELCBIRFRWRQAASW5kaWNhdGVzIGlmIGEgY29kZWMgYWN0aXZlbHkgY29u Y2VhbHMgYXJ0aWZhY3RzIGNhdXNlIGJ5IGZyYW1lIGxvc3MuTgAAVm9pY2UgQWN0aXZpdHkgRGV0 ZWN0aW9uLCBEaXNjb250aW51b3VzIFRyYW5zbWlzc2lvbiwgQ29tZm9ydCBOb2lzZSBHZW5lcmF0 aW9uMgAAVGhlIGZyZXF1ZW5jeSBhdCB3aGljaCBpbnB1dCBzYW1wbGVzIGFyZSBhY3F1aXJlZC46 AABUaGUgbGVuZ3RoIG9mIGVhY2ggc2V0IG9mIGluZGVwZW5kZW50bHktZGVjb2RhYmxlIHNhbXBs ZXMuMgAAUmFuZG9tIGFjY2VzcyBtZW1vcnkgbmVjZXNzYXJ5IHRvIGltcGxlbWVudCBjb2RlYy4r AABSZWFkLW9ubHkgbWVtb3J5IG5lY2Vzc2FyeSB0byBzdG9yZSB0YWJsZXMuFwAAVklERU8tU1BF Q0lGSUMgSEVBRElOR1NSAABJbmRpY2F0ZXMgaWYgdGhlIGNvZGVjIGhhcyB0b29scyBzcGVjaWZp Y2FsbHkgZm9yIGVuY29kaW5nIG9mIGludGVybGFjZWQgbWF0ZXJpYWwuQQAASW5kaWNhdGVzIGlm IHRoZSBjb2RlYyBpcyBjYXBhYmxlIG9mIGVuY29kaW5nIHByb2dyZXNzaXZlIGZyYW1lcy5AAABS YW5nZSBvZiBiaXRyYXRlcyBmb3Igd2hpY2ggdGhlIGNvZGVjIGhhcyBpbnRlbmRlZCBhcHBsaWNh dGlvbnMuPwAATGFyZ2VzdCBwaWN0dXJlIHNpemUgKGluIGx1bWluYW5jZSBzYW1wbGVzKSB3aGlj aCBjYW4gYmUgY29kZWQuQAAAU21hbGxlc3QgcGljdHVyZSBzaXplIChpbiBsdW1pbmFuY2Ugc2Ft cGxlcykgd2hpY2ggY2FuIGJlIGNvZGVkLkwAAEluZGljYXRlcyBpZiB0aGUgY29kZWMgY2FuIGhh bmRsZSBtYXRlcmlhbCBvZiBhIHdpZGUgcmFuZ2Ugb2YgYXNwZWN0IHJhdGlvcy5EAABJbmRpY2F0 ZXMgaWYgdGhlIGNvZGVjIGNhbiBoYW5kbGUgZnJhbWVzIG9mIGlycmVndWxhciBjYXB0dXJlIHRp bWVzLlkAAEluZGljYXRlcyBpZiB0aGUgY29kZWMgdXNlcyB0cmFuc2Zvcm1zIHRvIGltcHJvdmUg Y29kaW5nIHBlcmZvcm1hbmNlIChmb3IgZXhhbXBsZSwgRENUcykuHQAAU1RJTEwtSU1BR0UgU1BF Q0lGSUMgSEVBRElOR1NVAABJbmRpY2F0ZXMgaWYgY29kZWMgc3VwcG9ydHMgY29sb3IgKG11bHRp IHNwZWN0cmFsIGNoYW5uZWwpIG1hdGVyaWFsICh2cy4gbW9ub2Nocm9tZSkuMgAATnVtYmVyIG9m IGJpdHMgb2YgYWNjdXJhY3kgZm9yIGVhY2ggY29sb3IgY2hhbm5lbC48ABwgGwAAQ0hBUkFDVEVS LVNQRUNJRklDIEhFQURJTkdTKwAATnVtYmVyIG9mIGJpdHMgdXNlZCB0byBjb2RlIGVhY2ggY2hh cmFjdGVyLmAAAEEgbGlzdCBvZiB3cml0dGVuIGxhbmd1YWdlcyB3aGljaCB0aGUgY2hhcmFjdGVy IHNldCBzdXBwb3J0cyAoaGFzIHRoZSBuZWNlc3NhcnkgY2hhcmFjdGVycyBmb3IpLuYAAE1QRUcg LSBDb252ZW5lciwgSVNPL0lFQyBKVEMxIFNDMjkgV0cxMSAtIE1yLiBMZW9uYXJkbyBDaGlhcmln bGlvbmUsIENTRUxULCBWaWEgRy4gUmVpc3MgUm9tb2xpLCAyNzQsIDEwMTQ4IFRvcmlubywgSVRB TFksIFRlbDogKzM5IDExIDIyOCA2MTIwLCBGYXg6ICszOSAxMSAyMjggNjI5OSwgRW1haWw6IGxl b25hcmRvLmNoaWFyaWdsaW9uZUBjc2VsdC5pdCwgaHR0cDovL3d3dy5jc2VsdC5pdC9tcGVnBQAA Tm90ZXMEAAAxLCAzCgAAMSwgMiwgMywgNAsAADU3NiBzYW1wbGVzBgAATm90ZSA2DAAAMTAyNCBz YW1wbGVzTgAAMzItODAgKHN0ZXBzIG9mIDgpLCA5NiwgMTEyLCAxMjgsIDE1MC0yNTYgKHN0ZXBz IG9mIDMyKSwgMzAwLTY0MCAoc3RlcHMgb2YgNjQpBwAATm90ZSAxOgcAAE5vdGUgMjoMAAAxNTM2 IHNhbXBsZXMeAABJU08vSUVDIDExMTcyLTMsIElUVS1SIEJTLjExMTURAABNaW4uIFBpY3R1cmUg U2l6ZUEAAEluZGljYXRlcyBpZiB0aGUgY29kZWMgc3VwcG9ydHMgNDoyOjAgY2hyb21pbmFuY2Ug KGNvbG9yKSBmb3JtYXQuQQAASW5kaWNhdGVzIGlmIHRoZSBjb2RlYyBzdXBwb3J0cyA0OjI6MiBj aHJvbWluYW5jZSAoY29sb3IpIGZvcm1hdC5BAABJbmRpY2F0ZXMgaWYgdGhlIGNvZGVjIHN1cHBv cnRzIDQ6NDo0IGNocm9taW5hbmNlIChjb2xvcikgZm9ybWF0LlkAAEluZGljYXRlcyBpZiB0aGUg Y29kZWMgdXNlcyBtb3Rpb24gY29tcGVuc2F0aW9uIHRlY2huaXF1ZXMgdG8gaW1wcm92ZSBjb2Rp bmcgcGVyZm9ybWFuY2UugAAAU3ViamVjdGl2ZSBhbmQgcmVsYXRpdmUgbWVhc3VyZSBvZiBvdmVy YWxsIGNvZGluZyBwZXJmb3JtYW5jZS4gIEhpZ2hlciB2YWx1ZXMgaW5kaWNhdGUgbm90aWNlYWJs eSBiZXR0ZXIgY29tcHJlc3Npb24gZWZmaWNpZW5jeS4TAABDT05UQUNUUyBSRUZFUkVOQ0VE1QAA VkNFRyAtIFJhcHBvcnR1ZXIgSVRVLVQgUS42LzE2IC0gTXIuIEdhcnkgU3VsbGl2YW4sIE1pY3Jv c29mdCBDb3JwLiwgQnVpbGRpbmcgOSwgT25lIE1pY3Jvc29mdCBXYXksIFJlZG1vbmQsIFdBIDk4 MDUyLTYzOTksIFVuaXRlZCBTdGF0ZXMsIFRlbDogKzEgNDI1IDcwMyA1MzA4LCBGYXg6ICsxIDQy NSA5MzYgNzMyOSwgRS1tYWlsOiBnYXJ5c3VsbEBtaWNyb3NvZnQuY29tjgAAM0dQUDIsICBIZW5y eSBDdXNjaGllcmkgLSBEaXJlY3RvciwgM0dQUDIsIFRlbGVwaG9uZTogKzEgNzAzIDkwNyA3NDk3 LCBGYXg6ICsxIDcwMyA5MDcgNzcyOCwgRW1haWw6IGhjdXNjaGllQHRpYS5laWEub3JnLCBodHRw Oi8vd3d3LjNncHAyLm9yZ7oAAElTTywgSVNPIENlbnRyYWwgU2VjcmV0YXJpYXQsIDEgcnVlIGRl IFZhcmVtYmUnLCBDYXNlIHBvc3RhbGUgNTYsIENILTEyMTEsIEdlbmV2YSAyMCwgU3dpdHplcmxh bmQsIFRlbDogKzQxIDIyIDc0OSAwMSAxMSwgRmF4OiArNDEgMjIgNzMzIDM0IDM2LCBFbWFpbDog Y2Vuc2VjQGlzby5vcmcsIGh0dHA6Ly93d3cuaXNvLm9yZxUAAE9yZ2FuaXphdGlvbnMgbGlzdGVk OnsAAElUVS1ULCBQbGFjZSBkZXMgTmF0aW9ucywgQ0gtMTIxMSBHZW5ldmEgMjAsIFN3aXR6ZXJs YW5kLCBUZWw6ICs0MSAyMiA3MzAgNTEgMTEsIEVtYWlsOiBpdHVtYWlsQGl0dS5pbnQsIGh0dHA6 Ly93d3cuaXR1LmludAwAAEguMTIwIFBhcnQgMxUAAElUVS1UIEguMTIwIFNlY3Rpb24gMwQAADEu NU0HAAAxOTJ4MjYyBwAAMzg0eDUyNQsAAFkgKDQ6Mi8zOjApDQAAVkMgKG9ic29sZXRlKQYAAE5v dGVzOn0AAENvbG9yIHNhbXBsaW5nIHVzZXMgNjQgY29sb3IgZGlmZmVyZW5jZSBzYW1wbGVzIHBl ciBsaW5lLCBhbHRlcm5hdGUgY29tcG9uZW50IGJ5IGxpbmUgYWdhaW5zdCAzODQgbHVtaW5hbmNl IHNhbXBsZXMgcGVyIGxpbmUuDgAAMC44LCA0LjAsIDguNTUOAABRQ0VMUCA4IChDRE1BKQkAAEFO U0kgSVM5NhkAADNHUFAyIEMuUzAwMzAsIEFOU0kgSVM4OTMIAAAzMCB0byAzMwUAAFNQRUVYHAAA aHR0cDovL3NwZWV4LnNvdXJjZWZvcmdlLm5ldAkAADgsIDE2LCAzMk4AADIuMTUgdG8gMjQuNiBp biBuYXJyb3diYW5kLCBhZGQgZm9yIGVtYmVkZGVkIHdpZGViYW5kIGFuIGFkZGl0b25hbCA1LjYg dG8gMTcuNgYAADIwLCAzMCkAADEzLjMzICgzMCBtcyBmcmFtZXMpLCAxNS4yICgyMCBtcyBmcmFt ZXMpCQAAMy40NSwgNi43AwAAfjMwAwAAbi9hDAAAfjEwLTIwIFdNT1BTDwAAMC44LCAyLCA0LCA4 LjU1GgAASVRVLVQgRy43MjIuMiwgM0dQUCBBTVItV0IPAABNLCBTLCBULCBWLCBTVkQOAAAzOTAw IGJhc2ljIG9wcwYAAEdTTSBGUgYAAEdTTSBIUgcAAEdTTSBFRlIDAABBTVISAABHU00gRlIgKEZ1 bGwtUmF0ZSkSAABHU00gSFIgKEhhbGYtUmF0ZSkoAABHU00gLyBQQ1MgMTkwMCBFRlIgIChFbmhh bmNlZCBGdWxsLVJhdGUpHgAAM0dQUCBBTVIgKEFkYXB0aXZlIE11bHRpLVJhdGUpBAAATSwgVgcA AE0sIFQsIFYHAAAxOTk1LTAxBwAAMTk5Ni0wMQcAADE5OTktMDErAAA0Ljc1LCA1LjE1LCA1Ljks IDYuNywgNy40LCA3Ljk1LCAxMC4yLCAxMi4yCQAAMi45IFdNT1BTCgAAMTguNSBXTU9QUwoAADE1 LjIgV01PUFMNAAA5MDAgYmFzaWMgb3BzDwAAIDQxMDAgYmFzaWMgb3BzDgAAMTgwMCBiYXNpYyBv cHMOAAA0OTAwIGJhc2ljIG9wcwgAADNHUFAgU0E0DAAAMzIsIDQ0LjEsIDQ4DQAAMTYsIDIyLjA1 LCAyNAcAADEgb3IgMj+vAABTYW1lIGFzIE1QRUctMSwgbWF4IGJpdHJhdGUgMzIga0h6IHNhbXBs ZXMgLSBMMSBtYXggaXMgOTAzIGticHMsIEwyIDgzOSBrYnBzLCBMMyA3NzUga2Jwcy4gIEZvciA0 NC4xLCBMMSAxMDc1IGticHMsIEwyIDEwMTEga2JwcywgTDMgOTQ3IGticHMgRm9yIDQ4LCBMMSAx MTMwLCBMMiAxMDY2LCBMMyAxMDAyDwAAQUNFTFAgZm9yIFRFVFJBAgAAQSAKAAAxMC42NSBNSVBT AQAALREAAEVUU0kgRVAgVEVUUkEgV0c1EgAAIEVUU0kgRU4gMzAwIDM5NS0yCgAAMTk5Ni0wNi0x MgoAADE5OTgtMDItMTAEAABNLCBUCwAAMzg0IHNhbXBsZXMMAAAxMTUyIHNhbXBsZXMQAABTZWUg c2FtcGxlIHJhdGVzGQAAMzIgdG8gNDQ4ICgzMiBrYnBzIHN0ZXBzKTYAADMyIHRvIDEyOCAoOCBr YnBzIHN0ZXBzKSwgMTYwLCAxOTIsIDIyNCwgMjU2LCAzMjAsIDM4NBgAADMyIHRvIDMyMCAoOCBr YnBzIHN0ZXBzKRMAAE0sIFMsIFQsIFYsIFZDLCBTVkTAAABDaGFpciwgM0dQUCBUU0ctU0EgV0c0 IChTQTQpIC0gTXIuIEthcmkgSuRydmluZW4sIE5va2lhIFJlc2VhcmNoIENlbnRlciwgUC5PLiBC b3ggMTAwLCBGSU4tMzM3MjEgVGFtcGVyZSwgRmlubGFuZDsgVGVsOiArMzU4IDcxODAgMzU4NTQs IEZheDogKzM1OCA3MTgwIDM1ODg4LCBFbWFpbDoga2FyaS5qdS5qYXJ2aW5lbkBub2tpYS5jb21u AAAzR1BQLCBFVFNJIE1vYmlsZSBDb21wZXRlbmNlIENlbnRyZSwgNjUwIHJvdXRlIGRlcyBMdWNp b2xlcywgMDY5MjEgU29waGlhLUFudGlwb2xpcyBDZWRleCwgaHR0cDovL3d3dy4zZ3BwLm9yZwoA ADM5LjAgV01PUFMKAAAxNi43IFdNT1BTGQAAMzIgdG8gMjU2ICgzMiBrYnBzIHN0ZXBzKRcAADgg dG8gMTYwICg4IGticHMgc3RlcHMpCgAANDQuOCwgODUuMRIAADEuOS0yMi44LCAzLjgtNDYuMgQA AEFUU0ODAABQcm9ncmFtIFJPTSBpcyBnaXZlbiBhcyBhIG51bWJlciBvZiBiYXNpYyBhcml0aG1l dGljIG9wZXJhdGlvbnMgKGFwcHJveGltYXRpb24gb2YgbnVtYmVyIG9mIGFzc2VtYmx5IGluc3Ry dWN0aW9ucyBvbiBhIHR5cGljYWwgRFNQKXEAAEZvciBBTVIgYW5kIEFNUi1XQiwgdGhlIGNvbXBs ZXhpdHkgaXMgMTEuOS0xNi43IFdNT1BTIGFuZCAyNy4yLTM5LjAgV01PUFMsIHJlc3BlY3RpdmVs eSwgZGVwZW5kaW5nIG9uIHRoZSBtb2RlLiAgBwAATm90ZSA1OoAAAE1QRUcgMiBBQUMgTG93IGNv bXBsZXhpdHkgcHJvZmlsZSBpcyAwLjI0MjA2MyBNSVBTIHBlciBmcmFtZSwgbWFpbiBwcm9maWxl IGlzIDAuNDkyNDIzIE1JUFMgcGVyIGZyYW1lLCA0MjU2MCBrd29yZHMgKDE2IGJpdCkgUkFNBwAA Tm90ZSA3OhAAAFNhbXBsZSBSYXRlIChIeikFAABKQklHMhkAAElUVS1UIFQuODgsIElTTy9JRUMg MTQ0OTIHAAAyMDAwLTAyCQAATG9zc2xlc3M/BgAATG9zc3k/DwAASVRVLVQgVC42IChNTVIpAQAA RgoAAEZhY3NpbWlsaWUDAABXV1cQAABBcmNoaXZhbCBzdG9yYWdlagAASW5kaWNhdGVzIGlmIGNv ZGVjIHN1cHBvcnRzIGxvc3Mgb2YgcGVyY2VwdHVhbGx5IGxlc3MtaW1wb3J0YW50IGRldGFpbCwg dG8gaW1wcm92ZSBjb21wcmVzc2lvbiBlZmZpY2llbmN5LmoAAEluZGljYXRlcyBpZiBjb2RlYyBz dXBwb3J0cyBjb21wcmVzaW9uIHRoYXQgZG9lcyBub3QgbG9zZSBhbnkgZGV0YWlsIChleGNlcHQg Zm9yIGlucHV0IHF1YW50aXphdGlvbiBsb3NzKS4JAABBLCBGLCBXV1cEAABBTlNJCwAASVM1NCAo VERNQSkMAABJUzY0MSAoVERNQSklAABJUzEzNi00MTAgKFBDUyAxODAwIC0gR1NNIEAgMTgwMCBN SHopBAAAQVJJQgcAAChKYXBhbikEAABJTEJDRgAAU2VlIGh0dHA6Ly9zZWFyY2guaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFuZGVyc2VuLWlsYmMtMDEudHh0IBUAAElUVS1ULjg3LCBJ U08tMTQ0OTUtMQgAADI1NiBvbmx5AwAAMC04EgAASVRVLVQgVC40IChNSCwgTVIpBAAASkJJRxkA AElUVS1UIFQuODIsIElTTy9JRUMgMTE1NDQeAABJVFUtVCBULjgxL1QuODQsIElTTy9JRUMgMTA5 MTgeAABJVFUtVCBULjgwMC84MDEsIElTTy9JRUMgMTU0NDQYAAAoUHJvcC4gLSBBT0wvQ29tcHVT ZXJ2ZSkPAAAoUHJvcC4gLSBBZG9iZSkHAAA4IG9yIDE2BwAAMiB0byAxNggAAHVwIHRvIDIwBwAA QW5uZXggSC8AADggKGJhc2VsaW5lKSwgMTIgKGV4dGVuZGVkKSwgMTYgKGxvc3NsZXNzIG9ubHkp CAAAdXAgdG8gMTYcAABSRkMgMjA4MywgSVNPL0lFQyBGRElTIDE1OTQ4DwAAMSAoYmFzZWxpbmUp LCAyFwAAMSAoYmFzZWxpbmUgZGVjb2RlciksIDIDAABTTVYRAABNLCBQLCBTLCBULCBUQywgVgcA ADE5OTctMDEHAAAyMDAxLTEyEwAAOC41NSwgNC4wLCAyLjAsIDAuOAUAAFkvTi9ZBQAAOCwgMTYI AAA0MCBXTU9QUwgAADE3IFdNT1BTCAAANDUgV01PUFMIAAAzOCBXTU9QUw4AAFFDRUxQMTMgKENE TUEpGQAAM0dQUDIgQy5TMDAyMCwgQU5TSSBJUzczMxMAADEuMCwgMi43LCA2LjIsIDEzLjNQAQBB bGwgZGF0YSBmb3IgMjU2MDAgSHogaW50ZXJuYWwgc2FtcGxpbmcgZnJlcXVlbmN5IChJU0YpIChz Y2FsYWJsZSkuIE5vdGUgdGhhdCB0aGUgZGVsYXkgYW5kIGNvbXBsZXhpdHkgZmlndXJlcyBhcmUg YSBmdW5jdGlvbiBvZiB0aGUgSVNGLiBXb3JzdCBjYXNlIElTRiBpcyAyNS42KjEuNSA9IDM4LjQg a0h6LiBJbiB0aGlzIHdvcnN0IGNhc2U6IEZyYW1lIHNpemUgPSAgMjAvMS41ID0gMTMuMzMgbXM7 IGFsZ29yaXRobWljIGRlbGF5IG1vbm8gPSA2NyBtcywgc3RlcmVvID0gODcgbXMuICBXb3JzdCBj YXNlIGRlY29kZXIgY29tcGxleGl0eTogbW9ubzogMTMsIHN0ZXJlbyAyNCBXTU9QUy4IAABOb3Rl IDEwOgoAAElUVS1UIEouNDEKAABJVFUtVCBKLjQyBwAATm90ZSAzOgcAAE5vdGUgNDrRAABSYXBw b3J0ZXVyLCBJVFUtVCBRLjkvMTYgLSBNci4gSm9uIEdpYmJzLCBNb3Rvcm9sYSBMYWJzLCBKYXlz IENsb3NlLCBWaWFibGVzIEluZHVzdHJpYWwgRXN0YXRlLApCYXNpbmdzdG9rZSwgSGFtcHNoaXJl LCBSRzIyIDRQRCwgVUssIFRlbDogKzQ0IDEyNTYgNDg0Mzg1LCBGYXg6ICs0NCAxMjU2IDQ3MTM4 MywgRS1tYWlsOiBqb24uZ2liYnNAbW90b3JvbGEuY29tCgkAAElUVS1UIFNHOQgAADQwLTE1MDAw AgAAU0IPAABTb3VuZCBicm9hZGNhc3QUAAAxMS1iaXQgbG9nLVBDTSAxNGtIehkAADM4NCAoMzUy IHNvdXJjZSArIDMyIGJlcikOAAAyICgzMiBzYW1wbGVzKQ4AADEgKDMyIHNhbXBsZXMpEQAAMC4x MjUgKDIgc2FtcGxlcykjAAAzODQgKDIgeCAxOTIsIDE5Mj0xNzYgc3JjICsgMTYgcGFyKQoAADQw KD8pLTcwMDAUAAAxMS1iaXQgbG9nLVBDTSAxMGtIemwAAEFUU0MgLSBBVFNDLCAxNzUwIEsgU3Qu IE5XLCBTdWl0ZSAxMjAwLCBXYXNoaW5ndGlvbiBEQyAyMDAwNiwgVVNBLCBUZWw6ICsxIDIwMiA4 MjggMzEzMCwgaHR0cDovL3d3dy5hdHNjLm9yZwsAADwgNS41IFdNT1BTAwAARmF4BwAARiwgRG9j cwQAADE5OHgSAABJVFUtVCBULjQgKE1SLCBNSCkHAABMYXRpbi0yBwAAUnVzc2lhbgUAAElUVS1U CgAASVNPIDg4NTkvMQoAAElTTyA4ODU5LTIKAABJU08gODg1OS1YBAAAVC41MQQAAFQuNTAEAABU LjUyBQAAVC4xMDELAABXZXN0IEV1cm9wZQsAAEVhc3QgRXVyb3BlBAAATWFueQ8AAEVtYmVkZGVk ICBBRFBDTQwAAENvbG9yIGNvZGluZwQAAEN5YW4DAABLRVk4AABJbmZvcm1hdGlvbiBuZWVkcyB2 ZXJpZmljYXRpb24gb3IgaGFzIHN1c3BlY3RlZCBwcm9ibGVtcw0AAFJhcHAsIFEuMjMvMTYHAABT aXJlbjE0BgAAU2lyZW43FQAASVRVLVQgRy43MjIuMSBBbm5leCBDCAAANTAtMTQwMDAHAAAyMDA1 LTA1CgAAMjQsIDMyLCA0OAIAAE4gCgAAPCAxMSBXTU9QUwkAADwgMzAgTUlQUwwAAFJhcHAuIFEx MC8xNgcAAEFNUi1XQiseAAgCAKBNYXggQml0IFJhdGUvQ2hhbm5lbCAoa2JpdC9zKRcAEQAdAAAA MgAAQm90aCBSb3lhbHR5LUZyZWUgYW5kIFJBTkQgaWNlbnNpbmcgdGVybXMgb2ZmZXJlZC4IAABO b3RlIDE6IKMAAENvbnRyaWJ1dGlvbiBvZiBWQUQvRFRYL0NORyBpcyBpbmNsdWRlZCBpbiB0aGUg Y29tcGxleGl0eSBmaWd1cmVzIGZvciBHU00gRUZSIGFuZCBJVFUtVCBHLjcyMi4yIC8gM0dQUCBB TVItV0I7IGJ1dCBpcyBub3QgaW5jbHVkZWQgZm9yIEdTTSBGUiwgR1NNIEhSIGFuZCAzR1BQIEFN Ui6NAABGb3IgQU1SLCB0d28gYWx0ZXJuYXRpdmUgVkFEcyBhcmUgZGVmaW5lZCAoVkFEMSAvIFZB RDIpOiAwLjQgLyAxLjAgV01PUFM7IFJBTTogMC4xIC8gMC4yOyBUYWJsZSBST006IDAuMCAvIDAu NzsgUHJvZ3JhbSBST006IDAuNyAvIDAuNiBrYnl0ZXMHAABOb3RlIDY6lAAAVGhlc2UgY29kZWNz IGhhdmUgdGhlIHNhbWUgbnVtYmVyIG9mIGJpdHMgcGVyIGZyYW1lIGFzIHRoZSBlcXVpdmFsZW50 IE1QRUctMSBjb2RlYywgdGhlbiBhZGRpdG9uYWwgb3B0aW9uYWwgYml0cyBtYXkgYmUgYWRkZWQg dG8gc3VwcG9ydCBleHRlbnNpb25zIJcAAFJhcHBvcnRldXIsIElUVS1UIFEyMy8xNiAtIE1yLiBE YXZlIExpbmRiZXJnaCwgUG9seWNvbSBJbmMuLCAxMDAgTWludXRlbWFuIFJvYWQsIEFuZG92ZXIg TUEgMDE4NjcgVVNBLiAgVGVsOiArMSA5NzggMjkyIDUzNjYsIEVtYWlsOiBMaW5kYmVyZ2hAOTJG MS5jb20GAABOb3RlIDgHAABOb3RlIDg6aQAAQ29uZm9ybWFuY2UgcHJvY2VkdXJlIGFuZCByZWZl cmVuY2UgQyBzb3VyY2UgY29kZSBhcmUgYSBwYXJ0IG9mIElTTy9JRUMgMTQ0OTYtNCBhbmQgMTQ0 OTYtNSwgcmVzcGVjdGl2ZWx5VgAAQ29uZm9ybWFuY2UgcHJvY2VkdXJlIGFuZCByZWZlcmVuY2Ug QyBzb3VyY2UgY29kZSBpbiBILjI2NC4xIGFuZCBILjI2NC4yLCByZXNwZWN0aXZlbHkqAAAzR1BQ IEV4dGVuZGVkIEFkYXB0aXZlIE11bHRpLVJhdGUgV2lkZWJhbmRFAABFbmNvZGVyIDEwIChtb25v KSB0byA0OCAoc3RlcmVvKTsgZGVjb2RlciBjb21wYXRpYmxlIHRvIEFBQywgSEUtQUFDLCA9AAAx MC40IHRvIDI0IGZvciBtb25vLCBhZGRpdGlvbmFsIDIgdG8gOCBmb3Igc3RlcmVvICAgICAgICAg ICAqCAAAWS9ZL1kgKioKAAAxNiwgMjQsIDQ4DAAAMjA0OCBzYW1wbGVzCQAAMjAgbXNlYyAqCQAA U2VlIGFib3ZlDAAATSwgUk4sIFMsIFNCDgAAWSwgTiAoMiBtb2RlcykfAABFbmNvZGVyIDMyLCA0 ODsgZGVjb2RlciA4IHRvIDQ4FgAAbW9ubyAxMDAsIHN0ZXJlbyAxMzAgKm0AAEVuY29kZXIgbW9u byA1NCwgc3RlcmVvIDcwLCBsb3ctY29tcGxleGl0eSBlbmNvZGVyIG1vbm8gMzMuMyBzdGVyZW8g NTAsIGRlY29kZXIgbW9ubyA4Ljggc3RlcmVvIDE2LjYgV01PUFMgICoDAABOL0FKAABOL0EgPSBO b3QgQXBwbGljYWJsZSAodXN1YWxseSBiZWNhdXNlIG5vIGZsb2F0aW5nIHBvaW50IHZlcnNpb24g ZXZhbHVhdGVkKTYAAEVuY29kZXIgODcuNCwgZGVjb2RlciA0NS4yIHRvIDUzLjQgKFJBTSBhbmQg VGFibGUgUk9NKSwAAEVuY29kZXIgNzIsIGRlY29kZXIgNTQuNiAoUkFNIGFuZCBUYWJsZSBST00p PABrFRkAAEVuY29kZXIgMTMuNiwgZGVjb2RlciA5Ljg5AABFbmNvZGVyIDI1LjQxIHRvIDY1Ljg3 LCBkZWNvZGVyIDE0LjI1IHRvIDM1LjgzIHBlYWsgV01PUFMcAABDb2RlYyBpZGVudGljYWwgdG8g SEUtQUFDIHYyCgAAVGVjaG5vbG9neQUAAH4wLjAyBwAATEQtQ0VMUAgAAENTLUFDRUxQBwAAbG9n IFBDTQQAAH4wLjMZAAAxOCBNSVBTICh+MTMgZm9yIEFubmV4IEEpDgAATVBDLU1MUSwgQUNFTFAE AAB+NC4yBgAARkItTFBDBgAAMjUsIDQwAgAAfjgQAAB+MTUgYW5kIH4xOCBNSVBTBQAAWS8/Lz8F AABBQ0VMUAIAAH41CAAAfjE1IE1JUFMFAABSQ0VMUAgAAH4yNSBNSVBTBAAAQ0VMUAgAAH4yMiBN SVBTAwAATUxUDgAAU3ViLWJhbmQgQURQQ00HAABOb3RlIDk6VQAAdmFyaWFibGUgZm9yIGxvc3Ns ZXNzIHJlY29uc3RydWN0aW9uLCBjYW4gYmUgbGltaXRlZCBmb3IgbmVhci1sb3NzbGVzcyByZWNv bnN0cnVjdGlvbhgAADEwMjQsIDIwNDgsIDQwOTYgc2FtcGxlcwgAAE5vdGUgMTQ6IAAAc3VwcG9y dHMgbG9zc2xlc3MgcmVjb25zdHJ1Y3Rpb24mAABWQUQvRFRYL0NORyBpcyBsaW1pdGVkIHRvIEFN UldCIG1vZGVzLggAAE5vdGUgMTE6LwAATWVkaWEgQ29kaW5nIFN1bW1hcnkgRGF0YWJhc2UgLSBJ VFUtVCBTRzE2IFEuMjNdAABDaGFpciwgM0dQUDIgVFNHLUMxLjEgLSBNci4gRnJhbmsgQ29yY29y YW4gPGZyYW5rLmV4Y3NjdGRAd29ybGRuZXQuYXR0Lm5ldD4sICsgMSAzMDEgMjE2IDIyODIGAABW QywgVEMEAABULjg2UQAASW5kaWNhdGVzIGEgY29tbW9ubHktdXNlZCBuaWNrbmFtZSBvciBhYmJy ZXZpYXRpb24gZm9yIHRoZSBjb2RpbmcgdGVjaG5pcXVlIHVzZWQuBwAARy43MjlFVhQAAEVWLUNF TFAgK1REQldFKyBNRENUBwAAMjAwNi0wNC0AADgsIDEyLCAxNCwgMTYsIDE4LCAyMCwgMjIsIDI0 LCAyNiwgMjgsIDMwLCAzMgcAADIwMDYtMTEjAAA1MC00MDAwICg4LTEyIGspICA1MC03MDAwICgx NC0zMiBrKRsAAFQsIEQsIFNWRCwgViwgVkMsIFRDLCBTLCBWVAYAAFllbGxvdxUAAEZpeGVkLXBv aW50IHNvZnR3YXJlPxgAAEZsb2F0aW5nLXBvaW50IHNvZnR3YXJlP2QAAEluZGljYXRlcyBpZiBi aXQtZXhhY3QgZml4ZWQtcG9pbnQgc29mdHdhcmUgaXMgcHVibGlzaGVkIGFuZCBwdWJsaWNseSBh dmFpbGFibGUgZm9yIGVuY29kZXIvZGVjb2Rlci4DAABZL1kDAABOL05nAABJbmRpY2F0ZXMgaWYg cmVmZXJlbmNlIGZsb2F0aW5nLXBvaW50IHNvZnR3YXJlIGlzIHB1Ymxpc2hlZCBhbmQgcHVibGlj bHkgYXZhaWxhYmxlIGZvciBlbmNvZGVyL2RlY29kZXIuMgAAMzUuOCAoYmFzZWQgb24gU1RMIDIw MDUpLCAzNC43IChiYXNlZCBvbiBTVEwgMjAwMCkFAABULjg1MRYAAElTTyAxMDY0NiB8IElUVS1U IFQuNTUHAAAyMDA1LTA4DQAAUmFwcC4sIFEyMy8xNgMAAFQuNgcAAGVuYy9kZWMIAABOb3RlIDEy OgcAADEsIDMsMTIiAABDIHNvdXJjZSBjb2RlIGF2YWlsYWJsZSBpbiBTVEwyMDA1EwAAUywgVEMs IFZDLCBWVCwgVywgVjYAAGRlcGVuZHMgb24gc2FtcGxlIHJhdGUsIG51bWJlciBvZiBjaGFubmVs cywgc2VlIE5vdGUgNxAAADk2MCwxMDI0IHNhbXBsZXMQAAA0ODAsIDUxMiBzYW1wbGVzEQAAOTYw LCAxMDI0IHNhbXBsZXMIAABOb3RlIDEzOh8AADIuNTYyNSpmcmFtZXMgKyBiaXRyZXMgKE5vdGUx MykVAABNUEVHLTQgQUFDIExDIChBT1QgMikWAABNUEVHLTQgQUFDIExEIChBT1QgMjMpFwAATVBF Ry00IEFBQyBTQ0FMIChBT1QgNikZAABtYXggaGFsZiBvZiBzYW1wbGluZyByYXRlKAAATVBFRy00 IFNjYWxhYmxlIExvc3NsZXNzIENvZGluZyAoQU9UIDM3KY0AAERlcGVuZGluZyBvbiB0aGUgZGVz aXJlZCB0YXJnZXQgZGVsYXksIHRoZSB1c2Ugb2YgdGhlIGJpdCByZXNlcnZvaXIgbWlnaHQgYmUg bWluaW1pemVkLiBBcyBvbmUgZXh0cmVtZSBjYXNlLCBubyBiaXQgcmVzZXJ2b2lyIGlzIHVzZWQg YXQgYWxsLq4ACAIATWF4LiBCaXRyZXNlcnZvaXIgYml0cmVzIGZvciBhbnkgQUFDIHJlbGF0ZWQg Y29kZWM6IGJpdHJlcz0oNjE0NCpuQ2hhbi1iaXRzUGVyRnJhbWUpOyAgYml0c1BlckZyYW1lID0g Yml0UmF0ZSpzYW1wbGVzUGVyRnJhbWUvZnM7ICBmcz1zYW1wbGUgcmF0ZTsgIG5DaGFuPSBOdW1i ZXIgb2YgY2hhbm5lbHM7HQARADIAAAAeAABNUEVHLTIgTGF5ZXIgSUkgIG11bHRpLWNoYW5uZWwV AABhbnkgKDgtMTkyIGtIeiByYW5nZSkKAABNUEVHLTQgQUFDFAAATVBFRy00IExvdyBEZWxheSBB QUMTAABNUEVHLTQgQUFDIHNjYWxhYmxlJQAATVBFRy00IFNjYWxhYmxlIExvc3NsZXNzIENvZGlu ZyAoU0xTKRUAAE1QRUctNCBIRS1BQUMgb3IgQUFDKxkAAE1QRUctNCBIRS1BQUMtVjIgb3IgZUFB QysqAABJU08vSUVDIDE0NDk2LTMgYW5kIDNHUFAgRW5oYW5jZWQgQUFDIFBsdXNFAABFbmNvZGVy IDEyNTQwLzE0MzY1LCBkZWNvZGVyIDYyMDkvODA0OCBiYXNpYyBvcGVyYXRpb25zIChtb25vL3N0 ZXJlbykaAABNUEVHLTIgQXVkaW8gTGF5ZXIgMyAoTVAzKRoAAE1QRUctMSBBdWRpbyBMYXllciAz IChNUDMpFAAATVBFRy0xIEF1ZGlvIExheWVyIDIUAABNUEVHLTEgQXVkaW8gTGF5ZXIgMQ4AAE1Q RUctMSBMYXllciAxDgAATVBFRy0xIExheWVyIDIOAABNUEVHLTEgTGF5ZXIgMxQAAE1QRUctMiBB dWRpbyBMYXllciAxFAAATVBFRy0yIEF1ZGlvIExheWVyIDInAABNUEVHLTIgTGF5ZXIgMSBMU0Yg KExvdyBTYW1wbGluZyBGcmVxLiknAABNUEVHLTIgTGF5ZXIgMiBMU0YgKExvdyBTYW1wbGluZyBG cmVxLiknAABNUEVHLTIgTGF5ZXIgMyBMU0YgKExvdyBTYW1wbGluZyBGcmVxLikyAABNUEVHLTIg QmFja3dhcmQgQ29tcGF0aWJsZSAoQkMpIE11bHRpY2hhbm5lbCBBdWRpbyYAAE1QRUctNCBIRS1B QUMgSEUtQUFDIFByb2ZpbGUgKEFPVCAyLDUpKQAATVBFRy00IEhFLUFBQyBIRS1BQUMgUHJvZmls ZSAoQU9UIDIsNSwyOSkfAABNYXggYml0IHJhdGVzIGZyb3IgTVBFRy0yLDQgQUFDDQAARVZSQy1C IChDRE1BKQ4AAEVWUkMtV0IgKENETUEpIAAARW5oYW5jZWQgVmFyaWFibGUgUmF0ZSBDb2RlYyAt IEIjAABSQ0VMUCwgV0ksIE5FTFAsIEZhY3RvcmlhbCBDb2RlYm9vaxkAAFJDRUxQLCBGYWN0b3Jp YWwgQ29kZWJvb2sVAABNLCBQLCBTLCBULCBUQywgViwgVlQSAABNLCBQLCBTLCBULCBUQywgVlQT AAAwLjgsIDIuMCwgNC4wLCA4LjU1BAAAOCwxNg0AAEVWUkMtQSAoQ0RNQSkHAAAxLCAzLCA0BQAA ZUFBQysVAAAzR1BQIEVuaGFuY2VkIGFhY1BsdXMDAAB0YmQMAAAqIDEwLCAgKiogMTFFAAgCAEVu Y29kZXIgMTI1NDAvMTQzNjUsIGRlY29kZXIgNjIwOS84MDQ4IGJhc2ljIG9wZXJhdGlvbnMgKG1v bm8vc3RlcmVvKS0ABQA3AAAAGwAAM0dQUDIgQy5TMDAxNC1BLCBBTlNJIElTMTI3JwAARW5oYW5j ZWQgVmFyaWFibGUgUmF0ZSBDb2RlYyAtIFdpZGViYW5kDwAAM0dQUDIgQy5TMDA1Mi1BDQAAVk1S LVdCIChDRE1BKQUAAFZDRUxQIQAASVRVLVQgRy43MjkuMQpJVFUtVCBHLjcyOSBBbm5leCBKQQAA UmF0ZSBTZXQgMjogCjEuMCwgMi43LCA2LjIsIDEzLjMKUmF0ZSBTZXQgMTogCjAuOCwgMi4wLCA0 LjAsIDguNTUPAABZIChMQikgLyBZIChIQikHAAAyMDA3LTA4DQAAMjUgdG8gNDgsOTM3NREABBAA AABNaW4uIFBpY3R1cmUgU2l6ZQEADAAHADcAAAAAAAAAAAABAAQQAAAAWQEADAAHADcAAAAAAAAA AAAnAABTb3VyY2U6IFJhcHBvcnRldXIsIFEuMjMvMTYgKEguIFRhZGRlaSkHAAQQAAAARy43MTEu MQEADAAHADcAAAAAAAAAAAANAAQQAAAASVRVLVQgRy43MTEuMQEADAAHADcAAAAAAAAAAAASAAwC ABAAAABTdWItYmFuZCBQQ00sIE1EQ1QJAAEACgAAAAEADAAHADcAAAAAAAAAAAABAAQQAAAATgEA DAAHADcAAAAAAAAAAAAFAAQQAAAAVCwgVEMBAAwABwA3AAAAAAAAAAAAAQAEEAAAAEEBAAwABwA3 AAAAAAAAAAAACgAEEAAAADY0LCA4MCwgOTYBAAwABwA3AAAAAAAAAAAABQAEEAAAAE4vTi9OAQAM AAcANwAAAAAAAAAAAAYABBAAAAA1IG1zZWMBAAwABwA3AAAAAAAAAAAACgAEEAAAADguNzAgV01P UFMBAAwABwA3AAAAAAAAAAAAAwAEEAAAAE4vQQEADAAHADcAAAAAAAAAAAAaAAQQAAAARW5jb2Rl ciAxLjY4LCBkZWNvZGVyIDIuMjABAAwABwA3AAAAAAAAAAAAFAAEEAAAADE5NDMgYmFzaWMgb3Bl cmF0b3JzAQAMAAcANwAAAAAAAAAAAAMABBAAAABZL1kBAAwABwA3AAAAAAAAAAAAAwAEEAAAAE4v TgEADAAHADcAAAAAAAAAAAAFAAQQAAAASVRVLVQBAAwABwA3AAAAAAAAABgABQAARy43MTgLAABJ VFUtVCBHLjcxOAwAAEFDRUxQLCBNRENULAcAADIwMDgtMDY7AAA4LDEyLDE2LDI0LDMyICYgMTIu NjUoRy43MjIuMiwgQU1SLVdCLCBWTVItV0IgSW50ZXJvcCBNb2RlKRAAADMyLjg3NSB0byA0My44 NzUIAAA2OSBXTU9QUw4AAFE0LzA4IG9yIFExLzA5BQAARy43MTkLAABJVFUtVCBHLjcxOR4AAEFk YXB0aXZlIHJlc29sdXRpb24gTURDVCwgRkxWUQgAADIwLTIwMDAwQgAAMzIuLi4xMjggc3RlcHMg b2YgNGticHMgdXAgdG8gOTZrYnBzLCBzdGVwcyBvZiA4a2JwcyB1cCB0byAxMjhrYnBzEAAAMTUu MzkgLSAyMSBXTU9QUx4AADEyLjU0LTE3LjY3IE1DUFMgKG9uIFZMSVcgRFNQKQcAAHBlbmRpbmcI AABOb3RlIDE3Op4AAEcuNzE4IGhhcyBhIGJpdHN0cmVhbSBpbnRlcm9wZXJhYmxlIG1vZGUgYWxs b3dpbmcgaXQgdG8gb3BlcmF0ZSBhdCBhIGNvcmUgYml0IHJhdGUgb2YgMTIuNjUga2IvcyB3aGlj aCBpcyBhIGNvbW1vbiBiaXRyYXRlIGJldHdlZW4gRy43MjIuMiwgQU1SLVdCIGFuZCBWTVItV0Iu HQAATVBFRy00IEVuaGFuY2VkIExvdyBEZWxheSBBQUMXAABNUEVHLTQgQUFDIEVMRCAoQU9UIDM5 KR0AADQ4MCwgNTEyIG9yIDk2MCwgMTAyNCBzYW1wbGVzpAAASW4gY2FzZSBvZiB0aGUgdXNhZ2Ug b2YgU0JSLCB0aGUgZnJhbWUgc2l6ZSBvZiB0aGUgY29kZWMgbWlnaHQgYmUgZG91YmxlZCBhbmQg YWRkdGlvbmFsIDY0IHNhbXBsZXMgY29tZSB0byB0aGUgYWxnb3JpdGhtaWMgZGVsYXkgZHVlIHRv IHRoZSBTQlIgcG9zdHByb2Nlc3Npbmcgc3RlcC4IAAQQAAAATm90ZSAxODoBAAwABwA3AAAAAAAA AP8ALQAMAgAQAAAAMS41KmZyYW1lcyBvciAyKjEuNSpmcmFtZXMrNjQgKE5vdGUgMTMsMTYsMTgp KwAAACwAAQABAAwABwA3AAAAAAAAAAAAEAAMAQAQAAAANywxMywgMTUsIDE2LCAxOA8AAAABAAwA BwA3AAAAAAAAAAAACwAEEAAAAFkgKE5vdGUgMTUpAQAMAAcANwAAAAAAAAAAAAwADAIAEAAAACBZ IChOb3RlIDE1KQEAAAADAAEAAQAMAAcANwAAAAAAAAAAABYABBAAAABHZW5ldmEsIDMgT2N0b2Jl ciAyMDA4AQAMAAcANwAAAAAAAAAAAFcABBAAAABDb250YWN0OiBIZXJ26SBUYWRkZWksIEh1YXdl aSBUZWNobm9sb2dpZXMsICs0OSAxNjIgMjk0MCAyNjAsIDxoZXJ2ZS50YWRkZWlAaHVhd2VpLmNv bT4BAAwABwA3AAAAAAAAAAAATgAMAgAQAAAASW5mb3JtYXRpb24gdXBkYXRlZCBzaW5jZSBwcmV2 aW91cyB2ZXJzaW9uIC0gbmVlZHMgcmV2aWV3IGFuZCBhcHByb3ZhbCBieSBTRzE2HAAAAB0ABgAB AAwABwA3AAAAAAAAAAAA/wDaAggAPS4AAAwAAACGMAAAVQIAAOQwAACzAgAAJDIAAPMDAACPMgAA XgQAANMyAACiBAAArjMAAH0FAABCNAAAEQYAAKQ0AABzBgAA8DQAAL8GAADcNQAAqwcAAH82AABO CAAAcDgAAD8KAAByOgAAQQwAAMs7AACaDQAA/zsAAM4NAABvPAAAPg4AAL48AACNDgAAxj0AAJUP AABcPgAAKxAAALY/AACFEQAAH0AAAO4RAABuQgAAPRQAAHdDAABGFQAASkQAABkWAACYRAAAZxYA APJEAADBFgAAaUUAADgXAADoRQAAtxcAADZGAAAFGAAA+EYAAMcYAABfRwAALhkAALJHAACBGQAA oEgAAG8aAABuSQAAPRsAAGJKAAAxHAAALUwAAPwdAABVTgAABAAAABdQAADGAQAA2FAAAIcCAAAC VAAAsQUAAJdVAABGBwAAiFYAADcIAABYVwAABwkAAM5XAAB9CQAAZFgAABMKAADgWAAAjwoAAFhZ AAAHCwAAaFoAABcMAAAcWwAAywwAAMNcAAByDgAAg14AADIQAADpXgAAmBAAAAxgAAC7EQAAvmAA AG0SAABvYQAAHhMAABZiAADFEwAAdWIAACQUAAA3ZAAA5hUAAFVlAAAEFwAAA2YAALIXAADNZgAA fBgAABtnAADKGAAAdGcAACMZAAAMaAAAuxkAAK5oAABdGgAAnmsAAE0dAADfbAAAjh4AAAluAAC4 HwAAC28AAJoAAABtbwAA/AAAALhvAABHAQAAaXAAAPgBAAC2cQAARQMAAGhyAAD3AwAAtXMAAEQF AAAydAAAwQUAAAB1AACPBgAA/nYAAI0IAAAJeAAAmAkAALt4AABKCgAA/HkAAIsLAADFegAAVAwA AG17AAD8DAAAWXwAAOgNAABSfQAA4Q4AADN+AADCDwAABH8AAJMQAACyfwAAQREAAAyBAACbEgAA 1oIAAGUUAABjCBYAYwgAAAAAAAAAAAAAFgAAAAAAAACSAHwIFAB8CAAAAAAAAAAAAAAAAMsAI5tC 530ILQB9CAAAAAAAAAAAAAAAADYAAAACAA0AFAADAAAAAwAAAAAwADAAXwApDgAFAAF9CEEAfQgA AAAAAAAAAAAAAAA3AAAAAwANABQAAwAAAAMAAAAAMAAwAF8AKQ4ABQACCAAUAAMAAAAEAAAAWwAk AKwgLQB9CEEAfQgAAAAAAAAAAAAAAAA4AAAAAwANABQAAwAAAAMAAAAAMAAwAF8AKQ4ABQACCAAU AAMA/z8EAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAA5AAAAAwANABQAAwAAAAMAAAAAMAAw AF8AKQ4ABQACCAAUAAMAMjMEAAAAWwAkAKwgLQB9CC0AfQgAAAAAAAAAAAAAAAA6AAAAAgANABQA AwAAAAMAAAAAMAAwAF8AKQ4ABQACfQhBAH0IAAAAAAAAAAAAAAAAMAAAAAMADQAUAAIAAAAAYQD/ ADAAMABfACkOAAUAAgQAFAACAAAAxu/O/1sAJACsIC0AfQhBAH0IAAAAAAAAAAAAAAAANQAAAAMA DQAUAAIAAACcAAb/ADAAMABfACkOAAUAAgQAFAACAAAA/8fO/1sAJACsIC0AfQhBAH0IAAAAAAAA AAAAAAAAMgAAAAMADQAUAAIAAACcZQD/ADAAMABfACkOAAUAAgQAFAACAAAA/+uc/1sAJACsIC0A fQiRAH0IAAAAAAAAAAAAAAAALQAAAAcADQAUAAIAAAA/P3b/ADAAMABfACkOAAUAAgQAFAACAAAA /8yZ/1sAJACsIC0ABwAUAAIAAAB/f3//IwAjADAALgAIABQAAgAAAH9/f/8tADsAXwAtAAkAFAAC AAAAf39//0AAXwAtAEAACgAUAAIAAAB/f3//AAAAAAAAAAB9CJEAfQgAAAAAAAAAAAAAAAAoAAAA BwANABQAAgAAAD8/P/8AMAAwAF8AKQ4ABQACBAAUAAIAAADy8vL/WwAkAKwgLQAHABQAAgAAAD8/ P/8jACMAMAAuAAgAFAACAAAAPz8//y0AOwBfAC0ACQAUAAIAAAA/Pz//QABfAC0AQAAKABQAAgAA AD8/P/8AAAAAAAAAAH0IkQB9CAAAAAAAAAAAAAAAACkAAAAHAA0AFAACAAAA+n0A/wAwADAAXwAp DgAFAAIEABQAAgAAAPLy8v9bACQArCAtAAcAFAACAAAAf39//yMAIwAwAC4ACAAUAAIAAAB/f3// LQA7AF8ALQAJABQAAgAAAH9/f/9AAF8ALQBAAAoAFAACAAAAf39//wAAAAAAAAAAfQhBAH0IAAAA AAAAAAAAAAAAOwAAAAMADQAUAAIAAAD6fQD/ADAAMABfACkOAAUAAggAFAACAAAA/4AB/1sAJACs IC0AfQiRAH0IAAAAAAAAAAAAAAAAPwAAAAcADQAUAAMAAAAAAAAAADAAMABfACkOAAUAAgQAFAAC AAAApaWl/1sAJACsIC0ABwAUAAIAAAA/Pz//IwAjADAALgAIABQAAgAAAD8/P/8tADsAXwAtAAkA FAACAAAAPz8//0AAXwAtAEAACgAUAAIAAAA/Pz//AAAAAAAAAAB9CC0AfQgAAAAAAAAAAAAAAAA+ AAAAAgANABQAAgAAAP8AAP8AMAAwAF8AKQ4ABQACfQh4AH0IAAAAAAAAAAAAAAAAMwAAAAUABAAU AAIAAAD//8z/ADAAMABfACkHABQAAgAAALKysv8ApaWl/1sAJAgAFAACAAAAsrKy/wA/Pz//IwAj CQAUAAIAAACysrL/AD8/P/8tADsKABQAAgAAALKysv8APz8//0AAX30ILQB9CAAAAAAAAAAAAAAA AC8AAAACAA0AFAACAAAAf39//wAwADAAXwApDgAFAAJ9CFUAfQgAAAAAAAAAAAAAAAAuAAAABAAN ABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBwAUAAMAAAAEAAAAWwAkCAAUAAIIABQAAwAAAAQAAAAj ACMJABQAAn0IQQB9CAAAAAAAAAAAAAAAACIAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIE ABQAAwAAAAQAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABAAAAADAA0AFAADAAAAAQAAAAAw ADAAXwApDgAFAAIEABQAAwBlZgQAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABYAAAADAA0A FAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwDMTAQAAABbACQIABQAAn0IQQB9CAAAAAAAAAAA AAAAABwAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAyMwQAAABbACQIABQAAn0I QQB9CAAAAAAAAAAAAAAAACMAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAAAAUA AABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABEAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAF AAIEABQAAwBlZgUAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABcAAAADAA0AFAADAAAAAQAA AAAwADAAXwApDgAFAAIEABQAAwDMTAUAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAAB0AAAAD AA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAyMwUAAABbACQIABQAAn0IQQB9CAAAAAAA AAAAAAAAACQAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAAAAYAAABbACQIABQA An0IQQB9CAAAAAAAAAAAAAAAABIAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwBl ZgYAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABgAAAADAA0AFAADAAAAAQAAAAAwADAAXwAp DgAFAAIEABQAAwDMTAYAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAAB4AAAADAA0AFAADAAAA AAAAAAAwADAAXwApDgAFAAIEABQAAwAyMwYAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAACUA AAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAAAAcAAABbACQIABQAAn0IQQB9CAAA AAAAAAAAAAAAABMAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwBlZgcAAABbACQI ABQAAn0IQQB9CAAAAAAAAAAAAAAAABkAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQA AwDMTAcAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAAB8AAAADAA0AFAADAAAAAAAAAAAwADAA XwApDgAFAAIEABQAAwAyMwcAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAACYAAAADAA0AFAAD AAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAAAAgAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAA ABQAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwBlZggAAABbACQIABQAAn0IQQB9 CAAAAAAAAAAAAAAAABoAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwDMTAgAAABb ACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAACAAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIE ABQAAwAyMwgAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAACcAAAADAA0AFAADAAAAAAAAAAAw ADAAXwApDgAFAAIEABQAAwAAAAkAAABbACQIABQAAn0IQQB9CAAAAAAAAAAAAAAAABUAAAADAA0A FAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwBlZgkAAABbACQIABQAAn0IQQB9CAAAAAAAAAAA AAAAABsAAAADAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAIEABQAAwDMTAkAAABbACQIABQAAn0I QQB9CAAAAAAAAAAAAAAAACEAAAADAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIEABQAAwAyMwkA AABbACQIABQAApIITQCSCAAAAAAAAAAAAAABBB7/DQAyADAAJQAgAC0AIABBAGsAegBlAG4AdAAx AAAAAwABAAwABwRlZtvl8f8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBCL/DQAy ADAAJQAgAC0AIABBAGsAegBlAG4AdAAyAAAAAwABAAwABwVlZvLd3P8FAAwABwEAAAAAAP8lAAUA ApIITQCSCAAAAAAAAAAAAAABBCb/DQAyADAAJQAgAC0AIABBAGsAegBlAG4AdAAzAAAAAwABAAwA BwZlZurx3f8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBCr/DQAyADAAJQAgAC0A IABBAGsAegBlAG4AdAA0AAAAAwABAAwABwdlZuXg7P8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAA AAAAAAAAAAABBC7/DQAyADAAJQAgAC0AIABBAGsAegBlAG4AdAA1AAAAAwABAAwABwhlZtvu8/8F AAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBDL/DQAyADAAJQAgAC0AIABBAGsAegBl AG4AdAA2AAAAAwABAAwABwllZv3p2f8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAAB BB//DQA0ADAAJQAgAC0AIABBAGsAegBlAG4AdAAxAAAAAwABAAwABwTMTLjM5P8FAAwABwEAAAAA AP8lAAUAApIITQCSCAAAAAAAAAAAAAABBCP/DQA0ADAAJQAgAC0AIABBAGsAegBlAG4AdAAyAAAA AwABAAwABwXMTOa5uP8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBCf/DQA0ADAA JQAgAC0AIABBAGsAegBlAG4AdAAzAAAAAwABAAwABwbMTNfkvP8FAAwABwEAAAAAAP8lAAUAApII TQCSCAAAAAAAAAAAAAABBCv/DQA0ADAAJQAgAC0AIABBAGsAegBlAG4AdAA0AAAAAwABAAwABwfM TMzA2v8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBC//DQA0ADAAJQAgAC0AIABB AGsAegBlAG4AdAA1AAAAAwABAAwABwjMTLbd6P8FAAwABwEAAAAAAP8lAAUAApIITQCSCAAAAAAA AAAAAAABBDP/DQA0ADAAJQAgAC0AIABBAGsAegBlAG4AdAA2AAAAAwABAAwABwnMTPzVtP8FAAwA BwEAAAAAAP8lAAUAApIITQCSCAAAAAAAAAAAAAABBCD/DQA2ADAAJQAgAC0AIABBAGsAegBlAG4A dAAxAAAAAwABAAwABwQyM5Wz1/8FAAwABwAAAP////8lAAUAApIITQCSCAAAAAAAAAAAAAABBCT/ DQA2ADAAJQAgAC0AIABBAGsAegBlAG4AdAAyAAAAAwABAAwABwUyM9mXlf8FAAwABwAAAP////8l AAUAApIITQCSCAAAAAAAAAAAAAABBCj/DQA2ADAAJQAgAC0AIABBAGsAegBlAG4AdAAzAAAAAwAB AAwABwYyM8LWmv8FAAwABwAAAP////8lAAUAApIITQCSCAAAAAAAAAAAAAABBCz/DQA2ADAAJQAg AC0AIABBAGsAegBlAG4AdAA0AAAAAwABAAwABwcyM7Khx/8FAAwABwAAAP////8lAAUAApIITQCS CAAAAAAAAAAAAAABBDD/DQA2ADAAJQAgAC0AIABBAGsAegBlAG4AdAA1AAAAAwABAAwABwgyM5PN 3f8FAAwABwAAAP////8lAAUAApIITQCSCAAAAAAAAAAAAAABBDT/DQA2ADAAJQAgAC0AIABBAGsA egBlAG4AdAA2AAAAAwABAAwABwkyM/rAkP8FAAwABwAAAP////8lAAUAApIIQQCSCAAAAAAAAAAA AAABBB3/BwBBAGsAegBlAG4AdAAxAAAAAwABAAwABwQAAE+Bvf8FAAwABwAAAP////8lAAUAApII QQCSCAAAAAAAAAAAAAABBCH/BwBBAGsAegBlAG4AdAAyAAAAAwABAAwABwUAAMBQTf8FAAwABwAA AP////8lAAUAApIIQQCSCAAAAAAAAAAAAAABBCX/BwBBAGsAegBlAG4AdAAzAAAAAwABAAwABwYA AJu7Wf8FAAwABwAAAP////8lAAUAApIIQQCSCAAAAAAAAAAAAAABBCn/BwBBAGsAegBlAG4AdAA0 AAAAAwABAAwABwcAAIBkov8FAAwABwAAAP////8lAAUAApIIQQCSCAAAAAAAAAAAAAABBC3/BwBB AGsAegBlAG4AdAA1AAAAAwABAAwABwgAAEusxv8FAAwABwAAAP////8lAAUAApIIQQCSCAAAAAAA AAAAAAABBDH/BwBBAGsAegBlAG4AdAA2AAAAAwABAAwABwkAAPeWRv8FAAwABwAAAP////8lAAUA ApIIeQCSCAAAAAAAAAAAAAABAhX/BwBBAHUAcwBnAGEAYgBlAAAABwABAAwABf8AAPLy8v8FAAwA Bf8AAD8/P/8lAAUAAgYADgAF/wAAPz8//wEABwAOAAX/AAA/Pz//AQAIAA4ABf8AAD8/P/8BAAkA DgAF/wAAPz8//wEAkgh/AJIIAAAAAAAAAAAAAAECFv8KAEIAZQByAGUAYwBoAG4AdQBuAGcAAAAH AAEADAAF/wAA8vLy/wUADAAF/wAA+n0A/yUABQACBgAOAAX/AAB/f3//AQAHAA4ABf8AAH9/f/8B AAgADgAF/wAAf39//wEACQAOAAX/AAB/f3//AQCSCDwAkggAAAAAAAAAAAAAAQIJ/xMAQgBlAHMA dQBjAGgAdABlAHIAIABIAHkAcABlAHIAbABpAG4AawAAAAAAkggkAJIIAAAAAAAAAAAAAAEFA/8H AEQAZQB6AGkAbQBhAGwAAAAAAJIILACSCAAAAAAAAAAAAAABBQb/CwBEAGUAegBpAG0AYQBsACAA WwAwAF0AAAAAAJIIeQCSCAAAAAAAAAAAAAABAhT/BwBFAGkAbgBnAGEAYgBlAAAABwABAAwABf8A AP/Mmf8FAAwABf8AAD8/dv8lAAUAAgYADgAF/wAAf39//wEABwAOAAX/AAB/f3//AQAIAA4ABf8A AH9/f/8BAAkADgAF/wAAf39//wEAkghTAJIIAAAAAAAAAAAAAAEDGf8IAEUAcgBnAGUAYgBuAGkA cwAAAAQABQAMAAcBAAAAAAD/JQAFAAIGAA4ABwQAAE+Bvf8BAAcADgAHBAAAT4G9/wYAkghHAJII AAAAAAAAAAAAAAECNf8QAEUAcgBrAGwA5AByAGUAbgBkAGUAcgAgAFQAZQB4AHQAAAACAAUADAAF /wAAf39//yUABQACkgg5AJIIAAAAAAAAAAAAAAEBGv8DAEcAdQB0AAAAAwABAAwABf8AAMbvzv8F AAwABf8AAABhAP8lAAUAApIIKACSCAAAAAAAAAAAAAABAgj/CQBIAHkAcABlAHIAbABpAG4AawAA AAAAkghBAJIIAAAAAAAAAAAAAAEBHP8HAE4AZQB1AHQAcgBhAGwAAAADAAEADAAF/wAA/+uc/wUA DAAF/wAAnGUA/yUABQACkghkAJIIAAAAAAAAAAAAAAECCv8FAE4AbwB0AGkAegAAAAUAAQAMAAX/ AAD//8z/BgAOAAX/AACysrL/AQAHAA4ABf8AALKysv8BAAgADgAF/wAAsrKy/wEACQAOAAX/AACy srL/AQCSCCQAkggAAAAAAAAAAAAAAQUF/wcAUAByAG8AegBlAG4AdAAAAAAAkghDAJIIAAAAAAAA AAAAAAEBG/8IAFMAYwBoAGwAZQBjAGgAdAAAAAMAAQAMAAX/AAD/x87/BQAMAAX/AACcAAb/JQAF AAKSCCYAkggAAAAAAAAAAAAAAQEA/wgAUwB0AGEAbgBkAGEAcgBkAAAAAACSCD0AkggAAAAAAAAA AAAAAQMP/wsA3ABiAGUAcgBzAGMAaAByAGkAZgB0AAAAAgAFAAwABwMAAB9Jff8lAAUAAZIITwCS CAAAAAAAAAAAAAABAxD/DQDcAGIAZQByAHMAYwBoAHIAaQBmAHQAIAAxAAAAAwAFAAwABwMAAB9J ff8lAAUAAgcADgAHBAAAT4G9/wUAkghPAJIIAAAAAAAAAAAAAAEDEf8NANwAYgBlAHIAcwBjAGgA cgBpAGYAdAAgADIAAAADAAUADAAHAwAAH0l9/yUABQACBwAOAAcE/z+owN7/BQCSCE8AkggAAAAA AAAAAAAAAQMS/w0A3ABiAGUAcgBzAGMAaAByAGkAZgB0ACAAMwAAAAMABQAMAAcDAAAfSX3/JQAF AAIHAA4ABwQyM5Wz1/8CAJIIQQCSCAAAAAAAAAAAAAABAxP/DQDcAGIAZQByAHMAYwBoAHIAaQBm AHQAIAA0AAAAAgAFAAwABwMAAB9Jff8lAAUAApIIVQCSCAAAAAAAAAAAAAABAhj/EABWAGUAcgBr AG4A/ABwAGYAdABlACAAWgBlAGwAbABlAAAAAwAFAAwABf8AAPp9AP8lAAUAAgcADgAF/wAA/4AB /wYAkggkAJIIAAAAAAAAAAAAAAEFBP8HAFcA5ABoAHIAdQBuAGcAAAAAAJIILACSCAAAAAAAAAAA AAABBQf/CwBXAOQAaAByAHUAbgBnACAAWwAwAF0AAAAAAJIIQwCSCAAAAAAAAAAAAAABAgv/DgBX AGEAcgBuAGUAbgBkAGUAcgAgAFQAZQB4AHQAAAACAAUADAAF/wAA/wAA/yUABQACkgiLAJIIAAAA AAAAAAAAAAECF/8QAFoAZQBsAGwAZQAgAPwAYgBlAHIAcAByAPwAZgBlAG4AAAAHAAEADAAF/wAA paWl/wUADAAHAAAA/////yUABQACBgAOAAX/AAA/Pz//BgAHAA4ABf8AAD8/P/8GAAgADgAF/wAA Pz8//wYACQAOAAX/AAA/Pz//BgCOCFgAjggAAAAAAAAAAAAAkAAAABEAEQBUAGEAYgBsAGUAUwB0 AHkAbABlAE0AZQBkAGkAdQBtADkAUABpAHYAbwB0AFMAdAB5AGwAZQBMAGkAZwBoAHQAMQA2AJoI GACaCAAAAAAAAAAAAAABAAAAAAAAAAIAAACjCBAAowgAAAAAAAAAAAAAAAAAAJYIEACWCAAAAAAA AAAAAABC5QEAmwgQAJsIAAAAAAAAAAAAAAEAAACMCBAAjAgAAAAAAAAAAAAAAAAAAAoAAAAJCBAA AAYQAHMgzQfZwAEABgMAAAsCJAAAAAAAAAAAAJIAAADIowAAaasAALmxAAC9uAAA7b0AAF+/AAAN AAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIA AQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDBBBoACAABABcAAAD//xQAAAAVAAAAgwACAAAAhAAC AAAAJgAIAFs0rslkMuk/JwAIAFs0rslkMuk/KAAIAKRwPQrXo+A/KQAIAFK4HoXrUeA/oQAiAAEA NwABAAEAAgAAAMgAyAAAAAAAAADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAANsfRAACAAAAfQAM AAEABQAkCUEAAgAAAH0ADAAGAAYASQxBAAIAAAB9AAwABwAHACQLQQACAAAAfQAMAAgACAAADUgA AgAAAH0ADAAJAAkAbQxIAAIAAAB9AAwACgAKAG0NDwACAAAAfQAMAAsACwAkCQ8AAgAAAH0ADAAM AAwAAAoPAAIAAAB9AAwADQANACQJDwACAAAAfQAMAA4ADgAACg8ABgAAAH0ADAAPAA8AJAkPAAIA AAB9AAwAEAAQAG0LDwACAAAAfQAMABEAEQC2Cg8AAgAAAJAADwAAAAgAAABDb2x1bW4gQsgAAg4A AAAAAJIAAAAAABYAAAAIAhAAAAAAAAwA/wAAAAAAAAEPAAgCEAABAAAADAAsAQAAAAAAAQ8ACAIQ AAIAAAAMAP8AAAAAAAABDwAIAhAAAwAAAAwA/wAAAAAAAAEPAAgCEAAEAAAADAD/AAAAAAAAAQ8A CAIQAAYAAAAMAP8AAAAAAAABDwAIAhAABwAAAAwA/wAAAAAAAAEPAAgCEAAJAAAADAD/AAAAAAAA AQ8ACAIQAAsAAAAMAP8AAAAAAAABDwAIAhAADAAAAAwA/wAAAAAAAAEPAAgCEAANAAAADAD/AAAA AAAAAQ8ACAIQAA4AAAAMAP8AAAAAAAABDwAIAhAADwAAAAwA/wAAAAAAAAEPAAgCEAAQAAAACAD/ AAAAAAAAAQ8ACAIQABEAAAAIAP8AAAAAAAABDwAIAhAAEgAAAAgA/wAAAAAAAAEPAAgCEAATAAAA CAD/AAAAAAAAAQ8ACAIQABQAAAAIAP8AAAAAAAABDwAIAhAAFQAAAAgA/wAAAAAAAAEPAAgCEAAW AAAACAD/AAAAAAAAAQ8ACAIQABcAAAAIAP8AAAAAAAABDwAIAhAAGAAAAAgA/wAAAAAAAAEPAAgC EAAZAAAACAD/AAAAAAAAAQ8ACAIQABoAAAAIAP8AAAAAAAABDwAIAhAAGwAAAAgA/wAAAAAAAAEP AAgCEAAcAAAACAD/AAAAAAAAAQ8ACAIQAB0AAAAIAP8AAAAAAAABDwAIAhAAHgAAAAgA/wAAAAAA AAEPAAgCEAAfAAAACAD/AAAAAAAAAQ8A/QAKAAAAAABEAPcBAAD9AAoAAQAAAFUAQwIAAL4ACgAB AAoAQgBEAAsA/QAKAAIAAABVANACAAD9AAoAAwAAAFUApAIAAL4ACgADAAgAQwBDAAkA/QAKAAQA AABVANECAAD9AAoABgAAAEQA9QEAAP0ACgAGAAEAXAD2AQAA/QAKAAYAAgBBAPgBAAD9AAoABwAB ALMATwIAAP0ACgAHAAIAQQDSAgAA/QAKAAkAAABEAGoAAAD9AAoACwAAAEwAQAAAAP0ACgALAAEA QQBoAAAA/QAKAAwAAABMAEEAAAD9AAoADAABAEEAZwAAAP0ACgANAAAATACmAAAA/QAKAA0AAQBB AGYAAAABAgYADQAHAEYAAQIGAA4AAABMAP0ACgAOAAEAQQBQAAAA/QAKAA4AAgBBAKEBAAABAgYA DgAHAEYAAQIGAA8AAABMAP0ACgAPAAEAQQBEAAAA/QAKAA8AAgBBAOkAAAABAgYADwAHAEYAAQIG ABAAAABMAP0ACgAQAAEADwDfAAAA/QAKABAAAgAPAMMAAAABAgYAEAAHAEYAAQIGABEAAABMAP0A CgARAAEADwCeAQAA/QAKABEAAgAPAJ8BAAABAgYAEQAHAEYAAQIGABIAAABMAP0ACgASAAEADwDe AAAA/QAKABIAAgAPAOsAAAABAgYAEgAHAEYAAQIGABMAAABMAP0ACgATAAEAQQAoAAAA/QAKABMA AgBBAOoAAAABAgYAEwAHAEYAAQIGABQAAABMAP0ACgAUAAEAQQDjAAAA/QAKABQAAgBBAOQAAAAB AgYAFAAHAEYAAQIGABUAAABMAP0ACgAVAAEADwDEAAAA/QAKABUAAgAPAO0AAAABAgYAFQAHAEYA AQIGABYAAABMAP0ACgAWAAEAWADXAQAA/QAKABYAAgBYANgBAAABAgYAFgAHAEYAAQIGABcAAABM AP0ACgAXAAEAQQDnAAAA/QAKABcAAgBBAOgAAAABAgYAFwAHAEYAAQIGABgAAABMAP0ACgAYAAEA QQAjAAAA/QAKABgAAgBBAOIAAAABAgYAGAAHAEYAAQIGABkAAABMAP0ACgAZAAEAQQDlAAAA/QAK ABkAAgBBAOYAAAABAgYAGQAHAEYAAQIGABoAAABMAP0ACgAaAAEADwDFAAAA/QAKABoAAgAPAO8A AAABAgYAGgAHAEYAAQIGABsAAABMAP0ACgAbAAEAQQDhAAAA/QAKABsAAgBBAN0AAAABAgYAGwAH AEYAAQIGABwAAABMAP0ACgAcAAEADwAlAAAA/QAKABwAAgAPAPAAAAABAgYAHAAHAEYAAQIGAB0A AABMAP0ACgAdAAEADwAmAAAA/QAKAB0AAgAPAOwAAAABAgYAHQAHAEYA/QAKAB4AAQAPAOAAAAD9 AAoAHgACAA8A7gAAAAECBgAeAAcARgC+AAoAHwABAA8ADwACAAECBgAfAAcARgDXAD4AlgYAADAC DgAcAA4AHAAOACoAHAAOABwAHAAmADAAMAAwADAAMAAwADAAMAAwADAAMAAwADAAMAAwADAAJgAI AhAAIAAAAAgA/wAAAAAAAAEPAAgCEAAhAAAACAD/AAAAAAAAAQ8ACAIQACIAAAAIAP8AAAAAAAAB DwAIAhAAIwAAAAgA/wAAAAAAAAEPAAgCEAAkAAAACAD/AAAAAAAAAQ8ACAIQACUAAAAIAP8AAAAA AAABDwAIAhAAJgAAAAgA/wAAAAAAAAEPAAgCEAAnAAAACAD/AAAAAAAAAQ8ACAIQACgAAAAIAP8A AAAAAAABDwAIAhAAKQAAAAgA/wAAAAAAAAEPAAgCEAAqAAAACAD/AAAAAAAAAQ8ACAIQACsAAAAI AP8AAAAAAAABDwAIAhAALAAAAAgA/wAAAAAAAAEPAAgCEAAtAAAACAD/AAAAAAAAAQ8ACAIQAC4A AAAIAP8AAAAAAAABDwAIAhAALwAAAAgA/wAAAAAAAAEPAAgCEAAwAAAAFgD/AAAAAAAAAQ8ACAIQ ADEAAAAWAP8AAAAAAAABDwAIAhAAMgAAABYA/wAAAAAAAAEPAAgCEAAzAAAAFgD/AAAAAAAAAQ8A CAIQADQAAAAWAP8AAAAAAAABDwAIAhAANQAAABYA/wAAAAAAAAEPAAgCEAA2AAAAFgD/AAAAAAAA AQ8ACAIQADgAAAAWAP8AAAAAAAABDwAIAhAAOgAAABYA/wAAAAAAgAFYAAgCEAA7AAAAFgD/AAAA AAAAAQ8ACAIQADwAAAAWAP8AAAAAAAABDwAIAhAAPQAAABYA/wAAAAAAgAFBAAgCEAA+AAAAFgD/ AAAAAACAAUEACAIQAD8AAAAWAP8AAAAAAIABQQD9AAoAIAAAAEwAigAAAAECBgAgAAcARgABAgYA IQAAAEwA/QAKACEAAQBBAFAAAAD9AAoAIQACAEEAUQAAAAECBgAhAAcARgABAgYAIgAAAEwA/QAK ACIAAQBBAEQAAAD9AAoAIgACAEEAUgAAAAECBgAiAAcARgABAgYAIwAAAEwA/QAKACMAAQBBAFMA AAD9AAoAIwACAEEAVAAAAP0ACgAkAAAATACMAAAAAQIGACQABwBGAP0ACgAlAAEAQQACAAAAAQIG ACUABwBGAP0ACgAmAAEAQQAEAAAAAQIGACYABwBGAP0ACgAnAAAATACNAAAAAQIGACcABwBGAP0A CgAoAAEAQQADAAAAAQIGACgABwBGAP0ACgApAAEAQQCOAAAAAQIGACkABwBGAP0ACgAqAAAATACW AAAAAQIGACoABwBGAP0ACgArAAEARQBVAAAA/QAKACsAAgBBAFsAAAABAgYAKwAHAEYA/QAKACwA AQBFAFYAAAD9AAoALAACAEEAXwAAAAECBgAsAAcARgD9AAoALQABAEUAVwAAAP0ACgAtAAIAQQBg AAAAAQIGAC0ABwBGAP0ACgAuAAEARQBYAAAA/QAKAC4AAgBBAGEAAAABAgYALgAHAEYA/QAKAC8A AQBBAFwAAAD9AAoALwACAEEAXQAAAP0ACgAwAAEAQQBZAAAA/QAKADAAAgBBAF4AAAABAgYAMAAH AEYA/QAKADEAAABEAEcAAAD9AAoAMgABAEEAWgAAAP0ACgAzAAEAQQBPAAAA/QAKADQAAQBBAE4A AAD9AAoANQABAEEAAAAAAP0ACgA2AAEAQQABAAAA/QAKADgAAABEAGkAAAD9AAoAOgAAAFUAJQIA AP0ACgA6AAEAVgBHAgAAvgAWADoAAgBWAFYAVgBWAFYAVgBXAFcACQD9AAoAOwAAAEwAiwAAAP0A CgA7AAEAQQBrAAAA/QAKADwAAABMAIkAAAD9AAoAPAABAEEAbAAAAP0ACgA9AAAARACAAAAA/QAK AD0AAQBBAG0AAAC+ACIAPQAIAEgASAAPAA8ADwAPAA8ADwAPAA8ADwAPAA8ADwAVAP0ACgA+AAAA RACjAAAA/QAKAD4AAQBBABcBAAC+ACIAPgAIAEgASAAPAA8ADwAPAA8ADwAPAA8ADwAPAA8ADwAV AP0ACgA/AAAARABuAAAA/QAKAD8AAQBBABYBAAC+ACIAPwAIAEgASAAPAA8ADwAPAA8ADwAPAA8A DwAPAA8ADwAVANcAQAAOBgAARAIYADAAMAAmABgAGAAYABgAGAAYABgAJgAmACYAJgAcACYADgAO AA4ADgAOAA4ADgA2ABwAHABCAEIACAIQAEEAAAAWAPAAAAAAAMABQQAIAhAAQgAAABYA8AAAAAAA wAFBAAgCEABDAAAAFgDwAAAAAADAAUEACAIQAEQAAAAWAPAAAAAAAMABQQAIAhAARQAAABYA8AAA AAAAQAEPAAgCEABGAAAAFgDwAAAAAABAAQ8ACAIQAEcAAAAWAPAAAAAAAEABDwAIAhAASAAAABYA 8AAAAAAAQAEPAAgCEABJAAAAFgDwAAAAAADAAVgACAIQAEoAAAAWAPAAAAAAAEABDwAIAhAASwAA ABYA8AAAAAAAQAEPAAgCEABMAAAAFgDwAAAAAABAAQ8ACAIQAE0AAAAWAPAAAAAAAMABWAAIAhAA TgAAABYA8AAAAAAAwAFYAAgCEABPAAAAFgDwAAAAAADAAUEACAIQAFAAAAAWAPAAAAAAAMABQQAI AhAAUQAAABYA/wAAAAAAAAEPAAgCEABSAAAAFgD/AAAAAAAAAQ8ACAIQAFMAAAAWAP8AAAAAAAAB DwAIAhAAVAAAABYA/wAAAAAAAAEPAAgCEABVAAAAFgD/AAAAAAAAAQ8ACAIQAFYAAAAWAP8AAAAA AAABDwAIAhAAVwAAABYA/wAAAAAAAAEPAAgCEABYAAAAFgD/AAAAAAAAAQ8ACAIQAFkAAAAWAP8A AAAAAAABDwAIAhAAWgAAABYA/wAAAAAAAAEPAAgCEABbAAAAFgD/AAAAAAAAAQ8ACAIQAFwAAAAW AP8AAAAAAAABDwAIAhAAXQAAABYA/wAAAAAAAAEPAAgCEABeAAAAFgD/AAAAAAAAAQ8ACAIQAF8A AAAWAP8AAAAAAAABDwD9AAoAQQAAAEwAjwAAAP0ACgBBAAEAQQAYAQAAvgAiAEEACABIAEgADwAP AA8ADwAPAA8ADwAPAA8ADwAPAA8AFQD9AAoAQgAAAEwAkAAAAP0ACgBCAAEAQQAZAQAAvgAiAEIA CABIAEgADwAPAA8ADwAPAA8ADwAPAA8ADwAPAA8AFQD9AAoAQwAAAEwAqgAAAP0ACgBDAAEAQQCt AAAAvgAiAEMACABIAEgADwAPAA8ADwAPAA8ADwAPAA8ADwAPAA8AFQABAgYARAAAAEwA/QAKAEQA AQBBAK4AAAC+ACIARAAIAEgASAAPAA8ADwAPAA8ADwAPAA8ADwAPAA8ADwAVAP0ACgBFAAAATACV AAAA/QAKAEUAAQBBAK8AAAABAgYARgAAAEwA/QAKAEYAAQBBAK8AAAD9AAoARwAAAEwAlAAAAP0A CgBHAAEAQQCvAAAAAQIGAEgAAABMAP0ACgBIAAEARwApAAAAAQIGAEkAAACDAP0ACgBJAAEAggAf AgAAvgAWAEkAAgBWAFYAVgBWAFYAVgBXAFcACQD9AAoASgAAAEwAcQAAAP0ACgBKAAEAQQAaAQAA /QAKAEsAAABMAJgAAAD9AAoASwABAEEAsAAAAP0ACgBMAAAATACaAAAA/QAKAEwAAQBBABsBAAD9 AAoATQAAAKIAUAIAAP0ACgBNAAEAVgBSAgAAvgAWAE0AAgBWAFYAVgBWAFYAVgBXAFcACQD9AAoA TgAAAKIAUQIAAP0ACgBOAAEAVgBVAgAAvgAWAE4AAgBWAFYAVgBWAFYAVgBXAFcACQD9AAoATwAA AEwAFQAAAP0ACgBPAAEAQQC5AAAAvgAiAE8ACABIAEgADwAPAA8ADwAPAA8ADwAPAA8ADwAPAA8A FQABAgYAUAAAAEwAvgAiAFAACABIAEgADwAPAA8ADwAPAA8ADwAPAA8ADwAPAA8AFQD9AAoAUQAA AEwAHAEAAAECBgBSAAAATAD9AAoAUwAAAEwAKgAAAP0ACgBTAAEAQQAdAQAA/QAKAFQAAABMAC4A AAD9AAoAVAABAEEAHgEAAP0ACgBVAAAATAArAAAA/QAKAFUAAQBBAB8BAAD9AAoAVgAAAEwANwEA AP0ACgBWAAEAQQAhAQAA/QAKAFcAAABMAMsAAAD9AAoAVwABAEEAIAEAAP0ACgBYAAAATADbAAAA /QAKAFgAAQBBACIBAAD9AAoAWQAAAEwA1AAAAP0ACgBZAAEAQQAjAQAA/QAKAFoAAABMANgAAAD9 AAoAWgABAEEAOAEAAP0ACgBbAAAATADaAAAA/QAKAFsAAQBBADkBAAD9AAoAXAAAAEwA2QAAAP0A CgBcAAEAQQA6AQAA/QAKAF0AAABEADAAAAD9AAoAXQABAEEAOwEAAP0ACgBeAAAARAAvAAAA/QAK AF4AAQBBACQBAAD9AAoAXwAAAEQAMQAAAP0ACgBfAAEAQQA8AQAA1wBCAMAGAABYAkIAQgBCAD4A HAAYABwAGAAyABwAHAAcADYANgBCADAADgAKABwAHAAcABwAHAAcABwAHAAcABwAHAAcAAgCEABg AAAAFgD/AAAAAAAAAQ8ACAIQAGEAAAAWAPAAAAAAAMABQQAIAhAAYwAAABYA/wAAAAAAAAEPAAgC EABlAAAAFgD/AAAAAAAAAQ8ACAIQAGYAAAAWAP8AAAAAAAABDwAIAhAAZwAAABYA/wAAAAAAAAEP AAgCEABoAAAAFgD/AAAAAAAAAQ8ACAIQAGoAAAAWAP8AAAAAAAABDwAIAhAAbAAAABYA/wAAAAAA AAEPAAgCEABtAAAAFgD/AAAAAAAAAQ8ACAIQAG8AAAAWAP8AAAAAAAABDwAIAhAAcQAAAAoA/wAA AAAAAAEPAAgCEAByAAAACgD/AAAAAACAAVgACAIQAHMAAAAKAPAAAAAAAIABhQAIAhAAdAAAAAoA 8AAAAAAAgAGFAAgCEAB1AAAACgDwAAAAAACAAYUACAIQAHYAAAAKAPAAAAAAAIABhQAIAhAAdwAA AAoA8AAAAAAAgAGFAAgCEAB4AAAACgDwAAAAAACAAVAACAIQAHkAAAAKAPAAAAAAAIABUAAIAhAA egAAAAoA8AAAAAAAgAFQAAgCEAB7AAAACgD/AAAAAAAAAQ8ACAIQAHwAAAAKAP8AAAAAAAABDwAI AhAAfQAAAAoA/wAAAAAAAAEPAAgCEAB+AAAACgD/AAAAAAAAAQ8ACAIQAH8AAAAKAP8AAAAAAAAB DwD9AAoAYAAAAEQABQEAAP0ACgBgAAEAQQAJAQAA/QAKAGEAAABMABUAAAD9AAoAYQABAEEAuQAA AL4AIgBhAAgASABIAA8ADwAPAA8ADwAPAA8ADwAPAA8ADwAPABUA/QAKAGMAAABEACUBAAD9AAoA ZQAAAEwA9gAAAP0ACgBlAAEAQQAmAQAA/QAKAGYAAABMAPQAAAD9AAoAZgABAEEAJwEAAP0ACgBn AAAATACcAQAA/QAKAGcAAQBBAKIBAAD9AAoAaAAAAEwAmwEAAP0ACgBoAAEAQQCjAQAA/QAKAGoA AABEACgBAAD9AAoAbAAAAEwA/QAAAP0ACgBsAAEAQQApAQAA/QAKAG0AAABMAAABAAD9AAoAbQAB AEEAKgEAAP0ACgBvAAAARAA9AQAA/QAKAHEAAABEAJsAAAABAgYAcgAAAFUA/QAKAHIAAQBWAIkB AAC+ABYAcgACAFYAVgBWAFYAVgBWAFcAVwAJAAECBgBzAAAAhAD9AAoAcwABAIUARAIAAL4ACgBz AAgAhgCGAAkAAQIGAHQAAACEAP0ACgB0AAEAWgDUAQAAvgAKAHQACACGAIYACQABAgYAdQAAAIQA /QAKAHUAAQBaAJwAAAC+AAoAdQAIAIYAhgAJAAECBgB2AAAAhAD9AAoAdgABAFoADAIAAL4ACgB2 AAgAhgCGAAkAAQIGAHcAAACEAP0ACgB3AAEAWgA+AQAAvgAKAHcACACGAIYACQABAgYAeAAAAE8A /QAKAHgAAQBSAOEBAAC+AAoAeAAIAFEAUQAJAAECBgB5AAAATwD9AAoAeQABAFIAKwEAAL4ACgB5 AAgAUQBRAAkAAQIGAHoAAABPAL4ACgB6AAgAUQBRAAkA/QAKAHsAAABEAEEBAAABAgYAewABAFQA /QAKAHwAAQBUAEIBAAD9AAoAfQABAFQAQAEAAP0ACgB+AAEAVACKAQAA/QAKAH8AAQBUAD8BAADX ADgA6gQAAPQBHABCAA4AHAAcABwAHAAOABwAHAAOAA4AMgAmACYAJgAmACYAJgAmABgAGAAOAA4A DgAIAhAAggAAAAoA/wAAAAAAAAEPAAgCEACDAAAACgD/AAAAAAAAAQ8ACAIQAIQAAAAKAP8AAAAA AAABDwAIAhAAhQAAAAoA/wAAAAAAAAEPAAgCEACGAAAACgD/AAAAAAAAAQ8ACAIQAIcAAAAKAP8A AAAAAAABDwAIAhAAjgAAAAoA/wAAAAAAgAFYAAgCEACPAAAACgD/AAAAAACAAVgACAIQAJEAAAAB AP8AAAAAAAABDwABAgYAggABAEcAAQIGAIMAAQBHAAECBgCEAAEASAABAgYAhQABAEcAAQIGAIYA AQBHAAECBgCHAAEARwC+ABoAjgAAAFUAVgBWAFYAVgBWAFYAVgBXAFcACQC+ABoAjwAAAFUAVgBW AFYAVgBWAFYAVgBXAFcACQABAgYAkQAAAEAA1wAWADYBAACgAAoACgAKAAoACgAKAB4AHgA+AhIA tgAAAAAAQAAAADwASwAAAAAAHQAPAAMHAAIAAAABAAcABwACApkAAgAkCe8ABgAHADcAAABnCBcA ZwgAAAAAAAAAAAAAAgAB/////wNEAACcCCYAnAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAAAAAAAACLCBAAiwgAAAAAAAAAAAAAAABSAMgICQDICAAACAAAAAAKAAAACQgQAAAGEABzIM0H 2cABAAYDAAALAhgAAAAAAAAAAAA5AAAAYtkAAE8fAQCxMQEADQACAAEADAACAGQADwACAAEAEQAC AAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA /wCBAAIAwQUUAAAAFQAAAIMAAgAAAIQAAgAAACYACABbNK7JZDLpPycACABbNK7JZDLpPygACACK HTz8/X7vPykACACKHTz8/X7vP00AUhgAAFwAXABtAGMAaABwADcANgByAGEAXABNAEMASAAwADAA OAAwAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAF3AB0F0P/gAcBAAEA6gpvCGQAAQAP AFgCAgACAFgCAwAAAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAIAAAASAQAA//// /wAAAAAAAAAAAAAAAAAAAABESU5VIgAAADQCQBXIjPjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACkAAAAAAAAAAAAAAAAAAQAFAAAAAAAAAAAAAAAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABAFQAASVVQSAoAEQAAAAAAAQAAAAEAAAABAAAAAAAAAAAAAAADAAAAAAAAAAEA AAABAAIAZAABAAAAAwACAAAAAQAAAAIAAABMAGUAdAB0AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAg AFsAawBlAGkAbgBdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA WwBrAGUAaQBuAF0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBy AGkAYQBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAA UAAAAAAAAAABAAAAAAAAAMDAwAAAAAAAwMDAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAQAAAGQAAAAA AAAAAACAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAADwAAAA8A AAAAAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAEQARQBNAFMARgA0AFMANwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AEEAdQB0AG8AbQBhAHQAaQBjAD4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAEAAAAA AAAAAAAAAAEAAAABAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAA AAABAAAAAQAAAAEAAAABAAAADwAAABIBAAAAAAAADwAAABIBAAAAAAAAAAAAAAAAAAAAAAAADwAA ABIBAAAPAAAAEgEAAAMAAAAAAAAAAAAAADYAMAAwAGQAcABpAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAEAAA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATgBlAHUAZQAg AFMAYwBoAG4AZQBsAGwAZQBpAG4AcwB0AGUAbABsAHUAbgBnACAAZQBpAG4AZwBlAGIAZQBuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpAAAA8QwAAAAAAAAAAAAA agAAAC4PAAAAAAAAAAAAAGsAAAD+CwAAAAAAAAAAAABrAAAA/wsAAAAAAAAAAAAAbQAAAPkLAAAA AAAAAAAAAG0AAAD5CwAAAAAAAAAAAAACAAAALQMAAEVYQ0VMLkVYRQAAAAAAAAABAAAAAQAAAAEA AAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAADwAAABIBAAAPAAAAEgEAAA8AAAASAQAA DwAAABIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGABwAAAAAoQAiAAEANgABAAQABQACAMgAyAAA AAAAAADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAAG0fQAACAAIAfQAMAAEAAQC2Dw8AAgACAH0A DAACAAIAAAIPAAIAAgB9AAwAAwADANsIDwACAAIAfQAMAAQABADbDA8AAgACAH0ADAAFAAUASQkP AAIAAgB9AAwABgAGACQKDwACAAIAfQAMAAcABwAkClgAAgACAH0ADAAIAAgA2wxJAAIAAgB9AAwA CQAJAG0KDwACAAIAfQAMAAoACgC2Cg8AAgACAH0ADAALAAsA2wwPAAIAAgB9AAwADAAMAG0JDwAC AAIAfQAMAA0ADQDbDA8AAgACAH0ADAAOAA4Atg5YAAIAAgB9AAwADwAPALYOxgACAAIAfQAMABAA EAC2DA8AAgACAH0ADAARABIAAAwPAAIAAgB9AAwAEwATALYMDwACAAIAfQAMABQAFABtDA8AAgAC AH0ADAAVABUAAAwPAAIAAgB9AAwAFgAWAG0KDwACAAIAfQAMABcAFwAADlgAAgACAH0ADAAYABgA SQ4PAAIAAgB9AAwAGQAZAJIViAAGAAIAfQAMABoAGgCSFVgABgACAH0ADAAbABsAbQoPAAIAAgB9 AAwAHAAcAEkKWAACAAIAfQAMAB0AHQBtCw8AAgACAH0ADAAeAB4AtgoPAAIAAgB9AAwAHwAfACQK WAACAAIAfQAMACAAIAAkCg8AAgACAH0ADAAhACEAJAkPAAIAAgB9AAwAIgAiAG0KWAACAAIAfQAM ACMAIwAAClgAAgACAH0ADAAkACQAbQpYAAIAAgB9AAwAJQAlALYLWAACAAIAfQAMACYAJgC2C4cA AgACAH0ADAAnACcAtgtYAAIAAgB9AAwAKAAoAEkPWAACAAIAfQAMACkAKQC2ClgAAgACAH0ADAAq ACsAbQtYAAIAAgB9AAwALAAsAG0L2QACAAIAfQAMAC0AMABtC1gAAgACAH0ADAAxADEASQtYAAIA AgB9AAwAMgAyANsIWAACAAIAfQAMADMAMwDbCA8AAgACAH0ADAA0ADQA2w6IAAIAAgB9AAwANQA1 ANsOfQACAAIAfQAMADYANgAkCVgAAAACAJAAFwAAABAAAABTYW1wbGUgUmF0ZSAoSHop4AACDgAA AAAAOQAAAAAANwAAAAgCEAAAAAAANwD/AAAAAACAAVgACAIQAAEAAAA3ACwBAAAAAIABWAAIAhAA AgAAADcA/wAAAAAAgAFYAAgCEAADAAAANwD/AAAAAACAAVgACAIQAAQAAAA3AP8AAAAAAAABDwAI AhAABQAAADcA/wAAAAAAAAEPAAgCEAAGAAAANwDOBAAAAADAAV8ACAIQAAcAAAA3ACgFAAAAAMAB XwAIAhAACAAAADcAcwUAAAAAwAFyAAgCEAAJAAAANwD/AAAAAACAAWEACAIQAAoAAAA3AP0CAAAA AIABYAAIAhAACwAAADcAHAIAAAAAwAFkAAgCEAAMAAAANwD/AAAAAACAAWEACAIQAA0AAAA3AP8A AAAAAIABYQAIAhAADgAAADcAHQEAAAAAwAFhAAgCEAAPAAAANwD6BQAAAADAAWAACAIQABAAAAA3 AP8AAAAAAIABYQAIAhAAEQAAADcA/wAAAAAAgAFiAAgCEAASAAAANwD/AAAAAACAAWEACAIQABMA AAA3AHUDAAAAAMABYQAIAhAAFAAAADcA/QIAAAAAgAFhAAgCEAAVAAAANwD7BAAAAACAAWEACAIQ ABYAAAA3APgHAAAAAIABYAAIAhAAFwAAADcA/QIAAAAAgAFhAAgCEAAYAAAANwAKBQAAAADAAWEA CAIQABkAAAA3APoFAAAAAIABYQAIAhAAGgAAADcA/wAAAAAAgAFhAAgCEAAbAAAANwD/AAAAAACA AXsACAIQABwAAAA3AP8AAAAAAIABewAIAhAAHQAAADcA/wAAAAAAgAFhAAgCEAAeAAAANwD/AAAA AACAAWEACAIQAB8AAAA3AFkBAAAAAMABYQD9AAoAAAAAAFUANwAAAAECBgAAAAgAWQC+AAoAAAAO AJEAxgAPAAECBgAAABkAiAABAgYAAAAmAIcAAQIGAAAALADZAL4ACgAAADQAiACIADUABgAdAAEA AABVAAAA4AxMC///IAADAAD/BwBaAAABAADABwIyAC8AAE1lZGlhIENvZGluZyBTdW1tYXJ5IERh dGFiYXNlIC0gSVRVLVQgU0cxNiBRLjIzvgAeAAEAAQBWAFYAVgChAFYAVgBWAFcAVgBWAFYAVwAM AL4ACgABAA4AkQDHAA8AAQIGAAEAGQCIAAECBgABACYAhwABAgYAAQAsANkAvgAOAAEAMgBWAFYA iACIADUABgAdAAIAAABVAAAAQA1MC///IAABAAD+BwBaAAACAADABwIZABYAAEdlbmV2YSwgMyBP Y3RvYmVyIDIwMDi+ACQAAgABAFYAVgBWAKEAVgBWAFYAVwBWAFYAVgBXAFcAkQDGAA8AAQIGAAIA GQCIAAECBgACACYAhwABAgYAAgAsANkAvgAOAAIAMgBWAFYAiACIADUABgAdAAMAAABVAAAAcA1M C///IAAEAAD/BwBaAAADAADABwIqACcAAFNvdXJjZTogUmFwcG9ydGV1ciwgUS4yMy8xNiAoSC4g VGFkZGVpKb4AJAADAAEAVgBWAFYAoQBWAFYAVgBXAFYAVgBWAFsAWwCRAMYADwABAgYAAwAZAIgA AQIGAAMAJgCHAAECBgADACwA2QC+AA4AAwAyAFYAVgCIAIgANQAGAB0ABAAAAEQAAADADUwL//8g ABUABf8HAFoAAAQAAMAHAloAVwAAQ29udGFjdDogSGVydukgVGFkZGVpLCBIdWF3ZWkgVGVjaG5v bG9naWVzLCArNDkgMTYyIDI5NDAgMjYwLCA8aGVydmUudGFkZGVpQGh1YXdlaS5jb20+vgAiAAQA AQBWAFYAVgChAFYAVgBWAFcAVgBWAFYAVwBXAJEADgC+AA4ABAAQAFgAWABYAFgAEwC+AAoABAAy AFYAVgAzAL4AIgAFAAEAVgBWAFYAoQBWAFYAVgBXAFYAVgBWAFcAVwCRAA4AvgASAAUAEABYAKEA oQChAFMAUwAVAL4ACgAFACIAoQChACMAvgAKAAUAMgBWAFYAMwD9AAoABgAAAF0AQAAAAL4ACgAG AAEAogCjAAIA/QAKAAYAAwBrAHgAAAD9AAoABgAEAMgAvQIAAP0ACgAGAAUAawAIAAAA/QAKAAYA BgBrAPsBAAD9AAoABgAHAGsA+gEAAP0ACgAGAAgAawAKAAAA/QAKAAYACQBrAAYAAAD9AAoABgAK AGsAoAAAAP0ACgAGAAsAawD0AQAA/QAKAAYADABrAAUAAAD9AAoABgANAGsABwAAAP0ACgAGAA4A tABIAgAA/QAKAAYADwDIALUCAAD9AAoABgAQAGsAmwIAAP0ACgAGABEApABfAQAA/QAKAAYAEgCk AGABAAD9AAoABgATAKQAYQEAAP0ACgAGABQAagBiAQAA/QAKAAYAFQBfAHkBAAD9AAoABgAWAF8A TQEAAP0ACgAGABcAawDLAQAA/QAKAAYAGABfAJECAAD9AAoABgAZAKAAiAIAAP0ACgAGABoAawCJ AgAA/QAKAAYAGwBfAKYBAAD9AAoABgAcAGsApwEAAP0ACgAGAB0AXwCoAQAA/QAKAAYAHgBfAKkB AAD9AAoABgAfAGsAqwEAAP0ACgAGACAAXwBRAQAA/QAKAAYAIQBrAMABAAD9AAoABgAiAGsAewIA AP0ACgAGACMAawB6AgAA/QAKAAYAJABrAHkCAAD9AAoABgAlAGsAfwIAAP0ACgAGACYAawCAAgAA /QAKAAYAJwBrAHgCAAD9AAoABgAoAGsAhAIAAP0ACgAGACkAawANAQAA/QAKAAYAKgBrAHACAAD9 AAoABgArAGsAcQIAAP0ACgAGACwAyADHAgAA/QAKAAYALQBrAHICAAD9AAoABgAuAGsAcwIAAP0A CgAGAC8AawB0AgAA/QAKAAYAMABrAHUCAAD9AAoABgAxAGsADgEAAP0ACgAGADIAawDZAQAA/QAK AAYAMwBrAOABAAD9AAoABgA0AKAAkwIAAP0ACgAGADUAoAAEAgAA/QAKAAYANgBrAKUCAAD9AAoA BwAAAF0AQQAAAL4ACgAHAAEAogB7AAIA/QAKAAcAAwBrAH4AAAD9AAoABwAEAMgAvgIAAP0ACgAH AAUAawB5AAAA/QAKAAcABgBrAHoAAAD9AAoABwAHAGsA/AEAAP0ACgAHAAgAawBcAQAA/QAKAAcA CQBrAHwAAAD9AAoABwAKAGsAngAAAP0ACgAHAAsAawCfAAAA/QAKAAcADABrAHsAAAD9AAoABwAN AGsAfQAAAP0ACgAHAA4AwQCdAgAA/QAKAAcADwDIALYCAAD9AAoABwAQAGsAmgIAAP0ACgAHABEA pABjAQAA/QAKAAcAEgCkAGQBAAD9AAoABwATAKQAZQEAAP0ACgAHABQAagBmAQAA/QAKAAcAFQBf AH4BAAD9AAoABwAWAF8ATgEAAP0ACgAHABcAawDMAQAA/QAKAAcAGABrAJgCAAD9AAoABwAZAKAA igIAAP0ACgAHABoAtwCZAgAA/QAKAAcAGwBfAKUBAAD9AAoABwAcAGsApQEAAP0ACgAHAB0AXwCl AQAA/QAKAAcAHgBfAKoBAAD9AAoABwAfAI0ArAEAAP0ACgAHACAAbABSAQAA/QAKAAcAIQBrAE8B AAD9AAoABwAiAGsADwEAAP0ACgAHACMAawA2AQAA/QAKAAcAJABrADYBAAD9AAoABwAlAGsAEAEA AP0ACgAHACYAawAQAQAA/QAKAAcAJwBrABABAAD9AAoABwAoAGsAEAEAAP0ACgAHACkAawARAQAA /QAKAAcAKgBrABMBAAD9AAoABwArAGsAEwEAAP0ACgAHACwAyAATAQAA/QAKAAcALQBrABMBAAD9 AAoABwAuAGsAEwEAAP0ACgAHAC8AawATAQAA/QAKAAcAMABrAHYCAAD9AAoABwAxAGsAEgEAAP0A CgAHADIAawDQAQAA/QAKAAcAMwBrANEBAAD9AAoABwA0AKAAlAIAAP0ACgAHADUAoAARAgAA/QAK AAcANgBrAKYCAAD9AAoACAAAAIoAJQIAAL4ACgAIAAEAiwCMAAIA/QAKAAgAAwByACkCAAD9AAoA CAAEAMkAvwIAAP0ACgAIAAUAcgA7AgAA/QAKAAgABgByADoCAAD9AAoACAAHAHIAOgIAAP0ACgAI AAgAcgAzAgAA/QAKAAgACQByACwCAAD9AAoACAAKAHIAoAAAAP0ACgAIAAwAcgAnAgAA/QAKAAgA DQByACgCAAD9AAoACAAOAJAASQIAAP0ACgAIAA8AyQC3AgAA/QAKAAgAEgC5AJwCAAD9AAoACAAT AHIAMwIAAP0ACgAIABQAcgAzAgAA/QAKAAgAFwC5ADgCAAD9AAoACAAYAHIANgIAAP0ACgAIABkA uACLAgAA/QAKAAgAGgC5AIwCAAD9AAoACAAcAHIAMwIAAP0ACgAIAB8AjQAuAgAAAQIGAAgAIACO AP0ACgAIACIAawB8AgAA/QAKAAgAIwBrAH0CAAD9AAoACAAkAGsAfgIAAP0ACgAIACUAawCBAgAA /QAKAAgAJgBrAIICAAD9AAoACAAnAGsAgwIAAP0ACgAIACgAawBuAgAA/QAKAAgAKQBrAA0BAAD9 AAoACAAqAGsAZwIAAP0ACgAIACsAawBoAgAA/QAKAAgALADIAMgCAAD9AAoACAAtAGsAaQIAAP0A CgAIAC4AawBrAgAA/QAKAAgALwBrAIUCAAD9AAoACAAwAGsAhgIAAL4ACgAIADQAuACPADUA/QAK AAgANgB0AKcCAAD9AAoACQAAAF0AiwAAAP0ACgAJAAEAogBCAAAAAQIGAAkAAgCiAP0ACgAJAAMA cQAJAAAA/QAKAAkABADKAAkAAAD9AAoACQAFAHEACQAAAP0ACgAJAAYAcQAJAAAA/QAKAAkABwBx AAkAAAD9AAoACQAIAHEAbwAAAP0ACgAJAAkAcQBvAAAA/QAKAAkACgBuAAkAAAD9AAoACQALAG4A CQAAAP0ACgAJAAwAcQBvAAAA/QAKAAkADQBxAG8AAAD9AAoACQAOAJEAnwIAAP0ACgAJAA8AygBv AAAA/QAKAAkAEABxAG8AAAD9AAoACQARAHoAbwAAAP0ACgAJABIAegBvAAAA/QAKAAkAEwB6AG8A AAD9AAoACQAUAG0AbwAAAP0ACgAJABUAaQBvAAAA/QAKAAkAFgBuAG8AAAD9AAoACQAXAG4AbwAA AP0ACgAJABgAbgBvAAAA/QAKAAkAGQCbAG8AAAD9AAoACQAaAG4AbwAAAP0ACgAJABsAbgBvAAAA /QAKAAkAHABuAG8AAAD9AAoACQAdAG4AbwAAAP0ACgAJAB4AbgBvAAAAvgAKAAkAHwBuAGIAIAD9 AAoACQAhAG4AbwAAAP0ACgAJACIAcQAJAAAA/QAKAAkAIwBxAAkAAAD9AAoACQAkAHEACQAAAP0A CgAJACUAbgAJAAAA/QAKAAkAJgBuAAkAAAD9AAoACQAnAG4ACQAAAP0ACgAJACgAbgAJAAAA/QAK AAkAKQBuAAkAAAD9AAoACQAqAG4ACQAAAP0ACgAJACsAbgAJAAAA/QAKAAkALADKAAkAAAD9AAoA CQAtAG4ACQAAAP0ACgAJAC4AbgAJAAAA/QAKAAkALwBuAAkAAAD9AAoACQAwAG4ACQAAAP0ACgAJ ADEAbgAJAAAA/QAKAAkAMgBxAAkAAAD9AAoACQAzAHEACQAAAP0ACgAJADQAugAJAAAA/QAKAAkA NQCWABoCAAD9AAoACQA2AG4AqAIAAP0ACgAKAAAAXQCJAAAA/QAKAAoAAQCiAEUAAAABAgYACgAC AKIA/QAKAAoAAwByAIcAAAD9AAoACgAEAMkAwAIAAP0ACgAKAAUAcgCIAAAA/QAKAAoABgByAIgA AAD9AAoACgAHAHIA/QEAAP0ACgAKAAgAcgCIAAAA/QAKAAoACQByAIcAAAD9AAoACgAKAHIAhwAA AP0ACgAKAAsAcgCHAAAA/QAKAAoADAByAIcAAAD9AAoACgANAHIAhwAAAP0ACgAKAA4AkABNAgAA /QAKAAoADwDJAIgAAAD9AAoACgAQAHQAiAAAAP0ACgAKABEApQCHAAAA/QAKAAoAEgClAIcAAAD9 AAoACgATAKUAhwAAAP0ACgAKABQAcACHAAAA/QAKAAoAFQBvAIcAAAD9AAoACgAWAGQAhwAAAP0A CgAKABcAuwCHAAAA/QAKAAoAGABxAIcAAAD9AAoACgAZALoAhwAAAP0ACgAKABoAuwCIAAAA/QAK AAoAGwBxAIcAAAD9AAoACgAcAHEAhwAAAP0ACgAKAB0AcQCHAAAA/QAKAAoAHgBxAIcAAAD9AAoA CgAfAHEAhwAAAP0ACgAKACAAcgCEAQAA/QAKAAoAIQBxAIcAAAD9AAoACgAiAHQAhAEAAP0ACgAK ACMAdACEAQAA/QAKAAoAJAB0AIQBAAD9AAoACgAlAHQAhAEAAP0ACgAKACYAdACEAQAA/QAKAAoA JwB0AIQBAAD9AAoACgAoAHQAhAEAAP0ACgAKACkAdABqAgAA/QAKAAoAKgB0AGoCAAD9AAoACgAr AHQAagIAAP0ACgAKACwAyQBqAgAA/QAKAAoALQB0AGoCAAD9AAoACgAuAHQAagIAAP0ACgAKAC8A dABqAgAA/QAKAAoAMACcAIQBAAD9AAoACgAxAHQAhAEAAP0ACgAKADIAcgDWAQAA/QAKAAoAMwBz AN8BAAD9AAoACgA0AJwAhAEAAP0ACgAKADUAnACEAQAA/QAKAAoANgDFAIgAAAD9AAoACwAAAF0A pgAAAP0ACgALAAEAogAaAAAAAQIGAAsAAgCiAP0ACgALAAMAcgAjAAAA/QAKAAsABADJAEUCAAD9 AAoACwAFAHIAJAAAAP0ACgALAAYAcgAlAAAA/QAKAAsABwByAEUCAAD9AAoACwAIAHIAiAEAAP0A CgALAAkAcgAmAAAA/QAKAAsACgByAEQAAAD9AAoACwALAHIAKAAAAP0ACgALAAwAcgAnAAAA/QAK AAsADQByANwAAAD9AAoACwAOAHIATgIAAP0ACgALAA8AyQBOAgAA/QAKAAsAEAB0AMEBAAD9AAoA CwARAKUAZwEAAP0ACgALABIApQBnAQAA/QAKAAsAEwClAGgBAAD9AAoACwAUAHAAXQEAAP0ACgAL ABUAbwCBAQAA/QAKAAsAFgBkAN4AAAD9AAoACwAXAHQAwQEAAP0ACgALABgAbgDBAQAA/QAKAAsA GQCbAI0CAAD9AAoACwAaAG4AjgIAAAECBgALABwAdAABAgYACwAfAHQA/QAKAAsAIQB0AMEBAAD9 AAoACwAiAHQAFAEAAP0ACgALACMAdAAUAQAA/QAKAAsAJAB0ABQBAAD9AAoACwAlAHQAFAEAAP0A CgALACYAdAAUAQAA/QAKAAsAJwB0ABQBAAD9AAoACwAoAHQAFAEAAP0ACgALACkAdAAUAQAA/QAK AAsAKgB0AAwAAAD9AAoACwArAHQAYAIAAP0ACgALACwAyQBgAgAA/QAKAAsALQB0AMQAAAD9AAoA CwAuAHQADQAAAP0ACgALAC8AjwAZAgAA/QAKAAsAMACPABkCAAD9AAoACwAxAHQAFQEAAP0ACgAL ADIAcgDXAQAA/QAKAAsAMwByANcBAAD9AAoACwA0ALgAGQIAAP0ACgALADUAjwAZAgAA/QAKAAsA NgB0AKkCAAD9AAoADAAAAF0AigAAAP0ACgAMAAEAogBDAAAAAQIGAAwAAgCiAP0ACgAMAAMAcQBQ AAAA/QAKAAwABADKAFAAAAD9AAoADAAFAHEAUAAAAP0ACgAMAAYAcQBQAAAA/QAKAAwABwBxAFAA AAD9AAoADAAIAHEAUAAAAP0ACgAMAAkAcQBQAAAA/QAKAAwACgBuAFAAAAD9AAoADAALAG4AUAAA AP0ACgAMAAwAcQBQAAAA/QAKAAwADQBxAFAAAAD9AAoADAAOAJEAUAAAAP0ACgAMAA8AygBQAAAA /QAKAAwAEABxAFAAAAD9AAoADAARAHoAUAAAAP0ACgAMABIAegBQAAAA/QAKAAwAEwB6AFAAAAD9 AAoADAAUAG0AUAAAAP0ACgAMABUAaQB6AQAAAQIGAAwAFgBuAP0ACgAMABcAbgBQAAAA/QAKAAwA GABuAFAAAAD9AAoADAAZAJsAUAAAAP0ACgAMABoAbgBQAAAAvgAOAAwAGwBuAG4AbgBiAB4A/QAK AAwAHwBuAFAAAAABAgYADAAgAGIA/QAKAAwAIQBuAFAAAAD9AAoADAAiAG4AUAAAAP0ACgAMACMA bgBQAAAA/QAKAAwAJABuAFAAAAD9AAoADAAlAHEAUAAAAP0ACgAMACYAcQBQAAAA/QAKAAwAJwBx AFAAAAD9AAoADAAoAG4AUAAAAP0ACgAMACkAbgBQAAAA/QAKAAwAKgBuAFAAAAD9AAoADAArAG4A UAAAAP0ACgAMACwAygBQAAAA/QAKAAwALQBuAFAAAAD9AAoADAAuAG4AUAAAAP0ACgAMAC8AbgBQ AAAA/QAKAAwAMABuAFAAAAD9AAoADAAxAG4AUAAAAP0ACgAMADIAcQBQAAAA/QAKAAwAMwBxAFAA AAD9AAoADAA0ALoAUAAAAP0ACgAMADUAlgBQAAAA/QAKAAwANgBuAKoCAAD9AAoADQAAAF0AjAAA AP0ACgANAAEAogCoAAAAAQIGAA0AAgCiAL0AEgANAAMAcQAA5J5A0QAAVuNABAD9AAoADQAFAHEA GwAAAP0ACgANAAYAcQAcAAAA/QAKAA0ABwBxAP4BAAD9AAoADQAIAHEAqwAAAP0ACgANAAkAcQAd AAAA/QAKAA0ACgBuAB4AAAD9AAoADQALAG4AHgAAAP0ACgANAAwAcQAfAAAA/QAKAA0ADQBxAB0A AAD9AAoADQAOAJEASgIAAP0ACgANAA8AygC4AgAAvQASAA0AEABuAABQn0B6AAAUn0ARAP0ACgAN ABIAegBpAQAA/QAKAA0AEwB6AGoBAAD9AAoADQAUAG0AawEAAP0ACgANABUAdQB/AQAAvQASAA0A FgBuAAAgn0BuAAAon0AXAP0ACgANABgAbgDCAQAAvQAkAA0AGQCbAABYn0BuAABcn0BuAAAYn0Bu AAA0n0BuAAA8n0AdAAECBgANAB4AYgB+AgoADQAfAG4AAEifQAECBgANACAAYgD9AAoADQAhAG4A wwEAAL0AZgANACIAbgAAIJ9AbgAAIJ9AbgAAIJ9AbgAAKJ9AbgAAKJ9AbgAAKJ9AbgAAKJ9AbgAA NJ9AbgAAOJ9AbgAAQJ9AygAAYJ9AbgAAOJ9AbgAAWJ9AbgAAVJ9AbgAAVJ9AbgAALJ9AMQD9AAoA DQAyAHEAGwAAAP0ACgANADMAcQAbAAAAvQAYAA0ANAC6AABUn0CWAABUn0BuAABgn0A2AP0ACgAO AAAAXQCNAAAA/QAKAA4AAQCiAKgAAAABAgYADgACAKIA/QAKAA4AAwBxABsAAAB+AgoADgAEANEA AFbjQP0ACgAOAAUAcQAbAAAA/QAKAA4ABgBxAP4BAAD9AAoADgAHAHEA/gEAAP0ACgAOAAgAcQCr AAAA/QAKAA4ACQBxAEoCAAD9AAoADgAKAG4AoQAAAP0ACgAOAAsAbgChAAAA/QAKAA4ADABxAB8A AAD9AAoADgANAHEAIAAAAP0ACgAOAA4AkQCgAgAA/QAKAA4ADwDKALgCAAC9ABIADgAQAG4AAFSf QHoAABSfQBEA/QAKAA4AEgB6AGkBAAD9AAoADgATAHoAagEAAP0ACgAOABQAbQBrAQAA/QAKAA4A FQB2AIABAAABAgYADgAWAGIAvQAeAA4AFwBuAABMn0BiAABMn0CbAABYn0BuAABcn0AaAL4ADgAO ABsAYgBuAGIAYgAeAH4CCgAOAB8AbgAASJ9AAQIGAA4AIABiAP0ACgAOACEAbgDDAQAAvgAMAA4A IgBuAG4AbgAkAL0APAAOACUAbgAANJ9AbgAANJ9AbgAANJ9AbgAANJ9AbgAAWJ9AbgAAVJ9AbgAA VJ9AygAAYJ9AbgAAVJ9ALQABAgYADgAuAG4AvQASAA4ALwBuAABUn0BuAABUn0AwAAECBgAOADEA bgD9AAoADgAyAHEAGwAAAP0ACgAOADMAcQAbAAAAvQAYAA4ANAC6AABUn0CWAABUn0BuAABgn0A2 AP0ACgAPAAAAXQCAAAAA/QAKAA8AAQCiAH8AAAABAgYADwACAKIA/QAKAA8AAwCQAIEAAAD9AAoA DwAEANIAwQIAAP0ACgAPAAUAkACBAAAA/QAKAA8ABgCQAIIAAAD9AAoADwAHAJAA/wEAAP0ACgAP AAgApgCsAAAA/QAKAA8ACQCQAIMAAAD9AAoADwAKAHQAogAAAP0ACgAPAAsAdACiAAAAfgIKAA8A DACQAAAAMED9AAoADwANAJAAIQAAAP0ACgAPAA4AkABLAgAA/QAKAA8ADwDJALkCAAD9AAoADwAQ AHIAngIAAL0AGAAPABEApQAAACpApQABgIFApQABEJNAEwD9AAoADwAUAHAAbAEAAAMCDgAPABUA dwD4U+Olm0QSQP0ACgAPABYAZABbAQAA/QAKAA8AFwB0AM0BAAD9AAoADwAYAGQATAEAAP0ACgAP ABkAnACPAgAA/QAKAA8AGgB0AEwBAAC9ABgADwAbAGQAAdiIQHQAASCHQGQAARCTQB0A/QAKAA8A HgBkAFcBAAD9AAoADwAfAHQAVgEAAP0ACgAPACAAZABUAQAA/QAKAA8AIQB0AMQBAAD9AAoADwAi AHQAhQEAAP0ACgAPACMAdACGAQAA/QAKAA8AJAB0AIcBAAD9AAoADwAlAHQAjQEAAP0ACgAPACYA dACOAQAA/QAKAA8AJwB0AI4BAAD9AAoADwAoAHQAeAEAAP0ACgAPACkAdABhAgAA/QAKAA8AKgB0 AGECAAD9AAoADwArAHQAYQIAAP0ACgAPACwAyQBhAgAA/QAKAA8ALQB0AGECAAD9AAoADwAuAHQA PQIAAP0ACgAPAC8AdABhAgAA/QAKAA8AMAB0ABICAAD9AAoADwAxAHQAMgEAAP0ACgAPADIAkADa AQAA/QAKAA8AMwCQAN4BAAD9AAoADwA0AJcAEgIAAP0ACgAPADUAlwATAgAA/QAKAA8ANgB0AKsC AAD9AAoAEAAAAGUAowAAAP0ACgAQAAEApwCkAAAAAQIGABAAAgCiAP0ACgAQAAMAkQByAAAA/QAK ABAABADLAKUAAAD9AAoAEAAFAJEApQAAAP0ACgAQAAYAkQClAAAA/QAKABAABwCRAKUAAAD9AAoA EAAIAJEApwAAAP0ACgAQAAkAkQCnAAAA/QAKABAACgBuAKUAAAD9AAoAEAALAG4ApQAAAP0ACgAQ AAwAkQClAAAA/QAKABAADQCRAKcAAAD9AAoAEAAOAJEACQAAAP0ACgAQAA8AywCnAAAA/QAKABAA EABxAKcAAAD9AAoAEAARAKgApwAAAP0ACgAQABIAqACnAAAA/QAKABAAEwCoAKcAAAD9AAoAEAAU AHgApwAAAP0ACgAQABUAeQClAAAA/QAKABAAFgBiAMUBAAD9AAoAEAAXAG4AxQEAAP0ACgAQABgA YgDFAQAA/QAKABAAGQCbAKcAAAD9AAoAEAAaAG4ApwAAAL4ADgAQABsAYgBuAGIAYgAeAP0ACgAQ AB8AbgAyAgAA/QAKABAAIABiAKcAAAD9AAoAEAAhAG4AxQEAAP0ACgAQACIAbgClAAAA/QAKABAA IwBuAKUAAAD9AAoAEAAkAG4ApQAAAP0ACgAQACUAbgClAAAA/QAKABAAJgBuAKUAAAD9AAoAEAAn AG4ApQAAAP0ACgAQACgAbgClAAAA/QAKABAAKQBuAKUAAAD9AAoAEAAqAG4ApQAAAP0ACgAQACsA bgClAAAA/QAKABAALADKAKUAAAD9AAoAEAAtAG4ApQAAAP0ACgAQAC4AbgClAAAA/QAKABAALwBu AKUAAAD9AAoAEAAwAG4ApQAAAP0ACgAQADEAbgClAAAA/QAKABAAMgCRAAkAAAD9AAoAEAAzAJEA CQAAAP0ACgAQADQAmAClAAAA/QAKABAANQCYABQCAAD9AAoAEAA2AG4ArAIAAP0ACgARAAAAZQBu AAAA/QAKABEAAQCnAEIAAAABAgYAEQACAKIA/QAKABEAAwCRAHIAAAD9AAoAEQAEAMsAbwAAAP0A CgARAAUAkQBMAgAA/QAKABEABgCRAAkAAAD9AAoAEQAHAJEACQAAAP0ACgARAAgAkQBvAAAA/QAK ABEACQCRAG8AAAD9AAoAEQAKAG4AcgAAAP0ACgARAAsAbgByAAAA/QAKABEADACRAG8AAAD9AAoA EQANAJEAbwAAAP0ACgARAA4AkQBvAAAA/QAKABEADwDKAG8AAAD9AAoAEQAQAHEAbwAAAP0ACgAR ABEAqABvAAAA/QAKABEAEgCoAG8AAAD9AAoAEQATAKgAbwAAAP0ACgARABQAeABvAAAA/QAKABEA FQBpAG8AAAD9AAoAEQAWAGIAbwAAAP0ACgARABcAbgBvAAAA/QAKABEAGABiAG8AAAD9AAoAEQAZ AJsAbwAAAP0ACgARABoAbgBvAAAAAQIGABEAHABuAAECBgARAB8AbgD9AAoAEQAhAG4AbwAAAP0A CgARACIAbgAJAAAA/QAKABEAIwBuAAkAAAD9AAoAEQAkAG4ACQAAAP0ACgARACUAbgAJAAAA/QAK ABEAJgBuAAkAAAD9AAoAEQAnAG4ACQAAAP0ACgARACgAbgAJAAAA/QAKABEAKQDcAA4AAAD9AAoA EQAqANwADgAAAP0ACgARACsA3ADOAgAA/QAKABEALADdAM8CAAD9AAoAEQAtANwAzgIAAP0ACgAR AC4AbgAJAAAA/QAKABEALwDcAM4CAAD9AAoAEQAwAG4AbwAAAP0ACgARADEAbgAJAAAA/QAKABEA MgCRAAkAAAD9AAoAEQAzAJEACQAAAP0ACgARADQAmABvAAAA/QAKABEANQCYAG8AAAD9AAoAEQA2 AG4AowIAAP0ACgASAAAAXQAVAAAA/QAKABIAAQCiAEIAAAABAgYAEgACAKIA/QAKABIAAwBxAAkA AAD9AAoAEgAEAMoACQAAAP0ACgASAAUAbgBvAAAA/QAKABIABgBxAAkAAAD9AAoAEgAHAHEAAAIA AP0ACgASAAgAcQAJAAAA/QAKABIACQBuAAkAAAD9AAoAEgAKAG4ACQAAAP0ACgASAAsAbgBvAAAA /QAKABIADABuAAkAAAD9AAoAEgANAG4ACQAAAP0ACgASAA4AkQBvAAAA/QAKABIADwDKAG8AAAD9 AAoAEgAQAHEACQAAAP0ACgASABEAegAJAAAA/QAKABIAEgB6AAkAAAD9AAoAEgATAHoACQAAAP0A CgASABQAbQAJAAAA/QAKABIAFQBpAAkAAAD9AAoAEgAWAGIACQAAAP0ACgASABcAbgAJAAAA/QAK ABIAGABiAAkAAAD9AAoAEgAZAJsACQAAAP0ACgASABoAbgAJAAAAvgAQABIAGwBiAG4AYgBiAG4A HwD9AAoAEgAgAGIAbwAAAP0ACgASACEAbgAJAAAA/QAKABIAIgBuAAkAAAD9AAoAEgAjAG4ACQAA AP0ACgASACQAbgAJAAAA/QAKABIAJQBuAAkAAAD9AAoAEgAmAG4ACQAAAP0ACgASACcAbgAJAAAA /QAKABIAKABuAAkAAAD9AAoAEgApAG4ACQAAAP0ACgASACoAbgAJAAAA/QAKABIAKwBuAAkAAAD9 AAoAEgAsAN0ADgAAAP0ACgASAC0AbgBvAAAA/QAKABIALgBuAG8AAAD9AAoAEgAvANwADgAAAP0A CgASADAAbgAJAAAA/QAKABIAMQBuAAkAAAD9AAoAEgAyAHEACQAAAP0ACgASADMAcQAJAAAA/QAK ABIANAC6AAkAAAD9AAoAEgA1AJYACQAAAP0ACgASADYAbgCjAgAA/QAKABMAAABdAI8AAAD9AAoA EwABAKcAhQAAAAECBgATAAIAogC9AEgAEwADAJEAAAAgQMsAAABIQJEAAAAwQJEAAAAwQJEAAABA QJEAAAAwQJEAAAAgQG4AAAAgQG4AAAAgQJEAAAAgQJEAAAAgQA0A/QAKABMADgCRAMYBAAD9AAoA EwAPAMsAxgEAAP0ACgATABAAkQDGAQAAvQA8ABMAEQCoAAAAIECoAAAAIECoAAAAIEB4AAAAIEBp AAAAIEBiAAAAIEBuAAAAIEBiAAAAIECbAAAAIEAZAP0ACgATABoAvACQAgAAvgAOABMAGwBiAG4A YgBiAB4AfgIKABMAHwBuAAAAIED9AAoAEwAgAGQAUwEAAH4CCgATACEAbgAAACBA/QAKABMAIgC/ AHUBAAD9AAoAEwAjAL8AdQEAAP0ACgATACQAvwB1AQAA/QAKABMAJQBuAHYBAAD9AAoAEwAmAG4A dgEAAP0ACgATACcAbgB2AQAA/QAKABMAKAC/AHUBAAD9AAoAEwApAMAAbwIAAP0ACgATACoAwABv AgAA/QAKABMAKwDAAG8CAAD9AAoAEwAsANoAbwIAAP0ACgATAC0AwABvAgAA/QAKABMALgDAAG8C AAD9AAoAEwAvAMAAbwIAAP0ACgATADAAwAAbAgAA/QAKABMAMQBuAHUBAAC9ABIAEwAyAJEAAABA QJEAAAAwQDMA/QAKABMANACXABsCAAD9AAoAEwA1AJgAFQIAAH4CCgATADYAbgAAADBA/QAKABQA AABdAJAAAAD9AAoAFAABAKIARgAAAAECBgAUAAIAogC9ABIAFAADAJ0AAADAP9MAAAA0QAQA/QAK ABQABQCZAN0BAAC9AIQAFAAGAJEAAAA0QJEAAAA0QG4AAAA0QG4AAAA+QG4AAADAP24AAADAP24A AADkP24AAAAkQJEAAAA0QMoAAAA0QHEAAAA0QHoAAAA0QHoAAAA0QHoAAAA0QG0AAAA0QGkAAAA+ QGIAAAA0QG4AAAA0QGIAAAA0QJsAAAA0QG4AAAA0QBoAAQIGABQAGwBiAH4CCgAUABwAbgAAADRA vgAKABQAHQBiAGIAHgD9AAoAFAAfAG4AVQEAAL0AEgAUACAAYgAAADRAbgAAADRAIQD9AAoAFAAi AG4AggEAAP0ACgAUACMAbgCDAQAA/QAKABQAJABuAIMBAAD9AAoAFAAlAG4AggEAAP0ACgAUACYA dACDAQAA/QAKABQAJwB0AC8BAAD9AAoAFAAoAG4AMAEAAP0ACgAUACkAbgAxAQAA/QAKABQAKgB0 AGICAAD9AAoAFAArAHQAYwIAAP0ACgAUACwAyQDJAgAA/QAKABQALQB0AGQCAAD9AAoAFAAuAHQA PgIAAP0ACgAUAC8AdAAWAgAA/QAKABQAMAB0ABYCAAD9AAoAFAAxAG4ANQEAAP0ACgAUADIAmQDc AQAA/QAKABQAMwCZANsBAAD9AAoAFAA0AJoAFgIAAP0ACgAUADUAmgAXAgAA/QAKABQANgBuAK0C AAD9AAoAFQAAAF0AqgAAAP0ACgAVAAEAogBGAAAAAQIGABUAAgCiAP0ACgAVAAMAbgB2AAAAfgIK ABUABADMAAAAREAGACkAFQAFAG4AAAAAAAAA+j8AAMgApv0TAB8AAAAAAAD4Px8AAAAAAADAPwO9 ACoAFQAGAJEAAABEQJEAAABEQG4AAAA5QG4AAMBCQG4AAADAP24AAADAPwsA/QAKABUADABuAHcA AAB+AgoAFQANAG4AAAAuQP0ACgAVAA4AtQChAgAA/QAKABUADwDKALoCAAC9ACoAFQAQAG4AAOBA QHoAAAA0QHoAARCjQHoAAAA0QG0AAAA5QGkAAIBBQBUA/QAKABUAFgBiAFgBAAC9AB4AFQAXAHQA AIA7QGIAAIBAQJsAAIBAQG4AAIBBQBoAAQIGABUAGwBiAH4CCgAVABwAbgAAADlAvgAKABUAHQBi AGIAHgD9AAoAFQAfAG4ALwIAAAECBgAVACAAYgD9AAoAFQAhAG4AUAEAAL4AFAAVACIAegB6AG4A bgBuAG4AbgAoAP0ACgAVACkAdABmAgAA/QAKABUAKgB0AGYCAAD9AAoAFQArAHQAEwAAAP0ACgAV ACwAyQDMAgAA/QAKABUALQB0AGYCAAD9AAoAFQAuAHQAZgIAAL4ADAAVAC8AdAB0AG4AMQD9AAoA FQAyAG4AdgAAAP0ACgAVADMAbgB2AAAA/QAKABUANACbAJUCAAD9AAoAFQA1AJwAHAIAAH4CCgAV ADYAbgAAwCdA/QAKABYAAABdAJUAAAD9AAoAFgABAKIAqQAAAAECBgAWAAIAogD9AAoAFgADAJkA kwAAAP0ACgAWAAQA1ADCAgAA/QAKABYABQB0ABYAAAD9AAoAFgAGAHQA4gEAAP0ACgAWAAcAdAAB AgAA/QAKABYACAB0AIsBAAD9AAoAFgAJAHQAkgAAAP0ACgAWAAoAdAByAAAA/QAKABYACwB0AHIA AAD9AAoAFgAMAHQAkQAAAP0ACgAWAA0AdAArAgAA/QAKABYADgC2AFYCAAD9AAoAFgAPAMkAuwIA AAECBgAWABAAmQD9AAoAFgARAKUAbQEAAP0ACgAWABIApQBuAQAA/QAKABYAEwClAG8BAAD9AAoA FgAUAHAAjAEAAP0ACgAWABUAaQB7AQAA/QAKABYAFgBkAFkBAAD9AAoAFgAXAG4AOQIAAP0ACgAW ABgAdAA3AgAA/QAKABYAGQCcAMcBAAC+AAoAFgAaAHQAdAAbAP0ACgAWABwAdAA1AgAAvgAKABYA HQBkAGQAHgD9AAoAFgAfAHQAMQIAAAECBgAWACAAZAD9AAoAFgAhAHQAxwEAAL4AFAAWACIApQCl AHQAdAB0AHQAdAAoAP0ACgAWACkAbgCQAQAAvgASABYAKgB0AHQAyQB0AHQAdAAvAP0ACgAWADAA dAAjAgAAAQIGABYAMQB0AP0ACgAWADIAmQCTAAAA/QAKABYAMwCZAJMAAAD9AAoAFgA0AJoAIwIA AP0ACgAWADUAmgAdAgAA/QAKABYANgB0AK4CAAD9AAoAFwAAAF0AlAAAAP0ACgAXAAEApwCpAAAA AQIGABcAAgCiAP0ACgAXAAMAnQCTAAAA/QAKABcABADUAMMCAAD9AAoAFwAFAG4AcgAAAP0ACgAX AAYAbgAXAAAA/QAKABcABwBuAAICAAD9AAoAFwAIAG4AcgAAAP0ACgAXAAkAbgByAAAA/QAKABcA CgBuAHIAAAD9AAoAFwALAG4AcgAAAP0ACgAXAAwAbgByAAAA/QAKABcADQBuAHIAAAD9AAoAFwAO AJEAcgAAAP0ACgAXAA8AygCEAAAA/QAKABcAEACdAMoBAAC+AA4AFwARAHoAegB6AG0AFAD9AAoA FwAVAGkAfAEAAP0ACgAXABYAYgBaAQAAAQIGABcAFwBuAP0ACgAXABgAbgDIAQAAvgAWABcAGQCb AG4AbgBuAGIAYgBuAGIAIAD9AAoAFwAhAHQAyQEAAL4AIgAXACIAegB6AG4AbgBuAG4AbgBuAG4A bgDKAG4AbgBuAC8A/QAKABcAMABuAB4CAAABAgYAFwAxAG4A/QAKABcAMgCdAJMAAAD9AAoAFwAz AJ0AkwAAAP0ACgAXADQAmgAeAgAA/QAKABcANQCeAB4CAAD9AAoAFwA2AG4ArwIAAP0ACgAYAAAA XQBxAAAA/QAKABgAAQCiAHUAAAABAgYAGAACAKIA/QAKABgAAwCdACYCAAC9ACQAGAAEANMAAaCO QG4AAAAkQG4AAAAAQG4AAAAQQG4AAAAqQAgA/QAKABgACQBuAC0CAAD9AAoAGAAKAG4AKgIAAP0A CgAYAAsAbgByAAAA/QAKABgADABuAHIAAAD9AAoAGAANAG4AcgAAAL0AHgAYAA4AwwABUJlAygAB FKRAnQAAADJAegABAG5AEQADAg4AGAASAHoAZmZmZmZmIUC9ABgAGAATAHoAAWCNQG0AAZCQQHcA ARCTQBUAAQIGABgAFgBiAL0AGAAYABcAbgAAABhAbgAAADRAmwAAADZAGQC+AAoAGAAaAG4AbgAb AP0ACgAYABwAbgA0AgAAvgAKABgAHQBiAGIAHgD9AAoAGAAfAG4AMAIAAAECBgAYACAAYgB+AgoA GAAhAG4AAZiXQL4AFAAYACIAegB6AG4AbgBuAG4AbgAoAP0ACgAYACkAbgCPAQAAvgASABgAKgBu AG4AygBuAG4AbgAvAP0ACgAYADAAbgAgAgAAAQIGABgAMQBuAP0ACgAYADIAnQBzAAAA/QAKABgA MwCdAHMAAAD9AAoAGAA0AJoAIAIAAP0ACgAYADUAmgAhAgAA/QAKABgANgB0ALACAAD9AAoAGQAA AF0AmAAAAP0ACgAZAAEAogB1AAAAAQIGABkAAgCnAP0ACgAZAAMAbgByAAAA/QAKABkABADVAHIB AAD9AAoAGQAFAG4AcgAAAP0ACgAZAAYAbgByAAAA/QAKABkABwBuAHIAAAD9AAoAGQAIAHQAXgEA AP0ACgAZAAkAbgByAAAA/QAKABkACgBuAHIAAAD9AAoAGQALAG4AcgAAAP0ACgAZAAwAbgByAAAA /QAKABkADQBuAHIAAAD9AAoAGQAOAMIAcgAAAP0ACgAZAA8AygByAAAAAQIGABkAEABuAP0ACgAZ ABEApQBwAQAA/QAKABkAEgClAHEBAAD9AAoAGQATAKUAcgEAAP0ACgAZABQAcABzAQAAvgA8ABkA FQBpAGIAbgBiAJsAbgBiAG4AYgBiAG4AYgBuAHoAegBuAG4AbgBuAG4AbgBuAG4AygBuAG4AbgAv AP0ACgAZADAAbgB3AgAAAQIGABkAMQBuAP0ACgAZADIAbgByAAAA/QAKABkAMwBuAHIAAAD9AAoA GQA0AJwAlwIAAP0ACgAZADUAnwAiAgAA/QAKABkANgB0ALECAAD9AAoAGgAAAF0AmgAAAP0ACgAa AAEAogB1AAAAAQIGABoAAgCnAP0ACgAaAAMAnQB0AAAAfgIKABoABADTAAG4oED9AAoAGgAFAG4A cgAAAP0ACgAaAAYAbgByAAAA/QAKABoABwBuAHIAAAB+AgoAGgAIAG4AAfCeQP0ACgAaAAkAbgBy AAAA/QAKABoACgBuAHIAAAD9AAoAGgALAG4AcgAAAP0ACgAaAAwAbgByAAAA/QAKABoADQBuAHIA AAADAg4AGgAOAMQAmpmZmZmZMEC9ADAAGgAPAMoAAdioQJ0AAAA2QHoAAQA0QHoAAYiYQHoAAAAl QG0AAdCmQGkAAAAmQBUAAQIGABoAFgBiAL0AGAAaABcAbgAAAABAYgAAACRAmwAAAD1AGQC+ABQA GgAaAG4AYgBuAGIAYgBuAGIAIAB+AgoAGgAhAG4AAAA2QL4AFAAaACIAegB6AG4AbgBuAG4AbgAo AH4CCgAaACkAbgABMIZAvgASABoAKgBuAG4AygBuAG4AbgAvAP0ACgAaADAAbgAYAgAAAQIGABoA MQBuAP0ACgAaADIAnQB0AAAA/QAKABoAMwCdAHQAAAD9AAoAGgA0AJ4AGAIAAP0ACgAaADUAngAY AgAAfgIKABoANgBuAAGge0D9AAoAGwAAAIoAUAIAAP0ACgAbAAEAogBcAgAAAQIGABsAAgCnAP0A CgAbAAMAbgBTAgAA/QAKABsABADMAFMCAAD9AAoAGwAFAG4AUwIAAP0ACgAbAAYAbgBTAgAA/QAK ABsABwBuAFMCAAD9AAoAGwAIAHQAUwIAAP0ACgAbAAkAbgBTAgAA/QAKABsACgBuAFMCAAD9AAoA GwALAG4AUwIAAP0ACgAbAAwAbgBUAgAA/QAKABsADQBuAFMCAAD9AAoAGwAOAJEAUwIAAP0ACgAb AA8AygBTAgAAAQIGABsAEABuAP0ACgAbABEApQBTAgAAvgBOABsAEgClAKUApQBxAG4AbgBuAJsA bgBuAG4AbgBuAG4AbgBuAHoAegBuAG4AbgBuAG4AbgBuAG4AygBuAG4AbgBuAG4AbgBuAJwAnwA1 AP0ACgAbADYAbgCyAgAA/QAKABwAAACKAFECAAD9AAoAHAABAKIAXAIAAAECBgAcAAIApwD9AAoA HAADAG4AVAIAAP0ACgAcAAQAzADEAgAA/QAKABwABQBuAFQCAAD9AAoAHAAGAG4AUwIAAP0ACgAc AAcAbgBUAgAA/QAKABwACQBuAFMCAAD9AAoAHAAKAG4AVAIAAP0ACgAcAAsAbgBUAgAA/QAKABwA DABuAFQCAAD9AAoAHAANAG4AUwIAAP0ACgAcAA4AkQBTAgAA/QAKABwADwDMALwCAAC+AFIAHAAQ AG4ApQClAKUApQBxAG4AbgBuAJsAbgBuAG4AbgBuAG4AbgBuAHoAegBuAG4AbgBuAG4AbgBuAG4A ygBuAG4AbgBuAG4AbgBuAJwAnwA1AP0ACgAcADYAbgCzAgAA/QAKAB0AAABdAJYAAAD9AAoAHQAB AKIAlwAAAAECBgAdAAIApwC9ABIAHQADAG4AAAAAAMwAAAAAQAQA/QAKAB0ABQBuACIAAAB+AgoA HQAGAJEAAAAAQP0ACgAdAAcAkgANAgAAvQASAB0ACABuAAAAAEBuAAAAAEAJAP0ACgAdAAoAbgAi AAAA/QAKAB0ACwBuACIAAAC9AIoAHQAMAG4AAAAAQG4AAAAAQJEAAAAAQMwAAAAAQG4AAAAAQHoA AAAAQHoAAAAAQHoAAAAAQG0AAAAAQGkAAAAAQGIAAAAAQL4AAAAAQGIAAAAAQJsAAAAAQG4AAAAA QGIAAAAAQG4AAAAAQGIAAAAAQGIAAAAAQG4AAAAAAGIAAAAAAG4AAAAAQCEA/QAKAB0AIgB6AHcB AAC9AH4AHQAjAHoAAAAAQHoAAAAAQHoAAAAAQHoAAAAAQHoAAAAAQHoAAAAAQHoAAAAAQL4AAAAA QL4AAAAAQMoAAAAAQL4AAAAAQL4AAAAAQL4AAAAAQL4AAAAAQHoAAAAAQG4AAAAAAG4AAAAAAJsA AAAAQJsAAAAAQG4AAAAAQDYA/QAKAB4AAABdAEcAAAD9AAoAHgABAKIAGgAAAAECBgAeAAIAogD9 AAoAHgADAKkAGAAAAP0ACgAeAAQAzQAYAAAA/QAKAB4ABQB7ABgAAAD9AAoAHgAGAKkAGAAAAP0A CgAeAAcAbgADAgAA/QAKAB4ACAB7ABgAAAD9AAoAHgAJAKkAGAAAAP0ACgAeAAoAqQAYAAAA/QAK AB4ACwCpABgAAAD9AAoAHgAMAKkAGAAAAP0ACgAeAA0AqQAYAAAA/QAKAB4ADgCpABgAAAD9AAoA HgAPAM0AGQAAAP0ACgAeABAAqgCZAAAA/QAKAB4AEQB6AHQBAAD9AAoAHgASAHoAdAEAAP0ACgAe ABMAegB0AQAA/QAKAB4AFABtAHQBAAD9AAoAHgAVAGkAfQEAAP0ACgAeABYAewCZAAAA/QAKAB4A FwB7AJkAAAD9AAoAHgAYAHsAmQAAAP0ACgAeABkAvQCZAAAA/QAKAB4AGgB7AJkAAAC+ABIAHgAb AGIAbgBiAGIAbgBiACAA/QAKAB4AIQB7AJkAAAD9AAoAHgAiAHoAvAAAAP0ACgAeACMAegC8AAAA /QAKAB4AJAB6ALwAAAD9AAoAHgAlAHoAvAAAAP0ACgAeACYAegC8AAAA/QAKAB4AJwB6ALwAAAD9 AAoAHgAoAHoAvAAAAP0ACgAeACkAegC8AAAA/QAKAB4AKgC+ALwAAAD9AAoAHgArAL4AvAAAAP0A CgAeACwAygC8AAAA/QAKAB4ALQC+ALwAAAD9AAoAHgAuAL4AvAAAAP0ACgAeAC8AvgC8AAAA/QAK AB4AMAC+AHQBAAD9AAoAHgAxAHoAkQEAAP0ACgAeADIAewDVAQAA/QAKAB4AMwB7ANUBAAD9AAoA HgA0AJsAdAEAAP0ACgAeADUAmwB0AQAA/QAKAB4ANgBuALQCAAD9AAoAHwAAAF0ALAEAAL4ACgAf AAEAawCiAAIAfgIKAB8AAwBuAAAAKEABAgYAHwAEAG4AfgIKAB8ABQBuAAAAKEC+AAoAHwAGAG4A bgAHAP0ACgAfAAgAbgCSAgAAAQIGAB8ACQBuAL0AEgAfAAoAbgAAAChAbgAAAChACwC+AAwAHwAM AG4AbgBuAA4AfgIKAB8ADwDMAAAAMUABAgYAHwAQAG4A/QAKAB8AEQBuAF4CAAD9AAoAHwASAG4A LQEAAP0ACgAfABMAbgAtAQAA/QAKAB8AFABiAC4BAAC+AC4AHwAVAGkAYgBuAGIAmwBuAGIAbgBi AGIAbgBiAHsAbgBuAG4AbgBuAG4AbgAoAH4CCgAfACkAbgAAABRA/QAKAB8AKgBuABEAAAD9AAoA HwArAG4AFAAAAP0ACgAfACwAygDNAgAA/QAKAB8ALQBuABEAAAB+AgoAHwAuAG4AAYiUQP0ACgAf AC8AbgARAAAA/QAKAB8AMABuABEAAAC+AAwAHwAxAG4AbgBuADMAfgIKAB8ANACcAAAAIED9AAoA HwA1AJwAlgIAAAECBgAfADYAewDXAEQAmkIAAGwCUgC3AJYApwDFAFgA9AL0AjoC8AL+Ar4C0AJC AkAC5gLYAr4CzAJGAkICQQJOAtwBAgK8AewBVAEyAbYBwAIIAhAAIAAAADcAWQEAAAAAwAFhAAgC EAAhAAAANwAdAQAAAADAAWEACAIQACIAAAA3AP8AAAAAAIABYQAIAhAAIwAAADcA/wAAAAAAgAFh AAgCEAAkAAAANwArAgAAAADAAWEACAIQACUAAAA3AP8AAAAAAIABYQAIAhAAJgAAADcA/wAAAAAA gAFhAAgCEAAnAAAANwD/AAAAAACAAWEACAIQACgAAAA3AP8AAAAAAIABYQAIAhAAKQAAADcA/wAA AAAAgAFhAAgCEAAqAAAANwD/AAAAAACAAWEACAIQACsAAAA3AP8AAAAAAIABYQAIAhAALAAAADcA /wAAAAAAgAFhAAgCEAAtAAAANwD/AAAAAACAAWEACAIQAC4AAAA3AP8AAAAAAIABYQAIAhAALwAA ADcA/wAAAAAAAAEPAAgCEAAwAAAANwAcAgAAAADAAWEACAIQADEAAAA3AP8AAAAAAMABYQAIAhAA MgAAADcA/wAAAAAAgAFhAAgCEAAzAAAANwD/AAAAAACAAWEACAIQADQAAAA3AP8AAAAAAIABWAAI AhAANQAAADcA/wAAAAAAAAEPAAgCEAA2AAAANwD/AAAAAAAAAQ8ACAIQADcAAAA3AB0BAAAAAMAB xgAIAhAAOAAAADcAHQEAAAAAwAHGAL4AdAAgAAAAXQBrAKIAbgBuAG4AbgBuAG4AbgBuAG4AbgBu AG4AzABuAG4AbgBuAGIAaQBiAG4AYgCbAG4AYgBuAGIAYgBuAGIAewBuAG4AbgBuAG4AbgBuAG4A bgBuAMoAbgBuAG4AbgBuAG4AbgCcAJwAewA2AL4AMAAhAAAAaAB7AKcAewB7AHsAewB7AG4AewB7 AHsAewB7AHsAzQB7AHsAewBuAGIAFAC+ABwAIQAWAGIAbgBiAJsAbgBiAG4AYgBiAG4AYgAgAL4A KAAhACIAewB7AHsAewCrAHsAewB7AHsAewDbAHsAewB7AHsAewB7ADIAvgAMACEANAB7AIAAewA2 AL4ALgAiAAAAaAB7AKIAewB7AHsAewB7AG4AewB7AHsAewB7AHsAzQB7AHsAewB7ABMAAQIGACIA FwB7AL4ACgAiABkAvQB7ABoAAQIGACIAHAB7AAECBgAiAB8AewC+ACgAIgAiAHsAewB7AHsAqwB7 AHsAewB7AHsA2wB7AHsAewB7AHsAewAyAL4ADAAiADQAvQB+AHsANgC+AC4AIwAAAGgAewCiAG4A bgCrAHsAewBuAHsAewB7AHsAewB7AM0AewB7AHsAewATAAECBgAjABcAewC+AAoAIwAZAL0AewAa AAECBgAjABwAewABAgYAIwAfAHsAvgAwACMAIgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsA ewB7AG4AYgC9AH4AewA2AAECBgAkAAAAaAD9AAoAJAABAHwABwIAAAECBgAkAAIAogD9AAoAJAAD AN4ACAIAAL4AJgAkAAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4AewATAAECBgAkABcA ewC+AAoAJAAZAL0AewAaAAECBgAkABwAewABAgYAJAAfAHsAvgAwACQAIgB7AHsAewB7AKsAewB7 AHsAewB7ANsAewB7AHsAewB7AG4AYgC9AH4AewA2AAECBgAlAAAAaAD9AAoAJQABAHwANAEAAAEC BgAlAAIAogD9AAoAJQADAN4ACQIAAL4AJgAlAAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDe AN4AewATAAECBgAlABcAewC+AAoAJQAZAL0AewAaAAECBgAlABwAewABAgYAJQAfAHsAvgAwACUA IgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsAewB7AG4AYgC9AH4AewA2AAECBgAmAAAAfwD9 AAoAJgABAIwA0gEAAAECBgAmAAIAogD9AAoAJgADAN4AkgEAAL4AJgAmAAQA3gDeAN4A3gDeAN4A 3gDeAN4A3gDeAN4A3gDeAN4AewATAAECBgAmABcAewC+AAoAJgAZAL0AewAaAAECBgAmABwAewAB AgYAJgAfAHsAvgAwACYAIgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsAewB7AG4AYgC9AH4A ewA2AAECBgAnAAAAaAD9AAoAJwABAIwA0wEAAAECBgAnAAIAawD9AAoAJwADAN4AkwEAAL4AJgAn AAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4AewATAAECBgAnABcAewC+AAoAJwAZAL0A ewAaAAECBgAnABwAewABAgYAJwAfAHsAvgAwACcAIgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7 AHsAewB7AG4AYgC9AH4AewA2AAECBgAoAAAAaAD9AAoAKAABAHwAlAEAAAECBgAoAAIAcQD9AAoA KAADAN4AlQEAAL4AJgAoAAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4AewATAAECBgAo ABcAewC+AAoAKAAZAL0AewAaAAECBgAoABwAewABAgYAKAAfAHsAvgAwACgAIgB7AHsAewB7AKsA ewB7AHsAewB7ANsAewB7AHsAewB7AG4AYgC9AH4AewA2AAECBgApAAAAaAD9AAoAKQABAKoACgIA AAECBgApAAIAewD9AAoAKQADAN4ACwIAAL4AJgApAAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A 3gDeAN4AewATAAECBgApABcAewC+AAoAKQAZAL0AewAaAAECBgApABwAewABAgYAKQAfAHsAvgAw ACkAIgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsAewB7AG4AYgC9AH4AewA2AAECBgAqAAAA aAD9AAoAKgABAHsAlgEAAAECBgAqAAIAewD9AAoAKgADAN8AhwIAAL4AJgAqAAQA3wDfAN8A3wDf AN8A3wDfAN8A3wDfAN8A3wDfAN8AewATAAECBgAqABcAewC+AAoAKgAZAL0AewAaAAECBgAqABwA ewABAgYAKgAfAHsAvgAwACoAIgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsAewB7AG4AYgC9 AH4AewA2AL4ADAArAAAAaAB7AHsAAgD9AAoAKwADAOAAlwEAAL4ACgArAAQA4ADgAAUAvQA8ACsA BgCTAAAAIECTAAE6kUCTAAAAKECTAAAAMECTAAE6oUCTAAAAOECTAAAAQECTAAE6sUCTAAAASEAO AAECBgArAA8AzgC9ABgAKwAQAJMAAABQQJMAATrBQJMAAABYQBIAAQIGACsAEwB7AAECBgArABcA ewC+AAoAKwAZAL0AewAaAAECBgArABwAewABAgYAKwAfAHsAvgAoACsAIgB7AHsAewB7AKsAewB7 AHsAewB7ANsAewB7AHsAewB7AHsAMgC+AAwAKwA0AL0AfgB7ADYAvgAMACwAAABoAHsAewACAP0A CgAsAAMA4QAFAgAAvgAKACwABADhAOEABQC9AB4ALAAGAJMAAABIQJMAAJBQQJMAAABSQJMAAABY QAkAAwIOACwACgCTAJqZmZmZiWBAvQASACwACwCTAAAAYkCTAAAAaEAMAAMCDgAsAA0AkwCamZmZ mYlwQH4CCgAsAA4AkwAAAHJAAQIGACwADwDOAL0AGAAsABAAkwAAAHhAkwABE+BAkwAAAIJAEgAB AgYALAATAHsAAQIGACwAFwB7AL4ACgAsABkAvQB7ABoAAQIGACwAHAB7AAECBgAsAB8AewC+ACgA LAAiAHsAewB7AHsAqwB7AHsAewB7AHsA2wB7AHsAewB7AHsAewAyAL4ADAAsADQAvQB+AHsANgC+ AC4ALQAAAGgAewB7AJQAlACUAJQAlAB0AJQAlACUAJQAlACUAM8AlACUAJQAewATAAECBgAtABcA ewC+AAoALQAZAL0AewAaAAECBgAtABwAewABAgYALQAfAHsAvgAoAC0AIgB7AHsAewB7AKsAewB7 AHsAewB7ANsAewB7AHsAewB7AHsAMgC+AAwALQA0AL0AfgB7ADYAAQIGAC4AAABoAP0ACgAuAAEA rAAOAgAAAQIGAC4AAgB7AP0ACgAuAAMA3gAGAgAAvgAmAC4ABADeAN4A3gDeAN4A3gDeAN4A3gDe AN4A3gDeAN4A3gB7ABMAAQIGAC4AFwB7AL4ACgAuABkAvQB7ABoAAQIGAC4AHAB7AAECBgAuAB8A ewC+ACgALgAiAHsAewB7AHsAqwB7AHsAewB7AHsA2wB7AHsAewB7AHsAewAyAL4ADAAuADQAvQB+ AHsANgD9AAoALwABAFgAPAIAAAECBgAvAAIAWAD9AAoALwADAFgAJAIAAL4ADAAvAAQAWABYAFgA BgC+ABIALwAIAFkAWABYAFgAWABYAA0AvgAOAC8AEABYAFgAWABYABMAAQIGADAAAABoAP0ACgAw AAEAewDPAQAAAQIGADAAAgB7AP0ACgAwAAMA3gDOAQAAvgAmADAABADeAN4A3gDeAN4A3gDeAN4A 3gDeAN4A3gDeAN4A3gB7ABMAAQIGADAAFwB7AL4ACgAwABkAvQB7ABoAAQIGADAAHAB7AAECBgAw AB8AewC+ACgAMAAiAHsAewB7AHsAqwB7AHsAewB7AHsA2wB7AHsAewB7AHsAewAyAL4ADAAwADQA vQB+AHsANgABAgYAMQAAAGgA/QAKADEAAQB7AEICAAABAgYAMQACAHsA/QAKADEAAwCqAEECAAC+ ACYAMQAEAKoAlQCVAJUAlQCVAJUAlQCVAJUAlQDQAJUAlQCVAHsAEwABAgYAMQAXAHsAvgAKADEA GQC9AHsAGgABAgYAMQAcAHsAAQIGADEAHwB7AL4AKAAxACIAewB7AHsAewCrAHsAewB7AHsAewDb AHsAewB7AHsAewB7ADIAvgAMADEANAC9AH4AewA2AAECBgAyAAAAaAD9AAoAMgABAHsAXQIAAAEC BgAyAAIAewD9AAoAMgADAN4AXwIAAL4AJgAyAAQA3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDe AN4AewATAAECBgAyABcAewC+AAoAMgAZAL0AewAaAAECBgAyABwAewABAgYAMgAfAHsAvgAoADIA IgB7AHsAewB7AKsAewB7AHsAewB7ANsAewB7AHsAewB7AHsAMgC+AAwAMgA0AL0AfgB7ADYAAQIG ADMAAABoAP0ACgAzAAEAewBlAgAAAQIGADMAAgB7AP0ACgAzAAMA3gBtAgAAvgAmADMABADeAN4A 3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gB7ABMAAQIGADMAFwB7AL4ACgAzABkAvQB7ABoAAQIG ADMAHAB7AAECBgAzAB8AewC+ACgAMwAiAHsAewB7AHsAqwB7AHsAewBYAFgA2QBYAFgAWABYAHsA ewAyAL4ADAAzADQAvQB+AHsANgABAgYANAAAAIcA/QAKADQAAQB7AD8CAAABAgYANAACAHsA/QAK ADQAAwDeAEACAAC+ACQANAAEAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeABIAAQIGADQA GQCIAAECBgA0ACYAhwABAgYANAAsANkAvgAKADQANACIAIgANQD9AAoANQABAHsADwAAAAECBgA1 AAIAewD9AAoANQADAFgAEAAAAL4ADAA1AAQAWABYAFgABgC+ABIANQAIAFkAWABYAFgAWABYAA0A vgAOADUAEABYAFgAWABYABMA/QAKADYAAQB7ABIAAAABAgYANgACAFgA/QAKADYAAwDeAGwCAAC+ ACQANgAEAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeAN4A3gDeABIAAQIGADcAAADWAP0ACgA3AAEA zQDFAgAA/QAKADcAAwDGAMYCAAABAgYANwAHANcAAQIGADcAGQDYAAECBgA3ACYA1gABAgYANwAs ANkAvgAKADcANADYANgANQABAgYAOAAAANYA/QAKADgAAQDNAMsCAAD9AAoAOAADAMYAygIAAAEC BgA4AAcA1wABAgYAOAAZANgAAQIGADgAJgDWAAECBgA4ACwA2QC+AAoAOAA0ANgA2AA1ANcANgAa EgAA4AF4AJAAmgCSALoAugC6ALoAugC6ALoABAEuAZoAwgBeAMIAwgDCAMIAhABeAE4AXADCAQwA AQAVAAMACQAFANgA7ADOAA8AAvBUAQAAEAAI8AgAAAADAAAACQQAAA8AA/A8AQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8H4AAACiDArwCAAAAAYE AAAACgAAowAL8DwAAACAACy4WAmLAAIAAAC/AAgACABYAQAAAACBAVAAAAiDAVAAAAi/ARAAEAAB AgAAAAA/AgMAAwC/AwIAAgAAABDwEgAAAAMAFwCDAxMA6gAZAMsAFQAJAAAAEfAAAAAAXQA0ABUA EgAZAAYAEUAsuFgJ6AiCCQAAAAANABYAOkZOLIRSh0Gy3bdsTNZhvAAAEAAAAAAAAADsAAgAAAAN 8AAAAAC2ARIAEgIAAAAAAAAAACUAGAAAAAAAPAAmAABkZW1zZjRzNzoKVmFsdWUgdXBkYXRlZCBp biBqdW5lIDIwMDYKPAAYAAAAFQAvAAsACQAUAGYACwAlAAAAAA4ADuwAfgAPAATwfgAAAKIMCvAI AAAACAQAAAAKAACjAAvwPAAAAIAAkLhYCYsAAgAAAL8ACAAIAFgBAAAAAIEBUAAACIMBUAAACL8B EAAQAAECAAAAAD8CAwADAL8DAgACAAAAEPASAAAAAwAiAOsBBACIACQA/AAGAJkAAAAR8AAAAABd ADQAFQASABkACAARQJC4WAnoCYIJAAAAAA0AFgCqryY9GppwQ7eNQzfHbn1FAAC/AAgAAAAAAOwA CAAAAA3wAAAAALYBEgASAgAAAAAAAAAAMgAYAAAAAAA8ADMAAGRlbXNmNHM3OgpBbGwgbXBlZyBj b2RlY3MgdWRwYXRlZCBpbiBOb3ZlbWJlciAyMDA2PAAYAAAAFQAvAAsACQAUAKMACwAyAAAOwCBA ARwAFAAGACIAAAAIAAgAAGRlbXNmNHM3DhwAFAAVABcAAAAGAAgAAGRlbXNmNHM3Dj4CEgC+BwAA AABAAAAAPABkAAAAAACgAAQADQAKAEEACgACAAEADQAnAAAAHQAPAAMAAAAAAAABAAAAAAAAAB0A DwABAAACAAAAAQAAAAAAAgIdAA8AAgEAAAAAAAEAAQABAAAAHQAPAAATAC0AAAABABMAEwAtLZkA AgAkCeUAegAPADYANgADABIAKgAqAAMAEgAyADIAAwASADMAMwADABIANAA0AAMAEgAuAC4AAwAS ADAAMAADABIAKwArAAMABQAsACwAAwAFACgAKAADABIAKQApAAMAEgAkACQAAwASACUAJQADABIA JgAmAAMAEgAnACcAAwASAO8ATgAHADcACQADAAMALAAsAAcACQAsACwADwAQACwALAAXABgALAAs AB0AHQAsACwAIwAlACwALAAnACkALAAsADAAMAAsACwANwA3ACwALAC4Aa4ABwAHACAAIADQyep5 +brOEYyCAKoAS6kLAgAAABcAAAAdAAAAaAB0AHQAcAA6AC8ALwBzAHAAZQBlAHgALgBzAG8AdQBy AGMAZQBmAG8AcgBnAGUALgBuAGUAdAAAAODJ6nn5us4RjIIAqgBLqQs8AAAAaAB0AHQAcAA6AC8A LwBzAHAAZQBlAHgALgBzAG8AdQByAGMAZQBmAG8AcgBnAGUALgBuAGUAdAAvAAAAugEJAAYAAFNo ZWV0MWcIFwBnCAAAAAAAAAAAAAACAAH/////A0QAAGcIEwBnCAAAAAAAAAAAAAADAAEAAAAAaAg3 AGgIAAAAAAAAAAAAAAMAAAAAAAADAAQAAAAAABMAEwAOAA4AEwATABAAEAAfAB8ACAAIACAAAABo CCcAaAgAAAAAAAAAAAAAAwAAAAAAAAEABAAAAAAAEwATABoAGgAEAAAAnAgmAJwIAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAiwgQAIsIAAAAAAAAAAAAAAAAcmbICAkAyAgAAAgA AAAACgAAAAkIEAAABhAAcyDNB9nAAQAGAwAACwIYAAAAAAAAAAAAKwAAALA4AQAfTgEAJVMBAA0A AgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgAB AIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEFFAAAABUAAACDAAIAAACEAAIAAAAmAAgAWzSuyWQy 6T8nAAgAWzSuyWQy6T8oAAgAih08/P1+7z8pAAgAih08/P1+7z+hACIAAQBKAAEAAQABAAAAyADI AAAAAAAAAOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAAAbRlYAAIAAAB9AAwAAQABAAAPQAACAAAA fQAMAAIAAgAAAg8AAgAAAH0ADAADAAMAtgoPAAIAAAB9AAwABAAEAEkKDwACAAAAfQAMAAUABQC2 CA8AAgAAAH0ADAAGAAYAbQkPAAIAAAB9AAwABwAHAEkNDwACAAAAfQAMAAgACAAkCg8AAgAAAH0A DAAJAAkAbQoPAAIAAAB9AAwACgAKAEkNDwACAAAAfQAMAAsACwBtCg8AAgAAAH0ADAAMAAwAbQkP AAIAAAAAAg4AAAAAACsAAAAAAA8AAAAIAhAAAAAAAA0A/wAAAAAAAAEPAAgCEAABAAAADQAsAQAA AAAAAQ8ACAIQAAIAAAANAP8AAAAAAAABDwAIAhAAAwAAAA0A/wAAAAAAAAEPAAgCEAAEAAAADQD/ AAAAAAAAAQ8ACAIQAAUAAAANAP8AAAAAAAABDwAIAhAABgAAAA0A/wAAAAAAAAEPAAgCEAAHAAAA DQD/AAAAAAAAAQ8ACAIQAAgAAAANAA0CAAAAAMABYAAIAhAACQAAAA0AKQQAAAAAwAFhAAgCEAAK AAAADQDwAAAAAADAAWEACAIQAAsAAAANAPAAAAAAAMABYQAIAhAADAAAAA0A8AAAAAAAwAFhAAgC EAANAAAADQBJAgAAAADAAWAACAIQAA4AAAANAPAAAAAAAMABYQAIAhAADwAAAA0A8AAAAAAAwAFh AAgCEAAQAAAADQDwAAAAAADAAWEACAIQABEAAAANAPAAAAAAAMABYQAIAhAAEgAAAA0A8AAAAAAA wAFhAAgCEAATAAAADQDwAAAAAADAAWEACAIQABQAAAANAPAAAAAAAMABYQAIAhAAFQAAAA0A8AAA AAAAwAFhAAgCEAAWAAAADQDwAAAAAADAAWEACAIQABcAAAANAPAAAAAAAMABYQAIAhAAGAAAAA0A 8AAAAAAAwAFhAAgCEAAZAAAADQDwAAAAAADAAWEACAIQABoAAAANAPAAAAAAAMABYQAIAhAAGwAA AA0A4AEAAAAAwAFhAAgCEAAcAAAADQDwAAAAAADAAWEACAIQAB0AAAANAPAAAAAAAMABYQAIAhAA HgAAAA0A8AAAAAAAwAFhAAgCEAAfAAAADQDwAAAAAADAAWEA/QAKAAAAAABVADgAAAAGAB0AAQAA AFUAAACYDkwL//8gAAIAAP4HAFoAAAEAAMAHAjIALwAATWVkaWEgQ29kaW5nIFN1bW1hcnkgRGF0 YWJhc2UgLSBJVFUtVCBTRzE2IFEuMjO+ABgAAQACAEEAQQBBAEEAQQBBAEgASABCAAoABgAdAAIA AABVAAAA+A5MC///IAADAAD/BwBaAAACAADABwIZABYAAEdlbmV2YSwgMyBPY3RvYmVyIDIwMDi+ ABYAAgACAEEAQQBBAEEAQQBBAEgASAAJAAYAHQADAAAAVQAAACgPTAv//yAABAAA/wcAWgAAAwAA wAcCKgAnAABTb3VyY2U6IFJhcHBvcnRldXIsIFEuMjMvMTYgKEguIFRhZGRlaSm+ABYAAwACAEEA QQBBAEEAQQBBAEMAQwAJAAYAHQAEAAAAVQAAAHgPTAv//yAAdAGm/QcAWgAABAAAwAcCWgBXAABD b250YWN0OiBIZXJ26SBUYWRkZWksIEh1YXdlaSBUZWNobm9sb2dpZXMsICs0OSAxNjIgMjk0MCAy NjAsIDxoZXJ2ZS50YWRkZWlAaHVhd2VpLmNvbT6+ABYABAACAEEAQQBBAEEAQQBBAEgASAAJAAEC BgAFAAAAVQC+ABYABQACAEEAQQBBAEEAQQBBAEgASAAJAAECBgAGAAAAVQC+ABAABgACAEEAQQBB AEEAQQAGAP0ACgAGAAcATQBlAAAAvgAOAAYACABOAE4ATQCBAAsA/QAKAAYADABOAGQAAAABAgYA BwALAFgA/QAKAAgAAACKAEAAAAC+AAoACAABAF4AXgACAP0ACgAIAAMAXwACAQAA/QAKAAgABABf AEMBAAD9AAoACAAFAF8ASAAAAP0ACgAIAAYAXwBJAAAA/QAKAAgABwBfAC0AAAD9AAoACAAIAF8A SgAAAP0ACgAIAAkAXwBNAAAA/QAKAAgACgBfAEsAAAABAgYACAALAGsA/QAKAAgADABfAAsAAAD9 AAoACQAAAIoAQQAAAL4ACgAJAAEAXgBeAAIA/QAKAAkAAwBfADMAAAD9AAoACQAEAF8ARAEAAP0A CgAJAAUAXwAsAAAA/QAKAAkABgBfAAoBAAD9AAoACQAHAF8AsQAAAP0ACgAJAAgAXwA1AAAA/QAK AAkACQBfADQAAAD9AAoACQAKAF8ANgAAAAECBgAJAAsAawD9AAoACQAMAF8ATAAAAP0ACgAKAAAA igAqAAAA/QAKAAoAAQBeAEIAAAABAgYACgACAF4A/QAKAAoAAwBiAG8AAAD9AAoACgAEAGIAbwAA AP0ACgAKAAUAYgAJAAAA/QAKAAoABgBiAAkAAAD9AAoACgAHAGIAbwAAAP0ACgAKAAgAYgBvAAAA /QAKAAoACQBiAG8AAAD9AAoACgAKAGIAbwAAAAECBgAKAAsAbgD9AAoACgAMAGIAbwAAAP0ACgAL AAAAigAuAAAA/QAKAAsAAQBeAEIAAAABAgYACwACAF4A/QAKAAsAAwBiAAkAAAD9AAoACwAEAGIA CQAAAP0ACgALAAUAYgBvAAAA/QAKAAsABgBiAG8AAAD9AAoACwAHAGIAbwAAAP0ACgALAAgAYgBv AAAA/QAKAAsACQBiAG8AAAD9AAoACwAKAGIAbwAAAAECBgALAAsAbgD9AAoACwAMAGIACQAAAP0A CgAMAAAAigArAAAA/QAKAAwAAQBeALMAAAABAgYADAACAF4A/QAKAAwAAwBiALcAAAD9AAoADAAE AGIARQEAAP0ACgAMAAUAYgC0AAAA/QAKAAwABgBjALUAAAD9AAoADAAHAGMAtgAAAP0ACgAMAAgA YgDTAAAA/QAKAAwACQBiANMAAAD9AAoADAAKAGIA0wAAAAECBgAMAAsAbgD9AAoADAAMAGIAuAAA AP0ACgANAAAAigDCAAAA/QAKAA0AAQBeABoAAAABAgYADQACAF4A/QAKAA0AAwBkAEkBAAD9AAoA DQAEAGQASQEAAP0ACgANAAUAZAAlAAAA/QAKAA0ABgBkAMAAAAD9AAoADQAHAGQAwQAAAP0ACgAN AAgAZADVAAAA/QAKAA0ACQBkANYAAAD9AAoADQAKAGQA1wAAAAECBgANAAsAdAD9AAoADQAMAGQA xQAAAP0ACgAOAAAAigCKAAAA/QAKAA4AAQBeAEMAAAABAgYADgACAF4A/QAKAA4AAwBiAFAAAAD9 AAoADgAEAGIAUAAAAP0ACgAOAAUAYgBQAAAA/QAKAA4ABgBiAFAAAAD9AAoADgAHAGIAUAAAAP0A CgAOAAgAYgBQAAAA/QAKAA4ACQBiAFAAAAD9AAoADgAKAGIAUAAAAAECBgAOAAsAbgD9AAoADgAM AGIAUAAAAP0ACgAPAAAAigCMAAAA/QAKAA8AAQBeAKgAAAABAgYADwACAF4AvQAwAA8AAwBiAAAA n0BiAAAQn0BiAAAYn0BiAAAkn0BiAAAsn0BiAAAwn0BiAAA8n0AJAP0ACgAPAAoAYgCdAAAAAQIG AA8ACwBuAH4CCgAPAAwAYgAA+J5A/QAKABAAAACKAI0AAAD9AAoAEAABAF4AqAAAAAECBgAQAAIA XgC9ACoAEAADAGIAABCfQGIAABCfQGIAACSfQGIAADyfQGIAAECfQGIAAECfQAgA/QAKABAACQBi AMYAAAD9AAoAEAAKAGIASgIAAAECBgAQAAsAbgB+AgoAEAAMAGIAACyfQP0ACgARAAAAigCiAgAA /QAKABEAAQBeANEAAAABAgYAEQACAF4A/QAKABEAAwBiANIAAAD9AAoAEQAEAGIARgEAAP0ACgAR AAUAYgDHAAAA/QAKABEABgBiAMwAAAD9AAoAEQAHAGIAzAAAAP0ACgARAAgAYgDMAAAA/QAKABEA CQBiAMwAAAD9AAoAEQAKAGIAzAAAAAECBgARAAsAbgD9AAoAEQAMAGIA0AAAAP0ACgASAAAAigDL AAAA/QAKABIAAQBeANEAAAABAgYAEgACAF4A/QAKABIAAwBiAAMBAAD9AAoAEgAEAGIARwEAAP0A CgASAAUAYgDIAAAA/QAKABIABgBiAMkAAAD9AAoAEgAHAGIAygAAAP0ACgASAAgAYgDNAAAA/QAK ABIACQBiAMoAAAD9AAoAEgAKAGIAzgAAAAECBgASAAsAbgD9AAoAEgAMAGIAzwAAAP0ACgATAAAA igDbAAAA/QAKABMAAQBeAEIAAAABAgYAEwACAF4A/QAKABMAAwBiAAkAAAD9AAoAEwAEAGIACQAA AP0ACgATAAUAYgAJAAAA/QAKABMABgBiAG8AAAD9AAoAEwAHAGIAbwAAAP0ACgATAAgAYgBvAAAA /QAKABMACQBiAG8AAAD9AAoAEwAKAGIAbwAAAAECBgATAAsAbgD9AAoAEwAMAGIACQAAAP0ACgAU AAAAigDUAAAA/QAKABQAAQBeAEIAAAABAgYAFAACAF4A/QAKABQAAwBiAAkAAAD9AAoAFAAEAGIA CQAAAP0ACgAUAAUAYgBvAAAA/QAKABQABgBiAAkAAAD9AAoAFAAHAGIAsgAAAP0ACgAUAAgAYgBv AAAA/QAKABQACQBiAG8AAAD9AAoAFAAKAGIAbwAAAAECBgAUAAsAbgD9AAoAFAAMAGIACQAAAP0A CgAVAAAAigDYAAAA/QAKABUAAQBeAEIAAAABAgYAFQACAF4A/QAKABUAAwBiAAQBAAD9AAoAFQAE AGIASAEAAP0ACgAVAAUAYgBvAAAA/QAKABUABgBiAG8AAAD9AAoAFQAHAGIAbwAAAP0ACgAVAAgA YgBvAAAA/QAKABUACQBiAG8AAAD9AAoAFQAKAGIAbwAAAAECBgAVAAsAbgD9AAoAFQAMAGIACQAA AP0ACgAWAAAAigDaAAAA/QAKABYAAQBeAEIAAAABAgYAFgACAF4A/QAKABYAAwBiAAkAAAD9AAoA FgAEAGIACQAAAP0ACgAWAAUAYgAJAAAA/QAKABYABgBiAAkAAAD9AAoAFgAHAGIAbwAAAP0ACgAW AAgAYgAJAAAA/QAKABYACQBiAG8AAAD9AAoAFgAKAGIAbwAAAAECBgAWAAsAbgD9AAoAFgAMAGIA bwAAAP0ACgAXAAAAigDZAAAA/QAKABcAAQBeAEIAAAABAgYAFwACAF4A/QAKABcAAwBiAAkAAAD9 AAoAFwAEAGIACQAAAP0ACgAXAAUAYgAJAAAA/QAKABcABgBiAAkAAAD9AAoAFwAHAGIACQAAAP0A CgAXAAgAYgAJAAAA/QAKABcACQBiAG8AAAD9AAoAFwAKAGIACQAAAAECBgAXAAsAbgD9AAoAFwAM AGIACQAAAP0ACgAYAAAAsgAwAAAA/QAKABgAAQBmAEIAAAABAgYAGAACAGYA/QAKABgAAwBiAAkA AAD9AAoAGAAEAGIAbwAAAP0ACgAYAAUAYgBvAAAA/QAKABgABgBiAG8AAAD9AAoAGAAHAGIAbwAA AP0ACgAYAAgAYgBvAAAA/QAKABgACQBiAG8AAAD9AAoAGAAKAGIAbwAAAAECBgAYAAsAbgD9AAoA GAAMAGIACQAAAP0ACgAZAAAAsgAvAAAA/QAKABkAAQBmAEIAAAABAgYAGQACAGYA/QAKABkAAwBi AAkAAAD9AAoAGQAEAGIACQAAAP0ACgAZAAUAYgBvAAAA/QAKABkABgBiAG8AAAD9AAoAGQAHAGIA bwAAAP0ACgAZAAgAYgBvAAAA/QAKABkACQBiAG8AAAD9AAoAGQAKAGIAbwAAAAECBgAZAAsAbgD9 AAoAGQAMAGIACQAAAP0ACgAaAAAAsgAxAAAA/QAKABoAAQBmADIAAAABAgYAGgACAGYAvQA2ABoA AwBiAAAA8D9iAAAA8D9iAAAAAEBiAAAACEBiAAAACEBiAAAAEEBiAAAAEEBiAAAAFEAKAAECBgAa AAsAbgB+AgoAGgAMAGIAAAAAAP0ACgAbAAAAigAFAQAA/QAKABsAAQBeAAYBAAABAgYAGwACAF4A /QAKABsAAwBkAAgBAAD9AAoAGwAEAGQACAEAAP0ACgAbAAUAYgAHAQAA/QAKABsABgBiAAcBAAD9 AAoAGwAHAGIABwEAAP0ACgAbAAgAYgAHAQAA/QAKABsACQBiAAcBAAD9AAoAGwAKAGIABwEAAAEC BgAbAAsAbgD9AAoAGwAMAGIACQAAAP0ACgAcAAAAigAVAAAA/QAKABwAAQBeAEIAAAABAgYAHAAC AF4A/QAKABwAAwBiAAkAAAD9AAoAHAAEAGIACQAAAP0ACgAcAAUAYgAJAAAA/QAKABwABgBiAAkA AAD9AAoAHAAHAGIAbwAAAP0ACgAcAAgAYgBvAAAA/QAKABwACQBiAG8AAAD9AAoAHAAKAG4AowIA AAECBgAcAAsAbgD9AAoAHAAMAGIACQAAAP0ACgAdAAAAigCVAAAA/QAKAB0AAQBmAKkAAAABAgYA HQACAGYA/QAKAB0AAwBiAHIAAAD9AAoAHQAEAGIAcgAAAP0ACgAdAAUAYgByAAAA/QAKAB0ABgBi AHIAAAD9AAoAHQAHAGIAcgAAAP0ACgAdAAgAYgByAAAA/QAKAB0ACQBiAHIAAAD9AAoAHQAKAGIA cgAAAAECBgAdAAsAbgD9AAoAHQAMAGIAugAAAP0ACgAeAAAAigBxAAAA/QAKAB4AAQBeAHUAAAAB AgYAHgACAF4A/QAKAB4AAwBiAHIAAAD9AAoAHgAEAGIAcgAAAP0ACgAeAAUAYgByAAAA/QAKAB4A BgBiAHIAAAD9AAoAHgAHAGIAcgAAAP0ACgAeAAgAYgByAAAA/QAKAB4ACQBiAHIAAAD9AAoAHgAK AGIAcgAAAAECBgAeAAsAbgD9AAoAHgAMAGIAcgAAAP0ACgAfAAAAigCYAAAA/QAKAB8AAQBeAHUA AAABAgYAHwACAF4A/QAKAB8AAwBiAHIAAAD9AAoAHwAEAGIAcgAAAP0ACgAfAAUAYgByAAAA/QAK AB8ABgBiAHIAAAD9AAoAHwAHAGIAcgAAAP0ACgAfAAgAYgByAAAA/QAKAB8ACQBiAHIAAAD9AAoA HwAKAGIAcgAAAAECBgAfAAsAbgD9AAoAHwAMAGIAcgAAANcARACHFAAAbAIOAHMAWABpAJkAJABM AAoApACkAK4ArgCuAK4ArgCAAIgArgCuAK4ArgCuAK4ArgCuAK4AeACuAK4ArgCuAAgCEAAgAAAA DwDwAAAAAADAAWEACAIQACEAAAAPAPAAAAAAAMABYQAIAhAAIgAAAA8A8AAAAAAAwAFhAAgCEAAj AAAADwDgAQAAAADAAWAACAIQACQAAAAPAP8AAAAAAIABewAIAhAAJQAAAA8A/wAAAAAAgAF7AAgC EAAmAAAADwD/AAAAAACAAXsACAIQACcAAAAPAP8AAAAAAIABewAIAhAAKAAAAA8A/wAAAAAAgAF7 AAgCEAApAAAADwD/AAAAAACAAXsACAIQACoAAAAPAP8AAAAAAIABewD9AAoAIAAAAIoAmgAAAP0A CgAgAAEAXgB1AAAAAQIGACAAAgBeAP0ACgAgAAMAYgByAAAA/QAKACAABABiAHIAAAD9AAoAIAAF AGIAcgAAAP0ACgAgAAYAYgByAAAA/QAKACAABwBiAHIAAAD9AAoAIAAIAGIAcgAAAP0ACgAgAAkA YgByAAAA/QAKACAACgBiAHIAAAABAgYAIAALAG4A/QAKACAADABiAHIAAAD9AAoAIQAAAIoACwEA AP0ACgAhAAEAXgCXAAAAAQIGACEAAgBeAL0AMAAhAAMAYgAAAABAYgAAAABAZwAAAABAYgAAAABA YgAAAABAYgAAAABAYgAAAABACQD9AAoAIQAKAGIAcAAAAAECBgAhAAsAbgB+AgoAIQAMAGIAAAAA AP0ACgAiAAAAigAMAQAA/QAKACIAAQBeAJcAAAABAgYAIgACAF4AvQAwACIAAwBiAAAAAABiAAAA AABnAAAA8D9iAAAA8D9iAAAAAEBiAAAA8D9iAAAAAEAJAP0ACgAiAAoAYgBwAAAAAQIGACIACwBu AH4CCgAiAAwAYgAAAAAA/QAKACMAAACKAEcAAAC+AAoAIwABAF8AXwACAP0ACgAjAAMAZAC7AAAA /QAKACMABABkALsAAAD9AAoAIwAFAGQAuwAAAP0ACgAjAAYAZAC8AAAA/QAKACMABwBkAL4AAAD9 AAoAIwAIAGQAvAAAAP0ACgAjAAkAZAC8AAAA/QAKACMACgBkAL0AAAABAgYAIwALAHQA/QAKACMA DABkAL8AAAD9AAoAJAAAAIoALAEAAL4ACgAkAAEAqwBxAAIAvQASACQAAwBxAAAA8D9xAAAAAEAE AL4ADgAkAAUAcQBxAHEAcQAIAL0AEgAkAAkAcQAAAAhAcQAAABBACgC+AAwAJAALAHEAcQBxAA0A AQIGACUAAQCrAP0ACgAmAAAAigBKAQAAAQIGACYAAQCrAP0ACgAnAAEAqwAzAQAA/QAKACcAAwDi AAEBAAC+ABwAJwAEAOIA4gDiAOIA4gDiAOIA4gDiAOIA4gAOAP0ACgAoAAEAqwA0AQAA/QAKACgA AwDiAEsBAAC+ABwAKAAEAOIA4gDiAOIA4gDiAOIA4gDiAOIA4gAOAP0ACgApAAEAqwDSAQAAAQIG ACkAAgCMAP0ACgApAAMA4wAPAgAAvgAcACkABADjAOMA4wDjAOMA4wDjAOMA4wDjAOMADgD9AAoA KgABAKsA0wEAAAECBgAqAAIAjAD9AAoAKgADAOMAEAIAAL4AHAAqAAQA4wDjAOMA4wDjAOMA4wDj AOMA4wDjAA4A1wAaAL4EAADIAK4AgACAAKQAagAKABgAPAA8AEYAwgEYAAIAAQADAAkAAADjAAEA BAAEAAkAAADjAD4CEgC+AQAAAABAAAAAAAAAAAAAAACgAAQAAwAEAEEACgACAAEAAQACAAAAHQAP AAMAAAAAAAABAAAAAAAAAB0ADwABAAACAAAAAQAAAAAAAgIdAA8AAgEAAAAAAAEAAQABAAAAHQAP AAAcAAoAAAABABwAHAAKCpkAAgAkCeUAIgAEACcAJwADAA4AKAAoAAMADgApACkAAwAOACoAKgAD AA4A7wAGAAcANwAAALoBCQAGAABTaGVldDJnCBcAZwgAAAAAAAAAAAAAAgAB/////wNEAACcCCYA nAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAACLCBAAiwgAAAAAAAAAAAAAAAAC AMgICQDICAAACAAAAAAKAAAACQgQAAAGEABzIM0H2cABAAYDAAALAhgAAAAAAAAAAAAlAAAAdFUB AMdmAQA9aAEADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAA KwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQUUAAAAFQAAAIMAAgAAAIQAAgAA ACYACABbNK7JZDLpPycACABbNK7JZDLpPygACACKHTz8/X7vPykACACKHTz8/X7vP6EAIgABAEYA AQABAAEAAADIAMgAAAAAAAAA4D8AAAAAAADgPwEAVQACAAgAfQAMAAAAAADbHw8AAgAAAH0ADAAB AAEA2w8PAAIAAAB9AAwAAgACAAACDwACAAAAfQAMAAMAAwAACw8AAgAAAH0ADAAEAAQAbQ8PAAIA AAB9AAwABQAFACQJDwACAAAAfQAMAAYABgAkDA8AAgAAAH0ADAAHAAcA2wsPAAIAAAB9AAwACAAK ACQJDwACAAAAfQAMAAsACwC2Dw8AAgAAAH0ADAAMAAwAbQsPAAIAAAB9AAwADQANALYMDwACAAAA fQAMAA4ADwAkCQ8AAgAAAH0ADAAQABAAJAlYAAIAAAAAAg4AAAAAACUAAAAAABEAAAAIAhAAAAAA ABAA/wAAAAAAAAEPAAgCEAABAAAAEAAsAQAAAAAAAQ8ACAIQAAIAAAAQAP8AAAAAAAABDwAIAhAA AwAAABAA/wAAAAAAAAEPAAgCEAAEAAAAEAD/AAAAAAAAAQ8ACAIQAAUAAAAQAP8AAAAAAAABDwAI AhAABgAAABAA/wAAAAAAAAEPAAgCEAAHAAAAEAD/AAAAAAAAAQ8ACAIQAAgAAAAQAPAAAAAAAEAB DwAIAhAACQAAABAA8AAAAAAAwAFbAAgCEAAKAAAAEADuAgAAAADAAa4ACAIQAAsAAAAQAPAAAAAA AEABDwAIAhAADAAAABAAGwMAAAAAQAEPAAgCEAANAAAAEADwAAAAAABAAQ8ACAIQAA4AAAAQAPAA AAAAAEABDwAIAhAADwAAABAA8AAAAAAAQAEPAAgCEAAQAAAAEQDwAAAAAADAAVgACAIQABEAAAAR APAAAAAAAMABWAAIAhAAEgAAABEA8AAAAAAAwAFYAAgCEAATAAAAEQDwAAAAAADAAVgACAIQABQA AAARAPAAAAAAAMABWAAIAhAAFQAAABEA8AAAAAAAwAFYAAgCEAAWAAAAEQDwAAAAAADAAVgACAIQ ABcAAAARAPAAAAAAAMABWAAIAhAAGAAAABEA8AAAAAAAwAFYAAgCEAAZAAAAEQANAgAAAADAAVgA CAIQABoAAAARAPAAAAAAAMABWAAIAhAAGwAAABEA/wAAAAAAgAFYAAgCEAAcAAAAEQD/AAAAAACA AVgACAIQAB0AAAARAP8AAAAAAAABDwAIAhAAHgAAABEA/wAAAAAAAAEPAAgCEAAfAAAAEQD/AAAA AAAAAQ8A/QAKAAAAAABAADkAAAAGAB0AAQAAAFUAAAAoEEwL//8gAAIAAP4HAFoAAAEAAMAHAjIA LwAATWVkaWEgQ29kaW5nIFN1bW1hcnkgRGF0YWJhc2UgLSBJVFUtVCBTRzE2IFEuMjO+ACQAAQAB AFYAVgBWAFYAWABWAFYAVgBWAFcAVwCJAFgAWABYAA8ABgAdAAIAAABVAAAAiBBMC///IAADAAD/ BwBaAAACAADABwIZABYAAEdlbmV2YSwgMyBPY3RvYmVyIDIwMDi+ACQAAgABAFYAVgBWAFYAWABW AFYAVgBWAFcAVwBYAFgAWABYAA8ABgAdAAMAAABVAAAAuBBMC///IAAEAAD/BwBaAAADAADABwIq ACcAAFNvdXJjZTogUmFwcG9ydGV1ciwgUS4yMy8xNiAoSC4gVGFkZGVpKb4AJAADAAEAVgBWAFYA VgBYAFYAVgBWAFYAWwBbAFgAWABYAFgADwAGAB0ABAAAAFUAAAAIEUwL//8gABQCpv0HAFoAAAQA AMAHAloAVwAAQ29udGFjdDogSGVydukgVGFkZGVpLCBIdWF3ZWkgVGVjaG5vbG9naWVzLCArNDkg MTYyIDI5NDAgMjYwLCA8aGVydmUudGFkZGVpQGh1YXdlaS5jb20+vgAkAAQAAQBWAFYAVgBWAFgA VgBWAFYAVgBXAFcAWABYAFgAWAAPAL4AJgAFAAAAWABYAFYAWABYAFgAWABYAFgAWABYAFgAWABY AFgAWAAPAL4AJgAGAAAAWABYAFYAWABYAFgAWABYAFgAWABYAFgAWABYAFgAWAAPAP0ACgAHAAAA VQA5AAAAvgAkAAcAAQBWAFgAVgBWAFgAVgBWAFYAVgBXAFcAWABYAFgAWAAPAL4AJgAIAAAAVQBW AIMAVgBWAFgAVgBWAFYAVgBXAFcAWABYAFgAWAAPAP0ACgAJAAAArQBAAAAAvgAKAAkAAQCuAIMA AgD9AAoACQADAFsA8QAAAP0ACgAJAAQAWwA8AAAA/QAKAAkABQCuAFcCAAD9AAoACQAGAFsA8gAA AP0ACgAJAAcAWwDzAAAA/QAKAAkACABbAD0AAAD9AAoACQAJAFsAPgAAAP0ACgAJAAoAWwA/AAAA /QAKAAkACwBbAJgBAAD9AAoACQAMAFsAWwIAAP0ACgAJAA0AWwCxAQAA/QAKAAkADgBbAOMBAAD9 AAoACgAAAK0AQQAAAAECBgAKAAIAgwD9AAoACgADAK4AsAEAAP0ACgAKAAQArgCzAQAA/QAKAAoA BQBbAFcCAAD9AAoACgAGAK4ArQEAAP0ACgAKAAcArgC0AQAA/QAKAAoACACuALUBAAD9AAoACgAJ AK4AvQEAAP0ACgAKAAoArgC2AQAA/QAKAAoACwCuAJkBAAD9AAoACgAMAK4AnQEAAP0ACgAKAA0A rgCyAQAA/QAKAAoADgCuAOYBAAD9AAoACgAPAK4ARgIAAP0ACgALAAAArQD2AAAA/QAKAAsAAQCD AEIAAAABAgYACwACAIMA/QAKAAsAAwBZAAkAAAD9AAoACwAEAFkAbwAAAP0ACgALAAUAWQBvAAAA /QAKAAsABgBZAG8AAAD9AAoACwAHAFkAbwAAAP0ACgALAAgAWQCuAQAA/QAKAAsACQBZAG8AAAD9 AAoACwAKAFkAbwAAAP0ACgALAAsAWQAJAAAA/QAKAAsADABZAAkAAAD9AAoACwANAFkACQAAAP0A CgALAA4AWQAJAAAAAQIGAAsADwBZAP0ACgAMAAAArQD0AAAA/QAKAAwAAQCDAPUAAAABAgYADAAC AIMAfgIKAAwAAwBZAAAA8D/9AAoADAAEAK8AuwEAAP0ACgAMAAUAWQBvAAAA/QAKAAwABgBZALgB AAD9AAoADAAHAFkAuQEAAP0ACgAMAAgAWQCvAQAA/QAKAAwACQBZALwBAAD9AAoADAAKAFkAtwEA AL0AHgAMAAsAWQAAAPA/WQAAAPA/WQAAAPA/WQAAAPA/DgABAgYADAAPAFkA/QAKAA0AAACtAJwB AAD9AAoADQABAIMAQgAAAL4ACgANAAIAgwBZAAMA/QAKAA0ABABZAG8AAAABAgYADQAFAFkA/QAK AA0ABgBZAG8AAAABAgYADQAHAFkA/QAKAA0ACABZAAkAAAD9AAoADQAJAFkACQAAAP0ACgANAAoA WQAJAAAA/QAKAA0ACwBZAG8AAAD9AAoADQAMAFkACQAAAP0ACgANAA0AWQAJAAAA/QAKAA0ADgBZ AAkAAAABAgYADQAPAFkA/QAKAA4AAACtAJsBAAD9AAoADgABAIMAQgAAAL4ACgAOAAIAgwBZAAMA /QAKAA4ABABZALoBAAABAgYADgAFAFkA/QAKAA4ABgBZAG8AAAABAgYADgAHAFkA/QAKAA4ACABZ AG8AAAD9AAoADgAJAFkAbwAAAP0ACgAOAAoAWQBvAAAA/QAKAA4ACwBZAG8AAAD9AAoADgAMAFkA bwAAAP0ACgAOAA0AWQBvAAAA/QAKAA4ADgBZAG8AAAABAgYADgAPAFkA/QAKAA8AAACtAKYAAAD9 AAoADwABAIMAGgAAAAECBgAPAAIAgwD9AAoADwADAFkAngEAAAECBgAPAAQAWQD9AAoADwAFAFkA UAAAAL4ACgAPAAYAWQBZAAcA/QAKAA8ACABZAKABAAD9AAoADwAJAFkAoAEAAAECBgAPAAoAWQD9 AAoADwALAFkApAEAAP0ACgAPAAwAWQDjAQAA/QAKAA8ADQBZAOQBAAD9AAoADwAOAFkA4wEAAAEC BgAPAA8AWQD9AAoAEAAAAK0AigAAAP0ACgAQAAEAgwBDAAAAvgAKABAAAgCDAFkAAwD9AAoAEAAE AFkAUAAAAAECBgAQAAUAWQD9AAoAEAAGAFkAUAAAAP0ACgAQAAcAWQBQAAAAvgAMABAACABZAFkA WQAKAP0ACgAQAAsAWQBQAAAA/QAKABAADABZAFAAAAD9AAoAEAANAFkAUAAAAP0ACgAQAA4AWQBQ AAAAAQIGABAADwBZAP0ACgARAAAArQCMAAAA/QAKABEAAQCDAKgAAAC+AAwAEQACAIMAWQBZAAQA /QAKABEABQBZAFkCAAC+ABoAEQAGAFkAWQBZAFkAWQBZAFkAWQBZAFkADwD9AAoAEgAAAK0AjQAA AP0ACgASAAEAgwCoAAAAvgAMABIAAgCDAFkAWQAEAP0ACgASAAUAWQBKAgAAvgAQABIABgBZAFkA WQBZAFkACgD9AAoAEgALAFkAmgEAAP0ACgASAAwAWQDlAQAAfgIKABIADQBZAAAgn0D9AAoAEgAO AFkA5QEAAAECBgASAA8AWQD9AAoAEwAAAK0AFQAAAP0ACgATAAEAgwBCAAAAvgAaABMAAgCDAFkA WQBZAFkAWQBZAFkAWQBZAAsA/QAKABMADABZAAkAAAD9AAoAEwANAFkAbwAAAP0ACgATAA4AWQAJ AAAAAQIGABMADwBZAP0ACgAUAAAArQCVAAAA/QAKABQAAQBVAKkAAAC+ACIAFAACAIMAWQBZAFkA WQBZAFkAWQBZAFkAWQBZAFkAWQAPAP0ACgAVAAAArQCUAAAA/QAKABUAAQBVAKkAAAC+ACIAFQAC AIMAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQAPAP0ACgAWAAAArQBxAAAA/QAKABYAAQCDAHUA AAC+ACIAFgACAIMAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQAPAP0ACgAXAAAArQCYAAAA/QAK ABcAAQCDAHUAAAC+ACIAFwACAIMAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQAPAP0ACgAYAAAA rQCaAAAA/QAKABgAAQCDAHUAAAC+AAwAGAACAFUAWQBZAAQAfgIKABgABQBZAAAAAAC+ABoAGAAG AFkAWQBZAFkAWQBZAFkAWQBZAFkADwD9AAoAGQAAAK0AlgAAAP0ACgAZAAEAgwCXAAAAAQIGABkA AgBVAH4CCgAZAAMAWQAAAAAA/QAKABkABABZAL4BAAD9AAoAGQAFAFkAWgIAAP0ACgAZAAYAsAC/ AQAA/QAKABkABwCwAL8BAAC9ADAAGQAIAFkAAAAAQFkAAAAAAFkAAAAAAFkAAAAAQFkAAAAAAFkA AAAAQFkAAAAAAA4AAQIGABkADwBZAP0ACgAaAAAArQBHAAAA/QAKABoAAQCDABoAAAC+AAoAGgAC AFUAWQADAP0ACgAaAAQAsQD5AQAA/QAKABoABgCxAPkBAAD9AAoAGgAHALEA+QEAAL4ADAAaAAgA WQBZAFkACgD9AAoAGgALALEA+QEAAP0ACgAaAAwAsQD5AQAA/QAKABoADQCxAPkBAAC+AAoAGgAO AFkAWQAPAL4ADAAbAAIAgwBZAFkABAC+ABwAGwAGAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQAQAL4A DAAcAAIAgwBZAFkABAC+ABwAHAAGAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQAQAL4ADAAdAAIARABJ AEkABAC+ABwAHQAGAEkASQBJAEkASQBJAEkASQBJAEkAWQAQAL4ADAAeAAIATABJAEkABAC+ABwA HgAGAEkASQBJAEkASQBJAEkASQBJAEkAWQAQAL4ADAAfAAIATABJAEkABAC+ABwAHwAGAEkASQBJ AEkASQBJAEkASQBJAEkAWQAQANcARABbEAAAbAIOAH8AZgB3AKcAKgAqADYAKgDEAM4A2ADCAMYA xgDCALAAWACQAG4AQgBCAEIAQgBYAKoAnAAwADAAMAAwAAgCEAAgAAIAEQD/AAAAAAAAAQ8ACAIQ ACEAAgARAP8AAAAAAAABDwAIAhAAIgACABEA/wAAAAAAAAEPAAgCEAAjAAIAEQD/AAAAAAAAAQ8A CAIQACQAAgARAP8AAAAAAAABDwC+AAwAIAACAEwASQBJAAQAvgAcACAABgBJAEkASQBJAEkASQBJ AEkASQBJAFkAEAC+AAwAIQACAEwASQBJAAQAvgAcACEABgBJAEkASQBJAEkASQBJAEkASQBJAFkA EAC+AAwAIgACAEwASQBJAAQAvgAcACIABgBJAEkASQBJAEkASQBJAEkASQBJAFkAEAC+AAwAIwAC AEoASQBJAAQAvgAcACMABgBJAEkASQBJAEkASQBJAEkASQBJAFkAEAABAgYAJAACAEgA1wAOAC4B AABQADAAMAAwADAAwgEYAAIAAQAEAAkAAAAkAAEABAAFAAkAAABJAD4CEgC+AQAAAABAAAAAAAAA AAAAAACgAAQAAwAEAEEACgACAAEAAQACAAAAHQAPAAMAAAAAAAABAAAAAAAAAB0ADwABAAACAAAA AQAAAAAAAgIdAA8AAgEAAAAAAAEAAQABAAAAHQAPAAAAAAAAAAABAAAAAAAAAJkAAgAkCe8ABgAH ADcAAAC6AQkABgAAU2hlZXQzZwgXAGcIAAAAAAAAAAAAAAIAAf////8DRAAAnAgmAJwIAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAiwgQAIsIAAAAAAAAAAAAAAAAAgDICAkAyAgA AAgAAAAACgAAAAkIEAAABhAAcyDNB9nAAQAGAwAACwIYAAAAAAAAAAAAJQAAAFpqAQDdcQEAuXIB AA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIA AgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEFFAAAABUAAACDAAIAAACEAAIAAAAmAAgAWzSu yWQy6T8nAAgAWzSuyWQy6T8oAAgAih08/P1+7z8pAAgAih08/P1+7z+hACIAAQBkAAEAAQABAAAA yADIAAAAAAAAAOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAAAbR0PAAIAAAB9AAwAAQABALYPDwAC AAAAfQAMAAIAAgAAAg8AAgAAAH0ADAADAAMAbQsPAAIAAAAAAg4AAAAAACUAAAAAABMAAAAIAhAA AAAAABMA/wAAAAAAAAEPAAgCEAABAAAAEwAsAQAAAACAAVgACAIQAAIAAAATAP8AAAAAAIABWAAI AhAAAwAAABMA/wAAAAAAgAFYAAgCEAAEAAAAEwD/AAAAAACAAVgACAIQAAUAAAATAP8AAAAAAAAB DwAIAhAABgAAABMA/wAAAAAAAAEPAAgCEAAIAAAAEwDwAAAAAADAAUAACAIQAAkAAAATAPAAAAAA AMABQAAIAhAACgAAABMA8AAAAAAAQAEPAAgCEAALAAAAEwDwAAAAAABAAQ8ACAIQAAwAAAATAPAA AAAAAEABDwAIAhAADQAAABMA8AAAAAAAQAEPAAgCEAAOAAAAEwDwAAAAAABAAQ8ACAIQAA8AAAAT APAAAAAAAEABDwAIAhAAEAAAAAMA8AAAAAAAQAEPAAgCEAARAAAAAwDwAAAAAABAAQ8ACAIQABIA AAADAPAAAAAAAEABDwAIAhAAEwAAAAMA8AAAAAAAQAEPAAgCEAAUAAAAAwDwAAAAAABAAQ8ACAIQ ABUAAAADAPAAAAAAAEABDwAIAhAAFgAAAAMA/wAAAAAAAAEPAAgCEAAXAAAAAwD/AAAAAAAAAQ8A CAIQABgAAAADAP8AAAAAAAABDwAIAhAAGQAAAAMA/wAAAAAAAAEPAAgCEAAaAAAAAwD/AAAAAAAA AQ8ACAIQABsAAAADAP8AAAAAAAABDwAIAhAAHAAAAAMA/wAAAAAAAAEPAAgCEAAdAAAAAwD/AAAA AAAAAQ8ACAIQAB4AAAADAP8AAAAAAAABDwAIAhAAHwAAAAMA/wAAAAAAAAEPAP0ACgAAAAAARAA7 AAAABgAdAAEAAABVAAAAuBFMC///IAACAAD+BwBaAAABAADABwIyAC8AAE1lZGlhIENvZGluZyBT dW1tYXJ5IERhdGFiYXNlIC0gSVRVLVQgU0cxNiBRLjIzvgAcAAEAAQBWAFYAVgBWAFYAVgBWAFYA VwBXAIkACwAGAB0AAgAAAFUAAAAYEkwL//8gAAMAAP8HAFoAAAIAAMAHAhkAFgAAR2VuZXZhLCAz IE9jdG9iZXIgMjAwOL4AGgACAAEAVgBWAFYAVgBWAFYAVgBWAFcAVwAKAAYAHQADAAAAVQAAAEgS TAv//yAABAAA/wcAWgAAAwAAwAcCKgAnAABTb3VyY2U6IFJhcHBvcnRldXIsIFEuMjMvMTYgKEgu IFRhZGRlaSm+ABoAAwABAFYAVgBWAFYAVgBWAFYAVgBbAFsACgAGAB0ABAAAAFUAAACYEkwL//8g ALQCpv0HAFoAAAQAAMAHAloAVwAAQ29udGFjdDogSGVydukgVGFkZGVpLCBIdWF3ZWkgVGVjaG5v bG9naWVzLCArNDkgMTYyIDI5NDAgMjYwLCA8aGVydmUudGFkZGVpQGh1YXdlaS5jb20+vgAaAAQA AQBWAFYAVgBWAFYAVgBWAFYAVwBXAAoAvgAcAAUAAABEAEEAQQBBAEEAQQBBAEEAQQBIAEgACgC+ AAoABQARAEMAQwASAAECBgAGAAIAQQD9AAoACAAAAEsAQAAAAL4ACgAIAAEASgBMAAIA/QAKAAgA AwBDAIYAAAC+AAoACAAJAEMAQwAKAP0ACgAJAAAASwBBAAAAvgAKAAkAAQBKAEwAAgD9AAoACQAD AEMA9wAAAL4ACgAJAAkAQwBDAAoA/QAKAAoAAABLAKYAAAD9AAoACgABAEwAGgAAAAECBgAKAAIA TAD9AAoACwAAAEsAigAAAP0ACgALAAEATABDAAAAAQIGAAsAAgBMAP0ACgAMAAAASwCMAAAA/QAK AAwAAQBMAKgAAAABAgYADAACAEwA/QAKAA0AAABLAI0AAAD9AAoADQABAEwAqAAAAAECBgANAAIA TAD9AAoADgAAAEsAFQAAAP0ACgAOAAEATABCAAAAAQIGAA4AAgBMAP0ACgAPAAAASwCVAAAA/QAK AA8AAQBEAKkAAAABAgYADwACAEwA/QAKABAAAABLAJQAAAD9AAoAEAABAEQAqQAAAAECBgAQAAIA TAD9AAoAEQAAAEsAcQAAAP0ACgARAAEATAB1AAAAAQIGABEAAgBMAP0ACgASAAAASwCYAAAA/QAK ABIAAQBMAHUAAAABAgYAEgACAEwA/QAKABMAAABLAJoAAAD9AAoAEwABAEwAdQAAAAECBgATAAIA TAD9AAoAFAAAAEsAlgAAAP0ACgAUAAEATACXAAAAAQIGABQAAgBMAP0ACgAVAAAASwBHAAAA/QAK ABUAAQBMABoAAAABAgYAFQACAEwAAQIGABYAAgBMAAECBgAXAAIATAABAgYAGAACAEQAAQIGABkA AgBEAAECBgAaAAIARAABAgYAGwACAEwAAQIGABwAAgBMAAECBgAdAAIARAABAgYAHgACAEwAAQIG AB8AAgBMANcAQgArBwAAWAIOAHcAXABtAJ0ALgAKADgAOAAmACYAJgAmACYAJgAmACYAJgAmACYA JgAKAAoACgAKAAoACgAKAAoACgAIAhAAIAACAAMA/wAAAAAAAAEPAAgCEAAhAAIAAwD/AAAAAAAA AQ8ACAIQACIAAgADAP8AAAAAAAABDwAIAhAAIwACAAMA/wAAAAAAAAEPAAgCEAAkAAIAAwD/AAAA AAAAAQ8AAQIGACAAAgBMAAECBgAhAAIATAABAgYAIgACAEwAAQIGACMAAgBKAAECBgAkAAIASADX AA4AlgAAAFAACgAKAAoACgDCARgAAgABAAUACQAAABoAAQAEAAYACQAAAEEAPgISAL4BAAAAAEAA AAAAAAAAAAAAAKAABAADAAQAQQAKAAIAAQABAAIAAAAdAA8AAwAAAAAAAAEAAAAAAAAAHQAPAAEA AAIAAAABAAAAAAACAh0ADwACAQAAAAAAAQABAAEAAAAdAA8AAAAAAAAAAAEAAAAAAAAAmQACACQJ 7wAGAAcANwAAAGcIFwBnCAAAAAAAAAAAAAACAAH/////A0QAAJwIJgCcCAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAAAAAAAAAAIsIEACLCAAAAAAAAAAAAAAAAAIAyAgJAMgIAAAIAAAAAAoA AAAJCBAAAAYQAHMgzQfZwAEABgMAAAsCGAAAAAAAAAAAACYAAADJdAEAaoABAGaBAQANAAIAAQAM AAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgA AAAAAAAAAAAlAgQAAAD/AIEAAgDBBRQAAAAVAAAAgwACAAAAhAACAAAAJgAIAFs0rslkMuk/JwAI AFs0rslkMuk/KAAIAIodPPz9fu8/KQAIAIodPPz9fu8/oQAiAAEAWQABAAEAAQAAAMgAyAAAAAAA AADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAAG0dDwACAAAAfQAMAAEAAQBtDg8AAgAAAH0ADAAC AAIAAAIPAAIAAAB9AAwAAwADAEkKDwAGAAAAfQAMAAQABAAADA8ABgAAAH0ADAAFAAUAtgkPAAYA AAB9AAwABgAGALYXDwACAAAAfQAMAAcABwAkDA8ABgAAAH0ADAAIAAgASQwPAAYAAAB9AAwACQAJ AAAMDwAGAAAAfQAMAAoACwDbBQ8ABgAAAH0ADAAMAAwASQYPAAYAAAAAAg4AAAAAACYAAAAAABUA AAAIAhAAAAAAABUA/wAAAAAAgAFYAAgCEAABAAAAFQAsAQAAAACAAVgACAIQAAIAAAAVAP8AAAAA AIABWAAIAhAAAwAAABUA/wAAAAAAgAFYAAgCEAAEAAAAFQD/AAAAAACAAVgACAIQAAUAAAAVAP8A AAAAAIABWAAIAhAABgAAABUA/wAAAAAAgAFYAAgCEAAHAAAAFQD/AAAAAACAAVgACAIQAAgAAAAV AP8AAAAAAIABWAAIAhAACQAAABUA/wAAAAAAgAFbAAgCEAAKAAAAFQD/AAAAAACAAVsACAIQAAsA AAAVAP8AAAAAAIABWAAIAhAADAAAABUA/wAAAAAAgAFYAAgCEAANAAAAFQD/AAAAAACAAVgACAIQ AA4AAAAVAP8AAAAAAIABWAAIAhAADwAAABUA/wAAAAAAgAFYAAgCEAAQAAAAFQD/AAAAAACAAVgA CAIQABEAAAAVAP8AAAAAAIABWAAIAhAAEgAAABUA/wAAAAAAgAFYAAgCEAATAAAAFQD/AAAAAACA AVgACAIQABQAAAAVAP8AAAAAAIABWAAIAhAAFQAAABUA/wAAAAAAAAEPAAgCEAAWAAAAFQD/AAAA AAAAAQ8ACAIQABcAAAAVAP8AAAAAAAABDwAIAhAAGAAAABUA/wAAAAAAAAEPAAgCEAAZAAAAFQD/ AAAAAAAAAQ8ACAIQABoAAAAVAP8AAAAAAAABDwAIAhAAGwAAABUA/wAAAAAAAAEPAAgCEAAcAAAA FQD/AAAAAAAAAQ8ACAIQAB0AAAAVAP8AAAAAAAABDwAIAhAAHgAAABUA/wAAAAAAAAEPAAgCEAAf AAAAFQD/AAAAAAAAAQ8A/QAKAAAAAABVADoAAAAGAB0AAQAAAFUAAABIE0wL//8gAAIAAP4HAFoA AAEAAMAHAjIALwAATWVkaWEgQ29kaW5nIFN1bW1hcnkgRGF0YWJhc2UgLSBJVFUtVCBTRzE2IFEu MjMBAgYAAQABAFYAvgAYAAEAAwBWAFYAVgBWAFYAVgBXAFcAiQALAAYAHQACAAAAVQAAAKgTTAv/ /yAAAwAA/wcAWgAAAgAAwAcCGQAWAABHZW5ldmEsIDMgT2N0b2JlciAyMDA4vgAaAAIAAQBWAFYA VgBWAFYAVgBWAFYAVwBXAAoABgAdAAMAAABVAAAA2BNMC///IAAEAAD/BwBaAAADAADABwIqACcA AFNvdXJjZTogUmFwcG9ydGV1ciwgUS4yMy8xNiAoSC4gVGFkZGVpKb4AGgADAAEAVgBWAFYAVgBW AFYAVgBWAFsAWwAKAAYAHQAEAAAAVQAAACgUTAv//yAAVAOm/QcAWgAABAAAwAcCWgBXAABDb250 YWN0OiBIZXJ26SBUYWRkZWksIEh1YXdlaSBUZWNobm9sb2dpZXMsICs0OSAxNjIgMjk0MCAyNjAs IDxoZXJ2ZS50YWRkZWlAaHVhd2VpLmNvbT6+ABoABAABAFYAVgBWAFYAVgBWAFYAVgBXAFcACgC+ ABwABQAAAFUAVgBWAFYAVgBWAFYAVgBWAFcAVwAKAL4ACgAFABEAWwBbABIAvgAcAAYAAABVAFYA VgBWAFYAVgBWAFYAVgBXAFcACgC+ABwABwAAAFUAVgBWAFYAVgBWAFYAVgBWAFcAVwAKAL4ACgAI AAAAVQBWAAEAvgAWAAgAAwBWAFYAVgBWAFYAVgBXAFcACgD9AAoACQAAAK0AQAAAAL4ACgAJAAEA rgCDAAIA/QAKAAkAAwBbAPgAAAD9AAoACQAEAFsA+gAAAP0ACgAJAAUAWwD7AAAA/QAKAAkABgBb APwAAAD9AAoACQAHAFsA5wEAAP0ACgAJAAgAWwDoAQAA/QAKAAkACQBbAOkBAAD9AAoACgAAAK0A QQAAAL4ACgAKAAEArgCDAAIA/QAKAAoAAwBbAPkAAAD9AAoACgAEAFsA6gEAAP0ACgAKAAUAWwCl AQAA/QAKAAoABgBbAFgCAAD9AAoACgAHAFsA6wEAAP0ACgAKAAgAWwDsAQAA/QAKAAoACQBbAO0B AAD9AAoACgAKAFsA7gEAAP0ACgAKAAsAWwDvAQAA/QAKAAoADABbAPABAAD9AAoACwAAAK0A/QAA AP0ACgALAAEAgwD+AAAAvgAsAAsAAgCDAFcAVwBXAFcAVwBXAFcAVwBZAFkAWQBZAFkAWQBZAFkA WQBZABQA/QAKAAwAAACtAAABAAD9AAoADAABAIMA/wAAAAECBgAMAAIAgwD9AAoADAADAFcAYgAA AP0ACgAMAAQAVwDxAQAA/QAKAAwABQBXAGIAAAD9AAoADAAGAFcAYwAAAP0ACgAMAAcAVwDyAQAA /QAKAAwACABXAPMBAAD9AAoADAAJAFcA8QEAAL4AHAAMAAoAVwBZAFkAWQBZAFkAWQBZAFkAWQBZ ABQA/QAKAA0AAACtAKYAAAD9AAoADQABAIMAGgAAAL4ALAANAAIAgwBXAFcAVwBXAFcAVwBXAFcA WQBZAFkAWQBZAFkAWQBZAFkAWQAUAP0ACgAOAAAArQCKAAAA/QAKAA4AAQCDAEMAAAABAgYADgAC AIMA/QAKAA4AAwBZAFAAAAD9AAoADgAEAFkAUAAAAP0ACgAOAAUAWQBQAAAA/QAKAA4ABgBZAFAA AAD9AAoADgAHAFkAUAAAAP0ACgAOAAgAWQBQAAAA/QAKAA4ACQBZAFAAAAC+ABwADgAKAFkAWQBZ AFkAWQBZAFkAWQBZAFkAWQAUAP0ACgAPAAAArQCMAAAA/QAKAA8AAQCDAKgAAAC+ACwADwACAIMA WQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAFAD9AAoAEAAAAK0AjQAAAP0ACgAQ AAEAgwCoAAAAvgAsABAAAgCDAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQBZAFkAWQBZABQA /QAKABEAAACtAJYAAAD9AAoAEQABAIMAlwAAAAECBgARAAIAgwC9ADAAEQADAFkAAAAAAFkAAAAA AFkAAAAAAFkAAAAAAFkAAAAAAFkAAAAAAFkAAAAAAAkAvgAcABEACgBZAFcAWQBZAFkAWQBZAFkA WQBZAFkAFAD9AAoAEgAAAK0ARwAAAP0ACgASAAEAgwAaAAAAvgAOABIAAgCDAFkAWQBZAAUA/QAK ABIABgBZAFoCAAC+ACIAEgAHAFkAWQBZAFkAVwBZAFkAWQBZAFkAWQBZAFkAWQAUAL4ALAATAAIA gwBZAFkAWQBZAFkAWQBZAFkAVwBZAFkAWQBZAFkAWQBZAFkAWQAUAL4ALAAUAAIAgwBZAFkAWQBZ AFkAWQBZAFkAVwBZAFkAWQBZAFkAWQBZAFkAWQAUAL4ALAAVAAIATABJAEkASQBJAEkASQBJAEkA SQBJAEkASQBJAEkASQBJAEkASQAUAL4ALAAWAAIATABJAEkASQBJAEkASQBJAEkASQBJAEkASQBJ AEkASQBJAEkASQAUAL4ALAAXAAIATABJAEkASQBJAEkASQBJAEkASQBJAEkASQBJAEkASQBJAEkA SQAUAAECBgAYAAIATAABAgYAGQACAEQAAQIGABoAAgBEAAECBgAbAAIARAABAgYAHAACAEwAAQIG AB0AAgBMAAECBgAeAAIARAABAgYAHwACAEwA1wBEAMkKAABsAg4AfQBcAG0AnQAuACAAIAAoAH4A qABMAKgATACoAEwATAB6AGIAMAAwADAAMAAwAAoACgAKAAoACgAKAAoACAIQACAAAgADAP8AAAAA AAABDwAIAhAAIQACAAMA/wAAAAAAAAEPAAgCEAAiAAIAAwD/AAAAAAAAAQ8ACAIQACMAAgADAP8A AAAAAAABDwAIAhAAJAACAAMA/wAAAAAAAAEPAAgCEAAlAAIAAwD/AAAAAAAAAQ8AAQIGACAAAgBM AAECBgAhAAIATAABAgYAIgACAEwAAQIGACMAAgBMAAECBgAkAAIASgABAgYAJQACAEgA1wAQALQA AABkAAoACgAKAAoACgDCAQwAAgABAAYACQAAAB8APgISAL4BAAAAAEAAAAAAAAAAAAAAAKAABAAD AAQAQQAKAAIAAgACAAIAAAAdAA8AAwAAAAAAAAEAAAAAAAAAHQAPAAEAAAIAAAABAAAAAAACAh0A DwACAQAAAAAAAQABAAEAAAAdAA8AAAAAAAAAAAEAAAAAAAAAmQACACQJ7wAGAAcANwAAAGcIFwBn CAAAAAAAAAAAAAACAAH/////A0QAAJwIJgCcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA AAAAAAAAAIsIEACLCAAAAAAAAAAAAAAAAAoAyAgJAMgIAAAIAAAAAAoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAsAAAAAgAAAABAAAASAAAAAQAAABQAAAACAAAAGAAAAAS AAAAbAAAAAsAAACEAAAADAAAAJAAAAANAAAAnAAAABMAAACoAAAAAgAAAOQEAAAeAAAACAAAAEhl cnZlAAAAHgAAAAQAAABJVFUAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAIA1Kba1W8YBQAAA AACU+BkoursBQAAAAABosndhBMoBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3V nC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a44AQAA9AAAAAgAAAABAAAASAAAABcAAABQ AAAACwAAAFgAAAAQAAAAYAAAABMAAABoAAAAFgAAAHAAAAANAAAAeAAAAAwAAADQAAAAAgAAAOQE AAADAAAADycLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAYAAAAOAAAAS2V5 IGFuZCBOb3RlcwAGAAAAQVVESU8ABgAAAFZJREVPAAwAAABTVElMTCBJTUFHRQAIAAAAR1JBUEhJ QwAKAAAAQ0hBUkFDVEVSAAwQAAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAAGAAAAALwAAAAD AAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQE AABBAAAAdAAAAAYAAAADAAAACQBLAAMAAAAAAAEAAwAAAAAAAAADAAAABgAAAB8AAAAeAAAAaAB0 AHQAcAA6AC8ALwBzAHAAZQBlAHgALgBzAG8AdQByAGMAZQBmAG8AcgBnAGUALgBuAGUAdAAvAAAA HwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZ AAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcA AAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAA ADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAA RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABS AAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAA AABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAA AG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAA fQAAAH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACL AAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkA AACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAA AKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAA tgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAA/v///8MAAADE AAAAxQAAAMYAAADHAAAAyAAAAMkAAAD+////ywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAAP7/ ///9/////f////7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAA AAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8ggEAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAA AAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwgAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADKAAAAABAAAAAAAAA= --Apple-Mail-8-846830944 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit

--Apple-Mail-8-846830944-- --Apple-Mail-7-846830943-- From kpfleming@digium.com Tue Jul 14 10:46:37 2009 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 A36D628C363 for ; Tue, 14 Jul 2009 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 W0yXuwcNiXzg for ; Tue, 14 Jul 2009 10:46:36 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id CD0B228C35B for ; Tue, 14 Jul 2009 10:46:36 -0700 (PDT) Received: from kildare.digium.internal ([10.24.20.235]) by mail.digium.com with esmtp (Exim 4.63) (envelope-from ) id 1MQlRi-00049G-K7 for codec@ietf.org; Tue, 14 Jul 2009 12:05:38 -0500 Message-ID: <4A5CBB28.9020907@digium.com> Date: Tue, 14 Jul 2009 12:06:48 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 CC: codec@ietf.org References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> In-Reply-To: <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:46:37 -0000 Cullen Jennings wrote: > I just received > this Liaison from the ITU. I wanted to forward it on so people could see it ASAP. If > there are problems with attachments, let me know and I will get them > posted to a site where people can get them. So that MCSD listing is quite interesting indeed; it's comprehensive, and it appears to support some of the points that were used to initiate this discussion in the first place; of that entire list of audio coding standards known by the ITU-T (regardless of SDO), there are only four that are in common use that are not under RAND licensing terms: G.711, G.722.1 Annex C, iLBC and Speex. Of those four, only two have RF licensing terms that are actually compatible with the majority of FLOSS licenses in common use, G.711 and Speex. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From brian@freeswitch.org Tue Jul 14 11:20:09 2009 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 C41BF3A6F00 for ; Tue, 14 Jul 2009 11:20:08 -0700 (PDT) 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 3RiFBHhu3Nlv for ; Tue, 14 Jul 2009 11:20:07 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id B5CDC3A69EB for ; Tue, 14 Jul 2009 11:20:06 -0700 (PDT) Received: by ewy26 with SMTP id 26so3487269ewy.37 for ; Tue, 14 Jul 2009 11:20:05 -0700 (PDT) Received: by 10.216.16.208 with SMTP id h58mr1826874weh.60.1247594262691; Tue, 14 Jul 2009 10:57:42 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id f13sm18354314gvd.23.2009.07.14.10.57.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 10:57:41 -0700 (PDT) Message-Id: <375F7124-C0E5-4E23-B340-7E4ABB0872D9@freeswitch.org> From: Brian West To: Cullen Jennings In-Reply-To: <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 12:57:37 -0500 References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Gregory Lebovitz , codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 18:20:09 -0000 Anyone ever get info out of Ericsson about G.719 licensing? I refuse to sign the NDA to even get them to tell me the details of the license. /b On Jul 14, 2009, at 11:38 AM, Cullen Jennings wrote: > > I just received this Liaison from the ITU. I wanted to forward it on > so people could see it ASAP. If there are problems with attachments, > let me know and I will get them posted to a site where people can > get them. > > Cullen > From Borilin@spiritdsp.com Tue Jul 14 11:50:35 2009 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 565273A691B for ; Tue, 14 Jul 2009 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.888, 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 akWL2oQrHQzv for ; Tue, 14 Jul 2009 11:50:34 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 7A2BF3A6778 for ; Tue, 14 Jul 2009 11:50:32 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6EInEM4024832; Tue, 14 Jul 2009 22:49:14 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Jul 2009 22:49:07 +0400 Message-ID: In-Reply-To: <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoBhSVYNqZU/wxjTsiah0sRNNaa0ADLoOQA References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> From: "Slava Borilin" To: "Jason Fischl" , "Roni Even" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: Ingemar Johansson S , codec@ietf.org, stephen botzko Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 18:50:35 -0000 Dear Jason, Jean-Marc, Have you decided on the date and time for the lunch codec tutorial session (for trip planning purposes) please? best regards, Slava Borilin -----Original Message----- From: Jason Fischl [mailto:jason.fischl@skype.net]=20 Sent: Friday, July 10, 2009 9:38 PM To: Roni Even Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin; codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF The point of briefly presenting a few codecs is to show the type of =20 work that would be done in the working group and to address the =20 feasibility of the goal. It is not to present the issues with the =20 particular codecs or even the details of the codecs. There have been =20 assertions on the list that the IETF lacks the expertise to do this =20 work. This agenda item attempts to address that concern. I'd also like to encourage other people to post to the list with their =20 opinions on whether or not agenda item 4 (codecs) should be included. As Stephen suggests, Jean-Marc and I will arrange for a lunch codec =20 tutorial session prior to the BOF on Wednesday or Thursday. Jason On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > Hi, > I still fail to see what is the value in presenting one, two or three > codecs. I saw that there was a request to present a third one. > I can agree that there are people who can present codecs as a =20 > suggested > solution including existing ones. Since there is no charter yet =20 > under which > the codecs are to be specified it may serve as a tutorial on codecs. =20 > So if > we open to codec presentation in the BOF let allow everyone to =20 > present their > codecs including ITU and MPEG ones and spend the whole BOF of the =20 > different > codecs technologies. > If the idea behind this presentation is to show specific =20 > functionality than > instead it will be more fruitful to present requirements, since I =20 > could see > from the list discussion that there is no consensus even between the =20 > current > proponents what the requirements are. > > Roni Even > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf >> Of Peter Saint-Andre >> Sent: Friday, July 10, 2009 5:46 PM >> To: stephen botzko >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org >> Subject: Re: [codec] Updated Agenda for Codec BOF >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/10/09 5:26 AM, stephen botzko wrote: >>> Sorry to disagree on this. >>> >>> - A 25 minute presentation is not "short" in a 2 hour meeting. 5 >>> minutes would be short. >>> - SILK and CELT are well known, and can be studied/reviewed by =20 >>> anyone >>> interested off-line. >>> >>> The net effect of a 25 minute codec presentation by WG proponents is >> to >>> remove 25 minutes of discussoin time. A second effect is that it >> biases >>> the time allotment in favor of proponents, which acts to skew the >> input >>> to IESG in that direction. Arguments against are just as important =20 >>> as >>> arguments for at this point in the process. >>> >>> Perhaps a compromise is possible? Move item 4 to the _end_ of the >>> agenda, and make it the "time permits" activity? >> >> How about 5 minutes to discuss each of the codec I-Ds at a high =20 >> level? >> Allotting 10 minutes out of 2 hours to existence proofs and what they >> imply for the work of the Codec WG (if approved) seems helpful to me. >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can >> productively talk about how these codecs could be used as input to a >> working group. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV >> =3Dbx98 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 kpfleming@digium.com Tue Jul 14 12:52:50 2009 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 DF1FB3A6851 for ; Tue, 14 Jul 2009 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 4yYxGabhwb2X for ; Tue, 14 Jul 2009 12:52:49 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id A9CDF3A67E1 for ; Tue, 14 Jul 2009 12:52:49 -0700 (PDT) Received: from kildare.digium.internal ([10.24.20.235]) by mail.digium.com with esmtp (Exim 4.63) (envelope-from ) id 1MQo1Q-0007p5-8e for codec@ietf.org; Tue, 14 Jul 2009 14:50:40 -0500 Message-ID: <4A5CE1D5.6030705@digium.com> Date: Tue, 14 Jul 2009 14:51:49 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 CC: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 19:52:50 -0000 Switching tracks just a bit... I joined this group at the request of Jean-Marc (although unfortunately I won't be able to attend the BOF in person, but will be attending remotely via whatever means are made available). As one of the major open source telephony platforms in the world, the Asterisk project and community would *strongly* benefit a from a high quality, efficient and reliable audio codec that can provide a range of bandwidth and bit rate options and is *also* licensed in a way that makes it compatible with even the most restrictive of common open source licenses (GPLv2 and similar licenses). Digium currently expends a great deal of effort making G.729 available to the Asterisk community at a reasonable cost, which entails producing binary distributions and dealing with patent licensing (and all the requirements that brings along). We will do the same for G.722.1 and G.722.1 Annex C, because those codecs are starting to appear on endpoints and they provide real benefits over the other options that are available. We also currently support iLBC (although we don't distribute the source code for it due to the somewhat unusual license terms) and Speex, which are the only other open source license compatible audio codecs available today beyond G.711. We cannot see any practical way to offer the Asterisk community support for any other ITU or 3GPP codecs, because their "RAND" licensing precludes inclusion in an open source project, and even if we are willing to charge/pay for licensing, the terms are so skewed towards carrier deployments that we cannot reasonably become involved with pass-through licensing unless we can demonstrate up front that there is a large enough demand to warrant the initial licensing costs. This is in spite of the fact that Asterisk is being deployed heavily to interconnect to mobile networks, where support of AMR, AMR-WB and EVRC would be most welcome indeed (and some users add support for these codecs themselves, in spite of the patent infringement risk). While I cannot speak to the ability (or lack thereof) of an IETF WG to formulate, publish and follow a codec development, testing and selection process in the way that the ITU-T or other SDOs do, I can absolutely say that we support *any* process that has a stated goal of producing a world-class audio codec for speech and music, designed for Internet applications, with a FLOSS-compatible license. I look forward to seeing what this BOF can achieve; it is important that codecs become available that can compete with RAND (or even more restrictively licensed) codecs and have the backing of an established, respected SDO, so that endpoint manufacturers will see the value of including them in their products. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From ron.even.tlv@gmail.com Tue Jul 14 14:15:02 2009 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 2CEBD3A66B4 for ; Tue, 14 Jul 2009 14:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 ovb5Z+YvKn7Q for ; Tue, 14 Jul 2009 14:15:00 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id B214A3A677E for ; Tue, 14 Jul 2009 14:14:01 -0700 (PDT) Received: by bwz28 with SMTP id 28so1042664bwz.37 for ; Tue, 14 Jul 2009 14:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=3yuOn3Mk55jscb19GYDAvfgtHxYSL5XQ5w4VSYzM7Fo=; b=ZqwWBxc4VV9jgZ6HKFUaP05NdMlzCpJe9KdJVFx0X/ijyCiJyAmtf5PM3RGYlGs5EY 1KADw7XNla0YLiqC7/CKFxKtQh+pBKRyw01fkPYlIlFOnOILVufM8sHkQwoGyB1TwzBZ QetOGIZSpnK8VKCQ1LkW+wxN+UOUmcw2aXCwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=cqfewu2OBiDanBE+WvsW+iUDCFPYwD7Swk8sFHNsF9vcKbg2Nzkm/3BbdeXWelzLt6 EvZSrxIqdaLnKOQ4Fxp5G7u4F+Z8pDR94YRVhLDhvcMmlaYAdRs+cRGkmg6tjjEjbwTI pqoU9Fvf1ODFtdZtudD4JPd23aPpsWSRN9c+4= Received: by 10.103.169.18 with SMTP id w18mr3654198muo.101.1247605581259; Tue, 14 Jul 2009 14:06:21 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id t10sm3085573muh.0.2009.07.14.14.06.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 14:06:20 -0700 (PDT) From: "Roni Even" To: "'Kevin P. Fleming'" References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4A5CE1D5.6030705@digium.com> In-Reply-To: <4A5CE1D5.6030705@digium.com> Date: Wed, 15 Jul 2009 00:05:54 +0300 Message-ID: <4a5cf34c.0af6660a.3af4.369d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoEvMDjGPHiWV5UR7+pXiNXt2PHCwABlcyQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:15:02 -0000 Kevin, I see that you are using Speex and iLBC who are not standardize by any of the SDOs so why not just add Silk or Celt support to you platform. I do not think that the discussion is about the benefit of LF and simple licensing. At least G.722.1 and G.722.1C were used also in their proprietary form (SIREN) in the industry even though they were not standards because they offered benfits. The discussion is if the IETF process can mandate and guarantee such outcome (LF and Open source licensing). You have to take into account that a standard process should have clear rules about the requirements and quality of the outcome. It should give a fair chance for everyone to participate. This also requires that there will be independent reviewers capable of reviewing codec work. On the other hand using Celt or Silk based on their current developers and leaving it for their change control will be easier (like doing beta tests as was suggested) and their usage in the market will be based on the quality and benefits. Like you mention you want to support all codecs being used in shipping products and in my view the more codecs you add complicates the interoperability. The IETF does not define system solution and your solution will get better results if such codecs were defined in 3GPP or ETSI who define the codecs you currently have problem with. Roni Even. > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Kevin P. Fleming > Sent: Tuesday, July 14, 2009 10:52 PM > Cc: codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > Switching tracks just a bit... I joined this group at the request of > Jean-Marc (although unfortunately I won't be able to attend the BOF in > person, but will be attending remotely via whatever means are made > available). As one of the major open source telephony platforms in the > world, the Asterisk project and community would *strongly* benefit a > from a high quality, efficient and reliable audio codec that can > provide > a range of bandwidth and bit rate options and is *also* licensed in a > way that makes it compatible with even the most restrictive of common > open source licenses (GPLv2 and similar licenses). > > Digium currently expends a great deal of effort making G.729 available > to the Asterisk community at a reasonable cost, which entails producing > binary distributions and dealing with patent licensing (and all the > requirements that brings along). We will do the same for G.722.1 and > G.722.1 Annex C, because those codecs are starting to appear on > endpoints and they provide real benefits over the other options that > are > available. We also currently support iLBC (although we don't distribute > the source code for it due to the somewhat unusual license terms) and > Speex, which are the only other open source license compatible audio > codecs available today beyond G.711. We cannot see any practical way to > offer the Asterisk community support for any other ITU or 3GPP codecs, > because their "RAND" licensing precludes inclusion in an open source > project, and even if we are willing to charge/pay for licensing, the > terms are so skewed towards carrier deployments that we cannot > reasonably become involved with pass-through licensing unless we can > demonstrate up front that there is a large enough demand to warrant the > initial licensing costs. This is in spite of the fact that Asterisk is > being deployed heavily to interconnect to mobile networks, where > support > of AMR, AMR-WB and EVRC would be most welcome indeed (and some users > add > support for these codecs themselves, in spite of the patent > infringement > risk). > > While I cannot speak to the ability (or lack thereof) of an IETF WG to > formulate, publish and follow a codec development, testing and > selection > process in the way that the ITU-T or other SDOs do, I can absolutely > say > that we support *any* process that has a stated goal of producing a > world-class audio codec for speech and music, designed for Internet > applications, with a FLOSS-compatible license. > > I look forward to seeing what this BOF can achieve; it is important > that > codecs become available that can compete with RAND (or even more > restrictively licensed) codecs and have the backing of an established, > respected SDO, so that endpoint manufacturers will see the value of > including them in their products. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kpfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From brian@freeswitch.org Tue Jul 14 14:37:28 2009 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 0BE5D3A68D8 for ; Tue, 14 Jul 2009 14:37:28 -0700 (PDT) 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 MsSUZ+Amq5Ps for ; Tue, 14 Jul 2009 14:37:27 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 619EB3A677D for ; Tue, 14 Jul 2009 14:37:27 -0700 (PDT) Received: by pxi6 with SMTP id 6so551669pxi.29 for ; Tue, 14 Jul 2009 14:36:37 -0700 (PDT) Received: by 10.114.145.17 with SMTP id s17mr11327270wad.120.1247607397109; Tue, 14 Jul 2009 14:36:37 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id j31sm1981491waf.33.2009.07.14.14.36.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 14:36:35 -0700 (PDT) Message-Id: From: Brian West To: codec@ietf.org In-Reply-To: <4a5cf34c.0af6660a.3af4.369d@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 16:36:34 -0500 References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4A5CE1D5.6030705@digium.com> <4a5cf34c.0af6660a.3af4.369d@mx.google.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:37:28 -0000 Roni, I have been one of the cheer leaders behind wide/super/full band codecs in FreeSWITCH. We have implemented G722.1, G722.1C and CELT in FreeSWITCH, The uptake of wideband isn't as fast as it should be because most people don't realize how good it sounds till they hear it. Once you have someone hear the clarity and quality of a voice call from halfway around the world they are usually sold on the idea. /b On Jul 14, 2009, at 4:05 PM, Roni Even wrote: > On the other hand using Celt or Silk based on their current > developers and > leaving it for their change control will be easier (like doing beta > tests as > was suggested) and their usage in the market will be based on the > quality > and benefits. From brian@freeswitch.org Tue Jul 14 14:45:08 2009 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 EFE6A3A68F3 for ; Tue, 14 Jul 2009 14:45:08 -0700 (PDT) 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 Hif87pW+SOGQ for ; Tue, 14 Jul 2009 14:45:08 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 479D83A67E1 for ; Tue, 14 Jul 2009 14:45:08 -0700 (PDT) Received: by pxi6 with SMTP id 6so555197pxi.29 for ; Tue, 14 Jul 2009 14:44:34 -0700 (PDT) Received: by 10.114.169.13 with SMTP id r13mr11506228wae.113.1247606577253; Tue, 14 Jul 2009 14:22:57 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id m30sm11853537wag.34.2009.07.14.14.22.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 14:22:56 -0700 (PDT) Message-Id: <3B0407E7-8C34-4005-BD88-694378915B10@freeswitch.org> From: Brian West To: Kevin P. Fleming In-Reply-To: <4A5CE1D5.6030705@digium.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 16:22:54 -0500 References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4A5CE1D5.6030705@digium.com> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:45:09 -0000 Kevin, So Digium is going to sell G722.1/1C like G.729 on Asterisk? /b On Jul 14, 2009, at 2:51 PM, Kevin P. Fleming wrote: > We will do the same for G.722.1 and > G.722.1 Annex C, because those codecs are starting to appear on > endpoints and they provide real benefits over the other options that > are > available. From hsinnrei@adobe.com Tue Jul 14 14:55:30 2009 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 0CE243A6AAD for ; Tue, 14 Jul 2009 14:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3PLBsx5Nk65 for ; Tue, 14 Jul 2009 14:55:28 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id D0E803A66B4 for ; Tue, 14 Jul 2009 14:55:27 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSlz+sbxBXF2fCJ1eXVOjrLu/x8nTfOU4@postini.com; Tue, 14 Jul 2009 14:56:00 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6EJg1WG012445; Tue, 14 Jul 2009 12:42:02 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6EJg0iq017458; Tue, 14 Jul 2009 12:42:01 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 14 Jul 2009 12:42:01 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 14 Jul 2009 12:42:00 -0700 From: Henry Sinnreich To: "Kevin P. Fleming" Date: Tue, 14 Jul 2009 12:41:58 -0700 Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Thread-Index: AcoEqx+96RethiTsSMa/snU37AICEQAEAZ6f Message-ID: In-Reply-To: <4A5CBB28.9020907@digium.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68249B64D93hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:55:30 -0000 --_000_C68249B64D93hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >So that MCSD listing is quite interesting indeed; it's comprehensive, Actually a more comprehensive list and comparison table of audio codecs is = on the Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_audio_codecs Henry On 7/14/09 12:06 PM, "Kevin P. Fleming" wrote: Cullen Jennings wrote: > I just received > this Liaison from the ITU. I wanted to forward it on so people could see = it ASAP. If > there are problems with attachments, let me know and I will get them > posted to a site where people can get them. So that MCSD listing is quite interesting indeed; it's comprehensive, and it appears to support some of the points that were used to initiate this discussion in the first place; of that entire list of audio coding standards known by the ITU-T (regardless of SDO), there are only four that are in common use that are not under RAND licensing terms: G.711, G.722.1 Annex C, iLBC and Speex. Of those four, only two have RF licensing terms that are actually compatible with the majority of FLOSS licenses in common use, G.711 and Speex. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C68249B64D93hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (= 10 July 2009) >So that MCSD listing is quite interesting indeed; it's comprehens= ive,

Actually a more comprehensive list and comparison table of audio codecs is = on the Wikipedia:

http://= en.wikipedia.org/wiki/Comparison_of_audio_codecs

Henry


On 7/14/09 12:06 PM, "Kevin P. Fleming" <kpfleming@digium.com> wrote:

Cullen Jennings wrote:

> I just received
> this Liaison from the ITU. I wanted to forward it on so people could s= ee it ASAP. If
> there are problems with attachments, let me know and I will get them > posted to a site where people can get them.

So that MCSD listing is quite interesting indeed; it's comprehensive,
and it appears to support some of the points that were used to initiate
this discussion in the first place; of that entire list of audio coding
standards known by the ITU-T (regardless of SDO), there are only four
that are in common use that are not under RAND licensing terms: G.711,
G.722.1 Annex C, iLBC and Speex. Of those four, only two have RF
licensing terms that are actually compatible with the majority of FLOSS
licenses in common use, G.711 and Speex.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digiu= m.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C68249B64D93hsinnreiadobecom_-- From stpeter@stpeter.im Tue Jul 14 15:37:06 2009 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 0210D3A6A01 for ; Tue, 14 Jul 2009 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 Di8fb2oIyqO5 for ; Tue, 14 Jul 2009 15:37:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 22AC03A67A5 for ; Tue, 14 Jul 2009 15:37:05 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E6D24007B; Tue, 14 Jul 2009 15:47:45 -0600 (MDT) Message-ID: <4A5CFD01.1070403@stpeter.im> Date: Tue, 14 Jul 2009 15:47:45 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Brian West References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4A5CE1D5.6030705@digium.com> <3B0407E7-8C34-4005-BD88-694378915B10@freeswitch.org> In-Reply-To: <3B0407E7-8C34-4005-BD88-694378915B10@freeswitch.org> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:37:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/14/09 3:22 PM, Brian West wrote: > Kevin, > So Digium is going to sell G722.1/1C like G.729 on Asterisk? > > /b Brian: Isn't such a question quite off topic for this list? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpc/QEACgkQNL8k5A2w/vyt/wCgjXdkCCUeKMviB8ONo1jQYnfq mMIAoNPfEdhUtOYpAkjgzc6oesBaQOeL =LIBf -----END PGP SIGNATURE----- From brian@freeswitch.org Tue Jul 14 15:51:24 2009 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 A393E3A6F2C for ; Tue, 14 Jul 2009 15:51:24 -0700 (PDT) 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=[AWL=0.000, 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 DboQTtYglE+F for ; Tue, 14 Jul 2009 15:51:23 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 551263A6CD7 for ; Tue, 14 Jul 2009 15:51:23 -0700 (PDT) Received: by pxi6 with SMTP id 6so583646pxi.29 for ; Tue, 14 Jul 2009 15:50:26 -0700 (PDT) Received: by 10.114.167.3 with SMTP id p3mr11281274wae.214.1247608180024; Tue, 14 Jul 2009 14:49:40 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id j31sm1998672waf.33.2009.07.14.14.49.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 14:49:39 -0700 (PDT) Message-Id: <1D383D0A-9A2E-4420-A10D-3420C334F9EE@freeswitch.org> From: Brian West To: Peter Saint-Andre In-Reply-To: <4A5CFD01.1070403@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 16:49:38 -0500 References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <9EF887ED-EC75-4703-A774-A1648E65FE6A@skype.net> <4A5CE1D5.6030705@digium.com> <3B0407E7-8C34-4005-BD88-694378915B10@freeswitch.org> <4A5CFD01.1070403@stpeter.im> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:51:24 -0000 True, Didn't mean to replay all! :) /b On Jul 14, 2009, at 4:47 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/14/09 3:22 PM, Brian West wrote: >> Kevin, >> So Digium is going to sell G722.1/1C like G.729 on Asterisk? >> >> /b > > Brian: > > Isn't such a question quite off topic for this list? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpc/QEACgkQNL8k5A2w/vyt/wCgjXdkCCUeKMviB8ONo1jQYnfq > mMIAoNPfEdhUtOYpAkjgzc6oesBaQOeL > =LIBf > -----END PGP SIGNATURE----- From gregory.ietf@gmail.com Tue Jul 14 21:25:06 2009 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 8D83B3A67FA for ; Tue, 14 Jul 2009 21:25:04 -0700 (PDT) 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 T-e4iZSxcOJn for ; Tue, 14 Jul 2009 21:25:03 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 655163A67D3 for ; Tue, 14 Jul 2009 21:25:03 -0700 (PDT) Received: by gxk9 with SMTP id 9so1800049gxk.13 for ; Tue, 14 Jul 2009 21:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=zk20W2gf3DPGAc1KcL7wT9A99c56EKf6OZ1mVBdrMIU=; b=fRZ3OXQbwiFdnIb4P+w9J5NOawbTpy1ld0pBqU7BLopywjzxq7kQe56urcwMEeFxhd HaWou+23pXxCu592jFzgaPm2SNOe6reC2ds5NtUMt7uuX0SOOCkGLocqmqnX1bSC9eJF 1hfJ7QezjcmOUnOMFdKuV7tCFxyHDmqszB4YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=UMaitHCxVDQfp5/9gGzIOzhdNo2wS7/VQVohRsVn0+SRThPVcGRgjnfikH28Vkt8jQ DV9TmiZ3wfNg/Kfryfr/jM2kJH1gLdRk+OoQnlTe5nGarD9vmCrDxLyCfhTD1OxdQnMH CKeey65dczIeqEnz+Zic6XZRRAMUSft2xXWVA= Received: by 10.90.86.9 with SMTP id j9mr1740148agb.94.1247631876108; Tue, 14 Jul 2009 21:24:36 -0700 (PDT) Received: from Gregory-T60.gmail.com ([198.80.6.3]) by mx.google.com with ESMTPS id 38sm756735agd.49.2009.07.14.21.24.33 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 21:24:34 -0700 (PDT) Message-ID: <4a5d5a02.26045a0a.7879.7cd3@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jul 2009 21:21:02 -0700 To: Cullen Jennings ,codec@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 14 Jul 2009 21:32:36 -0700 Subject: Re: [codec] Welcome to Greg X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 04:25:06 -0000 At 02:23 PM 7/13/2009, Cullen Jennings wrote: >Greg Lebovitz has kindly volunteered to be the IAB shepherd for this >BOF. Greg is on the IAB and has plenty of experience in "complicated" >topics. I also believe that he brings a very neutral view to the topic >of codecs. Just wanted to let folks know that Greg would be helping >and tell him thanks. Glad to join the effort. This will be a fun and challenging topic for the IETF, and I'm looking forward to both aspects. Thx for the intro Cullen. >Cullen > >PS. Greg, I assume you will be sporting a large grey beard by IETF >75 :-) A brown goatie, and that's my final offer. ;-) From koen.vos@skype.net Wed Jul 15 01:44:16 2009 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 4A4523A684C for ; Wed, 15 Jul 2009 01:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 bGtTAbRoudlG for ; Wed, 15 Jul 2009 01:44:15 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 38A253A6B22 for ; Wed, 15 Jul 2009 01:43:59 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 047712007C21A for ; Wed, 15 Jul 2009 10:33:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=Q6hOOHOn66X4 5oK0yB5y6/lADOw=; b=N6mYcQZVSSX/0xCUdA1i9tH53tQqr+IZKnTHzmRIj+Fu ga/BcsoiuGdsHM3DaMyRRN5/TvNNNrW0nd8MHWNs5BJnWdSEkiK+0UdA7ty4xgkp mw5guDODki664w9PhWV8nN/Ekng7dAQowfQebBiEZDL3nibJQ4fmrNVjX5o3m1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=a+A0PUqcWdW4Yv8TxBPn 0kceICMffMS2vkI4XvmpbAwbcOmrUD1N7sQWmjd6CuFHG2WYPS3BobRrpVz+r/pX 1Z5CFk4tY4nFH9dmdOlHO4TCplW154R8/60cdganpBM1zPWED37DW6izm2a8U4E8 Njbc3QnmvjDw6H06WXLY0QA= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 025A02007C211 for ; Wed, 15 Jul 2009 10:33:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPLf5ylnKJ0L for ; Wed, 15 Jul 2009 10:33:34 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 3A9B72007C214; Wed, 15 Jul 2009 10:33:34 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Wed, 15 Jul 2009 01:33:34 -0700 Message-ID: <20090715013334.21361mvyjlbk39su@mail.skype.net> Date: Wed, 15 Jul 2009 01:33:34 -0700 From: Koen Vos To: codec@ietf.org References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> In-Reply-To: <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 08:44:16 -0000 So ITU won't adopt Royalty Free as a design goal, being equally fine =20 with RAND licensing terms. Regrettable. Can anyone shine a light on what "misconceptions" were corrected in =20 their Statement? thanks, koen. Quoting Cullen Jennings : > > I just received this Liaison from the ITU. I wanted to forward it on =20 > so people could see it ASAP. If there are problems with =20 > attachments, let me know and I will get them posted to a site where =20 > people can get them. > > Cullen > > > Begin forwarded message: > >> From: >> Date: July 14, 2009 7:51:01 AM PDT >> To: , , >> Cc: , >> Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009= ) >> >> >> >> Kindly find attached the Liaison Statement COM16 - LS 71 on =20 >> "information on ITU-T Speech and audio coding standardisation" =20 >> addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting =20 >> (10 July 2009). >> >> Please take note that we are sending herewith the word version as =20 >> well as the pdf version of the LS. In addition, there is an =20 >> attachment, which is in excel. Since it is quite complex with =20 >> different sheets, we preferred to keep the excel file in the =20 >> original version. >> >> >> >> <> <> <> Database-V20081003.xls>> >> >> >> Best regards, >> Rosa Angeles-Le=F3n de Vivero >> Assistant for ITU-T Study Group 16 >> ITU - Telecommunication Standardization Bureau (TSB) >> SG 16 e-mail: tsbsg16@itu.int >> Tel. 41-22 730 5445 >> Fax 41-22 730 5853 >> >> > > From hoene@uni-tuebingen.de Wed Jul 15 03:57:42 2009 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 572C93A6B8D for ; Wed, 15 Jul 2009 03:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 slBgt7grT9lc for ; Wed, 15 Jul 2009 03:57:40 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id DC5803A6B25 for ; Wed, 15 Jul 2009 03:57:38 -0700 (PDT) Received: from hoeneLenovoT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6F9uwVA002606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Jul 2009 11:56:59 +0200 From: "Christian Hoene" To: References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> In-Reply-To: <002a01ca0529$3ebb9800$bc32c800$@de> Date: Wed, 15 Jul 2009 11:56:59 +0200 Message-ID: <002b01ca0532$98fc84b0$caf58e10$@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: AcoEoaxGtVDXknWPSli1k3tvucohLAAh1MRAAAASbyA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 10:57:42 -0000 Hello, I have copied the liaison statement into this email to comment it. =20 > Question(s): 8, 9, 10/16 Geneva, 10 July 2009 > LIAISON STATEMENT > Source: ITU-T SG 16 =E2=80=93 Q8, 9, 10/16 > Title: LS to IESG and IETF-RAI on information on ITU-T Speech and = audio coding > standardisation > LIAISON STATEMENT > For action to: - > For comment to: - > For information to: IESG, IETF-RAI > Approval: ITU-T WP 3/16 meeting (Geneva, 10 July 2009) > Deadline: N/A > Contact: Ms Claude Lamblin > France Telecom Orange > France Tel: +33 2 96 05 13 03 > Fax: +33 2 96 05 35 30 > Email: claude.lamblin@orange-ftgroup.com >=20 >=20 > 1. Introduction > It has been brought to our attention that within IETF, the creation of = a new > IETF working group to define a wideband audio codec specifically for = use with > the Internet has been recently proposed. We observed that the initial = proposal > was followed by discussions on the IETF email reflector codec@ietf.org = and > that during these discussions, references to ITU-T speech and audio = coding > work were often made. > Despite the intervention of some individuals familiar with ITU-T > standardisation work, we regrettably observe that there are still = several > misconceptions and out-of-date understanding of the current state of = the > speech and audio coding work in ITU-T.=20 I am reactivating my TIES account to get a detailed understanding of the = current state of the work. I agree, it is a must. Having read the = documents suggested during the discussion on this mailing list, I have = to agree that in the last years the ITU-T SG16 and the 3GPP have made = substantial progress towards a codec, which is more better suited for = the Internet. However, still a number of issues have not been addresses, = yet. > We see as paramount that any decisions > to be taken in the upcoming IETF meeting be taken on a sound basis, = therefore > ITU-T WP3/16 would like to offer the following information on ITU-T = speech and > audio coders and its standardization process, in order to help allay = some of > the observed misconceptions. > 2. Speech and Audio Coding Standards > The ITU-T audio/speech codecs portfolio (see table below) is quite = significant > covering a wide range of audio bandwidths and bit rates, offering = different > trade-offs to address various applications with different requirements = (on > quality, bit rates, complexity, robustness, delay). TCP, the main transportation protocol on the Internet, works on any link = regardless whether it has a capacity of one 1 packet per second or one = million. One reason for the success of TCP is that is can be used on any = kind of device. No matter whether it is a 8bit processor or powerful = mainframe. I am wondering, why it is not possible to have a codec, which works on a = wide range of different network conditions and on a wide range of = devices. Maybe a combination of SILK and CELT can fulfill this dream? > Audio Bandwidth [kHz] Sampling frequency [Hz] Bit rates [kbit/s] ITU-T > G.7xx-series > 300-3400 (narrowband) 8000 5.3 =EF=82=AE 80 G.711, G.726, G.727, = G.728, > G.729, G.723.1, G.729.1, G.711.1, G.718 > 50-7000 (wideband) 16000 6.6 =EF=82=AE 96 G.722, G.722.1, G.722.2, = G.729.1, > G.711.1, G.718 > 50-14000 (superwideband) 32000 24 =EF=82=AE 48 G.722.1C > 20-20000 (fullband) 48000 32 =EF=82=AE 128 G.719 One important criteria for Internet based transmissions is the packet = rate (TCP controls the number of packets per round trip time, not the = bit rate of user data). This important parameter is missing in the = table. > Conversational applications are the primary applications=20 > and there has been an > evolution from circuit-switched voice applications (e.g. PSTN and = circuit > multiplication equipment) to packet-based multimedia (notably IP). To my understanding the goals of the proposed working group are to = develop a codec that should be optimized thwarts the Internet. The = support of classic PSTN networks is of lower importance. We need a clear cut between the traditions of a circuit switched codec = design and the work which shall be done here. A disruptive technology = having different goals has to be developed. The evolution approach = followed by the ITU might not allow a clean slate approach. > ITU-T coders are extensively deployed and their modern applications go = beyond > the constraints for which the codecs were initially targeted.=20 I do have the opinion that ITU_T make the most perfect codecs. But can = every Internet user afford to license them?=20 > Therefore, ITU-T has extended these coders with new features to = provide quick responses to > customer demands and to cope with new constraints of those modern > applications.=20 > For instance, Appendices to G.711 and G.722 =E2=80=93 coders initially > designed for PSTN and ISDN, respectively, provide Packet Loss = Concealment > (PLC) procedures to cope with packet losses that can occur during = transmission > over IP and other packet networks.=20 In my opinion, the requirements of an Internet codec, which is not = equivalent to a codec for packet networks, are not fulfilled if PLC is = added a circuit switched codec. The technical requirements listed in the = SILK draft are an example of requirements beyond PLC.=20 Or to say it easier: CircuitSwitchedCodec + PacketLossConcealment !=3D = InternetCodec > Other functionalities have been and are > being developed such as wider audio bandwidth and stereo rendering = capability. CELT supports ultra-low latency audio transmission for distributed = ensemble performances. The only standardized codec, which fulfills this = requirement is the SBC from Bluetooth SIG. But of course, the current = market for ultra-low latency audio transmission does not exist. > As the collection of speech and audio coding standards =E2=80=93 from = ITU and other > standards development organizations (SDOs) =E2=80=93 is considerable, = before launching > the standardization of a new codec leading to interoperability = problems, ITU-T > WP3/16 checks whether the desired codec requirements are not met by = existing > standards. ITU-T WP3/16 regularly updates a Media Coding Summary Data = base > (MCSD) which provides an authoritative summary of media coding = standards of > ITU-T and of other SDOs such as 3GPP, 3GPP2, ISO/IEC MPEG, ETSI, etc. As soon the CODEC BOF participants write down requirements on the codec = of the CODEC group are written down, we shall send them the ITU-T SG 16. = It has to be made sure that we did not oversaw any existing codecs, = which fulfill the requirements of an internet codec. > 3. ITU-T Standardization Process > If market needs for a new codec are identified, the ITU-T speech and = audio The IETF has developed the Internet long before a market need has been = identified. Also, I do not believe that a RF codec for the Internet will = create a large market. Telephone calls over the Internet are typically = free of charge. Companies have to make money by other means but with = VoIP calls.=20 > coding standardisation process has several well-defined stages from = the > specification of the Terms of Reference until the approval of the > Recommendation. We have found over the years that this phased approach = is > necessary to ensure a transparent process and the best possible choice = of > technology for a particular purpose. The Terms of Reference contain = the > targeted applications, their associated design constraints and = required > performance (delay, complexity, audio bandwidth, bit rate, quality, = etc). The > approval of the Recommendation is based on the review of a list of > deliverables: text of the proposed recommendation and C-code, = performance in > terms of quality, complexity, delay, and IPR policy (RAND or RF, see = below). As said before, ITU-T SG 16 processes are the best. We have to look at = them... > In the meantime, there are several stages to thoroughly assess the = performance > of the candidates,=20 The Internet CODEC shall be available RF, which reduces the potential = income for its developers. It would be nice to have the same assessment = for an Internet CODEC. I doubt whether the participants and codec = developers can afford them.=20 > the quality performance being performed in close > collaboration with SG 12, which selects the best suitable testing > methodologies, designs the test plan and analyses the results from the > international labs appointed by SG 12 to run the quality tests. = Currently, > the experts in SG12 consider that subjective quality assessment based = upon > formal listening tests in at least two languages remains the most = appropriate > manner in which to evaluate codec performance and to guarantee = suitability of > codecs to international use. Objective quality assessment = methodologies are > only considered appropriate to compare alternative implementations of = the same > codec. Yes, I agree. Objective quality assessment methodologies cannot replace = subjective tests. I have done some but I think it is a common = understanding that the objective results are not precise and are only an = indication of quality. They cannot replace formal tests following ITU-T = P.800 or ITU BS.1534-1 procedures. > Besides rigorous testing, since the standardization of G.729 and = G.723.1, ITU- > T speech and audio codec Recommendation specifications use C-source = code in > fixed point arithmetic as the normative algorithm description method > (alternative floating point implementations are also provided). For = older > standards, reference C-source code can be found in the ITU-T Software = tool > library (G.191 Annex A). This specification applies not only to the = encoder > and decoder but also to example solutions (e.g. Appendices describing = packet > loss concealment procedures). > Once published, ITU-T speech and audio coding Recommendations with = integrated > C-source code are freely downloadable. Is the ITU open source license compatible with BSD, LGPL, GPL? Maybe, = somebody who understands this license can added it to Wikipedia? = http://en.wikipedia.org/wiki/Open_source_license > 4. IPR Aspects > With regard to the presence of intellectual property rights in our = standards, > the IPR policy adopted is consistent with those of other SDOs, where = one must > ensure that the standards can be implemented under either royalty free = (RF) or > reasonable and non-discriminatory terms (RAND). Extensively deployed = ITU-T > codecs encompass both RF and RAND policies. When the preference is RF = there > are ITU-T codecs to address this some of which are already used in = Internet. Yes, but they do not fulfill the technical requirements of an internet = CODEC. > 5. Participation in ITU-T Work > As a final observation, we would like to inform you that 191 countries = (Member > States) and over 700 companies of all sizes are members of ITU. There = are many > means to enable participation of non-ITU members in our = standardization work. > One tool is the participation sponsored by existing members, such as a = Member > State; we could cite the example of a university and later its = spin-off > company in North-America that for many years used that mechanism = before > becoming a member, and was able to successfully contribute to the = development > of various existing Recommendations.=20 Yes, I agree. At least in Germany it is easy for an university employee = to join the German ITU delegation. I have done this a couple of times = joining SG12. > Another possibility commonly used is > participation at meetings as invited experts. The secretariat at > tsbsg16@itu.int is available to provide details to interested parties. > 6. Proposal > In conclusion, we would be very happy to work with you, we will be = glad to > review any requirements you might develop for an =E2=80=9CInternet = wideband codec=E2=80=9D and > discuss possible ways to meet them. Yes, I agree. We shall consider the offer to review the requirements - = as soon as they have been written done. I think it would be very useful. Thank you Christian Hoene >=20 > -------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=C3=BCbingen > Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Cullen Jennings > Sent: Tuesday, July 14, 2009 6:38 PM > To: codec@ietf.org > Cc: Gregory Lebovitz > Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 = meeting (10 > July 2009) >=20 >=20 > I just received this Liaison from the ITU. I wanted to forward it on = so people > could see it ASAP. If there are problems with attachments, let me know = and I > will get them posted to a site where people can get them. >=20 > Cullen >=20 >=20 > Begin forwarded message: >=20 >=20 > From: > Date: July 14, 2009 7:51:01 AM PDT > To: , , > Cc: , > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July = 2009) >=20 >=20 > Kindly find attached the Liaison Statement COM16 - LS 71 on = "information on > ITU-T Speech and audio coding standardisation" addressed to IESG and = IETF-RAI > agreed at the ITU-T WP2/16 meeting (10 July 2009). > Please take note that we are sending herewith the word version as well = as the > pdf version of the LS. In addition, there is an attachment, which is = in > excel. Since it is quite complex with different sheets, we preferred = to keep > the excel file in the original version. >=20 > <> <> < V20081003.xls>> >=20 > Best regards, > Rosa Angeles-Le=C3=B3n de Vivero > Assistant for ITU-T Study Group 16 > ITU - Telecommunication Standardization Bureau (TSB) > SG 16 e-mail: tsbsg16@itu.int > Tel. 41-22 730 5445 > Fax 41-22 730 5853 From stephen.botzko@gmail.com Wed Jul 15 04:42:45 2009 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 94A613A67A6 for ; Wed, 15 Jul 2009 04:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.458, 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 Z94IBJ8aOMnC for ; Wed, 15 Jul 2009 04:42:42 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id B08793A6778 for ; Wed, 15 Jul 2009 04:42:41 -0700 (PDT) Received: by bwz28 with SMTP id 28so1355612bwz.37 for ; Wed, 15 Jul 2009 04:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=27p70v2whBiyeNVRMe+5D4HfyCOfW2kn3Y3rCu2JN6o=; b=FA08Aa4nq8hWLLvyZVeqO/2y0gRUWmy3aaR4Ett+L60zzSEWhkvIUXCITp40cWbYXX FBWNUnX5fq2X/3pen6P/Rfqi04OvxHy3aotSVAqhRuS3HvSQLjjHDOlr0O75S4Dk+LQ1 e50eB5dqIAeWL7I+tExOqdEPGKNEXWqZne01k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dhN7HJmv4o0XQyL4FinWHJQ9uQMjDVwRJ72z/SQY+++kMSYOZrvDlwCZRfhK50uvF5 9IGIh0I31nD/YGL8z2uTbML0MJ/W1zySsCQgPjfhY3Wkttd8asDIlUtN8+tiXyl5Ri0o Q4JNpOuXUbe7gl4xlEvfyhnED8vWyr6mi23mY= MIME-Version: 1.0 Received: by 10.103.241.5 with SMTP id t5mr3982342mur.123.1247658162674; Wed, 15 Jul 2009 04:42:42 -0700 (PDT) In-Reply-To: <002b01ca0532$98fc84b0$caf58e10$@de> References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> Date: Wed, 15 Jul 2009 07:42:42 -0400 Message-ID: <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636b4313d965c5b046ebd0dd8 Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 11:42:45 -0000 --001636b4313d965c5b046ebd0dd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I share your view that the ITU-T testing processes are first rate, and that we do need to take an objective look at their current approach. I am curious as to why you are focused on TCP as the transport. I'd think that anything the working group does would be carried on RTP, which can use either TCP or UDP, but generally uses UDP for most speech applications. As far as packet rate, that is usually specified in the RTP packetization RFC, not in the codec spec itself. At present, the ITU-T is deferring to the IETF, and not specifying the RTP packetization in their recommendations. Though generally they do amend the recommendation to include a reference to the appropriate RFC after it is published. I'd think that there would still need to be 2 specs - the RFC for the codec itself, and a separate RFC for RTP/SIP, done through AVT. Some more dicussion on specific requirements that are not in the ITU-T codecs but which are desired in the "internet codec" would be fruitful, as = I agree that this proposed group (when and it) should have different goals from other SDOs. Ideally these goals would be broader than the attributes of SILK or CELT, since it is reasonable to assume that this group would go on to standardize more codecs (being re-chartered as necessary). IPR terms alone are not enough (in my view). to justify yet another codec standardization group. BTW, I don't think the ITU-T folks would agree that their codecs are "circuit switched", I think they would argue strongly that they are already standardizing codecs that are suitable for the internet. If there are requirements that they are missing, that would be a strong enough "market" statement for the ITU-T. They want to be sure there is an application for the codec that current codecs don't satisfy. They aren't particularly concerned with how large that market is, they just want assurance that ther= e is one. Regards, Stephen Botzko Polycom On Wed, Jul 15, 2009 at 5:56 AM, Christian Hoene wr= ote: > Hello, > > I have copied the liaison statement into this email to comment it. > > > Question(s): 8, 9, 10/16 Geneva, 10 July 2009 > > LIAISON STATEMENT > > Source: ITU-T SG 16 =E2=80=93 Q8, 9, 10/16 > > Title: LS to IESG and IETF-RAI on information on ITU-T Speech an= d > audio coding > > standardisation > > LIAISON STATEMENT > > For action to: - > > For comment to: - > > For information to: IESG, IETF-RAI > > Approval: ITU-T WP 3/16 meeting (Geneva, 10 July 2009) > > Deadline: N/A > > Contact: Ms Claude Lamblin > > France Telecom Orange > > France Tel: +33 2 96 05 13 03 > > Fax: +33 2 96 05 35 30 > > Email: claude.lamblin@orange-ftgroup.com > > > > > > 1. Introduction > > It has been brought to our attention that within IETF, the creation of = a > new > > IETF working group to define a wideband audio codec specifically for us= e > with > > the Internet has been recently proposed. We observed that the initial > proposal > > was followed by discussions on the IETF email reflector codec@ietf.orga= nd > > that during these discussions, references to ITU-T speech and audio > coding > > work were often made. > > Despite the intervention of some individuals familiar with ITU-T > > standardisation work, we regrettably observe that there are still sever= al > > misconceptions and out-of-date understanding of the current state of th= e > > speech and audio coding work in ITU-T. > > I am reactivating my TIES account to get a detailed understanding of the > current state of the work. I agree, it is a must. Having read the documen= ts > suggested during the discussion on this mailing list, I have to agree tha= t > in the last years the ITU-T SG16 and the 3GPP have made substantial progr= ess > towards a codec, which is more better suited for the Internet. However, > still a number of issues have not been addresses, yet. > > > We see as paramount that any decisions > > to be taken in the upcoming IETF meeting be taken on a sound basis, > therefore > > ITU-T WP3/16 would like to offer the following information on ITU-T > speech and > > audio coders and its standardization process, in order to help allay so= me > of > > the observed misconceptions. > > 2. Speech and Audio Coding Standards > > The ITU-T audio/speech codecs portfolio (see table below) is quite > significant > > covering a wide range of audio bandwidths and bit rates, offering > different > > trade-offs to address various applications with different requirements > (on > > quality, bit rates, complexity, robustness, delay). > > TCP, the main transportation protocol on the Internet, works on any link > regardless whether it has a capacity of one 1 packet per second or one > million. One reason for the success of TCP is that is can be used on any > kind of device. No matter whether it is a 8bit processor or powerful > mainframe. > I am wondering, why it is not possible to have a codec, which works on a > wide range of different network conditions and on a wide range of devices= . > Maybe a combination of SILK and CELT can fulfill this dream? > > > Audio Bandwidth [kHz] Sampling frequency [Hz] Bit rates [kbit/s] > ITU-T > > G.7xx-series > > 300-3400 (narrowband) 8000 5.3 =EF=82=AE 80 G.711, G.726, G.7= 27, G.728, > > G.729, G.723.1, G.729.1, G.711.1, G.718 > > 50-7000 (wideband) 16000 6.6 =EF=82=AE 96 G.722, G.722.1, G= .722.2, > G.729.1, > > G.711.1, G.718 > > 50-14000 (superwideband) 32000 24 =EF=82=AE 48 G.722.1C > > 20-20000 (fullband) 48000 32 =EF=82=AE 128 G.719 > > One important criteria for Internet based transmissions is the packet rat= e > (TCP controls the number of packets per round trip time, not the bit rate= of > user data). This important parameter is missing in the table. > > > Conversational applications are the primary applications > > and there has been an > > evolution from circuit-switched voice applications (e.g. PSTN and circu= it > > multiplication equipment) to packet-based multimedia (notably IP). > > To my understanding the goals of the proposed working group are to develo= p > a codec that should be optimized thwarts the Internet. The support of > classic PSTN networks is of lower importance. > > We need a clear cut between the traditions of a circuit switched codec > design and the work which shall be done here. A disruptive technology hav= ing > different goals has to be developed. The evolution approach followed by t= he > ITU might not allow a clean slate approach. > > > ITU-T coders are extensively deployed and their modern applications go > beyond > > the constraints for which the codecs were initially targeted. > > I do have the opinion that ITU_T make the most perfect codecs. But can > every Internet user afford to license them? > > > Therefore, ITU-T has extended these coders with new features to provide > quick responses to > > customer demands and to cope with new constraints of those modern > > applications. > > For instance, Appendices to G.711 and G.722 =E2=80=93 coders initially > > designed for PSTN and ISDN, respectively, provide Packet Loss Concealme= nt > > (PLC) procedures to cope with packet losses that can occur during > transmission > > over IP and other packet networks. > > In my opinion, the requirements of an Internet codec, which is not > equivalent to a codec for packet networks, are not fulfilled if PLC is ad= ded > a circuit switched codec. The technical requirements listed in the SILK > draft are an example of requirements beyond PLC. > Or to say it easier: CircuitSwitchedCodec + PacketLossConcealment !=3D > InternetCodec > > > Other functionalities have been and are > > being developed such as wider audio bandwidth and stereo rendering > capability. > > CELT supports ultra-low latency audio transmission for distributed ensemb= le > performances. The only standardized codec, which fulfills this requiremen= t > is the SBC from Bluetooth SIG. But of course, the current market for > ultra-low latency audio transmission does not exist. > > > As the collection of speech and audio coding standards =E2=80=93 from I= TU and > other > > standards development organizations (SDOs) =E2=80=93 is considerable, b= efore > launching > > the standardization of a new codec leading to interoperability problems= , > ITU-T > > WP3/16 checks whether the desired codec requirements are not met by > existing > > standards. ITU-T WP3/16 regularly updates a Media Coding Summary Data > base > > (MCSD) which provides an authoritative summary of media coding standard= s > of > > ITU-T and of other SDOs such as 3GPP, 3GPP2, ISO/IEC MPEG, ETSI, etc. > > As soon the CODEC BOF participants write down requirements on the codec o= f > the CODEC group are written down, we shall send them the ITU-T SG 16. It = has > to be made sure that we did not oversaw any existing codecs, which fulfil= l > the requirements of an internet codec. > > > 3. ITU-T Standardization Process > > If market needs for a new codec are identified, the ITU-T speech and > audio > > The IETF has developed the Internet long before a market need has been > identified. Also, I do not believe that a RF codec for the Internet will > create a large market. Telephone calls over the Internet are typically fr= ee > of charge. Companies have to make money by other means but with VoIP call= s. > > > coding standardisation process has several well-defined stages from the > > specification of the Terms of Reference until the approval of the > > Recommendation. We have found over the years that this phased approach = is > > necessary to ensure a transparent process and the best possible choice = of > > technology for a particular purpose. The Terms of Reference contain the > > targeted applications, their associated design constraints and required > > performance (delay, complexity, audio bandwidth, bit rate, quality, etc= ). > The > > approval of the Recommendation is based on the review of a list of > > deliverables: text of the proposed recommendation and C-code, performan= ce > in > > terms of quality, complexity, delay, and IPR policy (RAND or RF, see > below). > > As said before, ITU-T SG 16 processes are the best. We have to look at > them... > > > In the meantime, there are several stages to thoroughly assess the > performance > > of the candidates, > > The Internet CODEC shall be available RF, which reduces the potential > income for its developers. It would be nice to have the same assessment f= or > an Internet CODEC. I doubt whether the participants and codec developers = can > afford them. > > > the quality performance being performed in close > > collaboration with SG 12, which selects the best suitable testing > > methodologies, designs the test plan and analyses the results from the > > international labs appointed by SG 12 to run the quality tests. > Currently, > > the experts in SG12 consider that subjective quality assessment based > upon > > formal listening tests in at least two languages remains the most > appropriate > > manner in which to evaluate codec performance and to guarantee > suitability of > > codecs to international use. Objective quality assessment methodologie= s > are > > only considered appropriate to compare alternative implementations of t= he > same > > codec. > > Yes, I agree. Objective quality assessment methodologies cannot replace > subjective tests. I have done some but I think it is a common understandi= ng > that the objective results are not precise and are only an indication of > quality. They cannot replace formal tests following ITU-T P.800 or ITU > BS.1534-1 procedures. > > > Besides rigorous testing, since the standardization of G.729 and G.723.= 1, > ITU- > > T speech and audio codec Recommendation specifications use C-source cod= e > in > > fixed point arithmetic as the normative algorithm description method > > (alternative floating point implementations are also provided). For old= er > > standards, reference C-source code can be found in the ITU-T Software > tool > > library (G.191 Annex A). This specification applies not only to the > encoder > > and decoder but also to example solutions (e.g. Appendices describing > packet > > loss concealment procedures). > > Once published, ITU-T speech and audio coding Recommendations with > integrated > > C-source code are freely downloadable. > > Is the ITU open source license compatible with BSD, LGPL, GPL? Maybe, > somebody who understands this license can added it to Wikipedia? > http://en.wikipedia.org/wiki/Open_source_license > > > 4. IPR Aspects > > With regard to the presence of intellectual property rights in our > standards, > > the IPR policy adopted is consistent with those of other SDOs, where on= e > must > > ensure that the standards can be implemented under either royalty free > (RF) or > > reasonable and non-discriminatory terms (RAND). Extensively deployed > ITU-T > > codecs encompass both RF and RAND policies. When the preference is RF > there > > are ITU-T codecs to address this some of which are already used in > Internet. > > Yes, but they do not fulfill the technical requirements of an internet > CODEC. > > > 5. Participation in ITU-T Work > > As a final observation, we would like to inform you that 191 countries > (Member > > States) and over 700 companies of all sizes are members of ITU. There a= re > many > > means to enable participation of non-ITU members in our standardization > work. > > One tool is the participation sponsored by existing members, such as a > Member > > State; we could cite the example of a university and later its spin-off > > company in North-America that for many years used that mechanism before > > becoming a member, and was able to successfully contribute to the > development > > of various existing Recommendations. > > Yes, I agree. At least in Germany it is easy for an university employee t= o > join the German ITU delegation. I have done this a couple of times joinin= g > SG12. > > > Another possibility commonly used is > > participation at meetings as invited experts. The secretariat at > > tsbsg16@itu.int is available to provide details to interested parties. > > 6. Proposal > > In conclusion, we would be very happy to work with you, we will be glad > to > > review any requirements you might develop for an =E2=80=9CInternet wide= band > codec=E2=80=9D and > > discuss possible ways to meet them. > > Yes, I agree. We shall consider the offer to review the requirements - as > soon as they have been written done. I think it would be very useful. > > Thank you > Christian Hoene > > > > > -------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=C3=BCbingen > > Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of > > Cullen Jennings > > Sent: Tuesday, July 14, 2009 6:38 PM > > To: codec@ietf.org > > Cc: Gregory Lebovitz > > Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting > (10 > > July 2009) > > > > > > I just received this Liaison from the ITU. I wanted to forward it on so > people > > could see it ASAP. If there are problems with attachments, let me know > and I > > will get them posted to a site where people can get them. > > > > Cullen > > > > > > Begin forwarded message: > > > > > > From: > > Date: July 14, 2009 7:51:01 AM PDT > > To: , , > > Cc: , > > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 200= 9) > > > > > > Kindly find attached the Liaison Statement COM16 - LS 71 on "informatio= n > on > > ITU-T Speech and audio coding standardisation" addressed to IESG and > IETF-RAI > > agreed at the ITU-T WP2/16 meeting (10 July 2009). > > Please take note that we are sending herewith the word version as well = as > the > > pdf version of the LS. In addition, there is an attachment, which is i= n > > excel. Since it is quite complex with different sheets, we preferred t= o > keep > > the excel file in the original version. > > > > <> <> < MCSD-Database- > > V20081003.xls>> > > > > Best regards, > > Rosa Angeles-Le=C3=B3n de Vivero > > Assistant for ITU-T Study Group 16 > > ITU - Telecommunication Standardization Bureau (TSB) > > SG 16 e-mail: tsbsg16@itu.int > > Tel. 41-22 730 5445 > > Fax 41-22 730 5853 > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636b4313d965c5b046ebd0dd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I share your view that the ITU-T testing processes are first rate, and that= we do need to take an objective look at their current approach.

I a= m curious as to why you are focused on TCP as the transport.=C2=A0 I'd = think that anything the working group does would be carried on RTP, which c= an use either TCP or UDP, but generally uses UDP for most speech applicatio= ns.

As far as packet rate, that is usually specified in the RTP packetizati= on RFC, not in the codec spec itself.=C2=A0=C2=A0 At present, the ITU-T is = deferring to the IETF, and not specifying the RTP packetization in their re= commendations.=C2=A0 Though generally they do amend the recommendation to i= nclude a reference to the appropriate RFC after it is published.

I'd think that there would still need to be 2 specs - the RFC for = the codec itself, and a separate RFC for RTP/SIP, done through AVT.

= Some more dicussion on specific requirements that are not in the ITU-T code= cs but which are desired in the "internet codec" would be fruitfu= l, as I agree that this proposed group (when and it) should have different = goals from other SDOs.=C2=A0 Ideally these goals would be broader than the = attributes of SILK or CELT, since it is reasonable to assume that this grou= p would go on to standardize more codecs (being re-chartered as necessary).= =C2=A0 IPR terms alone are not enough (in my view). to justify yet another = codec standardization group.=C2=A0

BTW, I don't think the ITU-T folks would agree that their codecs ar= e "circuit switched", I think they would argue strongly that they= are already standardizing codecs that are suitable for the internet.=C2=A0= If there are requirements that they are missing, that would be a strong en= ough "market" statement for the ITU-T.=C2=A0 They want to be sure= there is an application for the codec that current codecs don't satisf= y.=C2=A0 They aren't particularly concerned with how large that market = is, they just want assurance that there is one.

Regards,
Stephen Botzko
Polycom

On Wed, Jul 15, 2009 at 5:56 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
Hello,

I have copied the liaison statement into this email to comment it.

> Question(s): =C2=A08, 9, 10/16 =C2=A0 =C2=A0 Geneva, 10 July 2009
> LIAISON STATEMENT
> Source: =C2=A0 =C2=A0 =C2=A0 ITU-T SG 16 =E2=80=93 Q8, 9, 10/16
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0LS to IESG and IETF-RAI on informati= on on ITU-T Speech and audio coding
> standardisation
> LIAISON STATEMENT
> For action to: =C2=A0 =C2=A0 =C2=A0 =C2=A0-
> For comment to: =C2=A0 =C2=A0 =C2=A0 -
> For information to: =C2=A0 IESG, IETF-RAI
> Approval: =C2=A0 =C2=A0 ITU-T WP 3/16 meeting (Geneva, 10 July 2009) > Deadline: =C2=A0 =C2=A0 N/A
> Contact: =C2=A0 =C2=A0 =C2=A0Ms Claude Lamblin
> France Telecom Orange
> France =C2=A0 =C2=A0 =C2=A0 =C2=A0Tel: =C2=A0 =C2=A0+33 2 96 05 13 03<= br> > Fax: =C2=A0+33 2 96 05 35 30
> Email: =C2=A0 =C2=A0 =C2=A0 =C2=A0claude.lamblin@orange-ftgroup.com
>
>
> 1. =C2=A0 =C2=A0Introduction
> It has been brought to our attention that within IETF, the creation of= a new
> IETF working group to define a wideband audio codec specifically for u= se with
> the Internet has been recently proposed. We observed that the initial = proposal
> was followed by discussions on the IETF email reflector codec@ietf.org and
> that during these discussions, references to ITU-T speech and audio co= ding
> work were often made.
> Despite the intervention of some individuals familiar with ITU-T
> standardisation work, we regrettably observe that there are still seve= ral
> misconceptions and out-of-date understanding of the current state of t= he
> speech and audio coding work in ITU-T.

I am reactivating my TIES account to get a detailed understanding of the cu= rrent state of the work. I agree, it is a must. Having read the documents s= uggested during the discussion on this mailing list, I have to agree that i= n the last years the ITU-T SG16 and the 3GPP have made substantial progress= towards a codec, which is more better suited for the Internet. However, st= ill a number of issues have not been addresses, yet.

> We see as paramount that any decisions
> to be taken in the upcoming IETF meeting be taken on a sound basis, th= erefore
> ITU-T WP3/16 would like to offer the following information on ITU-T sp= eech and
> audio coders and its standardization process, in order to help allay s= ome of
> the observed misconceptions.
> 2. =C2=A0 =C2=A0Speech and Audio Coding Standards
> The ITU-T audio/speech codecs portfolio (see table below) is quite sig= nificant
> covering a wide range of audio bandwidths and bit rates, offering diff= erent
> trade-offs to address various applications with different requirements= (on
> quality, bit rates, complexity, robustness, delay).

TCP, the main transportation protocol on the Internet, works on any link re= gardless whether it has a capacity of one 1 packet per second or one millio= n. One reason for the success of TCP is that is can be used on any kind of = device. No matter whether it is a 8bit processor or powerful mainframe.
I am wondering, why it is not possible to have a codec, which works on a wi= de range of different network conditions and on a wide range of devices. Ma= ybe a combination of SILK and CELT can fulfill this dream?

> Audio Bandwidth [kHz] Sampling frequency [Hz] Bit rates [kbit/s] =C2= =A0 =C2=A0 =C2=A0ITU-T
> G.7xx-series
> 300-3400 (narrowband) 8000 =C2=A0 =C2=A05.3 =EF=82=AE 80 =C2=A0 =C2=A0= =C2=A0 =C2=A0G.711, G.726, G.727, G.728,
> G.729, G.723.1, G.729.1, G.711.1, G.718
> 50-7000 (wideband) =C2=A0 =C2=A016000 =C2=A0 6.6 =EF=82=AE 96 =C2=A0 = =C2=A0 =C2=A0 =C2=A0G.722, G.722.1, G.722.2, G.729.1,
> G.711.1, G.718
> 50-14000 (superwideband) =C2=A0 =C2=A0 =C2=A032000 =C2=A0 24 =EF=82=AE= 48 G.722.1C
> 20-20000 (fullband) =C2=A0 48000 =C2=A0 32 =EF=82=AE 128 =C2=A0 =C2=A0= =C2=A0 =C2=A0G.719

One important criteria for Internet based transmissions is the packet rate = (TCP controls the number of packets per round trip time, not the bit rate o= f user data). This important parameter is missing in the table.

> Conversational applications are the primary applications
> and there has been an
> evolution from circuit-switched voice applications (e.g. PSTN and circ= uit
> multiplication equipment) to packet-based multimedia (notably IP).

To my understanding the goals of the proposed working group are to develop = a codec that should be optimized thwarts the Internet. The support of class= ic PSTN networks is of lower importance.

We need a clear cut between the traditions of a circuit switched codec desi= gn and the work which shall be done here. A disruptive technology having di= fferent goals has to be developed. The evolution approach followed by the I= TU might not allow a clean slate approach.

> ITU-T coders are extensively deployed and their modern applications go= beyond
> the constraints for which the codecs were initially targeted.

I do have the opinion that ITU_T make the most perfect codecs. But can ever= y Internet user afford to license them?

> Therefore, ITU-T has extended these coders with new features to provid= e quick responses to
> customer demands and to cope with new constraints of those modern
> applications.
> For instance, Appendices to G.711 and G.722 =E2=80=93 coders initially=
> designed for PSTN and ISDN, respectively, provide Packet Loss Concealm= ent
> (PLC) procedures to cope with packet losses that can occur during tran= smission
> over IP and other packet networks.

In my opinion, the requirements of an Internet codec, which is not equivale= nt to a codec for packet networks, are not fulfilled if PLC is added a circ= uit switched codec. The technical requirements listed in the SILK draft are= an example of requirements beyond PLC.
Or to say it easier: CircuitSwitchedCodec + PacketLossConcealment !=3D Inte= rnetCodec

> Other functionalities have been and are
> being developed such as wider audio bandwidth and stereo rendering cap= ability.

CELT supports ultra-low latency audio transmission for distributed ensemble= performances. The only standardized codec, which fulfills this requirement= is the SBC from Bluetooth SIG. But of course, the current market for ultra= -low latency audio transmission does not exist.

> As the collection of speech and audio coding standards =E2=80=93 from = ITU and other
> standards development organizations (SDOs) =E2=80=93 is considerable, = before launching
> the standardization of a new codec leading to interoperability problem= s, ITU-T
> WP3/16 checks whether the desired codec requirements are not met by ex= isting
> standards. =C2=A0ITU-T WP3/16 regularly updates a Media Coding Summary= Data base
> (MCSD) which provides an authoritative summary of media coding standar= ds of
> ITU-T and of other SDOs such as 3GPP, 3GPP2, ISO/IEC MPEG, ETSI, etc.<= br>
As soon the CODEC BOF participants write down requirements on the codec of = the CODEC group are written down, we shall send them the ITU-T SG 16. It ha= s to be made sure that we did not oversaw any existing codecs, which fulfil= l the requirements of an internet codec.

> 3. =C2=A0 =C2=A0ITU-T Standardization Process
> If market needs for a new codec are identified, the ITU-T speech and a= udio

The IETF has developed the Internet long before a market need has been iden= tified. Also, I do not believe that a RF codec for the Internet will create= a large market. Telephone calls over the Internet are typically free of ch= arge. Companies have to make money by other means but with VoIP calls.

> coding standardisation process has several well-defined stages from th= e
> specification of the Terms of Reference until the approval of the
> Recommendation. We have found over the years that this phased approach= is
> necessary to ensure a transparent process and the best possible choice= of
> technology for a particular purpose. The Terms of Reference contain th= e
> targeted applications, their associated design constraints and require= d
> performance (delay, complexity, audio bandwidth, bit rate, quality, et= c). The
> approval of the Recommendation is based on the review of a list of
> deliverables: text of the proposed recommendation and C-code, performa= nce in
> terms of quality, complexity, delay, and IPR policy (RAND or RF, see b= elow).

As said before, ITU-T SG 16 processes are the best. We have to look at them= ...

> In the meantime, there are several stages to thoroughly assess the per= formance
> of the candidates,

The Internet CODEC shall be available RF, which reduces the potential incom= e for its developers. It would be nice to have the same assessment for an I= nternet CODEC. I doubt whether the participants and codec developers can af= ford them.

> the quality performance being performed in close
> collaboration with SG 12, which selects the best suitable testing
> methodologies, designs the test plan and analyses the results from the=
> international labs appointed by SG 12 to run the quality tests. =C2=A0= Currently,
> the experts in SG12 consider that subjective quality assessment based = upon
> formal listening tests in at least two languages remains the most appr= opriate
> manner in which to evaluate codec performance and to guarantee suitabi= lity of
> codecs to international use. =C2=A0Objective quality assessment method= ologies are
> only considered appropriate to compare alternative implementations of = the same
> codec.

Yes, I agree. Objective quality assessment methodologies cannot replace sub= jective tests. I have done some but I think it is a common understanding th= at the objective results are not precise and are only an indication of qual= ity. They cannot replace formal tests following ITU-T P.800 or ITU BS.1534-= 1 procedures.

> Besides rigorous testing, since the standardization of G.729 and G.723= .1, ITU-
> T speech and audio codec Recommendation specifications use C-source co= de in
> fixed point arithmetic as the normative algorithm description method > (alternative floating point implementations are also provided). For ol= der
> standards, reference C-source code can be found in the ITU-T Software = tool
> library (G.191 Annex A). =C2=A0This specification applies not only to = the encoder
> and decoder but also to example solutions (e.g. Appendices describing = packet
> loss concealment procedures).
> Once published, ITU-T speech and audio coding Recommendations with int= egrated
> C-source code are freely downloadable.

Is the ITU open source license compatible with BSD, LGPL, GPL? Maybe, someb= ody who understands this license can added it to Wikipedia? http://en.w= ikipedia.org/wiki/Open_source_license

> 4. =C2=A0 =C2=A0IPR Aspects
> With regard to the presence of intellectual property rights in our sta= ndards,
> the IPR policy adopted is consistent with those of other SDOs, where o= ne must
> ensure that the standards can be implemented under either royalty free= (RF) or
> reasonable and non-discriminatory terms (RAND). Extensively deployed I= TU-T
> codecs encompass both RF and RAND policies. When the preference is RF = there
> are ITU-T codecs to address this some of which are already used in Int= ernet.

Yes, but they do not fulfill the technical requirements of an internet CODE= C.

> 5. =C2=A0 =C2=A0Participation in ITU-T Work
> As a final observation, we would like to inform you that 191 countries= (Member
> States) and over 700 companies of all sizes are members of ITU. There = are many
> means to enable participation of non-ITU members in our standardizatio= n work.
> One tool is the participation sponsored by existing members, such as a= Member
> State; we could cite the example of a university and later its spin-of= f
> company in North-America that for many years used that mechanism befor= e
> becoming a member, and was able to successfully contribute to the deve= lopment
> of various existing Recommendations.

Yes, I agree. At least in Germany it is easy for an university employee to = join the German ITU delegation. I have done this a couple of times joining = SG12.

> Another possibility commonly used is
> participation at meetings as invited experts. The secretariat at
> tsbsg16@itu.int is available to= provide details to interested parties.
> 6. =C2=A0 =C2=A0Proposal
> In conclusion, we would be very happy to work with you, we will be gla= d to
> review any requirements you might develop for an =E2=80=9CInternet wid= eband codec=E2=80=9D and
> discuss possible ways to meet them.

Yes, I agree. We shall consider the offer to review the requirements - as s= oon as they have been written done. I think it would be very useful.

Thank you
=C2=A0Christian Hoene

>
> --------------------------------------------------------
> Dr.-Ing. Christian Hoene
> Interactive Communication Systems (ICS), University of T=C3=BCbingen > Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532
> http://= www.net.uni-tuebingen.de/
>
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On Behalf Of
> Cullen Jennings
> Sent: Tuesday, July 14, 2009 6:38 PM
> To: codec@ietf.org
> Cc: Gregory Lebovitz
> Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meetin= g (10
> July 2009)
>
>
> I just received this Liaison from the ITU. I wanted to forward it on s= o people
> could see it ASAP. If there are problems with attachments, let me know= and I
> will get them posted to a site where people can get them.
>
> Cullen
>
>
> Begin forwarded message:
>
>
> From: <tsbsg16@itu.int> > Date: July 14, 2009 7:51:01 AM PDT
> To: <housley@vigilsec.com>, <fluffy@cisco.com>, &= lt;statements@ietf.org>
> Cc: <simao.campos@itu.int>, <claude.lam= blin@orange-ftgroup.com>
> Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 20= 09)
>
>
> Kindly find attached the Liaison Statement COM16 - LS 71 on "info= rmation on
> ITU-T Speech and audio coding standardisation" addressed to IESG = and IETF-RAI
> agreed at the ITU-T WP2/16 meeting (10 July 2009).
> Please take note that we are sending herewith the word version as well= as the
> pdf version of the LS. =C2=A0In addition, there is an attachment, whic= h is in
> excel. =C2=A0Since it is quite complex with different sheets, we prefe= rred to keep
> the excel file in the original version.
>
> =C2=A0 =C2=A0 <<ls071-16.doc>> <<ls071-16.pdf>>= ; <<ls071_Att.1_Copy of MCSD-Database-
> V20081003.xls>>
>
> Best regards,
> Rosa Angeles-Le=C3=B3n de Vivero
> Assistant for ITU-T Study Group 16
> ITU - Telecommunication Standardization Bureau (TSB)
> SG 16 e-mail: tsbsg16@itu.int > Tel. =C2=A041-22 730 5445
> Fax 41-22 730 5853


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

--001636b4313d965c5b046ebd0dd8-- From patrick.luthi@tandberg.no Wed Jul 15 06:30:38 2009 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 C76823A6BA5 for ; Wed, 15 Jul 2009 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 E23Ky8-fvWYr for ; Wed, 15 Jul 2009 06:30:36 -0700 (PDT) Received: from smtp-02.vtx.ch (smtp-02.vtx.ch [212.147.0.114]) by core3.amsl.com (Postfix) with ESMTP id 203D13A6AB8 for ; Wed, 15 Jul 2009 06:30:36 -0700 (PDT) Received: from suisse127.vtxnet.ch (dyn.144-85-144-039.dsl.vtx.ch [144.85.144.39]) by smtp-02.vtx.ch (VTX Services SA) with ESMTP id 03BF85FED6 for ; Wed, 15 Jul 2009 15:30:12 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 15:30:10 +0200 To: codec@ietf.org From: Patrick Luthi Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_451445921==.ALT" Message-Id: <20090715133013.03BF85FED6@smtp-02.vtx.ch> Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 13:30:38 -0000 --=====================_451445921==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I agree with the different postings requesting to not have any codec presentations during the upcoming BoF. It will be interesting, instead, to have a discussion on requirements and codec selection and how a future WG will define such requirements and selection process. From reading the mailing list, one of the key requirements is patent/licensing free technology. How will such requirement be enforced and how will the WG handle the case where IPR would appear during last call or just after the RFC is published? Best regards, Patrick At 23:15 10/07/2009, stephen botzko wrote: >I think this presentation concept is better than a codec >description. It would naturally form a framework for the following >discussion. Though I still think it needs to be short (no more than >10 minutes), and it should be clear to all that it represents just >one view of how it might be done. > >As far as codec developers goes, it is hopefully obvious to everyone >(pro and con) that there are quite a few individuals and >organizations participating in the IETF that have considerable >expertise in codec development. I'm sure several also have >experience with the codec characterization/quality testing Roni >mentions. Though I think getting this kind of testing in place will >require quite a bit of work - my assessment is that it is probably >more work than standardizing the first codec. Getting agreement on >the methodologies, the speech samples to use, etc. will take time and effort. > >Regards, >Stephen Botzko >Polycom > > > > >On Fri, Jul 10, 2009 at 4:56 PM, Roni Even ><ron.even.tlv@gmail.com> wrote: >Jason, >If you want to describe the type of work that will be done in the working >group it will be better to have a presentation on how you will define >requirements, test the quality and select a codec, how it is done in other >bodies and why should the IETF do it. >My current view based on the lack of any agreed requirements is that every >wide band codec is a good candidate including ones that were done by other >standard bodies. So to present just two do not have any value and may have >some bias, mostly since it is the ones suggested by the BOF chairs. If you >want to present codecs, I can probably present the list of all existing >codecs based on a list that is kept by the ITU. >As for showing that there are people capable of evaluating codecs in the >IETF, note that I did not say design but evaluate the process by which a >codec will be selected and evaluate the maturity of the proposal, I am not >sure that except for the proponent there are any others who have enough >experience in codec design and quality testing. I think that this is one of >the topics to be discussed since one of the conclusion of the iLBC work that >there is not enough such expertise. >Roni Even > > -----Original Message----- > > From: Jason Fischl [mailto:jason.fischl@skype.net] > > Sent: Friday, July 10, 2009 8:38 PM > > To: Roni Even > > Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S'; > > 'Slava Borilin'; codec@ietf.org > > Subject: Re: [codec] Updated Agenda for Codec BOF > > > > The point of briefly presenting a few codecs is to show the type of > > work that would be done in the working group and to address the > > feasibility of the goal. It is not to present the issues with the > > particular codecs or even the details of the codecs. There have been > > assertions on the list that the IETF lacks the expertise to do this > > work. This agenda item attempts to address that concern. > > > > I'd also like to encourage other people to post to the list with their > > opinions on whether or not agenda item 4 (codecs) should be included. > > > > As Stephen suggests, Jean-Marc and I will arrange for a lunch codec > > tutorial session prior to the BOF on Wednesday or Thursday. > > > > Jason > > > > > > On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > > > > > Hi, > > > I still fail to see what is the value in presenting one, two or three > > > codecs. I saw that there was a request to present a third one. > > > I can agree that there are people who can present codecs as a > > > suggested > > > solution including existing ones. Since there is no charter yet > > > under which > > > the codecs are to be specified it may serve as a tutorial on codecs. > > > So if > > > we open to codec presentation in the BOF let allow everyone to > > > present their > > > codecs including ITU and MPEG ones and spend the whole BOF of the > > > different > > > codecs technologies. > > > If the idea behind this presentation is to show specific > > > functionality than > > > instead it will be more fruitful to present requirements, since I > > > could see > > > from the list discussion that there is no consensus even between the > > > current > > > proponents what the requirements are. > > > > > > Roni Even > > > > > >> -----Original Message----- > > >> From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On > > >> Behalf > > >> Of Peter Saint-Andre > > >> Sent: Friday, July 10, 2009 5:46 PM > > >> To: stephen botzko > > >> Cc: Ingemar Johansson S; Slava Borilin; > codec@ietf.org > > >> Subject: Re: [codec] Updated Agenda for Codec BOF > > >> > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> On 7/10/09 5:26 AM, stephen botzko wrote: > > >>> Sorry to disagree on this. > > >>> > > >>> - A 25 minute presentation is not "short" in a 2 hour meeting. 5 > > >>> minutes would be short. > > >>> - SILK and CELT are well known, and can be studied/reviewed by > > >>> anyone > > >>> interested off-line. > > >>> > > >>> The net effect of a 25 minute codec presentation by WG proponents > > is > > >> to > > >>> remove 25 minutes of discussoin time. A second effect is that it > > >> biases > > >>> the time allotment in favor of proponents, which acts to skew the > > >> input > > >>> to IESG in that direction. Arguments against are just as important > > >>> as > > >>> arguments for at this point in the process. > > >>> > > >>> Perhaps a compromise is possible? Move item 4 to the _end_ of the > > >>> agenda, and make it the "time permits" activity? > > >> > > >> How about 5 minutes to discuss each of the codec I-Ds at a high > > >> level? > > >> Allotting 10 minutes out of 2 hours to existence proofs and what > > they > > >> imply for the work of the Codec WG (if approved) seems helpful to > > me. > > >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can > > >> productively talk about how these codecs could be used as input to a > > >> working group. > > >> > > >> Peter > > >> > > >> - -- > > >> Peter Saint-Andre > > >> https://stpeter.im/ > > >> > > >> > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG v1.4.8 (Darwin) > > >> Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > >> > > >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 > > >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV > > >> =bx98 > > >> -----END PGP SIGNATURE----- > > >> > > >> _______________________________________________ > > >> 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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --=====================_451445921==.ALT Content-Type: text/html; charset="us-ascii" Hi,

I agree with the different postings requesting to not have any codec presentations during the upcoming BoF. It will be interesting, instead, to have a discussion on requirements and codec selection and how a future WG will define such requirements and selection process.

From reading the mailing list, one of the key requirements is patent/licensing free technology. How will such requirement be enforced and how will the WG handle the case where IPR would appear during last call or just after the RFC is published?

Best regards,

Patrick

At 23:15 10/07/2009, stephen botzko wrote:
I think this presentation concept is better than a codec description.  It would naturally form a framework for the following discussion.  Though I still think it needs to be short (no more than 10 minutes), and it should be clear to all that it represents just one view of how it might be done.

As far as codec developers goes, it is hopefully obvious to everyone (pro and con) that there are quite a few individuals and organizations participating in the IETF that have considerable expertise in codec development.  I'm sure several also have experience with the codec characterization/quality testing Roni mentions.  Though I think getting this kind of testing in place will require quite a bit of work - my assessment is that it is probably more work than standardizing the first codec.  Getting agreement on the methodologies, the speech samples to use, etc. will take time and effort.

Regards,
Stephen Botzko
Polycom




On Fri, Jul 10, 2009 at 4:56 PM, Roni Even <ron.even.tlv@gmail.com > wrote:
Jason,
If you want to describe the type of work that will be done in the working
group it will be better to have a presentation on how you will define
requirements, test the quality and select a codec, how it is done in other
bodies and why should the IETF do it.
My current view based on the lack of any agreed requirements is that every
wide band codec is a good candidate including ones that were done by other
standard bodies. So to present just two do not have any value and may have
some bias, mostly since it is the ones suggested by the BOF chairs. If you
want to present codecs, I can probably present the list of all existing
codecs based on a list that is kept by the ITU.
As for showing that there are people capable of evaluating codecs in the
IETF, note that I did not say design but evaluate the process by which a
codec will be selected and evaluate the maturity of the proposal, I am not
sure that except for the proponent there are any others who have enough
experience in codec design and quality testing. I think that this is one of
the topics to be discussed since one of the conclusion of the iLBC work that
there is not enough such expertise.
Roni Even
> -----Original Message-----
> From: Jason Fischl [ mailto:jason.fischl@skype.net]
> Sent: Friday, July 10, 2009 8:38 PM
> To: Roni Even
> Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S';
> 'Slava Borilin'; codec@ietf.org
> Subject: Re: [codec] Updated Agenda for Codec BOF
>
> The point of briefly presenting a few codecs is to show the type of
> work that would be done in the working group and to address the
> feasibility of the goal. It is not to present the issues with the
> particular codecs or even the details of the codecs. There have been
> assertions on the list that the IETF lacks the expertise to do this
> work. This agenda item attempts to address that concern.
>
> I'd also like to encourage other people to post to the list with their
> opinions on whether or not agenda item 4 (codecs) should be included.
>
> As Stephen suggests, Jean-Marc and I will arrange for a lunch codec
> tutorial session prior to the BOF on Wednesday or Thursday.
>
> Jason
>
>
> On Jul 10, 2009, at 9:43 AM, Roni Even wrote:
>
> > Hi,
> > I still fail to see what is the value in presenting one, two or three
> > codecs. I saw that there was a request to present a third one.
> > I can agree that there are people who can present codecs as a
> > suggested
> > solution including existing ones. Since there is no charter yet
> > under which
> > the codecs are to be specified it may serve as a tutorial on codecs.
> > So if
> > we open to codec presentation in the BOF let allow everyone to
> > present their
> > codecs including ITU and MPEG ones and spend the whole BOF of the
> > different
> > codecs technologies.
> > If the idea behind this presentation is to show specific
> > functionality than
> > instead it will be more fruitful to present requirements, since I
> > could see
> > from the list discussion that there is no consensus even between the
> > current
> > proponents what the requirements are.
> >
> > Roni Even
> >
> >> -----Original Message-----
> >> From: codec-bounces@ietf.org [ mailto:codec-bounces@ietf.org] On
> >> Behalf
> >> Of Peter Saint-Andre
> >> Sent: Friday, July 10, 2009 5:46 PM
> >> To: stephen botzko
> >> Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org
> >> Subject: Re: [codec] Updated Agenda for Codec BOF
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 7/10/09 5:26 AM, stephen botzko wrote:
> >>> Sorry to disagree on this.
> >>>
> >>> - A 25 minute presentation is not "short" in a 2 hour meeting.  5
> >>> minutes would be short.
> >>> - SILK and CELT are well known, and can be studied/reviewed by
> >>> anyone
> >>> interested off-line.
> >>>
> >>> The net effect of a 25 minute codec presentation by WG proponents
> is
> >> to
> >>> remove 25 minutes of discussoin time.  A second effect is that it
> >> biases
> >>> the time allotment in favor of proponents, which acts to skew the
> >> input
> >>> to IESG in that direction. Arguments against are just as important
> >>> as
> >>> arguments for at this point in the process.
> >>>
> >>> Perhaps a compromise is possible?  Move item 4 to the _end_ of the
> >>> agenda, and make it the "time permits" activity?
> >>
> >> How about 5 minutes to discuss each of the codec I-Ds at a high
> >> level?
> >> Allotting 10 minutes out of 2 hours to existence proofs and what
> they
> >> imply for the work of the Codec WG (if approved) seems helpful to
> me.
> >> Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can
> >> productively talk about how these codecs could be used as input to a
> >> working group.
> >>
> >> Peter
> >>
> >> - --
> >> Peter Saint-Andre
> >> https://stpeter.im/
> >>
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.8 (Darwin)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>
> >> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2
> >> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV
> >> =bx98
> >> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> 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

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec --=====================_451445921==.ALT-- From patrick.luthi@tandberg.no Wed Jul 15 06:50:09 2009 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 826C63A6AB8 for ; Wed, 15 Jul 2009 06:50:09 -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=[AWL=0.001, BAYES_00=-2.599, 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 mvVV6qHIyOAk for ; Wed, 15 Jul 2009 06:50:07 -0700 (PDT) Received: from smtp-03.vtx.ch (smtp-03.vtx.ch [212.147.0.64]) by core3.amsl.com (Postfix) with ESMTP id 87B533A68B9 for ; Wed, 15 Jul 2009 06:50:07 -0700 (PDT) Received: from suisse127.vtxnet.ch (dyn.144-85-144-039.dsl.vtx.ch [144.85.144.39]) by smtp-03.vtx.ch (VTX Services SA) with ESMTP id 57D95296EC0 for ; Wed, 15 Jul 2009 15:49:29 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 15:49:27 +0200 To: codec@ietf.org From: Patrick Luthi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090715134929.57D95296EC0@smtp-03.vtx.ch> Subject: Re: [codec] Updated Agenda for Codec BOF. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 13:50:09 -0000 Hi Jason, I think that there should be no presentations on codecs as it is too early at the stage where the key is to discuss (and allow plenty of time) wether to create a WG or not. Therefore, please remove item 4 of the agenda! I would suggest that you replace the codec presentation by a discussion on the requirement definition and the codec selection processes. This would help be better understand how the proposed WG positions itself differently from standardization work done elsewhere. Best regards, Patrick At 19:37 10/07/2009, Jason Fischl wrote: >The point of briefly presenting a few codecs is to show the type of >work that would be done in the working group and to address the >feasibility of the goal. It is not to present the issues with the >particular codecs or even the details of the codecs. There have been >assertions on the list that the IETF lacks the expertise to do this >work. This agenda item attempts to address that concern. > >I'd also like to encourage other people to post to the list with their >opinions on whether or not agenda item 4 (codecs) should be included. > >As Stephen suggests, Jean-Marc and I will arrange for a lunch codec >tutorial session prior to the BOF on Wednesday or Thursday. > >Jason > > >On Jul 10, 2009, at 9:43 AM, Roni Even wrote: > >>Hi, >>I still fail to see what is the value in presenting one, two or three >>codecs. I saw that there was a request to present a third one. >>I can agree that there are people who can present codecs as a >>suggested >>solution including existing ones. Since there is no charter yet >>under which >>the codecs are to be specified it may serve as a tutorial on codecs. >>So if >>we open to codec presentation in the BOF let allow everyone to >>present their >>codecs including ITU and MPEG ones and spend the whole BOF of the >>different >>codecs technologies. >>If the idea behind this presentation is to show specific >>functionality than >>instead it will be more fruitful to present requirements, since I >>could see >>from the list discussion that there is no consensus even between the >>current >>proponents what the requirements are. >> >>Roni Even >> >>>-----Original Message----- >>>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>>Behalf >>>Of Peter Saint-Andre >>>Sent: Friday, July 10, 2009 5:46 PM >>>To: stephen botzko >>>Cc: Ingemar Johansson S; Slava Borilin; codec@ietf.org >>>Subject: Re: [codec] Updated Agenda for Codec BOF >>> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>On 7/10/09 5:26 AM, stephen botzko wrote: >>>>Sorry to disagree on this. >>>> >>>>- A 25 minute presentation is not "short" in a 2 hour meeting. 5 >>>>minutes would be short. >>>>- SILK and CELT are well known, and can be studied/reviewed by >>>>anyone >>>>interested off-line. >>>> >>>>The net effect of a 25 minute codec presentation by WG proponents is >>>to >>>>remove 25 minutes of discussoin time. A second effect is that it >>>biases >>>>the time allotment in favor of proponents, which acts to skew the >>>input >>>>to IESG in that direction. Arguments against are just as important >>>>as >>>>arguments for at this point in the process. >>>> >>>>Perhaps a compromise is possible? Move item 4 to the _end_ of the >>>>agenda, and make it the "time permits" activity? >>> >>>How about 5 minutes to discuss each of the codec I-Ds at a high >>>level? >>>Allotting 10 minutes out of 2 hours to existence proofs and what they >>>imply for the work of the Codec WG (if approved) seems helpful to me. >>>Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can >>>productively talk about how these codecs could be used as input to a >>>working group. >>> >>>Peter >>> >>>- -- >>>Peter Saint-Andre >>>https://stpeter.im/ >>> >>> >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.4.8 (Darwin) >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>>iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2 >>>TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV >>>=bx98 >>>-----END PGP SIGNATURE----- >>> >>>_______________________________________________ >>>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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Wed Jul 15 07:29:46 2009 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 5CBCB3A6A30 for ; Wed, 15 Jul 2009 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 aLIIMynFrMRh for ; Wed, 15 Jul 2009 07:29:45 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id A62313A68A6 for ; Wed, 15 Jul 2009 07:29:22 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:54:48 -0400 Message-ID: <4A5DDFA8.7070701@octasic.com> Date: Wed, 15 Jul 2009 09:54:48 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: stephen botzko References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> In-Reply-To: <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jul 2009 13:54:48.0793 (UTC) FILETIME=[D173C490:01CA0553] Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:29:46 -0000 Hi Stephen, stephen botzko wrote: > I'd think that there would still need to be 2 specs - the RFC for the > codec itself, and a separate RFC for RTP/SIP, done through AVT. I totally agree on this. Codecs and transport are two different things. That's why both SILK and CELT have separate drafts for the codec and the RTP profile. Of course, the codecs can (and should) be designed in parallel with the RTP profile to make sure they work well with the RTP/SIP/SDP stack. > Some more dicussion on specific requirements that are not in the ITU-T > codecs but which are desired in the "internet codec" would be fruitful, > as I agree that this proposed group (when and it) should have different > goals from other SDOs. Ideally these goals would be broader than the > attributes of SILK or CELT, since it is reasonable to assume that this > group would go on to standardize more codecs (being re-chartered as > necessary). IPR terms alone are not enough (in my view). to justify > yet another codec standardization group. In my opinion, IPR alone would be sufficient. But at the same time I agree that if we're going to standardise codecs, they might as well be targeted specifically for the Internet. The goals of MPEG and ITU-T are very different and I would expect this WG to have goals that are different from both. Cheers, Jean-Marc From herve.taddei@huawei.com Wed Jul 15 08:11:14 2009 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 C2BCB28C0F0 for ; Wed, 15 Jul 2009 08:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 Wo4-IqWaoY5p for ; Wed, 15 Jul 2009 08:11:13 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id 762DF28C0E5 for ; Wed, 15 Jul 2009 08:11:13 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMT001MSWJCZ8@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 15 Jul 2009 16:04:25 +0100 (BST) Received: from PCHERVE ([10.200.70.57]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMT00NUSWJB53@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 15 Jul 2009 16:04:24 +0100 (BST) Date: Wed, 15 Jul 2009 17:04:25 +0200 From: Herve Taddei In-reply-to: <4A5DDFA8.7070701@octasic.com> To: codec@ietf.org Message-id: <003a01ca055d$8b7d42e0$3946c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8EWTrEu5M3wWGotqv9v4SQ)" Thread-index: AcoFWaOxWpen5OjjRdKUBCyhQkSs3AAAKfRQ References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:11:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8EWTrEu5M3wWGotqv9v4SQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Dear Jean-Marc, =20 > that if we're going to standardise codecs, they might as well be = targeted > specifically for the Internet. The goals of MPEG and ITU-T are very different > and I would expect this WG to have goals that are different from both. =20 It would be good that you clarify what you call a codec specifically designed for Internet. In ITU-T and 3GPP they have codecs that seem to = be adequate for VoIP, see G.711, G.729. Speex Narrowband for example was = not very different to G.729/AMR in the principle, it is some kind of CELP = codec as you well know. Is that what you call a codec for Internet? BTW, is = Speex WB a codec for Internet? =20 It is something I am trying to understand from the different emails, but = so far I have not succeeded. The only thing I could assume is that what you call an Internet codec is a RF codec. In that case G.711, G.722, G.722.1 = and G.722.1C (and soon SBC if I understood well the previous emails) and certainly some other codecs will be =93Internet=94 codecs according to = my understanding of your definition. Is my understanding correct? Is the = only requirement? Are there technical requirements? I would appreciate if you could clarify. =20 Best regards =20 Herv=E9 =20 =20 =20 --Boundary_(ID_8EWTrEu5M3wWGotqv9v4SQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Dear Jean-Marc,

 

> that if we're going to standardise codecs, they = might as well be targeted

> specifically for the Internet. The goals of = MPEG and ITU-T are very different

> and I would expect this WG to have goals that = are different from both.

 

It would be = good that you clarify what you call a codec specifically designed for Internet. In = ITU-T and 3GPP they have codecs that seem to be adequate for VoIP, see G.711, = G.729. Speex Narrowband for example was not very different to G.729/AMR in the = principle, it is some kind of CELP codec as you well know. Is that what you call a = codec for Internet? BTW, is Speex WB a codec for = Internet?

 

It is = something I am trying to understand from the different emails, but so far I have not succeeded. The only thing I could assume is that what you call an = Internet codec is a RF codec. In that case G.711, G.722, G.722.1 and G.722.1C = (and soon SBC if I understood well the previous emails) and certainly some other = codecs will be =93Internet=94 codecs according to my understanding of your = definition. Is my understanding correct? Is the only requirement? Are there technical requirements? I would appreciate if you could = clarify.

 

Best = regards

 

Herv=E9

 

 

 

--Boundary_(ID_8EWTrEu5M3wWGotqv9v4SQ)-- From steveu@coppice.org Wed Jul 15 08:31:17 2009 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 45D0E3A6CED for ; Wed, 15 Jul 2009 08:31:17 -0700 (PDT) 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 BMz+d5ripFzq for ; Wed, 15 Jul 2009 08:31:15 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 6A9723A6947 for ; Wed, 15 Jul 2009 08:31:14 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6FFSuH2031442; Wed, 15 Jul 2009 23:28:57 +0800 Message-ID: <4A5DF5B8.5000304@coppice.org> Date: Wed, 15 Jul 2009 23:28:56 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jean-Marc Valin References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> In-Reply-To: <4A5DDFA8.7070701@octasic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:31:17 -0000 Jean-Marc Valin wrote: > Hi Stephen, > > stephen botzko wrote: >> I'd think that there would still need to be 2 specs - the RFC for the >> codec itself, and a separate RFC for RTP/SIP, done through AVT. > > I totally agree on this. Codecs and transport are two different > things. That's why both SILK and CELT have separate drafts for the > codec and the RTP profile. Of course, the codecs can (and should) be > designed in parallel with the RTP profile to make sure they work well > with the RTP/SIP/SDP stack. > >> Some more dicussion on specific requirements that are not in the >> ITU-T codecs but which are desired in the "internet codec" would be >> fruitful, as I agree that this proposed group (when and it) should >> have different goals from other SDOs. Ideally these goals would be >> broader than the attributes of SILK or CELT, since it is reasonable >> to assume that this group would go on to standardize more codecs >> (being re-chartered as necessary). IPR terms alone are not enough >> (in my view). to justify yet another codec standardization group. > > In my opinion, IPR alone would be sufficient. But at the same time I > agree that if we're going to standardise codecs, they might as well be > targeted specifically for the Internet. The goals of MPEG and ITU-T > are very different and I would expect this WG to have goals that are > different from both. Opinion is nice, but its better when backed up with need. I used to have a digital telephone answering machine, and it used a codec with a stack of patents on it (I know the one, as I worked on it :-) ). Did I care? No. The $1-$2 those patents cost to licence was a bit skewed compared with the $1 RAM chip the voice was stored in, but it all came bundled in the cost of the machine. It was transparent. It created no obstacles. Now I get voice mail from a web browser. People make calls from VoIP phones using G.729, and the G.729 ends up in a voice mail box. I use Firefox to access that mailbox. Can the voice be delivered to me as G.729? Nope. G.729 can't be distributed with a product like Firefox, for patent reasons. Even a 0.1 cent royalty for G.729 would stop it being a straightforward download. Popping up a box telling me to go buy and install some codec just ain't gonna cut it these days. So, we have to use something else. We typically end up using something at a much higher bit rate, in most cases, as transcoding from one low bit rate codec to another sounds pretty bad. The separation of software from hardware, and much of the software we use for key internet activities being free downloads, has been a game changer. Come up with a new codec that can't be freely distributed, and its an irrelevance that will eventually have to be bypassed. We will still be left to work on a solution that can be freely distributed. It comes down to the important and subtle difference between $0.00001 and $0. Steve From jmh@joelhalpern.com Wed Jul 15 08:45:59 2009 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 40FD53A6B79 for ; Wed, 15 Jul 2009 08:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 nwIA-5Yw9lFO for ; Wed, 15 Jul 2009 08:45:58 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 9F8233A6B2D for ; Wed, 15 Jul 2009 08:45:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id E48FBA3995 for ; Wed, 15 Jul 2009 08:44:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BCB9643033F; Wed, 15 Jul 2009 08:44:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 15A2D4303E0; Wed, 15 Jul 2009 08:44:07 -0700 (PDT) Message-ID: <4A5DF944.5030608@joelhalpern.com> Date: Wed, 15 Jul 2009 11:44:04 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jean-Marc Valin References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> In-Reply-To: <4A5DDFA8.7070701@octasic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:45:59 -0000 Given that the odds of achieving the stated IPR goals are extremely small, it would seem very strange to undertake the effort with the primary purpose of meeting those goals. Yours, Joel Jean-Marc Valin wrote: > Hi Stephen, ... > In my opinion, IPR alone would be sufficient. But at the same time I > agree that if we're going to standardise codecs, they might as well be > targeted specifically for the Internet. The goals of MPEG and ITU-T are > very different and I would expect this WG to have goals that are > different from both. > > Cheers, > > Jean-Marc From stephen.botzko@gmail.com Wed Jul 15 08:53:41 2009 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 6394C3A6947 for ; Wed, 15 Jul 2009 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.442, 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 Lh8+l5IkE4CC for ; Wed, 15 Jul 2009 08:53:40 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 567273A6B79 for ; Wed, 15 Jul 2009 08:53:39 -0700 (PDT) Received: by bwz28 with SMTP id 28so1503857bwz.37 for ; Wed, 15 Jul 2009 08:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SqM28llBEFBDGeCLMFTWV9Mwd9C6wwqi748wGcHDXKk=; b=XNnAL9u9rNwbJ0waly4IY1tD03n3wvTnxQrF/UN4yOnnIsq+83j04DGjqDeDZSlXDI 7AeHSAae9PQ2GXg5pOEmKXX6Tl3LFhHThM3E93bBpuI/FC/kxWXJj324ES2ngiJpnByk UpiHBZ96ajFdsvdV7rjpokk69rxo/aa0IddIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xISaRAYA45MOpe+zrpXM8FPqS6NP2rui8i5mE39DTNdQLJXxnqDi3zUUNQ/nLOJdSD EikIN2KQ8e3oaMrnyhYE8xMDbGJIEyeXc8ZaGVF3HBLE0ozqmqpZr3AX+B1TKEruf47t y1t8z2E3ZJOoE3MmUdHqNPzppa/CNas94DkA4= MIME-Version: 1.0 Received: by 10.103.248.17 with SMTP id a17mr4060235mus.83.1247672803629; Wed, 15 Jul 2009 08:46:43 -0700 (PDT) In-Reply-To: <4A5DF5B8.5000304@coppice.org> References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> <4A5DF5B8.5000304@coppice.org> Date: Wed, 15 Jul 2009 11:46:43 -0400 Message-ID: <6e9223710907150846r49fb70abtf71b9851d7f06e16@mail.gmail.com> From: stephen botzko To: Steve Underwood Content-Type: multipart/alternative; boundary=0016369fa2fd419ab8046ec0766d Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:53:41 -0000 --0016369fa2fd419ab8046ec0766d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We agree that royalty-free is very important for some distribution models. However, royalty-free speech codecs can and have been standardized in other SDOs, which is why I am saying our goals need to be broader. The observation that most speech codecs do have royalties is on point, however (as I've said before) this is not inherent to the process used by the other SDOs. Rather, it is because the most of the contributors have chosen to set those terms. BTW, if you read the proposed charter for this working group, it says "as much as possible choose technology that does not require paying patent royalties", which is somewhat softer than what many posters here seem to be assuming. http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt Regards, Stephen Botzko Polycom On Wed, Jul 15, 2009 at 11:28 AM, Steve Underwood wrote= : > Jean-Marc Valin wrote: > >> Hi Stephen, >> >> stephen botzko wrote: >> >>> I'd think that there would still need to be 2 specs - the RFC for the >>> codec itself, and a separate RFC for RTP/SIP, done through AVT. >>> >> >> I totally agree on this. Codecs and transport are two different things. >> That's why both SILK and CELT have separate drafts for the codec and the= RTP >> profile. Of course, the codecs can (and should) be designed in parallel = with >> the RTP profile to make sure they work well with the RTP/SIP/SDP stack. >> >> Some more dicussion on specific requirements that are not in the ITU-T >>> codecs but which are desired in the "internet codec" would be fruitful,= as I >>> agree that this proposed group (when and it) should have different goal= s >>> from other SDOs.=C2 Ideally these goals would be broader than the attr= ibutes >>> of SILK or CELT, since it is reasonable to assume that this group would= go >>> on to standardize more codecs (being re-chartered as necessary).=C2 IP= R terms >>> alone are not enough (in my view). to justify yet another codec >>> standardization group.=C2 >>> >> >> In my opinion, IPR alone would be sufficient. But at the same time I agr= ee >> that if we're going to standardise codecs, they might as well be targete= d >> specifically for the Internet. The goals of MPEG and ITU-T are very >> different and I would expect this WG to have goals that are different fr= om >> both. >> > Opinion is nice, but its better when backed up with need. > > I used to have a digital telephone answering machine, and it used a codec > with a stack of patents on it (I know the one, as I worked on it :-) ). D= id > I care? No. The $1-$2 those patents cost to licence was a bit skewed > compared with the $1 RAM chip the voice was stored in, but it all came > bundled in the cost of the machine. It was transparent. It created no > obstacles. > > Now I get voice mail from a web browser. People make calls from VoIP phon= es > using G.729, and the G.729 ends up in a voice mail box. I use Firefox to > access that mailbox. Can the voice be delivered to me as G.729? Nope. G.7= 29 > can't be distributed with a product like Firefox, for patent reasons. Eve= n a > 0.1 cent royalty for G.729 would stop it being a straightforward download= . > Popping up a box telling me to go buy and install some codec just ain't > gonna cut it these days. So, we have to use something else. We typically = end > up using something at a much higher bit rate, in most cases, as transcodi= ng > from one low bit rate codec to another sounds pretty bad. > > The separation of software from hardware, and much of the software we use > for key internet activities being free downloads, has been a game changer= . > Come up with a new codec that can't be freely distributed, and its an > irrelevance that will eventually have to be bypassed. We will still be le= ft > to work on a solution that can be freely distributed. > > It comes down to the important and subtle difference between $0.00001 and > $0. > > Steve > > --0016369fa2fd419ab8046ec0766d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We agree that royalty-free is very important for some distribution models.= =A0 However, royalty-free speech codecs can and have been standardized in o= ther SDOs, which is why I am saying our goals need to be broader.

Th= e observation that most speech codecs do have royalties is on point, howeve= r (as I've said before) this is not inherent to the process used by the= other SDOs.=A0 Rather, it is because the most of the contributors have cho= sen to set those terms.

BTW, if you read the proposed charter for this working group, it says &= quot;as much as possible choose technology that does not require paying pat= ent royalties", which is somewhat softer than what many posters here s= eem to be assuming.

http://svn.resiprocate.org/rep/ietf-drafts/codec-bo= f/charter.txt

Regards,
Stephen Botz= ko
Polycom

On Wed, Jul 15, 2009 at 11:28 AM,= Steve Underwood <steveu@coppice.org> wrote:
Jean-Marc Valin wrote:
Hi Stephen,

stephen botzko wrote:
I'd think that there would still need to be 2 specs - the RFC for the c= odec itself, and a separate RFC for RTP/SIP, done through AVT.

I totally agree on this. Codecs and transport are two different things. Tha= t's why both SILK and CELT have separate drafts for the codec and the R= TP profile. Of course, the codecs can (and should) be designed in parallel = with the RTP profile to make sure they work well with the RTP/SIP/SDP stack= .

Some more dicussion on specific requirements that are not in the ITU-T code= cs but which are desired in the "internet codec" would be fruitfu= l, as I agree that this proposed group (when and it) should have different = goals from other SDOs.=C2 =A0Ideally these goals would be broader than the = attributes of SILK or CELT, since it is reasonable to assume that this grou= p would go on to standardize more codecs (being re-chartered as necessary).= =C2 =A0IPR terms alone are not enough (in my view). to justify yet another = codec standardization group.=C2

In my opinion, IPR alone would be sufficient. But at the same time I agree = that if we're going to standardise codecs, they might as well be target= ed specifically for the Internet. The goals of MPEG and ITU-T are very diff= erent and I would expect this WG to have goals that are different from both= .
Opinion is nice, but its better when backed up with need.

I used to have a digital telephone answering machine, and it used a codec w= ith a stack of patents on it (I know the one, as I worked on it :-) ). Did = I care? No. The $1-$2 those patents cost to licence was a bit skewed compar= ed with the $1 RAM chip the voice was stored in, but it all came bundled in= the cost of the machine. It was transparent. It created no obstacles.

Now I get voice mail from a web browser. People make calls from VoIP phones= using G.729, and the G.729 ends up in a voice mail box. I use Firefox to a= ccess that mailbox. Can the voice be delivered to me as G.729? Nope. G.729 = can't be distributed with a product like Firefox, for patent reasons. E= ven a 0.1 cent royalty for G.729 would stop it being a straightforward down= load. Popping up a box telling me to go buy and install some codec just ain= 't gonna cut it these days. So, we have to use something else. We typic= ally end up using something at a much higher bit rate, in most cases, as tr= anscoding from one low bit rate codec to another sounds pretty bad.

The separation of software from hardware, and much of the software we use f= or key internet activities being free downloads, has been a game changer. C= ome up with a new codec that can't be freely distributed, and its an ir= relevance that will eventually have to be bypassed. We will still be left t= o work on a solution that can be freely distributed.

It comes down to the important and subtle difference between $0.00001 and $= 0.

Steve


--0016369fa2fd419ab8046ec0766d-- From steveu@coppice.org Wed Jul 15 09:15:08 2009 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 579233A6914 for ; Wed, 15 Jul 2009 09:15:08 -0700 (PDT) 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 fTZpPlOMM9pU for ; Wed, 15 Jul 2009 09:15:07 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id E57CB3A6963 for ; Wed, 15 Jul 2009 09:15:01 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6FGDslb018346; Thu, 16 Jul 2009 00:13:54 +0800 Message-ID: <4A5E0042.6090303@coppice.org> Date: Thu, 16 Jul 2009 00:13:54 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> <4A5DF944.5030608@joelhalpern.com> In-Reply-To: <4A5DF944.5030608@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:15:08 -0000 Joel M. Halpern wrote: > Given that the odds of achieving the stated IPR goals are extremely > small, it would seem very strange to undertake the effort with the > primary purpose of meeting those goals. > > Yours, > Joel What is this based on? People tried to attack Vorbis, and the only successful tactic they tried was FUD. Speex hasn't attracted any vultures so far. Nobody can guarantee patent issues have been properly handled - an extra licencee was recently added to the patent pool for G.729. Patent holders can always crawl out of the woodwork. However, saying the chances of success are extremely small is ****EXTREMELY**** defeatist. Why not just give up on life and end it all? :-) Steve > > Jean-Marc Valin wrote: >> Hi Stephen, > ... >> In my opinion, IPR alone would be sufficient. But at the same time I >> agree that if we're going to standardise codecs, they might as well >> be targeted specifically for the Internet. The goals of MPEG and >> ITU-T are very different and I would expect this WG to have goals >> that are different from both. >> >> Cheers, >> >> Jean-Marc From hsinnrei@adobe.com Wed Jul 15 11:03:29 2009 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 1330A3A6C46 for ; Wed, 15 Jul 2009 11:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5cXLXQ5dSvY for ; Wed, 15 Jul 2009 11:03:25 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 909E13A6C0C for ; Wed, 15 Jul 2009 11:03:24 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSl4Zs5ZjqK1ZelRPa+cJ8JzWbBWCKHcq@postini.com; Wed, 15 Jul 2009 11:03:57 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FI2PWG010559 for ; Wed, 15 Jul 2009 11:02:26 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n6FI2NY2028198 for ; Wed, 15 Jul 2009 11:02:24 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 15 Jul 2009 11:02:23 -0700 From: Henry Sinnreich To: "codec@ietf.org" Date: Wed, 15 Jul 2009 11:02:22 -0700 Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2f Message-ID: In-Reply-To: <4a5d5a02.26045a0a.7879.7cd3@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68383DE4E25hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:03:29 -0000 --_000_C68383DE4E25hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to make clear my company's position: We're supportive of the efforts to arrive at a selection of a preferred cod= ec for voice over the Internet, as proposed for the Voice Codec BOF. To accommodate the broadest possible community, we support the selection of= a voice codec which * has a broad range of audio bandwidths, with no more than 30ms and pref= erably lower delay, * can be implemented efficiently, * is available for use without patent license fees or any other known IP= R constraints, * has an open source reference implementation, * works over the Internet. We think several voice codecs have been proposed which seem to meet those r= equirements, and hope that the working group can produce the standard for a= n Internet voice codec along these lines. Henry Sinnreich Adobe Systems, Inc. --_000_C68383DE4E25hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] useful for Internet applications with voice Just to make clear my company’s position:

We’re supportive of the efforts to arrive at a selection of a preferr= ed codec for voice over the Internet, as proposed for the Voice Codec BOF. =
To accommodate the broadest possible community, we support the selection of= a voice codec which
 
  • has a broad range of au= dio bandwidths, with no more than 30ms and preferably lower delay,=20
  • can be implemented efficien= tly,=20
  • is available for use withou= t patent license fees or any other known IPR constraints,=20
  • has an open source referenc= e implementation,=20
  • works over the Internet.

We think several vo= ice codecs have been proposed which seem to meet those requirements, and ho= pe that the working group can produce the standard for an Internet voice co= dec along these lines.

Henry Sinnreich
Adobe Systems, Inc.

--_000_C68383DE4E25hsinnreiadobecom_-- From brian@freeswitch.org Wed Jul 15 11:22:47 2009 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 922443A6B1C for ; Wed, 15 Jul 2009 11:22:47 -0700 (PDT) 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=[AWL=-0.001, 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 UiIx6doHwwOX for ; Wed, 15 Jul 2009 11:22:46 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3FB143A6A6C for ; Wed, 15 Jul 2009 11:22:46 -0700 (PDT) Received: by ewy26 with SMTP id 26so4256901ewy.37 for ; Wed, 15 Jul 2009 11:21:24 -0700 (PDT) Received: by 10.216.36.82 with SMTP id v60mr2093092wea.120.1247682084106; Wed, 15 Jul 2009 11:21:24 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id g11sm21306483gve.16.2009.07.15.11.21.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Jul 2009 11:21:22 -0700 (PDT) Message-Id: <0CCCBC19-F9AB-4270-B692-3400DD958754@freeswitch.org> From: Brian West To: Henry Sinnreich In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-24-939422287 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 13:21:18 -0500 References: X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:22:47 -0000 --Apple-Mail-24-939422287 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Comments in line. On Jul 15, 2009, at 1:02 PM, Henry Sinnreich wrote: > has a broad range of audio bandwidths, with no more than 30ms and > preferably lower delay, I can agree with this but it should be noted that higher ptimes are preferred in some cases... performance gains (network and CPU) of 30ms vs 60ms can be seen very clearly in our testing. You have to think of the server side that has to scale the codec to 1000's of channels per instance. > can be implemented efficiently, Do you mean low CPU requirements? > is available for use without patent license fees or any other known > IPR constraints, I think this is a requirement also. > has an open source reference implementation, The reference implementation licensing should be as broad as possible in my opinion so its compatible with as many open source licenses as possible. > works over the Internet. > We think several voice codecs have been proposed which seem to meet > those requirements, and hope that the working group can produce the > standard for an Internet voice codec along these lines. > > Henry Sinnreich > Adobe Systems, Inc. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --Apple-Mail-24-939422287 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Comments in = line.

On Jul 15, 2009, at 1:02 PM, Henry Sinnreich = wrote:

  • has a broad = range of audio bandwidths, with no more than 30ms and preferably lower = delay,
I can = agree with this but it should be noted that higher ptimes are preferred = in some cases... performance gains (network and CPU) of 30ms vs 60ms can = be seen very clearly in our testing.  You have to think of the = server side that has to scale the codec to 1000's of channels per = instance.
  • can be implemented efficiently, =
Do you mean low = CPU requirements?
  • is available for use without patent license = fees or any other known IPR constraints, =
I think this is a = requirement also.
  • has an open source reference = implementation,
The = reference implementation licensing should be as&n= bsp;broad as possible in my opinion so = its compatible with as many open source = ;licenses as possible.
  • works over the = Internet. 
We think = several voice codecs have been proposed which seem to meet those = requirements, and hope that the working group can produce the standard = for an Internet voice codec along these lines.

Henry = Sinnreich
Adobe Systems, Inc.

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

= --Apple-Mail-24-939422287-- From stewe@stewe.org Wed Jul 15 11:34:46 2009 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 B8FFF3A693A for ; Wed, 15 Jul 2009 11:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.658, 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 PXosiZr-cajr for ; Wed, 15 Jul 2009 11:34:45 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0C1B53A6BF1 for ; Wed, 15 Jul 2009 11:34:08 -0700 (PDT) Received: from [192.168.1.110] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 342103-1743317 for multiple; Wed, 15 Jul 2009 20:11:52 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 11:07:39 -0700 From: Stephan Wenger To: Steve Underwood , "Joel M. Halpern" Message-ID: Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Thread-Index: AcoFdyOZlTzYeTLPrUic52e3ggPRqw== In-Reply-To: <4A5E0042.6090303@coppice.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:34:46 -0000 Hi, On 7/15/09 9:13 AM, "Steve Underwood" wrote: > Joel M. Halpern wrote: >> Given that the odds of achieving the stated IPR goals are extremely >> small, it would seem very strange to undertake the effort with the >> primary purpose of meeting those goals. >> >> Yours, >> Joel > What is this based on? People tried to attack Vorbis, and the only > successful tactic they tried was FUD. Speex hasn't attracted any > vultures so far. Sorry, but this is nonsense. Patent assertions and lawsuits are like bugs. You can sometimes observe their presence, but you can never show their absence. (Well, my old CS theory professor would argue against that for bugs, but I don't think anyone can reasonably argue against it for patent assertions). Just because you, and, presumably, your company has not been approached for licensing revenues does not mean that no one else has. I would also be careful to name anyone who is exercising one's legal right to enforce a patent a "vulture". People have been sued for even using the much more frequently used word "troll". > Nobody can guarantee patent issues have been properly > handled - an extra licencee was recently added to the patent pool for > G.729. Depending on how "properly handling of patent issues" is defined, it can sometimes be guarantied. To the best of my knowledge, there have been no violations of the ITU patent policy in the G.729 case, to which (I believe) you are referring to. There is no requirement set by the ITU (or any other SDO I'm aware of, outside China at least) to join a patent pool, and, to the best of my understanding of antitrust law, there cannot be such a requirement. > Patent holders can always crawl out of the woodwork. That is true. > However, > saying the chances of success are extremely small is ****EXTREMELY**** > defeatist. I agree with Joel, and disagree with you, that the chances are "extremely" small, based on my own experience (which, quite obviously is not the same as yours.) > Why not just give up on life and end it all? :-) Because at least my life is not dependent on an IETF project towards a open-source friendly codec RFC. If yours is, I would be ****EXTRENELY**** sorry for you. :-) Regards, Stephan > > Steve >> >> Jean-Marc Valin wrote: >>> Hi Stephen, >> ... >>> In my opinion, IPR alone would be sufficient. But at the same time I >>> agree that if we're going to standardise codecs, they might as well >>> be targeted specifically for the Internet. The goals of MPEG and >>> ITU-T are very different and I would expect this WG to have goals >>> that are different from both. >>> >>> Cheers, >>> >>> Jean-Marc > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Wed Jul 15 11:44:43 2009 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 0BDA53A6F65 for ; Wed, 15 Jul 2009 11:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.859, 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 65VHPlmlCp2W for ; Wed, 15 Jul 2009 11:44:42 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 12A623A6F49 for ; Wed, 15 Jul 2009 11:43:47 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6FIdqsZ048323; Wed, 15 Jul 2009 22:39:52 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Jul 2009 22:39:43 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Thread-Index: AcoFdyOZlTzYeTLPrUic52e3ggPRqwABCOvg References: <4A5E0042.6090303@coppice.org> From: "Slava Borilin" To: "Stephan Wenger" , "Steve Underwood" , "Joel M. Halpern" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:44:43 -0000 >> Depending on how "properly handling of patent issues" is defined, it can >> sometimes be guarantied. =20 Just remember 2007's scandal and legal case on MP3 patent and Microsoft ;-) best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Wednesday, July 15, 2009 10:08 PM To: Steve Underwood; Joel M. Halpern Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Hi, On 7/15/09 9:13 AM, "Steve Underwood" wrote: > Joel M. Halpern wrote: >> Given that the odds of achieving the stated IPR goals are extremely >> small, it would seem very strange to undertake the effort with the >> primary purpose of meeting those goals. >>=20 >> Yours, >> Joel > What is this based on? People tried to attack Vorbis, and the only > successful tactic they tried was FUD. Speex hasn't attracted any > vultures so far.=20 Sorry, but this is nonsense. Patent assertions and lawsuits are like bugs. You can sometimes observe their presence, but you can never show their absence. (Well, my old CS theory professor would argue against that for bugs, but I don't think anyone can reasonably argue against it for patent assertions). Just because you, and, presumably, your company has not been approached for licensing revenues does not mean that no one else has. I would also be careful to name anyone who is exercising one's legal right to enforce a patent a "vulture". People have been sued for even using the much more frequently used word "troll". > Nobody can guarantee patent issues have been properly > handled - an extra licencee was recently added to the patent pool for > G.729.=20 Depending on how "properly handling of patent issues" is defined, it can sometimes be guarantied. To the best of my knowledge, there have been no violations of the ITU patent policy in the G.729 case, to which (I believe) you are referring to. There is no requirement set by the ITU (or any other SDO I'm aware of, outside China at least) to join a patent pool, and, to the best of my understanding of antitrust law, there cannot be such a requirement. > Patent holders can always crawl out of the woodwork. That is true. > However,=20 > saying the chances of success are extremely small is ****EXTREMELY**** > defeatist.=20 I agree with Joel, and disagree with you, that the chances are "extremely" small, based on my own experience (which, quite obviously is not the same as yours.) > Why not just give up on life and end it all? :-) Because at least my life is not dependent on an IETF project towards a open-source friendly codec RFC. If yours is, I would be ****EXTRENELY**** sorry for you. :-) Regards, Stephan >=20 > Steve >>=20 >> Jean-Marc Valin wrote: >>> Hi Stephen, >> ... >>> In my opinion, IPR alone would be sufficient. But at the same time I >>> agree that if we're going to standardise codecs, they might as well >>> be targeted specifically for the Internet. The goals of MPEG and >>> ITU-T are very different and I would expect this WG to have goals >>> that are different from both. >>>=20 >>> Cheers, >>>=20 >>> Jean-Marc >=20 > _______________________________________________ > 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 stewe@stewe.org Wed Jul 15 11:53:30 2009 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 1F5ED3A6F1A for ; Wed, 15 Jul 2009 11:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 YptGWPIPbyRn for ; Wed, 15 Jul 2009 11:53:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 2F7083A6F29 for ; Wed, 15 Jul 2009 11:53:24 -0700 (PDT) Received: from [192.168.1.110] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 342143-1743317 for multiple; Wed, 15 Jul 2009 20:36:31 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 11:36:21 -0700 From: Stephan Wenger To: Henry Sinnreich , "codec@ietf.org" Message-ID: Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2fAAEv1cA= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330502590_747629" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:53:30 -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_3330502590_747629 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, I would object to any charter proposal that requires an =B3open source reference implementation=B2, because it unfairly excludes from IETF=B9s standar= d process all those companies which, on principle, do not contribute to open source.=20 You may also wish to clarify the sentence =B3is available for use without patent license fees or any other known IPR constraints, =B2. Isn=B9t this what you really want to say: =B3a voice codec whose known IPR is available under terms compatible with all major open source licenses=B2? Regards, Stephan On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: > Just to make clear my company=B9s position: >=20 > We=B9re supportive of the efforts to arrive at a selection of a preferred c= odec > for voice over the Internet, as proposed for the Voice Codec BOF. > To accommodate the broadest possible community, we support the selection = of a > voice codec which > =20 > * has a broad range of audio bandwidths, with no more than 30ms and prefe= rably > lower delay,=20 > * can be implemented efficiently, > * is available for use without patent license fees or any other known IPR > constraints,=20 > * has an open source reference implementation, > * works over the Internet. >=20 >> We think several voice codecs have been proposed which seem to meet thos= e >> requirements, and hope that the working group can produce the standard f= or an >> Internet voice codec along these lines. >>=20 >> Henry Sinnreich >> Adobe Systems, Inc. >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3330502590_747629 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] useful for Internet applications with voice Hi Henry,
I would object to any charter proposal that requires an “open source = reference implementation”, because it unfairly excludes from IETF̵= 7;s standard process all those companies which, on principle, do not contrib= ute to open source.
You may also wish to clarify the sentence “is available for use witho= ut patent license fees or any other known IPR constraints, ”.  Is= n’t this what you really want to say: “a voice codec whose known= IPR is available under terms compatible with all major open source licenses= ”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"4">Just to make clear my companyR= 17;s position:

We’re supportive of the efforts to arrive at a selection of a preferr= ed codec for voice over the Internet, as proposed for the Voice Codec BOF. <= BR> To accommodate the broadest possible community, we support the selection of= a voice codec which
 
  • has a broad range of audio ban= dwidths, with no more than 30ms and preferably lower delay,=20
  • can be implemented efficiently,=20
  • is available for use without paten= t license fees or any other known IPR constraints,=20
  • has an open source reference imple= mentation,=20
  • works over the Internet.
<= FONT SIZE=3D"4">
We think several voice cod= ecs have been proposed which seem to meet those requirements, and hope that = the working group can produce the standard for an Internet voice codec along= these lines.

Henry Sinnreich
Adobe Systems, Inc.


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3330502590_747629-- From stephen.botzko@gmail.com Wed Jul 15 12:00:38 2009 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 D01D73A6F1A for ; Wed, 15 Jul 2009 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, 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 qgUMazQdJB5P for ; Wed, 15 Jul 2009 12:00:37 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id D50693A6AA4 for ; Wed, 15 Jul 2009 12:00:16 -0700 (PDT) Received: by bwz28 with SMTP id 28so1610483bwz.37 for ; Wed, 15 Jul 2009 12:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZUfl3LtSHr1Sh8hV8sztYSnTRE409P8cvvSNFUQudgk=; b=TeL2J4mb7ClAOIwQakciDv6cDlofWd96WMdOm1axdEWUdK/0B+nUzhMKizj8/+RZra fijJCvlrOp2LN3l4aQV1PZp+dtt0NHtX9psz5//iQ4OiJg7ltDzRiRYBxubRXWfPMg99 iFylnNQctBkxY7f3yS8oAMnNtwOSZJJMiCZFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xu1+efCJBjLxEsg9tlqiS/DFz0jW/sxQkNtA6rd9n6gIEK/5k3oA/QjrhxR92alg9r 5hV73vhEVGZ8IU5MTOmnDYdPFadkjyBcLKZPgWudNEdKQfWBjPEunZtpNeCeCt1dkRJG jdSmyhrNzgIiw6w9DawIMs9PiUAQL3Hl+UppQ= MIME-Version: 1.0 Received: by 10.103.192.10 with SMTP id u10mr4229290mup.128.1247680463644; Wed, 15 Jul 2009 10:54:23 -0700 (PDT) In-Reply-To: <4A5E0042.6090303@coppice.org> References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> <4A5DF944.5030608@joelhalpern.com> <4A5E0042.6090303@coppice.org> Date: Wed, 15 Jul 2009 13:54:23 -0400 Message-ID: <6e9223710907151054g164e9a26v11ac41b7331089ca@mail.gmail.com> From: stephen botzko To: Steve Underwood Content-Type: multipart/alternative; boundary=001636c5b424d4278b046ec23e27 Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:00:39 -0000 --001636c5b424d4278b046ec23e27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, Vorbis is not a speech codec, it's not a "must have" codec for music in any player (PC or otherwise), and most of the folks deploying it haven't had any money anyway. I'd suggest that there's not a lot of incentive for anyone to go after it. Speex is more on point for this proposed group I think. As it gains in popularity, it could very well draw more attention. As would an IETF standard, which is likely to be a "must have" codec in at least one market segment. Joel is not the only poster to say that they think the odds are slight. At this point, I'm more concerned about the details on how the IPR goal would be implemented. The group should not need to be legal experts, and I really don't want to end up with the group attempting to publicly construe patent claims. I would also like to see procedures that allow contributors to delay full disclosure of algorithms/source code. Publishing one's current proprietary methods could also invite legal problems for the publisher, and allow your methods to be analyzed (or copied) by your competition. Obviously you need to disclose in order to standardize. But if your contribution doesn't make the cut (for whatever reason), you'd have disclosed it to no purpose. So some pre-qualification phase, where full disclosure isn't required, might be a useful middle ground. The goal would be to get more contributions, not to permit folks to sneak encumbrances into the standard. Stephen Botzko Polycom On Wed, Jul 15, 2009 at 12:13 PM, Steve Underwood wrote: > Joel M. Halpern wrote: > >> Given that the odds of achieving the stated IPR goals are extremely small, >> it would seem very strange to undertake the effort with the primary purpose >> of meeting those goals. >> >> Yours, >> Joel >> > What is this based on? People tried to attack Vorbis, and the only > successful tactic they tried was FUD. Speex hasn't attracted any vultures so > far. Nobody can guarantee patent issues have been properly handled - an > extra licencee was recently added to the patent pool for G.729. Patent > holders can always crawl out of the woodwork. However, saying the chances of > success are extremely small is ****EXTREMELY**** defeatist. Why not just > give up on life and end it all? :-) > > Steve > > >> Jean-Marc Valin wrote: >> >>> Hi Stephen, >>> >> ... >> >>> In my opinion, IPR alone would be sufficient. But at the same time I >>> agree that if we're going to standardise codecs, they might as well be >>> targeted specifically for the Internet. The goals of MPEG and ITU-T are very >>> different and I would expect this WG to have goals that are different from >>> both. >>> >>> Cheers, >>> >>> Jean-Marc >>> >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c5b424d4278b046ec23e27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, Vorbis is not a speech codec, it's not a "must have" co= dec for music in any player (PC or otherwise), and most of the folks deploy= ing it haven't had any money anyway.=A0 I'd suggest that there'= s not a lot of incentive for anyone to go after it.

Speex is more on point for this proposed group I think.=A0 As it gains = in popularity, it could very well draw more attention.=A0 As would an IETF = standard, which is likely to be a "must have" codec in at least o= ne market segment.=A0 Joel is not the only poster to say that they think th= e odds are slight.

At this point, I'm more concerned about the details on how the IPR = goal would be implemented.=A0 The group should not need to be legal experts= , and I really don't want to end up with the group attempting to public= ly construe patent claims.

I would also like to see procedures that allow contributors to delay fu= ll disclosure of algorithms/source code.=A0 Publishing one's current pr= oprietary methods could also invite legal problems for the publisher, and a= llow your methods to be analyzed (or copied) by your competition. Obviously= you need to disclose in order to standardize.=A0 But if your contribution = doesn't make the cut (for whatever reason), you'd have disclosed it= to no purpose.=A0

So some pre-qualification phase, where full disclosure isn't requir= ed, might be a useful middle ground.=A0 The goal would be to get more contr= ibutions, not to permit folks to sneak encumbrances into the standard.

Stephen Botzko
Polycom




On Wed, Jul 15, 2009 at 12:13 PM, Steve Underwood <steveu@coppice.org> wrote= :
Joel M. Halpern wrote:
Given that the odds of achieving the stated IPR goals are extremely small, = it would seem very strange to undertake the effort with the primary purpose= of meeting those goals.

Yours,
Joel
What is this based on? People tried to attack Vorbis, and the only successf= ul tactic they tried was FUD. Speex hasn't attracted any vultures so fa= r. Nobody can guarantee patent issues have been properly handled - an extra= licencee was recently added to the patent pool for G.729. Patent holders c= an always crawl out of the woodwork. However, saying the chances of success= are extremely small is ****EXTREMELY**** defeatist. Why not just give up o= n life and end it all? :-)

Steve


Jean-Marc Valin wrote:
Hi Stephen,
...
In my opinion, IPR alone would be sufficient. But at the same time I agree = that if we're going to standardise codecs, they might as well be target= ed specifically for the Internet. The goals of MPEG and ITU-T are very diff= erent and I would expect this WG to have goals that are different from both= .

Cheers,

=A0 =A0Jean-Marc

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

--001636c5b424d4278b046ec23e27-- From Borilin@spiritdsp.com Wed Jul 15 12:00:40 2009 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 155363A6F29 for ; Wed, 15 Jul 2009 12:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 T226CQ6Y9Evs for ; Wed, 15 Jul 2009 12:00:34 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 29C2328C488 for ; Wed, 15 Jul 2009 12:00:15 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6FJ0BxP048621; Wed, 15 Jul 2009 23:00:11 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA057E.76DEFCA7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Jul 2009 23:00:02 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2fAAEv1cAAAMAtoA== References: From: "Slava Borilin" To: "Stephan Wenger" , "Henry Sinnreich" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:00:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA057E.76DEFCA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephan, =20 The goals (of WG and codec) should be driven by customer demand, not by potential contributors - so Henry got the point that customers want to have open-source, if feasible. If there are means to get open-source and satisfy other goals of the codec, then it does not matter then "many did not contribute because they do not do open source". =20 We should remove "open source" only in the case when it is NOT feasible to achieve other codec performance targets by any open-source solutions (current or to be developed). =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Wednesday, July 15, 2009 10:36 PM To: Henry Sinnreich; codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice =20 Hi Henry, I would object to any charter proposal that requires an "open source reference implementation", because it unfairly excludes from IETF's standard process all those companies which, on principle, do not contribute to open source.=20 You may also wish to clarify the sentence "is available for use without patent license fees or any other known IPR constraints, ". Isn't this what you really want to say: "a voice codec whose known IPR is available under terms compatible with all major open source licenses"? Regards, Stephan On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: Just to make clear my company's position: We're supportive of the efforts to arrive at a selection of a preferred codec for voice over the Internet, as proposed for the Voice Codec BOF.=20 To accommodate the broadest possible community, we support the selection of a voice codec which=20 =20 * has a broad range of audio bandwidths, with no more than 30ms and preferably lower delay,=20 * can be implemented efficiently,=20 * is available for use without patent license fees or any other known IPR constraints,=20 * has an open source reference implementation,=20 * works over the Internet.=20 =20 We think several voice codecs have been proposed which seem to meet those requirements, and hope that the working group can produce the standard for an Internet voice codec along these lines. =09 Henry Sinnreich Adobe Systems, Inc. =20 ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA057E.76DEFCA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [codec] useful for Internet applications with voice

Stephan,

 =

The goals (of WG = and codec) should be driven by customer demand, not by potential = contributors – so Henry got the point that customers want to have open-source, if = feasible. If there are means to get open-source and satisfy other goals of the codec, = then it does not matter then “many did not contribute because they do = not do open source”.

 =

We should remove = “open source” only in the case when it is NOT feasible to achieve other = codec performance targets by any open-source solutions (current or to be = developed).

 =

best = regards,

Slava = Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Wednesday, July 15, = 2009 10:36 PM
To: Henry Sinnreich; codec@ietf.org
Subject: Re: [codec] = useful for Internet applications with voice

 

Hi Henry,
I would object to any charter proposal that requires an “open = source reference implementation”, because it unfairly excludes from = IETF’s standard process all those companies which, on principle, do not = contribute to open source.
You may also wish to clarify the sentence “is available for use = without patent license fees or any other known IPR constraints, ”.  Isn’t this what you really want to say: “a voice codec = whose known IPR is available under terms compatible with all major open source licenses”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> = wrote:

Just to make clear my company’s position:

We’re supportive of the efforts to arrive at a selection of a = preferred codec for voice over the Internet, as proposed for the Voice Codec BOF. =
To accommodate the broadest possible community, we support the selection = of a voice codec which
 

  • has a broad range of audio bandwidths, = with no more than 30ms and preferably lower delay, =
  • can be implemented efficiently, =
  • is available for use without patent = license fees or any other known IPR constraints, =
  • has an open source reference = implementation,
  • works over the Internet. =

 

We think several voice = codecs have been proposed which seem to meet those requirements, and hope that the = working group can produce the standard for an Internet voice codec along these = lines.

Henry Sinnreich
Adobe Systems, Inc.

 

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

------_=_NextPart_001_01CA057E.76DEFCA7-- From stewe@stewe.org Wed Jul 15 12:01:58 2009 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 C76D23A6F49 for ; Wed, 15 Jul 2009 12:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.692, 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 IWUpT0MiYGlK for ; Wed, 15 Jul 2009 12:01:57 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id BC12F28C164 for ; Wed, 15 Jul 2009 12:01:46 -0700 (PDT) Received: from [192.168.1.110] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 342183-1743317 for multiple; Wed, 15 Jul 2009 21:01:46 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 12:01:36 -0700 From: Stephan Wenger To: Slava Borilin , Steve Underwood , "Joel M. Halpern" Message-ID: Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Thread-Index: AcoFdyOZlTzYeTLPrUic52e3ggPRqwABCOvgAADZbvU= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:01:58 -0000 Oh, I'm aware of this. Perhaps more than I like it. But even in this case I fail to see how there was a violation of MPEG's processes or the ISO/IEC's patent policy. Avoiding such violations is the best we can possibly shoot for, I guess. Regards, Stephan On 7/15/09 11:39 AM, "Slava Borilin" wrote: >>> Depending on how "properly handling of patent issues" is defined, it > can >>> sometimes be guarantied. > > Just remember 2007's scandal and legal case on MP3 patent and Microsoft > ;-) > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Stephan Wenger > Sent: Wednesday, July 15, 2009 10:08 PM > To: Steve Underwood; Joel M. Halpern > Cc: codec@ietf.org > Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 > meeting (10 July 2009) > > Hi, > > On 7/15/09 9:13 AM, "Steve Underwood" wrote: > >> Joel M. Halpern wrote: >>> Given that the odds of achieving the stated IPR goals are extremely >>> small, it would seem very strange to undertake the effort with the >>> primary purpose of meeting those goals. >>> >>> Yours, >>> Joel >> What is this based on? People tried to attack Vorbis, and the only >> successful tactic they tried was FUD. Speex hasn't attracted any >> vultures so far. > > Sorry, but this is nonsense. Patent assertions and lawsuits are like > bugs. > You can sometimes observe their presence, but you can never show their > absence. (Well, my old CS theory professor would argue against that for > bugs, but I don't think anyone can reasonably argue against it for > patent > assertions). Just because you, and, presumably, your company has not > been > approached for licensing revenues does not mean that no one else has. > > I would also be careful to name anyone who is exercising one's legal > right > to enforce a patent a "vulture". People have been sued for even using > the > much more frequently used word "troll". > >> Nobody can guarantee patent issues have been properly >> handled - an extra licencee was recently added to the patent pool for >> G.729. > > Depending on how "properly handling of patent issues" is defined, it can > sometimes be guarantied. To the best of my knowledge, there have been > no > violations of the ITU patent policy in the G.729 case, to which (I > believe) > you are referring to. > > There is no requirement set by the ITU (or any other SDO I'm aware of, > outside China at least) to join a patent pool, and, to the best of my > understanding of antitrust law, there cannot be such a requirement. > >> Patent holders can always crawl out of the woodwork. > > That is true. > >> However, >> saying the chances of success are extremely small is ****EXTREMELY**** >> defeatist. > > I agree with Joel, and disagree with you, that the chances are > "extremely" > small, based on my own experience (which, quite obviously is not the > same as > yours.) > >> Why not just give up on life and end it all? :-) > > Because at least my life is not dependent on an IETF project towards a > open-source friendly codec RFC. If yours is, I would be > ****EXTRENELY**** > sorry for you. :-) > > Regards, > Stephan > > >> >> Steve >>> >>> Jean-Marc Valin wrote: >>>> Hi Stephen, >>> ... >>>> In my opinion, IPR alone would be sufficient. But at the same time I >>>> agree that if we're going to standardise codecs, they might as well >>>> be targeted specifically for the Internet. The goals of MPEG and >>>> ITU-T are very different and I would expect this WG to have goals >>>> that are different from both. >>>> >>>> Cheers, >>>> >>>> Jean-Marc >> >> _______________________________________________ >> 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 jean-marc.valin@octasic.com Wed Jul 15 12:06:57 2009 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 8B4083A6F29 for ; Wed, 15 Jul 2009 12:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 f--xTPgcO0Pj for ; Wed, 15 Jul 2009 12:06:56 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 35F3E28C10A for ; Wed, 15 Jul 2009 12:06:53 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 15:04:12 -0400 Message-ID: <4A5E282B.1080108@octasic.com> Date: Wed, 15 Jul 2009 15:04:11 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Herve Taddei References: <4FC158146B112A4B90CC2A0C8A9A8C8C0229FF0A@MAILBOX1.blue.itu.ch> <13111084-234E-47F3-A265-BEE0067187BE@cisco.com> <002a01ca0529$3ebb9800$bc32c800$@de> <002b01ca0532$98fc84b0$caf58e10$@de> <6e9223710907150442p27255508uaf17b6efa5fc5e58@mail.gmail.com> <4A5DDFA8.7070701@octasic.com> <003a01ca055d$8b7d42e0$3946c80a@china.huawei.com> In-Reply-To: <003a01ca055d$8b7d42e0$3946c80a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jul 2009 19:04:12.0060 (UTC) FILETIME=[0A0585C0:01CA057F] Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:06:57 -0000 Hi Herve, Herve Taddei wrote: >> that if we're going to standardise codecs, they might as well be targeted >> specifically for the Internet. The goals of MPEG and ITU-T are very > different >> and I would expect this WG to have goals that are different from both. > It would be good that you clarify what you call a codec specifically > designed for Internet. In ITU-T and 3GPP they have codecs that seem to > be adequate for VoIP, see G.711, G.729. Speex Narrowband for example was > not very different to G.729/AMR in the principle, it is some kind of > CELP codec as you well know. Is that what you call a codec for Internet? > BTW, is Speex WB a codec for Internet? Speex is a codec that addresses what *I* (and a handful of early adopters) perceived to be the needs of the Internet back in 2002 and is by no means perfect. It has a few features that -- while not unheard of -- where still uncommon at the time, such as embedded wideband, multi-rate capability and source-controlled VBR. There was also the licensing, which is not just about money, but about enabling new Internet applications that were simply not possible with the typical ITU licensing. Note that at the time, Speex was not even meant to compete with G.729 and AMR-NB. All it had to do to be useful is be better than G.711, GSM-FR and LPC10 -- which is what people who couldn't afford per-channel royalties were using. So we are now in 2009 and both the Internet and the codec technology have evolved since 2002. It would be a good thing to look at how we can address the current needs of the Internet with current technology. The idea is that doing that within the IETF based on a consensus is preferable to the way that Speex was designed. I'll go as far as to say that, had Speex been through IETF standardisation, some of its "sub-optimal" design decisions would likely have been avoided/corrected (non-integer number of bytes per compressed frame comes to mind). > It is something I am trying to understand from the different emails, but > so far I have not succeeded. The only thing I could assume is that what > you call an Internet codec is a RF codec. In that case G.711, G.722, > G.722.1 and G.722.1C (and soon SBC if I understood well the previous > emails) and certainly some other codecs will be “Internet” codecs > according to my understanding of your definition. Is my understanding > correct? Is the only requirement? Are there technical requirements? I > would appreciate if you could clarify. I think the final requirements will have to be established with the IETF community, so what follows is only my personal opinion (and I expect that many issues are missing). I see differences between the Internet and what the ITU currently targets that go much beyond the IP transport part, which I agree that the ITU *is* addressing (though I think the ITU -- rightly -- puts more emphasis on bit error robustness than is needed for the Internet). As I said earlier, licensing is one of these aspects. Codecs on the Internet should be a commodity and not a barrier to entry. There are many applications or business models (open source or not) on the Internet for which per-channel royalties are simply not an option, no matter what. There are also more technical aspects. One difference between the Internet and the cell phone market that many recent codecs focus on is the cost of bandwidth. While not free, Internet bandwidth is a lot cheaper than cellular wireless bandwidth, so it makes sense to target higher quality. Of the ITU codecs you list, I consider that G.722.1C is the only one that can really be said to have good quality, but even then it's limited in sampling rate (32 kHz), bit-rate (48 kbit/s music sounds bad) and latency (40 ms is a lot of delay in my opinion). Another issue is "legacy support". I understand how important it is for the ITU to release codecs that are backward-compatible with "legacy infrastructure", which explains the recent batch of codecs like G.729.1, G.711.1, G.718 and others. I'm not sure we need that complexity for an Internet codec where codecs are generally easier to deploy and negotiate (SIP/SDP). These are just a few examples I see that go beyond "works on packet networks". Cheers, Jean-Marc From steveu@coppice.org Wed Jul 15 12:12:11 2009 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 E8AFF28C14E for ; Wed, 15 Jul 2009 12:12:11 -0700 (PDT) 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 fINk+kaGKf1b for ; Wed, 15 Jul 2009 12:12:10 -0700 (PDT) Received: from eoemailadmin.pacific.net.hk (eoemailadmin.pacific.net.hk [202.14.67.94]) by core3.amsl.com (Postfix) with ESMTP id 7C58C3A6809 for ; Wed, 15 Jul 2009 12:12:10 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by eoemailadmin.pacific.net.hk with ESMTP id n6FJBspa018437 for ; Thu, 16 Jul 2009 03:11:54 +0800 Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6FJ8hvS014542; Thu, 16 Jul 2009 03:08:44 +0800 Message-ID: <4A5E293B.8000306@coppice.org> Date: Thu, 16 Jul 2009 03:08:43 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:12:12 -0000 Hi Stephan, Stephan Wenger wrote: > Hi, > > On 7/15/09 9:13 AM, "Steve Underwood" wrote: > > >> Joel M. Halpern wrote: >> >>> Given that the odds of achieving the stated IPR goals are extremely >>> small, it would seem very strange to undertake the effort with the >>> primary purpose of meeting those goals. >>> >>> Yours, >>> Joel >>> >> What is this based on? People tried to attack Vorbis, and the only >> successful tactic they tried was FUD. Speex hasn't attracted any >> vultures so far. >> > > Sorry, but this is nonsense. Patent assertions and lawsuits are like bugs. > You can sometimes observe their presence, but you can never show their > absence. (Well, my old CS theory professor would argue against that for > bugs, but I don't think anyone can reasonably argue against it for patent > assertions). Just because you, and, presumably, your company has not been > approached for licensing revenues does not mean that no one else has. > Why did you separate my sentance that said essentially the same thing? > I would also be careful to name anyone who is exercising one's legal right > to enforce a patent a "vulture". People have been sued for even using the > much more frequently used word "troll". > I think you need to accuse a specific person or entity of being a vulture before having any concerns of that type. > >> Nobody can guarantee patent issues have been properly >> handled - an extra licencee was recently added to the patent pool for >> G.729. >> > > Depending on how "properly handling of patent issues" is defined, it can > sometimes be guarantied. To the best of my knowledge, there have been no > violations of the ITU patent policy in the G.729 case, to which (I believe) > you are referring to. > > There is no requirement set by the ITU (or any other SDO I'm aware of, > outside China at least) to join a patent pool, and, to the best of my > understanding of antitrust law, there cannot be such a requirement. > Well, on the subject of G.729, Toshiba was not represented in the patent pool until July 2008. Before that people licensing the relevant patents were going, in good faith, to the licence pool, to Nokia, and to NEC. It seems they should have been going to Toshiba as well. From what was published it doesn't seem too clear whether prior licensees of the pool get backdated indemnification for the Toshiba patents or not. Clearly it could have gone either way. If there is a path of doing your best to skirt around other people's patents, and a path of blundering into them and hoping for a patent pool, why would anyone suggest the later (unless they are part of the pool, of course)? Without a patent pool its a nightmare to licence patents, unless you are very big. G.723.1, for example, is something that has far less users than there might have been with a working patent pool. Its a huge pain to licence. However, as you said, antitrust laws create problems for pools. The MPEG pool was actually nurtured into existence with a helping hand from the government, because the licencing issues were such a nightmare things were not taking off. Patent holders were afraid of an antitrust backlash against a pool, before the government showed a pool had its blessing. So, the path of choosing an overtly patented option is hardly a smooth path. >> Patent holders can always crawl out of the woodwork. >> > > That is true. > > >> However, >> saying the chances of success are extremely small is ****EXTREMELY**** >> defeatist. >> > > I agree with Joel, and disagree with you, that the chances are "extremely" > small, based on my own experience (which, quite obviously is not the same as > yours.) > Codecs are a patent minefield. No question there. You only need to fall foul of a single obscure patent somewhere or other to have trouble. In that regard almost all engineering is a minefield, but the codec mines are more closely spaced than most. Nonetheless, there are codecs around offering good quality, which people have not been able to challenge after trying really hard. They really really tried with Vorbis, and they failed. When they couldn't attack it legally, there was a smear campaign. It survived, though. Its not an easy path, but its not impossible, >> Why not just give up on life and end it all? :-) >> > > Because at least my life is not dependent on an IETF project towards a > open-source friendly codec RFC. If yours is, I would be ****EXTRENELY**** > sorry for you. :-) > > Regards, > Stephan > What's life without interesting challenges? :-) > > >> Steve >> >>> Jean-Marc Valin wrote: >>> >>>> Hi Stephen, >>>> >>> ... >>> >>>> In my opinion, IPR alone would be sufficient. But at the same time I >>>> agree that if we're going to standardise codecs, they might as well >>>> be targeted specifically for the Internet. The goals of MPEG and >>>> ITU-T are very different and I would expect this WG to have goals >>>> that are different from both. >>>> >>>> Cheers, >>>> >>>> Jean-Marc Steve From jmh@joelhalpern.com Wed Jul 15 12:14:36 2009 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 358653A69CD for ; Wed, 15 Jul 2009 12:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 wCNSnlVX7Pjf for ; Wed, 15 Jul 2009 12:14:35 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F04433A6A56 for ; Wed, 15 Jul 2009 12:13:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 90A2C430403 for ; Wed, 15 Jul 2009 12:12:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7E04F4303FD for ; Wed, 15 Jul 2009 12:12:43 -0700 (PDT) Message-ID: <4A5E2A27.6030002@joelhalpern.com> Date: Wed, 15 Jul 2009 15:12:39 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:14:36 -0000 A standard is not an implementation. I know that reference implementations are often useful. However, the IETF does not generally identify or mandate reference implementations. We look for implementations. We want interoperable implementations. (In fact, there is an argument that a reference implementation may even undermine the quality of the specification, as we are much less likely to see two completely independent implementations from the specifications, which is our preferred way of judging the quality of our documents.) I am quite sympathetic to the goal of having a standard that can be implemented by anyone who wants to, without payment or negotiation with anyone else. (My opinion on the likelihood of the outcome using the IETF process has been stated clearly elsewhere.) It is quite a leap from there to requiring the existence of an open source reference implementation. If one exists, that's nice. But I do not see why that should be a decision criterion for the working group. (Note that the presence of absence of such an implementation does not tell us anything about the actual IPR situation, so it does not help with the claimed concerns.) Returning to my comment above, if the spec can not be interoperably implemented from the specification, then we need a better document before it becomes an RFC. So that value of a "reference implementation" seems doubtful to me. Yours, Joel M. Halpern Slava Borilin wrote: > > > Stephan, > > > > The goals (of WG and codec) should be driven by customer demand, not by > potential contributors – so Henry got the point that customers want to > have open-source, if feasible. If there are means to get open-source and > satisfy other goals of the codec, then it does not matter then “many did > not contribute because they do not do open source”. > > > > We should remove “open source” only in the case when it is NOT feasible > to achieve other codec performance targets by any open-source solutions > (current or to be developed). > > > > best regards, > > Slava Borilin > > * From: * codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *Stephan Wenger > *Sent:* Wednesday, July 15, 2009 10:36 PM > *To:* Henry Sinnreich; codec@ietf.org > *Subject:* Re: [codec] useful for Internet applications with voice > > > > Hi Henry, > I would object to any charter proposal that requires an “open source > reference implementation”, because it unfairly excludes from IETF’s > standard process all those companies which, on principle, do not > contribute to open source. > You may also wish to clarify the sentence “is available for use without > patent license fees or any other known IPR constraints, ”. Isn’t this > what you really want to say: “a voice codec whose known IPR is available > under terms compatible with all major open source licenses”? > Regards, > Stephan > > > On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: > > Just to make clear my company’s position: > > We’re supportive of the efforts to arrive at a selection of a preferred > codec for voice over the Internet, as proposed for the Voice Codec BOF. > To accommodate the broadest possible community, we support the selection > of a voice codec which > > > * has a broad range of audio bandwidths, with no more than 30ms and > preferably lower delay, > * can be implemented efficiently, > * is available for use without patent license fees or any other > known IPR constraints, > * has an open source reference implementation, > * works over the Internet. > > > > We think several voice codecs have been proposed which seem to meet > those requirements, and hope that the working group can produce the > standard for an Internet voice codec along these lines. > > Henry Sinnreich > Adobe Systems, Inc. > > > > _______________________________________________ > 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 hsinnrei@adobe.com Wed Jul 15 12:23:45 2009 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 454D33A67CF for ; Wed, 15 Jul 2009 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4UDwjCkWNSZ for ; Wed, 15 Jul 2009 12:23:39 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id D61E33A6A56 for ; Wed, 15 Jul 2009 12:23:37 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKSl4sVNGuMFDfF4RPHBfDuMV2FI54g9Sf@postini.com; Wed, 15 Jul 2009 12:24:12 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FJFWao007969; Wed, 15 Jul 2009 12:15:32 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FJLtlT026283; Wed, 15 Jul 2009 12:21:55 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 15 Jul 2009 12:21:55 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 15 Jul 2009 12:21:55 -0700 From: Henry Sinnreich To: Brian West Date: Wed, 15 Jul 2009 12:21:53 -0700 Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFgM6CUsnXu3KBTzeADUGEaMcmRwAALPjh Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68396814E3Bhsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:23:45 -0000 --_000_C68396814E3Bhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, >Remember you have to also think about how this works on the server side. = And don't get me wrong I run at 20ms but its not feasible to run sub 10ms i= f you wish to scale on a server application. There is a long argument about client-side implementations being faster tha= n server-side ones. But this another topic. Henry On 7/15/09 2:16 PM, "Brian West" wrote: On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote: >has a broad range of audio bandwidths, with no more than 30ms and preferab= ly lower delay, >I can agree with this but it should be noted that higher ptimes are prefer= red in some cases... (My individual contributor's hat on) Codec delay less than 30 ms is still desirable in certain interactive scena= rios, especially where the network delay is small (locality). * Financial, stock and commodity trading desks, * Games with voice, * Digital living room and a heated discussion is going on :-) fortunately the end user will not hear any perceived delay with anything le= ss than about 100-200ms in the first place. Using anything less than 10ms= over the public internet is worthless... I have personally tried CELT at 1= ms, 2ms and 5ms over the public internet. You do not gain anything from do= ing this in fact you get very messed up audio unless you put a jitter buffe= r on the far end also which then again more delay added. The implementatio= n we did in FreeSWITCH with CELT can do 2,4,6,8 and 10ms but in reality any= thing below 10 doesn't work out well without a jitter buffer over the publi= c internet. Local network we did 1ms with no problem. I will argue that less than 10ms is a waste of bandwidth, CPU and context s= witches. You're copying sub 10ms chunks of audio in and out of kernel spac= e and that will never scale. Remember you have to also think about how thi= s works on the server side. And don't get me wrong I run at 20ms but its n= ot feasible to run sub 10ms if you wish to scale on a server application. /b Any extra delay may add irritation to a discussion. This should also count for conferencing/telepresence. Besides, one of the proposed codecs has <10 ms delay. Henry --_000_C68396814E3Bhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] useful for Internet applications with voice Brian,

>Remember you have to also think about how this works o= n the server side.  And don't get me wrong I run at 20ms but its not f= easible to run sub 10ms if you wish to scale on a server application.

There is a long argument about client-side implementations being faster tha= n server-side ones.
But this another topic.

Henry


On 7/15/09 2:16 PM, "Brian West" <brian@freeswitch.org> wrote:


On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote:

>has a broad range of audio bandwidths, with no more than 30= ms and preferably lower delay,
>I can agree with this but = it should be noted that higher ptimes are preferred in some cases...

(My individual contributor’s hat on)

Codec delay less than 30 ms is still desirable in certain interactive scena= rios, especially where the network delay is small (locality).
  • Financial, stock and commodity trading desks,
  • Games with voice,
  • Digital living room and a heated discussion is goin= g on :-)
fortunately the end user will not hear a= ny perceived delay with anything less than about 100-200ms in the first pla= ce.   Using anything less than 10ms over the public internet is w= orthless... I have personally tried CELT at 1ms, 2ms and 5ms over the publi= c internet.  You do not gain anything from doing this in fact you get = very messed up audio unless you put a jitter buffer on the far end also whi= ch then again more delay added.  The implementation we did in FreeSWIT= CH with CELT can do 2,4,6,8 and 10ms but in reality anything below 10 doesn= 't work out well without a jitter buffer over the public internet.  Lo= cal network we did 1ms with no problem.

I will argue that less than 10ms is a waste of bandwidth, CPU and context s= witches.  You're copying sub 10ms chunks of audio in and out of kernel= space and that will never scale.  Remember you have to also think abo= ut how this works on the server side.  And don't get me wrong I run at= 20ms but its not feasible to run sub 10ms if you wish to scale on a server= application.

/b



Any extra delay may add irritation to a dis= cussion.
This should also count for conferencing/telepresence.
Besides, one of the proposed codecs has <10 ms delay.

Henry
Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:24:21 -0000 --Apple-Mail-25-942744381 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote: > >has a broad range of audio bandwidths, with no more than 30ms and =20 > preferably lower delay, > >I can agree with this but it should be noted that higher ptimes are =20= > preferred in some cases... > > (My individual contributor=92s hat on) > > Codec delay less than 30 ms is still desirable in certain =20 > interactive scenarios, especially where the network delay is small =20 > (locality). > Financial, stock and commodity trading desks, > Games with voice, > Digital living room and a heated discussion is going on :-) fortunately the end user will not hear any perceived delay with =20 anything less than about 100-200ms in the first place. Using =20 anything less than 10ms over the public internet is worthless... I =20 have personally tried CELT at 1ms, 2ms and 5ms over the public =20 internet. You do not gain anything from doing this in fact you get =20 very messed up audio unless you put a jitter buffer on the far end =20 also which then again more delay added. The implementation we did in =20= FreeSWITCH with CELT can do 2,4,6,8 and 10ms but in reality anything =20 below 10 doesn't work out well without a jitter buffer over the public =20= internet. Local network we did 1ms with no problem. I will argue that less than 10ms is a waste of bandwidth, CPU and =20 context switches. You're copying sub 10ms chunks of audio in and out =20= of kernel space and that will never scale. Remember you have to also =20= think about how this works on the server side. And don't get me wrong =20= I run at 20ms but its not feasible to run sub 10ms if you wish to =20 scale on a server application. /b > Any extra delay may add irritation to a discussion. > This should also count for conferencing/telepresence. > Besides, one of the proposed codecs has <10 ms delay. > > Henry --Apple-Mail-25-942744381 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 15, 2009, = at 2:07 PM, Henry Sinnreich wrote:

>has a broad range of audio = bandwidths, with no more than 30ms and preferably lower delay, 
>I can agree with this but it should be = noted that higher ptimes are preferred in some cases... 

(My individual = contributor=92s hat on)

Codec delay less than 30 ms is still = desirable in certain interactive scenarios, especially where the network = delay is small (locality).
  • Financial, = stock and commodity trading desks,
  • Games with voice,
  • Digital = living room and a heated discussion is going on :-) 
fortunately the end user = will not hear any perceived delay with anything less than about = 100-200ms in the first place. Using anything less than 10ms over the = public internet is worthless... I have personally tried CELT at 1ms, 2ms = and 5ms over the public internet. You do not gain anything from doing = this in fact you get very messed up audio unless you put a jitter buffer = on the far end also which then again more delay added. The = implementation we did in FreeSWITCH with CELT can do 2,4,6,8 and 10ms = but in reality anything below 10 doesn't work out well without a jitter = buffer over the public internet. Local network we did 1ms with no = problem.

I will argue that less than 10ms is a waste of bandwidth, CPU and = context switches. You're copying sub 10ms chunks of audio in and out of = kernel space and that will never scale. Remember you have to also think = about how this works on the server side. And don't get me wrong I run = at 20ms but its not feasible to run sub 10ms if you wish to scale on a = server application.

/b



Any extra delay may = add irritation to a discussion. 
This should also count = for conferencing/telepresence.
Besides, one of the proposed codecs = has <10 ms = delay.

Henry

= --Apple-Mail-25-942744381-- From stewe@stewe.org Wed Jul 15 12:45:15 2009 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 4DDA028C143 for ; Wed, 15 Jul 2009 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 W2b7N8JBSUOp for ; Wed, 15 Jul 2009 12:45:09 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 015A83A6AA4 for ; Wed, 15 Jul 2009 12:45:08 -0700 (PDT) Received: from [192.168.1.110] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 342233-1743317 for multiple; Wed, 15 Jul 2009 21:43:56 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 12:43:39 -0700 From: Stephan Wenger To: Henry Sinnreich , "codec@ietf.org" Message-ID: Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2fAAEv1cAAAVMnGwABBo9k In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330506635_1013819" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:45:15 -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_3330506635_1013819 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, Antitrust is all about business decisions, albeit the wrong ones... Stephan On 7/15/09 12:14 PM, "Henry Sinnreich" wrote: >> >I would object to any charter proposal that requires an =B3open source >> reference implementation=B2, >> >because it unfairly excludes from IETF=B9s standard process all those >> companies which, on principle, do not contribute to open source. > =20 > (my individual contributor hat on) > This is their business decision. > Other companies chose to support and contribute to open source; also a > business decision. >=20 > The real value from an engineering point of view is that written code is = so > much more precise and useful than endless verbiage in documents and maili= ng > lists IMO. If in doubt, let=B9s count our emails today on various WG lists.= .. >=20 > Henry >=20 >=20 > On 7/15/09 1:36 PM, "Stephan Wenger" wrote: >=20 >> Hi Henry, >> I would object to any charter proposal that requires an =B3open source >> reference implementation=B2, because it unfairly excludes from IETF=B9s stan= dard >> process all those companies which, on principle, do not contribute to op= en >> source.=20 >> You may also wish to clarify the sentence =B3is available for use without >> patent license fees or any other known IPR constraints, =B2. Isn=B9t this w= hat >> you really want to say: =B3a voice codec whose known IPR is available unde= r >> terms compatible with all major open source licenses=B2? >> Regards, >> Stephan >>=20 >>=20 >> On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: >>=20 >>> Just to make clear my company=B9s position: >>>=20 >>> We=B9re supportive of the efforts to arrive at a selection of a preferred >>> codec for voice over the Internet, as proposed for the Voice Codec BOF. >>> To accommodate the broadest possible community, we support the selectio= n of >>> a voice codec which >>> =20 >>> * has a broad range of audio bandwidths, with no more than 30ms and >>> preferably lower delay, >>> * can be implemented efficiently, >>> * is available for use without patent license fees or any other known I= PR >>> constraints,=20 >>> * has an open source reference implementation, >>> * works over the Internet. >>>=20 >>>> We think several voice codecs have been proposed which seem to meet th= ose >>>> requirements, and hope that the working group can produce the standard= for >>>> an Internet voice codec along these lines. >>>>=20 >>>> Henry Sinnreich >>>> Adobe Systems, Inc. >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 --B_3330506635_1013819 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] useful for Internet applications with voice Hi Henry,
Antitrust is all about business decisions, albeit the wrong ones...
Stephan



On 7/15/09 12:14 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"5">>I would object to any charter proposal that requires an “= ;open source reference implementation”,
>because it unfairly excludes from IETF’s standard process all tho= se companies which, on principle, do not contribute to open source.
 
(my individual contribut= or hat on)
This is their business decision.
Other companies chose to support and contribute to open source; also a busi= ness decision.

The real value from an engineering point of view is that written code is so= much more precise and useful than endless verbiage in documents and mailing= lists IMO. If in doubt, let’s count our emails today on various WG li= sts...

Henry


On 7/15/09 1:36 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Henry,
I would object to any charter proposal that requires an “open source = reference implementation”, because it unfairly excludes from IETF̵= 7;s standard process all those companies which, on principle, do not contrib= ute to open source.
You may also wish to clarify the sentence “is available for use witho= ut patent license fees or any other known IPR constraints, ”.  Is= n’t this what you really want to say: “a voice codec whose known= IPR is available under terms compatible with all major open source licenses= ”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"4">Just to make clear my companyR= 17;s position:

We’re supportive of the efforts to arrive at a selection of a preferr= ed codec for voice over the Internet, as proposed for the Voice Codec BOF. <= BR> To accommodate the broadest possible community, we support the selection of= a voice codec which
 
  • has a broad range of audio ban= dwidths, with no more than 30ms and preferably lower delay,=20
  • can be implemented efficiently,=20
  • is available for use without paten= t license fees or any other known IPR constraints,=20
  • has an open source reference imple= mentation,=20
  • works over the Internet.
<= FONT SIZE=3D"4">
We think several voice cod= ecs have been proposed which seem to meet those requirements, and hope that = the working group can produce the standard for an Internet voice codec along= these lines.

Henry Sinnreich
Adobe Systems, Inc.


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec


--B_3330506635_1013819-- From stephen.botzko@gmail.com Wed Jul 15 12:48:38 2009 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 4A3233A6C3A for ; Wed, 15 Jul 2009 12:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 LTX67cocUK7j for ; Wed, 15 Jul 2009 12:48:37 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 62EC93A6C2C for ; Wed, 15 Jul 2009 12:48:36 -0700 (PDT) Received: by fxm18 with SMTP id 18so3673703fxm.37 for ; Wed, 15 Jul 2009 12:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zGTG8ycMLmRjJogJ2U/s/TeI8WJGK+k4XAziWEhHVSA=; b=tVyOM31Jwh2DH0QoZW4hH/1NUXBOed2EDbdjhT/yQdxDbVELnR4UQ4YM0UGNbCoZ0+ GNtHlLNgyDLncc+rseSWc9DzHq1GWPX1PmtACEZ9mUyCRZ1eshjuJhK1ovkYtoj6mMHt 7vFTSX1HtOPOM9894n6C2ww5O3dd+JTBpLQNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sPRUWTffrbtGtxzripBG/zcvPOEchfLXbJyBi5bx0lXPeRPYVN5XMd+F82cWL8Yp/7 BKA5CChmy96zyHPu0b9rq7cO2jS7c0wWldOVZKacNeVWrsFxnQFGGstynavdle9HzgcV SDLReJHI+AlNdBvSyGqRI0SysPru+B75O08Pk= MIME-Version: 1.0 Received: by 10.103.181.9 with SMTP id i9mr4248354mup.15.1247687160874; Wed, 15 Jul 2009 12:46:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jul 2009 15:46:00 -0400 Message-ID: <6e9223710907151246g7a058a6ufef6b4154e375e21@mail.gmail.com> From: stephen botzko To: Slava Borilin Content-Type: multipart/alternative; boundary=00163641671b03c836046ec3ce18 Cc: codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:48:38 -0000 --00163641671b03c836046ec3ce18 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm with Stephan on this. If working groups are allowed to add constraints that prevent reasonable companies currently involved in the IETF from participating in the group, then that is a HUGE problem. Participation has to be inclusive. Stephen Botzko Polycom On Wed, Jul 15, 2009 at 3:00 PM, Slava Borilin wrote= : > Stephan, > > > > The goals (of WG and codec) should be driven by customer demand, not by > potential contributors =96 so Henry got the point that customers want to = have > open-source, if feasible. If there are means to get open-source and satis= fy > other goals of the codec, then it does not matter then =93many did not > contribute because they do not do open source=94. > > > > We should remove =93open source=94 only in the case when it is NOT feasib= le to > achieve other codec performance targets by any open-source solutions > (current or to be developed). > > > > best regards, > > Slava Borilin > ------------------------------ > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Stephan Wenger > *Sent:* Wednesday, July 15, 2009 10:36 PM > *To:* Henry Sinnreich; codec@ietf.org > *Subject:* Re: [codec] useful for Internet applications with voice > > > > Hi Henry, > I would object to any charter proposal that requires an =93open source > reference implementation=94, because it unfairly excludes from IETF=92s s= tandard > process all those companies which, on principle, do not contribute to ope= n > source. > You may also wish to clarify the sentence =93is available for use without > patent license fees or any other known IPR constraints, =94. Isn=92t thi= s what > you really want to say: =93a voice codec whose known IPR is available und= er > terms compatible with all major open source licenses=94? > Regards, > Stephan > > > On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: > > Just to make clear my company=92s position: > > We=92re supportive of the efforts to arrive at a selection of a preferred > codec for voice over the Internet, as proposed for the Voice Codec BOF. > To accommodate the broadest possible community, we support the selection = of > a voice codec which > > > - has a broad range of audio bandwidths, with no more than 30ms and > preferably lower delay, > - can be implemented efficiently, > - is available for use without patent license fees or any other known > IPR constraints, > - has an open source reference implementation, > - works over the Internet. > > > > We think several voice codecs have been proposed which seem to meet those > requirements, and hope that the working group can produce the standard fo= r > an Internet voice codec along these lines. > > Henry Sinnreich > Adobe Systems, Inc. > > > ------------------------------ > > _______________________________________________ > 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 > > --00163641671b03c836046ec3ce18 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm with Stephan on this.

If working groups are allowed to add c= onstraints that prevent reasonable companies currently involved in the IETF= from participating in the group, then that is a HUGE problem.

Parti= cipation has to be inclusive.

Stephen Botzko
Polycom

On Wed, Jul= 15, 2009 at 3:00 PM, Slava Borilin <Borilin@spiritdsp.com> wrote:

Stephan,

=A0

The goals (of WG an= d codec) should be driven by customer demand, not by potential contributors = =96 so Henry got the point that customers want to have open-source, if feasible= . If there are means to get open-source and satisfy other goals of the codec, th= en it does not matter then =93many did not contribute because they do not do open source=94.

=A0

We should remove = =93open source=94 only in the case when it is NOT feasible to achieve other codec performance targets by any open-source solutions (current or to be develope= d).

=A0

best regards,

Slava Borilin

From:= codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of Stephan Wenger
Sent: Wednesday, July 15, = 2009 10:36 PM
To: Henry Sinnreich; codec@ietf.org
Subject: Re: [codec] usefu= l for Internet applications with voice<= /p>

=A0

Hi Henry,
I would object to any charter proposal that requires an =93open source reference implementation=94, because it unfairly excludes from IETF=92s standard process all those companies which, on principle, do not contribute= to open source.
You may also wish to clarify the sentence =93is available for use without patent license fees or any other known IPR constraints, =94. =A0Isn=92t this what you really want to say: =93a voice codec whose known IPR is available under terms compatible with all major open source licenses=94?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:<= /font>

Just to make clear my company=92s position:

We=92re supportive of the efforts to arrive at a selection of a preferred codec for voice over the Internet, as proposed for the Voice Codec BOF. To accommodate the broadest possible community, we support the selection of= a voice codec which
=A0

  • has a broad range of audio bandwidths, with no more than 30ms and preferably lower delay,
  • can be implemented efficiently,
  • is available for use without patent license fees or any other known IPR constraints,
  • has an open source reference implementation,
  • works over the Internet.

=A0

We think several voice code= cs have been proposed which seem to meet those requirements, and hope that the work= ing group can produce the standard for an Internet voice codec along these line= s.

Henry Sinnreich
Adobe Systems, Inc.

=A0

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


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


--00163641671b03c836046ec3ce18-- From hoene@uni-tuebingen.de Wed Jul 15 12:52:24 2009 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 EFF7D3A6BAC for ; Wed, 15 Jul 2009 12:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 5zaA4nkwH4AG for ; Wed, 15 Jul 2009 12:52:24 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 070263A6809 for ; Wed, 15 Jul 2009 12:52:23 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FJoP6O027659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Jul 2009 21:50:32 +0200 From: "Christian Hoene" To: Date: Wed, 15 Jul 2009 21:50:16 +0200 Message-ID: <00b101ca0585$7dfb9770$79f2c650$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFhS82kvyMj3rAQA+El2O2TLapqg== Content-Language: de x-cr-hashedpuzzle: aOw= AMCu Ac0B BH0I BXsS Bhk7 BnmP B8jD DdKQ Ds5w Dt3E D6ht Fz7C Hafo IYfK Is4C; 1; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {6A7CA3C9-A7FE-4B6B-8386-DF3E79E3198E}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Wed, 15 Jul 2009 19:50:12 GMT; dABlAHMAdABpAG4AZwA= x-cr-puzzleid: {6A7CA3C9-A7FE-4B6B-8386-DF3E79E3198E} X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-xAnf6Z Subject: [codec] testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:52:25 -0000 Does the IETF use a spam filter? I miss some of my emails... From stewe@stewe.org Wed Jul 15 12:52:29 2009 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 47CC128C14E for ; Wed, 15 Jul 2009 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 OGP+5q2rFDhC for ; Wed, 15 Jul 2009 12:52:21 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id D307F3A6BF9 for ; Wed, 15 Jul 2009 12:52:20 -0700 (PDT) Received: from [192.168.1.110] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 342240-1743317 for multiple; Wed, 15 Jul 2009 21:50:25 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 12:50:19 -0700 From: Stephan Wenger To: Henry Sinnreich , "codec@ietf.org" Message-ID: Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2fAAEv1cAAAVMnGwABQioK In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330507024_1053368" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:52:29 -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_3330507024_1053368 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, I think I need to row back a bit regarding the open source license stuff (and advance my bigger case at the same time). Since just recently (RFC 5378), the RFC editor attaches a BSD-style license (undoubtly an open source license) to any piece of code that appears in an IETF RFC. This is known to any contributor, and not a WG-specific. The main application for this, and, based on my recollection, the intention of the IPR WG at the time, has been to allow open source projects to use small code snippets of code that hardly could contain a patent right. But that=B9s beside the point= , I fear. Now, BSD-style licenses are believed at least by some to include a= n implicit grant to patent rights owned by the Contributor of the code. Let me just assume that these folks are correct. The result could well be that any major contribution towards an RFC whose normative content lies in the reference code would include the implicit grant of patent rights. In this light, I cannot reasonably hold up my previous objection against a principle of requiring an open-source licensed implementation, and argue at the same time (as I have before) that specifying a bit-exact codec is best done through source code. At the same time, I don=B9t believe that we are on safe ground when excluding all those folks that are not prepared to contribute to a reference implementation, but are prepared to contribute to the IETF=B9s standardization process as it stands. What it boils down to (for me), once again, is that the IETF is the wrong organization for this work. Regards, Stephan P.s.: (I have no idea what would happen in a courtroom if one would contribute to something made available, as part of an IETF RFC, under a BSD style license and, at the same time, explicitly announces that patent right= s are available only under RAND terms. But that=B9s a side discussion not necessarily appropriate for this forum.) On 7/15/09 12:14 PM, "Henry Sinnreich" wrote: >> >I would object to any charter proposal that requires an =B3open source >> reference implementation=B2, >> >because it unfairly excludes from IETF=B9s standard process all those >> companies which, on principle, do not contribute to open source. > =20 > (my individual contributor hat on) > This is their business decision. > Other companies chose to support and contribute to open source; also a > business decision. >=20 > The real value from an engineering point of view is that written code is = so > much more precise and useful than endless verbiage in documents and maili= ng > lists IMO. If in doubt, let=B9s count our emails today on various WG lists.= .. >=20 > Henry >=20 >=20 > On 7/15/09 1:36 PM, "Stephan Wenger" wrote: >=20 >> Hi Henry, >> I would object to any charter proposal that requires an =B3open source >> reference implementation=B2, because it unfairly excludes from IETF=B9s stan= dard >> process all those companies which, on principle, do not contribute to op= en >> source.=20 >> You may also wish to clarify the sentence =B3is available for use without >> patent license fees or any other known IPR constraints, =B2. Isn=B9t this w= hat >> you really want to say: =B3a voice codec whose known IPR is available unde= r >> terms compatible with all major open source licenses=B2? >> Regards, >> Stephan >>=20 >>=20 >> On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: >>=20 >>> Just to make clear my company=B9s position: >>>=20 >>> We=B9re supportive of the efforts to arrive at a selection of a preferred >>> codec for voice over the Internet, as proposed for the Voice Codec BOF. >>> To accommodate the broadest possible community, we support the selectio= n of >>> a voice codec which >>> =20 >>> * has a broad range of audio bandwidths, with no more than 30ms and >>> preferably lower delay, >>> * can be implemented efficiently, >>> * is available for use without patent license fees or any other known I= PR >>> constraints,=20 >>> * has an open source reference implementation, >>> * works over the Internet. >>>=20 >>>> We think several voice codecs have been proposed which seem to meet th= ose >>>> requirements, and hope that the working group can produce the standard= for >>>> an Internet voice codec along these lines. >>>>=20 >>>> Henry Sinnreich >>>> Adobe Systems, Inc. >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 --B_3330507024_1053368 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] useful for Internet applications with voice Hi Henry,

I think I need to row back a bit regarding the open source license stuff (a= nd advance my bigger case at the same time).  Since just recently (RFC = 5378), the RFC  editor attaches a BSD-style license (undoubtly an open = source license) to any piece of code that appears in an IETF RFC.  This= is known to any contributor, and not a WG-specific.  The main applicat= ion for this, and, based on my recollection, the intention of the IPR WG at = the time, has been to allow open source projects to use small code snippets = of code that hardly could contain a patent right.  But that’s bes= ide the point, I fear.  Now, BSD-style licenses are believed at least b= y some to include an implicit grant to patent rights owned by the Contributo= r of the code.  Let me just assume that these folks are correct.  = The result could well be that any major contribution towards an RFC whose no= rmative content  lies in the reference code would include the implicit = grant of patent rights.  

In this light, I cannot reasonably hold up my previous objection against a = principle of requiring an open-source licensed implementation, and argue at = the same time (as I have before) that specifying a bit-exact codec is best d= one through source code.  At the same time, I don’t believe that = we are on safe ground when excluding all those folks that are not prepared t= o contribute to a reference implementation, but are prepared to contribute t= o the IETF’s standardization process as it stands.

What it boils down to (for me), once again, is that the IETF is the wrong o= rganization for this work.

Regards,
Stephan

P.s.: (I have no idea what would happen in a courtroom if one would contrib= ute to something made available, as part of an IETF RFC, under a BSD style l= icense and, at the same time, explicitly announces that patent rights are av= ailable only under RAND terms.  But that’s a side discussion not = necessarily appropriate for this forum.)






On 7/15/09 12:14 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"5">>I would object to any charter proposal that requires an “= ;open source reference implementation”,
>because it unfairly excludes from IETF’s standard process all tho= se companies which, on principle, do not contribute to open source.
 
(my individual contribut= or hat on)
This is their business decision.
Other companies chose to support and contribute to open source; also a busi= ness decision.

The real value from an engineering point of view is that written code is so= much more precise and useful than endless verbiage in documents and mailing= lists IMO. If in doubt, let’s count our emails today on various WG li= sts...

Henry


On 7/15/09 1:36 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Henry,
I would object to any charter proposal that requires an “open source = reference implementation”, because it unfairly excludes from IETF̵= 7;s standard process all those companies which, on principle, do not contrib= ute to open source.
You may also wish to clarify the sentence “is available for use witho= ut patent license fees or any other known IPR constraints, ”.  Is= n’t this what you really want to say: “a voice codec whose known= IPR is available under terms compatible with all major open source licenses= ”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"4">Just to make clear my companyR= 17;s position:

We’re supportive of the efforts to arrive at a selection of a preferr= ed codec for voice over the Internet, as proposed for the Voice Codec BOF. <= BR> To accommodate the broadest possible community, we support the selection of= a voice codec which
 
  • has a broad range of audio ban= dwidths, with no more than 30ms and preferably lower delay,=20
  • can be implemented efficiently,=20
  • is available for use without paten= t license fees or any other known IPR constraints,=20
  • has an open source reference imple= mentation,=20
  • works over the Internet.
<= FONT SIZE=3D"4">
We think several voice cod= ecs have been proposed which seem to meet those requirements, and hope that = the working group can produce the standard for an Internet voice codec along= these lines.

Henry Sinnreich
Adobe Systems, Inc.


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec


--B_3330507024_1053368-- From Borilin@spiritdsp.com Wed Jul 15 12:58:30 2009 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 C34F828C165 for ; Wed, 15 Jul 2009 12:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 WLa8-IS05DPV for ; Wed, 15 Jul 2009 12:58:26 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 00B293A6BF9 for ; Wed, 15 Jul 2009 12:58:24 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6FJmBa8049443; Wed, 15 Jul 2009 23:48:11 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0585.2B4854F1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Jul 2009 23:48:01 +0400 Message-ID: In-Reply-To: <6e9223710907151246g7a058a6ufef6b4154e375e21@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFhOYWKOb6ZsXqR6ihFM8Pin4CxwAADdDA References: <6e9223710907151246g7a058a6ufef6b4154e375e21@mail.gmail.com> From: "Slava Borilin" To: "stephen botzko" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:58:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0585.2B4854F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any company can make a business decision to participate in open-source- nobody but them limit their freedom here =20 best regards, Slava Borilin ________________________________ From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, July 15, 2009 11:46 PM To: Slava Borilin Cc: Stephan Wenger; Henry Sinnreich; codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice =20 I'm with Stephan on this. If working groups are allowed to add constraints that prevent reasonable companies currently involved in the IETF from participating in the group, then that is a HUGE problem. Participation has to be inclusive. Stephen Botzko Polycom On Wed, Jul 15, 2009 at 3:00 PM, Slava Borilin wrote: Stephan, =20 The goals (of WG and codec) should be driven by customer demand, not by potential contributors - so Henry got the point that customers want to have open-source, if feasible. If there are means to get open-source and satisfy other goals of the codec, then it does not matter then "many did not contribute because they do not do open source". =20 We should remove "open source" only in the case when it is NOT feasible to achieve other codec performance targets by any open-source solutions (current or to be developed). =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Wednesday, July 15, 2009 10:36 PM To: Henry Sinnreich; codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice =20 Hi Henry, I would object to any charter proposal that requires an "open source reference implementation", because it unfairly excludes from IETF's standard process all those companies which, on principle, do not contribute to open source.=20 You may also wish to clarify the sentence "is available for use without patent license fees or any other known IPR constraints, ". Isn't this what you really want to say: "a voice codec whose known IPR is available under terms compatible with all major open source licenses"? Regards, Stephan On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: Just to make clear my company's position: We're supportive of the efforts to arrive at a selection of a preferred codec for voice over the Internet, as proposed for the Voice Codec BOF.=20 To accommodate the broadest possible community, we support the selection of a voice codec which=20 =20 * has a broad range of audio bandwidths, with no more than 30ms and preferably lower delay,=20 * can be implemented efficiently,=20 * is available for use without patent license fees or any other known IPR constraints,=20 * has an open source reference implementation,=20 * works over the Internet.=20 =20 We think several voice codecs have been proposed which seem to meet those requirements, and hope that the working group can produce the standard for an Internet voice codec along these lines. =09 Henry Sinnreich Adobe Systems, Inc. =20 ________________________________ _______________________________________________ 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 =20 ------_=_NextPart_001_01CA0585.2B4854F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any company can = make a business decision to participate in open-source- nobody but them limit = their freedom here

 =

best regards,

Slava = Borilin

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, July 15, = 2009 11:46 PM
To: Slava Borilin
Cc: Stephan Wenger; Henry Sinnreich; codec@ietf.org
Subject: Re: [codec] = useful for Internet applications with voice

 

I'm with = Stephan on this.

If working groups are allowed to add constraints that prevent reasonable companies currently involved in the IETF from participating in the = group, then that is a HUGE problem.

Participation has to be inclusive.

Stephen Botzko
Polycom

On Wed, Jul 15, 2009 at 3:00 PM, Slava Borilin <Borilin@spiritdsp.com> = wrote:

Stephan,

 

The goals (of WG and codec) should be = driven by customer demand, not by potential contributors – so Henry got the = point that customers want to have open-source, if feasible. If there are means to = get open-source and satisfy other goals of the codec, then it does not = matter then “many did not contribute because they do not do open = source”.

 

We should remove “open source” = only in the case when it is NOT feasible to achieve other codec performance targets by = any open-source solutions (current or to be = developed).

 

best regards,

Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan = Wenger
Sent: Wednesday, July 15, = 2009 10:36 PM
To: Henry Sinnreich; codec@ietf.org
Subject: Re: [codec] = useful for Internet applications with voice

 

Hi Henry,
I would object to any charter proposal that requires an “open = source reference implementation”, because it unfairly excludes from IETF’s = standard process all those companies which, on principle, do not contribute to open source. =
You may also wish to clarify the sentence “is available for use = without patent license fees or any other known IPR constraints, ”. =  Isn’t this what you really want to say: “a voice codec whose known IPR is available = under terms compatible with all major open source licenses”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

Just to make clear my company’s position:

We’re supportive of the efforts to arrive at a selection of a = preferred codec for voice over the Internet, as proposed for the Voice Codec BOF.
To accommodate the broadest possible community, we support the selection = of a voice codec which
 

  • has a broad range of audio bandwidths, = with no more than 30ms and preferably lower delay, =
  • can be implemented efficiently, =
  • is available for use without patent = license fees or any other known IPR constraints, =
  • has an open source reference = implementation,
  • works over the Internet. =

 

We think several voice = codecs have been proposed which seem to meet those requirements, and hope that the = working group can produce the standard for an Internet voice codec along these = lines.

Henry Sinnreich
Adobe Systems, Inc.

 <= /o:p>

_________________________= ______________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec<= /font>


_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------_=_NextPart_001_01CA0585.2B4854F1-- From stpeter@stpeter.im Wed Jul 15 13:02:40 2009 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 E23173A6C38 for ; Wed, 15 Jul 2009 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 X7VsSm+Xq-hZ for ; Wed, 15 Jul 2009 13:02:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F0F383A6809 for ; Wed, 15 Jul 2009 13:02:39 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 82D214007B; Wed, 15 Jul 2009 13:45:37 -0600 (MDT) Message-ID: <4A5E31E0.4030507@stpeter.im> Date: Wed, 15 Jul 2009 13:45:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "codec@ietf.org" Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:02:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/15/09 12:36 PM, Stephan Wenger wrote: > Hi Henry, > I would object to any charter proposal that requires an “open source > reference implementationâ€, because it unfairly excludes from IETF’s > standard process all those companies which, on principle, do not > contribute to open source. Your argument is false -- the existence of an open-source reference implementation in no way excludes or prevents the existence of other implementations, whether open-source or closed-source. Your conclusion, however, might be valid, along the lines of what Joel Halpern has posted. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpeMeAACgkQNL8k5A2w/vz89QCaAyDxTz7/MhNafpcV/zfajbw0 XAoAn2crdwanFcCHdG4BpjfZVQRywyfl =wkIm -----END PGP SIGNATURE----- From brian@freeswitch.org Wed Jul 15 13:12:48 2009 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 03DE23A6F4C for ; Wed, 15 Jul 2009 13:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 52nfrKCKRb0J for ; Wed, 15 Jul 2009 13:12:47 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id E57573A6F5E for ; Wed, 15 Jul 2009 13:12:46 -0700 (PDT) Received: by ewy26 with SMTP id 26so4341658ewy.37 for ; Wed, 15 Jul 2009 13:12:40 -0700 (PDT) Received: by 10.216.2.210 with SMTP id 60mr2190907wef.21.1247685603287; Wed, 15 Jul 2009 12:20:03 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id p37sm21535486gvf.12.2009.07.15.12.20.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Jul 2009 12:20:01 -0700 (PDT) Message-Id: From: Brian West To: Henry Sinnreich In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-26-942941574 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 14:19:57 -0500 References: X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:12:48 -0000 --Apple-Mail-26-942941574 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Also I think we are confusing coding delay vs ptime in the packet on the wire. /b On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote: > Codec delay less than 30 ms is still desirable in certain > interactive scenarios, especially where the network delay is small > (locality). > Financial, stock and commodity trading desks, > Games with voice, > Digital living room and a heated discussion is going on :-) > > Any extra delay may add irritation to a discussion. > This should also count for conferencing/telepresence. > Besides, one of the proposed codecs has <10 ms delay. > > Henry --Apple-Mail-26-942941574 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Also I think we are confusing = coding delay vs ptime in the packet on the = wire.

/b

On Jul 15, 2009, at = 2:07 PM, Henry Sinnreich wrote:

Codec delay less = than 30 ms is still desirable in certain interactive scenarios, = especially where the network delay is small = (locality).
  • Financial, stock and = commodity trading desks,
  • Games with = voice,
  • Digital living room and a = heated discussion is going on :-) 
<= font face=3D"Calibri, Verdana, Helvetica, Arial">
Any extra delay may add irritation to a discussion. 
This should also count = for conferencing/telepresence.
Besides, one of the proposed codecs = has <10 ms = delay.

Henry

= --Apple-Mail-26-942941574-- From hsinnrei@adobe.com Wed Jul 15 13:22:10 2009 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 9699C3A63CB for ; Wed, 15 Jul 2009 13:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7nqH2TjQc-d for ; Wed, 15 Jul 2009 13:22:05 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id D6D0D3A6A31 for ; Wed, 15 Jul 2009 13:22:04 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKSl45yh0eQzm06B0BerPPGNKtvMGOUhth@postini.com; Wed, 15 Jul 2009 13:22:38 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FJ7PWG022619; Wed, 15 Jul 2009 12:07:26 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n6FJ7NY2006172; Wed, 15 Jul 2009 12:07:24 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Wed, 15 Jul 2009 12:07:23 -0700 From: Henry Sinnreich To: Brian West Date: Wed, 15 Jul 2009 12:07:21 -0700 Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFeRMqhFnMRqpnTheO8742ciy8OQABmd52 Message-ID: In-Reply-To: <0CCCBC19-F9AB-4270-B692-3400DD958754@freeswitch.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68393194E30hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:22:10 -0000 --_000_C68393194E30hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >has a broad range of audio bandwidths, with no more than 30ms and preferab= ly lower delay, >I can agree with this but it should be noted that higher ptimes are prefer= red in some cases... (My individual contributor's hat on) Codec delay less than 30 ms is still desirable in certain interactive scena= rios, especially where the network delay is small (locality). * Financial, stock and commodity trading desks, * Games with voice, * Digital living room and a heated discussion is going on :-) Any extra delay may add irritation to a discussion. This should also count for conferencing/telepresence. Besides, one of the proposed codecs has <10 ms delay. Henry On 7/15/09 1:21 PM, "Brian West" wrote: Comments in line. On Jul 15, 2009, at 1:02 PM, Henry Sinnreich wrote: * has a broad range of audio bandwidths, with no more than 30ms and pref= erably lower delay, I can agree with this but it should be noted that higher ptimes are preferr= ed in some cases... performance gains (network and CPU) of 30ms vs 60ms can= be seen very clearly in our testing. You have to think of the server side= that has to scale the codec to 1000's of channels per instance. * can be implemented efficiently, Do you mean low CPU requirements? * is available for use without patent license fees or any other known IP= R constraints, I think this is a requirement also. * has an open source reference implementation, The reference implementation licensing should be as broad as possible in my= opinion so its compatible with as many open source licenses as possible. * works over the Internet. We think several voice codecs have been proposed which seem to meet those r= equirements, and hope that the working group can produce the standard for a= n Internet voice codec along these lines. Henry Sinnreich Adobe Systems, Inc. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C68393194E30hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] useful for Internet applications with voice >has a broa= d range of audio bandwidths, with no more than 30ms and preferably lower de= lay,
>I can agree with this but = it should be noted that higher ptimes are preferred in some cases...

(My individual contributor’s hat on)

Codec delay less than 30 ms is still desirable in certain interactive scena= rios, especially where the network delay is small (locality).
  • Financial, stock and commodity trading desks,
  • Games with voice,
  • Digital living room and a heated discussion is goin= g on :-)

Any extra delay may add irritation to a discussion.
This should also count for conferencing/telepresence.
Besides, one of the proposed codecs has <10 ms delay.

Henry

On 7/15/09 1:21 PM, "Brian West" <brian@freeswitch.org> wrote:

Comments in line.

On Jul 15, 2009, at 1:02 PM, Henry Sinnreich wrote:

  • has a broad range = of audio bandwidths, with no more than 30ms and preferably lower delay,
I can agree with this but it s= hould be noted that higher ptimes are preferred in some cases... performanc= e gains (network and CPU) of 30ms vs 60ms can be seen very clearly in our t= esting.  You have to think of the server side that has to scale the co= dec to 1000's of channels per instance.
  • can be implemented= efficiently,
Do you mean low CPU requiremen= ts?
  • is available for u= se without patent license fees or any other known IPR constraints,
I think this is a requirement = also.
  • has an open source= reference implementation,
The reference implementation l= icensing should be as broad as possible in my opinion so its compatible wit= h as many open source licenses as possible.
  • works over the Int= ernet.
We think sever= al voice codecs have been proposed which seem to meet those requirements, a= nd hope that the working group can produce the standard for an Internet voi= ce codec along these lines.
 
 Henry Sinnreich
 Adobe Systems, Inc.
 
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:22:51 -0000 Brian West [brian@freeswitch.org] wrote: [snip] > fortunately the end user will not hear any perceived delay with anything = less than about 100-200ms in the first place. It depends on your application. 100-200ms is noticeable in pure speech app= lications and is getting into the realm where active echo cancellation is r= equired (with computation and quality implications). For interactive musical applications, per the best research available to me= it looks like 25ms total system one way delay is the bound of perception (= https://www.itm.uni-luebeck.de/users/carot/TMT08.pdf). This meshes up well = with existing practices regarding seating distances and use of a conductor = in orchestras, so I believe it to be accurate. With a 5ms frame size codec you can achieve 25ms total one way delay (hardw= are, drivers, network, jitter-buffers, etc) over a public regional network.= 10ms very likely not, and 20ms is right out. Once you've admitted that there exists a desirable delay limit every ms sha= ved off the codec algorithmic delay makes that limit easier to achieve. If = nothing else shaving a millisecond off the codec allows increases network d= iameter for a given target delay by about 200km.=20 > Using anything less than 10ms over the public internet is worthless... I = have personally tried CELT at 1ms, 2ms and 5ms=20 For strict telephony applications, probably. Wideband audio over the intern= et is more than telephony. =20 It would also be a mistake to assume that the Internet will continue to exp= erience the same absolute levels of jitter. Low delay / low jitter is alre= ady a market differentiator for VPN services, the routing hardware can now = deliver very low delay and jitter, and some improvement is guaranteed from = decreased serialization delays as core link speeds increase.=20 > over the public internet. You do not gain anything from doing this in fac= t you get very messed up audio unless you put a jitter buffer on the far en= d also which then again more delay added. You should have a jitter buffer for any real-time application. If you don't= ... well. Since packet based codecs operate with frame-size granularity a smaller fra= me size can lead to delay which is closer to jitter limited, or alternative= ly can achieve the same delay with lower jitter induced losses. > The implementation we did in FreeSWITCH with CELT can do 2,4,6,8 and 10ms= but in reality anything below 10 doesn't work out well without a jitter bu= ffer over the public internet. Local network we did 1ms with no problem. Interesting, when I last looked at the FreeSWITCH code all that was there w= as 10ms, and there were a lot of assumptions around Nx10ms packetization, i= t didn't seem easy to change. I think it would be more accurate to say that below 10ms is not very useful= if one of the end-points is windows, since currently windows's software mi= xer forces applications to a 10ms frame rate. Even on other platforms some = care is required to make sure that system software isn't really making your= delay >>10ms when you think you're operating at low delay.=20 > I will argue that less than 10ms is a waste of bandwidth, CPU and context= switches. You're copying sub 10ms chunks of audio in and out of kernel spa= ce and that will never scale. > Remember you have to also think about how this works on the server side. = And don't get me wrong I run at 20ms but its not feasible to run sub 10ms i= f you wish to scale on a server application. A codec mandating 5ms intervals wouldn't make sense for the great number of= applications where delay that low isn't relevant, but it does not follow f= rom that that it isn't desirable for the applications where lower delay is = relevant. Different things have different requirements.=20 A modern desktop system can handle conferencing a full orchestra's worth of= 5ms users. Many applications strictly are peer to peer. Etc. Operating codecs with low delay has consequences, if nothing else IP+UDP+RT= P overhead can become rather insane, but low delay does have advantages. T= his is a trade off like any other parameter, and different applications wil= l weigh the different factors in different ways. This is why frame size (a= nd thus delay) is parametrizable in CELT (At 48kHz from ~2-20ms, now). I don't personally think that the working group should require CELT's level= of delay flexibility or delays as low as 2ms, but delay is a real consider= ation. All other things equal I think there would be a clear preference for= a codec with 20ms algorithmic delay over something with 40ms of delay as w= ell as 10ms over 20ms even for straight telephony applications. Below that,= lower delay likely becomes undesirable for straight telephony but can stil= l be interesting for other applications. From hoene@uni-tuebingen.de Wed Jul 15 13:38:30 2009 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 438733A6B30 for ; Wed, 15 Jul 2009 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.929, 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 ecSkmutVEAFe for ; Wed, 15 Jul 2009 13:38:29 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 3A7E93A6A3E for ; Wed, 15 Jul 2009 13:38:29 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FJtmZ0028284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Jul 2009 21:55:54 +0200 From: "Christian Hoene" To: Date: Wed, 15 Jul 2009 21:55:39 +0200 Message-ID: <00b801ca0586$3de16a60$b9a43f20$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQ== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-gcfVCO Subject: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:38:30 -0000 Hello, I just compiled a short summary of all the emails on this mailing list. Actually, it is a cut and paste collage. I tried to remain neutral. If = not, please feel free to correct and extend the Wiki articles. https groupware1.cs.uni-tuebingen.de wiki/codec_bof The SPAM filter might filter out this email because of the URL. With best regards, Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From hoene@uni-tuebingen.de Wed Jul 15 13:38:31 2009 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 4A85F3A6A3E for ; Wed, 15 Jul 2009 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0elCI5TsotN for ; Wed, 15 Jul 2009 13:38:27 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E90E33A63CB for ; Wed, 15 Jul 2009 13:38:26 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FKEhhx031517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 22:14:49 +0200 From: "Christian Hoene" To: "'Brian West'" , References: In-Reply-To: Date: Wed, 15 Jul 2009 22:14:33 +0200 Message-ID: <00c901ca0588$e21a5c70$a64f1550$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CA0599.A5A32C70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFiL9/JHxreTUgQCyougrz2H+j1wAAAzVQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-oWnVno Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:38:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01CA0599.A5A32C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had the spam filter. My last try=85 http://tinyurl.com/codecbof =20 =20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Brian West Sent: Wednesday, July 15, 2009 9:20 PM To: Henry Sinnreich Cc: codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice =20 Also I think we are confusing coding delay vs ptime in the packet on the wire. =20 /b =20 On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote: Codec delay less than 30 ms is still desirable in certain interactive scenarios, especially where the network delay is small (locality). * Financial, stock and commodity trading desks, * Games with voice, * Digital living room and a heated discussion is going on :-)=20 Any extra delay may add irritation to a discussion.=20 This should also count for conferencing/telepresence. Besides, one of the proposed codecs has <10 ms delay. Henry =20 ------=_NextPart_000_00CA_01CA0599.A5A32C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I had the spam filter. My last = try…

http://tinyurl.com/codecbof=

 

 

-------------------------------------------------------- Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532

http://www.net.uni-tuebingen.de/

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Brian West
Sent: Wednesday, July 15, 2009 9:20 PM
To: Henry Sinnreich
Cc: codec@ietf.org
Subject: Re: [codec] useful for Internet applications with = voice

 

Also I think we are confusing coding delay vs ptime = in the packet on the wire.

 

/b

 

On Jul 15, 2009, at 2:07 PM, Henry Sinnreich = wrote:



Codec delay less than 30 = ms is still desirable in certain interactive scenarios, especially where the = network delay is small (locality).

  • Financial, stock and commodity trading = desks,
  • Games with voice,
  • Digital living room and a heated discussion = is going on :-) 


Any extra delay may add irritation to a discussion. 
This should also count for conferencing/telepresence.
Besides, one of the proposed codecs has = <10 ms delay.

Henry

 

------=_NextPart_000_00CA_01CA0599.A5A32C70-- From hoene@uni-tuebingen.de Wed Jul 15 13:38:31 2009 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 56DAC3A63CB for ; Wed, 15 Jul 2009 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 jq3uOHRZ0hSL for ; Wed, 15 Jul 2009 13:38:30 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 2F13F3A690A for ; Wed, 15 Jul 2009 13:38:30 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FK7YPR030276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 22:07:40 +0200 From: "Christian Hoene" To: Date: Wed, 15 Jul 2009 22:07:25 +0200 Message-ID: <00bf01ca0587$e2d898d0$a889ca70$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQ== Content-Language: de x-cr-hashedpuzzle: JPuM JsFq KJYS MITV T9bn Wne4 YH9X Z4Gx cxdi fFLc jaYt kZBK m7Aa nmej nuGz n7gk; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAZwByAGUAZwBvAHIAeQAuAGkAZQB0AGYAQABnAG0AYQBpAGwALgBjAG8AbQA7AGoAYQBzAG8AbgAuAGYAaQBzAGMAaABsAEAAcwBrAHkAcABlAC4AbgBlAHQAOwBqAGUAYQBuAC0AbQBhAHIAYwAuAHYAYQBsAGkAbgBAAG8AYwB0AGEAcwBpAGMALgBjAG8AbQA=; Sosha1_v1; 7; {D9CBB773-E14E-4B39-B35A-1B363DDD2F4D}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Wed, 15 Jul 2009 20:06:46 GMT; UwB1AG0AbQBhAHIAeQAgAG8AZgAgAGEAbABsAA== x-cr-puzzleid: {D9CBB773-E14E-4B39-B35A-1B363DDD2F4D} X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-6lbgY1 Cc: gregory.ietf@gmail.com Subject: [codec] Summary of all X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:38:31 -0000 Hello, I just compiled a short summary of all the emails on this mailing list. Actually, it is a cut and paste collage. I tried to remain neutral. If = not, please feel free to correct and extend the Wiki articles. http://tinyurl.com/codecbof With best regards, Christian PS: Sorry, for multiple postings... -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From hoene@uni-tuebingen.de Wed Jul 15 13:38:32 2009 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 5BF013A6C70 for ; Wed, 15 Jul 2009 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlgAhSnlanil for ; Wed, 15 Jul 2009 13:38:28 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 24BFE3A6C67 for ; Wed, 15 Jul 2009 13:38:27 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FKFcv9031712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 22:15:43 +0200 From: "Christian Hoene" To: "'Brian West'" , References: In-Reply-To: Date: Wed, 15 Jul 2009 22:15:28 +0200 Message-ID: <00ce01ca0589$02854fb0$078fef10$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01CA0599.C60E1FB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFiL9/JHxreTUgQCyougrz2H+j1wAAAzVQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-0fE2tN Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:38:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01CA0599.C60E1FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I hate the spam filter. My last try=85 http://tinyurl.com/codecbof =20 =20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Brian West Sent: Wednesday, July 15, 2009 9:20 PM To: Henry Sinnreich Cc: codec@ietf.org Subject: Re: [codec] useful for Internet applications with voice =20 Also I think we are confusing coding delay vs ptime in the packet on the wire. =20 /b =20 On Jul 15, 2009, at 2:07 PM, Henry Sinnreich wrote: =20 Codec delay less than 30 ms is still desirable in certain interactive scenarios, especially where the network delay is small (locality). * Financial, stock and commodity trading desks, * Games with voice, * Digital living room and a heated discussion is going on :-)=20 Any extra delay may add irritation to a discussion.=20 This should also count for conferencing/telepresence. Besides, one of the proposed codecs has <10 ms delay. Henry =20 ------=_NextPart_000_00CF_01CA0599.C60E1FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I hate the spam filter. My last = try…

http://tinyurl.com/codecbof=

 

 

-------------------------------------------------------- Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532

http://www.net.uni-tuebingen.de/

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Brian West
Sent: Wednesday, July 15, 2009 9:20 PM
To: Henry Sinnreich
Cc: codec@ietf.org
Subject: Re: [codec] useful for Internet applications with = voice

 

Also I think we are confusing = coding delay vs ptime in the packet on the wire.

 

/b

 

On Jul 15, 2009, at 2:07 PM, = Henry Sinnreich wrote:

 

Codec delay less than 30 ms is still desirable in certain interactive = scenarios, especially where the network delay is small = (locality).

  • Financial, stock = and commodity trading desks,
  • Games with voice,
  • Digital living room and a = heated discussion is going on :-) 


Any extra delay may add irritation to a discussion. 
This should also count for = conferencing/telepresence.
Besides, one of the proposed codecs = has <10 ms delay.

Henry

 

------=_NextPart_000_00CF_01CA0599.C60E1FB0-- From hoene@uni-tuebingen.de Wed Jul 15 13:40:17 2009 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 3390E3A6B30 for ; Wed, 15 Jul 2009 13:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, 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 eR6IfTdPGyvl for ; Wed, 15 Jul 2009 13:40:16 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 30CAF3A6995 for ; Wed, 15 Jul 2009 13:40:16 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FJZFwS025175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Jul 2009 21:35:21 +0200 From: "Christian Hoene" To: Date: Wed, 15 Jul 2009 21:35:07 +0200 Message-ID: <009e01ca0583$5f5d5fd0$1e181f70$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQ== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-CtcJXS Subject: [codec] Summary of all X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:40:17 -0000 Hello, I just compiled a short summary of all the emails on this mailing list. Actually, it is a cut and paste collage. I tried to remain neutral. If = not, please feel free to correct and extend the Wiki articles. https://groupware1.cs.uni-tuebingen.de/wiki/codec_bof/index.php/Main_Page= With best regards, Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From hoene@uni-tuebingen.de Wed Jul 15 13:40:26 2009 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 662A928C145 for ; Wed, 15 Jul 2009 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.068 X-Spam-Level: X-Spam-Status: No, score=-6.068 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 SJdhKw0S5H93 for ; Wed, 15 Jul 2009 13:40:25 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 618BF28C13C for ; Wed, 15 Jul 2009 13:40:25 -0700 (PDT) Received: from [134.2.172.132] (u-172-c132.cs.uni-tuebingen.de [134.2.172.132]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FITCFa014047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jul 2009 20:29:13 +0200 From: Christian Hoene To: "codec@ietf.org" In-Reply-To: References: Content-Type: text/plain Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_T=FCbingen?= Date: Wed, 15 Jul 2009 20:20:32 +0200 Message-Id: <1247682032.11462.15.camel@hoene-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.239; host: mx05); id=31023-wszvKm Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:40:26 -0000 I have read again all the millions of emails that have been send on this mailing list during the last weeks. To avoid that arguments are repeated and to have a summary of the discussions, I have compiled the following few web pages: https://groupware1.cs.uni-tuebingen.de/wiki/codec_bof/index.php/Main_Page It is not all 100% neutral (of course), but feel free to correct the Wiki articles or to add comments. Christian From hsinnrei@adobe.com Wed Jul 15 13:40:31 2009 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 53C763A6995 for ; Wed, 15 Jul 2009 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXGvJrf7fgsb for ; Wed, 15 Jul 2009 13:40:27 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 3659528C13C for ; Wed, 15 Jul 2009 13:40:27 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSl4+is79jh36DSCpvUhqvuj9eiCjQGLE@postini.com; Wed, 15 Jul 2009 13:41:00 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FJ7vao006982; Wed, 15 Jul 2009 12:07:57 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6FJEKiq017136; Wed, 15 Jul 2009 12:14:20 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 15 Jul 2009 12:14:20 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Wed, 15 Jul 2009 12:14:20 -0700 From: Henry Sinnreich To: Stephan Wenger , "codec@ietf.org" Date: Wed, 15 Jul 2009 12:14:17 -0700 Thread-Topic: [codec] useful for Internet applications with voice Thread-Index: AcoFBV4zgAZQK5QkS0Ce28FBUSp0zQAcQh2fAAEv1cAAAVMnGw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68394B94E35hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] useful for Internet applications with voice X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:40:31 -0000 --_000_C68394B94E35hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I would object to any charter proposal that requires an "open source refer= ence implementation", >because it unfairly excludes from IETF's standard process all those compan= ies which, on principle, do not contribute to open source. (my individual contributor hat on) This is their business decision. Other companies chose to support and contribute to open source; also a busi= ness decision. The real value from an engineering point of view is that written code is so= much more precise and useful than endless verbiage in documents and mailin= g lists IMO. If in doubt, let's count our emails today on various WG lists.= .. Henry On 7/15/09 1:36 PM, "Stephan Wenger" wrote: Hi Henry, I would object to any charter proposal that requires an "open source refere= nce implementation", because it unfairly excludes from IETF's standard proc= ess all those companies which, on principle, do not contribute to open sour= ce. You may also wish to clarify the sentence "is available for use without pat= ent license fees or any other known IPR constraints, ". Isn't this what yo= u really want to say: "a voice codec whose known IPR is available under ter= ms compatible with all major open source licenses"? Regards, Stephan On 7/15/09 11:02 AM, "Henry Sinnreich" wrote: Just to make clear my company's position: We're supportive of the efforts to arrive at a selection of a preferred cod= ec for voice over the Internet, as proposed for the Voice Codec BOF. To accommodate the broadest possible community, we support the selection of= a voice codec which * has a broad range of audio bandwidths, with no more than 30ms and pref= erably lower delay, * can be implemented efficiently, * is available for use without patent license fees or any other known IP= R constraints, * has an open source reference implementation, * works over the Internet. We think several voice codecs have been proposed which seem to meet those r= equirements, and hope that the working group can produce the standard for a= n Internet voice codec along these lines. Henry Sinnreich Adobe Systems, Inc. ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C68394B94E35hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] useful for Internet applications with voice >I would ob= ject to any charter proposal that requires an “open source reference = implementation”,
>because it unfairly excludes from IETF’s standard process all tho= se companies which, on principle, do not contribute to open source.
 
(my individual contributor hat= on)
This is their business decision.
Other companies chose to support and contribute to open source; also a busi= ness decision.

The real value from an engineering point of view is that written code is so= much more precise and useful than endless verbiage in documents and mailin= g lists IMO. If in doubt, let’s count our emails today on various WG = lists...

Henry


On 7/15/09 1:36 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Henry,
I would object to any charter proposal that requires an “open source = reference implementation”, because it unfairly excludes from IETFR= 17;s standard process all those companies which, on principle, do not contr= ibute to open source.
You may also wish to clarify the sentence “is available for use witho= ut patent license fees or any other known IPR constraints, ”.  I= sn’t this what you really want to say: “a voice codec whose kno= wn IPR is available under terms compatible with all major open source licen= ses”?
Regards,
Stephan


On 7/15/09 11:02 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

Just to make clear = my company’s position:

We’re supportive of the efforts to arrive at a selection of a preferr= ed codec for voice over the Internet, as proposed for the Voice Codec BOF. =
To accommodate the broadest possible community, we support the selection of= a voice codec which
 
  • has a broad range of au= dio bandwidths, with no more than 30ms and preferably lower delay,=20
  • = can be implemented efficien= tly,=20
  • = is available for use withou= t patent license fees or any other known IPR constraints,=20
  • = has an open source referenc= e implementation,=20
  • = works over the Internet.

We think several vo= ice codecs have been proposed which seem to meet those requirements, and ho= pe that the working group can produce the standard for an Internet voice co= dec along these lines.

Henry Sinnreich
Adobe Systems, Inc.


_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C68394B94E35hsinnreiadobecom_-- From gmaxwell@juniper.net Wed Jul 15 13:58:29 2009 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 0D4E128C13E for ; Wed, 15 Jul 2009 13:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 yfSryviyqBZa for ; Wed, 15 Jul 2009 13:58:28 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 2272528C16C for ; Wed, 15 Jul 2009 13:58:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSl5CVKmwwwp5gNkas9tvCX1y+m3YWxkR@postini.com; Wed, 15 Jul 2009 13:59:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 15 Jul 2009 13:52:52 -0700 From: Gregory Maxwell To: Christian Hoene , "codec@ietf.org" Date: Wed, 15 Jul 2009 13:48:22 -0700 Thread-Topic: [codec] Summary of all... Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQACj+AP Message-ID: References: <00b801ca0586$3de16a60$b9a43f20$@de> In-Reply-To: <00b801ca0586$3de16a60$b9a43f20$@de> 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 Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:58:29 -0000 Christian Hoene [hoene@uni-tuebingen.de] wrote: > Hello, > I just compiled a short summary of all the emails on this mailing list. > Actually, it is a cut and paste collage. I tried to remain neutral. If no= t, > please feel free to correct and extend the Wiki articles. There appears to be a rather large amount of material on the wiki which as = never been a topic of discussion here. This may be misleading to those who = have not followed every message on this list since its inception. As a matter of good house-keeping I believe if it were be preferable if tho= se attempting scribe-like activity kept the editorializing to a minimum in = those efforts. But thanks for the collection of information, none the less= . Cheers. (FWIW, I think your email is working fine=97 I got a half dozen copies of y= our message. Keep in mind that the archives are not instant)= From hoene@uni-tuebingen.de Wed Jul 15 14:11:55 2009 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 885063A6BDD for ; Wed, 15 Jul 2009 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.266, 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 j8Yfb6pG-1RX for ; Wed, 15 Jul 2009 14:11:54 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 8480D3A68BB for ; Wed, 15 Jul 2009 14:11:54 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FLB9tn008938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 23:11:16 +0200 From: "Christian Hoene" To: "'Gregory Maxwell'" , References: <00b801ca0586$3de16a60$b9a43f20$@de> In-Reply-To: Date: Wed, 15 Jul 2009 23:10:58 +0200 Message-ID: <00f001ca0590$c4a83d30$4df8b790$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQACj+APAACyExA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-8pvOft Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:11:55 -0000 > -----Original Message----- > From: Gregory Maxwell [mailto:gmaxwell@juniper.net] > Sent: Wednesday, July 15, 2009 10:48 PM > To: Christian Hoene; codec@ietf.org > Subject: RE: [codec] Summary of all... > > Christian Hoene [hoene@uni-tuebingen.de] wrote: > > Hello, > > I just compiled a short summary of all the emails on this mailing list. > > Actually, it is a cut and paste collage. I tried to remain neutral. If not, > > please feel free to correct and extend the Wiki articles. > > There appears to be a rather large amount of material on the wiki which as > never been a topic of discussion here. This may be misleading to those who > have not followed every message on this list since its inception. Beside a few headline and some fill words, every word has been said on this mailing list. Christian From gmaxwell@juniper.net Wed Jul 15 14:27:52 2009 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 DC9CB3A6AB8 for ; Wed, 15 Jul 2009 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ulbfMZnaR+lz for ; Wed, 15 Jul 2009 14:27:49 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 553D63A68D2 for ; Wed, 15 Jul 2009 14:27:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSl5JfeihdHHHs9Dz7ymt8p8TZtwVA0PI@postini.com; Wed, 15 Jul 2009 14:28:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 15 Jul 2009 14:15:57 -0700 From: Gregory Maxwell To: Christian Hoene , "codec@ietf.org" Date: Wed, 15 Jul 2009 14:14:29 -0700 Thread-Topic: [codec] Summary of all... Thread-Index: AcoFg1e9tT8TXkKpTjuVx9A47v3uSQACj+APAACyExAAADdqNQ== Message-ID: References: <00b801ca0586$3de16a60$b9a43f20$@de> , <00f001ca0590$c4a83d30$4df8b790$@de> In-Reply-To: <00f001ca0590$c4a83d30$4df8b790$@de> 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 Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:27:52 -0000 From: Christian Hoene [hoene@uni-tuebingen.de] wrote: > Beside a few headline and some fill words, every word has been said on th= is > mailing list. Can you please point me to the message where AMR-WB+, HE-AACv2, etc were di= scussed? I'd like to point out their inapplicability to the work discusse= d here if someone hasn't done so already. Thanks! From hoene@uni-tuebingen.de Wed Jul 15 14:28:34 2009 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 EFF653A6AB8 for ; Wed, 15 Jul 2009 14:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.232, 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 HxDj9WKxoU8F for ; Wed, 15 Jul 2009 14:28:34 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 35DF23A68D2 for ; Wed, 15 Jul 2009 14:28:31 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-217-127-251.pools.arcor-ip.net [94.217.127.251]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6FLRGtf011392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 23:27:21 +0200 From: "Christian Hoene" To: "'Marc Petit-Huguenin'" , References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> In-Reply-To: <4A5E4804.8090507@acm.org> Date: Wed, 15 Jul 2009 23:27:05 +0200 Message-ID: <00f101ca0593$03cda2a0$0b68e7e0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoFkhPbE0VUMbbUSgKHnMz4ues6vwAAJLXA Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.240; host: mx05); id=31023-vFIyVN Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:28:35 -0000 Changed... -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Wednesday, July 15, 2009 11:20 PM > To: Christian Hoene > Cc: 'Gregory Maxwell'; codec@ietf.org > Subject: Re: [codec] Summary of all... >=20 > Christian Hoene wrote: > >> -----Original Message----- > >> From: Gregory Maxwell [mailto:gmaxwell@juniper.net] > >> Sent: Wednesday, July 15, 2009 10:48 PM > >> To: Christian Hoene; codec@ietf.org > >> Subject: RE: [codec] Summary of all... > >> > >> Christian Hoene [hoene@uni-tuebingen.de] wrote: > >>> Hello, > >>> I just compiled a short summary of all the emails on this mailing list. > >>> Actually, it is a cut and paste collage. I tried to remain = neutral. If > > not, > >>> please feel free to correct and extend the Wiki articles. > >> There appears to be a rather large amount of material on the wiki = which as > >> never been a topic of discussion here. This may be misleading to = those who > >> have not followed every message on this list since its inception. > > > > Beside a few headline and some fill words, every word has been said = on this > > mailing list. > > >=20 > Hmm. >=20 > "It need not to support for layered coding in the codec (which is > need for multicast)." >=20 > One of the requirements I proposed was support for layered coding, > and nobody objected. >=20 > -- > Marc Petit-Huguenin > Home: marc@petit-huguenin.org > Work: petithug@acm.org From petithug@acm.org Wed Jul 15 14:29:49 2009 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 14E663A6C58 for ; Wed, 15 Jul 2009 14:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 5ZEQ+tkQej1u for ; Wed, 15 Jul 2009 14:29:48 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 446973A68D2 for ; Wed, 15 Jul 2009 14:28:56 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 7DF67DFC4010; Wed, 15 Jul 2009 21:20:18 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 60A38DFC400C; Wed, 15 Jul 2009 21:20:17 +0000 (UTC) Message-ID: <4A5E4804.8090507@acm.org> Date: Wed, 15 Jul 2009 14:20:04 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Christian Hoene References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> In-Reply-To: <00f001ca0590$c4a83d30$4df8b790$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:29:49 -0000 Christian Hoene wrote: >> -----Original Message----- >> From: Gregory Maxwell [mailto:gmaxwell@juniper.net] >> Sent: Wednesday, July 15, 2009 10:48 PM >> To: Christian Hoene; codec@ietf.org >> Subject: RE: [codec] Summary of all... >> >> Christian Hoene [hoene@uni-tuebingen.de] wrote: >>> Hello, >>> I just compiled a short summary of all the emails on this mailing list. >>> Actually, it is a cut and paste collage. I tried to remain neutral. If > not, >>> please feel free to correct and extend the Wiki articles. >> There appears to be a rather large amount of material on the wiki which as >> never been a topic of discussion here. This may be misleading to those who >> have not followed every message on this list since its inception. > > Beside a few headline and some fill words, every word has been said on this > mailing list. > Hmm. "It need not to support for layered coding in the codec (which is need for multicast)." One of the requirements I proposed was support for layered coding, and nobody objected. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From koen.vos@skype.net Wed Jul 15 22:54:33 2009 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 2360B3A6774 for ; Wed, 15 Jul 2009 22:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 KaUzj9ZBRyEO for ; Wed, 15 Jul 2009 22:54:32 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 0111F3A67DF for ; Wed, 15 Jul 2009 22:54:09 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 533792007AAC3 for ; Thu, 16 Jul 2009 07:52:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=1H3sJAMHfZra TQR1r7zrofhDd+Y=; b=p8CxyBBrlPpzl1J0cqxfmjAPeXTv3lPFX/8d/U3JZk96 VtfOceha4ukIGHTn3ba9LhRE9KqDhaCMnZ94D0KUMc4ABm2jelSUlIFqsDsvdHRQ xXiN2yC0bq96Ejj0l5RAdCmFIJvEfBjc5G60WDiCqUCVvJRgpus4Bhv78uEkTUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=oNzP786VRYv91r36ePE2 FTZKPRvG0b/teEj5NEeqFV/3CRBVjobJ64fvOILEL+rcyUt4T1+fbGCZrnDGnLSu vvb3Mjk2zq8UrLC+IF64EXQSrVwmsBEpf5QZ0WZSFGVOjEBVxzxoQcM8uU0s4S/3 Kl9IYo7KbBsgR3SIG3KalwY= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 51D152007AAB9 for ; Thu, 16 Jul 2009 07:52:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWHXKNdvNcQF for ; Thu, 16 Jul 2009 07:52:43 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 4A8FA2007A575; Thu, 16 Jul 2009 07:52:43 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Wed, 15 Jul 2009 22:52:43 -0700 Message-ID: <20090715225243.977625si4ddxwd9n@mail.skype.net> Date: Wed, 15 Jul 2009 22:52:43 -0700 From: Koen Vos To: codec@ietf.org References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> In-Reply-To: <4A5E4804.8090507@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 05:54:33 -0000 Quoting Marc Petit-Huguenin: > One of the requirements I proposed was support for layered coding, > and nobody objected. Layered coding can be seen as a method for computationally efficient transcoding. So I would propose to rephrase the requirement as: support for efficient transcoding to a lower bitrate and/or sample rate. Also note the earlier discussion on this topic: http://www.ietf.org/mail-archive/web/codec/current/msg00066.html http://www.ietf.org/mail-archive/web/codec/current/msg00063.html koen. From hoene@uni-tuebingen.de Thu Jul 16 00:38:26 2009 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 075063A69AA for ; Thu, 16 Jul 2009 00:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar+dIRKvQdSi for ; Thu, 16 Jul 2009 00:38:21 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 474893A6895 for ; Thu, 16 Jul 2009 00:38:20 -0700 (PDT) Received: from hoeneLenovoT60 (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 n6G7aO41025539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Jul 2009 09:36:24 +0200 From: "Christian Hoene" To: "'Koen Vos'" , References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> In-Reply-To: <20090715225243.977625si4ddxwd9n@mail.skype.net> Date: Thu, 16 Jul 2009 09:36:15 +0200 Message-ID: <001f01ca05e8$19f57a30$4de06e90$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CA05F8.DD7E4A30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoF2gZJuAHqWfNBQNGAE3M3QyCOAwACvA7g Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.241; host: mx05); id=31897-6pxzwF Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 07:38:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0020_01CA05F8.DD7E4A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good morning, =20 I change it to * Support for efficient transcoding to a lower bitrate and/or sample rate.=20 * For example, as Marc Petit-Huguenin proposed, by supporting layered coding like in G.729.1 and G.718=20 * Layered coding can be seen as a method for computationally efficient transcoding.=20 * Layered coding make sense in the conferencing environment as such stripping should be done at the sender after encoding. Then, for all receivers the encoding has to be done only once.=20 * However, for bidirectional transmissions, you do not need layered encoding as most codecs now are VBR, its enough already to adapt codec = (at the source) to the bandwidth.=20 As far as I remember layered coding comes at some (neglectable?) costs. = I do not know how large the lost in term of bandwidth is going to be, if = multiple layers are supported as compared to a single layer. (I did not found the proper publication addressing this issue) =20 Are you planning to add a bandwidth extension layer to the SILK draft = soon? It might be quite useful to fill the quality gap between SILK and CELT = =96 especially for low delay audio coding =20 With best regards, Christian =20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ =20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen > Vos > Sent: Thursday, July 16, 2009 7:53 AM > To: codec@ietf.org > Subject: Re: [codec] Summary of all... >=20 > Quoting Marc Petit-Huguenin: >=20 > > One of the requirements I proposed was support for layered coding, > > and nobody objected. >=20 > Layered coding can be seen as a method for computationally efficient > transcoding. So I would propose to rephrase the requirement as: = support > for efficient transcoding to a lower bitrate and/or sample rate. >=20 > Also note the earlier discussion on this topic: > http://www.ietf.org/mail-archive/web/codec/current/msg00066.html > http://www.ietf.org/mail-archive/web/codec/current/msg00063.html >=20 > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_0020_01CA05F8.DD7E4A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good = morning,

 

I change it = to

  • Support for efficient transcoding to a = lower bitrate and/or sample rate.
    • For example, as Marc Petit-Huguenin proposed, by supporting layered coding like in = G.729.1 and G.718
    • Layered coding can be seen = as a method for computationally efficient transcoding. =
    • Layered coding make sense = in the conferencing environment as such stripping should be done at the = sender after encoding. Then, for all receivers the encoding has to be = done only once.
    • However, for bidirectional transmissions, you do not need layered encoding as most codecs now = are VBR, its enough already to adapt codec (at the source) to the = bandwidth.

As far as I remember layered = coding comes at some (neglectable?) costs. I do not know how large the lost in term = of bandwidth is going to be, if multiple layers are supported as compared to a single = layer. (I did not found the proper publication addressing this = issue)

 

Are you planning to add a = bandwidth extension layer to the SILK draft soon? It might be quite useful to fill = the quality gap between SILK and CELT – especially for low delay audio = coding

 

With best = regards,

=A0Christian

 

--------------------------------------------------------

Dr.-Ing. Christian = Hoene

Interactive Communication = Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, = Germany, Phone +49 7071 2970532

http://www.net.uni-tuebingen.de/

 

> -----Original Message-----

> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen

> Vos

> Sent: Thursday, July 16, 2009 7:53 = AM

> To: codec@ietf.org

> Subject: Re: [codec] Summary of = all...

>

> Quoting Marc Petit-Huguenin:

>

> > One of the requirements I proposed was = support for layered coding,

> > and nobody objected.

>

> Layered coding can be seen as a method for computationally efficient

> transcoding. So I would propose to rephrase = the requirement as: support

> for efficient transcoding to a lower = bitrate and/or sample rate.

>

> Also note the earlier discussion on this = topic:

> = http://www.ietf.org/mail-archive/web/codec/current/msg00066.html

> = http://www.ietf.org/mail-archive/web/codec/current/msg00063.html

>

> koen.

> = _______________________________________________

> codec mailing list

> codec@ietf.org

> = https://www.ietf.org/mailman/listinfo/codec

------=_NextPart_000_0020_01CA05F8.DD7E4A30-- From ron.even.tlv@gmail.com Thu Jul 16 01:30:11 2009 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 4C69B28C152 for ; Thu, 16 Jul 2009 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, 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 1mqtB9MOPrq9 for ; Thu, 16 Jul 2009 01:30:07 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C91A23A6C61 for ; Thu, 16 Jul 2009 01:30:06 -0700 (PDT) Received: by fxm18 with SMTP id 18so3936442fxm.37 for ; Thu, 16 Jul 2009 01:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=didwrZmSYKR0IXacW1yUGhz3GGrmv9vavgpHv+NT4ew=; b=wRpm3ki9P1oMNObXNY2m2tnYBOKBTHW1Ig87Q/D7j0UOqOGqQGCtuQ3UL/omt5Oxdo fAe3AXQCLpo8dWTls3MozXwFnUTf+gwHbRdeMtC3ZbWMw0Ze6uT0kuhKwMYzTsR9AjEW C7B349HlBlrihw68srVyvZRnasKAyPIBMJO5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=HlCx3vlMrIvm3oJkr9t/mzU+V5gLzgQY+TJAobGUUBIRw6Ynt5M608nsgrCgpOmpHH 0b7WAo9tds/qia5af4QrJEzH8zu+QNogNZy8Gkp7uv7IsiRaSkzQ/mRA+YZuAgIHmylB Bq8IWjArhPO9ertaD7zBThNWVvIyL91JG5JLk= Received: by 10.103.6.14 with SMTP id j14mr4608153mui.32.1247732999716; Thu, 16 Jul 2009 01:29:59 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id j10sm21535844muh.45.2009.07.16.01.29.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Jul 2009 01:29:58 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" , "'Koen Vos'" , References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> <001f01ca05e8$19f57a30$4de06e90$@de> In-Reply-To: <001f01ca05e8$19f57a30$4de06e90$@de> Date: Thu, 16 Jul 2009 11:28:46 +0300 Message-ID: <4a5ee506.0aec660a.5c4d.ffffe899@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D49_01CA0608.9652E340" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoF2gZJuAHqWfNBQNGAE3M3QyCOAwACvA7gAAKGroA= Content-Language: en-us Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 08:30:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0D49_01CA0608.9652E340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian, I am not sure what you are discussing since I did not see any of it on = this mailing list. If you want to have a discussion or suggest something it should be on this mailing list. BTW: I cannot access your link due to security reasons. Roni =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Thursday, July 16, 2009 10:36 AM To: 'Koen Vos'; codec@ietf.org Subject: Re: [codec] Summary of all... =20 Good morning, =20 I change it to * Support for efficient transcoding to a lower bitrate and/or sample rate.=20 * For example, as Marc Petit-Huguenin proposed, by supporting layered coding like in G.729.1 and G.718=20 * Layered coding can be seen as a method for computationally efficient transcoding.=20 * Layered coding make sense in the conferencing environment as such stripping should be done at the sender after encoding. Then, for all receivers the encoding has to be done only once.=20 * However, for bidirectional transmissions, you do not need layered encoding as most codecs now are VBR, its enough already to adapt codec = (at the source) to the bandwidth.=20 As far as I remember layered coding comes at some (neglectable?) costs. = I do not know how large the lost in term of bandwidth is going to be, if = multiple layers are supported as compared to a single layer. (I did not found the proper publication addressing this issue) =20 Are you planning to add a bandwidth extension layer to the SILK draft = soon? It might be quite useful to fill the quality gap between SILK and CELT = =96 especially for low delay audio coding =20 With best regards, Christian =20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ =20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen > Vos > Sent: Thursday, July 16, 2009 7:53 AM > To: codec@ietf.org > Subject: Re: [codec] Summary of all... >=20 > Quoting Marc Petit-Huguenin: >=20 > > One of the requirements I proposed was support for layered coding, > > and nobody objected. >=20 > Layered coding can be seen as a method for computationally efficient > transcoding. So I would propose to rephrase the requirement as: = support > for efficient transcoding to a lower bitrate and/or sample rate. >=20 > Also note the earlier discussion on this topic: > http://www.ietf.org/mail-archive/web/codec/current/msg00066.html > http://www.ietf.org/mail-archive/web/codec/current/msg00063.html >=20 > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_0D49_01CA0608.9652E340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Christian,

I am not sure what = you are discussing since I did not see any of it on this mailing list. If you = want to have a discussion or suggest something it should be on this mailing = list.

BTW: I cannot access = your link due to security reasons.

Roni

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Christian Hoene
Sent: Thursday, July 16, 2009 10:36 AM
To: 'Koen Vos'; codec@ietf.org
Subject: Re: [codec] Summary of all...

 

Good morning,

 

I change it to

  • Support for efficient transcoding to a = lower bitrate and/or sample rate.
    • For example, as Marc Petit-Huguenin proposed, by supporting layered coding like in = G.729.1 and G.718
    • Layered coding can be seen = as a method for computationally efficient transcoding. =
    • Layered coding make sense = in the conferencing environment as such stripping should be done at the = sender after encoding. Then, for all receivers the encoding has to be done only = once.
    • However, for bidirectional transmissions, you do not need layered encoding as most codecs now = are VBR, its enough already to adapt codec (at the source) to the = bandwidth.

As far as I remember layered = coding comes at some (neglectable?) costs. I do not know how large the lost in term = of bandwidth is going to be, if multiple layers are supported as compared = to a single layer. (I did not found the proper publication addressing this = issue)

 

Are you planning to add a = bandwidth extension layer to the SILK draft soon? It might be quite useful to fill = the quality gap between SILK and CELT – especially for low delay audio = coding

 

With best = regards,

 Christian

 

----------------------------------------------------= ----

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), = University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 = 7071 2970532

http://www.net.uni-tuebingen.de/

 

> -----Original = Message-----

> From: = codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen

> Vos

> Sent: Thursday, July 16, = 2009 7:53 AM

> To: = codec@ietf.org

> Subject: Re: [codec] = Summary of all...

>

> Quoting Marc = Petit-Huguenin:

>

> > One of the = requirements I proposed was support for layered coding,

> > and nobody = objected.

>

> Layered coding can be seen = as a method for computationally efficient

> transcoding. So I would = propose to rephrase the requirement as: support

> for efficient transcoding = to a lower bitrate and/or sample rate.

>

> Also note the earlier = discussion on this topic:

> http://www.ietf.org/mail-archive/web/codec/current/msg00066.html

> http://www.ietf.org/mail-archive/web/codec/current/msg00063.html

>

> koen.

> _______________________________________________

> codec mailing = list

> = codec@ietf.org

> https://www.ietf.org/mailman/listinfo/codec

------=_NextPart_000_0D49_01CA0608.9652E340-- From hoene@uni-tuebingen.de Thu Jul 16 01:42:04 2009 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 2D2FB3A6C64 for ; Thu, 16 Jul 2009 01:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, 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 LYXbvqjcwazN for ; Thu, 16 Jul 2009 01:42:03 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id DE7313A6BE8 for ; Thu, 16 Jul 2009 01:42:02 -0700 (PDT) Received: from [134.2.172.132] (u-172-c132.cs.uni-tuebingen.de [134.2.172.132]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6G8gXtY006290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jul 2009 10:42:34 +0200 From: Christian Hoene To: Roni Even In-Reply-To: <4a5ee506.0aec660a.5c4d.ffffe899@mx.google.com> References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> <001f01ca05e8$19f57a30$4de06e90$@de> <4a5ee506.0aec660a.5c4d.ffffe899@mx.google.com> Content-Type: text/plain; charset="UTF-8" Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_T=FCbingen?= Date: Thu, 16 Jul 2009 10:33:50 +0200 Message-Id: <1247733230.17016.7.camel@hoene-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.215; VDF: 7.1.4.241; host: mx05); id=31897-TFf9aJ Cc: codec@ietf.org Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 08:42:04 -0000 Hello Roni, > Christian, > > I am not sure what you are discussing since I did not see any of it on > this mailing list. If you want to have a discussion or suggest > something it should be on this mailing list. In the last weeks, some hundred mails have been send on the list. It is quite hard to keep track on the issues that have been discussed. My intention is not to discuss something outside the mailing list, but to keep track of the arguments. Therefore, I read all the mail again and did some cut-and-paste to write the Wiki articles. I tried to avoid adding arguments that have not been raised on this mailing but structured the arguments and made some minor editorial changes. > BTW: I cannot access your link due to security reasons. I have asked our web administrator to find a way to access the Wiki without security problems. As usual, it will take some hours until it is fixed... Sorry, Christian > > Roni > > > > From:codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Thursday, July 16, 2009 10:36 AM > To: 'Koen Vos'; codec@ietf.org > Subject: Re: [codec] Summary of all... > > > > > Good morning, > > > > I change it to > > * Support for efficient transcoding to a lower bitrate and/or > sample rate. > * For example, as Marc Petit-Huguenin proposed, by > supporting layered coding like in G.729.1 and G.718 > * Layered coding can be seen as a method for > computationally efficient transcoding. > * Layered coding make sense in the conferencing > environment as such stripping should be done at the > sender after encoding. Then, for all receivers the > encoding has to be done only once. > * However, for bidirectional transmissions, you do not > need layered encoding as most codecs now are VBR, its > enough already to adapt codec (at the source) to the > bandwidth. > > As far as I remember layered coding comes at some (neglectable?) > costs. I do not know how large the lost in term of bandwidth is going > to be, if multiple layers are supported as compared to a single layer. > (I did not found the proper publication addressing this issue) > > > > Are you planning to add a bandwidth extension layer to the SILK draft > soon? It might be quite useful to fill the quality gap between SILK > and CELT – especially for low delay audio coding > > > > With best regards, > > Christian > > > > -------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of Tübingen > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf Of Koen > > > Vos > > > Sent: Thursday, July 16, 2009 7:53 AM > > > To: codec@ietf.org > > > Subject: Re: [codec] Summary of all... > > > > > > Quoting Marc Petit-Huguenin: > > > > > > > One of the requirements I proposed was support for layered coding, > > > > and nobody objected. > > > > > > Layered coding can be seen as a method for computationally efficient > > > transcoding. So I would propose to rephrase the requirement as: > support > > > for efficient transcoding to a lower bitrate and/or sample rate. > > > > > > Also note the earlier discussion on this topic: > > > http://www.ietf.org/mail-archive/web/codec/current/msg00066.html > > > http://www.ietf.org/mail-archive/web/codec/current/msg00063.html > > > > > > koen. > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > https://www.ietf.org/mailman/listinfo/codec > > From koen.vos@skype.net Thu Jul 16 02:38:17 2009 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 24CB83A6BCE for ; Thu, 16 Jul 2009 02:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 Qkm2RAAbqtc3 for ; Thu, 16 Jul 2009 02:38:16 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 4A5E63A6910 for ; Thu, 16 Jul 2009 02:38:16 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A5E112007AC4F; Thu, 16 Jul 2009 11:38:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=0be0/HPwRptn 9BrPm0hJXqyejh0=; b=OBI7OKg1PjmDpSK6zomfSU1TNFSjWTcDz2rau8OZf+NR SnfyG5GT+RccpfJrCLRh+52UtalVBxC0oXx0F+siBJhpRa+QHmfACQuha8+OeUpl ChacD1mYvkJsWQayXQNzV2GUC8E6F6Msv8AfCL8PjsbIoN/DjjXocTXaj8cckd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=EGzXsITNDEa87DTTSR+o z7omA91Y7UIN23EtT7gTVnqrNoYHbAPcSNBhSlKh0COexksJL2WpSeaG7gWNjCHc lXRw4oWSwlG6S8btKVFJT3O2P4+NUCCNpoeu1QoFCKOith2DloB3aMXmcbNrTwnE J9mzuFlj3+/xzeufsvm89P8= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A434A2007AB49; Thu, 16 Jul 2009 11:38:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLbxxx+ZPmN9; Thu, 16 Jul 2009 11:38:47 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 0B3282007AC54; Thu, 16 Jul 2009 11:38:47 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Thu, 16 Jul 2009 02:38:47 -0700 Message-ID: <20090716023847.576685q3f588gr3b@mail.skype.net> Date: Thu, 16 Jul 2009 02:38:47 -0700 From: Koen Vos To: Christian Hoene References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> <001f01ca05e8$19f57a30$4de06e90$@de> In-Reply-To: <001f01ca05e8$19f57a30$4de06e90$@de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 09:38:17 -0000 Quoting Christian Hoene: > Are you planning to add a bandwidth extension layer to the SILK draft soon? There is no plan for that right now. > It might be quite useful to fill the quality gap between SILK and > CELT especially for low delay audio coding The gap is small: SILK goes up to 24 kHz sampling rate; CELT starts at 32 kHz. koen. From stephen.botzko@gmail.com Thu Jul 16 04:35:03 2009 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 9D6783A6C48 for ; Thu, 16 Jul 2009 04:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.439, 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 SRFFZprYXWHu for ; Thu, 16 Jul 2009 04:34:58 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id E77D83A6C37 for ; Thu, 16 Jul 2009 04:34:57 -0700 (PDT) Received: by bwz28 with SMTP id 28so46398bwz.37 for ; Thu, 16 Jul 2009 04:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oaLQeXj2O7ezlSJ6Om5qJeEmw7XGSZjpr4DLGhrWGqg=; b=UdP1GsKHV04ooQfnUIbAIEWjR+0AgAZm3bNqnTy1t0nunNfOl3/+1otdUh/rU4B7Sb Ib7uPTIm+8nPW1HBX+8VcO3VcTq2BzT1QFmq9Blo5vKydZGhZeDWDyZHS9GZjbQaOwTX rzStcTyYjTp8gqBgcvBZ7ZWbl6sdJnHptNLVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NO/683yOfgXUg53lILtC/Jq6jc1xKuVruRMmnI2iQMus7xz0OiucClqhKSc4rLZl5n GI7Jy3D0VEXoEk4PiXPhLHQ/kEjIjZppsy5wmJhdfe7p7gH2oYYSdUjIHHqNuk7ScmDp PelBGMxwnRGrpjEZs+FKt/euDgjwQDnsiJKXY= MIME-Version: 1.0 Received: by 10.223.105.16 with SMTP id r16mr4417354fao.24.1247742339646; Thu, 16 Jul 2009 04:05:39 -0700 (PDT) In-Reply-To: <1247733230.17016.7.camel@hoene-desktop> References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> <001f01ca05e8$19f57a30$4de06e90$@de> <4a5ee506.0aec660a.5c4d.ffffe899@mx.google.com> <1247733230.17016.7.camel@hoene-desktop> Date: Thu, 16 Jul 2009 07:05:39 -0400 Message-ID: <6e9223710907160405j3a5874dboe6c275e78bf54362@mail.gmail.com> From: stephen botzko To: Christian Hoene , Cullen Jennings Content-Type: multipart/alternative; boundary=001636c5b52bed0a74046ed0a6b5 Cc: codec@ietf.org Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 11:35:03 -0000 --001636c5b52bed0a74046ed0a6b5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all Though I think Christian's attempt to summarize is noble, I am somewhat concerned about it. He is clearly working to be fair, and the bulk of the wiki is snippets of actual postings. However, by its very nature it is a summary, and will not include everything. The classification/organization/selection of postings into categories also represents Christian's view of what categories matter. It is not clear to me how (or even if) this will be used by the IETF leadership, so I am not sure how much time/effort I need to spend cross-checking the hundreds of emails against the wiki. Perhaps a clarification from IETF leadership as to whether this activity matters would be helpful? Regards, Stephen Botzko Polycom 2009/7/16 Christian Hoene > Hello Roni, > > > Christian, > > > > I am not sure what you are discussing since I did not see any of it on > > this mailing list. If you want to have a discussion or suggest > > something it should be on this mailing list. > > In the last weeks, some hundred mails have been send on the list. It is > quite hard to keep track on the issues that have been discussed. > My intention is not to discuss something outside the mailing list, but > to keep track of the arguments. Therefore, I read all the mail again and > did some cut-and-paste to write the Wiki articles. > I tried to avoid adding arguments that have not been raised on this > mailing but structured the arguments and made some minor editorial > changes. > > > BTW: I cannot access your link due to security reasons. > > I have asked our web administrator to find a way to access the Wiki > without security problems. As usual, it will take some hours until it is > fixed... > > Sorry, > > Christian > > > > > Roni > > > > > > > > From:codec-bounces@ietf.org [mailto: > codec-bounces@ietf.org] On Behalf > > Of Christian Hoene > > Sent: Thursday, July 16, 2009 10:36 AM > > To: 'Koen Vos'; codec@ietf.org > > Subject: Re: [codec] Summary of all... > > > > > > > > > > Good morning, > > > > > > > > I change it to > > > > * Support for efficient transcoding to a lower bitrate and/or > > sample rate. > > * For example, as Marc Petit-Huguenin proposed, by > > supporting layered coding like in G.729.1 and G.718 > > * Layered coding can be seen as a method for > > computationally efficient transcoding. > > * Layered coding make sense in the conferencing > > environment as such stripping should be done at the > > sender after encoding. Then, for all receivers the > > encoding has to be done only once. > > * However, for bidirectional transmissions, you do not > > need layered encoding as most codecs now are VBR, its > > enough already to adapt codec (at the source) to the > > bandwidth. > > > > As far as I remember layered coding comes at some (neglectable?) > > costs. I do not know how large the lost in term of bandwidth is going > > to be, if multiple layers are supported as compared to a single layer. > > (I did not found the proper publication addressing this issue) > > > > > > > > Are you planning to add a bandwidth extension layer to the SILK draft > > soon? It might be quite useful to fill the quality gap between SILK > > and CELT =96 especially for low delay audio coding > > > > > > > > With best regards, > > > > Christian > > > > > > > > -------------------------------------------------------- > > > > Dr.-Ing. Christian Hoene > > > > Interactive Communication Systems (ICS), University of T=FCbingen > > > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > > > > http://www.net.uni-tuebingen.de/ > > > > > > > > > -----Original Message----- > > > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf Of Koen > > > > > Vos > > > > > Sent: Thursday, July 16, 2009 7:53 AM > > > > > To: codec@ietf.org > > > > > Subject: Re: [codec] Summary of all... > > > > > > > > > > Quoting Marc Petit-Huguenin: > > > > > > > > > > > One of the requirements I proposed was support for layered coding, > > > > > > and nobody objected. > > > > > > > > > > Layered coding can be seen as a method for computationally efficient > > > > > transcoding. So I would propose to rephrase the requirement as: > > support > > > > > for efficient transcoding to a lower bitrate and/or sample rate. > > > > > > > > > > Also note the earlier discussion on this topic: > > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00066.html > > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00063.html > > > > > > > > > > koen. > > > > > _______________________________________________ > > > > > 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 > --001636c5b52bed0a74046ed0a6b5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all

Though I think Christian's attempt to summarize is noble,= I am somewhat concerned about it.=A0

He is clearly working to be f= air, and the bulk of the wiki is snippets of actual postings.=A0 However, b= y its very nature it is a summary, and will not include everything.=A0 The = classification/organization/selection of postings into categories also repr= esents Christian's view of what categories matter.

It is not clear to me how (or even if) this will be used by the IETF le= adership, so I am not sure how much time/effort I need to spend cross-check= ing the hundreds of emails against the wiki.

Perhaps a clarification= from IETF leadership as to whether this activity matters would be helpful?=

Regards,
Stephen Botzko
Polycom



2009/7/16 Christian Hoene <hoene@uni-tuebingen.de>
Hello Roni,

> Christian,
>
> I am not sure what you are discussing since I did not see any of it on=
> this mailing list. If you want to have a discussion or suggest
> something it should be on this mailing list.

In the last weeks, some hundred mails have been send on the list. It = is
quite hard to keep track on the issues that have been discussed.
My intention is not to discuss something outside the mailing list, but
to keep track of the arguments. Therefore, I read all the mail again and did some cut-and-paste to write the Wiki articles.
I tried to avoid adding arguments that have not been raised on this
mailing but structured the arguments and made some minor editorial
changes.

> BTW: I cannot access your link due to security reasons.

I have asked our web administrator to find a way to access the Wiki without security problems. As usual, it will take some hours until it is fixed...

Sorry,

=A0Christian

>
> Roni
>
>
>
> From:codec-bounces@ie= tf.org [mailto:codec-bounces@= ietf.org] On Behalf
> Of Christian Hoene
> Sent: Thursday, July 16, 2009 10:36 AM
> To: 'Koen Vos'; codec@ietf.o= rg
> Subject: Re: [codec] Summary of all...
>
>
>
>
> Good morning,
>
>
>
> I change it to
>
> =A0 =A0 =A0 * Support for efficient transcoding to a lower bitrate and= /or
> =A0 =A0 =A0 =A0 sample rate.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For example, as Marc Petit-Huguenin prop= osed, by
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 supporting layered coding like in G.72= 9.1 and G.718
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Layered coding can be seen as a method f= or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 computationally efficient transcoding.=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Layered coding make sense in the confere= ncing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 environment as such stripping should b= e done at the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sender after encoding. Then, for all r= eceivers the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 encoding has to be done only once.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * However, for bidirectional transmissions= , you do not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 need layered encoding as most codecs n= ow are VBR, its
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enough already to adapt codec (at the = source) to the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bandwidth.
>
> As far as I remember layered coding comes at some (neglectable?)
> costs. I do not know how large the lost in term of bandwidth is going<= br> > to be, if multiple layers are supported as compared to a single layer.=
> (I did not found the proper publication addressing this issue)
>
>
>
> Are you planning to add a bandwidth extension layer to the SILK draft<= br> > soon? It might be quite useful to fill the quality gap between SILK > and CELT =96 especially for low delay audio coding
>
>
>
> With best regards,
>
> =A0Christian
>
>
>
> --------------------------------------------------------
>
> Dr.-Ing. Christian Hoene
>
> Interactive Communication Systems (ICS), University of T=FCbingen
>
> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
>
> http://= www.net.uni-tuebingen.de/
>
>
>
> > -----Original Message-----
>
> > From: codec-bounces@iet= f.org [mailto:codec-bounces@i= etf.org] On
> Behalf Of Koen
>
> > Vos
>
> > Sent: Thursday, July 16, 2009 7:53 AM
>
> > To: codec@ietf.org
>
> > Subject: Re: [codec] Summary of all...
>
> >
>
> > Quoting Marc Petit-Huguenin:
>
> >
>
> > > One of the requirements I proposed was support for layered c= oding,
>
> > > and nobody objected.
>
> >
>
> > Layered coding can be seen as a method for computationally effici= ent
>
> > transcoding. So I would propose to rephrase the requirement as: > support
>
> > for efficient transcoding to a lower bitrate and/or sample rate.<= br> >
> >
>
> > Also note the earlier discussion on this topic:
>
> > http://www.ietf.org/mail-archive/web/codec/cu= rrent/msg00066.html
>
> > http://www.ietf.org/mail-archive/web/codec/cu= rrent/msg00063.html
>
> >
>
> > koen.
>
> > _______________________________________________
>
> > 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

--001636c5b52bed0a74046ed0a6b5-- From jean-marc.valin@usherbrooke.ca Thu Jul 16 04:43:45 2009 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 2E71828C0E3 for ; Thu, 16 Jul 2009 04:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 8utSTEitXuPX for ; Thu, 16 Jul 2009 04:43:42 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 509A63A6986 for ; Thu, 16 Jul 2009 04:43:42 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/9Gh/QK9GeQO0oIHZmiJLg)" Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMV00MX8HTJ7K50@VL-MO-MR004.ip.videotron.ca> for codec@ietf.org; Thu, 16 Jul 2009 07:41:46 -0400 (EDT) Message-id: <4A5F11F7.4090902@usherbrooke.ca> Date: Thu, 16 Jul 2009 07:41:43 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: "codec@ietf.org" References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> In-reply-to: <20090714225004.1357112pvshm8w0c@mail.skype.net> X-Enigmail-Version: 0.95.2 Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 11:43:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/9Gh/QK9GeQO0oIHZmiJLg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hello, Koen and I have been having a technical discussion in the past few days before we realised that it would be best to do that publicly on the list. So we're moving the thread to the list and I'm attaching the discussion we had in private (with only very minor edits). Cheers, Jean-Marc --Boundary_(ID_/9Gh/QK9GeQO0oIHZmiJLg) Content-type: text/plain; CHARSET=ISO-8859-1; name=SILK_CELT_discussion Content-transfer-encoding: 8BIT Content-disposition: inline; filename=SILK_CELT_discussion Date: Tue, 07 Jul 2009 22:33:15 -0400 From: Jean-Marc Valin To: Koen Vos , Jason Fischl Subject: Comments on draft-vos-silk-00.txt Hi Koen, Jason, I've started reading draft-vos-silk-00.txt and had a few comments. I'm not posting on the list, since I'm guessing you didn't want to "officially" announce the draft yet. In no particular order: 1) I think section 2 is a bit strange as it seems to list the requirements that lead to the proposed codec, rather than requirements for compliance with the draft standard. Maybe it should be labeled as "design goals" or something like that, with the MUSTs and SHOULDs removed. 2) Some of the requirements may be useful in another section that is really about compliance. For example, "The codec MUST be capable of running with an algorithmic delay of no more than 30 milliseconds" could be there to say that any implementation of SILK cannot add more than 10 ms lookahead (on top of the 20 ms frame size). 3) It would be nice to have more details on the "Noise Shaping Quantizer", though I'm guessing that's mostly a matter of lack of time so far. I see a mention of "pyramid range encoder", but it's not clear where the pyramid comes from (any relationship with the pyramid vector quantizer we're using in CELT)? 4) Not sure about that one, but a "comparison with CELP" may be useful to better understand the algorithm. 5) Are you standardising only the decoder (MPEG-style, where the reference encoder is merely a suggestion) or are you also standardising the encoder (ITU-style, minus bit-exactness)? I haven't read through all the details yet, so I may have more comments later. If you have any comments on the CELT draft, I'd be glad to hear them so I can address then before the final cut-off. Cheers, Jean-Marc ------------------------------------------------------------ Date: Wed, 08 Jul 2009 14:01:13 -0700 From: Koen Vos To: Jean-Marc Valin Cc: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Jean-Marc, Thanks for the very useful feedback. The requirements should indeed be replaced by design goals later on. For now these are also meant as a discussion point in Stockholm about what the codec(s) should provide. We'll fill in the details about noise shaping quantizer. FYI: the noise shaping quantizer generates quantization indices, but without the constraints for "tracks" and total number of pulses found in a CELP codec. This makes it possible to process the signal sample-by-sample, which is simpler than CELP's search. The quantization indices are entropy coded with a pyramid quantization scheme that is indeed similar to the one in CELT. We haven't made up our mind about what we want to standardize. Besides the two options you mention, even the full ITU approach including bit-exactness is a candidate as it guarantees quality (at the cost of innovation opportunity). I'll get back to you with feedback on the CELT draft shortly. best, koen. ---------------------------------------------------------------- Date: Wed, 08 Jul 2009 19:29:43 -0400 From: Jean-Marc Valin To: Koen Vos CC: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Koen, Koen Vos a écrit : > We'll fill in the details about noise shaping quantizer. FYI: the noise > shaping quantizer generates quantization indices, but without the > constraints for "tracks" and total number of pulses found in a CELP > codec. This makes it possible to process the signal sample-by-sample, > which is simpler than CELP's search. Do you have a higher-complexity option where the scalar quantization takes into account the "N-best solutions"? This is something I've done with the split-VQ innovation codebook in Speex (only at complexity 3 and above). > The quantization indices are > entropy coded with a pyramid quantization scheme that is indeed similar > to the one in CELT. Do you mean that you entropy-code the total number of pulses and then you convert the PVQ value to a single integer? Considering that both CELT and SILK use a range coder and assuming the pyramid quantization in SILK is similar enough to what CELT does, would it make sense to specifically attempt to make SILK and CELT share common code? That way a DSP implementation could support both codecs without having to completely duplicate the code size (and the porting effort). Not sure it's practical, but I think it's at least worth checking whether there's enough practical similarities. > We haven't made up our mind about what we want to standardize. Besides > the two options you mention, even the full ITU approach including > bit-exactness is a candidate as it guarantees quality (at the cost of > innovation opportunity). I think it may be useful to have a "if you're bit-exact with this you know you're OK" type of reference, but it would probably would not be a good idea to force everyone to be bit-exact with that. That would not only favour some DSP manufacturers over others (depending on how you implement the basic operators), but it would also prevent float implementations, which can be faster on some machines. For example, the float version of Speex can be almost double the speed of the fixed-point version on a PC. That can be important for applications like PSTN gateways. > I'll get back to you with feedback on the CELT draft shortly. I look forward to having your feedback. Cheers, Jean-Marc ------------------------------------------------------------------- Date: Mon, 13 Jul 2009 04:03:06 -0700 From: Koen Vos To: Jean-Marc Valin Cc: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Jean-Marc, Sorry for the slow response - here are some answers inline, followed by feedback on the CELT draft. > Do you have a higher-complexity option where the scalar quantization > takes into account the "N-best solutions"? This is something I've done > with the split-VQ innovation codebook in Speex (only at complexity 3 and > above). Yes, we use trellis coding with 2 and 4 states/best solutions in the medium and high complexity settings. It helps quite a bit, saving several kbps. > Considering that both CELT and SILK use a range coder and assuming the > pyramid quantization in SILK is similar enough to what CELT does, would > it make sense to specifically attempt to make SILK and CELT share common > code? That way a DSP implementation could support both codecs without > having to completely duplicate the code size (and the porting effort). > Not sure it's practical, but I think it's at least worth checking > whether there's enough practical similarities. I like the idea of sharing part of the code base. As discussed, the PVQ in SILK is somewhat different from the one in CELT, and uses trained probabilities to describe how a given number of pulses in a 16-sample block is distributed. We could try CELT's PVQ but it might slightly increase the bitrate. The range encoder could be shared (although it would break the bitstream format for one codec). In any case, there should be many low-level functions that can be shared. Feedback on the CELT draft: We already discussed transients over the phone a bit. In the description of the time-domain windowing, reference is made to a "transient time"; it was not immediately clear to me how this time is determined: is it fixed on the transition between first and second MDCT window? Have you considered using shorter transitions for the intra-frame overlaps in "short blocks" mode? I wonder if that could accomplish the same as the time-domain windowing (so that you wouldn't need that mode anymore). The coarse energies are predicted based on energies in the previous frame and lower bands. Are the coarse or fine energies from the previous frame used as a basis for prediction? In theory it could be more efficient to predict and encode fine energies directly, but that would result in a variable number of bits spend for the energy encoding (which might be acceptable, don't know). Alternatively, to reduce such bit rate variation, the energies could be encoding one band at a time, while varying quantization accuracy depending on how many bits were spent so far. It also feels like the energy quantization coarseness for one band could be made dependent on its energy relative to the preceding band: if the band below had a lot more energy, than the current band's energy can be quantized more coarsely. Companding could achieve that, for example. How well does the pitch prediction work? Does it remove most of the energy in the pitch bands for voiced speech? Is the pitch lag estimation accurate when the pitch lag is not a multiple number of frames? I wonder how the frequency domain correlation can be accurate in that case, because with an MDCT, a shift in time does not correspond to a phase rotation like with a Fourier transform. Probably I should just take a look at the code to understand better what goes on.. Anyway, it's nice to see a codec with lots of original ideas that make perfect sense. best, koen. ----------------------------------------------------------------------- Date: Mon, 13 Jul 2009 07:43:05 -0400 From: Jean-Marc Valin To: Koen Vos CC: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Koen, Thanks very much for the review. Comments below. Koen Vos a écrit : > We already discussed transients over the phone a bit. > In the description of the time-domain windowing, reference is made to a > "transient time"; it was not immediately clear to me how this time is > determined: is it fixed on the transition between first and second MDCT > window? I guess I should make this clearer. The transient time is determined by the encoder and transmitted in the bit-stream. It's the exact time (in samples) where the transient begins. > Have you considered using shorter transitions for the intra-frame > overlaps in "short blocks" mode? I wonder if that could accomplish the > same as the time-domain windowing (so that you wouldn't need that mode > anymore). The time-domain windowing (I guess I could call it a time-domain pre-emphasis because it's compensated at the decoder) is more precise in time than just short blocks, but it's true that it may be possible to reduce the overlap inside the frame. I'll have a look at this. > The coarse energies are predicted based on energies in the previous > frame and lower bands. Are the coarse or fine energies from the previous > frame used as a basis for prediction? The prediction is based on the fine quantisation of the previous frame. Will try and make that clearer. > In theory it could be more > efficient to predict and encode fine energies directly, but that would > result in a variable number of bits spend for the energy encoding (which > might be acceptable, don't know). The 6 dB coarse energy quantisation was selected because that's roughly where prediction stops being useful. At this point, the fine energy bits are mostly random. Also, because the quantisation step is fixed, the probability model is easier to deal with (one set of probabilities per band). Another technical issue is that for bands where fine energy can have a resolution of 0.05 dB, there would be too many symbols to encode in one step anyway. > Alternatively, to reduce such bit rate > variation, the energies could be encoding one band at a time, while > varying quantization accuracy depending on how many bits were spent so far. > It also feels like the energy quantization coarseness for one band could > be made dependent on its energy relative to the preceding band: if the > band below had a lot more energy, than the current band's energy can be > quantized more coarsely. I'm still considering adjusting the quantisation level of fine and PVQ with the input spectrum (i.e. dynamic allocation), but haven't yet figured out a way to do that that sounds better than the current code. > Companding could achieve that, for example. Not sure I understand what you mean here. > How well does the pitch prediction work? Does it remove most of the > energy in the pitch bands for voiced speech? So far, pitch only seems to be useful for lower bit-rate (<= 48 kbit/s) speech. It not that it really hurts otherwise, but the improvement it makes is usually just enough to cover the bits it adds. > Is the pitch lag > estimation accurate when the pitch lag is not a multiple number of > frames? I wonder how the frequency domain correlation can be accurate > in that case, because with an MDCT, a shift in time does not correspond > to a phase rotation like with a Fourier transform. Probably I should > just take a look at the code to understand better what goes on.. Oh, the pitch period is estimated using a time-domain weighted cross-correlation (implemented using an FFT), so the lag can be precise. > Anyway, it's nice to see a codec with lots of original ideas that make > perfect sense. Thanks! Jean-Marc ---------------------------------------------------------------------- Date: Mon, 13 Jul 2009 21:07:48 -0700 From: Koen Vos To: Jean-Marc Valin Cc: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Jean-Marc, > I'm still considering adjusting the quantisation level of fine and PVQ > with the input spectrum (i.e. dynamic allocation), but haven't yet > figured out a way to do that that sounds better than the current code. I guess a simple way is to operate on the differences between the band log energies (subtract, from each band, the log energy of the band below). Then apply non-uniform quantization (or companding + uniform quantization). The non-uniform quantizer would have less accuracy at lower levels, where there is more masking from the band below. The resulting indices can be predictively entropy coded, where the probability is equal to the integral of the Laplacian over the quantization interval. The mean of the Laplacian is set equal to the predicted value, and the spread/variance comes from a predefined table. > Another technical issue is that for bands where fine energy can > have a resolution of 0.05 dB, there would be too many symbols to encode > in one step anyway. Whether the entropy coding is done in one step or in multiple refinements could be local to the entropy coder. Although 0.05 dB quantization steps means that the quantization noise sits more than 40 dB below the signal. Is quantizing more coarsely audibly worse? > So far, pitch only seems to be useful for lower bit-rate (<= 48 kbit/s) > speech. It not that it really hurts otherwise, but the improvement it > makes is usually just enough to cover the bits it adds. It could be interesting to establish an upper bound of what could be achieved with the "perfect" pitch lag estimator: do a brute-force search over all possibly pitch lags by computing the windowed MDCT for each time lag and computing the energy reduction with that lag. Although unacceptably complex, it would be relatively easy to implement and gives a feel of how much potential there is from improving pitch lag estimates. best, koen. ---------------------------------------------------------------------- Date: Tue, 14 Jul 2009 00:37:02 -0400 From: Jean-Marc Valin To: Koen Vos CC: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Koen, Koen Vos a écrit : >> I'm still considering adjusting the quantisation level of fine and PVQ >> with the input spectrum (i.e. dynamic allocation), but haven't yet >> figured out a way to do that that sounds better than the current code. > > I guess a simple way is to operate on the differences between the band > log energies (subtract, from each band, the log energy of the band > below). That's similar to what the current quantizer already does if you disable inter-frame prediction. > Then apply non-uniform quantization (or companding + uniform > quantization). The non-uniform quantizer would have less accuracy at > lower levels, where there is more masking from the band below. I see. I tried something a bit similar (adding a linear offset before the log and removing at the decoder) in the past without much improvement. Could be worth revisiting that though. > The > resulting indices can be predictively entropy coded, where the > probability is equal to the integral of the Laplacian over the > quantization interval. The mean of the Laplacian is set equal to the > predicted value, and the spread/variance comes from a predefined table. You mean adjusting the Laplacian probabilities based on the companding? With the current code, that would require too much computations to be worth it. I actually tried all kinds of fancy things for coarse energy prediction/entropy coding and it's really hard to beat the (simple) current code by more than about one bit. >> Another technical issue is that for bands where fine energy can >> have a resolution of 0.05 dB, there would be too many symbols to encode >> in one step anyway. > > Whether the entropy coding is done in one step or in multiple > refinements could be local to the entropy coder. Although 0.05 dB > quantization steps means that the quantization noise sits more than 40 > dB below the signal. Is quantizing more coarsely audibly worse? The number of fine energy bits is actually computed in the bit allocation process. If the allocator finds that it has B bits for a certain band of N bins, then fine energy will get B/N bits and PVQ will get (N-1)*B/N (in practice, there also an offset, but it's not important here). So at *very* high bit-rates, CELT can give as much as 7 bits per sample for some bands, which means the fine energy for those bands can be 7 bits, so 0.05 dB resolution. In practice, it tends to be coarser than that though (at very low rates, some bands will not have fine energy bits at all). >> So far, pitch only seems to be useful for lower bit-rate (<= 48 kbit/s) >> speech. It not that it really hurts otherwise, but the improvement it >> makes is usually just enough to cover the bits it adds. > > It could be interesting to establish an upper bound of what could be > achieved with the "perfect" pitch lag estimator: do a brute-force search > over all possibly pitch lags by computing the windowed MDCT for each > time lag and computing the energy reduction with that lag. Although > unacceptably complex, it would be relatively easy to implement and gives > a feel of how much potential there is from improving pitch lag estimates. I think the main problem with the pitch does not come from the lag estimation, but the way the pitch gain is quantised and used. That's because if the pitch gain is very large, then the PVQ codebook gain (computed to ensure that the final vector has unit norm) will vary a lot with the actual codeword selected. Consider the geometric interpretation if you have a pitch gain of 0.9. The codebook that results from pitch+PVQ obviously has a higher resolution in the direction of the pitch vector. However, because the "residual" (after removing pitch) tends to be mostly orthogonal to the pitch vector, the net result is that the resolution for the value we're actually quantising isn't improved by much. In the past, I've tried to use some kind of companding to the PVQ codebook to increase the resolution in directions that are orthogonal to the pitch vector, but it was quite expensive, reduced loss robustness and gave little improvements overall. Cheers, Jean-Marc ----------------------------------------------------------------------- Date: Mon, 13 Jul 2009 22:11:09 -0700 From: Koen Vos To: Jean-Marc Valin Cc: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Jean-Marc, > You mean adjusting the Laplacian probabilities based on the companding? Yes, that would be one implementation of it. > I actually tried all kinds of fancy things for coarse energy > prediction/entropy coding and it's really hard to beat the (simple) > current code by more than about one bit. Better keep it simple then :) > I think the main problem with the pitch does not come from the lag > estimation, but the way the pitch gain is quantised and used. That's > because if the pitch gain is very large, then the PVQ codebook gain > (computed to ensure that the final vector has unit norm) will vary a lot > with the actual codeword selected. Consider the geometric interpretation > if you have a pitch gain of 0.9. The codebook that results from > pitch+PVQ obviously has a higher resolution in the direction of the > pitch vector. However, because the "residual" (after removing pitch) > tends to be mostly orthogonal to the pitch vector, the net result is > that the resolution for the value we're actually quantising isn't > improved by much. The variations of the PVQ codebook gain, could they be avoided by orhogonalizing the PVQ contribution relative to the pitch vector? Given the pitch gain, you would then automatically know the PVQ gain: gain_PVQ = sqrt( 1 - gain_pitch^2 ); (assuming the PVQ part in normalized in energy after the orthogonalization). best, koen. ------------------------------------------------------------------------ Date: Tue, 14 Jul 2009 07:17:04 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Koen Vos CC: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Koen Vos a écrit : >> I think the main problem with the pitch does not come from the lag >> estimation, but the way the pitch gain is quantised and used. That's >> because if the pitch gain is very large, then the PVQ codebook gain >> (computed to ensure that the final vector has unit norm) will vary a lot >> with the actual codeword selected. Consider the geometric interpretation >> if you have a pitch gain of 0.9. The codebook that results from >> pitch+PVQ obviously has a higher resolution in the direction of the >> pitch vector. However, because the "residual" (after removing pitch) >> tends to be mostly orthogonal to the pitch vector, the net result is >> that the resolution for the value we're actually quantising isn't >> improved by much. > > The variations of the PVQ codebook gain, could they be avoided by > orhogonalizing the PVQ contribution relative to the pitch vector? Given > the pitch gain, you would then automatically know the PVQ gain: > gain_PVQ = sqrt( 1 - gain_pitch^2 ); > (assuming the PVQ part in normalized in energy after the > orthogonalization). Yes, that was the original thing we thought about (before the companding), but we ended up with two major problems: 1) We couldn't find a way to compute the orthogonalization efficiently (O(N^3) is not an option); 2) If you lose a packet, there is basically no hope of resynchronising. Jean-Marc Date: Tue, 14 Jul 2009 22:50:04 -0700 From: Koen Vos To: Jean-Marc Valin Cc: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt >> The variations of the PVQ codebook gain, could they be avoided by >> orhogonalizing the PVQ contribution relative to the pitch vector? Given >> the pitch gain, you would then automatically know the PVQ gain: >> gain_PVQ = sqrt( 1 - gain_pitch^2 ); >> (assuming the PVQ part in normalized in energy after the >> orthogonalization). > > Yes, that was the original thing we thought about (before the > companding), but we ended up with two major problems: > 1) We couldn't find a way to compute the orthogonalization efficiently > (O(N^3) is not an option); Should be O(N) I think: PVQ_orth = PVQ - Pitch * (Pitch' * PVQ); (Eq. 1) Where Pitch and PVQ are like the adaptive and fixed codebook vectors. Under normal operation, Pitch is normalized in energy (but it may have less energy after packet loss - see below). The decoder creates the quantized signal as: S_quant = Pitch * pitch_gain + PVQ_orth * sqrt( (1 - pitch_gain ^ 2) / (PVQ_orth' * PVQ_orth) ); > 2) If you lose a packet, there is basically no hope of resynchronising. Maybe that can be avoided. After a packet loss, and assuming no normalization, the Pitch vector has zero energy so S_quant is equal to the scaled PVQ. With each decoded packet Pitch gradually increases until it reaches unit energy. As a result the orthogonalization in the decoder (as described in Equation 1) is only a partial orthogonalization in that the result is not completely orthogonal to Pitch as long as Pitch has energy below one. In other words PVQ_orth will be more similar to PVQ while the Pitch vector is building up. (You could of course still choose to normalize the S_quant signal for creating the output signal, as long the signal going into the pitch buffer is based on the unnormalized S_quant. This increases complexity though.) There's also a way to balance pitch coding gain and speed of error recovery: When creating the pitch residual signal as input to the PVQ, using a pitch gain that is lower than the ideal pitch gain (= Pitch' * S) will typically lead to a PVQ vector that is less orthogonal to Pitch. So it contains part innovation but also part a description of Pitch itself. The pitch gain sent to the decoder should still be the (quantized) ideal pitch gain. Without packet loss, the orthogonalization removes the part of PVQ that's aligned with Pitch, and the S_quant signal is created as usual. Following a packet loss, however, there is no orthogonalization and the full PVQ is used which already looks more like the original signal. And subsequent packets, with partial orthogonalization, will converge faster to the signal that would have existed without packet loss. Don't know if this makes any sense... best, koen. ------------------------------------------------------------------------- Date: Wed, 15 Jul 2009 07:31:10 -0400 From: Jean-Marc Valin To: Koen Vos CC: Jason Fischl Subject: Re: Comments on draft-vos-silk-00.txt Hi Koen, Koen Vos a écrit : >> Yes, that was the original thing we thought about (before the >> companding), but we ended up with two major problems: >> 1) We couldn't find a way to compute the orthogonalization efficiently >> (O(N^3) is not an option); > > Should be O(N) I think: > > PVQ_orth = PVQ - Pitch * (Pitch' * PVQ); (Eq. 1) This is is exactly (well, we a coefficient before the second term) what I meant by the companding and that's what CELT was doing until around 0.3.0. The complexity wasn't too bad (it doubled the search complexity or so), but it was causing resynchronisation problems. For the case where PVQ is forced to be completely orthogonal, there were even numerical stability problems. Another issue now is that going back to the companding idea would prevent one of the search optimisations (projection on the pyramid to find the first pulses) we added later, so the cost on the search would be more like 10x or so. > Where Pitch and PVQ are like the adaptive and fixed codebook vectors. Did you know that CELT originally stood for "Code-Excited Lapped Transform" because of the analogy with CELP? In the end I got too many complaints that it was misleading that I changed it to Constrained-Energy Lapped Transform. So far I'm impressed that we're thinking about the exact same solutions for all these issues. > Under normal operation, Pitch is normalized in energy (but it may have > less energy after packet loss - see below). The decoder creates the > quantized signal as: > > S_quant = Pitch * pitch_gain + > PVQ_orth * sqrt( (1 - pitch_gain ^ 2) / (PVQ_orth' * PVQ_orth) ); > > >> 2) If you lose a packet, there is basically no hope of resynchronising. > > Maybe that can be avoided. After a packet loss, and assuming no > normalization, the Pitch vector has zero energy so S_quant is equal to > the scaled PVQ. With each decoded packet Pitch gradually increases > until it reaches unit energy. You mean you would force it to be smaller than unity? Because with the normalisation it usually *has* to have unit norm. > As a result the orthogonalization in the > decoder (as described in Equation 1) is only a partial orthogonalization > in that the result is not completely orthogonal to Pitch as long as > Pitch has energy below one. In other words PVQ_orth will be more > similar to PVQ while the Pitch vector is building up. > (You could of course still choose to normalize the S_quant signal for > creating the output signal, as long the signal going into the pitch > buffer is based on the unnormalized S_quant. This increases complexity > though.) I'm not following here. > There's also a way to balance pitch coding gain and speed of error > recovery: When creating the pitch residual signal as input to the PVQ, > using a pitch gain that is lower than the ideal pitch gain (= Pitch' * > S) will typically lead to a PVQ vector that is less orthogonal to > Pitch. So it contains part innovation but also part a description of > Pitch itself. The pitch gain sent to the decoder should still be the > (quantized) ideal pitch gain. Without packet loss, the > orthogonalization removes the part of PVQ that's aligned with Pitch, and > the S_quant signal is created as usual. Following a packet loss, > however, there is no orthogonalization and the full PVQ is used which > already looks more like the original signal. And subsequent packets, > with partial orthogonalization, will converge faster to the signal that > would have existed without packet loss. > > Don't know if this makes any sense... Well it does and as far as I can tell it's pretty close to what we used to do (I can dig out the source code if you'd like to look at it). In the end, we judged that it wasn't really worth the effort -- especially considering that we had to quantise pitch better. That's what it was removed. Right now, the pitch gain is either 0 or 0.9 (one bit for each of the 8 "pitch bands") and to me that sounds about as good as all the fancy things we did. It turns out that even though we're minimizing the complexity added by pitch, it still nearly doubles the encoder complexity, and as far as I can tell it only improves lower bit-rate speech performance (<= 48 kbit/s). Cheers, Jean-Marc --Boundary_(ID_/9Gh/QK9GeQO0oIHZmiJLg)-- From jean-marc.valin@octasic.com Thu Jul 16 06:09:24 2009 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 5CB0B28C1BE for ; Thu, 16 Jul 2009 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 w1jMRb7d673l for ; Thu, 16 Jul 2009 06:09:23 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 39A2728C16C for ; Thu, 16 Jul 2009 06:09:17 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 09:08:02 -0400 Message-ID: <4A5F2632.7050902@octasic.com> Date: Thu, 16 Jul 2009 09:08:02 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: stephen botzko References: <00b801ca0586$3de16a60$b9a43f20$@de> <00f001ca0590$c4a83d30$4df8b790$@de> <4A5E4804.8090507@acm.org> <20090715225243.977625si4ddxwd9n@mail.skype.net> <001f01ca05e8$19f57a30$4de06e90$@de> <4a5ee506.0aec660a.5c4d.ffffe899@mx.google.com> <1247733230.17016.7.camel@hoene-desktop> <6e9223710907160405j3a5874dboe6c275e78bf54362@mail.gmail.com> In-Reply-To: <6e9223710907160405j3a5874dboe6c275e78bf54362@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jul 2009 13:08:02.0971 (UTC) FILETIME=[73770EB0:01CA0616] Cc: codec@ietf.org Subject: Re: [codec] Summary of all... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 13:09:24 -0000 Hi, I share Stephen's concerns about the summary and I see that these concerns are actually expressed on both sides. Again, I don't think there was any bad-faith or bias involved, but simply that this sort of summary is bound to be subjective. There is also the issue that some people who expressed opinions may even have changed their mind now. So instead of arguing over the summary itself, which is counter-productive, I suggest we just continue discussing on the list. Considering how often the arguments get repeated, it's not necessary for anyone to read the whole archive or a summary to get an idea of the arguments. Jean-Marc stephen botzko wrote: > Hi all > > Though I think Christian's attempt to summarize is noble, I am somewhat > concerned about it. > > He is clearly working to be fair, and the bulk of the wiki is snippets > of actual postings. However, by its very nature it is a summary, and > will not include everything. The classification/organization/selection > of postings into categories also represents Christian's view of what > categories matter. > > It is not clear to me how (or even if) this will be used by the IETF > leadership, so I am not sure how much time/effort I need to spend > cross-checking the hundreds of emails against the wiki. > > Perhaps a clarification from IETF leadership as to whether this activity > matters would be helpful? > > Regards, > Stephen Botzko > Polycom > > > > 2009/7/16 Christian Hoene > > > Hello Roni, > > > Christian, > > > > I am not sure what you are discussing since I did not see any of > it on > > this mailing list. If you want to have a discussion or suggest > > something it should be on this mailing list. > > In the last weeks, some hundred mails have been send on the list. It is > quite hard to keep track on the issues that have been discussed. > My intention is not to discuss something outside the mailing list, but > to keep track of the arguments. Therefore, I read all the mail again and > did some cut-and-paste to write the Wiki articles. > I tried to avoid adding arguments that have not been raised on this > mailing but structured the arguments and made some minor editorial > changes. > > > BTW: I cannot access your link due to security reasons. > > I have asked our web administrator to find a way to access the Wiki > without security problems. As usual, it will take some hours until it is > fixed... > > Sorry, > > Christian > > > > > Roni > > > > > > > > From:codec-bounces@ietf.org > > [mailto:codec-bounces@ietf.org ] On > Behalf > > Of Christian Hoene > > Sent: Thursday, July 16, 2009 10:36 AM > > To: 'Koen Vos'; codec@ietf.org > > Subject: Re: [codec] Summary of all... > > > > > > > > > > Good morning, > > > > > > > > I change it to > > > > * Support for efficient transcoding to a lower bitrate and/or > > sample rate. > > * For example, as Marc Petit-Huguenin proposed, by > > supporting layered coding like in G.729.1 and G.718 > > * Layered coding can be seen as a method for > > computationally efficient transcoding. > > * Layered coding make sense in the conferencing > > environment as such stripping should be done at the > > sender after encoding. Then, for all receivers the > > encoding has to be done only once. > > * However, for bidirectional transmissions, you do not > > need layered encoding as most codecs now are VBR, its > > enough already to adapt codec (at the source) to the > > bandwidth. > > > > As far as I remember layered coding comes at some (neglectable?) > > costs. I do not know how large the lost in term of bandwidth is going > > to be, if multiple layers are supported as compared to a single > layer. > > (I did not found the proper publication addressing this issue) > > > > > > > > Are you planning to add a bandwidth extension layer to the SILK draft > > soon? It might be quite useful to fill the quality gap between SILK > > and CELT – especially for low delay audio coding > > > > > > > > With best regards, > > > > Christian > > > > > > > > -------------------------------------------------------- > > > > Dr.-Ing. Christian Hoene > > > > Interactive Communication Systems (ICS), University of Tübingen > > > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > > > > http://www.net.uni-tuebingen.de/ > > > > > > > > > -----Original Message----- > > > > > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org ] On > > Behalf Of Koen > > > > > Vos > > > > > Sent: Thursday, July 16, 2009 7:53 AM > > > > > To: codec@ietf.org > > > > > Subject: Re: [codec] Summary of all... > > > > > > > > > > Quoting Marc Petit-Huguenin: > > > > > > > > > > > One of the requirements I proposed was support for layered > coding, > > > > > > and nobody objected. > > > > > > > > > > Layered coding can be seen as a method for computationally > efficient > > > > > transcoding. So I would propose to rephrase the requirement as: > > support > > > > > for efficient transcoding to a lower bitrate and/or sample rate. > > > > > > > > > > Also note the earlier discussion on this topic: > > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00066.html > > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00063.html > > > > > > > > > > koen. > > > > > _______________________________________________ > > > > > 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From gmaxwell@juniper.net Thu Jul 16 10:06:05 2009 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 D8FB028C18D for ; Thu, 16 Jul 2009 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 f4DYlTJCI2yv for ; Thu, 16 Jul 2009 10:06:04 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id A4FA53A67AC for ; Thu, 16 Jul 2009 10:06:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSl9eFDjQnKhlFrKN7mbKaG14f3dyQyGL@postini.com; Thu, 16 Jul 2009 10:06:38 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 16 Jul 2009 09:45:34 -0700 From: Gregory Maxwell To: "codec@ietf.org" , "koen.vos@skype.net" Date: Thu, 16 Jul 2009 09:45:33 -0700 Thread-Topic: [codec] Comments on draft-vos-silk-00.txt Thread-Index: AcoGCtPpyCbwCQmpTGGWhnt6b/ySXwAJc0+R Message-ID: References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net>, <4A5F11F7.4090902@usherbrooke.ca> In-Reply-To: <4A5F11F7.4090902@usherbrooke.ca> 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 Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 17:06:06 -0000 Jean-Marc Valin [jean-marc.valin@usherbrooke.ca] wrote: > Koen and I have been having a technical discussion in the past few days > before we realised that it would be best to do that publicly on the > list. So we're moving the thread to the list and I'm attaching the > discussion we had in private (with only very minor edits). >[SILK_CELT_discussion.txt] Koen, I'm very curious how well your 'pyramid range coder' works in terms o= f storage efficiency compared to the indexed PVQ scheme used in CELT. Given uniformly distributed pyramidal vectors and providing that the sum of= absolute values is known (In CELT the vectors are all unit norm, and the P= VQ precision is inferred from the current state and allocation table, so th= is is known without signalling cost) the indexed approach CELT uses is opti= mal for codebooks of less than 32bits (=B1 the range coder precision). How= ever, your approach may gain some advantage from entropy coding=97 in CELT = optimal entropy coding of the PVQ vectors appears to be a negligible improv= ement, but the underlying distribution of your data may be different.=20 (CELT also works with vectors of many dimensions, so the memory required fo= r probability tables was one reason the indexing scheme is used). For codebooks greater than 32bits CELT recursively bisects the vector in di= mensions until each leaf fits in 32 bits. This is significantly less effici= ent, especially since the number pulses on one side is currently coded with= out entropy coding. But it's hardly applicable to CELT because CELT doesn't= encounter codebooks this big at normal rates as most of the bits are used = on low frequencies which have small bands. (The approach CELT is using doe= s work beyond 32bits, but it requires 64-bit arithmetic)=20 The approximate storage required for the CELT approach is easy to calculate= (for codewords <32bits). Providing the magnitude is know the storage is ju= st the log2 of the number of possible PVQ codewords. If the magnitude must = be signalled it would need to be entropy coded (I presume that if need that= you're already entropy coding it). If N is the number of dimensions, and K is the magnitude (sum of absolute v= alues), The cardinality of the codebook, V(N,K) can be determined by the re= cursive formula: V(N,0)=3D1 ; V(0,K)=3D0; V(N,K)=3DV(N-1,K) + V(N,K-1) + = V(N-1,K-1)=20 (What CELT does internally is, obviously, much faster) Here is a simple python script that calculates this: ---cwrs.py--- #!/usr/bin/python import math,sys sys.setrecursionlimit(32768) memory=3D{} def V (n,k): if (k=3D=3D0): return 1 if (n=3D=3D0): return 0 if (n,k) not in memory: memory[(n,k)] =3D V(n-1,k) + V(n,k-1) + V(n-1,k-1) return memory[(n,k)] return memory[(n,k)] N=3D16 for K in range(13): print "(%d,%d)"%(N,K),math.log(V(N,K),2) ---end: cwrs.py --- It outputs: (16,0) 0.0 (16,1) 5.0 (16,2) 9.0 (16,3) 12.4178525149 (16,4) 15.4262647547 (16,5) 18.1210477887 (16,6) 20.5636729598 (16,7) 22.7971992119 (16,8) 24.853601964 (16,9) 26.7576215488 (16,10) 28.5289824639 (16,11) 30.1837675338 (16,12) 31.7353184363 If would be interesting to know how that compares to your approach, and if = codebooks of greater than 32bits are relevant to your usage.=20 Cheers, From hoene@uni-tuebingen.de Thu Jul 16 10:59:31 2009 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 75BA528C195 for ; Thu, 16 Jul 2009 10:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, 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 B-80DOdsBLmP for ; Thu, 16 Jul 2009 10:59:30 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 8537B28C13F for ; Thu, 16 Jul 2009 10:59:01 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-092-074-160-028.pools.arcor-ip.net [92.74.160.28]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6GHxBNk016477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Jul 2009 19:59:17 +0200 From: "Christian Hoene" To: References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net>, <4A5F11F7.4090902@usherbrooke.ca> In-Reply-To: Date: Thu, 16 Jul 2009 19:59:02 +0200 Message-ID: <003a01ca063f$1db26fa0$59174ee0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoGCtPpyCbwCQmpTGGWhnt6b/ySXwAJc0+RAAMk6IA= Content-language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.220; VDF: 7.1.4.246; host: mx05); id=31897-PfHmxu Cc: gregory.ietf@gmail.com Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 17:59:31 -0000 Guys,=20 please stop coding and start working! Did you call read =93RFC 5434: Considerations for Having a Successful Birds-of-a-Feather (BOF) = Session=94. May I cite a few paragraphs? This document provides suggestions on how to host a successful BOF at an IETF meeting. It is hoped that by documenting the methodologies that have proven successful, as well as listing some pitfalls, BOF organizers will improve their chances of hosting a BOF with a positive outcome. 6) During the 2-4 weeks before an IETF (assuming a BOF has been approved and scheduled), the focus (on the mailing list) should be on identifying areas of agreement and areas of disagreement. Since disagreement, or "lack of consensus", tends to be the main reason for not forming a WG, focusing on those specific areas where "lack of consensus" exists is critically important. In general, only after those disagreements have been resolved will a WG be formed; thus, the main goal should be to find consensus and work through the areas of disagreement. Alternatively, a specific case should be made about why the charter, as it is written, is the best one, in spite of the stated opposition. 7) Prior to the BOF, it is critical to produce a proposed charter and iterate on it on the mailing list to attempt to get a consensus charter. Ultimately, the most important question to ask during a BOF is: "should a WG with the following charter be formed?". It goes without saying that a charter with shortcomings (no matter how seemingly trivial to fix) will not achieve consensus if folk still have issues with the specific wording. 8) Decide what questions will be asked during the BOF itself. Since the exact wording of the questions is critical (and hard to do on the fly), it is strongly recommended that those questions be floated on the mailing list and to the ADs prior to the BOF. This will enable people to understand what they will be asked to approve and will allow the questions to be modified (prior to the BOF) to remove ambiguities, etc. Likewise, discussing these questions in advance may lead to refinement of the charter so that the questions can be answered affirmatively. I do not see any progress on this mailing to address these issues. I = have my doubts whether you are interesting in forming a working group at all: No progress on the charter, no progress on the agenda, no progress on understanding the real problem. I only see new CELT versions. Please, please, do start to act. Stockholm is in 10 days... Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Gregory Maxwell > Sent: Thursday, July 16, 2009 6:46 PM > To: codec@ietf.org; koen.vos@skype.net > Subject: Re: [codec] Comments on draft-vos-silk-00.txt >=20 > Jean-Marc Valin [jean-marc.valin@usherbrooke.ca] wrote: > > Koen and I have been having a technical discussion in the past few = days > > before we realised that it would be best to do that publicly on the > > list. So we're moving the thread to the list and I'm attaching the > > discussion we had in private (with only very minor edits). > >[SILK_CELT_discussion.txt] >=20 > Koen, I'm very curious how well your 'pyramid range coder' works in = terms of > storage efficiency compared to the indexed PVQ scheme used in CELT. >=20 > Given uniformly distributed pyramidal vectors and providing that the = sum of > absolute values is known (In CELT the vectors are all unit norm, and = the PVQ > precision is inferred from the current state and allocation table, so = this is > known without signalling cost) the indexed approach CELT uses is = optimal for > codebooks of less than 32bits (=B1 the range coder precision). = However, your > approach may gain some advantage from entropy coding=97 in CELT = optimal entropy > coding of the PVQ vectors appears to be a negligible improvement, but = the > underlying distribution of your data may be different. >=20 > (CELT also works with vectors of many dimensions, so the memory = required for > probability tables was one reason the indexing scheme is used). >=20 > For codebooks greater than 32bits CELT recursively bisects the vector = in > dimensions until each leaf fits in 32 bits. This is significantly less > efficient, especially since the number pulses on one side is currently coded > without entropy coding. But it's hardly applicable to CELT because = CELT > doesn't encounter codebooks this big at normal rates as most of the = bits are > used on low frequencies which have small bands. (The approach CELT is using > does work beyond 32bits, but it requires 64-bit arithmetic) >=20 > The approximate storage required for the CELT approach is easy to calculate > (for codewords <32bits). Providing the magnitude is know the storage = is just > the log2 of the number of possible PVQ codewords. If the magnitude = must be > signalled it would need to be entropy coded (I presume that if need = that > you're already entropy coding it). >=20 > If N is the number of dimensions, and K is the magnitude (sum of = absolute > values), The cardinality of the codebook, V(N,K) can be determined by = the > recursive formula: V(N,0)=3D1 ; V(0,K)=3D0; V(N,K)=3DV(N-1,K) + = V(N,K-1) + V(N- > 1,K-1) > (What CELT does internally is, obviously, much faster) >=20 > Here is a simple python script that calculates this: >=20 > ---cwrs.py--- > #!/usr/bin/python > import math,sys > sys.setrecursionlimit(32768) >=20 > memory=3D{} >=20 > def V (n,k): > if (k=3D=3D0): > return 1 > if (n=3D=3D0): > return 0 > if (n,k) not in memory: > memory[(n,k)] =3D V(n-1,k) + V(n,k-1) + V(n-1,k-1) > return memory[(n,k)] > return memory[(n,k)] >=20 > N=3D16 > for K in range(13): > print "(%d,%d)"%(N,K),math.log(V(N,K),2) >=20 > ---end: cwrs.py --- >=20 > It outputs: > (16,0) 0.0 > (16,1) 5.0 > (16,2) 9.0 > (16,3) 12.4178525149 > (16,4) 15.4262647547 > (16,5) 18.1210477887 > (16,6) 20.5636729598 > (16,7) 22.7971992119 > (16,8) 24.853601964 > (16,9) 26.7576215488 > (16,10) 28.5289824639 > (16,11) 30.1837675338 > (16,12) 31.7353184363 >=20 >=20 > If would be interesting to know how that compares to your approach, = and if > codebooks of greater than 32bits are relevant to your usage. >=20 > Cheers, >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Thu Jul 16 14:31:15 2009 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 2D74928C204 for ; Thu, 16 Jul 2009 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 MZc0NOtto4KW for ; Thu, 16 Jul 2009 14:31:14 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 536EA3A6DEA for ; Thu, 16 Jul 2009 14:31:14 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 17:31:46 -0400 Message-ID: <4A5F9C42.1020808@octasic.com> Date: Thu, 16 Jul 2009 17:31:46 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Gregory Maxwell References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net>, <4A5F11F7.4090902@usherbrooke.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jul 2009 21:31:46.0962 (UTC) FILETIME=[D25E1720:01CA065C] Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 21:31:15 -0000 Gregory Maxwell wrote: > Koen, I'm very curious how well your 'pyramid range coder' works in > terms of storage efficiency compared to the indexed PVQ scheme used in > CELT. Actually, what I'd be curious to know is how SILK computes/stores the probabilities for the number of pulses on each side of the "pyramid split". Do you store a set of probabilities for all codebook sizes and for all number of pulses? Or is there a neat "trick" we could try to reduce the splitting overhead on large CELT codebooks? Christian Hoene wrote: > please stop coding and start working! Did you call read “RFC 5434: > Considerations for Having a Successful Birds-of-a-Feather (BOF) Session”. > May I cite a few paragraphs? Since when are coding and working mutually exclusive? And what happened to rough consensus and running code? ;-) Cheers, Jean-Marc From koen.vos@skype.net Thu Jul 16 15:47:28 2009 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 D568428C254 for ; Thu, 16 Jul 2009 15:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 TMU9nKjNzWKs for ; Thu, 16 Jul 2009 15:47:27 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 185F728C1FA for ; Thu, 16 Jul 2009 15:47:26 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 1B7442007A7F0; Fri, 17 Jul 2009 00:47:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=eZO07y3u+obj aknbVf0HPevALLU=; b=U5l7i/Ajs7J2lVnpMuYH54Y75oMga4lM5dgfb8wN6rst UvXu9QJXhRnZFOQDRdw+ezK2/89eZaG5EZh25+wWTGmE59Yx78Roo/o0npu4Wpw/ OYFEtHxnMCTNKdvWDitNXHD17XjpqAgAzgLUp9hXHgngTGXDKRELnKP6i+m8fyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=gwJqXEiK5hPMIogKL6xm FiNldEKWGiJbfV78jPDiYOjGAirgqzAvcGHIkVsE8KkypyIiJzv09pJmVcyb1pg2 dDsX8oZ6V/cqHHOJ2zVa+AQnNWPl6xdlb1wjB/RGWqzzGYhLRcXI82VujWAAbA25 Y2YPrkcsowcHnEhwnIwzM2I= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 19B6F2007A7CC; Fri, 17 Jul 2009 00:47:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYIMJd5bE5rD; Fri, 17 Jul 2009 00:47:58 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 20EF02007A7DB; Fri, 17 Jul 2009 00:47:58 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Thu, 16 Jul 2009 15:47:58 -0700 Message-ID: <20090716154758.10487hmw93n2mtr2@mail.skype.net> Date: Thu, 16 Jul 2009 15:47:58 -0700 From: Koen Vos To: Gregory Maxwell References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net>, <4A5F11F7.4090902@usherbrooke.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 22:47:28 -0000 Hi Gregory, Here's how SILK's version of PVQ works: The input is a frame of integer-valued quantization indices. Each =20 frames is split into blocks of 16 indices. For each block, we =20 separately encode: (1) the sum of absolute values (which is known in =20 CELT so is not encoded there); (2) the distribution of pulses over the =20 the block; and (3) the sign of each non-zero quantization index. More about step (2): Each block is recursively split in two equal-sized halves, and the =20 distribution of summed pulses over the two halves is losslessly =20 encoded. Given that a block contains K pulses, there are K+1 ways in =20 which to distribute these K pulses over the first and second halves of =20 the block. Each of these K+1 ways has an assigned probability that is =20 stored in a table, and was computed heuristically by running on a =20 large training set. Starting with a block of 16 indices, it takes 15 =20 splits to determine the locations of all pulses. For computational =20 efficiency, splitting stops whenever a subblock contains 0 pulses. =20 Each block of 16 indices may contain up to 18 summed pulses. Subblocks =20 of size 8, 4 and 2 may contain up to 12, 8 and 6 pulses respectively. =20 If the block or any of its subblocks contains more pulses than =20 allowed, an escape mechanism is used which codes the LSBs of the =20 pulses separately. Storage (ROM) size: Separate tables are used for splitting the blocks of size 16, 8, 4 and 2: Size 16: sum(3:20) =3D 207 Size 8: sum(3:14) =3D 102 Size 4: sum(3:10) =3D 52 Size 2: sum(3:8) =3D 33 Total: 394 probability values. Compared with CELT, this method makes no assumptions on the =20 distribution of indices. It should provide an optimal encoding as long =20 as all indices within a block are i.i.d. (independent and identically =20 distributed). The ROM storage comes at a (small) cost in memory size, =20 but gives us the probability values without any computations. We've =20 tried increasing the block size to 32, but that gave no real =20 performance gain. As to Jean-Marc's question if there's a trick that could be used to =20 reduce the splitting overhead on large CELT codebooks: that might =20 indeed be possible. best, koen. Quoting Gregory Maxwell : > Jean-Marc Valin [jean-marc.valin@usherbrooke.ca] wrote: >> Koen and I have been having a technical discussion in the past few days >> before we realised that it would be best to do that publicly on the >> list. So we're moving the thread to the list and I'm attaching the >> discussion we had in private (with only very minor edits). >> [SILK_CELT_discussion.txt] > > Koen, I'm very curious how well your 'pyramid range coder' works in =20 > terms of storage efficiency compared to the indexed PVQ scheme used =20 > in CELT. > > Given uniformly distributed pyramidal vectors and providing that the =20 > sum of absolute values is known (In CELT the vectors are all unit =20 > norm, and the PVQ precision is inferred from the current state and =20 > allocation table, so this is known without signalling cost) the =20 > indexed approach CELT uses is optimal for codebooks of less than =20 > 32bits (=C2=B1 the range coder precision). However, your approach may =20 > gain some advantage from entropy coding=E2=80=94 in CELT optimal entropy = =20 > coding of the PVQ vectors appears to be a negligible improvement, =20 > but the underlying distribution of your data may be different. > > (CELT also works with vectors of many dimensions, so the memory =20 > required for probability tables was one reason the indexing scheme =20 > is used). > > For codebooks greater than 32bits CELT recursively bisects the =20 > vector in dimensions until each leaf fits in 32 bits. This is =20 > significantly less efficient, especially since the number pulses on =20 > one side is currently coded without entropy coding. But it's hardly =20 > applicable to CELT because CELT doesn't encounter codebooks this big =20 > at normal rates as most of the bits are used on low frequencies =20 > which have small bands. (The approach CELT is using does work =20 > beyond 32bits, but it requires 64-bit arithmetic) > > The approximate storage required for the CELT approach is easy to =20 > calculate (for codewords <32bits). Providing the magnitude is know =20 > the storage is just the log2 of the number of possible PVQ =20 > codewords. If the magnitude must be signalled it would need to be =20 > entropy coded (I presume that if need that you're already entropy =20 > coding it). > > If N is the number of dimensions, and K is the magnitude (sum of =20 > absolute values), The cardinality of the codebook, V(N,K) can be =20 > determined by the recursive formula: V(N,0)=3D1 ; V(0,K)=3D0; =20 > V(N,K)=3DV(N-1,K) + V(N,K-1) + V(N-1,K-1) > (What CELT does internally is, obviously, much faster) > > Here is a simple python script that calculates this: > > ---cwrs.py--- > #!/usr/bin/python > import math,sys > sys.setrecursionlimit(32768) > > memory=3D{} > > def V (n,k): > if (k=3D=3D0): > return 1 > if (n=3D=3D0): > return 0 > if (n,k) not in memory: > memory[(n,k)] =3D V(n-1,k) + V(n,k-1) + V(n-1,k-1) > return memory[(n,k)] > return memory[(n,k)] > > N=3D16 > for K in range(13): > print "(%d,%d)"%(N,K),math.log(V(N,K),2) > > ---end: cwrs.py --- > > It outputs: > (16,0) 0.0 > (16,1) 5.0 > (16,2) 9.0 > (16,3) 12.4178525149 > (16,4) 15.4262647547 > (16,5) 18.1210477887 > (16,6) 20.5636729598 > (16,7) 22.7971992119 > (16,8) 24.853601964 > (16,9) 26.7576215488 > (16,10) 28.5289824639 > (16,11) 30.1837675338 > (16,12) 31.7353184363 > > > If would be interesting to know how that compares to your approach, =20 > and if codebooks of greater than 32bits are relevant to your usage. > > Cheers, > > From jean-marc.valin@usherbrooke.ca Thu Jul 16 17:49:19 2009 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 8595328C23A for ; Thu, 16 Jul 2009 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 rsvHZazJZOIS for ; Thu, 16 Jul 2009 17:49:18 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 8C19B3A6782 for ; Thu, 16 Jul 2009 17:49:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMW009HDIB1M0C0@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Thu, 16 Jul 2009 20:49:50 -0400 (EDT) Message-id: <4A5FCAAD.5090909@usherbrooke.ca> Date: Thu, 16 Jul 2009 20:49:49 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Koen Vos References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716154758.10487hmw93n2mtr2@mail.skype.net> In-reply-to: <20090716154758.10487hmw93n2mtr2@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 00:49:19 -0000 Hi Koen, Koen Vos a écrit : > More about step (2): > Each block is recursively split in two equal-sized halves, and the > distribution of summed pulses over the two halves is losslessly encoded. > Given that a block contains K pulses, there are K+1 ways in which to > distribute these K pulses over the first and second halves of the block. > Each of these K+1 ways has an assigned probability that is stored in a > table, and was computed heuristically by running on a large training > set. Just curious, have you considered taking into account the pitch period for adjusting the probabilities? i.e. assuming that pulses are likely to be bigger at pitch intervals, even after LTP. > Starting with a block of 16 indices, it takes 15 splits to > determine the locations of all pulses. For computational efficiency, > splitting stops whenever a subblock contains 0 pulses. Each block of 16 > indices may contain up to 18 summed pulses. Subblocks of size 8, 4 and 2 > may contain up to 12, 8 and 6 pulses respectively. If the block or any > of its subblocks contains more pulses than allowed, an escape mechanism > is used which codes the LSBs of the pulses separately. Any special reason for the limit? Is it often exceeded? > Compared with CELT, this method makes no assumptions on the distribution > of indices. It should provide an optimal encoding as long as all indices > within a block are i.i.d. (independent and identically distributed). The > ROM storage comes at a (small) cost in memory size, but gives us the > probability values without any computations. We've tried increasing the > block size to 32, but that gave no real performance gain. Technically, CELT cannot use this method because we need to know in advance the precise number of bits required. However, it could potentially be useful for cases where we need to split anyway to make the codebook fit in 32 bits. It would be challenging though because unlike SILK, CELT has to deal with arbitrary vector sizes (all different) and not just 2,4,8,16. One thing that would be interesting to measure is the performance of the SILK codebook compared to what the i.i.d. assumption of CELT does. I remember measuring a while ago and the *upper bound* (measuring the entropy directly on the "training set") for some CELT codebook was about 1% improvement, which wasn't worth the complexity. I'd be curious to see if the gain is larger for the data SILK encodes. Cheers, Jean-Marc From koen.vos@skype.net Thu Jul 16 19:26:09 2009 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 A97143A6E10 for ; Thu, 16 Jul 2009 19:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 9dovCWy8WlbA for ; Thu, 16 Jul 2009 19:26:06 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 5A7FC3A6A8A for ; Thu, 16 Jul 2009 19:26:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 530022007AAA2; Fri, 17 Jul 2009 04:26:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=q33rHuUKJMpv HT3FBbOyBai8frU=; b=eL+A25VMO5CkwAYthPxtgSF1eAc1InQYvS1z2DRjcN61 yGRRoeyzPEaGA9eIRHCVmKvkPkTjE47EAoill58tQm1ZV7K35WrLfU6PLO9CdT6F FQOcFdGAtSc3+t7zQNuBPst5jJcaSgUDmBZnYc2H7ZWwPfNldepl9QpvgXDX2tY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=jybyxos5zjPuCil2bN6v WDEaTpAXQxGswVHF7LCW5317cezTfdexhqTIITKO3IIn2ZkbSSYtMATRczfq5xDs q8jEIgSTD9Ia5cKzmcJjvARBwrIm3nS8AXxAHGMlOVhTo3y6ZpCXPCsLxw/yS0cl goAXbWpFYPugBHoST9RCwPg= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 511CC2007A94D; Fri, 17 Jul 2009 04:26:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwy0sdGabRjy; Fri, 17 Jul 2009 04:26:37 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 7B8C22007A97E; Fri, 17 Jul 2009 04:26:37 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Thu, 16 Jul 2009 19:26:37 -0700 Message-ID: <20090716192637.15473m8hcbjwe2ql@mail.skype.net> Date: Thu, 16 Jul 2009 19:26:37 -0700 From: Koen Vos To: Jean-Marc Valin References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716154758.10487hmw93n2mtr2@mail.skype.net> <4A5FCAAD.5090909@usherbrooke.ca> In-Reply-To: <4A5FCAAD.5090909@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 02:26:10 -0000 Hi Jean-Marc, > Just curious, have you considered taking into account the pitch period > for adjusting the probabilities? i.e. assuming that pulses are likely to > be bigger at pitch intervals, even after LTP. If tried to look for such patterns in the sum-of-pulses (per block) parameter. This is encoded once per millisecond, in wideband mode, but I couldn't find a clear gain. > Any special reason for the limit? Is it often exceeded? At low rates it's never exceeded for normal speech signals. At high rates it's exceeded maybe a few times per second. The limit was chosen such that increasing it further didn't reduces the bitrate by more than a few bits/second. > One thing that would be interesting to measure is the performance of the > SILK codebook compared to what the i.i.d. assumption of CELT does. I > remember measuring a while ago and the *upper bound* (measuring the > entropy directly on the "training set") for some CELT codebook was about > 1% improvement, which wasn't worth the complexity. I'd be curious to see > if the gain is larger for the data SILK encodes. Initially we constructed the probability tables using combinatorial logic. The table could be filled under Laplacian assumptions or Gaussian assumptions or anything in between. The optimum was clearly around Gaussian, being perhaps a few percent better than Laplacian. I don't remember how much the trained tables improved over the Gaussian constructed tables. Not so much for sure. Frequency domain coefficients are known to have more of a Laplacian distribution, whereas a time domain LPC+LTP residual is approximately Gaussian (probably because of the least-squares optimization). That could explain why the norm-1 pyramid vector quantizer is so close to optimal for CELT. best, koen From koen.vos@skype.net Thu Jul 16 21:22:21 2009 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 1706C3A657C for ; Thu, 16 Jul 2009 21:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 66cDaeQThSIb for ; Thu, 16 Jul 2009 21:22:20 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id D07E53A6843 for ; Thu, 16 Jul 2009 21:22:19 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 155452007AAC0; Fri, 17 Jul 2009 06:22:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=I6wzPMr1wIqs 2ZJvMlSaTTLXUOU=; b=Q8VXNEbjp+kGbIG+ejztqkAKrSVcz0IvU9E5cUYWgFSm qp9AXnDyRFqzjIF0fnu9plv8BDrZ7f7b+Z3FyzPKBwxgZnaNtDRCEj6qfTPwqMUy Y2L3yIsWaTvTezmvBIESGqZXU7wqECo9xq93gnAxWBK2B3N/pT9/zbKenji0lF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=mP6hk9F/AVe8vAGnSob+ tCg5uqF6Egi5mhnMt5OCzQBeadzuHmY/5H/fKWhf1Vz4dT8ojfl5H0EP2HLrgGns YgCemrO9ScfW9RJwpvXZaIWUVY74nrmMD40zMDmsq4c/werkyOE2oQ+pC/PUVXAA b4uqMbZ3sRMq6nrWDqOC2Lc= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 139102007AAB6; Fri, 17 Jul 2009 06:22:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSj153qYq6I1; Fri, 17 Jul 2009 06:22:51 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 4FE402007AB1F; Fri, 17 Jul 2009 06:22:44 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Thu, 16 Jul 2009 21:22:44 -0700 Message-ID: <20090716212244.20712946pjat5b4k@mail.skype.net> Date: Thu, 16 Jul 2009 21:22:44 -0700 From: Koen Vos To: Jean-Marc Valin References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> In-Reply-To: <4A5F11F7.4090902@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 04:22:21 -0000 Hi Jean-Marc, Continuing the CELT discussion: >> PVQ_orth = PVQ - Pitch * (Pitch' * PVQ); (Eq. 1) > > This is is exactly (well, we a coefficient before the second term) what > I meant by the companding and that's what CELT was doing until around > 0.3.0. The complexity wasn't too bad (it doubled the search complexity > or so), but it was causing resynchronisation problems. It's probably enough to only orthogonalize after the search, when generating the reconstructed signal in the encoder (for the pitch buffer) and in the decoder. >> After a packet loss, and assuming no normalization, the Pitch >> vector has zero energy so S_quant is equal to the scaled PVQ. With >> each decoded packet Pitch gradually increases until it reaches unit >> energy. > > You mean you would force it to be smaller than unity? Because with the > normalisation it usually *has* to have unit norm. Right, maybe the Pitch vector should not be normalized after packet loss before being used in equation 1. Because after losing one or more packets, whatever Pitch is, it surely is very different from the encoder. Best might be to reset Pitch, as a result of which no orthogonalization will occur. One packet later, Pitch still contains only a small amount of useful information, and I would argue it should still not be normalized to unity. Doing so would build up noise over subsequent pitch-predicted decodes with orthogonalization. Also, forcing S_quant to be unit energy in the decoder when it only contains a small/noisy innovation signal after packet loss might reduce the quality of the decoded signal? > Right now, the pitch gain is either 0 or 0.9 (one bit for each > of the 8 "pitch bands") and to me that sounds about as good as all the > fancy things we did. How do you control error propagation when the pitch gain is 0.9? Turn off pitch prediction every so many packets? > It turns out that even though we're minimizing the > complexity added by pitch, it still nearly doubles the encoder > complexity, and as far as I can tell it only improves lower bit-rate > speech performance (<= 48 kbit/s). With SILK, turning off the LTP model reduces the PESQ MOS score from 4.5 to 3.8, at 30 kbps in wideband mode. With LTP on, the 3.8 score is reached already at 9 kbps. Is there an explanation of why pitch prediction couldn't work well for CELT? best, koen From jean-marc.valin@usherbrooke.ca Fri Jul 17 04:46:34 2009 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 8177F3A6A29 for ; Fri, 17 Jul 2009 04:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 6Nyx4a0WE28q for ; Fri, 17 Jul 2009 04:46:33 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id DF99D3A6B05 for ; Fri, 17 Jul 2009 04:46:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMX004S6CQHHR30@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Fri, 17 Jul 2009 07:47:05 -0400 (EDT) Message-id: <4A6064B8.9060307@usherbrooke.ca> Date: Fri, 17 Jul 2009 07:47:04 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Koen Vos References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> In-reply-to: <20090716212244.20712946pjat5b4k@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 11:46:34 -0000 Hi Koen, Koen Vos a écrit : >> This is is exactly (well, we a coefficient before the second term) what >> I meant by the companding and that's what CELT was doing until around >> 0.3.0. The complexity wasn't too bad (it doubled the search complexity >> or so), but it was causing resynchronisation problems. > > It's probably enough to only orthogonalize after the search, when > generating the reconstructed signal in the encoder (for the pitch > buffer) and in the decoder. This is something we've tried and it's a catastrophe. > Also, forcing S_quant to be unit energy in the decoder when it only > contains a small/noisy innovation signal after packet loss might reduce > the quality of the decoded signal? Well, what would you normalise S_quant to? We can artificially lower its energy, but normalisation is necessary because of how CELT works. > How do you control error propagation when the pitch gain is 0.9? Turn > off pitch prediction every so many packets? With a pitch gain of 0.9 and no attempt at companding or anything, the decoder naturally resyncs about as quickly as a CELT coder does (see figure 9 in http://people.xiph.org/~jm/papers/celt_tasl.pdf ). It even has the advantage that you still have the right gain and energy envelope even during the resync. For example, CELP codecs sometimes need pitch gains greater than unity for onsets whereas CELT's normalisation means that a gain smaller than zero can still predict it correctly and be more stable. You just want to make sure not to predict from a block that has *much* weaker energy to avoid numerical stability problems (it would be equivalent to having a pitch gain of 10 or something). > With SILK, turning off the LTP model reduces the PESQ MOS score from 4.5 > to 3.8, at 30 kbps in wideband mode. With LTP on, the 3.8 score is > reached already at 9 kbps. Is there an explanation of why pitch > prediction couldn't work well for CELT? Well one obvious reason we don't see as much improvement in CELT is that the LTP-off performance of CELT is much better due to the use of the MDCT rather than time-domain LPC. There is also the fact that CELT deals with a larger audio bandwidth than SILK, so the relative size of the region where LTP is useful is smaller. But that likely does not explain everything. I think the rest is due to the normalisation and how the fixed codebook gain is automatically calculated (not encoded). Whether this is worth trying to improve (given whatever cost it may have) is an open question. So far I did not find anything that could provide a significant improvement, but that doesn't mean that no such thing exists. Cheers, Jean-Marc From jason.fischl@skype.net Fri Jul 17 11:42:04 2009 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 9D6FF28C2FE for ; Fri, 17 Jul 2009 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.111, 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 XQN9rF63aRCz for ; Fri, 17 Jul 2009 11:42:03 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id AAF883A6A55 for ; Fri, 17 Jul 2009 11:42:03 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8A7392007C231 for ; Fri, 17 Jul 2009 20:42:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :from:to:content-type:content-transfer-encoding:mime-version :subject:date; s=mail; bh=4eCIBDj6RKmAO1H09icyxGydjeA=; b=fd6n+a 3Or949EL9cUEhAUUIJ4nojQa3N9jQIh3rlmgLQmJdtZJj6oai012H30eTFEC5TmP lRfht2zE4JfMRPnxl+bpCfHQx6KHWuQs/gXaOpX6SLk/sU9fcGfBBtAnnJBHFiHE gIUxWwK7ih0QxPEw6TT0dV5y5DxGA1Mh5QLaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:from:to :content-type:content-transfer-encoding:mime-version:subject: date; q=dns; s=mail; b=tVRtK9xUFpLtstJVPMMStnF2f7s8LY+vhL8aBKTb3 YNSrFMFgA7yG3Tuo/qQyf4okqrzn6yhmN2eG+A5pGs3jOjp98tLkFE92cohEfBjS P5Oo7HdRPqp3KxVGr9sc/b/yYw08OvyqAVwsK3rGl7Cm0Z9/ENWw/HRrzUIvc8En gg= Received: from [10.0.1.29] (c-69-181-180-22.hsd1.ca.comcast.net [69.181.180.22]) by mail.skype.net (Postfix) with ESMTPSA id 2DB6E2007C22D for ; Fri, 17 Jul 2009 20:42:35 +0200 (CEST) Message-Id: From: Jason Fischl To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 11:42:27 -0700 X-Mailer: Apple Mail (2.935.3) Subject: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 18:42:04 -0000 DRAFT CHARTER: The goal of this working group is to standardize audio codecs that can be implemented and used broadly, and be interoperable between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs optimized for very low bit rates or for non-interactive audio are out of scope. The codecs should address the following considerations: * suitability for most fixed-point DSPs; * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; IPR issues will be handled in accordance with BCP 79. Proposed Deliverables: 1) Detailed requirements for Internet audio codecs. 2) Algorithm description for wideband Internet audio codecs as PS. From koen.vos@skype.net Fri Jul 17 12:42:28 2009 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 F08F33A6E8D for ; Fri, 17 Jul 2009 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 S891JI1pLDC5 for ; Fri, 17 Jul 2009 12:42:28 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id C57783A683C for ; Fri, 17 Jul 2009 12:42:27 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 09A592007C234; Fri, 17 Jul 2009 21:43:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=bqtahWlWSRPT cG7khAnK0oI2Y34=; b=YBrUQ/JNkMXzf7jvav40uAV+MYr/QI0lFALFXkhBpwkH aLjTbllAfPhhsGyfaU/RanVIul3Ju3g0VuH27WZQOhfl3uz/IHfUaZgFk16Mli3q ijtND+44BhYLXDsxPYDM1BSBPI5j52QVrS1UpnuuMzNnlKTES0uoXCnwR/Yjmiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=ezrEe3qM4oQbH3RpuO5b HmR9/nqxNGte0ZJzxa2zttAhnq241vdakv3oNnIVjuWdvaN0e3TDQUXjHhDk0ePa GxtyJa6u6P+sYnnEjPbjGhTypFWCTcx3OTlMJnUtTLfmKaUfog4wEgT/OR25o8wo mE+9zWm/rSUK9sz3UdhUkTc= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 032D12007C213; Fri, 17 Jul 2009 21:43:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bQlA0W3cFVU; Fri, 17 Jul 2009 21:43:00 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 38FBE2007C22C; Fri, 17 Jul 2009 21:43:00 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Fri, 17 Jul 2009 12:43:00 -0700 Message-ID: <20090717124300.62131jenjxmnstok@mail.skype.net> Date: Fri, 17 Jul 2009 12:43:00 -0700 From: Koen Vos To: Jean-Marc Valin References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> <4A6064B8.9060307@usherbrooke.ca> In-Reply-To: <4A6064B8.9060307@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 19:42:29 -0000 Quoting Jean-Marc Valin: > Well, what would you normalise S_quant to? We can artificially lower its > energy, but normalisation is necessary because of how CELT works. Without packet loss, and asuming the PVQ signal is always normalized, the normalization factor applied to S_quant is close to 1.0 (in fact, no normalization would be needed with orthogonalization). So my thinking was you can just not do any normalization after packet loss. I guess the question is: what's more important, to get the energy right over time-frequency or to have a good SNR in each energy band. The answer might be somewhere in the middle. > Well one obvious reason we don't see as much improvement in CELT is that > the LTP-off performance of CELT is much better due to the use of the > MDCT rather than time-domain LPC. Why is that? From a rate-distortion point of view, the only advantage I can think of for MDCT over LPC is that the quantized signal has a Laplacian distribution rather than a Gaussian one. Laplacian signals can be coded at a lower bitrate, for a given SNR. The gain is < 1 kbps though... > There is also the fact that CELT deals > with a larger audio bandwidth than SILK, so the relative size of the > region where LTP is useful is smaller. True, although most bits are spent at frequencies where LTP is used. koen. From jean-marc.valin@octasic.com Fri Jul 17 12:58:36 2009 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 BDF863A690B for ; Fri, 17 Jul 2009 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 43+yRDSwYvEd for ; Fri, 17 Jul 2009 12:58:36 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id B5E1C3A683C for ; Fri, 17 Jul 2009 12:58:35 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:59:08 -0400 Message-ID: <4A60D80C.1050003@octasic.com> Date: Fri, 17 Jul 2009 15:59:08 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Koen Vos References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> <4A6064B8.9060307@usherbrooke.ca> <20090717124300.62131jenjxmnstok@mail.skype.net> In-Reply-To: <20090717124300.62131jenjxmnstok@mail.skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 19:59:08.0919 (UTC) FILETIME=[0BEDC870:01CA0719] Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 19:58:36 -0000 Hi Koen, Koen Vos wrote: > Without packet loss, and asuming the PVQ signal is always normalized, > the normalization factor applied to S_quant is close to 1.0 (in fact, no > normalization would be needed with orthogonalization). So my thinking > was you can just not do any normalization after packet loss. I think we're talking about different normalizations. When I'm talking about normalisation, I mean taking the PVQ codebook and transforming it into something of unit norm (possibly with pitch included). If you don't normalise, you have integers with a norm far greater than unity. > I guess the question is: what's more important, to get the energy right > over time-frequency or to have a good SNR in each energy band. The > answer might be somewhere in the middle. From my experience with CELT, the most important is to get the energy right, especially considering that damping everything will not make the noise any less audible (the masking threshold goes down by the same amount). > Why is that? From a rate-distortion point of view, the only advantage I > can think of for MDCT over LPC is that the quantized signal has a > Laplacian distribution rather than a Gaussian one. Laplacian signals can > be coded at a lower bitrate, for a given SNR. The gain is < 1 kbps > though... I only meant that the MDCT has better redundancy reduction than LPC alone (no LTP), especially on tonal signals (and even if the freq resolution is not that good). >> There is also the fact that CELT deals >> with a larger audio bandwidth than SILK, so the relative size of the >> region where LTP is useful is smaller. > > True, although most bits are spent at frequencies where LTP is used. Fair enough. BWT, if you're interested in making some experiments with the pitch in CELT, I can give you a hand. Most of the interesting code is in quant_bands() (bands.c) and alg_quant() (vq.c), and it's easy to completely bypass the decoder and get the synthesis signal straight from the encoder. Cheers, Jean-Marc From stephen.botzko@gmail.com Fri Jul 17 13:20:40 2009 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 CD86C28C2E8 for ; Fri, 17 Jul 2009 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.426, 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 RFpwIJ2RALTF for ; Fri, 17 Jul 2009 13:20:40 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 7F21E28C2AE for ; Fri, 17 Jul 2009 13:20:36 -0700 (PDT) Received: by fxm18 with SMTP id 18so952784fxm.37 for ; Fri, 17 Jul 2009 13:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bSYz76SiJJW6XpZ5DPCDE8UJJV06y9fB1BGeXhDKYy0=; b=SX1NbC9tFCE3aq1ur/FoQRYsuWk9D0trvyxetCB+Gszj8jSfXYyabpUjWRsCzUpfUT WunAQW73RIMd2qfkfUkahvysTOccCGBhUmeGolcSt01nI487aCRmjBFmAdNVgnRuooAG uTBEqJVQmMkp1ZN3mAU0vzpdlFT4QwsQ3SYOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EhOcx5KQVRYPW2gDtSrfJ5tHO6MwWHG639+Im92qSBwbL4OdLKwxM8I79NOLjJ/AjW ezAy3iquLEFbBsR8/J2ZpMuVt32rUuu0st5LdRUW0ajy772CC+N9McFjlfqA2WQzNQhg XKmTFn9TQQncRTK3o+UEingFVtmhed4j0GF54= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr734572fap.19.1247862067348; Fri, 17 Jul 2009 13:21:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2009 16:21:07 -0400 Message-ID: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> From: stephen botzko To: Jason Fischl Content-Type: multipart/alternative; boundary=001636c923d740c510046eec8711 Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 20:20:40 -0000 --001636c923d740c510046eec8711 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can you add "Codec Characterization Test Results" to the Proposed Deliverables? Regards, Stephen Botzko Polycom On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl wrote: > DRAFT CHARTER: > > The goal of this working group is to standardize audio codecs that can be > implemented and used broadly, and be interoperable between a wide set of > interested parties. The group is chartered to work on audio codecs for > interactive communication over the Internet. Codecs optimized for very low > bit rates or for non-interactive audio are out of scope. The codecs should > address the following considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > IPR issues will be handled in accordance with BCP 79. > > Proposed Deliverables: > 1) Detailed requirements for Internet audio codecs. > 2) Algorithm description for wideband Internet audio codecs as PS. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c923d740c510046eec8711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can you add "Codec Characterization Test Results" to the Proposed= Deliverables?

Regards,
Stephen Botzko
Polycom

On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl <jason.fischl@skype.n= et> wrote:
DRAFT CHARTER:
The goal of this working group is to standardize audio codecs that can be i= mplemented and used broadly, and be interoperable between a wide set of int= erested parties. The group is chartered to work on audio codecs for interac= tive communication over the Internet. Codecs optimized for very low bit rat= es or for non-interactive audio are out of scope. The codecs should address= the following considerations:

* suitability for most fixed-point DSPs;
* medium- to high-quality speech at moderate bit-rate;
* high-quality music encoding at higher bit-rates;
* sampling rate profiles from narrow-band to full audio bandwidth;
* real-time adaptive bit rate;
* source-controlled variable bit-rate (VBR);
* low algorithmic delay;

IPR issues will be handled in accordance with BCP 79.

Proposed Deliverables:
1) Detailed requirements for Internet audio codecs.
2) Algorithm description for wideband Internet audio codecs as PS.

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

--001636c923d740c510046eec8711-- From stewe@stewe.org Fri Jul 17 14:31:05 2009 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 632563A6F1B for ; Fri, 17 Jul 2009 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 yeBIQs46ZyJN for ; Fri, 17 Jul 2009 14:31:00 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5A3333A6A55 for ; Fri, 17 Jul 2009 14:31:00 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 345486-1743317 for multiple; Fri, 17 Jul 2009 23:31:32 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 17 Jul 2009 14:31:22 -0700 From: Stephan Wenger To: stephen botzko , Jason Fischl Message-ID: Thread-Topic: [codec] Revised Draft Charter Thread-Index: AcoHJe3mcV5BEHXyzUWntZFuQjMpYQ== In-Reply-To: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330685891_9945754" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 21:31:05 -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_3330685891_9945754 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think there would be a great value in someone explaining what =B3codec characterization=B2 actually means to those poor (majority of?) IETFers who don=B9t know... Stephan On 7/17/09 1:21 PM, "stephen botzko" wrote: > Can you add "Codec Characterization Test Results" to the Proposed > Deliverables? >=20 > Regards, > Stephen Botzko > Polycom >=20 > On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl wr= ote: >> DRAFT CHARTER: >>=20 >> The goal of this working group is to standardize audio codecs that can b= e >> implemented and used broadly, and be interoperable between a wide set of >> interested parties. The group is chartered to work on audio codecs for >> interactive communication over the Internet. Codecs optimized for very l= ow >> bit rates or for non-interactive audio are out of scope. The codecs shou= ld >> address the following considerations: >>=20 >> * suitability for most fixed-point DSPs; >> * medium- to high-quality speech at moderate bit-rate; >> * high-quality music encoding at higher bit-rates; >> * sampling rate profiles from narrow-band to full audio bandwidth; >> * real-time adaptive bit rate; >> * source-controlled variable bit-rate (VBR); >> * low algorithmic delay; >>=20 >> IPR issues will be handled in accordance with BCP 79. >>=20 >> Proposed Deliverables: >> 1) Detailed requirements for Internet audio codecs. >> 2) Algorithm description for wideband Internet audio codecs as PS. >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3330685891_9945754 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Revised Draft Charter I think there would be a great value in someone explaining what “cod= ec characterization” actually means to those poor (majority of?) IETFe= rs who don’t know...
Stephan



On 7/17/09 1:21 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Can you add "Codec Characterization Test Re= sults" to the Proposed Deliverables?

Regards,
Stephen Botzko
Polycom

On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl <jason.fischl@skype.net> wrote:
<= SPAN STYLE=3D'font-size:11pt'>DRAFT CHARTER:

The goal of this working group is to standardize audio codecs that can be i= mplemented and used broadly, and be interoperable between a wide set of inte= rested parties. The group is chartered to work on audio codecs for interacti= ve communication over the Internet. Codecs optimized for very low bit rates = or for non-interactive audio are out of scope. The codecs should address the= following considerations:

* suitability for most fixed-point DSPs;
* medium- to high-quality speech at moderate bit-rate;
* high-quality music encoding at higher bit-rates;
* sampling rate profiles from narrow-band to full audio bandwidth;
* real-time adaptive bit rate;
* source-controlled variable bit-rate (VBR);
* low algorithmic delay;

IPR issues will be handled in accordance with BCP 79.

Proposed Deliverables:
1) Detailed requirements for Internet audio codecs.
2) Algorithm description for wideband Internet audio codecs as PS.

_______________________________________________
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
--B_3330685891_9945754-- From stephen.botzko@gmail.com Fri Jul 17 17:48:47 2009 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 5119B3A698E for ; Fri, 17 Jul 2009 17:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, 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 AXj3jyIMqk+T for ; Fri, 17 Jul 2009 17:48:46 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 48EE63A6BFD for ; Fri, 17 Jul 2009 17:48:30 -0700 (PDT) Received: by bwz28 with SMTP id 28so1034700bwz.37 for ; Fri, 17 Jul 2009 17:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UPnuq1+896njFGjRNjXwb7xlGbrnH/au6Tu/6ZvOTsc=; b=Gm6yS2eR61uPDya/n7OHpXOh+pQgsQxXaRgrW1yF9Dg89n0pW1ocoRoLcu9UUwHbgn gbQ0WuJdCZpFAbkO/0yOH5aJQ3wbpW8Wna0ErImehtBwhi0dkobesPoD9/0zW3AmEPe4 Tcz0ffoQ8+DGAG9R8m1F/pDv5Ut0rcQTxG90c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fw8IxqslqaPZsHMvBRY9R7cyx5sy5jTVlJiwzoPDwS9NsgRBONvS+CwBKRORdGmXd4 cj61FFTZvA9wSTcgE1DyRiba/TrQ3bvC9ZrWZnqNgVogbxw+FtJ/mKnoA9obcO56a6di 3jbWFOQNazhXz0mGh5v8ZU1lS+XhIBeobCqqw= MIME-Version: 1.0 Received: by 10.204.117.141 with SMTP id r13mr1477878bkq.207.1247878140540; Fri, 17 Jul 2009 17:49:00 -0700 (PDT) In-Reply-To: References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> Date: Fri, 17 Jul 2009 20:49:00 -0400 Message-ID: <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> From: stephen botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=001636c599f64a3664046ef045fd Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 00:48:47 -0000 --001636c599f64a3664046ef045fd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Basically, its statistically valid testing of the codec in order to prove that it meets its requirements.. In the ITU-T process, a test plan is developed, generally testing the codec against a reference codec under stated conditions. This is worked out before selection process. It might include an audio quality requirement like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts with reverberant speech" A statistically valid listening test is then done by couple of different test labs, using reverberant speech samples in different languages, wiht a specified confidence interval. The results are then reported back for each candidate codec. 3GPP uses a similar process I'm not saying that we would need to follow the ITU-T or 3GPP characterization methods, though we should look at them. But that we will need to develop more refined requirements, and work out a statisitically valid way to prove the standard meets each requirement. Regards, Stephen Botzko Polycom On Fri, Jul 17, 2009 at 5:31 PM, Stephan Wenger wrote: > I think there would be a great value in someone explaining what =93codec > characterization=94 actually means to those poor (majority of?) IETFers w= ho > don=92t know... > Stephan > > > > > On 7/17/09 1:21 PM, "stephen botzko" wrote: > > Can you add "Codec Characterization Test Results" to the Proposed > Deliverables? > > Regards, > Stephen Botzko > Polycom > > On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl > wrote: > > DRAFT CHARTER: > > The goal of this working group is to standardize audio codecs that can be > implemented and used broadly, and be interoperable between a wide set of > interested parties. The group is chartered to work on audio codecs for > interactive communication over the Internet. Codecs optimized for very lo= w > bit rates or for non-interactive audio are out of scope. The codecs shoul= d > address the following considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > IPR issues will be handled in accordance with BCP 79. > > Proposed Deliverables: > 1) Detailed requirements for Internet audio codecs. > 2) Algorithm description for wideband Internet audio codecs as PS. > > _______________________________________________ > 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 > > --001636c599f64a3664046ef045fd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Basically, its statistically valid testing of the codec in order to prove t= hat it meets its requirements..

In the ITU-T process, a test plan i= s developed, generally testing the codec against a reference codec under st= ated conditions.=A0 This is worked out before selection process.=A0 It migh= t include an audio quality requirement like "Codec x at 16 kbits will = sound no worse than G.722 at 48 kibts with reverberant speech"

A statistically valid listening test is then done by couple of differen= t test labs, using reverberant speech samples in different languages, wiht = a specified confidence interval.=A0 The results are then reported back for = each candidate codec.

3GPP uses a similar process

I'm not saying that we would nee= d to follow the ITU-T or 3GPP characterization methods, though we should lo= ok at them.=A0 But that we will need to develop more refined requirements, = and work out a statisitically valid way to prove the standard meets each re= quirement.

Regards,
Stephen Botzko
Polycom




On Fri, Jul 17, 2009 at 5:31 PM, Stephan Wenger <stewe@stewe.org> w= rote:
I think there would be a great value in someone explaining what =93= codec characterization=94 actually means to those poor (majority of?) IETFe= rs who don=92t know...
Stephan




On 7/17/09 1:21 PM, "stephen botzko" <stephen.botzko@gmail.com> wrot= e:

Can you add "Codec Characterization Test Results" to the Pro= posed Deliverables?

Regards,
Stephen Botzko
Polycom

On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl <jason.fischl@skype.net> wrote:
DRAFT CHARTER:

The goal of this working group is to standardize audio codecs that can be i= mplemented and used broadly, and be interoperable between a wide set of int= erested parties. The group is chartered to work on audio codecs for interac= tive communication over the Internet. Codecs optimized for very low bit rat= es or for non-interactive audio are out of scope. The codecs should address= the following considerations:

* suitability for most fixed-point DSPs;
* medium- to high-quality speech at moderate bit-rate;
* high-quality music encoding at higher bit-rates;
* sampling rate profiles from narrow-band to full audio bandwidth;
* real-time adaptive bit rate;
* source-controlled variable bit-rate (VBR);
* low algorithmic delay;

IPR issues will be handled in accordance with BCP 79.

Proposed Deliverables:
1) Detailed requirements for Internet audio codecs.
2) Algorithm description for wideband Internet audio codecs as PS.

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


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

--001636c599f64a3664046ef045fd-- From steveu@coppice.org Fri Jul 17 22:14:58 2009 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 A03023A69F5 for ; Fri, 17 Jul 2009 22:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 EHPQqs3ptu4O for ; Fri, 17 Jul 2009 22:14:58 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id A85E23A69B9 for ; Fri, 17 Jul 2009 22:14:54 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6I5EnZI026152; Sat, 18 Jul 2009 13:14:49 +0800 Message-ID: <4A615A48.5040300@coppice.org> Date: Sat, 18 Jul 2009 13:14:48 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: stephen botzko References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> In-Reply-To: <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 05:14:58 -0000 Hi Stephen, stephen botzko wrote: > Basically, its statistically valid testing of the codec in order to > prove that it meets its requirements.. > > In the ITU-T process, a test plan is developed, generally testing the > codec against a reference codec under stated conditions. This is > worked out before selection process. It might include an audio > quality requirement like "Codec x at 16 kbits will sound no worse than > G.722 at 48 kibts with reverberant speech" > > A statistically valid listening test is then done by couple of > different test labs, using reverberant speech samples in different > languages, wiht a specified confidence interval. The results are then > reported back for each candidate codec. > > 3GPP uses a similar process > > I'm not saying that we would need to follow the ITU-T or 3GPP > characterization methods, though we should look at them. But that we > will need to develop more refined requirements, and work out a > statisitically valid way to prove the standard meets each requirement. Actually, that's just one side of what they consider to be codec characterisation. The other is the computational complexity. Nobody wants a fantastic sounding codec that takes 100 64x cores to implement. :-) The ITU reference code, at least for fixed point, is written so that its fairly straightforward to sum up all the saturated multiplies, saturated adds, shifts, etc. Steve From stephen.botzko@gmail.com Sat Jul 18 03:43:20 2009 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 20EA428C0E0 for ; Sat, 18 Jul 2009 03:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.427 X-Spam-Level: * X-Spam-Status: No, score=1.427 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, 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 CSCxClzCWSsC for ; Sat, 18 Jul 2009 03:43:19 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id BCF6C3A68B6 for ; Sat, 18 Jul 2009 03:43:18 -0700 (PDT) Received: by bwz28 with SMTP id 28so1159815bwz.37 for ; Sat, 18 Jul 2009 03:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=w3pMLI4+EgQ10MLmBgLFf0Yuy24OVZcB7PfRZ0Ko/DM=; b=xojd7oqK5boEr1X/OozE+Q02nz63dyxD1QmtINveZ/4oPUDu7VJcGEWkFkymg6gNHf hxAUJEa/BdLKzc0VU13X1U4aUE+DyXoEey3gmwgt+AbWs27IjH+aaRCaLVJ6L2z7cXQq RfuAoQfFbunaPcSr23OTcYNpkUDyfHj296S9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VnrXhzjicl/PgpVvOuhlE//m0t49rk+/smXDs5F3C3ARcCQKqDR7yb1zP0bAEHJiVr If7dqztb5jTQidPE37WaRrpbaUQbH6/0ES2+F+N/Uh4A3KgkbszIDZHVNkGSbY7YkVpd j9aFKrdHp3EnObBTymg+1RL/4mJSE8eZrPo5U= MIME-Version: 1.0 Received: by 10.204.58.9 with SMTP id e9mr2012673bkh.15.1247913795710; Sat, 18 Jul 2009 03:43:15 -0700 (PDT) In-Reply-To: <4A615A48.5040300@coppice.org> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> Date: Sat, 18 Jul 2009 06:43:15 -0400 Message-ID: <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> From: stephen botzko To: Steve Underwood Content-Type: multipart/alternative; boundary=001636c5bcc580f172046ef8924b Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 10:43:20 -0000 --001636c5bcc580f172046ef8924b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree that we should have a complexity requirement that is also tested, and I am fine with including that as part of characterization. In addition to computational load, we could also consider memory requirements (volatile and non volatile?) Another aspect is to ensure that the fixed and floating point versions have the same characteristics ( that all combinations - fixed->fixed, fixed->float, float->fixed, float->float - sound identical). Regards Stephen Botzko Polycom On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood wrote: > Hi Stephen, > > stephen botzko wrote: > >> Basically, its statistically valid testing of the codec in order to prove >> that it meets its requirements.. >> >> In the ITU-T process, a test plan is developed, generally testing the >> codec against a reference codec under stated conditions. This is worked out >> before selection process. It might include an audio quality requirement >> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts with >> reverberant speech" >> >> A statistically valid listening test is then done by couple of different >> test labs, using reverberant speech samples in different languages, wiht a >> specified confidence interval. The results are then reported back for each >> candidate codec. >> >> 3GPP uses a similar process >> >> I'm not saying that we would need to follow the ITU-T or 3GPP >> characterization methods, though we should look at them. But that we will >> need to develop more refined requirements, and work out a statisitically >> valid way to prove the standard meets each requirement. >> > > Actually, that's just one side of what they consider to be codec > characterisation. The other is the computational complexity. Nobody wants a > fantastic sounding codec that takes 100 64x cores to implement. :-) The ITU > reference code, at least for fixed point, is written so that its fairly > straightforward to sum up all the saturated multiplies, saturated adds, > shifts, etc. > > Steve > > --001636c5bcc580f172046ef8924b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that we should have a complexity requirement that is also tested, a= nd I am fine with including that as part of characterization.=A0 In additio= n to computational load, we could also consider memory requirements (volati= le and non volatile?)

Another aspect is to ensure that the fixed and floating point versions = have the same characteristics=A0 ( that all combinations - fixed->fixed,= fixed->float, float->fixed, float->float - sound identical).=A0 <= br>
Regards
Stephen Botzko
Polycom

= On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood <steveu@coppice.org> wrote:<= br>
Hi Stephen,


stephen botzko wrote:
Basically, its statistically valid testing of the codec in order to prove t= hat it meets its requirements..

In the ITU-T process, a test plan is developed, generally testing the codec= against a reference codec under stated conditions. =A0This is worked out b= efore selection process. =A0It might include an audio quality requirement l= ike "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts wi= th reverberant speech"

A statistically valid listening test is then done by couple of different te= st labs, using reverberant speech samples in different languages, wiht a sp= ecified confidence interval. =A0The results are then reported back for each= candidate codec.

3GPP uses a similar process

I'm not saying that we would need to follow the ITU-T or 3GPP character= ization methods, though we should look at them. =A0But that we will need to= develop more refined requirements, and work out a statisitically valid way= to prove the standard meets each requirement.

Actually, that's just one side of what they consider to be codec charac= terisation. The other is the computational complexity. Nobody wants a fanta= stic sounding codec that takes 100 64x cores to implement. :-) The ITU refe= rence code, at least for fixed point, is written so that its fairly straigh= tforward to sum up all the saturated multiplies, saturated adds, shifts, et= c.

Steve


--001636c5bcc580f172046ef8924b-- From stephen.botzko@gmail.com Sat Jul 18 05:55:30 2009 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 28F833A6A81 for ; Sat, 18 Jul 2009 05:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.715 X-Spam-Level: X-Spam-Status: No, score=0.715 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_50=0.001, 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 O1Jns2w5CToS for ; Sat, 18 Jul 2009 05:55:28 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 0CE2C3A6A53 for ; Sat, 18 Jul 2009 05:55:27 -0700 (PDT) Received: by fxm18 with SMTP id 18so1194518fxm.37 for ; Sat, 18 Jul 2009 05:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eYIhiNb023+qwdeJatF3dswuy6OOD4Lit3KRK5A9qj8=; b=mvo01MsgkfDSgYLY8eNDYwv942pCvDZ+73v3DefGRLxzCji4V5W8Pdk9IWFN8ONiKX /isK9jmApMuNerORNPkvANwDsptvEfk59gd3XBSxsgRrtD4KFMY0077GTyWLyDEW+sRB +ZMVn3GPOqFwHzdAcIR7KQYBiW5XrqbwvhLUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oSMJZQwiPS8Blb54cet5hYCxNQzZy46G1Q3q7O9PgajEDxLWAwbdS7DDqR+mGMoBqt 0TCpjMk5XKdJNLxFC5KB45anmcqnL3mP0qlagAxVl0NDOkK1Fg3RRFUkwTN7f3zXR7Oc F2cKtcyNFqGODHKYlTgQ8Id5jvnbzZ9ZgTVfE= MIME-Version: 1.0 Received: by 10.204.54.198 with SMTP id r6mr2024512bkg.191.1247921725295; Sat, 18 Jul 2009 05:55:25 -0700 (PDT) In-Reply-To: <783FF063-B8B1-43B6-88A5-D74E7E1C9ED3@telio.no> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <783FF063-B8B1-43B6-88A5-D74E7E1C9ED3@telio.no> Date: Sat, 18 Jul 2009 08:55:25 -0400 Message-ID: <6e9223710907180555n6410526p1ac0199c48e68b48@mail.gmail.com> From: stephen botzko To: Alan Duric Content-Type: multipart/alternative; boundary=001636c5ba5924cc2d046efa6b96 Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 12:55:30 -0000 --001636c5ba5924cc2d046efa6b96 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This would be a very worthwhile discussion, and IMHO should be held before any codec contributions are considered. Though I fear that we don't have enough time to get consensus on the detail= s of the codec development/selection/characterization procedures before the BOF. Regards, Stephen Botzko Polycom On Fri, Jul 17, 2009 at 9:16 PM, Alan Duric wrote: > Hi all, > > agree with Stephen for the need of such deliverable, since that will also > govern (among other things) what kind of PLC will be enclosed as referenc= e > PLC etc. Given that goal of the group is to deliver codec of a high quali= ty, > this is quite essential. > However, I would be very cautious on copying too much ITU-T and 3GPP and > using them as reference "a priori", since I find a number of nits in > those methods as outdated and believe that we can do even better job by > using it as a benchmark "a posteriori". > > regz, > alan > > > _________________________________________________________________________= ___ > "The strong do what they have to do and the weak accept what they have to > accept." -- Thucydides > > > On Jul 18, 2009, at 2:49 AM, stephen botzko wrote: > > Basically, its statistically valid testing of the codec in order to prove > that it meets its requirements.. > > In the ITU-T process, a test plan is developed, generally testing the cod= ec > against a reference codec under stated conditions. This is worked out > before selection process. It might include an audio quality requirement > like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts with > reverberant speech" > > A statistically valid listening test is then done by couple of different > test labs, using reverberant speech samples in different languages, wiht = a > specified confidence interval. The results are then reported back for ea= ch > candidate codec. > > 3GPP uses a similar process > > I'm not saying that we would need to follow the ITU-T or 3GPP > characterization methods, though we should look at them. But that we wil= l > need to develop more refined requirements, and work out a statisitically > valid way to prove the standard meets each requirement. > > Regards, > Stephen Botzko > Polycom > > > > > On Fri, Jul 17, 2009 at 5:31 PM, Stephan Wenger wrote: > >> I think there would be a great value in someone explaining what =93code= c >> characterization=94 actually means to those poor (majority of?) IETFers = who >> don=92t know... >> Stephan >> >> >> >> >> On 7/17/09 1:21 PM, "stephen botzko" wrote: >> >> Can you add "Codec Characterization Test Results" to the Proposed >> Deliverables? >> >> Regards, >> Stephen Botzko >> Polycom >> >> On Fri, Jul 17, 2009 at 2:42 PM, Jason Fischl >> wrote: >> >> DRAFT CHARTER: >> >> The goal of this working group is to standardize audio codecs that can b= e >> implemented and used broadly, and be interoperable between a wide set of >> interested parties. The group is chartered to work on audio codecs for >> interactive communication over the Internet. Codecs optimized for very l= ow >> bit rates or for non-interactive audio are out of scope. The codecs shou= ld >> address the following considerations: >> >> * suitability for most fixed-point DSPs; >> * medium- to high-quality speech at moderate bit-rate; >> * high-quality music encoding at higher bit-rates; >> * sampling rate profiles from narrow-band to full audio bandwidth; >> * real-time adaptive bit rate; >> * source-controlled variable bit-rate (VBR); >> * low algorithmic delay; >> >> IPR issues will be handled in accordance with BCP 79. >> >> Proposed Deliverables: >> 1) Detailed requirements for Internet audio codecs. >> 2) Algorithm description for wideband Internet audio codecs as PS. >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --001636c5ba5924cc2d046efa6b96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This would be a very worthwhile discussion, and IMHO should be held before = any codec contributions are considered.

Though I fear that we don= 9;t have enough time to get consensus on the details of the codec developme= nt/selection/characterization procedures before the BOF.=A0

Regards,
Stephen Botzko
Polycom

On Fri, Jul 17, 2009 at 9:16 PM, Alan Duric <alan@telio.no> wrote:
Hi all,

agree with Stephen for the need of su= ch deliverable, since that will also govern (among other things) what kind = of PLC will be enclosed as reference PLC etc. Given that goal of the group = is to deliver codec of a high quality, this is quite essential.
However, I would be very cautious on copying too much ITU-T and 3GPP a= nd using them as reference "a priori", since I find a number of n= its in those=A0methods=A0as outdated and believe that we can do even better= job by using it as a benchmark "a posteriori".

regz,
alan

_________= ___________________________________________________________________
"The strong do what they have to do and the weak accept what they h= ave to accept." -- Thucydides


On = Jul 18, 2009, at 2:49 AM, stephen botzko wrote:

Basically, its statistically valid testing of the codec in order = to prove that it meets its requirements..

In the ITU-T process, a test plan is developed, generally testing the c= odec against a reference codec under stated conditions.=A0 This is worked o= ut before selection process.=A0 It might include an audio quality requireme= nt like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibt= s with reverberant speech"

A statistically valid listening test is then done by couple of differe= nt test labs, using reverberant speech samples in different languages, wiht= a specified confidence interval.=A0 The results are then reported back for= each candidate codec.

3GPP uses a similar process

I'm not saying that we would ne= ed to follow the ITU-T or 3GPP characterization methods, though we should l= ook at them.=A0 But that we will need to develop more refined requirements,= and work out a statisitically valid way to prove the standard meets each r= equirement.

Regards,
Stephen Botzko
Polycom




On Fri, Jul 17, 2009 at 5:31 PM, Stephan Wenger <stewe@stewe.o= rg> wrote:
I= think there would be a great value in someone explaining what =93codec cha= racterization=94 actually means to those poor (majority of?) IETFers who do= n=92t know...
Stephan



=
On 7/17/09 1:21 PM, "stephen botzko" <stephen.botzko@gmail.com>= ; wrote:

Ca= n you add "Codec Characterization Test Results" to the Proposed D= eliverables?

Regards,
Stephen Botzko
Polycom

On Fri, Jul 17, 2009= at 2:42 PM, Jason Fischl <jason.fischl@skype.net> wrote:
 DRAFT CHARTER:

The goal of this working group is to standa= rdize audio codecs that can be implemented and used broadly, and be interop= erable between a wide set of interested parties. The group is chartered to = work on audio codecs for interactive communication over the Internet. Codec= s optimized for very low bit rates or for non-interactive audio are out of = scope. The codecs should address the following considerations:

* suitability for most fixed-point DSPs;
* medium- to high-qualit= y speech at moderate bit-rate;
* high-quality music encoding at higher = bit-rates;
* sampling rate profiles from narrow-band to full audio band= width;
* real-time adaptive bit rate;
* source-controlled variable bit-rate (= VBR);
* low algorithmic delay;

IPR issues will be handled in a= ccordance with BCP 79.

Proposed Deliverables:
1) Detailed requ= irements for Internet audio codecs.
2) Algorithm description for wideband Internet audio codecs as PS.
_______________________________________________
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

______________________________= _________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listi= nfo/codec


--001636c5ba5924cc2d046efa6b96-- From koen.vos@skype.net Sat Jul 18 06:14:06 2009 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 9622628C0E0 for ; Sat, 18 Jul 2009 06:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, 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 oHBGQp9rzCRd for ; Sat, 18 Jul 2009 06:14:05 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 4EC393A6BAF for ; Sat, 18 Jul 2009 06:14:05 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C42392007C12C for ; Sat, 18 Jul 2009 15:14:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=/zJpJu2KhvXa Al9vjJ0gLtedE2w=; b=jvB+eU5GsspS9eW1frP2l9gJ/AX6IazUSvSXxumX/0CD w6ugOePNeu8j+nhwNiZ161L+Q7KKzHaSdXMnp8LNyE0roHf3QlKQ4A2uv51iGCoT 8PcisuvXpAW+c8IouFJi+I/C+WKToAQqpaUOrTS37GACRtHD3QILNSTxxXL/D2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=lPvn/Ttmg2qRjov5XVjs 9raWQcQNEhHx9KAjNXYVVlAhZMTr4vdMSL9NDWwnDVqOtgosHSMc9JsIYmiKtl8o ipHV3kNvGwG4E89ydigIxBXdXWsr1Rg73iDxT0+w4Y89cXleHViLPM0buyiCW/C1 IWHBkHE0KAiv+aU5KIAFfEk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C29EE2007AB27 for ; Sat, 18 Jul 2009 15:14:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWyf06PqMUEV for ; Sat, 18 Jul 2009 15:13:59 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id DB02F2007AB50; Sat, 18 Jul 2009 15:13:59 +0200 (CEST) Received: from a80-101-196-128.adsl.xs4all.nl (a80-101-196-128.adsl.xs4all.nl [80.101.196.128]) by mail.skype.net (Horde Framework) with HTTP; Sat, 18 Jul 2009 06:13:59 -0700 Message-ID: <20090718061359.13046nca2lhexuhj@mail.skype.net> Date: Sat, 18 Jul 2009 06:13:59 -0700 From: Koen Vos To: codec@ietf.org References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> In-Reply-To: <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 13:14:06 -0000 The validation testing may need some thinking. For example, G.718 used 7 independent listening labs (which usually cost between $10k and $20k each to run one listening batch). It may be hard to find that kind of money for testing a royalty-free codec. But agree that we will need some mechanism to compare a candidate against (1) the requirements and (2) other candidates. Testing the combinations of float and fixed-point versions can perhaps be done with objective measurement tools like PESQ or PEAQ. I believe this is how ITU also does it(?) Complexity: Average WMOPS complexity, measured over a test file? Memory consumption measures: - RAM (static/state) - RAM (scratch) - ROM (tables) - Program ROM is a bit trickier, not sure we need it..? best, koen. Quoting stephen botzko : > I agree that we should have a complexity requirement that is also tested, > and I am fine with including that as part of characterization. In addition > to computational load, we could also consider memory requirements (volatile > and non volatile?) > > Another aspect is to ensure that the fixed and floating point versions have > the same characteristics ( that all combinations - fixed->fixed, > fixed->float, float->fixed, float->float - sound identical). > > Regards > Stephen Botzko > Polycom > > On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood wrote: > >> Hi Stephen, >> >> stephen botzko wrote: >> >>> Basically, its statistically valid testing of the codec in order to prove >>> that it meets its requirements.. >>> >>> In the ITU-T process, a test plan is developed, generally testing the >>> codec against a reference codec under stated conditions. This is >>> worked out >>> before selection process. It might include an audio quality requirement >>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts with >>> reverberant speech" >>> >>> A statistically valid listening test is then done by couple of different >>> test labs, using reverberant speech samples in different languages, wiht a >>> specified confidence interval. The results are then reported back for each >>> candidate codec. >>> >>> 3GPP uses a similar process >>> >>> I'm not saying that we would need to follow the ITU-T or 3GPP >>> characterization methods, though we should look at them. But that we will >>> need to develop more refined requirements, and work out a statisitically >>> valid way to prove the standard meets each requirement. >>> >> >> Actually, that's just one side of what they consider to be codec >> characterisation. The other is the computational complexity. Nobody wants a >> fantastic sounding codec that takes 100 64x cores to implement. :-) The ITU >> reference code, at least for fixed point, is written so that its fairly >> straightforward to sum up all the saturated multiplies, saturated adds, >> shifts, etc. >> >> Steve >> >> > From stephen.botzko@gmail.com Sat Jul 18 06:22:34 2009 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 E455E3A69FD for ; Sat, 18 Jul 2009 06:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 vnDYPBvon89o for ; Sat, 18 Jul 2009 06:22:33 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 5F42E3A6C3F for ; Sat, 18 Jul 2009 06:20:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so1201446fxm.37 for ; Sat, 18 Jul 2009 06:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rI5bG4Lpiwip3G+H+Kuv1k9mnL5ga2Ymq4f/MqDOZDk=; b=sXiZwTtgqyNWEicmvvrOw7q2wCgtrqzQwLMkPLU3WbJuANE/2lTiqs+zgjMTQh0rpS 3Yc1yAjsNavz/e+vzmj4jIesj8dMDk+88vCep0cHQDcvsVd0fju8t4wrAaP+HiU5wP+P 0YpawpqoaQFgkSrMK2MPz4gtNCsJrAMu58e3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tq1fxTEqEr3sGVCTRZGWSezj+Q99yMzm3djpoaXdvkCOesBzsm82Ej56FZoyMqWt19 yZMDP33Ddt5F+L2dqAMeZCwLpcN8JwZ7Q0FzloQ09X5oeCndoSeyP331WAp9RhoK78Fh EpG13lohh0uk1RpUJFpTcR+9HZxpFDMJoAuw0= MIME-Version: 1.0 Received: by 10.204.117.141 with SMTP id r13mr2072781bkq.207.1247923235642; Sat, 18 Jul 2009 06:20:35 -0700 (PDT) In-Reply-To: <20090718061359.13046nca2lhexuhj@mail.skype.net> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> Date: Sat, 18 Jul 2009 09:20:35 -0400 Message-ID: <6e9223710907180620y60222921i19af65a5947f6f94@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636c599f62adcce046efac56c Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 13:22:35 -0000 --001636c599f62adcce046efac56c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm hearing a consensus that characterization testing should be a charter deliverable, but that the specific methods need more development. Does anyone hold a different view? Regards, Stephen Botzko Polycom On Sat, Jul 18, 2009 at 9:13 AM, Koen Vos wrote: > The validation testing may need some thinking. For example, G.718 used 7 > independent listening labs (which usually cost between $10k and $20k each to > run one listening batch). It may be hard to find that kind of money for > testing a royalty-free codec. But agree that we will need some mechanism to > compare a candidate against (1) the requirements and (2) other candidates. > > Testing the combinations of float and fixed-point versions can perhaps be > done with objective measurement tools like PESQ or PEAQ. I believe this is > how ITU also does it(?) > > Complexity: > Average WMOPS complexity, measured over a test file? > > Memory consumption measures: > - RAM (static/state) > - RAM (scratch) > - ROM (tables) > - Program ROM is a bit trickier, not sure we need it..? > > best, > koen. > > > > Quoting stephen botzko : > > I agree that we should have a complexity requirement that is also tested, >> and I am fine with including that as part of characterization. In >> addition >> to computational load, we could also consider memory requirements >> (volatile >> and non volatile?) >> >> Another aspect is to ensure that the fixed and floating point versions >> have >> the same characteristics ( that all combinations - fixed->fixed, >> fixed->float, float->fixed, float->float - sound identical). >> >> Regards >> Stephen Botzko >> Polycom >> >> On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood >> wrote: >> >> Hi Stephen, >>> >>> stephen botzko wrote: >>> >>> Basically, its statistically valid testing of the codec in order to >>>> prove >>>> that it meets its requirements.. >>>> >>>> In the ITU-T process, a test plan is developed, generally testing the >>>> codec against a reference codec under stated conditions. This is worked >>>> out >>>> before selection process. It might include an audio quality requirement >>>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts >>>> with >>>> reverberant speech" >>>> >>>> A statistically valid listening test is then done by couple of different >>>> test labs, using reverberant speech samples in different languages, wiht >>>> a >>>> specified confidence interval. The results are then reported back for >>>> each >>>> candidate codec. >>>> >>>> 3GPP uses a similar process >>>> >>>> I'm not saying that we would need to follow the ITU-T or 3GPP >>>> characterization methods, though we should look at them. But that we >>>> will >>>> need to develop more refined requirements, and work out a statisitically >>>> valid way to prove the standard meets each requirement. >>>> >>>> >>> Actually, that's just one side of what they consider to be codec >>> characterisation. The other is the computational complexity. Nobody wants >>> a >>> fantastic sounding codec that takes 100 64x cores to implement. :-) The >>> ITU >>> reference code, at least for fixed point, is written so that its fairly >>> straightforward to sum up all the saturated multiplies, saturated adds, >>> shifts, etc. >>> >>> Steve >>> >>> >>> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c599f62adcce046efac56c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm hearing a consensus that characterization testing should be a chart= er deliverable, but that the specific methods need more development.=A0 Doe= s anyone hold a different view?

Regards,
Stephen Botzko
Polyco= m

On Sat, Jul 18, 2009 at 9:13 AM, Koen Vos <koen.vos@skype.ne= t> wrote:
The validation testing may need some thinking. For example, G.718 used 7 in= dependent listening labs (which usually cost between $10k and $20k each to = run one listening batch). =A0It may be hard to find that kind of money for = testing a royalty-free codec. =A0But agree that we will need some mechanism= to compare a candidate against (1) the requirements and (2) other candidat= es.

Testing the combinations of float and fixed-point versions can perhaps be d= one with objective measurement tools like PESQ or PEAQ. I believe this is h= ow ITU also does it(?)

Complexity:
Average WMOPS complexity, measured over a test file?

Memory consumption measures:
- RAM (static/state)
- RAM (scratch)
- ROM (tables)
- Program ROM is a bit trickier, not sure we need it..?

best,
koen.



Quoting stephen botzko <stephen.botzko@gmail.com>:

I agree that we should have a complexity requirement that is also tested, and I am fine with including that as part of characterization. =A0In additi= on
to computational load, we could also consider memory requirements (volatile=
and non volatile?)

Another aspect is to ensure that the fixed and floating point versions have=
the same characteristics =A0( that all combinations - fixed->fixed,
fixed->float, float->fixed, float->float - sound identical).

Regards
Stephen Botzko
Polycom

On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood <steveu@coppice.org> wrote:

Hi Stephen,

stephen botzko wrote:

Basically, its statistically valid testing of the codec in order to prove that it meets its requirements..

In the ITU-T process, a test plan is developed, generally testing the
codec against a reference codec under stated conditions. =A0This is worked = out
before selection process. =A0It might include an audio quality requirement<= br> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts w= ith
reverberant speech"

A statistically valid listening test is then done by couple of different test labs, using reverberant speech samples in different languages, wiht a<= br> specified confidence interval. =A0The results are then reported back for ea= ch
candidate codec.

3GPP uses a similar process

I'm not saying that we would need to follow the ITU-T or 3GPP
characterization methods, though we should look at them. =A0But that we wil= l
need to develop more refined requirements, and work out a statisitically valid way to prove the standard meets each requirement.


Actually, that's just one side of what they consider to be codec
characterisation. The other is the computational complexity. Nobody wants a=
fantastic sounding codec that takes 100 64x cores to implement. :-) The ITU=
reference code, at least for fixed point, is written so that its fairly
straightforward to sum up all the saturated multiplies, saturated adds,
shifts, etc.

Steve





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

--001636c599f62adcce046efac56c-- From jean-marc.valin@usherbrooke.ca Sat Jul 18 06:43:52 2009 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 069FD3A6948 for ; Sat, 18 Jul 2009 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 Tpq4z2YcJRKo for ; Sat, 18 Jul 2009 06:43:51 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id EE3CD3A684F for ; Sat, 18 Jul 2009 06:43:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMZ00DJ3CSR3R80@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Sat, 18 Jul 2009 09:43:40 -0400 (EDT) Message-id: <4A61D18A.7040201@usherbrooke.ca> Date: Sat, 18 Jul 2009 09:43:38 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Koen Vos References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> In-reply-to: <20090718061359.13046nca2lhexuhj@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 13:43:52 -0000 Koen Vos a écrit : > The validation testing may need some thinking. For example, G.718 used 7 > independent listening labs (which usually cost between $10k and $20k > each to run one listening batch). It may be hard to find that kind of > money for testing a royalty-free codec. But agree that we will need > some mechanism to compare a candidate against (1) the requirements and > (2) other candidates. The question is what to use for comparison in the first place. I tend to think that the only useful reference we have is unencumbered codecs. For example, SILK might be tested against Speex. I'm not sure what CELT could be tested against considering the large bandwidth it has and the very low delay. Regarding validation, I think we should also have a look at the MPEG process and see what they do there. I'm not familiar enough with MPEG, though. Does anyone know more about that process? > Testing the combinations of float and fixed-point versions can perhaps > be done with objective measurement tools like PESQ or PEAQ. I believe > this is how ITU also does it(?) Sounds reasonable, though that assumes both fixed-point and floating-point are available. I don't think it's a problem for CELT and SILK, but do we want to mandate that for everyone. > Complexity: > Average WMOPS complexity, measured over a test file? I'm less sure on this one. There are several issues that make WMOPS less than ideal: * it forces you to code the fixed-point in a certain way (e.g. fractional vs interger multiply); * it's designed for a 16-bit (TI) DSP and is not very respresentative of modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; * it completely ignore issues such as conditional branches, which can be more important than arithmetic operations on modern architectures; * some of its operators (e.g. those that use a global overflow flag) are ugly, to say the least. I'm not sure what to use instead for complexity, but I'm also wondering if we want a fixed complexity requirement up-front. For example, why not use "rough consensus" as a means to determine whether a codec's complexity is acceptable for most people. > Memory consumption measures: > - RAM (static/state) > - RAM (scratch) > - ROM (tables) > - Program ROM is a bit trickier, not sure we need it..? Regarding size, I would think it may also be a good idea to seek rough consensus. Cheers, Jean-Marc > best, > koen. > > > Quoting stephen botzko : > >> I agree that we should have a complexity requirement that is also tested, >> and I am fine with including that as part of characterization. In >> addition >> to computational load, we could also consider memory requirements >> (volatile >> and non volatile?) >> >> Another aspect is to ensure that the fixed and floating point versions >> have >> the same characteristics ( that all combinations - fixed->fixed, >> fixed->float, float->fixed, float->float - sound identical). >> >> Regards >> Stephen Botzko >> Polycom >> >> On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood >> wrote: >> >>> Hi Stephen, >>> >>> stephen botzko wrote: >>> >>>> Basically, its statistically valid testing of the codec in order to >>>> prove >>>> that it meets its requirements.. >>>> >>>> In the ITU-T process, a test plan is developed, generally testing the >>>> codec against a reference codec under stated conditions. This is >>>> worked out >>>> before selection process. It might include an audio quality >>>> requirement >>>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts >>>> with >>>> reverberant speech" >>>> >>>> A statistically valid listening test is then done by couple of >>>> different >>>> test labs, using reverberant speech samples in different languages, >>>> wiht a >>>> specified confidence interval. The results are then reported back >>>> for each >>>> candidate codec. >>>> >>>> 3GPP uses a similar process >>>> >>>> I'm not saying that we would need to follow the ITU-T or 3GPP >>>> characterization methods, though we should look at them. But that >>>> we will >>>> need to develop more refined requirements, and work out a >>>> statisitically >>>> valid way to prove the standard meets each requirement. >>>> >>> >>> Actually, that's just one side of what they consider to be codec >>> characterisation. The other is the computational complexity. Nobody >>> wants a >>> fantastic sounding codec that takes 100 64x cores to implement. :-) >>> The ITU >>> reference code, at least for fixed point, is written so that its fairly >>> straightforward to sum up all the saturated multiplies, saturated adds, >>> shifts, etc. >>> >>> Steve >>> >>> >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From koen.vos@skype.net Sat Jul 18 07:45:08 2009 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 801373A696B for ; Sat, 18 Jul 2009 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CHPF1H+0SeR for ; Sat, 18 Jul 2009 07:45:07 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 5A4F43A6857 for ; Sat, 18 Jul 2009 07:45:07 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 872C12007C150; Sat, 18 Jul 2009 16:45:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=Fub/uL5+2W+P ngyLTeC5O3s1UjI=; b=DcKfubicxMYqNsnXLHeszWVIl/g8w7N5q4hopfBy2QCj ixkk5/gV4B8PwbwgEc7NCbUQPrQ0xvu+qpVO9nPh+WF83rNzSD8gvXRcaWTC8Rpr uXVL0w/a/HxDru+2iS/GdIJOljv5TRqMkuvOo3gODxwzNOfeG011fNGz0f/Jei8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=F23a0PKgI2aPM28bOlPA LF7jFqvo38FMMUlLD6f3pIt3XrO7lsQUQ47SDUpF99NuooFQrSbIXHEfWxpyWKIf Rf5Zc5/2jkMnRFMF1/w7QH/JUnr8fkM9B8koBVipmjOqlLQDNssjzkybkzW5nLHt xVL10zAH0QiC3Rxs2fzQAaQ= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 859B42007A7F0; Sat, 18 Jul 2009 16:45:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHlcIgoMyENv; Sat, 18 Jul 2009 16:45:05 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id D8B892007C14E; Sat, 18 Jul 2009 16:45:05 +0200 (CEST) Received: from a80-101-196-128.adsl.xs4all.nl (a80-101-196-128.adsl.xs4all.nl [80.101.196.128]) by mail.skype.net (Horde Framework) with HTTP; Sat, 18 Jul 2009 07:45:05 -0700 Message-ID: <20090718074505.66636jfwdy3nrwfl@mail.skype.net> Date: Sat, 18 Jul 2009 07:45:05 -0700 From: Koen Vos To: Jean-Marc Valin References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> <4A6064B8.9060307@usherbrooke.ca> <20090717124300.62131jenjxmnstok@mail.skype.net> <4A60D80C.1050003@octasic.com> In-Reply-To: <4A60D80C.1050003@octasic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 14:45:08 -0000 > From my experience with CELT, the most important is to get the > energy right, especially considering that damping everything will > not make the noise any less audible (the masking threshold goes down > by the same amount). Makes sense. > I only meant that the MDCT has better redundancy reduction than LPC > alone (no LTP), especially on tonal signals (and even if the freq > resolution is not that good). For the redundancy reduction to lead to a lower bitrate requires a model to describe how energy is distributed over MDCT bins/bands. CELT uses a model with 20 energy bands, which gives a similar flexibility in describing the energy distribution as an LPC model of order 16. Beyond that, within a single energy band, there is (almost) no coding gain from having all energy sitting in one bin instead of it being spread over all bins. (And the small gain that exists comes from the Laplacian rather than Gaussian encoding.) > BWT, if you're interested in making some experiments with the pitch > in CELT, I can give you a hand. Most of the interesting code is in > quant_bands() (bands.c) and alg_quant() (vq.c), and it's easy to > completely bypass the decoder and get the synthesis signal straight > from the encoder. Sounds interesting for sure. I'll take a look at the code and get back to you. koen. From koen.vos@skype.net Sat Jul 18 07:55:57 2009 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 49C143A69E7 for ; Sat, 18 Jul 2009 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=1.842, 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 Wh8klgm8buWk for ; Sat, 18 Jul 2009 07:55:56 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 11D2C3A69DB for ; Sat, 18 Jul 2009 07:55:56 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 162582007C147; Sat, 18 Jul 2009 16:55:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=neM6Pq9CBYFd vCnm+RLchufxNEM=; b=Tm8bNVNtEf3eR691+FOQIJWdscXmPFOF24NuqoZ5sych Eg3g/MgcfO4jlf8fDE1WuXI4fCpk0El2c3XxqPCLBiZp29UkDLly2r4RJtbgDEnA 04AeB/IZE2jKfUX+Nce96PyvXmk5hgj+xEvoFSD41g47a1ulPhx51fkeUDjM8ho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=FzVSR9QMIncl+uFCpgKu MJosr9OmAe78mCz9UFG5iOHGbGZM9++yoeujO7L+Tpj79vZwMksLiqxTRVcuSNBP VTwbQvVFlVBzN103xKNBjG3iKKXrwS8pytndQ628WjjvIA8SPXMUwszgB++fnlnZ sgnanGhAdfWUz98FGmsUdic= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 146EC2007A7F0; Sat, 18 Jul 2009 16:55:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRhatgDOaTfu; Sat, 18 Jul 2009 16:55:54 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 690322007C15A; Sat, 18 Jul 2009 16:55:54 +0200 (CEST) Received: from a80-101-196-128.adsl.xs4all.nl (a80-101-196-128.adsl.xs4all.nl [80.101.196.128]) by mail.skype.net (Horde Framework) with HTTP; Sat, 18 Jul 2009 07:55:54 -0700 Message-ID: <20090718075554.167032uicopmr33u@mail.skype.net> Date: Sat, 18 Jul 2009 07:55:54 -0700 From: Koen Vos To: Jean-Marc Valin References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> In-Reply-To: <4A61D18A.7040201@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 14:55:57 -0000 Quoting Jean-Marc Valin: > I'm not sure what to use instead for complexity, but I'm also wondering > if we want a fixed complexity requirement up-front. For example, why not > use "rough consensus" as a means to determine whether a codec's > complexity is acceptable for most people. Agree with your points on WMOPS, let's forget about that one. Rough consensus based on MHz on an x86 core is simple to measure and gives already a pretty meaningful indication. > Regarding size, I would think it may also be a good idea to seek rough > consensus. Works for me. koen. From jean-marc.valin@usherbrooke.ca Sat Jul 18 11:11:15 2009 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 E70363A69F4 for ; Sat, 18 Jul 2009 11:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_20=-0.74] 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 cb+Z9BYnGVWf for ; Sat, 18 Jul 2009 11:11:15 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 0500D3A696B for ; Sat, 18 Jul 2009 11:11:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KMZ00LQOP6PL620@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Sat, 18 Jul 2009 14:11:14 -0400 (EDT) Message-id: <4A621041.6050804@usherbrooke.ca> Date: Sat, 18 Jul 2009 14:11:13 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: Koen Vos References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> <4A6064B8.9060307@usherbrooke.ca> <20090717124300.62131jenjxmnstok@mail.skype.net> <4A60D80C.1050003@octasic.com> <20090718074505.66636jfwdy3nrwfl@mail.skype.net> In-reply-to: <20090718074505.66636jfwdy3nrwfl@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 18:11:16 -0000 Koen Vos a écrit : > For the redundancy reduction to lead to a lower bitrate requires a model > to describe how energy is distributed over MDCT bins/bands. CELT uses a > model with 20 energy bands, which gives a similar flexibility in > describing the energy distribution as an LPC model of order 16. Not strictly related to coding efficiency, but the MDCT band model used by CELT is closer to a *warped* LPC model. However, the main advantage is that you get more control over the quantisation error, because you can control it independently for each band, whereas LSP quantization error is hard to control efficiently and tends to spread across the whole spectrum. That being said, I agree that an all-pole model is probably best when speech is the only thing you want to encode. > Beyond > that, within a single energy band, there is (almost) no coding gain from > having all energy sitting in one bin instead of it being spread over all > bins. (And the small gain that exists comes from the Laplacian rather > than Gaussian encoding.) The gain is actually pretty big. It's probably not that much in terms of SNR, but mainly perceptually. I once tried quantising using a "random rotation matrix" to spread/unspread the PVQ pulses (so that "pulses" end up looking like noise) and the sound quality went down dramatically. Cheers, Jean-Marc From stephen.botzko@gmail.com Sat Jul 18 12:02:44 2009 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 0D1093A6A67 for ; Sat, 18 Jul 2009 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 2lUgIkFSmc+W for ; Sat, 18 Jul 2009 12:02:42 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id DB1723A683A for ; Sat, 18 Jul 2009 12:02:41 -0700 (PDT) Received: by bwz28 with SMTP id 28so1295955bwz.37 for ; Sat, 18 Jul 2009 12:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=17zcUOSdBqZzrOPXLUTBshakDTq2FqcyjHQwHBsWRKI=; b=v+sEkMmEFdd+UPy0iF78BZxTRI+1el2ADLISi6yHuZqgv6O+pJ+sCW4+4XvUCD8EFW qKtkQfm5b3r1EEfyDewZl9h38I0OaLHIKqSOyHwGI1OedcTmFmvOGjAm7k/7L2UFIP8L NM22DbFKLtSHs4C6+kNrE+EjMWJl1CNXfG3gA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IYf0UVQqlCwihtEq2w+x4tO3+CoAnjQG3uVa9wO8xYKHEZbgwOdcQek4IFJcJMo0Bb 1GTWA8ZuO6OiYdMwaHNDQh1xZzTBKXfJGI7SgosO/sFF8qZ0NDrXhPOcaevAXtOeAvjV DCFOtJTYdKHW7vaIKtT4/UQ2N/ayjgFf4yFYI= MIME-Version: 1.0 Received: by 10.223.121.208 with SMTP id i16mr790857far.32.1247943687795; Sat, 18 Jul 2009 12:01:27 -0700 (PDT) In-Reply-To: <6e9223710907180733t70e8cbb8o79cd67d5c2ed439a@mail.gmail.com> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <6e9223710907180733t70e8cbb8o79cd67d5c2ed439a@mail.gmail.com> Date: Sat, 18 Jul 2009 15:01:27 -0400 Message-ID: <6e9223710907181201m3c92e507s9f6066b0d0420b5d@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636c5b58f35f368046eff886b Subject: [codec] Fwd: Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 19:02:44 -0000 --001636c5b58f35f368046eff886b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (meant to post this to the list) ---------- Forwarded message ---------- From: stephen botzko Date: Sat, Jul 18, 2009 at 10:33 AM Subject: Re: [codec] Revised Draft Charter To: Jean-Marc Valin Some comments in line. I would suggest though that we should first get agreement on adding the one line to the charter, and re-issue the draft with that line in it. Iterating the charter draft is probably the most efficient way to get consensus on th= e charter, and I think it is cleanest if the drafts all come through you and Jason. Regards, Stephen Botzko Polycom On Sat, Jul 18, 2009 at 9:43 AM, Jean-Marc Valin < jean-marc.valin@usherbrooke.ca> wrote: > Koen Vos a =E9crit : > > The validation testing may need some thinking. For example, G.718 used = 7 > > independent listening labs (which usually cost between $10k and $20k > > each to run one listening batch). It may be hard to find that kind of > > money for testing a royalty-free codec. But agree that we will need > > some mechanism to compare a candidate against (1) the requirements and > > (2) other candidates. > > The question is what to use for comparison in the first place. I tend to > think that the only useful reference we have is unencumbered codecs. For > example, SILK might be tested against Speex. I'm not sure what CELT > could be tested against considering the large bandwidth it has and the > very low delay. I agree that this is an important question. In other SDOs, this is worked out on a case by case basis, and depends on the market application that is being targeted. Personally, I don't think it matters much if you use RF or royalty-bearing codecs as references, it is more important that the test conditions be properly set. Note that you don't necessarily need to out-perform the reference - for instance "codec x at 12 kbits is not worse than G.729 at 8 kbits" might be appropriate for a low-complexity codec. > > Regarding validation, I think we should also have a look at the MPEG > process and see what they do there. I'm not familiar enough with MPEG, > though. Does anyone know more about that process? MPEG should also be looked at of course. I believe its process is similar t= o the other SDOs, with one very important caveat - MPEG does not standardize encoders, so their characterization tests are not easily reproducible. Given our goals, I think we will be standardizing both the encoder and the decoder, and should be testing them as a pair. > > > > Testing the combinations of float and fixed-point versions can perhaps > > be done with objective measurement tools like PESQ or PEAQ. I believe > > this is how ITU also does it(?) > > Sounds reasonable, though that assumes both fixed-point and > floating-point are available. I don't think it's a problem for CELT and > SILK, but do we want to mandate that for everyone. Agreed that if there aren't both versions available, that it would not be required (how reasonable is THAT!) Though I suspect we will find that both fixed and float versions will be necessary. The ITU-T has recently used objective measurement tools for this (G.719 was done that way), it is inexpensive since it does not require any listening tests. > > > > Complexity: > > Average WMOPS complexity, measured over a test file? > > I'm less sure on this one. There are several issues that make WMOPS less > than ideal: > * it forces you to code the fixed-point in a certain way (e.g. > fractional vs interger multiply); > * it's designed for a 16-bit (TI) DSP and is not very respresentative of > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; > * it completely ignore issues such as conditional branches, which can be > more important than arithmetic operations on modern architectures; > * some of its operators (e.g. those that use a global overflow flag) are > ugly, to say the least. > > I'm not sure what to use instead for complexity, but I'm also wondering > if we want a fixed complexity requirement up-front. For example, why not > use "rough consensus" as a means to determine whether a codec's > complexity is acceptable for most people. > > > Memory consumption measures: > > - RAM (static/state) > > - RAM (scratch) > > - ROM (tables) > > - Program ROM is a bit trickier, not sure we need it..? > > Regarding size, I would think it may also be a good idea to seek rough > consensus . > > Cheers, > > Jean-Marc > > > best, > > koen. > > > > > > Quoting stephen botzko : > > > >> I agree that we should have a complexity requirement that is also > tested, > >> and I am fine with including that as part of characterization. In > >> addition > >> to computational load, we could also consider memory requirements > >> (volatile > >> and non volatile?) > >> > >> Another aspect is to ensure that the fixed and floating point versions > >> have > >> the same characteristics ( that all combinations - fixed->fixed, > >> fixed->float, float->fixed, float->float - sound identical). > >> > >> Regards > >> Stephen Botzko > >> Polycom > >> > >> On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood > >> wrote: > >> > >>> Hi Stephen, > >>> > >>> stephen botzko wrote: > >>> > >>>> Basically, its statistically valid testing of the codec in order to > >>>> prove > >>>> that it meets its requirements.. > >>>> > >>>> In the ITU-T process, a test plan is developed, generally testing th= e > >>>> codec against a reference codec under stated conditions. This is > >>>> worked out > >>>> before selection process. It might include an audio quality > >>>> requirement > >>>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 kibts > >>>> with > >>>> reverberant speech" > >>>> > >>>> A statistically valid listening test is then done by couple of > >>>> different > >>>> test labs, using reverberant speech samples in different languages, > >>>> wiht a > >>>> specified confidence interval. The results are then reported back > >>>> for each > >>>> candidate codec. > >>>> > >>>> 3GPP uses a similar process > >>>> > >>>> I'm not saying that we would need to follow the ITU-T or 3GPP > >>>> characterization methods, though we should look at them. But that > >>>> we will > >>>> need to develop more refined requirements, and work out a > >>>> statisitically > >>>> valid way to prove the standard meets each requirement. > >>>> > >>> > >>> Actually, that's just one side of what they consider to be codec > >>> characterisation. The other is the computational complexity. Nobody > >>> wants a > >>> fantastic sounding codec that takes 100 64x cores to implement. :-) > >>> The ITU > >>> reference code, at least for fixed point, is written so that its fair= ly > >>> straightforward to sum up all the saturated multiplies, saturated add= s, > >>> shifts, etc. > >>> > >>> Steve > >>> > >>> > >> > > > > > > _______________________________________________ > > 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 > --001636c5b58f35f368046eff886b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (meant to post this to the list)

--------= -- Forwarded message ----------
From: step= hen botzko <stephen.botzko@gmail.com>
Date: Sat, Jul 18, 2009 at 10:33 AM
Subject: Re: [codec] Revised Draft C= harter
To: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>


Some comments in= line.=A0

I would suggest though that we should first get agreement on adding the= one line to the charter, and re-issue the draft with that line in it. Iter= ating the charter draft is probably the most efficient way to get consensus= on the charter, and I think it is cleanest if the drafts all come through = you and Jason.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 18, 2009 at 9:43 AM, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:
Koen Vos a =E9cri= t :
> The validation testing may need some thinking. For example, G.718= used 7
> independent listening labs (which usually cost between $10k and $20k > each to run one listening batch). =A0It may be hard to find that kind = of
> money for testing a royalty-free codec. =A0But agree that we will need=
> some mechanism to compare a candidate against (1) the requirements and=
> (2) other candidates.

The question is what to use for comparison in the first place. I tend= to
think that the only useful reference we have is unencumbered codecs. For example, SILK might be tested against Speex. I'm not sure what CELT
could be tested against considering the large bandwidth it has and the
very low delay.
=A0
I agree that this is a= n important question.=A0 In other SDOs, this is worked out on a case by cas= e basis, and depends on the market application that is being targeted.=A0 P= ersonally, I don't think it matters much if you use RF or royalty-beari= ng codecs as references, it is more important that the test conditions be p= roperly set.=A0 Note that you don't necessarily need to out-perform the= reference - for instance "codec x at 12 kbits is not worse than G.729= at 8 kbits" might be appropriate for a low-complexity codec.
=A0

Regarding validation, I think we should also have a look at the MPEG
process and see what they do there. I'm not familiar enough with MPEG,<= br> though. Does anyone know more about that process?
=A0
MPEG should also be looked at of course. I believe its process = is similar to the other SDOs, with one very important caveat - MPEG does no= t standardize encoders, so their characterization tests are not easily repr= oducible.=A0 Given our goals, I think we will be standardizing both the enc= oder and the decoder, and should be testing them as a pair.


> Testing the combinations of float and fixed-point versions can perhaps=
> be done with objective measurement tools like PESQ or PEAQ. I believe<= br> > this is how ITU also does it(?)

Sounds reasonable, though that assumes both fixed-point and
floating-point are available. I don't think it's a problem for CELT= and
SILK, but do we want to mandate that for everyone.
=A0
Agreed that if there aren't both versions available, that = it would not be required (how reasonable is THAT!)=A0 Though I suspect we w= ill find that both fixed and float versions will be necessary.=A0 The ITU-T= has recently used objective measurement tools for this (G.719 was done tha= t way), it is inexpensive since it does not require any listening tests. =A0


> Complexity:
> Average WMOPS complexity, measured over a test file?

I'm less sure on this one. There are several issues that make WMO= PS less
than ideal:
* it forces you to code the fixed-point in a certain way (e.g.
fractional vs interger multiply);
* it's designed for a 16-bit (TI) DSP and is not very respresentative o= f
modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC;
* it completely ignore issues such as conditional branches, which can be more important than arithmetic operations on modern architectures;
* some of its operators (e.g. those that use a global overflow flag) are ugly, to say the least.

I'm not sure what to use instead for complexity, but I'm also wonde= ring
if we want a fixed complexity requirement up-front. For example, why not use "rough consensus" as a means to determine whether a codec'= ;s
complexity is acceptable for most people.

> Memory consumption measures:
> - RAM (static/state)
> - RAM (scratch)
> - ROM (tables)
> - Program ROM is a bit trickier, not sure we need it..?

Regarding size, I would think it may also be a good idea to seek roug= h
consensus=A0
.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

> best,
> koen.
>
>
> Quoting stephen botzko <stephen.botzko@gmail.com>:
>
>> I agree that we should have a complexity requirement that is also = tested,
>> and I am fine with including that as part of characterization. =A0= In
>> addition
>> to computational load, we could also consider memory requirements<= br> >> (volatile
>> and non volatile?)
>>
>> Another aspect is to ensure that the fixed and floating point vers= ions
>> have
>> the same characteristics =A0( that all combinations - fixed->fi= xed,
>> fixed->float, float->fixed, float->float - sound identica= l).
>>
>> Regards
>> Stephen Botzko
>> Polycom
>>
>> On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood <steveu@coppice.org>
>> wrote:
>>
>>> Hi Stephen,
>>>
>>> stephen botzko wrote:
>>>
>>>> Basically, its statistically valid testing of the codec in= order to
>>>> prove
>>>> that it meets its requirements..
>>>>
>>>> In the ITU-T process, a test plan is developed, generally = testing the
>>>> codec against a reference codec under stated conditions. = =A0This is
>>>> worked out
>>>> before selection process. =A0It might include an audio qua= lity
>>>> requirement
>>>> like "Codec x at 16 kbits will sound no worse than G.= 722 at 48 kibts
>>>> with
>>>> reverberant speech"
>>>>
>>>> A statistically valid listening test is then done by coupl= e of
>>>> different
>>>> test labs, using reverberant speech samples in different l= anguages,
>>>> wiht a
>>>> specified confidence interval. =A0The results are then rep= orted back
>>>> for each
>>>> candidate codec.
>>>>
>>>> 3GPP uses a similar process
>>>>
>>>> I'm not saying that we would need to follow the ITU-T = or 3GPP
>>>> characterization methods, though we should look at them. = =A0But that
>>>> we will
>>>> need to develop more refined requirements, and work out a<= br> >>>> statisitically
>>>> valid way to prove the standard meets each requirement. >>>>
>>>
>>> Actually, that's just one side of what they consider to be= codec
>>> characterisation. The other is the computational complexity. N= obody
>>> wants a
>>> fantastic sounding codec that takes 100 64x cores to implement= . :-)
>>> The ITU
>>> reference code, at least for fixed point, is written so that i= ts fairly
>>> straightforward to sum up all the saturated multiplies, satura= ted adds,
>>> shifts, etc.
>>>
>>> Steve
>>>
>>>
>>
>
>
> _______________________________________________
> 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


--001636c5b58f35f368046eff886b-- From stephen.botzko@gmail.com Sat Jul 18 12:04:44 2009 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 E63DC3A696B for ; Sat, 18 Jul 2009 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=1.370, 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 bBBgOgJs7mx3 for ; Sat, 18 Jul 2009 12:04:44 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 8D2073A683A for ; Sat, 18 Jul 2009 12:04:43 -0700 (PDT) Received: by bwz28 with SMTP id 28so1296468bwz.37 for ; Sat, 18 Jul 2009 12:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=QXNksMnq7xku1hb3pW/tVGKiO28H0XPURXNio43H7Eg=; b=oZo2K5nYWnoBE7TCFSPsRaDRjms6waQv7TUhBC8z9AkwGcTkFfyqT/TBTxE7zkgfRe RRzuB7PeVuTWP9m/RtfF0IRUB8bwqITVgOtfeZYIgGxTbjA7P2N+i0TEVeGOLxJW7sXs 3lcENBc69AttK5Hv+iBQCdD4gjjZCZsUmW+YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KZn4nEzHk1HZ3Gz1bcqLaotQNX94OJWYnnFEAhsO0T9yXwTsRerhhlvBuXq2BdMa0z 1Rtvjo5ZZybKPoxnXiZiRhQFgxbqVFpEA/PlSZH8D/YNvA4H8/j+7Tr+v0KZnA+Q+pzm LFmCFyuFQrRIG5v5wuCfiXvrqIZ2m5+y7hndM= MIME-Version: 1.0 Received: by 10.223.107.135 with SMTP id b7mr787634fap.30.1247943800761; Sat, 18 Jul 2009 12:03:20 -0700 (PDT) In-Reply-To: <4A620DAF.6080002@usherbrooke.ca> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <6e9223710907180733t70e8cbb8o79cd67d5c2ed439a@mail.gmail.com> <4A620DAF.6080002@usherbrooke.ca> Date: Sat, 18 Jul 2009 15:03:20 -0400 Message-ID: <6e9223710907181203vf0098cbw61b4b37e3ed7ad8d@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636c5b314f1add4046eff8e94 Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 19:04:45 -0000 --001636c5b314f1add4046eff8e94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (taking the liberty of fowarding Jean-Marc's reply) On Sat, Jul 18, 2009 at 2:00 PM, Jean-Marc Valin < jean-marc.valin@usherbrooke.ca> wrote: > stephen botzko a =E9crit : > > MPEG should also be looked at of course. I believe its process is > > similar to the other SDOs, with one very important caveat - MPEG does > > not standardize encoders, so their characterization tests are not easil= y > > reproducible. Given our goals, I think we will be standardizing both > > the encoder and the decoder, and should be testing them as a pair. > > Actually, there are some significant advantages to the way MPEG > standardises only the decoders, provided there is a decent reference > encoder. It means that the codec can keep improving for some time, while > still retaining compatibility. The best example of that is probably MP3, > where the current encoders are much, much better than the original > reference encoder (and other 15 years old encoders). The potential for > improvement isn't as large for a speech codec, but it's not negligible. > Speex has improved (in a backward-compatible way) since the bit-stream > was frozen and CELT certainly has potential for encoder-side > improvements. I don't know enough about the details of SILK to comment, > but I'd be surprised if there wasn't room for improvement. Even G.711 > got improved recently (G.711.1 sounds better in compatibility mode even > without enhancement layers). > > In any case, I'm not saying I know how we should standardise the codec > (decoder vs both), but it's certainly something to consider. I think the > idea is to have as much flexibility as possible while making sure not to > create compatibility problems. > > Cheers, > > Jean-Marc > --001636c5b314f1add4046eff8e94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (taking the liberty of fowarding Jean-Marc's reply)

On Sat, Jul 18, 2009 at 2:00 PM, Jean-Marc Valin <jean-marc.va= lin@usherbrooke.ca> wrote:
stephen botzko a = =E9crit :
> MPEG should also be looked at of course. I believe i= ts process is
> similar to the other SDOs, with one very important caveat - MPEG does<= br> > not standardize encoders, so their characterization tests are not easi= ly
> reproducible. =A0Given our goals, I think we will be standardizing bot= h
> the encoder and the decoder, and should be testing them as a pair.

Actually, there are some significant advantages to the way MPEG
standardises only the decoders, provided there is a decent reference
encoder. It means that the codec can keep improving for some time, while still retaining compatibility. The best example of that is probably MP3, where the current encoders are much, much better than the original
reference encoder (and other 15 years old encoders). The potential for
improvement isn't as large for a speech codec, but it's not negligi= ble.
Speex has improved (in a backward-compatible way) since the bit-stream
was frozen and CELT certainly has potential for encoder-side
improvements. I don't know enough about the details of SILK to comment,=
but I'd be surprised if there wasn't room for improvement. Even G.7= 11
got improved recently (G.711.1 sounds better in compatibility mode even
without enhancement layers).

In any case, I'm not saying I know how we should standardise the codec<= br> (decoder vs both), but it's certainly something to consider. I think th= e
idea is to have as much flexibility as possible while making sure not to create compatibility problems.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

--001636c5b314f1add4046eff8e94-- From stephen.botzko@gmail.com Sat Jul 18 12:05:35 2009 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 BA0363A6AC0 for ; Sat, 18 Jul 2009 12:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=1.096, 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 rC+gzAvkrbL8 for ; Sat, 18 Jul 2009 12:05:34 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 5A60C3A6AB6 for ; Sat, 18 Jul 2009 12:05:33 -0700 (PDT) Received: by fxm18 with SMTP id 18so1296846fxm.37 for ; Sat, 18 Jul 2009 12:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=epfN6j0e5k6RT+ljtWrtD/uwRFADtaWs+DtHFmC1xng=; b=VU4cZFfe15o5z1u5VUIMYb4Xmg7W8E4u+mJ9hPzfMrsB7XVc6Ojp+IRbJATJ56CiBe uaobvPWtFp1zOPXKbrzEagK1rWDu00zqK4KzZSKYs30mMTAO3IiemLxOQPcM6fJ5f3Yi QEDEs+ZjrjOvxpxWCNnoewIV8kO2uhgwzmcvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZZbiN/XPbMY6dcWKvbPXXR0WYQfcGe2SogOJZTu1oAkrd2v9YbmqkE45JvpfBKYlQ/ S5LJobOo6Iq/4S4qs+UnJmQ0UuM5mqDYi4bov/qQIZ55oDL3KSznIAG9p+zAHViP23CM ARbq5bURQnE/fur0WUnBrSatLY0q5vNoClkfM= MIME-Version: 1.0 Received: by 10.223.121.208 with SMTP id i16mr791272far.32.1247943871902; Sat, 18 Jul 2009 12:04:31 -0700 (PDT) In-Reply-To: <6e9223710907181134y3cb0da0apf610132c1760737a@mail.gmail.com> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <6e9223710907180733t70e8cbb8o79cd67d5c2ed439a@mail.gmail.com> <4A620DAF.6080002@usherbrooke.ca> <6e9223710907181134y3cb0da0apf610132c1760737a@mail.gmail.com> Date: Sat, 18 Jul 2009 15:04:31 -0400 Message-ID: <6e9223710907181204m4b1decf0ocf239334cb2d4f77@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636c5b58f2f3675046eff93ea Subject: [codec] Fwd: Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 19:05:35 -0000 --001636c5b58f2f3675046eff93ea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (meant to put this on the lost) ---------- Forwarded message ---------- From: stephen botzko Date: Sat, Jul 18, 2009 at 2:34 PM Subject: Re: [codec] Revised Draft Charter To: Jean-Marc Valin Though I can't speak authoritatively on the MPEG process, it's my understanding that the encoder(s) used in the characerization are neither disclosed nor publicly available. I can understand how that might work for broadcast applications, but it seems sub-optimal for speech codecs. If anyone has a different (or more complete) understanding of the MPEG approach, I'd be interested in hearing it. Stephen Botzko Polycom On Sat, Jul 18, 2009 at 2:00 PM, Jean-Marc Valin < jean-marc.valin@usherbrooke.ca> wrote: > stephen botzko a =E9crit : > > MPEG should also be looked at of course. I believe its process is > > similar to the other SDOs, with one very important caveat - MPEG does > > not standardize encoders, so their characterization tests are not easil= y > > reproducible. Given our goals, I think we will be standardizing both > > the encoder and the decoder, and should be testing them as a pair. > > Actually, there are some significant advantages to the way MPEG > standardises only the decoders, provided there is a decent reference > encoder. It means that the codec can keep improving for some time, while > still retaining compatibility. The best example of that is probably MP3, > where the current encoders are much, much better than the original > reference encoder (and other 15 years old encoders). The potential for > improvement isn't as large for a speech codec, but it's not negligible. > Speex has improved (in a backward-compatible way) since the bit-stream > was frozen and CELT certainly has potential for encoder-side > improvements. I don't know enough about the details of SILK to comment, > but I'd be surprised if there wasn't room for improvement. Even G.711 > got improved recently (G.711.1 sounds better in compatibility mode even > without enhancement layers). > > In any case, I'm not saying I know how we should standardise the codec > (decoder vs both), but it's certainly something to consider. I think the > idea is to have as much flexibility as possible while making sure not to > create compatibility problems. > > Cheers, > > Jean-Marc > --001636c5b58f2f3675046eff93ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (meant to put this on the lost)

---------= - Forwarded message ----------
From: steph= en botzko <stephen.botzko@gmail.com>
Date: Sat, Jul 18, 2009 at 2:34 PM
Subject: Re: [codec] Revised Draft Ch= arter
To: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>


Though I can'= t speak authoritatively on the MPEG process, it's my understanding that= the encoder(s) used in the characerization are neither disclosed nor publi= cly available.=A0 I can understand how that might work for broadcast applic= ations, but it seems sub-optimal for speech codecs.

If anyone has a different (or more complete) understanding of the MPEG = approach, I'd be interested in hearing it.
<= br>Stephen Botzko
Polycom


On Sat, Jul 18, 2009 at 2:00 PM, Jean-Marc V= alin <jean-marc.valin@usherbrooke.ca> wrote:
stephen botzko a = =E9crit :
> MPEG should also be looked at of course. I believe its process is=
> similar to the other SDOs, with one very important caveat - MPEG does<= br> > not standardize encoders, so their characterization tests are not easi= ly
> reproducible. =A0Given our goals, I think we will be standardizing bot= h
> the encoder and the decoder, and should be testing them as a pair.

Actually, there are some significant advantages to the way MPEG
standardises only the decoders, provided there is a decent reference
encoder. It means that the codec can keep improving for some time, while still retaining compatibility. The best example of that is probably MP3, where the current encoders are much, much better than the original
reference encoder (and other 15 years old encoders). The potential for
improvement isn't as large for a speech codec, but it's not negligi= ble.
Speex has improved (in a backward-compatible way) since the bit-stream
was frozen and CELT certainly has potential for encoder-side
improvements. I don't know enough about the details of SILK to comment,=
but I'd be surprised if there wasn't room for improvement. Even G.7= 11
got improved recently (G.711.1 sounds better in compatibility mode even
without enhancement layers).

In any case, I'm not saying I know how we should standardise the codec<= br> (decoder vs both), but it's certainly something to consider. I think th= e
idea is to have as much flexibility as possible while making sure not to create compatibility problems.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc


--001636c5b58f2f3675046eff93ea-- From steveu@coppice.org Sat Jul 18 20:08:02 2009 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 910903A6A3C for ; Sat, 18 Jul 2009 20:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 MWvMoWPkgc8z for ; Sat, 18 Jul 2009 20:08:01 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 83AD43A67A1 for ; Sat, 18 Jul 2009 20:08:01 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6J37wx5008058; Sun, 19 Jul 2009 11:07:59 +0800 Message-ID: <4A628E0E.6090100@coppice.org> Date: Sun, 19 Jul 2009 11:07:58 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jean-Marc Valin References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> In-Reply-To: <4A61D18A.7040201@usherbrooke.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 03:08:02 -0000 Jean-Marc Valin wrote: > Koen Vos a écrit : > >> Complexity: >> Average WMOPS complexity, measured over a test file? >> > > I'm less sure on this one. There are several issues that make WMOPS less > than ideal: > * it forces you to code the fixed-point in a certain way (e.g. > fractional vs interger multiply); > * it's designed for a 16-bit (TI) DSP and is not very respresentative of > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; > * it completely ignore issues such as conditional branches, which can be > more important than arithmetic operations on modern architectures; > * some of its operators (e.g. those that use a global overflow flag) are > ugly, to say the least. > > I'm not sure what to use instead for complexity, but I'm also wondering > if we want a fixed complexity requirement up-front. For example, why not > use "rough consensus" as a means to determine whether a codec's > complexity is acceptable for most people. > I agree with this concern. The ITU approach was supposed to be kind of generic in its counting of instructions, but has ended up quite the opposite. It is based around the notion of a machine implementing saturating arithmetic as a basic operation. This is true for pretty much any DSP, but when you use an ARM, a MIPS or a Intel/AMD machine the instruction count is wildly wrong. Also, the ITU approach only tries to get an instruction count for the fixed point implementations. The floating point computational complexity is also very important these days. >> Memory consumption measures: >> - RAM (static/state) >> - RAM (scratch) >> - ROM (tables) >> - Program ROM is a bit trickier, not sure we need it..? >> > > Regarding size, I would think it may also be a good idea to seek rough > consensus. > You will probably end up with two sets of reference sizes - one for fixed point and one for floating. I guess the other interesting area of implementational performance is bit exactness. For many older codecs (e.g. G.722) bit exactness was a vital concern, or the decoder would not properly unwind the actions of the coder. For most modern codecs its not that interesting. It is generally possible to make fixed point implementations bit exact, and its generally impractical to make floating point ones bit exact. However, even in the fixed point case, bit exactness may be highly undesirable. On an modern x86_64 machine I could make a perfectly good fixed point G.729 that runs far faster than a bit exact one. Steve From koen.vos@skype.net Sun Jul 19 00:26:58 2009 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 965033A6C11 for ; Sun, 19 Jul 2009 00:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=1.228, 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 aUJBQz0UGEyY for ; Sun, 19 Jul 2009 00:26:57 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 0878F3A6920 for ; Sun, 19 Jul 2009 00:25:31 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 97AB62007AB5E; Sun, 19 Jul 2009 09:25:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=rIhawUY7qJQy nw34h8uaT3olehc=; b=Gf2kwMZTemDSygvqco42tyTC3aV1Rg/am/nJ5fI4d/Fu ktILlRoFo9tgY6meNdIrJqo3sxd1MDlIt80acx7fNnRqfx9cNumYLlBRG5de9c5H 4ScECqY6dLZFahD6yrfRMYf9K/VajV48bhVlugsR2eMyqNyVCGvTFbIaKMdpDEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=whGa10iQD7v1wYMd+Iaj V5FWZ5wYmdZfKd8n3aiXXD5lnHj6LiQFdBghiMUzH6Mci1NxQGO4Od0kPpYmET5M SQ9Bucno9l9fcbZ1ZdBQMk2hZGKfnn1Wc4lmj3+6uJlc7kRjt7oMe19+SMvHkAVu E9WvNGBB0yqJMjW9eT74ji4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9603F2007AB36; Sun, 19 Jul 2009 09:25:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwPUDmuh5d8N; Sun, 19 Jul 2009 09:25:29 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id E4D392007AB44; Sun, 19 Jul 2009 09:25:29 +0200 (CEST) Received: from a80-101-196-128.adsl.xs4all.nl (a80-101-196-128.adsl.xs4all.nl [80.101.196.128]) by mail.skype.net (Horde Framework) with HTTP; Sun, 19 Jul 2009 00:25:29 -0700 Message-ID: <20090719002529.18636x0bw4i8nxpl@mail.skype.net> Date: Sun, 19 Jul 2009 00:25:29 -0700 From: Koen Vos To: Jean-Marc Valin References: <4A54056B.6060007@usherbrooke.ca> <20090708140113.57962ievv8itadqx@mail.skype.net> <4A552BE7.5070909@usherbrooke.ca> <20090713040306.1241262wsohetoq2@mail.skype.net> <4A5B1DC9.4020005@usherbrooke.ca> <20090713210748.16753o56u4hxmaok@mail.skype.net> <4A5C0B6E.9080605@usherbrooke.ca> <20090713221109.486731esbhtqysml@mail.skype.net> <4A5C6930.3080006@usherbrooke.ca> <20090714225004.1357112pvshm8w0c@mail.skype.net> <4A5F11F7.4090902@usherbrooke.ca> <20090716212244.20712946pjat5b4k@mail.skype.net> <4A6064B8.9060307@usherbrooke.ca> <20090717124300.62131jenjxmnstok@mail.skype.net> <4A60D80C.1050003@octasic.com> <20090718074505.66636jfwdy3nrwfl@mail.skype.net> <4A621041.6050804@usherbrooke.ca> In-Reply-To: <4A621041.6050804@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Comments on draft-vos-silk-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 07:26:58 -0000 Quoting Jean-Marc Valin: > Not strictly related to coding efficiency, but the MDCT band model used > by CELT is closer to a *warped* LPC model. True. > However, the main advantage is that you get more control over the > quantisation error, because you can control it independently for > each band, whereas LSP quantization error is hard to control > efficiently and tends to spread across the whole spectrum. SILK uses LPC to minimize the residual energy, and, thus, the bitrate. LSP/LSF quantization works well for that. The quantization error in SILK is controlled through noise shaping, and is largely independent of the LPC model and LSF quantization. Because this noise shaping is done only on the encoder side, it can be based on any model for distributing quantization noise over the spectrum (including frequency domain masking models), without breaking the bitstream or affecting the LPC model. > The gain is actually pretty big. It's probably not that much in terms of > SNR, but mainly perceptually. I once tried quantising using a "random > rotation matrix" to spread/unspread the PVQ pulses (so that "pulses" end > up looking like noise) and the sound quality went down dramatically. Interesting. The same thing applies to LPC in the time domain: LPC is good at encoding short impulses in time without time-domain smearing artifacts like pre-echoes. So I guess there's a perceptual advantage when the basis functions mimic the signal's time-frequency energy distribution, because it's easier to handle the large dynamic range. best, koen. From ron.even.tlv@gmail.com Mon Jul 20 02:02:03 2009 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 61C533A6B8F for ; Mon, 20 Jul 2009 02:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 GzLePITLD44N for ; Mon, 20 Jul 2009 02:02:02 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 541CE3A6AF1 for ; Mon, 20 Jul 2009 02:02:01 -0700 (PDT) Received: by fxm18 with SMTP id 18so1827309fxm.37 for ; Mon, 20 Jul 2009 01:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=pa4WL+WHUARQtzwhzUuJ7tbh7gut/edkE6OaChD2yrM=; b=V7YI81Rtum4OJdaudsBbEY4wHj+fLCTgdZQY2XgbMfLuvDGDe1NT2DqTICS4puAg9T Z0sc41YmBnCT3lsDQffeMkU15sfSwvqxJzGVvz3doDuGPJTRv21e3U/v0XyKWLQUPdKi aXXTbNz8OtGrFqZ67OKYhTFyT3cBxn+4SDa7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=gCswInEmdRJIa/vV25cRVWYBJ0S46SzvbT5PVMyb9boN+ZRQ+rzdn9z+vpNMiIxaN4 WMthU8j7Kwrzo7DTgE4YhdfTpZnrJeCUlvTx9rNgcE7RK1NbwPpnzIP+zoQhWSeucS6L y+2cF8yRcANEGbyOqpxUHZmNg0DIwKczM1wWA= Received: by 10.102.219.11 with SMTP id r11mr710902mug.82.1248080276823; Mon, 20 Jul 2009 01:57:56 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id u26sm20863548mug.22.2009.07.20.01.57.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 01:57:55 -0700 (PDT) From: "Roni Even" To: "'Koen Vos'" , "'Jean-Marc Valin'" References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <20090718075554.167032uicopmr33u@mail.skype.net> In-Reply-To: <20090718075554.167032uicopmr33u@mail.skype.net> Date: Mon, 20 Jul 2009 11:56:35 +0300 Message-ID: <4a643193.1ade660a.14bc.ffffda65@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoHt9zm+3Sru6jbTNaiyXEHaOtqpABX774A Content-language: en-us Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:02:03 -0000 Hi, I am not sure I understand what you mean when you say rough consensus here. Does it mean that after the codec is specified and in WGLC the complexity will be agreed by rough consensus. I would think that people need of know ahead of time what is the requirement and how to measure it. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Saturday, July 18, 2009 5:56 PM > To: Jean-Marc Valin > Cc: codec@ietf.org > Subject: Re: [codec] Revised Draft Charter > > Quoting Jean-Marc Valin: > > > I'm not sure what to use instead for complexity, but I'm also > wondering > > if we want a fixed complexity requirement up-front. For example, why > not > > use "rough consensus" as a means to determine whether a codec's > > complexity is acceptable for most people. > > Agree with your points on WMOPS, let's forget about that one. > > Rough consensus based on MHz on an x86 core is simple to measure and > gives already a pretty meaningful indication. > > > > Regarding size, I would think it may also be a good idea to seek > rough > > consensus. > > Works for me. > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Mon Jul 20 02:05:35 2009 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 E89653A6CB6 for ; Mon, 20 Jul 2009 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11] 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 ksz0Z8ZLMdVI for ; Mon, 20 Jul 2009 02:05:33 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 500AE3A696D for ; Mon, 20 Jul 2009 02:05:11 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so545036fgg.18 for ; Mon, 20 Jul 2009 02:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=AeWQwEKK4kvPustKR+Ewn0wmkhtoxBRi2BZmZuZqsXE=; b=wKxUz55z4Vfa+3Ho2Jci3mPyhrI+6gzWtoWCvXnvnsVKIj5vfDMjSYmdAmUPWdAcdb 8QihSg+V/N5t2ALgUSLtvLq2NZsBqKRyhr56ixDt+DZ/AFV/Q0FuWkCP62sPeigoTlPd xnPUNjHhWJa7/wvpeFXJe/1UfixOjhIhQWFv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=f1u18xfj3xxsXJoRfyWprZK1boNLdrL3QwYO6eLo3pvITLal9Q/XWwj1WWkU4O+cva bcDDg1/XX2MLoo9t8se76WrzmqkohA/a8lHwfJcXMqPoPxGAvEOZ7oDUPSepfSrLUKcx TqpqYGPs1TSYnBNYJNwkSu3Idbqa6V3TBBoP4= Received: by 10.86.30.9 with SMTP id d9mr3485779fgd.28.1248080619959; Mon, 20 Jul 2009 02:03:39 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id e11sm9348858fga.6.2009.07.20.02.03.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 02:03:39 -0700 (PDT) From: "Roni Even" To: "'Jason Fischl'" , References: In-Reply-To: Date: Mon, 20 Jul 2009 12:02:19 +0300 Message-ID: <4a6432eb.0b38560a.3860.643d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoHDl6CkLYM+/95QCu+mV+cSDKD9gCCe/Gw Content-language: en-us Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:05:36 -0000 Hi, This looks to me like a very wide charter for a long living WG. The charter says that the WG will standardize audio codecs without giving any limit on the number of such codecs nor does the charter limit the scope of such codecs since it uses very broad terms for considerations. Is this the real purpose of the WG. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jason Fischl > Sent: Friday, July 17, 2009 9:42 PM > To: codec@ietf.org > Subject: [codec] Revised Draft Charter > > DRAFT CHARTER: > > The goal of this working group is to standardize audio codecs that can > be implemented and used broadly, and be interoperable between a wide > set of interested parties. The group is chartered to work on audio > codecs for interactive communication over the Internet. Codecs > optimized for very low bit rates or for non-interactive audio are out > of scope. The codecs should address the following considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > IPR issues will be handled in accordance with BCP 79. > > Proposed Deliverables: > 1) Detailed requirements for Internet audio codecs. > 2) Algorithm description for wideband Internet audio codecs as PS. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Mon Jul 20 02:22:21 2009 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 9A47C3A6D32 for ; Mon, 20 Jul 2009 02:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 XTD7+WKlL6ik for ; Mon, 20 Jul 2009 02:22:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 543A93A6D2D for ; Mon, 20 Jul 2009 02:22:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so425398fga.18 for ; Mon, 20 Jul 2009 02:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=QLX97zvt5cI2izZ6sO/1JdPVxahQagpoUN7XkDXJH1M=; b=VLCmVFxKKP3+mN9e0e24UuSWtJ9tn12jzyqRDkq2QjdeL1p4tFIFBOgsY1/AJCTYuv AKdlJiTAM3Tw3zZHLWm85QMEqTm0FhiIbl3qcLy7v0pOrhJ8CySUdheoux0xh4xK/oxH CM8vlhKBibVfLULjPAiNd4LQmXRBRfiYY2HAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=QHaxx/R1WFZxiVVtoYoI0/12lxa9U/MeRPqxAsEXsEhhmecwXKJ969AitIUQD9Ar2I TNPKUj+jV/7taj2UL6jlnosmOv10SSmky8l6mgGxVQyOebaHqwrMmX4mTjLALqdIwGKB LXxxuBVSImh7hSNKN2avORWzsogzmPbDflsMw= Received: by 10.86.90.8 with SMTP id n8mr3398786fgb.59.1248081188593; Mon, 20 Jul 2009 02:13:08 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id 3sm3849914fge.13.2009.07.20.02.13.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 02:13:06 -0700 (PDT) From: "Roni Even" To: "'Koen Vos'" , References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> In-Reply-To: <20090718061359.13046nca2lhexuhj@mail.skype.net> Date: Mon, 20 Jul 2009 12:11:45 +0300 Message-ID: <4a643522.0305560a.42ac.fffffb15@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoHqaQ/sv0hQvWSSv+7taBMsQk9HgBcC0Gg Content-language: en-us Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:22:21 -0000 inline > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Saturday, July 18, 2009 4:14 PM > To: codec@ietf.org > Subject: Re: [codec] Revised Draft Charter > > The validation testing may need some thinking. For example, G.718 used > 7 independent listening labs (which usually cost between $10k and $20k > each to run one listening batch). It may be hard to find that kind of > money for testing a royalty-free codec. But agree that we will need > some mechanism to compare a candidate against (1) the requirements and > (2) other candidates. > > Testing the combinations of float and fixed-point versions can perhaps > be done with objective measurement tools like PESQ or PEAQ. I believe > this is how ITU also does it(?) The ITU does it for the floating point version after the fixed point was tested. One thing to take unto account that these methods are not that suitable for audio codecs like the ones discussed here. > > Complexity: > Average WMOPS complexity, measured over a test file? > > Memory consumption measures: > - RAM (static/state) > - RAM (scratch) > - ROM (tables) > - Program ROM is a bit trickier, not sure we need it..? > > best, > koen. > > > Quoting stephen botzko : > > > I agree that we should have a complexity requirement that is also > tested, > > and I am fine with including that as part of characterization. In > addition > > to computational load, we could also consider memory requirements > (volatile > > and non volatile?) > > > > Another aspect is to ensure that the fixed and floating point > versions have > > the same characteristics ( that all combinations - fixed->fixed, > > fixed->float, float->fixed, float->float - sound identical). > > > > Regards > > Stephen Botzko > > Polycom > > > > On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood > wrote: > > > >> Hi Stephen, > >> > >> stephen botzko wrote: > >> > >>> Basically, its statistically valid testing of the codec in order to > prove > >>> that it meets its requirements.. > >>> > >>> In the ITU-T process, a test plan is developed, generally testing > the > >>> codec against a reference codec under stated conditions. This is > >>> worked out > >>> before selection process. It might include an audio quality > requirement > >>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 > kibts with > >>> reverberant speech" > >>> > >>> A statistically valid listening test is then done by couple of > different > >>> test labs, using reverberant speech samples in different languages, > wiht a > >>> specified confidence interval. The results are then reported back > for each > >>> candidate codec. > >>> > >>> 3GPP uses a similar process > >>> > >>> I'm not saying that we would need to follow the ITU-T or 3GPP > >>> characterization methods, though we should look at them. But that > we will > >>> need to develop more refined requirements, and work out a > statisitically > >>> valid way to prove the standard meets each requirement. > >>> > >> > >> Actually, that's just one side of what they consider to be codec > >> characterisation. The other is the computational complexity. Nobody > wants a > >> fantastic sounding codec that takes 100 64x cores to implement. :-) > The ITU > >> reference code, at least for fixed point, is written so that its > fairly > >> straightforward to sum up all the saturated multiplies, saturated > adds, > >> shifts, etc. > >> > >> Steve > >> > >> > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Mon Jul 20 02:57:32 2009 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 1D92E3A68EB for ; Mon, 20 Jul 2009 02:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 1zRea3mpq1ik for ; Mon, 20 Jul 2009 02:57:25 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 59E213A63EB for ; Mon, 20 Jul 2009 02:57:24 -0700 (PDT) Received: by fxm18 with SMTP id 18so1854046fxm.37 for ; Mon, 20 Jul 2009 02:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pls5DRmFOxQjtjLAt+/VSGw+6qbnWpojwhrK9vTpipI=; b=jpJLuAYnCBBpiaimrT40NDW1zkw8wbSKjRtGsykg9luvCNeQ0n/5VlydJCKaDsG5SV FMcuxiCxqKJiTNLJf9u/vEBHzpHywJ6/B3OmnLKedJeuLLX0IGWemqazh5wvaYBI8lca nr7xFXUcQIBkHyIfcoazXabJ8sq5SuEz2RRD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TfVXyi2rg1004LioUeoaEDkCjR+xkT0ltdFp8CpaERxwplZSfBobgjmiH+xWgdQ+6/ N+nI19N/+De6C3mRLjyDzWwpz52FQzZ+btYoAPRbWPB8N7/Wu+yv3ARXYURNWFsYZIRy 8Jp2uLCAA5cIBoKHjYqWAAUwNnMf09u4bkoZI= MIME-Version: 1.0 Received: by 10.223.105.75 with SMTP id s11mr1179672fao.4.1248083717059; Mon, 20 Jul 2009 02:55:17 -0700 (PDT) In-Reply-To: <4a643522.0305560a.42ac.fffffb15@mx.google.com> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4a643522.0305560a.42ac.fffffb15@mx.google.com> Date: Mon, 20 Jul 2009 05:55:17 -0400 Message-ID: <6e9223710907200255y6a4e8463y2902fc04353995b6@mail.gmail.com> From: stephen botzko To: Roni Even Content-Type: multipart/alternative; boundary=0016e6d27ed19af50d046f20224d Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:57:32 -0000 --0016e6d27ed19af50d046f20224d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> One thing to take unto account that these methods are not that suitable for audio codecs like the ones discussed here. >>> I think the basic techniques in the objective test method would be suitable for any codec, though perhaps I am missing something? Regards, Stephen Botzko Polycom On Mon, Jul 20, 2009 at 5:11 AM, Roni Even wrote: > inline > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Koen Vos > > Sent: Saturday, July 18, 2009 4:14 PM > > To: codec@ietf.org > > Subject: Re: [codec] Revised Draft Charter > > > > The validation testing may need some thinking. For example, G.718 used > > 7 independent listening labs (which usually cost between $10k and $20k > > each to run one listening batch). It may be hard to find that kind of > > money for testing a royalty-free codec. But agree that we will need > > some mechanism to compare a candidate against (1) the requirements and > > (2) other candidates. > > > > Testing the combinations of float and fixed-point versions can perhaps > > be done with objective measurement tools like PESQ or PEAQ. I believe > > this is how ITU also does it(?) > > The ITU does it for the floating point version after the fixed point was > tested. One thing to take unto account that these methods are not that > suitable for audio codecs like the ones discussed here. > > > > > Complexity: > > Average WMOPS complexity, measured over a test file? > > > > Memory consumption measures: > > - RAM (static/state) > > - RAM (scratch) > > - ROM (tables) > > - Program ROM is a bit trickier, not sure we need it..? > > > > best, > > koen. > > > > > > Quoting stephen botzko : > > > > > I agree that we should have a complexity requirement that is also > > tested, > > > and I am fine with including that as part of characterization. In > > addition > > > to computational load, we could also consider memory requirements > > (volatile > > > and non volatile?) > > > > > > Another aspect is to ensure that the fixed and floating point > > versions have > > > the same characteristics ( that all combinations - fixed->fixed, > > > fixed->float, float->fixed, float->float - sound identical). > > > > > > Regards > > > Stephen Botzko > > > Polycom > > > > > > On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood > > wrote: > > > > > >> Hi Stephen, > > >> > > >> stephen botzko wrote: > > >> > > >>> Basically, its statistically valid testing of the codec in order to > > prove > > >>> that it meets its requirements.. > > >>> > > >>> In the ITU-T process, a test plan is developed, generally testing > > the > > >>> codec against a reference codec under stated conditions. This is > > >>> worked out > > >>> before selection process. It might include an audio quality > > requirement > > >>> like "Codec x at 16 kbits will sound no worse than G.722 at 48 > > kibts with > > >>> reverberant speech" > > >>> > > >>> A statistically valid listening test is then done by couple of > > different > > >>> test labs, using reverberant speech samples in different languages, > > wiht a > > >>> specified confidence interval. The results are then reported back > > for each > > >>> candidate codec. > > >>> > > >>> 3GPP uses a similar process > > >>> > > >>> I'm not saying that we would need to follow the ITU-T or 3GPP > > >>> characterization methods, though we should look at them. But that > > we will > > >>> need to develop more refined requirements, and work out a > > statisitically > > >>> valid way to prove the standard meets each requirement. > > >>> > > >> > > >> Actually, that's just one side of what they consider to be codec > > >> characterisation. The other is the computational complexity. Nobody > > wants a > > >> fantastic sounding codec that takes 100 64x cores to implement. :-) > > The ITU > > >> reference code, at least for fixed point, is written so that its > > fairly > > >> straightforward to sum up all the saturated multiplies, saturated > > adds, > > >> shifts, etc. > > >> > > >> Steve > > >> > > >> > > > > > > > > > _______________________________________________ > > 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 > --0016e6d27ed19af50d046f20224d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
One thing to take unto account that these methods are not t= hat suitable for audio codecs like the ones discussed here.
>>>=

I think the basic techniques in the objective test method would be = suitable for any codec, though perhaps I am missing something?

Regards,
Stephen Botzko
Polycom

On Mon, Jul 20, 2009 at 5:11 AM, Roni Even <ron.even.tlv@gmail.com> wr= ote:
inline

> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On Behalf
> Of Koen Vos
> Sent: Saturday, July 18, 2009 4:14 PM
> To: codec@ietf.org
> Subject: Re: [codec] Revised Draft Charter
>
> The validation testing may need some thinking.= For example, G.718 used
> 7 independent listening labs (which usually cost between $10k and $20k=
> each to run one listening batch). =A0It may be hard to find that kind = of
> money for testing a royalty-free codec. =A0But agree that we will need=
> some mechanism to compare a candidate against (1) the requirements and=
> (2) other candidates.
>
> Testing the combinations of float and fixed-point versions can perhaps=
> be done with objective measurement tools like PESQ or PEAQ. I believe<= br> > this is how ITU also does it(?)

The ITU does it for the floating point version after the fixed point = was
tested. One thing to take unto account that these methods are not that
suitable for audio codecs like the ones discussed here.

>
> Complexity:
> Average WMOPS complexity, measured over a test file?
>
> Memory consumption measures:
> - RAM (static/state)
> - RAM (scratch)
> - ROM (tables)
> - Program ROM is a bit trickier, not sure we need it..?
>
> best,
> koen.
>
>
> Quoting stephen botzko <stephen.botzko@gmail.com>:
>
> > I agree that we should have a complexity requirement that is also=
> tested,
> > and I am fine with including that as part of characterization. = =A0In
> addition
> > to computational load, we could also consider memory requirements=
> (volatile
> > and non volatile?)
> >
> > Another aspect is to ensure that the fixed and floating point
> versions have
> > the same characteristics =A0( that all combinations - fixed->f= ixed,
> > fixed->float, float->fixed, float->float - sound identic= al).
> >
> > Regards
> > Stephen Botzko
> > Polycom
> >
> > On Sat, Jul 18, 2009 at 1:14 AM, Steve Underwood <steveu@coppice.org>
> wrote:
> >
> >> Hi Stephen,
> >>
> >> stephen botzko wrote:
> >>
> >>> Basically, its statistically valid testing of the codec i= n order to
> prove
> >>> that it meets its requirements..
> >>>
> >>> In the ITU-T process, a test plan is developed, generally= testing
> the
> >>> codec against a reference codec under stated conditions. = =A0This is
> >>> worked out
> >>> before selection process. =A0It might include an audio qu= ality
> requirement
> >>> like "Codec x at 16 kbits will sound no worse than G= .722 at 48
> kibts with
> >>> reverberant speech"
> >>>
> >>> A statistically valid listening test is then done by coup= le of
> different
> >>> test labs, using reverberant speech samples in different = languages,
> wiht a
> >>> specified confidence interval. =A0The results are then re= ported back
> for each
> >>> candidate codec.
> >>>
> >>> 3GPP uses a similar process
> >>>
> >>> I'm not saying that we would need to follow the ITU-T= or 3GPP
> >>> characterization methods, though we should look at them. = =A0But that
> we will
> >>> need to develop more refined requirements, and work out a=
> statisitically
> >>> valid way to prove the standard meets each requirement. > >>>
> >>
> >> Actually, that's just one side of what they consider to b= e codec
> >> characterisation. The other is the computational complexity. = Nobody
> wants a
> >> fantastic sounding codec that takes 100 64x cores to implemen= t. :-)
> The ITU
> >> reference code, at least for fixed point, is written so that = its
> fairly
> >> straightforward to sum up all the saturated multiplies, satur= ated
> adds,
> >> shifts, etc.
> >>
> >> Steve
> >>
> >>
> >
>
>
> _______________________________________________
> 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

--0016e6d27ed19af50d046f20224d-- From jean-marc.valin@octasic.com Mon Jul 20 06:56:20 2009 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 AB39D3A6C36 for ; Mon, 20 Jul 2009 06:56:20 -0700 (PDT) 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 yR2YEFhH0Vk2 for ; Mon, 20 Jul 2009 06:56:19 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 4B45F3A6BA1 for ; Mon, 20 Jul 2009 06:56:19 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:56:18 -0400 Message-ID: <4A647781.8030107@octasic.com> Date: Mon, 20 Jul 2009 09:56:17 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Roni Even References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <20090718075554.167032uicopmr33u@mail.skype.net> <4a643193.1ade660a.14bc.ffffda65@mx.google.com> In-Reply-To: <4a643193.1ade660a.14bc.ffffda65@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 13:56:18.0230 (UTC) FILETIME=[DAD38560:01CA0941] Cc: codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:56:20 -0000 Roni Even wrote: > Hi, > I am not sure I understand what you mean when you say rough consensus here. > Does it mean that after the codec is specified and in WGLC the complexity > will be agreed by rough consensus. I would think that people need of know > ahead of time what is the requirement and how to measure it. (contributor hat on) What I meant was rough consensus *before* approving/freezing the codec. If there is rough consensus that the codec has sufficiently low complexity to be implemented on most devices where it would be expected to be implementable, then it can be approved. On the other hand, there *are* complexity concerns, then they would need to be solved. We can decide to also characterize the complexity afterwards, but I believe that's less useful than making sure it's acceptable in the first place. See my other email for concerns I have over the use of WMOPS specifically. Cheers, Jean-Marc > Roni Even > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Koen Vos >> Sent: Saturday, July 18, 2009 5:56 PM >> To: Jean-Marc Valin >> Cc: codec@ietf.org >> Subject: Re: [codec] Revised Draft Charter >> >> Quoting Jean-Marc Valin: >> >>> I'm not sure what to use instead for complexity, but I'm also >> wondering >>> if we want a fixed complexity requirement up-front. For example, why >> not >>> use "rough consensus" as a means to determine whether a codec's >>> complexity is acceptable for most people. >> Agree with your points on WMOPS, let's forget about that one. >> >> Rough consensus based on MHz on an x86 core is simple to measure and >> gives already a pretty meaningful indication. >> >> >>> Regarding size, I would think it may also be a good idea to seek >> rough >>> consensus. >> Works for me. >> >> koen. >> _______________________________________________ >> 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 stewe@stewe.org Mon Jul 20 07:28:24 2009 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 715D028C166 for ; Mon, 20 Jul 2009 07:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 fKNyoCPI-2tJ for ; Mon, 20 Jul 2009 07:28:23 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5B94C28C142 for ; Mon, 20 Jul 2009 07:28:23 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 349337-1743317 for multiple; Mon, 20 Jul 2009 16:28:21 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 20 Jul 2009 07:28:13 -0700 From: Stephan Wenger To: Jason Fischl , Message-ID: Thread-Topic: [codec] Revised Draft Charter Thread-Index: AcoJRlAea1z+nks3YEuMy2iLGAdAQw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 14:28:24 -0000 One small thing inline: On 7/17/09 11:42 AM, "Jason Fischl" wrote: > DRAFT CHARTER: > > The goal of this working group is to standardize audio codecs that can > be implemented and used broadly, and be interoperable between a wide > set of interested parties. The group is chartered to work on audio > codecs for interactive communication over the Internet. Codecs > optimized for very low bit rates or for non-interactive audio are out > of scope. The codecs should address the following considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > IPR issues will be handled in accordance with BCP 79. You may wish to add "BCP 78" as well. IPR is commonly understood as "Intellectual Property Rights", and those include not only patents, but also copyright (and other stuff, like trademarks). BCP 79 handles the IETF patent (disclosure) policy; BCP 78 is related to the copyright stuff. Alternatively, you could replace "IPR issues" with "Patent issues". Although some would argue that the sentence in question is redundant (as any IETF activity runs under BCP 78 and BCP 79), I'm in favor of keeping the sentence in the charter, simply to remind everyone of the policy that applies. Regards, Stephan > > Proposed Deliverables: > 1) Detailed requirements for Internet audio codecs. > 2) Algorithm description for wideband Internet audio codecs as PS. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Tue Jul 21 14:37:31 2009 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 61C1E28C3A3 for ; Tue, 21 Jul 2009 14:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Vva0YjvIplCl for ; Tue, 21 Jul 2009 14:37:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 00CF728C3A1 for ; Tue, 21 Jul 2009 14:37:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKDRZUqrR7PE/2dsb2JhbAC6O4gjkBsFhAw X-IronPort-AV: E=Sophos;i="4.43,242,1246838400"; d="scan'208";a="351203244" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2009 21:37:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6LLbUVk018990; Tue, 21 Jul 2009 14:37:30 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6LLbTP7020937; Tue, 21 Jul 2009 21:37:29 GMT Message-Id: From: Cullen Jennings To: codec@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 15:37:28 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=989; t=1248212250; x=1249076250; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Codec=20Tuotorial |Sender:=20; bh=0MuNaIon7RbGMtl9lLEmogTTeXnEUQOwdcEhEH0u/GM=; b=gkC8qNkWXL23xO0b41IPKb6HZvd0fH4q/OZqYjfp5rDNeijGgSeHSVDHVK ZlSSlWhSSUKULoCsd8Nq8LE4VXtMcbR+WHntgZOnTbUdk1h/joXifN26lLZT wKMnyWCwFN; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Gregory Lebovitz , Jean-Marc Valin Subject: [codec] Codec Tuotorial X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 21:37:31 -0000 I received a request to run a tutorial on codecs. I have decided to not approve this but before you get out your torches and pitch forks, let me explain why. I think approving this would be getting too far ahead of ourselves. Typically the IETF avoids using meeting time for tutorials other than the EDU events. There have been exceptions to this in the past such as the ICE tutorials which helped educate people on the nuances of ICE which in turn helped the WG reach consensus on technical topics. A codec tutorial might help if we were doing detailed codec work if a WG was formed, but right now we are still in the process of deciding if a WG should be formed. I don't think a codec tutorial is going to contribute very much to that. For folks that do want to learn more about codecs, or argue the finer points of codec design, I'm sure there will be plenty of opportunity to talk to codec experts over many fine beers. Cullen From gherlein@herlein.com Tue Jul 21 16:02:44 2009 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 058AE3A6892 for ; Tue, 21 Jul 2009 16:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.684 X-Spam-Level: X-Spam-Status: No, score=0.684 tagged_above=-999 required=5 tests=[AWL=2.660, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 L9L5KoFa8oBA for ; Tue, 21 Jul 2009 16:02:43 -0700 (PDT) Received: from mail-pz0-f196.google.com (mail-pz0-f196.google.com [209.85.222.196]) by core3.amsl.com (Postfix) with ESMTP id 1E4F03A688F for ; Tue, 21 Jul 2009 16:02:43 -0700 (PDT) Received: by pzk34 with SMTP id 34so2135026pzk.29 for ; Tue, 21 Jul 2009 16:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.142.16 with SMTP id p16mr35966wfd.281.1248217361510; Tue, 21 Jul 2009 16:02:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2009 16:02:41 -0700 Message-ID: <31d1be720907211602l689e96f2v4f9db5dc8771c3a8@mail.gmail.com> From: Greg Herlein To: Cullen Jennings Content-Type: multipart/alternative; boundary=000e0cd147dc6f732b046f3f4061 Cc: Gregory Lebovitz , codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Codec Tuotorial X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 23:02:44 -0000 --000e0cd147dc6f732b046f3f4061 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This seems like a practical choice to me. Ah, if only I could attend and share some of that beer! On Tue, Jul 21, 2009 at 2:37 PM, Cullen Jennings wrote: > > I received a request to run a tutorial on codecs. I have decided to not > approve this but before you get out your torches and pitch forks, let me > explain why. > > I think approving this would be getting too far ahead of ourselves. > Typically the IETF avoids using meeting time for tutorials other than the > EDU events. There have been exceptions to this in the past such as the ICE > tutorials which helped educate people on the nuances of ICE which in turn > helped the WG reach consensus on technical topics. A codec tutorial might > help if we were doing detailed codec work if a WG was formed, but right now > we are still in the process of deciding if a WG should be formed. I don't > think a codec tutorial is going to contribute very much to that. > > For folks that do want to learn more about codecs, or argue the finer > points of codec design, I'm sure there will be plenty of opportunity to talk > to codec experts over many fine beers. > > Cullen > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > -- Greg Herlein www.herlein.com --000e0cd147dc6f732b046f3f4061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems like a practical choice to me.=A0 Ah, if only I could attend and= share some of that beer!

On Tue, Jul 21,= 2009 at 2:37 PM, Cullen Jennings <fluffy@cisco.com> wrote:

I received a request to run a tutorial on codecs. I have decided to not app= rove this but before you get out your torches and pitch forks, let me expla= in why.

I think approving this would be getting too far ahead of ourselves. Typical= ly the IETF avoids using meeting time for tutorials other than the EDU even= ts. There have been exceptions to this in the past such as the ICE tutorial= s which helped educate people on the nuances of ICE which in turn helped th= e WG reach consensus on technical topics. =A0A codec tutorial might help if= we were doing detailed codec work if a WG was formed, but right now we are= still in the process of deciding if a WG should be formed. I don't thi= nk a codec tutorial is going to contribute very much to that.

For folks that do want to learn more about codecs, or argue the finer point= s of codec design, I'm sure there will be plenty of opportunity to talk= to codec experts over many fine beers.

Cullen <RAI AD>

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



--
Greg Herlein
www.herlein.com
--000e0cd147dc6f732b046f3f4061-- From steveu@coppice.org Tue Jul 21 18:02:55 2009 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 08AB13A6ECE for ; Tue, 21 Jul 2009 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 CjpdAGkKpvvX for ; Tue, 21 Jul 2009 18:02:54 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 087683A6ECB for ; Tue, 21 Jul 2009 18:02:53 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6M12jf9010313; Wed, 22 Jul 2009 09:02:45 +0800 Message-ID: <4A666535.3080902@coppice.org> Date: Wed, 22 Jul 2009 09:02:45 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec Tuotorial X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 01:02:55 -0000 Cullen Jennings wrote: > > I received a request to run a tutorial on codecs. I have decided to > not approve this but before you get out your torches and pitch forks, > let me explain why. > > I think approving this would be getting too far ahead of ourselves. > Typically the IETF avoids using meeting time for tutorials other than > the EDU events. There have been exceptions to this in the past such as > the ICE tutorials which helped educate people on the nuances of ICE > which in turn helped the WG reach consensus on technical topics. A > codec tutorial might help if we were doing detailed codec work if a WG > was formed, but right now we are still in the process of deciding if a > WG should be formed. I don't think a codec tutorial is going to > contribute very much to that. > > For folks that do want to learn more about codecs, or argue the finer > points of codec design, I'm sure there will be plenty of opportunity > to talk to codec experts over many fine beers. "codec tutorial" seems a little vague. What is the intended subject matter? How they work? What their goals are? What their limitations are? Steve From herve.taddei@huawei.com Wed Jul 22 05:42:45 2009 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 B7F243A699A for ; Wed, 22 Jul 2009 05:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 M-dIz+yssclB for ; Wed, 22 Jul 2009 05:42:43 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 767CA3A6B04 for ; Wed, 22 Jul 2009 05:42:43 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN600LEHOKMAU@lhrga02-in.huawei.com> for codec@ietf.org; Wed, 22 Jul 2009 13:41:10 +0100 (BST) Received: from PCHERVE ([10.200.70.198]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN600MJ7OKKMT@lhrga02-in.huawei.com> for codec@ietf.org; Wed, 22 Jul 2009 13:41:10 +0100 (BST) Date: Wed, 22 Jul 2009 14:41:08 +0200 From: Herve Taddei In-reply-to: <4A628E0E.6090100@coppice.org> To: 'Steve Underwood' , 'Jean-Marc Valin' Message-id: <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_jbh84LN+4KZNI5hHKVyVag)" Thread-index: AcoIHiSg2nzBk7MnTFGEKgaEyUGiPgCp25MA References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 12:42:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jbh84LN+4KZNI5hHKVyVag) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Jean Marc and Steve, Let me correct some statements made on the WMOPS counting as it seems to me they are either wrong or you are not looking to the tool we are used to have. So I am not sure your comments are based on G.191, if that is the case, I have asked someone heavily involved in the design of ITU-T G.191 to answer some of your points. > > * it forces you to code the fixed-point in a certain way (e.g. > > fractional vs interger multiply); In general, in order to "automate" the evaluation of the complexity of an algorithm on a family of processor architectures, the fixed point code needs to be written in certain ways. If evaluating the complexity of a codec is an important factor in the standardisation process, then such coding guidelines should be agreed by the various parties involved in the standardisation. W/ regards to fractional vs interger multiply : ITU STL 2000 supports few integer multiplication (L mult0, L_mac0, L_msu0). It is true that the variety & numbers of fractional multiplication operators vs integer multiplication operators is not equal. From historical point of view, the "fractional" multiplication was priviledged. In 2003 (in preparation of STL2005), there was a proposal to widen the set of integer multiplication while taking care of well counting the integer/fractional multiplication mode switch that may be needed on some processors. This discussion was not carried on forward. > > * it's designed for a 16-bit (TI) DSP and is not very respresentative of > > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; 1st of all, I don't believe that the STL2005 is designed for a TI DSP. For example, during the STL2005 design process STM inputs were factored in, among others on the reflector. Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 (same as L_mac). Now, in a more general statement, is the STL a basic operator library representing more a 16b or 32b processor ? If I look at the STl2005 list of operators which have a complexity > 1, I believe we fall in those categories : - add / subtract with carry bit. - shift and round. - integer multiplication with truncation to 16 lsbs (reflects indeed that STL is historically fractional based). - bit rotation operation - high precision 32x16 and 32x32 multiplication (requires 40b STL headers). I believe that with the renewed complexity weights made in 2005, the STL is closer to a 32b processor than a 16b processor to the exception of the 32x32b multiplication which is not having a complexity of 1 ... but of 4 (Mpy 32 32 ss inside the 40b lib). > > * it completely ignore issues such as conditional branches, which can be > > more important than arithmetic operations on modern architectures; This is incorrect, with STL2005, control operation complexity count is supported. Any improvement suggestions welcomed to be discussed. > Also, the ITU approach only tries to get an instruction count for the fixed point implementations. > The floating point computational complexity is also very important these days. I think this is not correct as floating point implementation counters were proposed in ITU-T (from VoiceAge actually) and have been used in many standardization exercises for reporting floating point complexity. Best regards Herve --Boundary_(ID_jbh84LN+4KZNI5hHKVyVag) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Jean Marc and Steve,

 

Let me correct some statements made on the WMOPS counting as it seems to me they are either wrong or you are not looking to the tool we are used to have. So I am not sure your comments are based on G.191, if that is the case, I have asked someone heavily involved in the design of ITU-T G.191 to answer some of your points.

 

> > * it forces you to code the fixed-point in a certain way (e.g.

> > fractional vs interger multiply);

In general, in order to "automate" the evaluation of the complexity of an algorithm on a family of processor architectures, the fixed point code needs to be written in certain ways. If evaluating the complexity of a codec is an important factor in the standardisation process, then such coding guidelines should be agreed by the various parties involved in the standardisation.
W/ regards to fractional vs interger multiply : ITU STL 2000 supports few integer multiplication (L mult0, L_mac0, L_msu0). It is true that the variety & numbers of fractional multiplication operators vs integer multiplication operators is not equal. From historical point of view, the "fractional" multiplication was priviledged. In 2003 (in preparation of STL2005), there was a proposal to widen the set of integer multiplication while taking care of well counting the integer/fractional multiplication mode switch that may be needed on some processors. This discussion was not carried on forward.

 

> > * it's designed for a 16-bit (TI) DSP and is not very respresentative of

> > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC;

1st of all, I don't believe that the STL2005 is designed for a TI DSP. For example, during the STL2005 design process STM inputs were factored in, among others on the reflector.
Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 (same as L_mac).

Now, in a more general statement, is the STL a basic operator library representing more a 16b or 32b processor ? If I look at the STl2005 list of operators which have a complexity > 1, I believe we fall in those categories :
- add / subtract with carry bit.
- shift and round.
- integer multiplication with truncation to 16 lsbs (reflects indeed that STL is historically fractional based).
- bit rotation operation
- high precision 32x16 and 32x32 multiplication (requires 40b STL headers).

I believe that with the renewed complexity weights made in 2005, the STL is closer to a 32b processor than a 16b processor to the exception of the 32x32b multiplication which is not having a complexity of 1 ... but of 4 (Mpy 32 32 ss inside the 40b lib).

 

> > * it completely ignore issues such as conditional branches, which can be

> > more important than arithmetic operations on modern architectures;

This is incorrect, with STL2005, control operation complexity count is supported.
Any improvement suggestions welcomed to be discussed.

 

> Also, the ITU approach only tries to get an instruction count for the fixed point implementations.

> The floating point computational complexity is also very important these days.

I think this is not correct as floating point implementation counters were proposed in ITU-T (from VoiceAge actually) and have been used in many standardization exercises for reporting floating point complexity.

 

Best regards

 

Herve

--Boundary_(ID_jbh84LN+4KZNI5hHKVyVag)-- From jean-marc.valin@octasic.com Wed Jul 22 07:34:52 2009 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 56E213A6833 for ; Wed, 22 Jul 2009 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 f2bvU8vX1EcJ for ; Wed, 22 Jul 2009 07:34:50 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 1E0613A67EA for ; Wed, 22 Jul 2009 07:34:48 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:32:23 -0400 Message-ID: <4A6722F6.40903@octasic.com> Date: Wed, 22 Jul 2009 10:32:22 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Herve Taddei References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> In-Reply-To: <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 14:32:23.0184 (UTC) FILETIME=[3A10C900:01CA0AD9] Cc: codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:34:52 -0000 Hi Herve, (contributor hat on) My earlier comments were based on the version of the basic ops that I saw in many standards (and assuming there was just one WMOPS definition). I was not aware that these operators had been "recently" revised. Thanks for pointing those out. I agree that the revised version makes more sense and is closer to the a 32-bit DSP. I still see a few issues with STL2005 (e.g. lack of unsigned add/sub), but they are relatively minor compared to the older version. That being said, I still consider that there are fundamental limitations to the WMOPS *approach*, caused by differences in DSP/CPU architectures. For example, many (all?) ARM cores do not have saturating operators. When it comes to conditional branches, some architectures will pay a fixed price for a branch taken, while others (e.g. x86) will have virtually no cost for an easily predicted branch and a huge cost for a branch on "random" data. In the end, WMOPS will give you a rough idea of the complexity, but I believe it is preferable to use rough consensus (possibly backed by some benchmarks) to ultimately decide on what's acceptable. Cheers, Jean-Marc Herve Taddei wrote: > Dear Jean Marc and Steve, > > > > Let me correct some statements made on the WMOPS counting as it seems to > me they are either wrong or you are not looking to the tool we are used > to have. So I am not sure your comments are based on G.191, if that is > the case, I have asked someone heavily involved in the design of ITU-T > G.191 to answer some of your points. > > > >> > * it forces you to code the fixed-point in a certain way (e.g. > >> > fractional vs interger multiply); > > In general, in order to "automate" the evaluation of the complexity of > an algorithm on a family of processor architectures, the fixed point > code needs to be written in certain ways. If evaluating the complexity > of a codec is an important factor in the standardisation process, then > such coding guidelines should be agreed by the various parties involved > in the standardisation. > W/ regards to fractional vs interger multiply : ITU STL 2000 supports > few integer multiplication (L mult0, L_mac0, L_msu0). It is true that > the variety & numbers of fractional multiplication operators vs integer > multiplication operators is not equal. From historical point of view, > the "fractional" multiplication was priviledged. In 2003 (in preparation > of STL2005), there was a proposal to widen the set of integer > multiplication while taking care of well counting the > integer/fractional multiplication mode switch that may be needed on some > processors. This discussion was not carried on forward. > > > >> > * it's designed for a 16-bit (TI) DSP and is not very respresentative of > >> > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; > > 1st of all, I don't believe that the STL2005 is designed for a TI DSP. > For example, during the STL2005 design process STM inputs were factored > in, among others on the reflector. > Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 > (same as L_mac). > > Now, in a more general statement, is the STL a basic operator library > representing more a 16b or 32b processor ? If I look at the STl2005 list > of operators which have a complexity > 1, I believe we fall in those > categories : > - add / subtract with carry bit. > - shift and round. > - integer multiplication with truncation to 16 lsbs (reflects indeed > that STL is historically fractional based). > - bit rotation operation > - high precision 32x16 and 32x32 multiplication (requires 40b STL headers). > > I believe that with the renewed complexity weights made in 2005, the STL > is closer to a 32b processor than a 16b processor to the exception of > the 32x32b multiplication which is not having a complexity of 1 ... but > of 4 (Mpy 32 32 ss inside the 40b lib). > > > >> > * it completely ignore issues such as conditional branches, which can be > >> > more important than arithmetic operations on modern architectures; > > This is incorrect, with STL2005, control operation complexity count is > supported. > Any improvement suggestions welcomed to be discussed. > > > >> Also, the ITU approach only tries to get an instruction count for the > fixed point implementations. > >> The floating point computational complexity is also very important > these days. > > I think this is not correct as floating point implementation counters > were proposed in ITU-T (from VoiceAge actually) and have been used in > many standardization exercises for reporting floating point complexity. > > > > Best regards > > > > Herve > > > ------------------------------------------------------------------------ > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Wed Jul 22 07:37:10 2009 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 F22F83A6833 for ; Wed, 22 Jul 2009 07:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 FAQpd7lbN2+0 for ; Wed, 22 Jul 2009 07:37:10 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 3086628C104 for ; Wed, 22 Jul 2009 07:37:10 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:35:06 -0400 Message-ID: <4A67239A.5040706@octasic.com> Date: Wed, 22 Jul 2009 10:35:06 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Steve Underwood References: <4A666535.3080902@coppice.org> In-Reply-To: <4A666535.3080902@coppice.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 14:35:06.0747 (UTC) FILETIME=[9B8E84B0:01CA0AD9] Cc: codec@ietf.org Subject: Re: [codec] Codec Tuotorial X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:37:11 -0000 Steve Underwood wrote: > "codec tutorial" seems a little vague. What is the intended subject > matter? How they work? What their goals are? What their limitations are? The original idea was a sort of "crash course in audio coding", but I guess we can just make this an informal codec discussion over beer! Cheers, Jean-Marc From stephen.botzko@gmail.com Wed Jul 22 07:55:12 2009 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 2097D3A6403 for ; Wed, 22 Jul 2009 07:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 BFZ9ccPmhhop for ; Wed, 22 Jul 2009 07:55:10 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2AEFD3A68AE for ; Wed, 22 Jul 2009 07:55:09 -0700 (PDT) Received: by fxm18 with SMTP id 18so239114fxm.37 for ; Wed, 22 Jul 2009 07:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qlxWZcBbGWuPlwfbtSwrTEotVynR9DjHUbzN/AMzEVc=; b=Jz3TbTZDCCDF8SEW5vr6jECF6EHU8+/iqjXkfOLb4OY3Yl0f7R7v+I9WX7GVV89SoS W9dPckmJI1ePbYk01ahInI5/tQ9CTjo8S8liPjn6Rlnee4k7ruBmHG3ysmEm66N5TvEC TwcCgnBJH8O1VSnhDCdYvawGdfb7Ct+BPYsvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hAb1QmQeX5+XrxjoOgXlD1CFsrVJLyWqKoAbXCsO1zW4gRNaCanCY/BCyjR2dkw6N4 TN4N8UB8/EwD1ZNBo7ypfHP9JrJMghjJj4YBkzkZ6bW5zH8tfyuytOJljLtn+jca4udQ J2FW70YVk99HulWDVlaLe9mZiWIta7ypykAxM= MIME-Version: 1.0 Received: by 10.223.109.198 with SMTP id k6mr539177fap.46.1248274424882; Wed, 22 Jul 2009 07:53:44 -0700 (PDT) In-Reply-To: <4A6722F6.40903@octasic.com> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> <4A6722F6.40903@octasic.com> Date: Wed, 22 Jul 2009 10:53:44 -0400 Message-ID: <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> From: stephen botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001636c5b496ad6559046f4c89ea Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:55:12 -0000 --001636c5b496ad6559046f4c89ea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The benefit of measured complexity is that it provides a precise definition of the requirement that can be tested. Even if it does not exactly map onto a given processor, this can still be useful. For instance, if you have two codec candidates, using a "rough consensus" will make it very hard to reject one of them on the grounds that it doesn't meet the complexity requirement. My guess is that the result will either be that complexity gradually creeps upwards, or that "rough consensus" will not be achieved, totally blocking progress. More generally, if you use a process where multiple codec candidates are considered, "rough consensus" is not efficient - it is likely to be unachievable if a significant fraction of the WG participants have candidates in play. This would be likely true even if the "signficant fraction" is < 50%. Regards, Stephen Botzko Polycom On Wed, Jul 22, 2009 at 10:32 AM, Jean-Marc Valin < jean-marc.valin@octasic.com> wrote: > Hi Herve, > > (contributor hat on) > > My earlier comments were based on the version of the basic ops that I saw > in many standards (and assuming there was just one WMOPS definition). I was > not aware that these operators had been "recently" revised. Thanks for > pointing those out. I agree that the revised version makes more sense and is > closer to the a 32-bit DSP. I still see a few issues with STL2005 (e.g. lack > of unsigned add/sub), but they are relatively minor compared to the older > version. > > That being said, I still consider that there are fundamental limitations to > the WMOPS *approach*, caused by differences in DSP/CPU architectures. For > example, many (all?) ARM cores do not have saturating operators. When it > comes to conditional branches, some architectures will pay a fixed price for > a branch taken, while others (e.g. x86) will have virtually no cost for an > easily predicted branch and a huge cost for a branch on "random" data. In > the end, WMOPS will give you a rough idea of the complexity, but I believe > it is preferable to use rough consensus (possibly backed by some benchmarks) > to ultimately decide on what's acceptable. > > Cheers, > > Jean-Marc > > Herve Taddei wrote: > >> Dear Jean Marc and Steve, >> >> >> Let me correct some statements made on the WMOPS counting as it seems to >> me they are either wrong or you are not looking to the tool we are used to >> have. So I am not sure your comments are based on G.191, if that is the >> case, I have asked someone heavily involved in the design of ITU-T G.191 to >> answer some of your points. >> >> >> >>> > * it forces you to code the fixed-point in a certain way (e.g. >>> >> >> > fractional vs interger multiply); >>> >> >> In general, in order to "automate" the evaluation of the complexity of an >> algorithm on a family of processor architectures, the fixed point code needs >> to be written in certain ways. If evaluating the complexity of a codec is an >> important factor in the standardisation process, then such coding guidelines >> should be agreed by the various parties involved in the standardisation. >> W/ regards to fractional vs interger multiply : ITU STL 2000 supports few >> integer multiplication (L mult0, L_mac0, L_msu0). It is true that the >> variety & numbers of fractional multiplication operators vs integer >> multiplication operators is not equal. From historical point of view, the >> "fractional" multiplication was priviledged. In 2003 (in preparation of >> STL2005), there was a proposal to widen the set of integer multiplication >> while taking care of well counting the integer/fractional multiplication >> mode switch that may be needed on some processors. This discussion was not >> carried on forward. >> >> >> >>> > * it's designed for a 16-bit (TI) DSP and is not very respresentative >>> of >>> >> >> > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; >>> >> >> 1st of all, I don't believe that the STL2005 is designed for a TI DSP. For >> example, during the STL2005 design process STM inputs were factored in, >> among others on the reflector. >> Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 >> (same as L_mac). >> >> Now, in a more general statement, is the STL a basic operator library >> representing more a 16b or 32b processor ? If I look at the STl2005 list of >> operators which have a complexity > 1, I believe we fall in those categories >> : >> - add / subtract with carry bit. >> - shift and round. >> - integer multiplication with truncation to 16 lsbs (reflects indeed that >> STL is historically fractional based). >> - bit rotation operation >> - high precision 32x16 and 32x32 multiplication (requires 40b STL >> headers). >> >> I believe that with the renewed complexity weights made in 2005, the STL >> is closer to a 32b processor than a 16b processor to the exception of the >> 32x32b multiplication which is not having a complexity of 1 ... but of 4 >> (Mpy 32 32 ss inside the 40b lib). >> >> >> >>> > * it completely ignore issues such as conditional branches, which can >>> be >>> >> >> > more important than arithmetic operations on modern architectures; >>> >> >> This is incorrect, with STL2005, control operation complexity count is >> supported. >> Any improvement suggestions welcomed to be discussed. >> >> >> >>> Also, the ITU approach only tries to get an instruction count for the >>> >> fixed point implementations. >> >> The floating point computational complexity is also very important >>> >> these days. >> >> I think this is not correct as floating point implementation counters were >> proposed in ITU-T (from VoiceAge actually) and have been used in many >> standardization exercises for reporting floating point complexity. >> >> >> Best regards >> >> >> Herve >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > --001636c5b496ad6559046f4c89ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The benefit of measured complexity is that it provides a precise definition= of the requirement that can be tested.=A0 Even if it does not exactly map = onto a given processor, this can still be useful.

For instance, if y= ou have two codec candidates, using a "rough consensus" will make= it very hard to reject one of them on the grounds that it doesn't meet= the complexity requirement.=A0 My guess is that the result will either be = that complexity gradually creeps upwards, or that "rough consensus&quo= t; will not be achieved, totally blocking progress.=A0

More generally, if you use a process where multiple codec candidates ar= e considered, "rough consensus" is not efficient - it is likely t= o be unachievable if a significant fraction of the WG participants have can= didates in play.=A0 This would be likely true even if the "signficant = fraction" is < 50%.

Regards,
Stephen Botzko
Polycom


On Wed, Jul 22, 2009 at 10:32 AM, Jean-Marc Valin &l= t;jean-marc.valin@octasic.co= m> wrote:
Hi Herve,

(contributor hat on)

My earlier comments were based on the version of the basic ops that I saw i= n many standards (and assuming there was just one WMOPS definition). I was = not aware that these operators had been "recently" revised. Thank= s for pointing those out. I agree that the revised version makes more sense= and is closer to the a 32-bit DSP. I still see a few issues with STL2005 (= e.g. lack of unsigned add/sub), but they are relatively minor compared to t= he older version.

That being said, I still consider that there are fundamental limitations to= the WMOPS *approach*, caused by differences in DSP/CPU architectures. For = example, many (all?) ARM cores do not have saturating operators. When it co= mes to conditional branches, some architectures will pay a fixed price for = a branch taken, while others (e.g. x86) will have virtually no cost for an = easily predicted branch and a huge cost for a branch on "random" = data. In the end, WMOPS will give you a rough idea of the complexity, but I= believe it is preferable to use rough consensus (possibly backed by some b= enchmarks) to ultimately decide on what's acceptable.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

Herve Taddei wrote:
<= div class=3D"h5"> Dear Jean Marc and Steve,

=A0
Let me correct some statements made on the WMOPS counting as it seems to me= they are either wrong or you are not looking to the tool we are used to ha= ve. So I am not sure your comments are based on G.191, if that is the case,= I have asked someone heavily involved in the design of ITU-T G.191 to answ= er some of your points.

=A0
=A0> * it forces you to code the fixed-point in a certain way (e.g.

=A0> fractional vs interger multiply);

In general, in order to "automate" the evaluation of the complexi= ty of an algorithm on a family of processor architectures, the fixed point = code needs to be written in certain ways. If evaluating the complexity of a= codec is an important factor in the standardisation process, then such cod= ing guidelines should be agreed by the various parties involved in the stan= dardisation.
W/ regards to fractional vs interger multiply : ITU STL 2000 supports few i= nteger multiplication (L mult0, L_mac0, L_msu0). It is true that the variet= y & numbers of fractional multiplication operators vs integer multiplic= ation operators is not equal. From historical point of view, the "frac= tional" multiplication was priviledged. In 2003 (in preparation of STL= 2005), there was a proposal to widen the set of integer multiplication whil= e taking care of well counting the integer/fractional multiplication mode s= witch that may be needed on some processors. This discussion was not carrie= d on forward.

=A0
=A0> * it's designed for a 16-bit (TI) DSP and is not very respresen= tative of

=A0> modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC= ;

1st of all, I don't believe that the STL2005 is designed for a TI DSP. = For example, during the STL2005 design process STM inputs were factored in,= among others on the reflector.
Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 (sa= me as L_mac).

Now, in a more general statement, is the STL a basic operator library repre= senting more a 16b or 32b processor ? If I look at the STl2005 list of oper= ators which have a complexity > 1, I believe we fall in those categories= :
- add / subtract with carry bit.
- shift and round.
- integer multiplication with truncation to 16 lsbs (reflects indeed that S= TL is historically fractional based).
- bit rotation operation
- high precision 32x16 and 32x32 multiplication (requires 40b STL headers).=

I believe that with the renewed complexity weights made in 2005, the STL is= closer to a 32b processor than a 16b processor to the exception of the 32x= 32b multiplication which is not having a complexity of 1 ... but of 4 (Mpy = 32 32 ss inside the 40b lib).

=A0
=A0> * it completely ignore issues such as conditional branches, which c= an be

=A0> more important than arithmetic operations on modern architectures;<= br>

This is incorrect, with STL2005, control operation complexity count is supp= orted.
Any improvement suggestions welcomed to be discussed.

=A0
=A0Also, the ITU approach only tries to get an instruction count for the
fixed point implementations.

=A0The floating point computational complexity is also very important
these days.

I think this is not correct as floating point implementation counters were = proposed in ITU-T (from VoiceAge actually) and have been used in many stand= ardization exercises for reporting floating point complexity.

=A0
Best regards

=A0
Herve


------------------------------------------------------------------------

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

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

--001636c5b496ad6559046f4c89ea-- From fluffy@cisco.com Wed Jul 22 08:02:43 2009 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 BB5293A698C for ; Wed, 22 Jul 2009 08:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.243 X-Spam-Level: X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 D8CYSIZkgRRp for ; Wed, 22 Jul 2009 08:02:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7BCB63A68AE for ; Wed, 22 Jul 2009 08:02:42 -0700 (PDT) X-Files: DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm, DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf : 40883, 15797 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAEAE/GZkqrR7PD/2dsb2JhbACCKhIYtyGIIyYBkD4FgjoIgUyBRQ X-IronPort-AV: E=Sophos;i="4.43,247,1246838400"; d="pdf'?htm'217?scan'217,208,217";a="188568895" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2009 15:01:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6MF1ctw005099 for ; Wed, 22 Jul 2009 08:01:38 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6MF0bmh022976 for ; Wed, 22 Jul 2009 15:01:28 GMT Message-Id: <2F73DAAD-E503-4DC8-A329-4F40FDFD5723@cisco.com> From: Cullen Jennings To: codec@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: multipart/mixed; boundary=Apple-Mail-5--615251455 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 09:01:28 -0600 References: <334A4109C6BEA14ABB48EBCF274A6C8A04E339C7@MAILBOX1.blue.itu.ch> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=70490; t=1248274904; x=1249138904; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20COM=2016-LS=2071=20-=20Outgoing=20LS=2 0from=20ITU-T=20WP3=20meeting=20(10=20July=202009) |Sender:=20; bh=eHY+E4prFoLWVnk6ZvTloPp2/5T8qK1z7G4b4Pk68tE=; b=UKn+Ry6ca/705rjNXnKJDtU/SSHlXqQrZfML6ovkvXhIVR6MDPqp1cYLO6 u4O4JGrTJS4mh0QyiGFAMjQdYGFiQFDul5PDKYn92oStSsXrb/wvaV4qK9rB rI5/YL2PPV; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:02:43 -0000 --Apple-Mail-5--615251455 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: > Date: July 22, 2009 8:53:31 AM MDT (CA) > To: , > Cc: , > Subject: RE: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 =20 > July 2009) > > Dear Cullen, Russ > > I have been asked to forward you information we just received from =20 > ETSI DECT on the usage of ITU-T codecs in next generation ETSI DECT =20= > systems, in the hope it may assist in the discussions in the codec =20 > mailing list, as well as on the deliberations whether or not to =20 > create a WG under RAI for a wideband internet codec. > > I attach two derivative formats of the original document (the =20 > original was winword), PDF and HTML, I am not sure which format will =20= > render better. Will you, or should I, forward =20 > <> i =20 > <> t to the codec =20 > mailing list? > > Best regards, > Sim=E3o > > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm >> > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf >> > > _____________________________________________ > From: TSBSG16, ITU [mailto:tsbsg16@itu.int] > Sent: 14 July 2009 16:51 > To: housley@vigilsec.com; fluffy@cisco.com; statements@ietf.org > Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 = July =20 > 2009) > > > > Kindly find attached the Liaison Statement COM16 - LS 71 on =20 > "information on ITU-T Speech and audio coding standardisation" =20 > addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting =20 > (10 July 2009). > > Please take note that we are sending herewith the word version as =20 > well as the pdf version of the LS. In addition, there is an =20 > attachment, which is in excel. Since it is quite complex with =20 > different sheets, we preferred to keep the excel file in the =20 > original version. > > << ls071-16.doc >> > << ls071-16.pdf >> > << ls071_Att.1_Copy of MCSD-Database-V20081003.xls >> > > > Best regards, > Rosa Angeles-Le=F3n de Vivero > Assistant for ITU-T Study Group 16 > ITU - Telecommunication Standardization Bureau (TSB) > SG 16 e-mail: tsbsg16@itu.int > Tel. 41-22 730 5445 > Fax 41-22 730 5853 > > --Apple-Mail-5--615251455 Content-Disposition: attachment; filename=DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm Content-Type: text/html; x-unix-mode=0666; name="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm" Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D =0D =0D =0D =0D ETSI DECT#38 / DECT38_017 - LS to ITU-T SG 16=0D =0D =0D =0D =0D =0D =0D =0D
=0D =0D

ETSI DECT#38=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 DECT38_017

=0D =0D

 =

=0D =0D

Liaison=0D Statement

=0D =0D =0D = =0D =0D =0D =0D
=0D

Title:

=0D 		=0D

Liaison statement regarding the use of = wideband=0D codecs with DECT new generation

=0D
=0D =0D

 

=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D

From:

=0D 		=0D

 

=0D
=0D

Organisation:

=0D 		=0D

ETSI=0D TC DECT

=0D
=0D

Contact:

=0D 		=0D

Dr. G=FCnter Kleindl

=0D
=0D

e-mail:

=0D 		=0D

guenter.kleindl@siemens.com

=0D
=0D

Technical = Officer:

=0D 		=0D

Andrea lorelli

=0D
=0D

e-mail:

=0D 		=0D

Andrea.lorelli@etsi.org

=0D
=0D =0D

 

=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D

To= :

=0D 		=0D

 

=0D
=0D

Organisation:

=0D 		=0D

ITU-T=0D SG16 Q8, 9, 10/16

=0D
=0D

= Contact:

=0D 		=0D

Claude=0D Lamblin

=0D
=0D

e-mail:

=0D 		=0D

claude.lamblin@orange-ft= group.com

=0D
=0D

Technical = Officer:

=0D 		=0D

 

=0D
=0D

e-mail:

=0D 		=0D

 

=0D
=0D =0D

 

=0D =0D

 

=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D

For:

=0D

 

=0D

Action:

=0D 		=0D

 

=0D
=0D

Information:

=0D 		=0D

X

=0D
=0D =0D

 

=0D =0D

 

=0D =0D

ETSI TC DECT would like to thank ITU-T = SG16 for=0D informing about the possible set up of a new IETF working group that = would be=0D chartered with the purpose of collecting expertise within the IETF in = order to=0D review the design of wideband audio codecs specifically for use with the=0D= Internet.

=0D =0D

 

=0D =0D

In response to this liaison ETCI TC DECT would like to give the=0D= following feedback about the use of wideband codecs within its standards = and=0D the corresponding devices.

=0D =0D

 

=0D =0D

New Generation DECT (NG-DECT) standards (ETSI TS 102 527-1 and = -3) are=0D intended for wideband audio enabled devices to be connected on VoIP = networks.=0D These standards are an evolution of the DECT well-known standard EN 300 = 175 in=0D order to support wideband speech communications.

=0D= =0D

 

=0D =0D

These standards allow the support of 2 wideband codecs = (additionally to=0D some possible other codecs with different audio bandwidths): =

=0D =0D

 

=0D =0D

-         =0D mandatory=0D support: ITU-T G.722 at 64 kbit/s codec

=0D =0D

-         =0D optional=0D support: ITU-T G.729.1 codec

=0D =0D

 

=0D =0D

G.722 = codec was=0D chosen mainly for the following reasons:

=0D =0D

 

=0D =0D

-         =0D Low= =0D complexity

=0D =0D

-         =0D Good=0D quality for speech communications

=0D =0D

-         =0D Standardized=0D encoder and decoder with test vectors (implementations easy to verify) = ensuring=0D interoperability and quality thanks to bit exact implementation =

=0D =0D

-         =0D Packet=0D loss concealment mechanisms available

=0D =0D

-         =0D Low= delay=0D and sample based codec allowing any packetisation on=0D VoIP/ internet networks

=0D =0D

 

=0D =0D

These choices are consistent with the ETSI recommendations TS = 181005=0D from TISPAN (Telecommunications and Internet converged Services and = Protocols=0D for Advanced Networking; Service and Capability Requirements) for Next=0D= Generation Networks and devices where following wideband codecs are=0D recommended: G.722, G.722.2, G.729.1 and EVRC-WB.

=0D= =0D

 

=0D =0D

Additionally, ETSI TC DECT would like to point out that millions = of=0D devices implementing ITU-T G.722 codec were manufactured,=0D sold in several countries and are available worldwide now. In particular = a=0D certification program handled by DECT Forum exists for cordless devices: = namely=0D DECT Forum=92s CAT-iq 1.0 (and CAT-iq=0D 2.0 to come). This emphasizes strongly the need for backwards = compatibility and=0D keeping a high level of voice quality and avoiding transcoding with its=0D= inherent decrease in voice quality.

=0D =0D

 

=0D =0D

As a = conclusion,=0D ETSI TC DECT would like to highlight that:

=0D =0D

 

=0D =0D

-         =0D The= =0D motivation and benefits related to the codecs selected by TC DECT (and=0D= especially G.722) for usage over IP and internet through DECT interface = should=0D probably also be valid for any other wideband communication needs over = IP=0D networks and the internet and should be explicitly considered by IETF = and other=0D SDOs.

=0D =0D

-         =0D Using the=0D same codecs increases the chances of interoperability, allows to = interconnect=0D networks or devices without cost adders and avoids transcoding and its = inherent=0D quality degradation..

=0D= =0D

_______________

=0D= =0D

 

=0D =0D
=0D =0D =0D =0D =0D --Apple-Mail-5--615251455 Content-Disposition: inline; filename=DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf Content-Type: application/pdf; x-unix-mode=0666; name="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nOVcWY8ctxF+318xQB4yE3hazZtUXiw7sqBE8aW1E0AOgr202lja1bGynPz2 PKTYvIpkdc/sehU4iAzBLTbPOr+qYs+b1Tgwvhr9f+nh5NXBuHoEf88P3hzYQfg/0wv8fPJq9dnh wb1vzYqpwenV4fODcXDOSSan92ylxGDtyjg5wNtXB8/WDzdbPiitpFwfbtigGXRfPy2NjzfbcRDK ar5elcc/+EfOLWcizSCdXX8em7XhMNsW9jAKzte/8c2GGS7XojzazdYOXI5G+JkZF5qleY1ReV7l 0rRTa9lknMoyZf1c+fnvYV4mzHpEzQw9m41S+m+HfwykksMoC6mEjqSSmgORMqlgk4f/gAF2xcdq ABNxADfOD1BsUByPMGXE1uphdKNabbkYGMx7erB+knrN8YyPagCeceB0ZBowBTrLUan1gw3ng5DM JU650UwMZLCmdWz91QZWGp0y6y8RGVcbbmyiwOyBtBo4Whim3bVVYwctq72CHDAxSK4l7BVobZk1 uLGw+c/+aTRKOtT4Zct7Po4Mth/27lYOb0TYxDwNIgA0Ywwol7YBog/Sy9YXGxAEDjRx6+vNVg4g C0Cnl6X1DNaREgT3fnxtlRdRbgWQWgHDwlSjwVMdpUGo7V1quypDLssjzCmAjRJ4k3umHTFTZkRt eWuvJhFg2unShqZGQ9Aqb0EWOGeyDDkvQ44mmdFMyNLvFB91C9QUQiq8zjl5GrT6i9IhL4p6vi+v MwmofoiAz8mjffDmRjNuMf1PicWPJ9HhBkTNGpAVUMFnhdToaKfk0U4alnoLSC2T+70jTkNuliYa GgXG0TNAc680YgC1G4W3janxkBx1SWwO1mdm0NrKYgi2HJrgNCvPZm/APF3OicHUhFlgKJlFZyT0 QLuozQ8PD745cEatlHFAHTBLoNEruXp7dvB8D59nobWyYrZyedrayeAWs7zDdmijwAIF4/FFMR7h pKPW+SzQ+GpjrQsWiY0rVzbBTZzTwShZzXnfmzimR66zNbNhqAXWqBHc/rS907jhiTxMKgf0YYE+ CrDB3vSZ2RhjejqtFnlnX20kHBGE8623vYpLYZ2XBDkIcEXMG4r0eFkeL/yjcXqUIPJ6EFZYg7te h/OyYEpS16uNG0Y+SoOnSqTRsiWNBplyZrWdYNEkoQ/BKYDVUuAKnz4uS6zK46F/BBMuNSgLiHaE Mun1H1Lbw88nCwf+x67TpBbLZiA+bOvuiC+AUHylATLo6KfyFq9IKiMqItqeZIKj9/NUlEBFqRQm Y6YC5vlA0vNREo9/79rhWWnF06K5/vRyY2Ev0kncGcnHZZaP0/DeG5mX8b1hPXvAtNwdeyQH+KAF 2AkeuIM2uUUnerUBhKYcCM4ReYqX5bHjyrT3sN63j+LD231Avp2zX8yOgwVjI6z/37Tv82SW33dO 9rK4/WsCAr0tdnwor3+EQbCnCTap0vlio/B8p6kdzm8Gj1Y/3QCC4pZ5t7jV/lBuGoRhDeBZoGQF a7IrTWPiVkCIQPZT41WZxApR5AJEApzAaL1cMMbcSge52D+esqR4CA/AOKJzZ6jl6O5MGJ2DE680 15mpyLBFuWRCBHoA3GcMYAQoD3Pgq2g7fULZaSSrSFGzT3he2p5ji57UGC0/o/7zdskyaNeVXXqA dn5Kz3dGeqbVBmw5MyCrL7G3mZkhGZmXpM5eLNgbMY53bW9ArEb7q7Q31J6jsYHIzkX8cGueDR+B Z/D4KdiF0UrNwiBmrYxeCkgog1UJEhvEWAgWXd/0/qo4nhoQxRwCMjJgXbwwGA2o825sjI9TALYW 8nY2ho+8FUB4oWEzo4gv7N2h6FHeDEUrx7LzRCH41UYztgiYrSd0NXweMDPQQWFsA5jL1NsEGxmf jOfp/xrIfYzRbIK73wXI5oQ3DQwoq5VEr5HxfpohGyvra2wrc9dvUk9bXn9SdGFVHl1RC7oDKx3G rHf3yPdxLz4gbg2sdOwODaxgXoqVTrHgfwlv28FZyzBH87LIZKEF3pMW9AyzLJnKJ1hmk5y98oBL WqbWx9izJyddAex50ttgzu7Qt4HJ9Fbh1+jbFrE0KNQQzVDEm0qYCfsedcj6tADgDGERdI5YWEuU 4EuoFwDGccHMKuLp2PDpZushoAHKXBHo/IgA9OcN2hfckzqNeF4yegj5nxNzX3WHfE2cbD8kDn54 kirYn7ozJA7CxRGXWicJhO2c5C8E4gATfOj+fwLEO4J6IHDHpkF4mflopiGfDaK1UQOsmT+bGrv0 2oSopMypn7tDVIDfqnIRqC7864n/12+X4JURnlrS2RwrfIHhFZGvvL8RQRd9ASfNytwgFQ9p8BY2 EWwCiZdWFaSPhOxOoI8CwZNOLDCH8YkHOpmOuVaQXqLVsNzKPZyN7Yacg26d1hsFC61O4c5d8+11 AvwBOEoJbE7hPgKBiJZI92ciJVJrrimTQUOgBaAKMMq5Ctf8dQNIlDveR8py5IrgUWzlTtZ073tD q3BibOgemrmkOnetsGBqbRckpjbkJGTrL0AYwQyAV/RepZiBUIOJduDwd89SycfoqXgKLHUAnJ/m xsfFD3tvAc7JjQx3RYUi1KGvKRmduipVTYBGffBRhmGTyGRkkFGHRy459YdGIeTjgU3JIZ4Rna9x 0ci/FtrMvH+RhqMKZkZNZRU0+PEG8IAx2uTzgR58F05tlAGnA+jZ3wXA79H4p7n89ihX8lhaUROn QVCLwm6oZwX5nodapQT9knYVa5XUBChtWk1wTuwlA8UMNXt4d01K03U5xYsGWVYrvC58yFOX3G2d +T2u5Yaq/ZYBZ8v769EpenlViJpPQVEFtV2WQ+ZNfghSIkQtT3k7kxYJO9osOkIn12ynmwv+jsQ4 ilBzjaz1O4qJiQ9FIztOgxQXeZ5j9DySd4zU10gtJ/DgSr9y1yOaAYme1N4XDEMadtxGTEHX28DC h1xI13st2FG/QFykdoE270lLGRjUm3qNFkC7f91pF9rT66Dh4HvgRafhhOSvWrvYSvRSOOYZkGsx 6KpC6ogOdZG6LYpYnuPnIJbWqXJeigfVCqo6IKId4klyNIElvf2ptOBW/GmVd7LryO5/ga9VVLu/ JOej7PNp2cLEb2bASMjEb+jIAGUyZhvzICXQFCIPfCWjc4w1R5CuZ/r/VPQnFNtaaxZAAa37i7Q7 zabjDMksMlBZaCge7RDgRiG7vIq3EsedPaDqj2hShBFQxiYLU0YoFG2RHboqY/tszwnh69A0pbFX lRPkHINlEB6cJ0lBhPIkKb3D8RWTScchsGNs1Ot/bkDWjDGVcd8JR3LP94itvSm6me3EN52WcATS THTlrHc8lH25JNiBhgzYbU3XQTlLic9tonXRtoDFPfpGRgJLsvGXUbkite5dkZbM56tOHVCvM2Li XtsnN029R24amVY/Meofsop9BrIZcUUgaTRLsJPCVfgZBRh1MKLcRJqZvmjaLhiBtvp+G8LiaRAZ i7T3Dk6JQ6QE64/FdUXrLMzAtU46t8QNxaoDnDeGRIHpVX7ETua+IOQW9aQUNii6wrxq1JDKBNOT nnVqmCmGwNlRb6V+RAYuT3zzCIOkCBFhpH47zJIVg9aKYwfj55Wj5C0Aj7zGHrbzO70LvLHbWXId 3HT23/erFLhziqw3tJX6U/62GVFbiNQJtV5jt9kartOOBBTeoQ9BBeoUJN8hDktQF22mCgHyvoKm s8HqjLuruHVhh/thYwoZ/FTFvie98HZXnLKrCredsqsKG89xY/FUXxbprYBespIobI3JC8nr273d rpF3owLAHjWBj8Lyh5NN/hFc7m77ngb9sC7sQ2dLe2cMl7T29yA/bMj0y0eRfuHmDkQGHCW7tJzU q7qi9zkTNQYh175UkIWcE4xRqY0X7pvQVpcMGTF4hwkM/fAkIr2c4QFFUirN1KshBQ6pXfVe7ka5 unKNv0SnLdBA3xv0/hOJEYqqKr8UmYb90mKp+WKjcMwC7R7203To/TNKzba0CXgzTUc5wya8PCEQ beNq4mR0KJtfH+co74x4S3nUy+6Bcqwo/CAFIa3QT4tefu+/MmMsfJsSXyN1/RorZhpDByd09iwk fgE5T19jpTRBEkKEWbHHSFltWNN53CkqgN670JmgLm63vL1rU5hW2KXpXT+KE4RzrTAySkA22aeZ KKfjf50xnl7bZGwmTEmBkzrNGxiJtXmp8oJ9FasSLkhGzsohs/L6826pZHE+Xz5UMl4VVKSwIZLQ RQNGs5/KGmXXjPw5ei3KoLG4sh4dZmdk0oMiet06UUeZfiqFQWWKirSjmkRQaQhNRAGcLVfoVOlM RrT3ObcPUGaTUoqRma0XJEnJK0C+owU3gopU7ztBotJZLcxU8/kTAjDXuZ1Adyq1gxRt1kK26Zmm NPUxgqWtNIMamShDGj2v4n6E7tFHmIvVujQ/Kavtw24BTdPNWM20K07soJNpLSlN3B9Joa81O3k8 jZGfG8AnJkVsBXx0uvZYaUIM3o867p5iab6ubRDlbFAcvJC2RRzFH1ISx31Hql/3QQ0a0TN4vlCL fOoZuXyeY1H0aCxNcmrf1Hqd0QmcpUuqe1T2KiYiIabSZVTel4pGVp1xAHv4nrDIOyoQx4TkUCpQ nbhRKQ+oKRIg64MDs/utWXXapk921+lyCsIcEyUdAFFbrrXuZxKpcCCVxgAsRJWYvsmkcAqyXm1p e6f9ag/ZVQb7eyK6SjxUuYsEw1F+BTmnjFZ494CkkK6050ddzigJOUHxwTEWZzTZPcr3L7vy3iSf ZFDDpMO3CLepDUNeWkquCt8op9/rw5z5/MhikVmzWyzI20N50L5i4dID6sUIZleR8EKyI/XjJqqv gQ1zYTtUtO1fPLuNMN96h3VGOsADjjNDdFqZuifS+rWA5Oi4L66XzJZq6mO5LwJipFHav7y6b4Kb rv/Mw8E9ykDdjQEcex9FkCRBh3PxmUAXlzlEKC/vE4XVMA+RraZNwpPCPRLjLpZVkNd5XWiFnPbP db7quqT+EjeTf5vfIdKGq07UqPjqTTnJ+0Llyn7NbOaWokWVn/syH6UyOxU3hXQjy49MLcd0fobb BHW7+FAuwNLxV29sugjMsTqPmrXqX1PtduRiJk3YgsFLgqiLYJZm3K58eo1Tq/QovfAyAJ+9wtFD eNpwEdlEOnXR18LJm2dIrhO4MKq3QWgzOCjLWRFkxVszIMA9I3hK/tYAJU57pA/J/Z11sveu4LMq 0iMKn1cE63tKoitkMWwpZoQ7/ztFri23zMsvkRF4S1CYqn7mHxPisENRw7/Khy7d45nuqbZgTRAS PBUk+5zXRe0Z97Gr+1ak36S2eSOe10YqhNdETO5VrI+TSg6XBj2BkFwZthwxNvCfEoCf+/wbqaHN NchX8U4jAH7ButRm5XpvoXJNEqUdRNfGWVM6o53H19l5tOf1NCa+T6Bp8BJvDDFpJ0jtT0PVzhoB Q9+K7kg5pDAU+ehycXLxTvUl9ofVlRA019zVjjhHtlFHjVqq+N1sr7dIVASP7AyQ8cldgEXKBVdf 4+bXpLruyDlSwIv6wJdWDDrHU3uLLImefze9ZEQk0eY4d1eBBRYnOL3WjnZ2r7sDx7SC/zRK5Ht4 5apZKUzMXiffw4AsloSouPD7XNNFJCFrvvdIO9v4v/ls4nSPtUVtaACac7EfcTVysYYcfg8wGNFI +zY1kL9Lu23lRLnRp2qXY3X6GoETTYUkzbWrjEysuRRzNCaPvlRCGdytHjkojqMLGjNp57S53ZdB U88bXRpKgyjSoGLHcrkOnXtSTMuhR84LLGZydwd4eYtz95rS+5z7sulhahFOWKJQrAjKoeiZ+nUD dGI/yBj/jLeFSFt2+HW+DP0gP/nCdrzp1lQnIukwOMnhi6u+t0Q+qv9YJ8pwiWQmpnGBsx93H5BH vRNcesdLB6pVYch3NI68Pb/zIn9v2LBcxz3QKo2uJnUhfFzDMeZ/7qfTMwz64xpPy1Ufaqf4TmcE OO3FzpAgCz7Nfxlv0N3ynpjzOykehhJfKmjEWfwKRtbVzTD9HjffQscHeR95kz3ca0Ft/ZEXcbrq 5irlzeY/jKzd2cVGDs6Z6ec2WBOi/j7AYqeLpwscwRpZskpUyLnHfTd/nXD0P9Sxu1TtUSzTDn90 jZBoj41QFfyifM6XPqqeiXPzKt8Ww4SY8SbDymwz/GSUz9g3/JipJqKt7Ja21JMSjBKrNkFtHFM+ zN5xtTnkmMBCm3xF9iYJn2abmba/HI2J6jzL9iEJG309M2rmrHlqHXJaE2ncYhn/jCDGQsVi+bOV orpUcFHfqgtcm6/0/7o+3dgBUxcLMjdJxPd6uXDxma58zxX78sp9ue+TpYlADYciEAtFQ9QLzUx9 HRpmHh2AtSG6Vg8GMypdrKeGCY0k66n75gILDi+RIbKv6S6nLwgz/wmcWv8F9uyztEKvP8tDlj/0 iIdq47Dpd1W+OfgPAO2FqGVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0ODUwCmVuZG9iagoxMyAw IG9iago8PC9MZW5ndGggMTQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytWlmP 2zYQfvevMNCHSkWsiqeovKVNWqQI0Mt5aorCu3Z2t83au90jTX9Gf3GHEo8hOZK9RbMIIEjkcO75 ZujbZdswvmztn384v160y2/h/8XidmEaYf8NH/Dz+fXyq/Xiy5+6JVNNr5fr94u26fteMjl8Z0sl GmOWXS8b+Hq9+KV6Va94o7SSslrXrNEMllc/x5ev61XbCGU0r5bx8aV95NxwJjwF2Zvqa/dadxyo rYCHVnBefWZfd6zjshLx0dQr03DZdsJSZlxo5ul2nQp0Ve/JDm8jk46UYcpYWuH5t5EuE13VotcM PXe1UvrX9XejqmTTyqgqoZ2qpOagpKAqYHL9O2wwyx6rVhidqlbDKU63L2rRgO47XW2BaylBFVuQ tAUBhKyualXd17CasxbEuapXXdOCHrvq4Ffv4+qNf/chrkOPn2rWNaAgUz2DPQx8QiqrVi4a0bcM lGlZ4cqaBXzD9JyBld2715ELtMWvbDtrAEtSg9XQgpfxbSBvV9rPzPj9cBTe9LFm1gy9jFI+EKIF hcFWoeBRWXHVoLQ/gLCxZ1Q7tMofgFR6ID7fRJWGz5YoUvU9qY5DXBAYTlZafwLfb3rDwB/WW3AA 9P2SMGV5kIHAuYZHDto0emDsg/vv/ENh73APd/VK2yyQ8eu+vicdIih4Fxl7rJXlpxvOPQ9Ed+Q5 3ip2LWL5JhpTxZ1owa5gPwkCFd9fEOZDror88+3oiX2rqlW9kg1EN0iBFiAK39q8pBk3VRNpdf4o Xjwsa96Zpm2Fte/KG9iqVPHRyk5TSqDIRep1D2gVcGNEo7XB4RAW/ukkGPw72Ab2dDbz8ajtjkVX 2hfBhMy+IXhASn/ITwbd7QpBniXO6nmJLnHAhsfh60XNoqwkYtkK5z4S7xB/G3waIuUk1EaSAUv5 HFBlGtZByrrCPou9fYht8HjDlY/tTSQ/UlVMJnJ7ljakeik9bIhQ3KQFw4qLXp1lqVMlKbF0sgPi ZRBaSWevQPJjzOpX2JI0y0GhB0zBH9ckqcfvQTG8J7gNGYRSXJYrYpJ6iOePOir3+jMUxyrM4tsZ eSK+qSDNWEJxhzi0m6m8b5ccck8a9cEMgD/AVzeEKMGOF3OxgRIFondZ6Hcfgx0pMdTiUWih06rs yZ0Nh2jdIwyCPr+MgCABCc7F0hw9bpLVN1BeGiNU2yUe6wV8yAWEsoKODEb6K3iHVXOMZ6T/Ox9n LsZlB+dyH+PIlhQf6MzzMg+ihdsYpmSCSQqrJ1mWkMdEntkC/TzJ1p7kPpo+GJoqzSGbfKp5bxXS z5qUteKYTcWcTQUXhU0V09U/NeSoVnGNzZREqzOXtZIcTYb4iPDbcwRsrGLgWiXeIo8GYqqFJcy/ QwChJda9qyItKpbKHQgdv8gBOeLNITCKN34ibxMo2H+mIAvKFsER3tWRpaZmHMJbdxj9IVuHvIKC zaEdfyzQFY3sO0MixjIx3SGHdx75t/eEnQtYBvm69wGbBJI/lQx8KpmWyBMFwpDbxl41Kjmkh8si WNG6ffwYwq4EWGjD8bwDK6HhRgAAYTynINcmmV6hikzVxW2p7tJVcGajjDdV3M6iV0jolzutvVKh s0Yv72MD9Gkq2EdT49J8WtgRDWN4QP1g1nxguOMpufP6wQ1UPwR/6vho3yVixa8dC0AG81ou8EsH af2ZE43c4AG9QSQOqSgUbEGchOzyEE2YsDDOJ0LflFR3T2QWQiR6K5Ftxu7WNdCwQ/pwnrGI52B0 N9lKGgIRPTLh0NtoQRfvZBPqz8wgMt3lI+mzRUmYeZpZd1TmE6o5mxxa+JMn21DRkwSJzLubFGlP fnks1RujHGOW0dyy4b0Z7T1O2FbQSEFRN0mc/3dndXWSaeYgnqP6xh73+WL9BR7TJVUr6HMTXSC8 owroPtOx/Yhg9EOmW/sZw3/eRQpps+2jvhjiQdWlh3jUkCQZ4oUFbognu+44Pg+bUACcOsULe9Hn yWFeWEzDGCrcxtwbkETmHC6qL1wjLyDHhCRzORFEGRNDiikhCtryHOfnYdbMmXFet/KHRq8e3X1E rm8GR0TYdLB6D3jLRIBIZYVlAGUBviFVZbU4lgrEftKt0q1oGQko9CkbnxE4Z1/wnnXKiJUiDrkC VEolrKTXR+Lu5hmcgMf+/CSjlyrPs8CQ68rziJx75xxQgy+ESdKSKg1lL4ZEOs8Q7eCbFKLEFkm7 9AHJPjlNxFn/XM8XdoUOiSzJFJ9EK3tDONN50gnndyN2TLZiPbSdrablPTYEDieGfst1Qpq3Osel kL+UkEm9mgPwQ3SXw1fk80GeiznnQy6HYSTVLoQ9ryNfP/hsn8R3Gf5bIj4SXHZPWA/NVMd1dnq0 I3YkMVl2U1SX9hC1Q0HtxGVPHlPQNxATonmWkhH7CGfA6dpw/UNMaMpYb3sd2Z+spoqMFno0WE6H g0OhxHwsRDKARQz6k/RSdrjoc8SEBGzbkluOtsDTRUnztF0v6NCAnQ6d9PJnNC+O9BPG5aUZjpTP iekMbAEUkNz/lBcbJ8+cS1YQB/tcLUn85gODDC//L4nJBuscQyl2oW84/DloEoJ7L8qDZpLevRs4 qUYwFsGjXWivfnbElqckE1pCKlEeydIEmEBejjJMEomnwjgkHTFnT25/nSt61Wdd8ET+gXhz055R z8cuWvMG33dVJQqj71VPAkvD0IPyVaojQ4PuU32sBKPTo0UbiXQMhVYQgbXvR6AjoblEChpAD+u1 8Xeb1kgty9RNtyNvI/FM5dTMZLa6z1TFJHdRk+kj6XL2/p1OW4kI56EtLboOa4B8TpIM2WjyT+wp 7G7qNyP5kGHq9xmlSyXjw0zqMbPpphXUb1coWBfI3pQZMBnElWXwKqL0qcENpAJ6BEJB/aRtjZWA 1MY9WaYKfVATAUo8Ypa4Lx6IruWeFK7ckZS4cuZS1rhepYLnv11peRLiR5qT6R8J2ZI+NWRO734I /qeHpiX+pUsgFfLoWFq9wXeoX+M57kWi1CPzwNlUXoy8iRE9efNC+SodUU8ebhM9CjnoLjR2tBuc GG+jsMoH60cm3KWQtCfcxpVPmw2n3U7pCUl/SV0tbEPio0H25M/10MihKeeEsgNQhK60w5gQTa1f rRc/wt+/gaQUjmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMjM1MwplbmRvYmoKNCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDExIDAgUgo+PgovQ29udGVu dHMgNSAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0ZvbnQgMTUgMCBSCj4+Ci9Db250ZW50cyAxMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTIgMCBSCl0gL0NvdW50IDIKL1JvdGF0ZSAw Pj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRh IDE3IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvUjEwCjEwIDAgUi9SNwo3IDAgUi9SOAo4IDAg Ui9SOQo5IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9i agoxMCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5 cGUvVHlwZTE+PgplbmRvYmoKNyAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtQm9sZC9UeXBl L0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRp Y2EvVHlwZS9Gb250Ci9FbmNvZGluZyAxNiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxNiAw IG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxNDYvcXVvdGVyaWdodAoyNTIvdWRp ZXJlc2lzXT4+CmVuZG9iago5IDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1 ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE2 MDk+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3 b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8y Mi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+ CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1 ZmY0MmQ0YWYnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlBy b2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQgOC41NCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0nYzI1ZjFmMzMtNzkyOS0xMWRlLTAwMDAtN2RiNWZmNDJkNGFmJyB4bWxuczp4YXA9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpNb2RpZnlEYXRlPScyMDA5LTA3LTIyJyB4YXA6 Q3JlYXRlRGF0ZT0nMjAwOS0wNy0yMic+PHhhcDpDcmVhdG9yVG9vbD5HUEwgR2hvc3RzY3JpcHQg OC41NCBQREYgV3JpdGVyPC94YXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0 YWYnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpE b2N1bWVudElEPSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYnLz4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2MyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZicgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9 J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gt ZGVmYXVsdCc+XDM3NlwzNzdcMDAwRFwwMDBFXDAwMENcMDAwVFwwMDAzXDAwMDhcMDAwX1wwMDAw XDAwMDFcMDAwN1wwMDByXDAwMDFcMDAwX1wwMDBMXDAwMGlcMDAwYVwwMDBpXDAwMHNcMDAwb1ww MDBuXDAwMF9cMDAwdFwwMDBvXDAwMF9cMDAwSVwwMDBUXDAwMFVcMDAwX1wwMDBTXDAwMEdcMDAw MVwwMDA2XDAwMF9cMDAwb1wwMDBuXDAwMF9cMDAwY1wwMDBvXDAwMGRcMDAwZVwwMDBjXDAwMHNc MDAwLVwwMDBjXDAwMGxcMDAwZVwwMDBhXDAwMG48L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRs ZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPlwzNzZcMzc3XDAwMGNcMDAwYVwwMDBtXDAw MHBcMDAwb1wwMDBzPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlw dGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9k dWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkKL0NyZWF0aW9uRGF0ZShEOjIwMDkwNzIyMTY0NDU4 KzAyJzAwJykKL01vZERhdGUoRDoyMDA5MDcyMjE2NDQ1OCkKL1RpdGxlKFwzNzZcMzc3XDAwMERc MDAwRVwwMDBDXDAwMFRcMDAwM1wwMDA4XDAwMF9cMDAwMFwwMDAxXDAwMDdcMDAwclwwMDAxXDAw MF9cMDAwTFwwMDBpXDAwMGFcMDAwaVwwMDBzXDAwMG9cMDAwblwwMDBfXDAwMHRcMDAwb1wwMDBf XDAwMElcMDAwVFwwMDBVXDAwMF9cMDAwU1wwMDBHXDAwMDFcMDAwNlwwMDBfXDAwMG9cMDAwblww MDBfXDAwMGNcMDAwb1wwMDBkXDAwMGVcMDAwY1wwMDBzXDAwMC1cMDAwY1wwMDBsXDAwMGVcMDAw YVwwMDBuKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAwMHJcMDAwZVww MDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBpXDAwMG9cMDAw blwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3N1wwMDBjXDAw MGFcMDAwbVwwMDBwXDAwMG9cMDAwcykKL0tleXdvcmRzKCkKL1N1YmplY3QoKT4+ZW5kb2JqCnhy ZWYKMCAxOAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDc3NjIgMDAwMDAgbiAKMDAwMDAwOTk2 MCAwMDAwMCBuIAowMDAwMDA3Njg3IDAwMDAwIG4gCjAwMDAwMDc0MDEgMDAwMDAgbiAKMDAwMDAw MDAxNSAwMDAwMCBuIAowMDAwMDA0OTM1IDAwMDAwIG4gCjAwMDAwMDc5OTggMDAwMDAgbiAKMDAw MDAwODA2NyAwMDAwMCBuIAowMDAwMDA4MjI1IDAwMDAwIG4gCjAwMDAwMDc5MjUgMDAwMDAgbiAK MDAwMDAwNzgyNyAwMDAwMCBuIAowMDAwMDA3NTQzIDAwMDAwIG4gCjAwMDAwMDQ5NTUgMDAwMDAg biAKMDAwMDAwNzM4MCAwMDAwMCBuIAowMDAwMDA3ODg2IDAwMDAwIG4gCjAwMDAwMDgxNDcgMDAw MDAgbiAKMDAwMDAwODMwMSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE4IC9Sb290IDEgMCBS IC9JbmZvIDIgMCBSCi9JRCBbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjxGQjBB MEZDOUI3QjlBMTQyQ0JFNTY5OEVEMTk2ODJFNT5dCj4+CnN0YXJ0eHJlZgoxMDU0MwolJUVPRgox IDAgb2JqPDwvTWV0YWRhdGEgMTkgMCBSL1BhZ2VzIDMgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9i ag0yIDAgb2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwOTA3MjIxNjQ0NTgrMDInMDAnKS9TdWJqZWN0 KCkvQXV0aG9yKP7/AGMAYQBtAHAAbwBzKS9DcmVhdG9yKP7/AFAARABGAEMAcgBlAGEAdABvAHIA IABWAGUAcgBzAGkAbwBuACAAMAAuADkALgAzKS9LZXl3b3JkcygpL1Byb2R1Y2VyKEdQTCBHaG9z dHNjcmlwdCA4LjU0KS9Nb2REYXRlKEQ6MjAwOTA3MjIxNjQ0NTgpL1RpdGxlKERFQ1QzOF8wMTdy MV9MaWFpc29uX3RvX0lUVV9TRzE2X29uX2NvZGVjcyk+Pg1lbmRvYmoNMTggMCBvYmo8PC9DcmVh dGlvbkRhdGUoRDoyMDA5MDcyMjE2NDQ1OCswMicwMCcpL1N1YmplY3QoKS9DcmVhdG9yKFBERkNy ZWF0b3IgVmVyc2lvbiAwLjkuMykvS2V5d29yZHMoKS9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQg OC41NCkvTW9kRGF0ZShEOjIwMDkwNzIyMTY0NjA5KzAyJzAwJykvVGl0bGUoREVDVDM4XzAxN3Ix X0xpYWlzb25fdG9fSVRVX1NHMTZfb25fY29kZWNzKT4+DWVuZG9iag0xOSAwIG9iajw8L1N1YnR5 cGUvWE1ML0xlbmd0aCAzODU1L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2lu PSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMiI+CiAgIDxyZGY6UkRGIHhtbG5zOnJk Zj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0 MmQ0YWYiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z LyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+R1BMIEdob3N0c2NyaXB0IDguNTQ8L3BkZjpQcm9k dWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRm OmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYiCiAgICAgICAgICAg IHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6 TW9kaWZ5RGF0ZT4yMDA5LTA3LTIyVDE2OjQ2OjA5KzAyOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAg ICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDktMDctMjJUMTY6NDQ6NTgrMDI6MDA8L3hhcDpDcmVh dGVEYXRlPgogICAgICAgICA8eGFwOkNyZWF0b3JUb29sPlBERkNyZWF0b3IgVmVyc2lvbiAwLjku MzwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDA5LTA3LTIy VDE2OjQ2OjA5KzAyOjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0w MDAwLTdkYjVmZjQyZDRhZiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD5jMjVmMWYzMy03 OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWY8L3hhcE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4 YXBNTTpJbnN0YW5jZUlEPnV1aWQ6NTQwYWU3YzctZWQ2My00OTM1LWFkN2QtOTM4ZWQwOGUxYmYz PC94YXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv Ij4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAg ICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjps aSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5ERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9v bl9jb2RlY3M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRp dGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAg ICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6ZGVzY3Jp cHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDps YW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOmRl c2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1w bWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDXhyZWYNCjEgMg0KMDAwMDAx MTA1NyAwMDAwMCBuDQowMDAwMDExMTE3IDAwMDAwIG4NCjE4IDINCjAwMDAwMTEzODUgMDAwMDAg bg0KMDAwMDAxMTYxMiAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDIwL1Jvb3QgMSAwIFIvSW5m byAxOCAwIFIvSURbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjwwMDk4NkIwNUUw MTM1QjQ1OUFCRDk0NzYwRjdFNzAxRj5dL1ByZXYgMTA1NDMgPj4NCnN0YXJ0eHJlZg0KMTU1NDQN CiUlRU9GDQo= --Apple-Mail-5--615251455 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-5--615251455-- From stewe@stewe.org Wed Jul 22 08:16:53 2009 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 3BB0F3A6807 for ; Wed, 22 Jul 2009 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 iduGyldIOvDf for ; Wed, 22 Jul 2009 08:16:47 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id B37D33A6820 for ; Wed, 22 Jul 2009 08:16:46 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 352703-1743317 for ; Wed, 22 Jul 2009 17:15:23 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 22 Jul 2009 08:15:12 -0700 From: Stephan Wenger To: "codec@ietf.org" Message-ID: Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) Thread-Index: AcoK3zUzXJxUBcQUOkuTNoZZ6HLCwQ== In-Reply-To: <2F73DAAD-E503-4DC8-A329-4F40FDFD5723@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331095320_25342994" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:16:53 -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_3331095320_25342994 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable For those who don=B9t know: the mandatory G.722 (without any fractional numbers) is the 1988 generation, 7kHz, 64 kbit/s sub-band ADPCM codec whose patents are widely believe to have expired. It=B9s also not exactly state-of-the-art anymore :-) Regards, Stephan On 7/22/09 8:01 AM, "Cullen Jennings" wrote: >=20 >=20 > Begin forwarded message: >=20 >> > From: >> > Date: July 22, 2009 8:53:31 AM MDT (CA) >> > To: , >> > Cc: , >> > Subject: RE: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 >> > July 2009) >> > >> > Dear Cullen, Russ >> > >> > I have been asked to forward you information we just received from >> > ETSI DECT on the usage of ITU-T codecs in next generation ETSI DECT >> > systems, in the hope it may assist in the discussions in the codec >> > mailing list, as well as on the deliberations whether or not to >> > create a WG under RAI for a wideband internet codec. >> > >> > I attach two derivative formats of the original document (the >> > original was winword), PDF and HTML, I am not sure which format will >> > render better. Will you, or should I, forward >> > <> i >> > <> t to the codec >> > mailing list? >> > >> > Best regards, >> > Sim=E3o >> > >> > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm >> >> > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf >> >> > >> > _____________________________________________ >> > From: TSBSG16, ITU [mailto:tsbsg16@itu.int] >> > Sent: 14 July 2009 16:51 >> > To: housley@vigilsec.com; fluffy@cisco.com; statements@ietf.org >> > Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com >> > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July >> > 2009) >> > >> > >> > >> > Kindly find attached the Liaison Statement COM16 - LS 71 on >> > "information on ITU-T Speech and audio coding standardisation" >> > addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting >> > (10 July 2009). >> > >> > Please take note that we are sending herewith the word version as >> > well as the pdf version of the LS. In addition, there is an >> > attachment, which is in excel. Since it is quite complex with >> > different sheets, we preferred to keep the excel file in the >> > original version. >> > >> > << ls071-16.doc >> >> > << ls071-16.pdf >> >> > << ls071_Att.1_Copy of MCSD-Database-V20081003.xls >> >> > >> > >> > Best regards, >> > Rosa Angeles-Le=F3n de Vivero >> > Assistant for ITU-T Study Group 16 >> > ITU - Telecommunication Standardization Bureau (TSB) >> > SG 16 e-mail: tsbsg16@itu.int >> > Tel. 41-22 730 5445 >> > Fax 41-22 730 5853 >> > >> > >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3331095320_25342994 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (= 10 July 2009) For those who don’t know: the mandatory G.722 (without any fractiona= l numbers) is the 1988 generation, 7kHz, 64 kbit/s sub-band ADPCM codec whos= e patents are widely believe to have expired.  It’s also not exac= tly state-of-the-art anymore :-)
Regards,
Stephan



On 7/22/09 8:01 AM, "Cullen Jennings" <fluffy@cisco.com> wrote:



Begin forwarded message:

> From: <simao.campos@itu.int><= BR> > Date: July 22, 2009 8:53:31 AM MDT (CA)
> To: <housley@vigilsec.com>, &= lt;fluffy@cisco.com>
> Cc: <claude.lamblin@ora= nge-ftgroup.com>, <tsbsg16@itu.int&g= t;
> Subject: RE: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 &nb= sp;
> July 2009)
>
> Dear Cullen, Russ
>
> I have been asked to forward you information we just received from &nb= sp;
> ETSI DECT on the usage of ITU-T codecs in next generation ETSI DECT &n= bsp;
> systems, in the hope it may assist in the discussions in the codec &nb= sp;
> mailing list, as well as on the deliberations whether or not to  =
> create a WG under RAI for a wideband internet codec.
>
> I attach two derivative formats of the original document (the   > original was winword), PDF and HTML, I am not sure which format will &= nbsp;
> render better. Will you, or should I, forward   
> <<DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm>> i  = ;
> <<DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf>> t to th= e codec  
> mailing list?
>
> Best regards,
> Simão
>
> << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm >>
> << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf >>
>
> _____________________________________________
> From:  TSBSG16, ITU [mailto:tsbs= g16@itu.int]
> Sent: 14 July 2009 16:51
> To: housley@vigilsec.com; fluffy@cisco.com; s= tatements@ietf.org
> Cc: Campos, Simao; cl= aude.lamblin@orange-ftgroup.com
> Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 Ju= ly  
> 2009)
>
>
>
> Kindly find attached the Liaison Statement COM16 - LS 71 on  
> "information on ITU-T Speech and audio coding standardisation&quo= t;  
> addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting &nbs= p;
> (10 July 2009).
>
> Please take note that we are sending herewith the word version as &nbs= p;
> well as the pdf version of the LS.  In addition, there is an &nbs= p;
> attachment, which is in excel.  Since it is quite complex with &n= bsp;
> different sheets, we preferred to keep the excel file in the   > original version.
>
> << ls071-16.doc >>
> << ls071-16.pdf >>
> << ls071_Att.1_Copy of MCSD-Database-V20081003.xls >>
>
>
> Best regards,
> Rosa Angeles-León de Vivero
> Assistant for ITU-T Study Group 16
> ITU - Telecommunication Standardization Bureau (TSB)
> SG 16 e-mail: tsbsg16@itu.int
> Tel.  41-22 730 5445
> Fax 41-22 730 5853
>
>

_____________________________________= __________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3331095320_25342994-- From steveu@coppice.org Wed Jul 22 08:45:37 2009 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 D36853A6B91 for ; Wed, 22 Jul 2009 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 RIzk5XziPcQl for ; Wed, 22 Jul 2009 08:45:37 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id B865D3A68FB for ; Wed, 22 Jul 2009 08:45:36 -0700 (PDT) Received: from xeon.coppice.org (204.196.17.210.dyn.pacific.net.hk [210.17.196.204]) by cwb.pacific.net.hk with ESMTP id n6MFiC58012331; Wed, 22 Jul 2009 23:44:13 +0800 Message-ID: <4A6733CB.7060507@coppice.org> Date: Wed, 22 Jul 2009 23:44:11 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "codec@ietf.org" Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:45:37 -0000 Stephan Wenger wrote: > For those who don’t know: the mandatory G.722 (without any fractional > numbers) is the 1988 generation, 7kHz, 64 kbit/s sub-band ADPCM codec > whose patents are widely believe to have expired. It’s also not > exactly state-of-the-art anymore :-) Interestingly, G.722 is the only wideband codec getting widely deployed outside cellular right now. Its adoption at such a late stage in its life (actually, it didn't see much use until recently) is a testament to the need for unencumbered codecs. People are safe with it, as nowhere allows a patent to persist for 21 years. That seems to be the only reason for its broad adoption, and the only reason other things are seeing wide deployment is their encumberance. Unencumbered appears to trump old and high bit rate. Steve From stephen.botzko@gmail.com Wed Jul 22 09:15:29 2009 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 9E36C3A6929 for ; Wed, 22 Jul 2009 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 saxPhWa2ZF1Z for ; Wed, 22 Jul 2009 09:15:28 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3C5C63A6820 for ; Wed, 22 Jul 2009 09:15:26 -0700 (PDT) Received: by fxm18 with SMTP id 18so293974fxm.37 for ; Wed, 22 Jul 2009 09:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jlS3IngckNsJGre6c9hILvHDwO98FOir2iPKYg/wIKY=; b=W5N7ydh37DTtT6BNwh9ghCaeQf84lm/dz0toktbFpHkM5mU/bnUWSzGmHzdilwoHgt +KBEPv59xkIFne1KZYJXVDzcbzXKlMj6tmonmMVexIDOQZr+XJrdIcIuiiayF7M94v6J ZDLMCAVZaywo5+24aGAxvbJXSEMAGB3m8rBjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fgRpecNZor889gq6cXkBcTi4HzlVdveBUZIuufZ8DCD6GWiY1HbCOpJ+EcbrQ6mNl/ BBvLVqm69icmZCBSIvbGmNKNVccAppT9+4371yn9NzRUNehxYWIXkDbuJXtTIDSRl6tJ fXusTjarXXTHARqdnnFztgR4P6QkgyecDgG8s= MIME-Version: 1.0 Received: by 10.223.108.74 with SMTP id e10mr598895fap.35.1248279222961; Wed, 22 Jul 2009 09:13:42 -0700 (PDT) In-Reply-To: <20090722085309.146560cu5ffmjy79@mail.skype.net> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> <4A6722F6.40903@octasic.com> <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> <20090722085309.146560cu5ffmjy79@mail.skype.net> Date: Wed, 22 Jul 2009 12:13:42 -0400 Message-ID: <6e9223710907220913i6d129a67i659ace8676279026@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636c5a87eaa4780046f4da7b0 Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:15:29 -0000 --001636c5a87eaa4780046f4da7b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adding requirements during the end-game may not be the best. Also, I think the "agile" vs "waterfall" comparison does not really apply in an SDO development, where the various participants do not have aligned business goals. Assuming that participants have a stake (e.g. want their own proposals to be accepted), they will predictably argue for "rough consensus" to relax requirements that their proposal might not meet, and for "strict assessment" of requirements that they are sure they meet. If there is competition for a specific codec, it will become a mess. A parallel might be 802.11n in the IEEE, where failure to achieve consensus on drafts has been a huge issue. Though perhaps this could wait until after the BOF. Stephen Botzko Polycom On Wed, Jul 22, 2009 at 11:53 AM, Koen Vos wrote: > Agree that rough consensus for complexity evaluation may not work when > comparing very similar candidates. However, there is a good chance that > either there won't be very similar candidates, or the similar candidates > will all be deemed to have acceptable complexity. If that happens, the > rough consensus approach will have saved us a large amount of work. On the > other hand, if we do run into a problem, we can -through rough consensus- > create a detailed WMOPS requirement at that stage. > > I see the difference in approach as "waterfall" versus "agile". > > koen. > > > Quoting stephen botzko : > > The benefit of measured complexity is that it provides a precise >> definition >> of the requirement that can be tested. Even if it does not exactly map >> onto >> a given processor, this can still be useful. >> >> For instance, if you have two codec candidates, using a "rough consensus" >> will make it very hard to reject one of them on the grounds that it >> doesn't >> meet the complexity requirement. My guess is that the result will either >> be >> that complexity gradually creeps upwards, or that "rough consensus" will >> not >> be achieved, totally blocking progress. >> >> More generally, if you use a process where multiple codec candidates are >> considered, "rough consensus" is not efficient - it is likely to be >> unachievable if a significant fraction of the WG participants have >> candidates in play. This would be likely true even if the "signficant >> fraction" is < 50%. >> >> Regards, >> Stephen Botzko >> Polycom >> >> >> On Wed, Jul 22, 2009 at 10:32 AM, Jean-Marc Valin < >> jean-marc.valin@octasic.com> wrote: >> >> Hi Herve, >>> >>> (contributor hat on) >>> >>> My earlier comments were based on the version of the basic ops that I saw >>> in many standards (and assuming there was just one WMOPS definition). I >>> was >>> not aware that these operators had been "recently" revised. Thanks for >>> pointing those out. I agree that the revised version makes more sense and >>> is >>> closer to the a 32-bit DSP. I still see a few issues with STL2005 (e.g. >>> lack >>> of unsigned add/sub), but they are relatively minor compared to the older >>> version. >>> >>> That being said, I still consider that there are fundamental limitations >>> to >>> the WMOPS *approach*, caused by differences in DSP/CPU architectures. For >>> example, many (all?) ARM cores do not have saturating operators. When it >>> comes to conditional branches, some architectures will pay a fixed price >>> for >>> a branch taken, while others (e.g. x86) will have virtually no cost for >>> an >>> easily predicted branch and a huge cost for a branch on "random" data. In >>> the end, WMOPS will give you a rough idea of the complexity, but I >>> believe >>> it is preferable to use rough consensus (possibly backed by some >>> benchmarks) >>> to ultimately decide on what's acceptable. >>> >>> Cheers, >>> >>> Jean-Marc >>> >>> Herve Taddei wrote: >>> >>> Dear Jean Marc and Steve, >>>> >>>> >>>> Let me correct some statements made on the WMOPS counting as it seems to >>>> me they are either wrong or you are not looking to the tool we are used >>>> to >>>> have. So I am not sure your comments are based on G.191, if that is the >>>> case, I have asked someone heavily involved in the design of ITU-T G.191 >>>> to >>>> answer some of your points. >>>> >>>> >>>> >>>> > * it forces you to code the fixed-point in a certain way (e.g. >>>>> >>>>> >>>> > fractional vs interger multiply); >>>> >>>>> >>>>> >>>> In general, in order to "automate" the evaluation of the complexity of >>>> an >>>> algorithm on a family of processor architectures, the fixed point code >>>> needs >>>> to be written in certain ways. If evaluating the complexity of a codec >>>> is an >>>> important factor in the standardisation process, then such coding >>>> guidelines >>>> should be agreed by the various parties involved in the standardisation. >>>> W/ regards to fractional vs interger multiply : ITU STL 2000 supports >>>> few >>>> integer multiplication (L mult0, L_mac0, L_msu0). It is true that the >>>> variety & numbers of fractional multiplication operators vs integer >>>> multiplication operators is not equal. From historical point of view, >>>> the >>>> "fractional" multiplication was priviledged. In 2003 (in preparation of >>>> STL2005), there was a proposal to widen the set of integer >>>> multiplication >>>> while taking care of well counting the integer/fractional multiplication >>>> mode switch that may be needed on some processors. This discussion was >>>> not >>>> carried on forward. >>>> >>>> >>>> >>>> > * it's designed for a 16-bit (TI) DSP and is not very >>>>> respresentative >>>>> of >>>>> >>>>> >>>> > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; >>>> >>>>> >>>>> >>>> 1st of all, I don't believe that the STL2005 is designed for a TI DSP. >>>> For >>>> example, during the STL2005 design process STM inputs were factored in, >>>> among others on the reflector. >>>> Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 >>>> (same as L_mac). >>>> >>>> Now, in a more general statement, is the STL a basic operator library >>>> representing more a 16b or 32b processor ? If I look at the STl2005 list >>>> of >>>> operators which have a complexity > 1, I believe we fall in those >>>> categories >>>> : >>>> - add / subtract with carry bit. >>>> - shift and round. >>>> - integer multiplication with truncation to 16 lsbs (reflects indeed >>>> that >>>> STL is historically fractional based). >>>> - bit rotation operation >>>> - high precision 32x16 and 32x32 multiplication (requires 40b STL >>>> headers). >>>> >>>> I believe that with the renewed complexity weights made in 2005, the STL >>>> is closer to a 32b processor than a 16b processor to the exception of >>>> the >>>> 32x32b multiplication which is not having a complexity of 1 ... but of 4 >>>> (Mpy 32 32 ss inside the 40b lib). >>>> >>>> >>>> >>>> > * it completely ignore issues such as conditional branches, which >>>>> can >>>>> be >>>>> >>>>> >>>> > more important than arithmetic operations on modern architectures; >>>> >>>>> >>>>> >>>> This is incorrect, with STL2005, control operation complexity count is >>>> supported. >>>> Any improvement suggestions welcomed to be discussed. >>>> >>>> >>>> >>>> Also, the ITU approach only tries to get an instruction count for the >>>>> >>>>> fixed point implementations. >>>> >>>> The floating point computational complexity is also very important >>>> >>>>> >>>>> these days. >>>> >>>> I think this is not correct as floating point implementation counters >>>> were >>>> proposed in ITU-T (from VoiceAge actually) and have been used in many >>>> standardization exercises for reporting floating point complexity. >>>> >>>> >>>> Best regards >>>> >>>> >>>> Herve >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > --001636c5a87eaa4780046f4da7b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adding requirements during the end-game may not be the best.

Also, I= think the "agile" vs "waterfall" comparison does not r= eally apply in an SDO development, where the various participants do not ha= ve aligned business goals.

Assuming that participants have a stake (e.g. want their own proposals = to be accepted), they will predictably argue for "rough consensus"= ; to relax requirements that their proposal might not meet, and for "s= trict assessment" of requirements that they are sure they meet.=A0 If = there is competition for a specific codec, it will become a mess.=A0 A para= llel might be 802.11n in the IEEE, where failure to achieve consensus on dr= afts has been a huge issue.

Though perhaps this could wait until after the BOF.

Stephen Botz= ko
Polycom




On Wed, Jul 22,= 2009 at 11:53 AM, Koen Vos <koen.vos@skype.net> wrote:
Agree that rough = consensus for complexity evaluation may not work when comparing very simila= r candidates. =A0However, there is a good chance that either there won'= t be very similar candidates, or the similar candidates will all be deemed = to have acceptable complexity. =A0If that happens, the rough consensus appr= oach will have saved us a large amount of work. =A0On the other hand, if we= do run into a problem, we can -through rough consensus- create a detailed = WMOPS requirement at that stage.

I see the difference in approach as "waterfall" versus "agil= e".


koen.


Quoting stephen botzko <stephen.botzko@gmail.com>:

The benefit of measured complexity is that it provides a precise definition=
of the requirement that can be tested. =A0Even if it does not exactly map o= nto
a given processor, this can still be useful.

For instance, if you have two codec candidates, using a "rough consens= us"
will make it very hard to reject one of them on the grounds that it doesn&#= 39;t
meet the complexity requirement. =A0My guess is that the result will either= be
that complexity gradually creeps upwards, or that "rough consensus&quo= t; will not
be achieved, totally blocking progress.

More generally, if you use a process where multiple codec candidates are considered, "rough consensus" is not efficient - it is likely to = be
unachievable if a significant fraction of the WG participants have
candidates in play. =A0This would be likely true even if the "signfica= nt
fraction" is < 50%.

Regards,
Stephen Botzko
Polycom


On Wed, Jul 22, 2009 at 10:32 AM, Jean-Marc Valin <
jean-marc.= valin@octasic.com> wrote:

Hi Herve,

(contributor hat on)

My earlier comments were based on the version of the basic ops that I saw in many standards (and assuming there was just one WMOPS definition). I was=
not aware that these operators had been "recently" revised. Thank= s for
pointing those out. I agree that the revised version makes more sense and i= s
closer to the a 32-bit DSP. I still see a few issues with STL2005 (e.g. lac= k
of unsigned add/sub), but they are relatively minor compared to the older version.

That being said, I still consider that there are fundamental limitations to=
the WMOPS *approach*, caused by differences in DSP/CPU architectures. For example, many (all?) ARM cores do not have saturating operators. When it comes to conditional branches, some architectures will pay a fixed price fo= r
a branch taken, while others (e.g. x86) will have virtually no cost for an<= br> easily predicted branch and a huge cost for a branch on "random" = data. In
the end, WMOPS will give you a rough idea of the complexity, but I believe<= br> it is preferable to use rough consensus (possibly backed by some benchmarks= )
to ultimately decide on what's acceptable.

Cheers,

=A0 =A0 =A0 Jean-Marc

Herve Taddei wrote:

Dear Jean Marc and Steve,


Let me correct some statements made on the WMOPS counting as it seems to me they are either wrong or you are not looking to the tool we are used to<= br> have. So I am not sure your comments are based on G.191, if that is the
case, I have asked someone heavily involved in the design of ITU-T G.191 to=
answer some of your points.



=A0> * it forces you to code the fixed-point in a certain way (e.g.


=A0> fractional vs interger multiply);


In general, in order to "automate" the evaluation of the complexi= ty of an
algorithm on a family of processor architectures, the fixed point code need= s
to be written in certain ways. If evaluating the complexity of a codec is a= n
important factor in the standardisation process, then such coding guideline= s
should be agreed by the various parties involved in the standardisation. W/ regards to fractional vs interger multiply : ITU STL 2000 supports few integer multiplication (L mult0, L_mac0, L_msu0). It is true that the
variety & numbers of fractional multiplication operators vs integer
multiplication operators is not equal. From historical point of view, the "fractional" multiplication was priviledged. In 2003 (in preparat= ion of
STL2005), there was a proposal to widen the set of integer multiplication while taking care of well counting the integer/fractional multiplication mode switch that may be needed on some processors. This discussion was not<= br> carried on forward.



=A0> * it's designed for a 16-bit (TI) DSP and is not very respresen= tative
of


=A0> modern 32-bit DSPs. For example, a 32-bit add costs more than a MA= C;


1st of all, I don't believe that the STL2005 is designed for a TI DSP. = For
example, during the STL2005 design process STM inputs were factored in,
among others on the reflector.
Then, with regards to 32b add, in STL2005, L_add complexity weight is 1
(same as L_mac).

Now, in a more general statement, is the STL a basic operator library
representing more a 16b or 32b processor ? If I look at the STl2005 list of=
operators which have a complexity > 1, I believe we fall in those catego= ries
:
- add / subtract with carry bit.
- shift and round.
- integer multiplication with truncation to 16 lsbs (reflects indeed that STL is historically fractional based).
- bit rotation operation
- high precision 32x16 and 32x32 multiplication (requires 40b STL
headers).

I believe that with the renewed complexity weights made in 2005, the STL is closer to a 32b processor than a 16b processor to the exception of the 32x32b multiplication which is not having a complexity of 1 ... but of 4 (Mpy 32 32 ss inside the 40b lib).



=A0> * it completely ignore issues such as conditional branches, which c= an
be


=A0> more important than arithmetic operations on modern architectures;=


This is incorrect, with STL2005, control operation complexity count is
supported.
Any improvement suggestions welcomed to be discussed.



=A0Also, the ITU approach only tries to get an instruction count for the
fixed point implementations.

=A0The floating point computational complexity is also very important

these days.

I think this is not correct as floating point implementation counters were<= br> proposed in ITU-T (from VoiceAge actually) and have been used in many
standardization exercises for reporting floating point complexity.


Best regards


Herve


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


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





--001636c5a87eaa4780046f4da7b0-- From jean-marc.valin@octasic.com Wed Jul 22 10:46:09 2009 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 2E2133A6820 for ; Wed, 22 Jul 2009 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 WOzNgR3bIUr3 for ; Wed, 22 Jul 2009 10:46:03 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id AD4443A69F3 for ; Wed, 22 Jul 2009 10:46:03 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:44:12 -0400 Message-ID: <4A674FEC.9090901@octasic.com> Date: Wed, 22 Jul 2009 13:44:12 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: stephen botzko References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> <4A6722F6.40903@octasic.com> <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> <20090722085309.146560cu5ffmjy79@mail.skype.net> <6e9223710907220913i6d129a67i659ace8676279026@mail.gmail.com> In-Reply-To: <6e9223710907220913i6d129a67i659ace8676279026@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 17:44:12.0962 (UTC) FILETIME=[066D8820:01CA0AF4] Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:46:09 -0000 stephen botzko wrote: > Assuming that participants have a stake (e.g. want their own proposals > to be accepted), One of the ideas which I (personally) hope we can achieve is a process that is more cooperative than competitive. If participants have no direct incentive (e.g. patent royalties) to get their technology in, it should be easier to achieve consensus on the result. > they will predictably argue for "rough consensus" to > relax requirements that their proposal might not meet, and for "strict > assessment" of requirements that they are sure they meet. Note also that having strict requirements decided before the standardisation process does not necessarily mean a better process. You might just end up with participants pushing these requirements in the direction of the technology they are planning on proposing later. > Though perhaps this could wait until after the BOF. I think it's OK to have some early discussions one the process now, but I agree that most of these process issues should be decided after the BoF. Cheers, Jean-Marc From stephen.botzko@gmail.com Wed Jul 22 11:07:15 2009 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 1132E3A6C25 for ; Wed, 22 Jul 2009 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.970, 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 AXZ1FOrmqfXB for ; Wed, 22 Jul 2009 11:07:14 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A9C5A3A6C0E for ; Wed, 22 Jul 2009 11:07:13 -0700 (PDT) Received: by fxm18 with SMTP id 18so359175fxm.37 for ; Wed, 22 Jul 2009 11:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O1aBvPkzMgFZd+6+Gr4lPaEWtPyjhFpVfVioayEzg14=; b=KBmrxt+HMLkqjfodrAlTz1u3DGlXhs4WD9BBSy/ZWsbW9d/u/H0rTTXLlwTeznuppM 5GnixR8/HUkYLs/2mnQeCSi5RmDYggWG3hWyxrtMuRlKQgOHJjaJOn6SE1097on5GC1f RGolQO8MgAKLoIFjOYePzpGlTVptbE2n2/S30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Iul4OfY/eqG+VqKgdtf/JepIu+EjtvHimlI8peZpUn6KD7e1vdVYALM4I2seiP2/y+ Pfgt9jpy++BjX7D4fS4u9HzEtTt9wFwycoJESLeiNb2crJlBRbbxbJa95Zwt/zxFqG8V Hhh24O7YsQxOmWU29gkfiF+XuhWsXDebh6RMY= MIME-Version: 1.0 Received: by 10.223.115.193 with SMTP id j1mr643734faq.98.1248285604272; Wed, 22 Jul 2009 11:00:04 -0700 (PDT) In-Reply-To: <4A674FEC.9090901@octasic.com> References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> <4A6722F6.40903@octasic.com> <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> <20090722085309.146560cu5ffmjy79@mail.skype.net> <6e9223710907220913i6d129a67i659ace8676279026@mail.gmail.com> <4A674FEC.9090901@octasic.com> Date: Wed, 22 Jul 2009 14:00:04 -0400 Message-ID: <6e9223710907221100l619fa872sf930ed2ba519fdfa@mail.gmail.com> From: stephen botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001636c5b8ef056940046f4f24bc Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:07:15 -0000 --001636c5b8ef056940046f4f24bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline- Stephen Botzko Polycom On Wed, Jul 22, 2009 at 1:44 PM, Jean-Marc Valin < jean-marc.valin@octasic.com> wrote: > stephen botzko wrote: > >> Assuming that participants have a stake (e.g. want their own proposals to >> be accepted), >> > > One of the ideas which I (personally) hope we can achieve is a process that > is more cooperative than competitive. If participants have no direct > incentive (e.g. patent royalties) to get their technology in, it should be > easier to achieve consensus on the result. Note the new charter has a different IPR statement from the original. Though I think indirect incentives can be just as powerful as direct ones. > > > they will predictably argue for "rough consensus" to relax requirements >> that their proposal might not meet, and for "strict assessment" of >> requirements that they are sure they meet. >> > > Note also that having strict requirements decided before the > standardisation process does not necessarily mean a better process. You > might just end up with participants pushing these requirements in the > direction of the technology they are planning on proposing later. I agree that participants would do precisely that. Though it is perhaps more efficient to have that discussion up front, and not allow it to be re-visited at the end. > > > Though perhaps this could wait until after the BOF. >> > > I think it's OK to have some early discussions one the process now, but I > agree that most of these process issues should be decided after the BoF. > > Cheers, > > Jean-Marc > --001636c5b8ef056940046f4f24bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline-
Stephen Botzko
Polycom

On W= ed, Jul 22, 2009 at 1:44 PM, Jean-Marc Valin <jean-marc.valin@octasic.com>= wrote:
stephen botzko wrote:
Assuming that participants have a stake (e.g. want their own proposals to b= e accepted),

One of the ideas which I (personally) hope we can achieve is a process that= is more cooperative than competitive. If participants have no direct incen= tive (e.g. patent royalties) to get their technology in, it should be easie= r to achieve consensus on the result.
=A0
Note the new charter has a different IPR statement from = the original. Though I think indirect incentives can be just as powerful as= direct ones.


they will predictably argue for "rough consensus" to relax requir= ements that their proposal might not meet, and for "strict assessment&= quot; of requirements that they are sure they meet.

Note also that having strict requirements decided before the standardisatio= n process does not necessarily mean a better process. You might just end up= with participants pushing these requirements in the direction of the techn= ology they are planning on proposing later.
=A0
=A0I agree that participants would do precisely that.=A0= Though it is perhaps more efficient to have that discussion up front, and = not allow it to be re-visited at the end.


Though perhaps this could wait until after the BOF.

I think it's OK to have some early discussions one the process now, but= I agree that most of these process issues should be decided after the BoF.=

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

--001636c5b8ef056940046f4f24bc-- From koen.vos@skype.net Wed Jul 22 15:52:43 2009 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 C2B4528C13E for ; Wed, 22 Jul 2009 15:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 VZWHZ-o75j3k for ; Wed, 22 Jul 2009 15:52:42 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 2CB873A67F3 for ; Wed, 22 Jul 2009 15:52:42 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0BE222007C235; Wed, 22 Jul 2009 17:53:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=OnfrqWuifo3x A8cK3mPDVpssaVY=; b=ruDZ/Z6/rIvO/5e2RKX2+tvsPoGRLrDdUDYHdb1g/OIj F5Moh7Gn+2gXE2NNvy2GUW56qW2HC2M0RkTwqZs5jP2/uEJDRcR5DgtvSa5hrYP6 XxTkRH/+FnCxt4vqD3jivw69KRufnQJqN4mG/j1n+JlxTjgsm6XRp0L9coPVodw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=tAR7vHigKpGD1tsJ7Nh0 36c2mIb7XJlkUELIZfK+96sVQnp+9Eg/SKNfsobTo0UisC3tv9FkbYaX6o1d6XXG 7mH2H8BECdtVIcjFSaIipXtLj+zQGqYH8fyjxrG/0F9rEO0QC0j+BrmRqhgc6iF0 OdQ29l3WD0dzja3Mj0Gr9Wk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0A1682007AC4C; Wed, 22 Jul 2009 17:53:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq6g4Ewd7soY; Wed, 22 Jul 2009 17:53:09 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C81A22007C1BD; Wed, 22 Jul 2009 17:53:09 +0200 (CEST) Received: from 84-55-127-131.customers.ownit.se (84-55-127-131.customers.ownit.se [84.55.127.131]) by mail.skype.net (Horde Framework) with HTTP; Wed, 22 Jul 2009 08:53:09 -0700 Message-ID: <20090722085309.146560cu5ffmjy79@mail.skype.net> Date: Wed, 22 Jul 2009 08:53:09 -0700 From: Koen Vos To: stephen botzko References: <6e9223710907171321h2f6ca49bu50a689eabe492e25@mail.gmail.com> <6e9223710907171749r6a7bdce5r51e833e963eab5a6@mail.gmail.com> <4A615A48.5040300@coppice.org> <6e9223710907180343s72c54f0xb21cc52dcaf06d72@mail.gmail.com> <20090718061359.13046nca2lhexuhj@mail.skype.net> <4A61D18A.7040201@usherbrooke.ca> <4A628E0E.6090100@coppice.org> <00dc01ca0ac9$b04b2760$c646c80a@china.huawei.com> <4A6722F6.40903@octasic.com> <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> In-Reply-To: <6e9223710907220753h5a28fa5bh6a24004b0c697f9e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Revised Draft Charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:52:43 -0000 Agree that rough consensus for complexity evaluation may not work when comparing very similar candidates. However, there is a good chance that either there won't be very similar candidates, or the similar candidates will all be deemed to have acceptable complexity. If that happens, the rough consensus approach will have saved us a large amount of work. On the other hand, if we do run into a problem, we can -through rough consensus- create a detailed WMOPS requirement at that stage. I see the difference in approach as "waterfall" versus "agile". koen. Quoting stephen botzko : > The benefit of measured complexity is that it provides a precise definition > of the requirement that can be tested. Even if it does not exactly map onto > a given processor, this can still be useful. > > For instance, if you have two codec candidates, using a "rough consensus" > will make it very hard to reject one of them on the grounds that it doesn't > meet the complexity requirement. My guess is that the result will either be > that complexity gradually creeps upwards, or that "rough consensus" will not > be achieved, totally blocking progress. > > More generally, if you use a process where multiple codec candidates are > considered, "rough consensus" is not efficient - it is likely to be > unachievable if a significant fraction of the WG participants have > candidates in play. This would be likely true even if the "signficant > fraction" is < 50%. > > Regards, > Stephen Botzko > Polycom > > > On Wed, Jul 22, 2009 at 10:32 AM, Jean-Marc Valin < > jean-marc.valin@octasic.com> wrote: > >> Hi Herve, >> >> (contributor hat on) >> >> My earlier comments were based on the version of the basic ops that I saw >> in many standards (and assuming there was just one WMOPS definition). I was >> not aware that these operators had been "recently" revised. Thanks for >> pointing those out. I agree that the revised version makes more sense and is >> closer to the a 32-bit DSP. I still see a few issues with STL2005 (e.g. lack >> of unsigned add/sub), but they are relatively minor compared to the older >> version. >> >> That being said, I still consider that there are fundamental limitations to >> the WMOPS *approach*, caused by differences in DSP/CPU architectures. For >> example, many (all?) ARM cores do not have saturating operators. When it >> comes to conditional branches, some architectures will pay a fixed price for >> a branch taken, while others (e.g. x86) will have virtually no cost for an >> easily predicted branch and a huge cost for a branch on "random" data. In >> the end, WMOPS will give you a rough idea of the complexity, but I believe >> it is preferable to use rough consensus (possibly backed by some benchmarks) >> to ultimately decide on what's acceptable. >> >> Cheers, >> >> Jean-Marc >> >> Herve Taddei wrote: >> >>> Dear Jean Marc and Steve, >>> >>> >>> Let me correct some statements made on the WMOPS counting as it seems to >>> me they are either wrong or you are not looking to the tool we are used to >>> have. So I am not sure your comments are based on G.191, if that is the >>> case, I have asked someone heavily involved in the design of ITU-T G.191 to >>> answer some of your points. >>> >>> >>> >>>> > * it forces you to code the fixed-point in a certain way (e.g. >>>> >>> >>> > fractional vs interger multiply); >>>> >>> >>> In general, in order to "automate" the evaluation of the complexity of an >>> algorithm on a family of processor architectures, the fixed point >>> code needs >>> to be written in certain ways. If evaluating the complexity of a >>> codec is an >>> important factor in the standardisation process, then such coding >>> guidelines >>> should be agreed by the various parties involved in the standardisation. >>> W/ regards to fractional vs interger multiply : ITU STL 2000 supports few >>> integer multiplication (L mult0, L_mac0, L_msu0). It is true that the >>> variety & numbers of fractional multiplication operators vs integer >>> multiplication operators is not equal. From historical point of view, the >>> "fractional" multiplication was priviledged. In 2003 (in preparation of >>> STL2005), there was a proposal to widen the set of integer multiplication >>> while taking care of well counting the integer/fractional multiplication >>> mode switch that may be needed on some processors. This discussion was not >>> carried on forward. >>> >>> >>> >>>> > * it's designed for a 16-bit (TI) DSP and is not very respresentative >>>> of >>>> >>> >>> > modern 32-bit DSPs. For example, a 32-bit add costs more than a MAC; >>>> >>> >>> 1st of all, I don't believe that the STL2005 is designed for a TI DSP. For >>> example, during the STL2005 design process STM inputs were factored in, >>> among others on the reflector. >>> Then, with regards to 32b add, in STL2005, L_add complexity weight is 1 >>> (same as L_mac). >>> >>> Now, in a more general statement, is the STL a basic operator library >>> representing more a 16b or 32b processor ? If I look at the STl2005 list of >>> operators which have a complexity > 1, I believe we fall in those >>> categories >>> : >>> - add / subtract with carry bit. >>> - shift and round. >>> - integer multiplication with truncation to 16 lsbs (reflects indeed that >>> STL is historically fractional based). >>> - bit rotation operation >>> - high precision 32x16 and 32x32 multiplication (requires 40b STL >>> headers). >>> >>> I believe that with the renewed complexity weights made in 2005, the STL >>> is closer to a 32b processor than a 16b processor to the exception of the >>> 32x32b multiplication which is not having a complexity of 1 ... but of 4 >>> (Mpy 32 32 ss inside the 40b lib). >>> >>> >>> >>>> > * it completely ignore issues such as conditional branches, which can >>>> be >>>> >>> >>> > more important than arithmetic operations on modern architectures; >>>> >>> >>> This is incorrect, with STL2005, control operation complexity count is >>> supported. >>> Any improvement suggestions welcomed to be discussed. >>> >>> >>> >>>> Also, the ITU approach only tries to get an instruction count for the >>>> >>> fixed point implementations. >>> >>> The floating point computational complexity is also very important >>>> >>> these days. >>> >>> I think this is not correct as floating point implementation counters were >>> proposed in ITU-T (from VoiceAge actually) and have been used in many >>> standardization exercises for reporting floating point complexity. >>> >>> >>> Best regards >>> >>> >>> Herve >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 jean-marc.valin@octasic.com Fri Jul 24 07:15:31 2009 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 7F8EB28C1CE for ; Fri, 24 Jul 2009 07:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 Tf-WGUGolfCc for ; Fri, 24 Jul 2009 07:15:30 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 410E23A6B49 for ; Fri, 24 Jul 2009 07:15:29 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 09:41:02 -0400 Message-ID: <4A69B9EE.8030806@octasic.com> Date: Fri, 24 Jul 2009 09:41:02 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2009 13:41:02.0285 (UTC) FILETIME=[628867D0:01CA0C64] Subject: [codec] draft-valin-celt-codec-01.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:15:31 -0000 Hi everyone, Just a note about the agenda at http://www.ietf.org/proceedings/75/agenda/codec.txt It still points to the initial CELT draft, which has been replaced by: http://www.ietf.org/id/draft-valin-celt-codec-01.txt I didn't announce it because all it had was a few minor source code changes. Jean-Marc From petithug@acm.org Fri Jul 24 07:55:19 2009 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 6447828C1C7 for ; Fri, 24 Jul 2009 07:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 fg-+97OyyhMv for ; Fri, 24 Jul 2009 07:55:18 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 7BC7F28C1F9 for ; Fri, 24 Jul 2009 07:54:33 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id C25FC15BC4016; Fri, 24 Jul 2009 14:54:33 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 22A0415BC4014 for ; Fri, 24 Jul 2009 14:54:33 +0000 (UTC) Message-ID: <4A69CB27.9060904@acm.org> Date: Fri, 24 Jul 2009 07:54:31 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [codec] Support for the codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:55:19 -0000 I am writing this as a potential user and implementer of an Internet patent free audio codec in a widely distributed situation. Unfortunately, I won't be able to attend the Stockholm meeting. I am in favor of the creation of a codec WG and, even if some of my arguments for it may have been heard before, it may not be completely useless to state them again: * Even if there has been some discussion about 'what is an internet codec' and whether existing codecs may fit, or not, such a definition, I think it is quite necessary to address the issue head first, at least to establish what would be so specific about it, and possibly to develop (a) codec(s) which address such specificity. One such specificity, and an important one, IMHO, is multicast and its possible applications. One necessity of multicast is congestion control, and this in turn calls for layered encoding, something which hasn't been thoroughly investigated before, I think. Even if it is sometime possible, for some codecs, to add partial support for this when designing the RTP transport (e.g. layered encoding for bandwidth extension, but not for quality improvements or added channels), I think it would be much better to design the codec with that option in mind from the beginning. Along the same lines, I tend to think that the design should go from Internet specificities (not only in terms of packet loss, delay, throughput etc. but also in terms of [possible] usage) to the requirements: input from the internet community, as much as audio expertise is needed, and that's why IETF is, in my opinion, the correct place. * My usage of this audio codec supporting layered encoding would be for a future free software project. Because it is free software, the codec needs to be patent free or royalty free, which excludes G.718. I understand that the IETF does not mandate this, but I am wondering if a specific WG can choose to impose more restrictive rules (for example, the dnsext WG requests the commitment of 5 people before accepting a document as WG item). * I think there is already a consensus that the audio expertise to develop an audio codec here exists. Even if the IETF does not have a history of designing codecs, I can't think that historic legacy is a valid argument against it. On the contrary, there are examples where applying a fresh perspective to a domain traditionally reserved was a good thing, for example FOSS vs traditional development or Apple iPhone vs traditional cellphone companies. Anyway if the WG is created and work on a codec which fulfills my requirements, I will develop and publish under a free software license an independent reference implementation for interoperability verification purposes and provide comment and reviews based on this implementation. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From Andrew@spiritdsp.com Sun Jul 26 13:37:36 2009 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 689DF3A6BAD; Sun, 26 Jul 2009 13:37:36 -0700 (PDT) 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 DV3S-+4E9Zm3; Sun, 26 Jul 2009 13:37:34 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 888663A698C; Sun, 26 Jul 2009 13:37:33 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6QKbWOv075788; Mon, 27 Jul 2009 00:37:33 +0400 (MSD) (envelope-from Andrew@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 00:40:05 +0400 Message-ID: In-Reply-To: <4A5777DB.4080400@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoBgnF5vBFx/FGmTgCDU0EtNN3J4QMqWJ3g References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> From: "Andrew Sviridenko" To: , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 X-Mailman-Approved-At: Sun, 26 Jul 2009 14:44:35 -0700 Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 20:41:11 -0000 Dear all- SPIRIT DSP is interested to contribute to the IETF codec WG / BOF, and present our IPMR wideband codec on July 30, along with SILK. During the last 17 years (since 1992) SPIRIT DSP speech experts designed and developed several proprietary codecs actually deployed by many global leading telecom OEMs and semiconductor vendors- http://www.spiritdsp.com/customers/ SPIRIT IPMR is multi-rate, scalable, adaptive, wideband codec specifically designed for IP-based communications several years ago- WGLC on draft-ietf-avt-rtp-ipmr-04 SPIRIT IPMR is- - multi-rate, scalable, adaptive, wideband codec, - low latency, - delivers generally better voice quality than Speex, - robust to packet loss, - we have both PC and mobile (low MIPS) implementations, - licensed and deployed by many leading companies, including Adobe and Oracle, as well as multiple Asia-based telecom operators and telecom OEMs, - patent-free, - payload already submitted to IETF. SPIRIT would like to contribute to the codec WG / BOF of IETF, and help create wideband codec standard for IP-communications and global voice interoperability. We can open-source SPIRIT IPMR if needed to make it part of the standard. We are also open to partner with bigger companies in this group if needed to make IPMR codec part of the standard. Please let us present our SPIRIT IPMR wideband codec on July 30, along with SILK. Slava Borilin from SPIRIT DSP will join the WG / BOF. Thank you, Andrew Sviridenko SPIRIT DSP, www.spiritDSP.com, Voice & Video Engine Experts =20 -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 Sent: Friday, July 10, 2009 9:18 PM To: Roni Even Cc: 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin; codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/09 10:43 AM, Roni Even wrote: > Hi, > I still fail to see what is the value in presenting one, two or three > codecs.=20 Present them as existence proofs (yes, we can!) and provide lessons learned as input to the kind of work that a Codec WG would pursue. We need to know that it is within the realm of possibility for a Codec WG to be successful. > I saw that there was a request to present a third one.=20 Which? > I can agree that there are people who can present codecs as a suggested > solution including existing ones.=20 No. As far as I can see these are *not* suggested solutions. The point is show that we have the expertise within the IETF to pursue this work, to learn how those codecs were developed, and to judge whether we think even better codecs could be developed by a Codec WG. > Since there is no charter yet under which > the codecs are to be specified it may serve as a tutorial on codecs.=20 Given that the IETF has not traditionally been home to codec work, I think that a very brief tutorial on what's involved in such work would be quite beneficial. > So if > we open to codec presentation in the BOF let allow everyone to present their > codecs including ITU and MPEG ones and spend the whole BOF of the different > codecs technologies.=20 Don't be ridiculous. Two or three proof points should be plenty. > If the idea behind this presentation is to show specific functionality I don't think that's the idea. > than > instead it will be more fruitful to present requirements, since I could see > from the list discussion that there is no consensus even between the current > proponents what the requirements are. Discussion of existence proofs and lessons learned from previous codec work is not at odds with discussion of requirements. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXd9sACgkQNL8k5A2w/vzbdwCgxU2s6pjxTWp67WE30oJd/s1F L6AAn3s7EmSR3aDYrX0Pz79Rnjc36oVm =3D8ctr -----END PGP SIGNATURE----- From ingemar.s.johansson@ericsson.com Mon Jul 27 01:38:19 2009 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 B33F528C23B for ; Mon, 27 Jul 2009 01:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 mHkWO6ZeBjsJ for ; Mon, 27 Jul 2009 01:38:19 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id ABC0C28C23A for ; Mon, 27 Jul 2009 01:38:18 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-6d-4a6d677ad6c0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 9B.30.18827.A776D6A4; Mon, 27 Jul 2009 10:38:18 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:37:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 10:37:58 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for the Codec Bof Thread-Index: AcoOlYt00RGHhNwjS0+JGBtJN/+cTw== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 27 Jul 2009 08:37:59.0707 (UTC) FILETIME=[8C1C6EB0:01CA0E95] X-Brightmail-Tracker: AAAAAA== Subject: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:38:19 -0000 Hi I am a bit curious regarding the agenda for the codec BoF Is this the latest ? http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs = and instead focus on the question "should IETF do this?" Regards /Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVK - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From herve.taddei@huawei.com Mon Jul 27 01:47:56 2009 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 4251928C22B for ; Mon, 27 Jul 2009 01:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=1.084, 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 GEZrl0qd5I4J for ; Mon, 27 Jul 2009 01:47:55 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 3C8FB28C1D7 for ; Mon, 27 Jul 2009 01:47:55 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNF00BINN3SAW@lhrga02-in.huawei.com> for codec@ietf.org; Mon, 27 Jul 2009 09:47:53 +0100 (BST) Received: from PCHERVE ([10.200.70.148]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNF00GE8N3RGG@lhrga02-in.huawei.com> for codec@ietf.org; Mon, 27 Jul 2009 09:47:52 +0100 (BST) Date: Mon, 27 Jul 2009 10:47:51 +0200 From: Herve Taddei In-reply-to: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> To: 'Ingemar Johansson S' , codec@ietf.org Message-id: <000b01ca0e96$ed294ab0$9446c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Thread-index: AcoOlYt00RGHhNwjS0+JGBtJN/+cTwAARsWA References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:47:56 -0000 Dear Ingemar, All, I have not been on vacation yet, and you are right, I don=92t think the = agenda reflects the discussions/concerns raised by many people on the email = list. I am also a bit surprised. Best regards, Herv=E9 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Ingemar Johansson S > Sent: Monday, July 27, 2009 10:38 AM > To: codec@ietf.org > Subject: [codec] Agenda for the Codec Bof >=20 > Hi >=20 > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (false?) > impression that it was not the intention to present any codecs and = instead focus on > the question "should IETF do this?" >=20 >=20 > Regards > /Ingemar >=20 > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Mon Jul 27 01:52:55 2009 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 4606628C24D for ; Mon, 27 Jul 2009 01:52:55 -0700 (PDT) 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 BeC96VG0K9Ud for ; Mon, 27 Jul 2009 01:52:54 -0700 (PDT) Received: from idefix.homelinux.org (dhcp-160f.meeting.ietf.org [130.129.22.15]) by core3.amsl.com (Postfix) with ESMTP id CE8D928C250 for ; Mon, 27 Jul 2009 01:52:49 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTPS id 10750509840; Mon, 27 Jul 2009 10:52:49 +0200 (CEST) Message-ID: <4A6D6AD0.30504@usherbrooke.ca> Date: Mon, 27 Jul 2009 10:52:32 +0200 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:52:55 -0000 Hi, Indeed, the link has not been updated. The updated agenda was posted here: http://www.ietf.org/mail-archive/web/codec/current/msg00241.html Regards, Jean-Marc Ingemar Johansson S a écrit : > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (false?) impression that it was not the intention to present any codecs and instead focus on the question "should IETF do this?" > > > Regards > /Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Luleå, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From magnus.westerlund@ericsson.com Mon Jul 27 01:53:08 2009 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 583B428C250 for ; Mon, 27 Jul 2009 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=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 EV3WZHvs896i for ; Mon, 27 Jul 2009 01:53:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C3CF528C262 for ; Mon, 27 Jul 2009 01:53:05 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-3c-4a6d6af199da Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8B.D9.00514.1FA6D6A4; Mon, 27 Jul 2009 10:53:05 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:52:51 +0200 Received: from [153.88.48.250] ([153.88.48.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:52:51 +0200 Message-ID: <4A6D6AE3.9080202@ericsson.com> Date: Mon, 27 Jul 2009 10:52:51 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Jul 2009 08:52:51.0221 (UTC) FILETIME=[9F7EAC50:01CA0E97] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:53:08 -0000 Ingemar Johansson S skrev: > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (false?) impression that it was not the intention to present any codecs and instead focus on the question "should IETF do this?" Please do look at the official agenda: http://www.ietf.org/proceedings/75/agenda/codec.txt Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ingemar.s.johansson@ericsson.com Mon Jul 27 01:56:17 2009 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 A780C28C1BD for ; Mon, 27 Jul 2009 01:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_SE=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 9RVchnMYZMmu for ; Mon, 27 Jul 2009 01:56:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9AD7028C196 for ; Mon, 27 Jul 2009 01:56:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-67-4a6d6bb0cabd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5B.2A.00514.0BB6D6A4; Mon, 27 Jul 2009 10:56:16 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:56:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 10:56:15 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018EC0E1@esealmw109.eemea.ericsson.se> In-Reply-To: <4A6D6AE3.9080202@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOl59ZGTUUUcv7QSKwWi4yiOB+7AAAHNlA References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AE3.9080202@ericsson.com> From: "Ingemar Johansson S" To: "Magnus Westerlund" X-OriginalArrivalTime: 27 Jul 2009 08:56:16.0537 (UTC) FILETIME=[19DF6890:01CA0E98] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:56:17 -0000 OK Thanks! /Ingemar=20 > -----Original Message----- > From: Magnus Westerlund=20 > Sent: den 27 juli 2009 10:53 > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof >=20 > Ingemar Johansson S skrev: > > Hi > >=20 > > I am a bit curious regarding the agenda for the codec BoF=20 > Is this the=20 > > latest ? > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > I have probably missed a lot as I have been on vacation but=20 > I got the (false?) impression that it was not the intention=20 > to present any codecs and instead focus on the question=20 > "should IETF do this?" >=20 > Please do look at the official agenda: >=20 > http://www.ietf.org/proceedings/75/agenda/codec.txt >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From herve.taddei@huawei.com Mon Jul 27 03:12:56 2009 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 144E83A6C2A for ; Mon, 27 Jul 2009 03:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 tSlfsPZ37xz7 for ; Mon, 27 Jul 2009 03:12:55 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 1E5F83A6C05 for ; Mon, 27 Jul 2009 03:12:55 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNF00BN6R1EAW@lhrga02-in.huawei.com> for codec@ietf.org; Mon, 27 Jul 2009 11:12:50 +0100 (BST) Received: from PCHERVE ([10.200.70.148]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNF00GFIR1DGG@lhrga02-in.huawei.com> for codec@ietf.org; Mon, 27 Jul 2009 11:12:50 +0100 (BST) Date: Mon, 27 Jul 2009 12:12:50 +0200 From: Herve Taddei In-reply-to: <4A6D6AD0.30504@usherbrooke.ca> To: 'Jean-Marc Valin' , 'Ingemar Johansson S' Message-id: <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Thread-index: AcoOmK33VF8HJD14Tveo8vq7s5ABSwABd8OA References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 10:12:56 -0000 Dear Jean Marc, Indeed the agenda was changed, but still the introduction of codecs is there. Best regards, Herv=E9 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Jean-Marc Valin > Sent: Monday, July 27, 2009 10:53 AM > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof >=20 > Hi, >=20 > Indeed, the link has not been updated. The updated agenda was posted = here: > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html >=20 > Regards, >=20 > Jean-Marc >=20 > Ingemar Johansson S a =E9crit : > > Hi > > > > I am a bit curious regarding the agenda for the codec BoF > > Is this the latest ? > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > I have probably missed a lot as I have been on vacation but I got = the (false?) > impression that it was not the intention to present any codecs and = instead focus on > the question "should IETF do this?" > > > > > > Regards > > /Ingemar > > > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVK - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > 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 ingemar.s.johansson@ericsson.com Mon Jul 27 06:44:04 2009 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 64ADA3A6836 for ; Mon, 27 Jul 2009 06:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=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 PXyWpHdt9yMD for ; Mon, 27 Jul 2009 06:44:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 097633A6C75 for ; Mon, 27 Jul 2009 06:43:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-a6-4a6daf0d3ee3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BB.BF.20893.D0FAD6A4; Mon, 27 Jul 2009 15:43:41 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 15:43:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 15:43:40 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> In-Reply-To: <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOmK33VF8HJD14Tveo8vq7s5ABSwABd8OAAAgR+uA= References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> From: "Ingemar Johansson S" To: "Herve Taddei" , "Jean-Marc Valin" X-OriginalArrivalTime: 27 Jul 2009 13:43:41.0566 (UTC) FILETIME=[40B601E0:01CA0EC0] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:44:04 -0000 Hi I believe that I have expressed earlier that I don't believe that a = description of particular codecs gives any additional value, = speech/audio coding is a very specialized area and going beyond a = descripion of a few "black boxes" in 25 minutes is probably more than = the average newbie can digest. This is of course my personal opinion and = if you believe that it is important to have his then I respect it. Regards Ingemar > -----Original Message----- > From: Herve Taddei [mailto:herve.taddei@huawei.com]=20 > Sent: den 27 juli 2009 12:13 > To: 'Jean-Marc Valin'; Ingemar Johansson S > Cc: codec@ietf.org > Subject: RE: [codec] Agenda for the Codec Bof >=20 > Dear Jean Marc, >=20 > Indeed the agenda was changed, but still the introduction of=20 > codecs is there. >=20 > Best regards, > Herv=E9 >=20 >=20 >=20 > > -----Original Message----- > > From: codec-bounces@ietf.org=20 > [mailto:codec-bounces@ietf.org] On Behalf=20 > > Of Jean-Marc Valin > > Sent: Monday, July 27, 2009 10:53 AM > > To: Ingemar Johansson S > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > >=20 > > Hi, > >=20 > > Indeed, the link has not been updated. The updated agenda=20 > was posted here: > > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > >=20 > > Regards, > >=20 > > Jean-Marc > >=20 > > Ingemar Johansson S a =E9crit : > > > Hi > > > > > > I am a bit curious regarding the agenda for the codec BoF Is this=20 > > > the latest ? > > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > > I have probably missed a lot as I have been on vacation but I got=20 > > > the > (false?) > > impression that it was not the intention to present any codecs and=20 > > instead > focus on > > the question "should IETF do this?" > > > > > > > > > Regards > > > /Ingemar > > > > > > ******************************************* > > > Ingemar Johansson > > > Senior Research Engineer, IETF "nethead" > > > EAB/TVK - Multimedia Technologies > > > Ericsson Research Ericsson AB > > > Box 920 S-971 28 Lule=E5, Sweden > > > Tel: +46 (0)10 7143042 > > > ECN: 852-43042 > > > ECC: 852-19042 > > > Mobile: +46 (0)730 783289 > > > Visit http://labs.ericsson.com ! > > > ******************************************* > > > _______________________________________________ > > > 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 >=20 >=20 From patrick.luthi@tandberg.no Mon Jul 27 06:57:14 2009 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 B4DF428C166 for ; Mon, 27 Jul 2009 06:57:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xc8cxn3Y5pj for ; Mon, 27 Jul 2009 06:57:13 -0700 (PDT) Received: from smtp-03.vtx.ch (smtp-03.vtx.ch [212.147.0.64]) by core3.amsl.com (Postfix) with ESMTP id 331BC3A6C43 for ; Mon, 27 Jul 2009 06:57:13 -0700 (PDT) Received: from suisse127.vtxnet.ch (dhcp-23fa.meeting.ietf.org [130.129.35.250]) (Authenticated sender: vtxnet.pluthi) by smtp-03.vtx.ch (VTX Services SA) with ESMTP id 75DB0296D80; Mon, 27 Jul 2009 15:57:13 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jul 2009 15:57:05 +0200 To: "Ingemar Johansson S" , "Herve Taddei" , "Jean-Marc Valin" From: Patrick Luthi In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea. ericsson.se> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <20090727135713.75DB0296D80@smtp-03.vtx.ch> Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:57:14 -0000 Hi, I am surprised to still see codecs listed in item=20 4 of the agenda. As I said before I think that it=20 would be best to have more time to discuss the=20 other items of the agenda. So, please remove the=20 codec presentations from the agenda! Regards, Patrick At 15:43 27/07/2009, Ingemar Johansson S wrote: >Hi > >I believe that I have expressed earlier that I=20 >don't believe that a description of particular=20 >codecs gives any additional value, speech/audio=20 >coding is a very specialized area and going=20 >beyond a descripion of a few "black boxes" in 25=20 >minutes is probably more than the average newbie=20 >can digest. This is of course my personal=20 >opinion and if you believe that it is important to have his then I respect= it. > >Regards >Ingemar > > > > -----Original Message----- > > From: Herve Taddei [mailto:herve.taddei@huawei.com] > > Sent: den 27 juli 2009 12:13 > > To: 'Jean-Marc Valin'; Ingemar Johansson S > > Cc: codec@ietf.org > > Subject: RE: [codec] Agenda for the Codec Bof > > > > Dear Jean Marc, > > > > Indeed the agenda was changed, but still the introduction of > > codecs is there. > > > > Best regards, > > Herv=E9 > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org > > [mailto:codec-bounces@ietf.org] On Behalf > > > Of Jean-Marc Valin > > > Sent: Monday, July 27, 2009 10:53 AM > > > To: Ingemar Johansson S > > > Cc: codec@ietf.org > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > Hi, > > > > > > Indeed, the link has not been updated. The updated agenda > > was posted here: > > > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > > > > > Regards, > > > > > > Jean-Marc > > > > > > Ingemar Johansson S a =E9crit : > > > > Hi > > > > > > > > I am a bit curious regarding the agenda for the codec BoF Is this > > > > the latest ? > > > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > > > I have probably missed a lot as I have been on vacation but I got > > > > the > > (false?) > > > impression that it was not the intention to present any codecs and > > > instead > > focus on > > > the question "should IETF do this?" > > > > > > > > > > > > Regards > > > > /Ingemar > > > > > > > > ******************************************* > > > > Ingemar Johansson > > > > Senior Research Engineer, IETF "nethead" > > > > EAB/TVK - Multimedia Technologies > > > > Ericsson Research Ericsson AB > > > > Box 920 S-971 28 Lule=E5, Sweden > > > > Tel: +46 (0)10 7143042 > > > > ECN: 852-43042 > > > > ECC: 852-19042 > > > > Mobile: +46 (0)730 783289 > > > > Visit http://labs.ericsson.com ! > > > > ******************************************* > > > > _______________________________________________ > > > > 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 > > > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Mon Jul 27 07:01:08 2009 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 B506128C1F6 for ; Mon, 27 Jul 2009 07:01:08 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnSEL6oXBfBh for ; Mon, 27 Jul 2009 07:01:07 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 1F7A328C172 for ; Mon, 27 Jul 2009 07:01:00 -0700 (PDT) Received: from hoeneLenovoT60 (c155.a98.sto.bahnhof.net [213.80.98.155] (may be forged)) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6RE0oY9027021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jul 2009 16:00:59 +0200 From: "Christian Hoene" To: "'Patrick Luthi'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> In-Reply-To: <20090727135713.75DB0296D80@smtp-03.vtx.ch> Date: Mon, 27 Jul 2009 16:00:50 +0200 Message-ID: <002a01ca0ec2$ab85fe10$0291fa30$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoOwi8XxIsw1C7UTNSUe9FVyTl+AAAAC0xg Content-language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.228; VDF: 7.1.5.32; host: mx05); id=8352-SmPvv8 Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:01:08 -0000 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Patrick Luthi > Sent: Monday, July 27, 2009 3:57 PM > To: Ingemar Johansson S; Herve Taddei; Jean-Marc Valin > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof >=20 Hi, > I am surprised to still see codecs listed in item > 4 of the agenda. As I said before I think that it > would be best to have more time to discuss the > other items of the agenda. So, please remove the > codec presentations from the agenda! I support this request. Regards, Christian >=20 > Regards, >=20 > Patrick >=20 > At 15:43 27/07/2009, Ingemar Johansson S wrote: > >Hi > > > >I believe that I have expressed earlier that I > >don't believe that a description of particular > >codecs gives any additional value, speech/audio > >coding is a very specialized area and going > >beyond a descripion of a few "black boxes" in 25 > >minutes is probably more than the average newbie > >can digest. This is of course my personal > >opinion and if you believe that it is important to have his then I respect > it. > > > >Regards > >Ingemar > > > > > > > -----Original Message----- > > > From: Herve Taddei [mailto:herve.taddei@huawei.com] > > > Sent: den 27 juli 2009 12:13 > > > To: 'Jean-Marc Valin'; Ingemar Johansson S > > > Cc: codec@ietf.org > > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > Dear Jean Marc, > > > > > > Indeed the agenda was changed, but still the introduction of > > > codecs is there. > > > > > > Best regards, > > > Herv=E9 > > > > > > > > > > > > > -----Original Message----- > > > > From: codec-bounces@ietf.org > > > [mailto:codec-bounces@ietf.org] On Behalf > > > > Of Jean-Marc Valin > > > > Sent: Monday, July 27, 2009 10:53 AM > > > > To: Ingemar Johansson S > > > > Cc: codec@ietf.org > > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > > > Hi, > > > > > > > > Indeed, the link has not been updated. The updated agenda > > > was posted here: > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > > > > > > > Regards, > > > > > > > > Jean-Marc > > > > > > > > Ingemar Johansson S a =E9crit : > > > > > Hi > > > > > > > > > > I am a bit curious regarding the agenda for the codec BoF Is = this > > > > > the latest ? > > > > > = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > > > > I have probably missed a lot as I have been on vacation but I = got > > > > > the > > > (false?) > > > > impression that it was not the intention to present any codecs = and > > > > instead > > > focus on > > > > the question "should IETF do this?" > > > > > > > > > > > > > > > Regards > > > > > /Ingemar > > > > > > > > > > ******************************************* > > > > > Ingemar Johansson > > > > > Senior Research Engineer, IETF "nethead" > > > > > EAB/TVK - Multimedia Technologies > > > > > Ericsson Research Ericsson AB > > > > > Box 920 S-971 28 Lule=E5, Sweden > > > > > Tel: +46 (0)10 7143042 > > > > > ECN: 852-43042 > > > > > ECC: 852-19042 > > > > > Mobile: +46 (0)730 783289 > > > > > Visit http://labs.ericsson.com ! > > > > > ******************************************* > > > > > _______________________________________________ > > > > > 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 > > > > > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hsinnrei@adobe.com Mon Jul 27 08:17:11 2009 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 A56AF28C211 for ; Mon, 27 Jul 2009 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vwMT28MZbKu for ; Mon, 27 Jul 2009 08:17:10 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 1707428C22A for ; Mon, 27 Jul 2009 08:17:10 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSm3E2D6LOMeB7Q6gMNDp+VEgmRCCt8oD@postini.com; Mon, 27 Jul 2009 08:17:11 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6RFA9ao016043; Mon, 27 Jul 2009 08:10:10 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6RFGdiq015439; Mon, 27 Jul 2009 08:16:39 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 27 Jul 2009 08:16:39 -0700 From: Henry Sinnreich To: Jean-Marc Valin , Ingemar Johansson S Date: Mon, 27 Jul 2009 08:16:37 -0700 Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOl6YHrLG2kzKFTK+c7oQiNh5vNwANZXmy Message-ID: In-Reply-To: <4A6D6AD0.30504@usherbrooke.ca> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6939175EEA6hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:17:11 -0000 --_000_C6939175EEA6hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The hum item is not fair nor representative IMO, since it favors people who= have a travel budget. >7. HUM on if the IETF should form this WG (All, 15 min) I would like to understand how/why the hum is representative for the Intern= et industry, since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs. My personal 2 cents. Henry On 7/27/09 10:52 AM, "Jean-Marc Valin" wro= te: Hi, Indeed, the link has not been updated. The updated agenda was posted here: http://www.ietf.org/mail-archive/web/codec/current/msg00241.html Regards, Jean-Marc Ingemar Johansson S a =E9crit : > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (fa= lse?) impression that it was not the intention to present any codecs and in= stead focus on the question "should IETF do this?" > > > Regards > /Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > 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 --_000_C6939175EEA6hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Agenda for the Codec Bof The hum item is not fair nor representative IMO, since it favors peop= le who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry


On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= BR> http://www.ietf.org/mail-archive/web/codec/current/msg00241.html

Regards,

        Jean-Marc

Ingemar Johansson S a écrit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and= instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6939175EEA6hsinnreiadobecom_-- From stephen.botzko@gmail.com Mon Jul 27 08:17:38 2009 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 2D5F428C1A3 for ; Mon, 27 Jul 2009 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.873, 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 xoZn811dEX0Y for ; Mon, 27 Jul 2009 08:17:36 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 46B0528C16B for ; Mon, 27 Jul 2009 08:17:36 -0700 (PDT) Received: by fxm18 with SMTP id 18so2663438fxm.37 for ; Mon, 27 Jul 2009 08:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=P0/nhFEuy3lCX0bXPAa1AnYhqyvo0vWGfcco5yB58K8=; b=RJVoRIm8S7Jy+BmdJbP+F/Ms2U3PvjiMZ+o/MtOg9nDIoMQ56Y/NJ+xflKsiwF3evU RBiGiw9C0RmeF4CJDeaW0esq/a1kAZ0D8Ye6jEeC1aUCghVlcyQ44XplAnHhZ+asLfke XE1RBdCpT+9nb+nexEPpuBYdLjy6ZKC5yOTVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jH0ydpMSadq4Uw916ww38AQq5s6HESCwsj+3qfusSOIDof8igeaneId2+TJZjoiNu/ 1zgcNGxGp4aF/YKFtNL72LYqdKaQLh3t+g9gVedJwfce6rNFg1FDIOfQghAPqthnGLzl PC8iBVy61ZjvbjujsK+d/BDK9Qg6ovwbIPDTI= MIME-Version: 1.0 Received: by 10.223.108.75 with SMTP id e11mr2778597fap.51.1248707826992; Mon, 27 Jul 2009 08:17:06 -0700 (PDT) In-Reply-To: <002a01ca0ec2$ab85fe10$0291fa30$@de> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <002a01ca0ec2$ab85fe10$0291fa30$@de> Date: Mon, 27 Jul 2009 11:17:06 -0400 Message-ID: <6e9223710907270817l30207138sfa2e77a35ad8a448@mail.gmail.com> From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636c5a72e74f653046fb17248 Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:17:38 -0000 --001636c5a72e74f653046fb17248 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As do I Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 10:00 AM, Christian Hoene w= rote: > > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of > > Patrick Luthi > > Sent: Monday, July 27, 2009 3:57 PM > > To: Ingemar Johansson S; Herve Taddei; Jean-Marc Valin > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > Hi, > > > I am surprised to still see codecs listed in item > > 4 of the agenda. As I said before I think that it > > would be best to have more time to discuss the > > other items of the agenda. So, please remove the > > codec presentations from the agenda! > > I support this request. > > Regards, > > Christian > > > > > > Regards, > > > > Patrick > > > > At 15:43 27/07/2009, Ingemar Johansson S wrote: > > >Hi > > > > > >I believe that I have expressed earlier that I > > >don't believe that a description of particular > > >codecs gives any additional value, speech/audio > > >coding is a very specialized area and going > > >beyond a descripion of a few "black boxes" in 25 > > >minutes is probably more than the average newbie > > >can digest. This is of course my personal > > >opinion and if you believe that it is important to have his then I > respect > > it. > > > > > >Regards > > >Ingemar > > > > > > > > > > -----Original Message----- > > > > From: Herve Taddei [mailto:herve.taddei@huawei.com] > > > > Sent: den 27 juli 2009 12:13 > > > > To: 'Jean-Marc Valin'; Ingemar Johansson S > > > > Cc: codec@ietf.org > > > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > > > Dear Jean Marc, > > > > > > > > Indeed the agenda was changed, but still the introduction of > > > > codecs is there. > > > > > > > > Best regards, > > > > Herv=E9 > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: codec-bounces@ietf.org > > > > [mailto:codec-bounces@ietf.org] On Behalf > > > > > Of Jean-Marc Valin > > > > > Sent: Monday, July 27, 2009 10:53 AM > > > > > To: Ingemar Johansson S > > > > > Cc: codec@ietf.org > > > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > > > > > Hi, > > > > > > > > > > Indeed, the link has not been updated. The updated agenda > > > > was posted here: > > > > > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > > > > > > > > > Regards, > > > > > > > > > > Jean-Marc > > > > > > > > > > Ingemar Johansson S a =E9crit : > > > > > > Hi > > > > > > > > > > > > I am a bit curious regarding the agenda for the codec BoF Is th= is > > > > > > the latest ? > > > > > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > > > > > I have probably missed a lot as I have been on vacation but I g= ot > > > > > > the > > > > (false?) > > > > > impression that it was not the intention to present any codecs an= d > > > > > instead > > > > focus on > > > > > the question "should IETF do this?" > > > > > > > > > > > > > > > > > > Regards > > > > > > /Ingemar > > > > > > > > > > > > ******************************************* > > > > > > Ingemar Johansson > > > > > > Senior Research Engineer, IETF "nethead" > > > > > > EAB/TVK - Multimedia Technologies > > > > > > Ericsson Research Ericsson AB > > > > > > Box 920 S-971 28 Lule=E5, Sweden > > > > > > Tel: +46 (0)10 7143042 > > > > > > ECN: 852-43042 > > > > > > ECC: 852-19042 > > > > > > Mobile: +46 (0)730 783289 > > > > > > Visit http://labs.ericsson.com ! > > > > > > ******************************************* > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > >_______________________________________________ > > >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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c5a72e74f653046fb17248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As do I

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 10:00 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:


> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On Behalf Of
> Patrick Luthi
> Sent: Monday, July 27, 2009 3:57 PM
> To: Ingemar Johansson S; Herve Taddei; Jean-Marc Valin
> Cc: codec@ietf.org
> Subject: Re: [codec] Agenda for the Codec Bof
>
Hi,

> I am surprised to still see codecs listed in i= tem
> 4 of the agenda. As I said before I think that it
> would be best to have more time to discuss the
> other items of the agenda. So, please remove the
> codec presentations from the agenda!

I support this request.

Regards,

=A0Christian


>
> Regards,
>
> Patrick
>
> At 15:43 27/07/2009, Ingemar Johansson S wrote:
> >Hi
> >
> >I believe that I have expressed earlier that I
> >don't believe that a description of particular
> >codecs gives any additional value, speech/audio
> >coding is a very specialized area and going
> >beyond a descripion of a few "black boxes" in 25
> >minutes is probably more than the average newbie
> >can digest. This is of course my personal
> >opinion and if you believe that it is important to have his then I=
respect
> it.
> >
> >Regards
> >Ingemar
> >
> >
> > > -----Original Message-----
> > > From: Herve Taddei [mailto:herve.taddei@huawei.com]
> > > Sent: den 27 juli 2009 12:13
> > > To: 'Jean-Marc Valin'; Ingemar Johansson S
> > > Cc: codec@ietf.org
> > > Subject: RE: [codec] Agenda for the Codec Bof
> > >
> > > Dear Jean Marc,
> > >
> > > Indeed the agenda was changed, but still the introduction of=
> > > codecs is there.
> > >
> > > Best regards,
> > > Herv=E9
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: codec-b= ounces@ietf.org
> > > [mailto:codec-boun= ces@ietf.org] On Behalf
> > > > Of Jean-Marc Valin
> > > > Sent: Monday, July 27, 2009 10:53 AM
> > > > To: Ingemar Johansson S
> > > > Cc: codec@ietf.org
> > > > Subject: Re: [codec] Agenda for the Codec Bof
> > > >
> > > > Hi,
> > > >
> > > > Indeed, the link has not been updated. The updated agen= da
> > > was posted here:
> > > > http://www.ietf.org/mail-archive/we= b/codec/current/msg00241.html
> > > >
> > > > Regards,
> > > >
> > > > =A0 =A0 Jean-Marc
> > > >
> > > > Ingemar Johansson S a =E9crit :
> > > > > Hi
> > > > >
> > > > > I am a bit curious regarding the agenda for the co= dec BoF Is this
> > > > > the latest ?
> > > > > http://svn.resiprocate.org/rep/= ietf-drafts/codec-bof/agenda.txt
> > > > > I have probably missed a lot as I have been on vac= ation but I got
> > > > > the
> > > (false?)
> > > > impression that it was not the intention to present any= codecs and
> > > > instead
> > > focus on
> > > > the question "should IETF do this?"
> > > > >
> > > > >
> > > > > Regards
> > > > > /Ingemar
> > > > >
> > > > > *******************************************
> > > > > Ingemar Johansson
> > > > > Senior Research Engineer, IETF "nethead"=
> > > > > EAB/TVK - Multimedia Technologies
> > > > > Ericsson Research Ericsson AB
> > > > > Box 920 S-971 28 Lule=E5, Sweden
> > > > > Tel: +46 (0)10 7143042
> > > > > ECN: 852-43042
> > > > > ECC: 852-19042
> > > > > Mobile: +46 (0)730 783289
> > > > > Visit http://labs.ericsson.com !
> > > > > *******************************************
> > > > > _______________________________________________ > > > > > 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
> > >
> > >
> >_______________________________________________
> >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

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

--001636c5a72e74f653046fb17248-- From stephen.botzko@gmail.com Mon Jul 27 08:25:50 2009 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 7DFD928B56A for ; Mon, 27 Jul 2009 08:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 jXokESnnWUTX for ; Mon, 27 Jul 2009 08:25:49 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id E2B4C28C17B for ; Mon, 27 Jul 2009 08:25:48 -0700 (PDT) Received: by fxm18 with SMTP id 18so2669661fxm.37 for ; Mon, 27 Jul 2009 08:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fENUJcfUviFWO2VKUZDDDd63Vk3ojGfEGqdEvXONTR0=; b=NYFGhHc5X+dRlSf2Nsh5quJlxlJmti4SjdRExRoThIv+LwV6rT6VSZh1vilp/osOVm eE8urC9xRQvZ5Oj7jzZT55KqKaDMGdGXLNN8Ul6WTBxWP9xFPtJyoOtS05Cx4AHrAwT2 WkD+l9icoOUuuWNdcIByAr1isw06FK815nT6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KaRn8KpGkOGe+c4n+i2vFyeU2kk2AXcyN9neyHUt8IRqiFAbYEixWSowbXpGAvta64 GMjL8RJtCA3k1IUr5c1A/EBSSxfdS8LnvT2fCxld3t/akJQIgPKNK3d/s4X9rSYuHysr jDPqaCfdb1D8Wn6uAAzOYKtkNbKZhVlRaqs+4= MIME-Version: 1.0 Received: by 10.223.109.198 with SMTP id k6mr2716064fap.46.1248708344781; Mon, 27 Jul 2009 08:25:44 -0700 (PDT) In-Reply-To: References: <4A6D6AD0.30504@usherbrooke.ca> Date: Mon, 27 Jul 2009 11:25:44 -0400 Message-ID: <6e9223710907270825o25dcffa5jcb58515dfac71594@mail.gmail.com> From: stephen botzko To: Henry Sinnreich Content-Type: multipart/alternative; boundary=001636c5b496519a94046fb191c4 Cc: Ingemar Johansson S , "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:25:50 -0000 --001636c5b496519a94046fb191c4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henry I believe that hums include chatroom support/dissent. Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich wrote= : > The hum item is not fair nor representative IMO, since it favors people > who have a travel budget. > > >7. HUM on if the IETF should form this WG (All, 15 min) > > I would like to understand how/why the hum is representative for the > Internet industry, > since it looks humming disadvantages the little guys, exactly those who > depend on free codecs. > > My personal 2 cents. > Henry > > > > On 7/27/09 10:52 AM, "Jean-Marc Valin" > wrote: > > Hi, > > Indeed, the link has not been updated. The updated agenda was posted here= : > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > Regards, > > Jean-Marc > > Ingemar Johansson S a =E9crit : > > Hi > > > > I am a bit curious regarding the agenda for the codec BoF > > Is this the latest ? > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > I have probably missed a lot as I have been on vacation but I got the > (false?) impression that it was not the intention to present any codecs a= nd > instead focus on the question "should IETF do this?" > > > > > > Regards > > /Ingemar > > > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVK - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > 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 > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --001636c5b496519a94046fb191c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henry

I believe that hums include chatroom support/dissent.
Regards,
Stephen Botzko
Polycom

O= n Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:<= br>
The hum item is not fair nor representative IMO, since it favors pe= ople who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.c= a> wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= br> http://www.ietf.org/mail-archive/web/codec/current/msg0= 0241.html

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar Johansson S a =E9crit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bo= f/agenda.txt
> I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and= instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Lule=E5, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://la= bs.ericsson.com !
> *******************************************
> _______________________________________________
> 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


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


--001636c5b496519a94046fb191c4-- From hsinnrei@adobe.com Mon Jul 27 08:55:08 2009 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 E25523A67DD for ; Mon, 27 Jul 2009 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auZQP90q-8DA for ; Mon, 27 Jul 2009 08:55:03 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 19AC93A6ABD for ; Mon, 27 Jul 2009 08:55:03 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSm3NyupPl1cWPOWzwKjRlzZjcGudFPMu@postini.com; Mon, 27 Jul 2009 08:55:04 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6RFmKao019741; Mon, 27 Jul 2009 08:48:20 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6RFsniq021115; Mon, 27 Jul 2009 08:54:49 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 27 Jul 2009 08:54:49 -0700 From: Henry Sinnreich To: stephen botzko Date: Mon, 27 Jul 2009 08:54:46 -0700 Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOzoXjK1VZY5YYTNqOEoMEU3OfjAABApmX Message-ID: In-Reply-To: <6e9223710907270825o25dcffa5jcb58515dfac71594@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6939A66EEAFhsinnreiadobecom_" MIME-Version: 1.0 Cc: Ingemar Johansson S , "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:55:09 -0000 --_000_C6939A66EEAFhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The little guys on the Internet who depend on free codecs will still not be= represented. Even if they turn out to be in minority. I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs. Take a look for example on the lists of users for free codecs - no names me= ntioned here. Henry On 7/27/09 5:25 PM, "stephen botzko" wrote: Hi Henry I believe that hums include chatroom support/dissent. Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich wrot= e: The hum item is not fair nor representative IMO, since it favors people who= have a travel budget. >7. HUM on if the IETF should form this WG (All, 15 min) I would like to understand how/why the hum is representative for the Intern= et industry, since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs. My personal 2 cents. Henry On 7/27/09 10:52 AM, "Jean-Marc Valin" > wrote: Hi, Indeed, the link has not been updated. The updated agenda was posted here: http://www.ietf.org/mail-archive/web/codec/current/msg00241.html Regards, Jean-Marc Ingemar Johansson S a =E9crit : > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (fa= lse?) impression that it was not the intention to present any codecs and in= stead focus on the question "should IETF do this?" > > > Regards > /Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > 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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6939A66EEAFhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Agenda for the Codec Bof The little guys on the Internet who depend on free codecs will still = not be represented.
Even if they turn out to be in minority.

I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs.
Take a look for example on the lists of users for free codecs – no na= mes mentioned here.

Henry


On 7/27/09 5:25 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

Hi Henry

I believe that hums include chatroom support/dissent.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
The hum item is not fair nor representative= IMO, since it favors people who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca <http://jean-marc.valin@usherbrooke.ca> > wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= BR> http://www.ietf.org/mail-archive/web/codec/current/msg00241.html

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar Johansson S a écrit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and= instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org <http://codec@ietf.org>
> https://www.ie= tf.org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf.org>
https://www.ietf.or= g/mailman/listinfo/codec

codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

To: "'Andrew Sviridenko'" , References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> In-Reply-To: Date: Mon, 27 Jul 2009 17:55:47 +0200 Message-ID: <005201ca0ed2$b9baf980$2d30ec80$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBgnF5vBFx/FGmTgCDU0EtNN3J4QMqWJ3gAClfY8A= Content-language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.0.228; VDF: 7.1.5.33; host: mx05); id=8352-CNEnx2 Subject: Re: [codec] [AVT] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:55:58 -0000 To make the list complete, some weeks ago I requested to present the Bluetooth SBC codec, which is good for similar usage scenarios as CELT = and is available as open source. However, instead of codecs I think it is more important to discuss the processes on how a Internet audio codec WG should develop, assess, and select codecs. Obviously, we have already four candidates. Another important point is on how other parties (e.g., the IESG) can evaluate whether the WG does a good job. For example, there have been requests on a proper codec classification and comparison. None of these issues are addressed in the charter nor the agenda. With best regards, Christian Hoene -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Andrew > Sviridenko > Sent: Sunday, July 26, 2009 10:40 PM > To: codec@ietf.org; avt@ietf.org > Subject: Re: [AVT] [codec] Updated Agenda for Codec BOF >=20 >=20 > Dear all- >=20 > SPIRIT DSP is interested to contribute to the IETF codec WG / BOF, and > present our IPMR wideband codec on July 30, along with SILK. >=20 > During the last 17 years (since 1992) SPIRIT DSP speech experts = designed > and developed several proprietary codecs actually deployed by many > global leading telecom OEMs and semiconductor vendors- > http://www.spiritdsp.com/customers/ >=20 > SPIRIT IPMR is multi-rate, scalable, adaptive, wideband codec > specifically designed for IP-based communications several years ago- > WGLC on draft-ietf-avt-rtp-ipmr-04 >=20 > SPIRIT IPMR is- > - multi-rate, scalable, adaptive, wideband codec, > - low latency, > - delivers generally better voice quality than Speex, > - robust to packet loss, > - we have both PC and mobile (low MIPS) implementations, > - licensed and deployed by many leading companies, including Adobe and > Oracle, as well as multiple Asia-based telecom operators and telecom > OEMs, > - patent-free, > - payload already submitted to IETF. >=20 > SPIRIT would like to contribute to the codec WG / BOF of IETF, and = help > create wideband codec standard for IP-communications and global voice > interoperability. >=20 > We can open-source SPIRIT IPMR if needed to make it part of the > standard. > We are also open to partner with bigger companies in this group if > needed to make IPMR codec part of the standard. >=20 > Please let us present our SPIRIT IPMR wideband codec on July 30, along > with SILK. Slava Borilin from SPIRIT DSP will join the WG / BOF. >=20 > Thank you, > Andrew Sviridenko > SPIRIT DSP, www.spiritDSP.com, Voice & Video Engine Experts >=20 >=20 >=20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Friday, July 10, 2009 9:18 PM > To: Roni Even > Cc: 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin; > codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 7/10/09 10:43 AM, Roni Even wrote: > > Hi, > > I still fail to see what is the value in presenting one, two or = three > > codecs. >=20 > Present them as existence proofs (yes, we can!) and provide lessons > learned as input to the kind of work that a Codec WG would pursue. We > need to know that it is within the realm of possibility for a Codec WG > to be successful. >=20 > > I saw that there was a request to present a third one. >=20 > Which? >=20 > > I can agree that there are people who can present codecs as a > suggested > > solution including existing ones. >=20 > No. As far as I can see these are *not* suggested solutions. The point > is show that we have the expertise within the IETF to pursue this = work, > to learn how those codecs were developed, and to judge whether we = think > even better codecs could be developed by a Codec WG. >=20 > > Since there is no charter yet under which > > the codecs are to be specified it may serve as a tutorial on codecs. >=20 > Given that the IETF has not traditionally been home to codec work, I > think that a very brief tutorial on what's involved in such work would > be quite beneficial. >=20 > > So if > > we open to codec presentation in the BOF let allow everyone to = present > their > > codecs including ITU and MPEG ones and spend the whole BOF of the > different > > codecs technologies. >=20 > Don't be ridiculous. Two or three proof points should be plenty. >=20 > > If the idea behind this presentation is to show specific = functionality >=20 >=20 > I don't think that's the idea. >=20 > > than > > instead it will be more fruitful to present requirements, since I > could see > > from the list discussion that there is no consensus even between the > current > > proponents what the requirements are. >=20 > Discussion of existence proofs and lessons learned from previous codec > work is not at odds with discussion of requirements. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkpXd9sACgkQNL8k5A2w/vzbdwCgxU2s6pjxTWp67WE30oJd/s1F > L6AAn3s7EmSR3aDYrX0Pz79Rnjc36oVm > =3D8ctr > -----END PGP SIGNATURE----- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ingemar.s.johansson@ericsson.com Mon Jul 27 09:12:10 2009 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 216943A68FD for ; Mon, 27 Jul 2009 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-2.828, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_SE=0.35, 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 fuTJrzJTeq-M for ; Mon, 27 Jul 2009 09:12:08 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0AFA73A6B1F for ; Mon, 27 Jul 2009 09:12:07 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-f9-4a6dd1d7e014 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2D.EE.18827.7D1DD6A4; Mon, 27 Jul 2009 18:12:07 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 18:12:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0ED4.FC965C70" Date: Mon, 27 Jul 2009 18:12:06 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018EC37C@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOzoXjK1VZY5YYTNqOEoMEU3OfjAABApmXAABbn/A= References: <6e9223710907270825o25dcffa5jcb58515dfac71594@mail.gmail.com> From: "Ingemar Johansson S" To: "Henry Sinnreich" , "stephen botzko" X-OriginalArrivalTime: 27 Jul 2009 16:12:07.0374 (UTC) FILETIME=[FCFC76E0:01CA0ED4] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:12:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0ED4.FC965C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 I would believe that the hum procedure is quite well established and = controlled and I believe that other people with more IETF experience = than me will make sure that it is handled in a fair way regarless if = people are physically present on the meeting or not.=20 =20 /Ingemar=20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: den 27 juli 2009 17:55 To: stephen botzko Cc: Jean-Marc Valin; Ingemar Johansson S; codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof =09 =09 The little guys on the Internet who depend on free codecs will still = not be represented. Even if they turn out to be in minority. =09 I table for this reason to delete the humming item, or find a better = way to safeguard their dependence on free codecs. Take a look for example on the lists of users for free codecs - no = names mentioned here. =09 Henry =09 =09 On 7/27/09 5:25 PM, "stephen botzko" wrote: =09 =09 Hi Henry =09 I believe that hums include chatroom support/dissent. =09 Regards, Stephen Botzko Polycom =09 On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich = wrote: =09 The hum item is not fair nor representative IMO, since it favors = people who have a travel budget. =09 >7. HUM on if the IETF should form this WG (All, 15 min) =09 I would like to understand how/why the hum is representative for the = Internet industry,=20 since it looks humming disadvantages the little guys, exactly those = who depend on free codecs.=20 =09 My personal 2 cents. Henry =09 =09 =09 On 7/27/09 10:52 AM, "Jean-Marc Valin" = = > wrote: =09 =09 Hi, =09 Indeed, the link has not been updated. The updated agenda was posted = here: http://www.ietf.org/mail-archive/web/codec/current/msg00241.html =09 Regards, =09 Jean-Marc =09 Ingemar Johansson S a =E9crit : > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got = the (false?) impression that it was not the intention to present any = codecs and instead focus on the question "should IETF do this?" > > > Regards > /Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > codec mailing list > codec@ietf.org =20 > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ codec mailing list codec@ietf.org =20 https://www.ietf.org/mailman/listinfo/codec =09 =09 =09 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =09 =09 =09 =09 =09 ------_=_NextPart_001_01CA0ED4.FC965C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Agenda for the Codec Bof
Hi
 
I would believe that the hum procedure is quite = well=20 established and controlled and I believe that other people with more = IETF=20 experience than me will make sure that it is handled in a fair way = regarless if=20 people are physically present on the meeting or not. =
 
/Ingemar 

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: den 27 juli 2009=20 17:55
To: stephen botzko
Cc: Jean-Marc Valin; = Ingemar=20 Johansson S; codec@ietf.org
Subject: Re: [codec] Agenda for = the=20 Codec Bof

The little guys on the Internet who depend = on free=20 codecs will still not be represented.
Even if they turn out to be = in=20 minority.

I table for this reason to delete the humming item, = or find a=20 better way to safeguard their dependence on free codecs.
Take a = look for=20 example on the lists of users for free codecs =96 no names mentioned=20 here.

Henry


On 7/27/09 5:25 PM, "stephen botzko" = <stephen.botzko@gmail.com>=20 wrote:
Hi Henry

I believe that hums = include chatroom=20 support/dissent.

Regards,
Stephen = Botzko
Polycom

On Mon,=20 Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com>=20 wrote:
The hum item is not fair nor = representative IMO,=20 since it favors people who have a travel budget.

>7. HUM = on if=20 the IETF should form this WG (All, 15 min)

I would like to=20 understand how/why the hum is representative for the Internet = industry,=20
since it looks humming disadvantages the little guys, exactly = those=20 who depend on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, = "Jean-Marc=20 Valin" <jean-marc.valin@usherbrooke.ca=20 <http://jean-marc.valin@ush= erbrooke.ca>=20 > wrote:
Hi,

Indeed, the link has not = been=20 updated. The updated agenda was posted here:
http://www.ietf.org/mail-archive/web/codec/current/msg00241.html
=
Regards,

        Jean-= Marc

Ingemar=20 Johansson S a =E9crit :
> Hi
>
> I am a bit = curious=20 regarding the agenda for the codec BoF
> Is this the = latest=20 ?
> = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
&g= t;=20 I have probably missed a lot as I have been on vacation but I = got the=20 (false?) impression that it was not the intention to present any = codecs=20 and instead focus on the question "should IETF do=20 this?"
>
>
> Regards
> = /Ingemar
>
>=20 *******************************************
> Ingemar=20 Johansson
> Senior Research Engineer, IETF = "nethead"
>=20 EAB/TVK - Multimedia Technologies
> Ericsson Research = Ericsson=20 AB
> Box 920 S-971 28 Lule=E5, Sweden
> Tel: +46 = (0)10=20 7143042
> ECN: 852-43042
> ECC: 852-19042
> = Mobile:=20 +46 (0)730 783289
> Visit http://labs.ericsson.com = !
>=20 *******************************************
>=20 _______________________________________________
> codec = mailing=20 list
> codec@ietf.org = <http://codec@ietf.org> =
> https://www.ietf.org= /mailman/listinfo/codec
>
>
__________________________= _____________________
codec=20 mailing list
codec@ietf.org = <http://codec@ietf.org> =
https://www.ietf.org= /mailman/listinfo/codec


_______________________________________________
codec=20 mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec



------_=_NextPart_001_01CA0ED4.FC965C70-- From stephen.botzko@gmail.com Mon Jul 27 09:22:46 2009 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 7BB543A6AD4 for ; Mon, 27 Jul 2009 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 V4QnzKRrM7q4 for ; Mon, 27 Jul 2009 09:22:45 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 8F87C28C0F4 for ; Mon, 27 Jul 2009 09:22:44 -0700 (PDT) Received: by bwz21 with SMTP id 21so335359bwz.37 for ; Mon, 27 Jul 2009 09:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p5msZjfjFdNZtXmTHI9E7zzYQSShHq/IKYNFi8J0MKc=; b=B+K/Oto7mQH9oWJAACioftMScQykcuIlesWkYeSZlpIpEbkuLNMtkEEpkk9RDBh4sK HH9jbiFWpmw3rBRkoiaIapk8ApzYVnh6EuiYMgTcXPDh3ntho8Iqtsq8ETKuXK/jMKKY m+72rUqRZ6BPeeeHNcHV8iDZmlq3hgcVPivlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U2O8RDcZJYHnJGbYaxnRRjapHpPYM2syyn5AqTDBBr6KWjaAi2gXckVoGpmzDc2UtE C/BJ2jLpTyd5TAQJygmK5iNWbmIs2N91SV1rqpv6aF3UhoaU7hWki2HkE/gaNKY8/x1J FLDcb0yiHJir42AZMnqw1vddXmc6CyvDPjr9Q= MIME-Version: 1.0 Received: by 10.223.114.208 with SMTP id f16mr2690520faq.91.1248711763342; Mon, 27 Jul 2009 09:22:43 -0700 (PDT) In-Reply-To: References: <6e9223710907270825o25dcffa5jcb58515dfac71594@mail.gmail.com> Date: Mon, 27 Jul 2009 12:22:43 -0400 Message-ID: <6e9223710907270922h4d519869tf6cfe78cc23561c2@mail.gmail.com> From: stephen botzko To: Henry Sinnreich Content-Type: multipart/alternative; boundary=001636c5b1fa14ba03046fb25dae Cc: "codec@ietf.org" Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:22:46 -0000 --001636c5b1fa14ba03046fb25dae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Folks who participate in person or via the chatroom are represented. Folks who choose *not* to participate are *not* represented. This is standard practice in the IETF, there is no other way to decide things here. Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 11:54 AM, Henry Sinnreich wrote= : > The little guys on the Internet who depend on free codecs will still not > be represented. > Even if they turn out to be in minority. > > I table for this reason to delete the humming item, or find a better way = to > safeguard their dependence on free codecs. > Take a look for example on the lists of users for free codecs =96 no name= s > mentioned here. > > Henry > > > On 7/27/09 5:25 PM, "stephen botzko" wrote: > > Hi Henry > > I believe that hums include chatroom support/dissent. > > Regards, > Stephen Botzko > Polycom > > On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich > wrote: > > The hum item is not fair nor representative IMO, since it favors people w= ho > have a travel budget. > > >7. HUM on if the IETF should form this WG (All, 15 min) > > I would like to understand how/why the hum is representative for the > Internet industry, > since it looks humming disadvantages the little guys, exactly those who > depend on free codecs. > > My personal 2 cents. > Henry > > > > On 7/27/09 10:52 AM, "Jean-Marc Valin" http://jean-marc.valin@usherbrooke.ca> > wrote: > > Hi, > > Indeed, the link has not been updated. The updated agenda was posted here= : > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > Regards, > > Jean-Marc > > Ingemar Johansson S a =E9crit : > > Hi > > > > I am a bit curious regarding the agenda for the codec BoF > > Is this the latest ? > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > I have probably missed a lot as I have been on vacation but I got the > (false?) impression that it was not the intention to present any codecs a= nd > instead focus on the question "should IETF do this?" > > > > > > Regards > > /Ingemar > > > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVK - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > 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 > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > --001636c5b1fa14ba03046fb25dae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Folks who participate in person or via the chatroom are represented.=A0 Fol= ks who choose not to participate are not represented.=A0 This= is standard practice in the IETF, there is no other way to decide things h= ere.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:54 AM,= Henry Sinnreich <hsinnrei@adobe.com> wrote:
The little guys on the Internet who depend on free codecs will stil= l not be represented.
Even if they turn out to be in minority.

I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs.
Take a look for example on the lists of users for free codecs =96 no names = mentioned here.

Henry



On 7/27/09 5:25 PM, "stephen botzko" <stephen.botzko@gmail.com> wrot= e:

Hi Henry

I believe that hums include chatroom support/dissent.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
The hum item is not fair nor r= epresentative IMO, since it favors people who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.c= a <http://jean-marc.valin@usherbrooke.ca> > wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= br> http://www.ietf.org/mail-archive/web/codec/current/msg0= 0241.html

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar Johansson S a =E9crit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bo= f/agenda.txt
> I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and= instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Lule=E5, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://la= bs.ericsson.com !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org= <http://codec@ietf.= org>
> https://www.ietf.org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf= .org>

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




--001636c5b1fa14ba03046fb25dae-- From stewe@stewe.org Mon Jul 27 10:11:15 2009 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 8816828C32B for ; Mon, 27 Jul 2009 10:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 i7f49DCNZUmh for ; Mon, 27 Jul 2009 10:11:09 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 8490628C33A for ; Mon, 27 Jul 2009 10:11:06 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 360835-1743317 for multiple; Mon, 27 Jul 2009 19:10:35 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 27 Jul 2009 10:10:27 -0700 From: Stephan Wenger To: Henry Sinnreich , stephen botzko Message-ID: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoOzoXjK1VZY5YYTNqOEoMEU3OfjAABApmXAAKkqTU= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331534234_1594842" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: Ingemar Johansson S , "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:11:15 -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_3331534234_1594842 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, You are really an old hand in the IETF business. Do you recall a single BO= F where there was no =B3humm=B2, or =B3show of hands=B2, or similar exercise, to gaug= e the readiness of the IETF to take on the work? My personal recollection is that a humm is the norm. Regards, Stephan =20 On 7/27/09 8:54 AM, "Henry Sinnreich" wrote: > The little guys on the Internet who depend on free codecs will still not = be > represented. > Even if they turn out to be in minority. >=20 > I table for this reason to delete the humming item, or find a better way = to > safeguard their dependence on free codecs. > Take a look for example on the lists of users for free codecs =AD no names > mentioned here. >=20 > Henry >=20 >=20 > On 7/27/09 5:25 PM, "stephen botzko" wrote: >=20 >> Hi Henry >>=20 >> I believe that hums include chatroom support/dissent. >>=20 >> Regards, >> Stephen Botzko >> Polycom >>=20 >> On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich w= rote: >>> The hum item is not fair nor representative IMO, since it favors people= who >>> have a travel budget. >>>=20 >>>> >7. HUM on if the IETF should form this WG (All, 15 min) >>>=20 >>> I would like to understand how/why the hum is representative for the >>> Internet industry, >>> since it looks humming disadvantages the little guys, exactly those who >>> depend on free codecs. >>>=20 >>> My personal 2 cents. >>> Henry >>>=20 >>>=20 >>>=20 >>> On 7/27/09 10:52 AM, "Jean-Marc Valin" >> > wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Indeed, the link has not been updated. The updated agenda was posted h= ere: >>>> http://www.ietf.org/mail-archive/web/codec/current/msg00241.html >>>>=20 >>>> Regards, >>>>=20 >>>> =A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc >>>>=20 >>>> Ingemar Johansson S a =E9crit : >>>>> > Hi >>>>> > >>>>> > I am a bit curious regarding the agenda for the codec BoF >>>>> > Is this the latest ? >>>>> > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >>>>> > I have probably missed a lot as I have been on vacation but I got t= he >>>>> (false?) impression that it was not the intention to present any code= cs >>>>> and instead focus on the question "should IETF do this?" >>>>> > >>>>> > >>>>> > Regards >>>>> > /Ingemar >>>>> > >>>>> > ******************************************* >>>>> > Ingemar Johansson >>>>> > Senior Research Engineer, IETF "nethead" >>>>> > EAB/TVK - Multimedia Technologies >>>>> > Ericsson Research Ericsson AB >>>>> > Box 920 S-971 28 Lule=E5, Sweden >>>>> > Tel: +46 (0)10 7143042 >>>>> > ECN: 852-43042 >>>>> > ECC: 852-19042 >>>>> > Mobile: +46 (0)730 783289 >>>>> > Visit http://labs.ericsson.com ! >>>>> > ******************************************* >>>>> > _______________________________________________ >>>>> > 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 >>>>=20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3331534234_1594842 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Agenda for the Codec Bof Hi Henry,
You are really an old hand in the IETF business.  Do you recall a sing= le BOF where there was no “humm”, or “show of hands”= , or similar exercise, to gauge the readiness of the IETF to take on the wor= k?  My personal recollection is that a humm is the norm.
Regards,
Stephan
 


On 7/27/09 8:54 AM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"4">The little guys on the Internet w= ho depend on free codecs will still not be represented.
Even if they turn out to be in minority.

I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs.
Take a look for example on the lists of users for free codecs – no na= mes mentioned here.

Henry


On 7/27/09 5:25 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

Hi Henry

I believe that hums include chatroom support/dissent.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
The hum item is not fair n= or representative IMO, since it favors people who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca <http://jean-marc.valin@usherbrooke.ca> = > wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= BR> = http://www.ietf.org/mail-archive/web/codec/current/msg00241.html

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar Johansson S a écrit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
> I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and = instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com = !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org <http://codec@ietf.org>
> https://www.ietf= .org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf.org>
https://www.ietf.org/= mailman/listinfo/codec


_______________________________________________
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
--B_3331534234_1594842-- From stewe@stewe.org Mon Jul 27 10:18:20 2009 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 64B4E28C35B for ; Mon, 27 Jul 2009 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ewovlriHLdBS for ; Mon, 27 Jul 2009 10:18:13 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id BD65F28C36C for ; Mon, 27 Jul 2009 10:18:11 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 360845-1743317 for multiple; Mon, 27 Jul 2009 19:18:04 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 27 Jul 2009 10:17:56 -0700 From: Stephan Wenger To: stephen botzko , Henry Sinnreich Message-ID: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoO3i6MyhHmjcYsJ0iHQaFks+uYzw== In-Reply-To: <6e9223710907270922h4d519869tf6cfe78cc23561c2@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331534683_1622708" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:18:20 -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_3331534683_1622708 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable With respect to all this discussion, please note that there is an agenda item =B3agenda bashing=B2 at the very beginning of the BOF. While I personally do not consider it to be overly productive to augment an (at this point) useless presentation of two randomly chosen codec candidates with an even more useless meta discussion on the agenda, I fear that=B9s precisely what=B9s going to happen... Perhaps we should fix this whole issue by removing both agenda items :-) Regards, Stephan On 7/27/09 9:22 AM, "stephen botzko" wrote: > Folks who participate in person or via the chatroom are represented.=A0 Fol= ks > who choose not to participate are not represented.=A0 This is standard prac= tice > in the IETF, there is no other way to decide things here. >=20 > Regards, > Stephen Botzko > Polycom >=20 > On Mon, Jul 27, 2009 at 11:54 AM, Henry Sinnreich wr= ote: >> The little guys on the Internet who depend on free codecs will still not= be >> represented. >> Even if they turn out to be in minority. >>=20 >> I table for this reason to delete the humming item, or find a better way= to >> safeguard their dependence on free codecs. >> Take a look for example on the lists of users for free codecs =AD no names >> mentioned here. >>=20 >> Henry >>=20 >>=20 >>=20 >> On 7/27/09 5:25 PM, "stephen botzko" > > wrote: >>=20 >>> Hi Henry >>>=20 >>> I believe that hums include chatroom support/dissent. >>>=20 >>> Regards, >>> Stephen Botzko >>> Polycom >>>=20 >>> On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich >> > wrote: >>>> The hum item is not fair nor representative IMO, since it favors peopl= e who >>>> have a travel budget. >>>>=20 >>>>> >7. HUM on if the IETF should form this WG (All, 15 min) >>>>=20 >>>> I would like to understand how/why the hum is representative for the >>>> Internet industry, >>>> since it looks humming disadvantages the little guys, exactly those wh= o >>>> depend on free codecs. >>>>=20 >>>> My personal 2 cents. >>>> Henry >>>>=20 >>>>=20 >>>>=20 >>>> On 7/27/09 10:52 AM, "Jean-Marc Valin" >>> >>>> > wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Indeed, the link has not been updated. The updated agenda was posted = here: >>>>> http://www.ietf.org/mail-archive/web/codec/current/msg00241.html >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> =A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc >>>>>=20 >>>>> Ingemar Johansson S a =E9crit : >>>>>> > Hi >>>>>> > >>>>>> > I am a bit curious regarding the agenda for the codec BoF >>>>>> > Is this the latest ? >>>>>> > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >>>>>> > I have probably missed a lot as I have been on vacation but I got = the >>>>>> (false?) impression that it was not the intention to present any cod= ecs >>>>>> and instead focus on the question "should IETF do this?" >>>>>> > >>>>>> > >>>>>> > Regards >>>>>> > /Ingemar >>>>>> > >>>>>> > ******************************************* >>>>>> > Ingemar Johansson >>>>>> > Senior Research Engineer, IETF "nethead" >>>>>> > EAB/TVK - Multimedia Technologies >>>>>> > Ericsson Research Ericsson AB >>>>>> > Box 920 S-971 28 Lule=E5, Sweden >>>>>> > Tel: +46 (0)10 7143042 >>>>>> > ECN: 852-43042 >>>>>> > ECC: 852-19042 >>>>>> > Mobile: +46 (0)730 783289 >>>>>> > Visit http://labs.ericsson.com ! >>>>>> > ******************************************* >>>>>> > _______________________________________________ >>>>>> > 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 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>>=20 >>>=20 >>>=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3331534683_1622708 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Agenda for the Codec Bof With respect to all this discussion, please note that there is an agenda i= tem “agenda bashing” at the very beginning of the BOF.  Whi= le I personally do not consider it to be overly productive to augment an (at= this point) useless presentation of two randomly chosen codec candidates wi= th an even more useless meta discussion on the agenda, I fear that’s p= recisely what’s going to happen...
Perhaps we should fix this whole issue by removing both agenda items :-) Regards,
Stephan




On 7/27/09 9:22 AM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Folks who participate in person or via the chatr= oom are represented.=A0 Folks who choose not to participate are not<= /U> represented.=A0 This is standard practice in the IETF, there is no other w= ay to decide things here.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:54 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
<= FONT SIZE=3D"4">The little guys on the Internet w= ho depend on free codecs will still not be represented.
Even if they turn out to be in minority.

I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs.
Take a look for example on the lists of users for free codecs – no na= mes mentioned here.

Henry



On 7/27/09 5:25 PM, "stephen botzko" <stephen.botzko@gmail.com <http://stephen.botzko@gmail.com> > wrote:

Hi Henry

I believe that hums include chatroom support/dissent.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com <http:= //hsinnrei@adobe.com> > wrote:
The hum item is not fair n= or representative IMO, since it favors people who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca <http://jean-marc.valin@usherbrooke.ca> =  <http://jean-marc.v= alin@usherbrooke.ca> > wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= BR> = http://www.ietf.org/mail-archive/web/codec/current/msg00241.html

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar Johansson S a écrit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
> I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and = instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com = !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org <http://codec@ietf.org>  <http://codec@ietf.org>
> https://www.ietf= .org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf.org>  <http://codec@ietf.org>
https://www.ietf.org/= mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf.org>
https://www.ietf.org/= mailman/listinfo/codec





___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3331534683_1622708-- From gherlein@herlein.com Mon Jul 27 10:29:29 2009 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 2093428C1A3 for ; Mon, 27 Jul 2009 10:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.025 X-Spam-Level: * X-Spam-Status: No, score=1.025 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 VlaiDcP6K+zb for ; Mon, 27 Jul 2009 10:29:27 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id C29BE3A6A30 for ; Mon, 27 Jul 2009 10:29:27 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so883940wff.31 for ; Mon, 27 Jul 2009 10:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.163.12 with SMTP id q12mr826793wfo.125.1248715711119; Mon, 27 Jul 2009 10:28:31 -0700 (PDT) In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018EC37C@esealmw109.eemea.ericsson.se> References: <6e9223710907270825o25dcffa5jcb58515dfac71594@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC37C@esealmw109.eemea.ericsson.se> Date: Mon, 27 Jul 2009 10:28:31 -0700 Message-ID: <31d1be720907271028m5a29eda1xf42d919b9755efe0@mail.gmail.com> From: Greg Herlein To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=0016368e25cc63014f046fb3482b Cc: codec@ietf.org, stephen botzko , Jean-Marc Valin Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:29:29 -0000 --0016368e25cc63014f046fb3482b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For 'little guys' like me... where is the hum documented such that I could participate in a chat room if I wanted? I've lurked (and sometimes activel= y participated) on this list for years and only recently learned that there was such a way to participate. Greg On Mon, Jul 27, 2009 at 9:12 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > I would believe that the hum procedure is quite well established and > controlled and I believe that other people with more IETF experience than= me > will make sure that it is handled in a fair way regarless if people are > physically present on the meeting or not. > > /Ingemar > > ------------------------------ > *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] > *Sent:* den 27 juli 2009 17:55 > *To:* stephen botzko > *Cc:* Jean-Marc Valin; Ingemar Johansson S; codec@ietf.org > *Subject:* Re: [codec] Agenda for the Codec Bof > > The little guys on the Internet who depend on free codecs will still not = be > represented. > Even if they turn out to be in minority. > > I table for this reason to delete the humming item, or find a better way = to > safeguard their dependence on free codecs. > Take a look for example on the lists of users for free codecs =96 no name= s > mentioned here. > > Henry > > > On 7/27/09 5:25 PM, "stephen botzko" wrote: > > Hi Henry > > I believe that hums include chatroom support/dissent. > > Regards, > Stephen Botzko > Polycom > > On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich > wrote: > > The hum item is not fair nor representative IMO, since it favors people w= ho > have a travel budget. > > >7. HUM on if the IETF should form this WG (All, 15 min) > > I would like to understand how/why the hum is representative for the > Internet industry, > since it looks humming disadvantages the little guys, exactly those who > depend on free codecs. > > My personal 2 cents. > Henry > > > > On 7/27/09 10:52 AM, "Jean-Marc Valin" http://jean-marc.valin@usherbrooke.ca> > wrote: > > Hi, > > Indeed, the link has not been updated. The updated agenda was posted here= : > http://www.ietf.org/mail-archive/web/codec/current/msg00241.html > > Regards, > > Jean-Marc > > Ingemar Johansson S a =E9crit : > > Hi > > > > I am a bit curious regarding the agenda for the codec BoF > > Is this the latest ? > > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > I have probably missed a lot as I have been on vacation but I got the > (false?) impression that it was not the intention to present any codecs a= nd > instead focus on the question "should IETF do this?" > > > > > > Regards > > /Ingemar > > > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVK - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > > --=20 Greg Herlein www.herlein.com --0016368e25cc63014f046fb3482b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For 'little guys' like me... where is the hum documented such that = I could participate in a chat room if I wanted?=A0 I've lurked (and som= etimes actively participated) on this list for years and only recently lear= ned that there was such a way to participate.

Greg

On Mon, Jul 27, 2009 at 9:12 AM,= Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:<= br>
Hi
=A0
I would believe that the hum procedure is quite well=20 established and controlled and I believe that other people with more IETF= =20 experience than me will make sure that it is handled in a fair way regarles= s if=20 people are physically present on the meeting or not.
=A0
/Ingemar=A0

From: Henry Sinnreich=20 [mailto:hsinnrei@= adobe.com]
Sent: den 27 juli 2009=20 17:55
To: stephen botzko
Cc: Jean-Marc Valin; Ingemar= =20 Johansson S; codec@ie= tf.org

Subject: Re: [codec] Agenda for the= =20 Codec Bof

The little guys on the Internet who depend on free=20 codecs will still not be represented.
Even if they turn out to be in= =20 minority.

I table for this reason to delete the humming item, or f= ind a=20 better way to safeguard their dependence on free codecs.
Take a look f= or=20 example on the lists of users for free codecs =96 no names mentioned=20 here.

Henry


On 7/27/09 5:25 PM, "stephen botzko&qu= ot; <steph= en.botzko@gmail.com>=20 wrote:
Hi Henry

I believe that hums include chatroom= =20 support/dissent.

Regards,
Stephen Botzko
Polycom

On= Mon,=20 Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com>=20 wrote:
The hum item is not fair nor representative IMO,=20 since it favors people who have a travel budget.

>7. HUM on= if=20 the IETF should form this WG (All, 15 min)

I would like to=20 understand how/why the hum is representative for the Internet industr= y,=20
since it looks humming disadvantages the little guys, exactly tho= se=20 who depend on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-M= arc=20 Valin" <jean-marc.valin@usherbrooke.ca=20 <http://jean-marc.valin@usherbrooke.ca>=20 > wrote:
Hi,

Indeed, the link has not been=20 updated. The updated agenda was posted here:
http://www.ietf.org/mail-archive/web/codec/current/msg00241.html
Regards,

=A0=A0=A0=A0=A0=A0=A0=A0Jean-Marc

Ingemar=20 Johansson S a =E9crit :
> Hi
>
> I am a bit curio= us=20 regarding the agenda for the codec BoF
> Is this the latest= =20 ?
> http://svn.resiprocate.org/rep/ietf-dr= afts/codec-bof/agenda.txt
>=20 I have probably missed a lot as I have been on vacation but I got t= he=20 (false?) impression that it was not the intention to present any co= decs=20 and instead focus on the question "should IETF do=20 this?"
>
>
> Regards
> /Ingemar
>= ;
>=20 *******************************************
> Ingemar=20 Johansson
> Senior Research Engineer, IETF "nethead"= ;
>=20 EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsso= n=20 AB
> Box 920 S-971 28 Lule=E5, Sweden
> Tel: +46 (0)10= =20 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobil= e:=20 +46 (0)730 783289
> Visit http://labs.ericsson.com !
>=20 *******************************************
>=20 _______________________________________________
> codec maili= ng=20 list
> co= dec@ietf.org <ht= tp://codec@ietf.org>
> https://www.ietf.org/mailman/listinfo/c= odec
>
>
_______________________________________________
codec=20 mailing list
codec@ietf.org <http://codec@ietf.org>
https://www.ietf.org/mailman/listinfo/cod= ec


________________________________= _______________
codec=20 mailing list
c= odec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

=



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




--
Greg Herlein
www.herlein.com
--0016368e25cc63014f046fb3482b-- From hsinnrei@adobe.com Mon Jul 27 10:41:51 2009 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 9BE663A6A46 for ; Mon, 27 Jul 2009 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl9Wm1eUIu-p for ; Mon, 27 Jul 2009 10:41:42 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id 80DD63A681D for ; Mon, 27 Jul 2009 10:41:38 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSm3mYeMKOFywNrXFeK/JnvLBmrE/feMd@postini.com; Mon, 27 Jul 2009 10:41:43 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6RHXEao001357; Mon, 27 Jul 2009 10:33:15 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n6RHdfY2021054; Mon, 27 Jul 2009 10:39:42 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 27 Jul 2009 10:39:40 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 27 Jul 2009 10:39:40 -0700 From: Henry Sinnreich To: Stephan Wenger , stephen botzko Date: Mon, 27 Jul 2009 10:39:36 -0700 Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoO3i6MyhHmjcYsJ0iHQaFks+uYzwAAwbdJ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C693B2F8EEC9hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:41:51 -0000 --_000_C693B2F8EEC9hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree we should raise the "delete hum" in the agenda bashing. Humming does not represent the little guys who depend on free codecs. Dear Chairs: Can you accommodate this? Henry On 7/27/09 7:17 PM, "Stephan Wenger" wrote: With respect to all this discussion, please note that there is an agenda it= em "agenda bashing" at the very beginning of the BOF. While I personally d= o not consider it to be overly productive to augment an (at this point) use= less presentation of two randomly chosen codec candidates with an even more= useless meta discussion on the agenda, I fear that's precisely what's goin= g to happen... Perhaps we should fix this whole issue by removing both agenda items :-) Regards, Stephan On 7/27/09 9:22 AM, "stephen botzko" wrote: Folks who participate in person or via the chatroom are represented. Folks= who choose not to participate are not represented. This is standard pract= ice in the IETF, there is no other way to decide things here. Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 11:54 AM, Henry Sinnreich wrot= e: The little guys on the Internet who depend on free codecs will still not be= represented. Even if they turn out to be in minority. I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs. Take a look for example on the lists of users for free codecs - no names me= ntioned here. Henry On 7/27/09 5:25 PM, "stephen botzko" > wrote: Hi Henry I believe that hums include chatroom support/dissent. Regards, Stephen Botzko Polycom On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich > wrote: The hum item is not fair nor representative IMO, since it favors people who= have a travel budget. >7. HUM on if the IETF should form this WG (All, 15 min) I would like to understand how/why the hum is representative for the Intern= et industry, since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs. My personal 2 cents. Henry On 7/27/09 10:52 AM, "Jean-Marc Valin" > wrote: Hi, Indeed, the link has not been updated. The updated agenda was posted here: http://www.ietf.org/mail-archive/web/codec/current/msg00241.html Regards, Jean-Marc Ingemar Johansson S a =E9crit : > Hi > > I am a bit curious regarding the agenda for the codec BoF > Is this the latest ? > http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the (fa= lse?) impression that it was not the intention to present any codecs and in= stead focus on the question "should IETF do this?" > > > Regards > /Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer, IETF "nethead" > EAB/TVK - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Lule=E5, Sweden > Tel: +46 (0)10 7143042 > ECN: 852-43042 > ECC: 852-19042 > Mobile: +46 (0)730 783289 > Visit http://labs.ericsson.com ! > ******************************************* > _______________________________________________ > 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 _______________________________________________ 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 --_000_C693B2F8EEC9hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Agenda for the Codec Bof I agree we should raise the “delete hum” in the agenda ba= shing.
Humming does not represent the little guys who depend on free codecs.

Dear Chairs: Can you accommodate this?

Henry


On 7/27/09 7:17 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

With respect to all this d= iscussion, please note that there is an agenda item “agenda bashing&#= 8221; at the very beginning of the BOF.  While I personally do not con= sider it to be overly productive to augment an (at this point) useless pres= entation of two randomly chosen codec candidates with an even more useless = meta discussion on the agenda, I fear that’s precisely what’s g= oing to happen...
Perhaps we should fix this whole issue by removing both agenda items :-) Regards,
Stephan




On 7/27/09 9:22 AM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

Folks who participa= te in person or via the chatroom are represented.  Folks who choose not to participate are not represented.  This is standard = practice in the IETF, there is no other way to decide things here.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:54 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
The little guys on the Internet who = depend on free codecs will still not be represented.
Even if they turn out to be in minority.

I table for this reason to delete the humming item, or find a better way to= safeguard their dependence on free codecs.
Take a look for example on the lists of users for free codecs – no na= mes mentioned here.

Henry



On 7/27/09 5:25 PM, "stephen botzko" <stephen.botzko@gmail.com <http://stephen.botzko@gmail.com> > wrote:

Hi Henry

I believe that hums include chatroom support/dissent.

Regards,
Stephen Botzko
Polycom

On Mon, Jul 27, 2009 at 11:16 AM, Henry Sinnreich <hsinnrei@adobe.com <= http://hsinnrei@adobe.com> > wrote:
The hum item is not fair nor representative= IMO, since it favors people who have a travel budget.

>7. HUM on if the IETF should form this WG (All, 15 min)

I would like to understand how/why the hum is representative for the Intern= et industry,
since it looks humming disadvantages the little guys, exactly those who dep= end on free codecs.

My personal 2 cents.
Henry



On 7/27/09 10:52 AM, "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca <http://jean-marc.valin@usherbrooke.ca>  <http://je= an-marc.valin@usherbrooke.ca> > wrote:

Hi,

Indeed, the link has not been updated. The updated agenda was posted here:<= BR> http://www.ietf.org/mail-archive/web/codec/current/msg00241.html

Regards,

        Jean-Marc

Ingemar Johansson S a écrit :
> Hi
>
> I am a bit curious regarding the agenda for the codec BoF
> Is this the latest ?
> http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > I have probably missed a lot as I have been on vacation but I got the = (false?) impression that it was not the intention to present any codecs and= instead focus on the question "should IETF do this?"
>
>
> Regards
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVK - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com !
> *******************************************
> _______________________________________________
> codec mailing list
> codec@ietf.org <http://codec@ietf.org>  <http://codec@ietf.org>
> https://www.ie= tf.org/mailman/listinfo/codec
>
>
_______________________________________________
codec mailing list
codec@ietf.org <http://codec@ietf.org>  <http://codec@ietf.org>
https://www.ietf.or= g/mailman/listinfo/codec

codec@ietf.org <http://codec@ietf.org>
https://www.ietf.or= g/mailman/listinfo/codec



_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C693B2F8EEC9hsinnreiadobecom_-- From stefan.sayer@iptego.com Mon Jul 27 12:36:52 2009 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 06CAE3A69CE for ; Mon, 27 Jul 2009 12:36:52 -0700 (PDT) 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 BL539msgZc1W for ; Mon, 27 Jul 2009 12:36:51 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id A06043A693C for ; Mon, 27 Jul 2009 12:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id C745C1154094; Mon, 27 Jul 2009 21:36:50 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iatug28ezYqu; Mon, 27 Jul 2009 21:36:50 +0200 (CEST) Received: from [192.168.10.100] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id 8354D1154090; Mon, 27 Jul 2009 21:36:50 +0200 (CEST) Message-ID: <4A6E01D3.2040600@iptego.com> Date: Mon, 27 Jul 2009 21:36:51 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Patrick Luthi References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> In-Reply-To: <20090727135713.75DB0296D80@smtp-03.vtx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:36:52 -0000 Hi o Patrick Luthi [07/27/09 15:57]: > Hi, > > I am surprised to still see codecs listed in item 4 of the agenda. As I > said before I think that it would be best to have more time to discuss > the other items of the agenda. So, please remove the codec presentations > from the agenda! in the beginning it was questioned whether a) there is enough expertise in the IETF to develop an IWAC b) there is suitable RF codec technology available. If now there is - thanks to the existence of codec candidates - consensus that both a and b are met then it probably does not make sense to present the candidates themselves. Best Regards Stefan Sayer From ron.even.tlv@gmail.com Mon Jul 27 14:50:23 2009 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 3BF1C3A6A9F for ; Mon, 27 Jul 2009 14:50:23 -0700 (PDT) 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 Le1g8SW50jaW for ; Mon, 27 Jul 2009 14:50:22 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 2BCAB3A6905 for ; Mon, 27 Jul 2009 14:50:22 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so860223eye.31 for ; Mon, 27 Jul 2009 14:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=/+PbsYFt6H9aOgsnA8t4AATNd5MZwbWQnUP/SzKle3c=; b=RI6uBX0KRxN5XdcGwjWp2uxd19iZNEnlxo5ekj/P29FKXtWDr2mYgvf5GEcWvQjM8B sytYVeZRJiEFzPJz6Bc+RAV/2wwvnv87t+U1oDowUbYz3ku1y27MEiHRkGLwPinaWHO7 KVspbcMZQ7ODPKqAbLHSAll/sEGQXPVN7nqLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=JbWG+Rz2iJDvZe7M0QPXNbXcOwHc66kKMvuXPWou6GnmSSU8BR38jmzp5V72Pwgca8 dYEjHyHF3IRQlY/ZH6JDATKp3z62mNrU03EmbRtKKTcMHdGYDeYBtM8B1RYrdf23tOig A456WgKpj4Y6OcrDUPrTTPNkIfKCxXZgsI5k4= Received: by 10.211.194.4 with SMTP id w4mr8915225ebp.46.1248731421043; Mon, 27 Jul 2009 14:50:21 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id 10sm408828eyz.11.2009.07.27.14.50.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 14:50:20 -0700 (PDT) From: "Roni Even" To: "'Stefan Sayer'" , "'Patrick Luthi'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> In-Reply-To: <4A6E01D3.2040600@iptego.com> Date: Tue, 28 Jul 2009 00:48:30 +0300 Message-ID: <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoO8ZrFjIrOG08+TKa1PFHhAtU/KwAEg6NQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:50:23 -0000 Hi, Having two codec suggested does not represent expertise to review codec work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, which you consider expertise, but no capability to do a real review and quality assessment Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Stefan Sayer > Sent: Monday, July 27, 2009 10:37 PM > To: Patrick Luthi > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof > > Hi > > o Patrick Luthi [07/27/09 15:57]: > > Hi, > > > > I am surprised to still see codecs listed in item 4 of the agenda. As > I > > said before I think that it would be best to have more time to > discuss > > the other items of the agenda. So, please remove the codec > presentations > > from the agenda! > in the beginning it was questioned whether > a) there is enough expertise in the IETF to develop an IWAC > b) there is suitable RF codec technology available. > > If now there is - thanks to the existence of codec candidates - > consensus that both a and b are met then it probably does not make > sense > to present the candidates themselves. > > Best Regards > Stefan Sayer > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From lars.eggert@nokia.com Mon Jul 27 23:23:09 2009 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 A29843A6819 for ; Mon, 27 Jul 2009 23:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.044, 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 ko9SUgZS32gW for ; Mon, 27 Jul 2009 23:23:09 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id A18153A6407 for ; Mon, 27 Jul 2009 23:23:08 -0700 (PDT) Received: from [IPv6:2001:df8::80:225:ff:fe45:eccf] ([IPv6:2001:df8:0:80:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6S6MtLY069882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 09:22:57 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> From: Lars Eggert To: Roni Even In-Reply-To: <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> Content-Type: multipart/signed; boundary=Apple-Mail-118--127969064; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 08:22:50 +0200 References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 28 Jul 2009 09:22:57 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 06:23:09 -0000 --Apple-Mail-118--127969064 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-7-27, at 23:48, Roni Even wrote: > Having two codec suggested does not represent expertise to review > codec > work. The IETF "rubber stamped" the iLBC codec. There was a proposed > codec, > which you consider expertise, but no capability to do a real review > and > quality assessment agree with Roni. Having codec specs available that (apparently) fit the requirements is nice, but it's not clear at all that that means that the experts who have created these codecs will actively participate in an IETF effort that would be based on something other than their initial candidate submission. Lars --Apple-Mail-118--127969064 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MjgwNjIyNTBaMCMGCSqGSIb3DQEJBDEWBBS1zB2nfTPZ8mZV MHhxHoI5Hc+bEjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAQC+hEHGEKbJuG25kS0vS2uNLpJoz3xG7vIjyt8XhOI4U+wW1WO7h T4ojqMdBSVc8+CDXIV/6eeTj0hvxaTG3WQLAOqZECpYiJGf96W6RjihG1TSfFQxyZ7sQAnu3OCGb mV9qUF62KsLsazsruTJJeI1sfkQw3CsyIh2zwBVARs9RDHlPG2oWombgzjU/WNqqj+elEDGnxoud C5HEQbj2Jv+ydn+eYReQA1RJjl8zGCzXyucKKHzDxtJjb1pm8N8CahfJ7dgItQDYIwYiau7xrO5B 5swGnb2iupexePndAT/u+xFCsIQfC8BFxAAB5CwzPXAZpel3pE9wJALInH8PKAAAAAAAAA== --Apple-Mail-118--127969064-- From gregory.ietf@gmail.com Tue Jul 28 02:06:06 2009 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 523CE3A6CEB for ; Tue, 28 Jul 2009 02:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 yCxJ1gpZVN0q for ; Tue, 28 Jul 2009 02:06:05 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E1DBE3A6D9B for ; Tue, 28 Jul 2009 02:06:02 -0700 (PDT) Received: by pxi9 with SMTP id 9so6609pxi.29 for ; Tue, 28 Jul 2009 02:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=85rSClsLDuyY2W5vkkbayqIFUvgW0AErcvuaf7qfY8c=; b=bhUulManx7CJmQJukfBleUrc9LaLhj8wzgEy+Te1UKdCkeW1/nikYC9bHMV6O0WMYa 07kmxK/Fo1rqaA3KJDO0P9UW1YheGO84y5HZxuSPyJ6ui0hVSzdJtl8En6B4EJiCY1fe vsnIH37HziX7amxSg8yAIqT7bA6MIDlG1wpSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=u8IWHvT2wCMWCjI6j94uTW9iNqpvHNVcriHJfWlJ/oRvThJfr/bybysI1wMTYORg+2 SbMg6NVJ82kPYUhwfRx1/9X9iIoa3M9cZlPT9V1Nnz904oBSHQm1Fyy79/YHq7irVpFV VczrryV7/26RoL4Uy5W5ojUhzJK11Qp1fH/Pg= Received: by 10.114.153.17 with SMTP id a17mr11545859wae.162.1248771962312; Tue, 28 Jul 2009 02:06:02 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id n40sm15575314wag.30.2009.07.28.02.05.59 (version=SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 02:06:01 -0700 (PDT) Message-ID: <4a6ebf79.28d7720a.7c3d.75f0@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jul 2009 02:05:55 -0700 To: "Roni Even" , "'Stefan Sayer'" , "'Patrick Luthi'" From: "Gregory M. Lebovitz" In-Reply-To: <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_211047359==.ALT" Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:06:06 -0000 --=====================_211047359==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Folks, Let's look again at the charter's text, as posted on the current Agenda at: http://tools.ietf.org/agenda/75/codec.html "4. What type of engineering work would this be? ( 25 min ) Have presentations on the two proposed codecs. Focus is to make sure it looks feasible to do the technical work to meet the goals. This should also help clarify what type of work is being considered." Perhaps the sentence should change as: s/presentations on the two proposed codecs/presentations on two example codecs ?? So, less than these being discussions of these particular codecs as candidates or lead candidates, these two are just serving as archetypical models of the type of codec we might see if the work progresses, SO THAT THE BoF PARTICIPANTS CAN DISCUSS HOW WE WILL DO TECHNICAL work. The goal is NOT to do the technical work on the codecs at this BoF. This is not a beauty contest of these codecs. It's more like "Here are two specimens of this species. Let's note some characteristics about this species. Now, how would we go about analyzing this species further?" Versus "I like the left specimen because he seems bigger and softer and darker. Can I take it home?" We aren't doing the latter. The idea should be to say, "Okay, we've seen two examples. We aren't going to dig into those two codecs in particular, but if we did decide do dig into codecs roughly like these, what TYPE of: - analysis would we want to do? - questions would we ask about such example codecs? - metrics would we use for comparing multiple examples? - decsisions would be need to make in order to take a codec to RFC or not? See? It's not about THESE CODECS, they are just examples to jump start discussion about the content that must ultimately fill out a charter. Does that make sense? As a second order comment, I appreciate seeing a number of different codecs being thrown at the mail list by their handlers during this bof period because: - it helps us gauge the level of interest and contribution in doing this work, - ensures we have a diversity of options that will be made available (i.e. not just one vendor pushing their kool-aide) - helps us calibrate our expectations about the types of codecs we would see if we proceeded the work. Hope that helps, Gregory. At 02:48 PM 7/27/2009, Roni Even wrote: >Hi, >Having two codec suggested does not represent expertise to review codec >work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, >which you consider expertise, but no capability to do a real review and >quality assessment >Roni Even > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Stefan Sayer > > Sent: Monday, July 27, 2009 10:37 PM > > To: Patrick Luthi > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > > Hi > > > > o Patrick Luthi [07/27/09 15:57]: > > > Hi, > > > > > > I am surprised to still see codecs listed in item 4 of the agenda. As > > I > > > said before I think that it would be best to have more time to > > discuss > > > the other items of the agenda. So, please remove the codec > > presentations > > > from the agenda! > > in the beginning it was questioned whether > > a) there is enough expertise in the IETF to develop an IWAC > > b) there is suitable RF codec technology available. > > > > If now there is - thanks to the existence of codec candidates - > > consensus that both a and b are met then it probably does not make > > sense > > to present the candidates themselves. > > > > Best Regards > > Stefan Sayer > > > > _______________________________________________ > > 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 --=====================_211047359==.ALT Content-Type: text/html; charset="us-ascii" Folks,
Let's look again at the charter's text, as posted on the current Agenda at:
http://tools.ietf.org/agenda/75/codec.html 

"4. What type of engineering work would
this be? ( 25 min )
Have presentations on the two proposed codecs. Focus is to make sure it
looks feasible to do the technical work to meet the goals. This should
also help clarify what type of work is being considered."

Perhaps the sentence should change as:
 s/presentations on the two proposed codecs/presentations on two
example codecs
??

So, less than these being discussions of these particular codecs as
candidates or lead candidates, these two are just serving as archetypical
models of the type of codec we might see if the work progresses, SO THAT
THE BoF PARTICIPANTS CAN DISCUSS HOW WE WILL DO TECHNICAL work. The goal
is NOT to do the technical work on the codecs at this BoF. This is not a
beauty contest of these codecs. It's more like "Here are two
specimens of this species. Let's note some characteristics about this
species. Now, how would we go about analyzing this species further?"
Versus "I like the left specimen because he seems bigger and softer
and darker. Can I take it home?" We aren't doing the latter.

The idea should be to say, "Okay, we've seen two examples. We aren't
going to dig into those two codecs in particular, but if we did decide do
dig into codecs roughly like these, what TYPE of:
 - analysis would we want to do? 
 - questions would we ask about such example codecs?
 - metrics would we use for comparing multiple examples?
 - decsisions would be need to make in order to take a codec to RFC
or not?

See? It's not about THESE CODECS, they are just examples to jump start
discussion about the content that must ultimately fill out a charter.

Does that make sense?

As a second order comment, I appreciate seeing a number of different
codecs being thrown at the mail list by their handlers during this bof
period because:
 - it helps us gauge the level of interest and contribution in doing
this work,
 - ensures we have a diversity of options that will be made
available (i.e. not just one vendor pushing their kool-aide)
 - helps us calibrate our expectations about the types of codecs we
would see if we proceeded the work.

Hope that helps,
Gregory.
At 02:48 PM 7/27/2009, Roni Even wrote:
Hi,
Having two codec suggested does not represent expertise to review codec
work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec,
which you consider expertise, but no capability to do a real review and
quality assessment
Roni Even

> -----Original Message-----
> From: codec-bounces@ietf.org [ mailto:codec-bounces@ietf.org] On Behalf
> Of Stefan Sayer
> Sent: Monday, July 27, 2009 10:37 PM
> To: Patrick Luthi
> Cc: codec@ietf.org
> Subject: Re: [codec] Agenda for the Codec Bof
>
> Hi
>
> o Patrick Luthi [07/27/09 15:57]:
> > Hi,
> >
> > I am surprised to still see codecs listed in item 4 of the agenda. As
> I
> > said before I think that it would be best to have more time to
> discuss
> > the other items of the agenda. So, please remove the codec
> presentations
> > from the agenda!
> in the beginning it was questioned whether
> a) there is enough expertise in the IETF to develop an IWAC
> b) there is suitable RF codec technology available.
>
> If now there is - thanks to the existence of codec candidates -
> consensus that both a and b are met then it probably does not make
> sense
> to present the candidates themselves.
>
> Best Regards
> Stefan Sayer
>
> _______________________________________________
> 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
--=====================_211047359==.ALT-- From koen.vos@skype.net Tue Jul 28 02:20:12 2009 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 D351C3A6D3F for ; Tue, 28 Jul 2009 02:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=1.083, 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 FJ9VF9nMZWz1 for ; Tue, 28 Jul 2009 02:20:12 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id CFE7E3A6C03 for ; Tue, 28 Jul 2009 02:20:11 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A66FB2007C344 for ; Tue, 28 Jul 2009 11:20:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=xf3e1xZ9Vzzm 4WXsZaTF5QSiUi8=; b=SG0A3SJKiIuwpzRuqEiMvjeQGATb6mTPv++WV8v/m4lV xTRTBn7NKcld4MPxdVTyTumUBboHHDuFIw3yCv8ZpIat8Oai32cDA1ISxxr4tsO0 O16RkwAUuVJO4l+MO7Bb19AeG5OLBIyLPJlaQq0Y1wQGxhCbLvOKc/xVqC5C2n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=qtgx/1nq0QXoKGnjIM/N L5G25nJN985PG7UGryZKaWr/oWbUyxyPX7rqR//Hb/WMp1Y1KUfqNfO0GoXSpfgu EIXOw/pu9KW+UcDmk/ioZonioa0XRAJThrfNxZ4ls05fAbzIl0cRXmq0uHBMoTcL V6nR5QefOIkRsaPOsN2sK8A= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A51612007C203 for ; Tue, 28 Jul 2009 11:20:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9AJCm1MnUDv for ; Tue, 28 Jul 2009 11:20:02 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id B68B42007C150; Tue, 28 Jul 2009 11:20:02 +0200 (CEST) Received: from 84-55-127-131.customers.ownit.se (84-55-127-131.customers.ownit.se [84.55.127.131]) by mail.skype.net (Horde Framework) with HTTP; Tue, 28 Jul 2009 02:20:02 -0700 Message-ID: <20090728022002.66455hw3upkze7ya@mail.skype.net> Date: Tue, 28 Jul 2009 02:20:02 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> In-Reply-To: <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:20:12 -0000 Clearly, we've already done much more than suggesting two codecs. For instance, we've had detailed discussions about what it takes to make a codec work on the Internet. We seemed to agree that the codec should support not only packet loss concealment, but also time compression/stretching to handle network jitter. (Incidentally, such time modification is not supported by any ITU, 3GPP or ETSI codec, which complicates their use for Internet applications.) Or take the technical discussion between Jean-Marc and myself. We went over many details of SILK and CELT, and have been making suggestions how to improve each codec. I will continue to participate actively in any technical review and quality assessment. best, koen. Quoting lars.eggert@nokia.com: > Hi, > > On 2009-7-27, at 23:48, Roni Even wrote: >> Having two codec suggested does not represent expertise to review codec >> work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, >> which you consider expertise, but no capability to do a real review and >> quality assessment > > agree with Roni. Having codec specs available that (apparently) fit > the requirements is nice, but it's not clear at all that that means > that the experts who have created these codecs will actively > participate in an IETF effort that would be based on something other > than their initial candidate submission. > > Lars From stephen.botzko@gmail.com Tue Jul 28 04:47:05 2009 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 D20583A6D9C for ; Tue, 28 Jul 2009 04:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.860, 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 j36iUsNk3vkV for ; Tue, 28 Jul 2009 04:47:04 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 0F72F3A6E59 for ; Tue, 28 Jul 2009 04:46:58 -0700 (PDT) Received: by fxm12 with SMTP id 12so67261fxm.37 for ; Tue, 28 Jul 2009 04:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X+fpr6NQ9X83K0oCvLSwHhMyUMU/asKAaSBK6M273sM=; b=RfEKP2yejYlE1qYrkvmah11gKSLI4qfvFbEgc6B1vl8y55OM6YJ0wszgiy7tNG9g+R pNOM3oBr0/FECfVifN3at9NveZorzBLAIsKDeAup0OOHUhEZRudBWwgDdBh7v7brZ56P sLr3eCw9GCh0fu7pe3InY3puR06E8//d/9nCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=D8aa9+L5hzkfDbLH9P0Ovg6f24dvJiDB2Snu4uolII0g9efniBQCWpMuWgTWS097Mw cQbS6W+hgeFxGmAE1LBe7o8KDy2QGlPiWMULVxYkcOg3wXbC9sUC1n0cjxOdCUr3/Ky9 HIYc0menoMnTcSXI+y8m7KjUUsTRw+aDZx3fU= MIME-Version: 1.0 Received: by 10.223.119.198 with SMTP id a6mr3311188far.42.1248781609454; Tue, 28 Jul 2009 04:46:49 -0700 (PDT) In-Reply-To: <4a6ebf79.28d7720a.7c3d.75f0@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <4a6ebf79.28d7720a.7c3d.75f0@mx.google.com> Date: Tue, 28 Jul 2009 07:46:49 -0400 Message-ID: <6e9223710907280446h57a23dadl79d2ee74cb724044@mail.gmail.com> From: stephen botzko To: "Gregory M. Lebovitz" Content-Type: multipart/alternative; boundary=001636c5b91e3bcebf046fc2a0ae Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:47:05 -0000 --001636c5b91e3bcebf046fc2a0ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline comment Regards, Stephen Botzko Polycom On Tue, Jul 28, 2009 at 5:05 AM, Gregory M. Lebovitz wrote: > Folks, > Let's look again at the charter's text, as posted on the current Agenda at: > http://tools.ietf.org/agenda/75/codec.html > > "4. What type of engineering work would > this be? ( 25 min ) > Have presentations on the two proposed codecs. Focus is to make sure it > looks feasible to do the technical work to meet the goals. This should > also help clarify what type of work is being considered." > > Perhaps the sentence should change as: > s/presentations on the two proposed codecs/presentations on two > example codecs > ?? > > So, less than these being discussions of these particular codecs as > candidates or lead candidates, these two are just serving as archetypical > models of the type of codec we might see if the work progresses, SO THAT > THE BoF PARTICIPANTS CAN DISCUSS HOW WE WILL DO TECHNICAL work. The goal > is NOT to do the technical work on the codecs at this BoF. This is not a > beauty contest of these codecs. It's more like "Here are two > specimens of this species. Let's note some characteristics about this > species. Now, how would we go about analyzing this species further?" > Versus "I like the left specimen because he seems bigger and softer > and darker. Can I take it home?" We aren't doing the latter. > > The idea should be to say, "Okay, we've seen two examples. We aren't > going to dig into those two codecs in particular, but if we did decide do > dig into codecs roughly like these, what TYPE of: > - analysis would we want to do? > - questions would we ask about such example codecs? > - metrics would we use for comparing multiple examples? > - decsisions would be need to make in order to take a codec to RFC > or not? > > See? It's not about THESE CODECS, they are just examples to jump start > discussion about the content that must ultimately fill out a charter. > > Does that make sense? > > I agree these questions matter, though I think that we can discuss them just as effective/y w/o the presentations. My issue with the presentations is the amount of time they consume (about 1/4 of the total meeting), I just don't see a sufficient return on the time invested. > As a second order comment, I appreciate seeing a number of different > codecs being thrown at the mail list by their handlers during this bof > period because: > - it helps us gauge the level of interest and contribution in doing > this work, > - ensures we have a diversity of options that will be made > available (i.e. not just one vendor pushing their kool-aide) > - helps us calibrate our expectations about the types of codecs we > would see if we proceeded the work. > > Hope that helps, > Gregory. > > > At 02:48 PM 7/27/2009, Roni Even wrote: > > Hi, > Having two codec suggested does not represent expertise to review codec > work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, > which you consider expertise, but no capability to do a real review and > quality assessment > Roni Even > > > -----Original Message----- > > From: codec-bounces@ietf.org [ mailto:codec-bounces@ietf.org] > On Behalf > > Of Stefan Sayer > > Sent: Monday, July 27, 2009 10:37 PM > > To: Patrick Luthi > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > > Hi > > > > o Patrick Luthi [07/27/09 15:57]: > > > Hi, > > > > > > I am surprised to still see codecs listed in item 4 of the agenda. As > > I > > > said before I think that it would be best to have more time to > > discuss > > > the other items of the agenda. So, please remove the codec > > presentations > > > from the agenda! > > in the beginning it was questioned whether > > a) there is enough expertise in the IETF to develop an IWAC > > b) there is suitable RF codec technology available. > > > > If now there is - thanks to the existence of codec candidates - > > consensus that both a and b are met then it probably does not make > > sense > > to present the candidates themselves. > > > > Best Regards > > Stefan Sayer > > > > _______________________________________________ > > 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 > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --001636c5b91e3bcebf046fc2a0ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline comment

Regards,
Stephen Botzko
Polycom

On Tue, Jul 28, 2009 at 5:05 AM, Gregory M. Lebovitz <gregory.ietf@g= mail.com> wrote:
Folks,
Let's look again at the charter's text, as posted on the current Ag= enda at:
http://tools.ietf.org/agenda/75/codec.html 

"4. What type of engin=
eering work would
this be? ( 25 min )
Have presentations on the two proposed codecs. Focus is to make sure it
looks feasible to do the technical work to meet the goals. This should
also help clarify what type of work is being considered."

Perhaps the sentence should change as:
=A0s/presentations on the two proposed codecs/presentations on two
example codecs
??

So, less than these being discussions of these particular codecs as
candidates or lead candidates, these two are just serving as archetypical
models of the type of codec we might see if the work progresses, SO THAT
THE BoF PARTICIPANTS CAN DISCUSS HOW WE WILL DO TECHNICAL work. The goal
is NOT to do the technical work on the codecs at this BoF. This is not a
beauty contest of these codecs. It's more like "Here are two
specimens of this species. Let's note some characteristics about this
species. Now, how would we go about analyzing this species further?"
Versus "I like the left specimen because he seems bigger and softer
and darker. Can I take it home?" We aren't doing the latter.

The idea should be to say, "Okay, we've seen two examples. We aren=
't
going to dig into those two codecs in particular, but if we did decide do
dig into codecs roughly like these, what TYPE of:
=A0- analysis would we want to do?=20
=A0- questions would we ask about such example codecs?
=A0- metrics would we use for comparing multiple examples?
=A0- decsisions would be need to make in order to take a codec to RFC
or not?

See? It's not about THESE CODECS, they are just examples to jump start
discussion about the content that must ultimately fill out a charter.

Does that make sense?
I agree these questions matter, though I thin= k that we can discuss them just as effective/y w/o the presentations.=A0 My= issue with the presentations is the amount of time they consume (about 1/4= of the total meeting), I just don't see a sufficient return on the tim= e invested.
A=
s a second order comment, I appreciate seeing a number of different
codecs being thrown at the mail list by their handlers during this bof
period because:
=A0- it helps us gauge the level of interest and contribution in doing
this work,
=A0- ensures we have a diversity of options that will be made
available (i.e. not just one vendor pushing their kool-aide)
=A0- helps us calibrate our expectations about the types of codecs we
would see if we proceeded the work.

Hope that helps,
Gregory.
At 02:48 PM 7/27/2009, Roni Even wr= ote:
Hi,
Having two codec suggested does not represent expertise to review codec
work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec,
which you consider expertise, but no capability to do a real review and
quality assessment
Roni Even

> -----Original Message-----
> From: code= c-bounces@ietf.org [ mailto:codec-bounces@ietf.org] On Behalf
> Of Stefan Sayer
> Sent: Monday, July 27, 2009 10:37 PM
> To: Patrick Luthi
> Cc: codec@ietf.org=
> Subject: Re: [codec] Agenda for the Codec Bof
>
> Hi
>
> o Patrick Luthi [07/27/09 15:57]:
> > Hi,
> >
> > I am surprised to still see codecs listed in item 4 of the agenda. As
> I
> > said before I think that it would be best to have more time to
> discuss
> > the other items of the agenda. So, please remove the codec
> presentations
> > from the agenda!
> in the beginning it was questioned whether
> a) there is enough expertise in the IETF to develop an IWAC
> b) there is suitable RF codec technology available.
>
> If now there is - thanks to the existence of codec candidates -
> consensus that both a and b are met then it probably does not make
> sense
> to present the candidates themselves.
>
> Best Regards
> Stefan Sayer
>
> _______________________________________________
> 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

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


--001636c5b91e3bcebf046fc2a0ae-- From julian.spittka@skype.net Tue Jul 28 05:00:55 2009 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 507943A6840 for ; Tue, 28 Jul 2009 05:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 QvxzWClrJGSV for ; Tue, 28 Jul 2009 05:00:54 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id F136F3A682B for ; Tue, 28 Jul 2009 05:00:53 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id DEB532007CB63 for ; Tue, 28 Jul 2009 14:00:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=reply-to:from :to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding; s=mail; bh=ZQX21yy7td9W ESu0lfW9H4SUpY0=; b=XlFdTATH0O3VaHl+wZUr/75E+BDjiGoW6+k27PyGvl1u O1F+wlesCy4G0up5XCq7edIX7guqNaaUalx++A7gaqFRl4OlHZHB1VpNUaELOJ5E f+UEcv8S5CsB7fxU4H8S+VbABitIRvFw5RZRsnn+QwpU13aGL4UBOj0q6FjQv68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=reply-to:from:to :references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=MNXJ83 BY1/zLddljDNn0Tv3mrgzCqF0jfy0/+0Wu5rRXoa6mfi+oQ1VrPDbFDfYmfbaHER okNVCL/BxJeYvdnzh4QO2zVlU+os+QheY7cz/ZPlepg5zS8ZMhAOw1TN9g0d2s3t 86b0vlO8ERfllA9F9xDL3ATbmEKHCKg0hiwTw= Received: from outlook (p50874BFD.dip.t-dialin.net [80.135.75.253]) by mail.skype.net (Postfix) with ESMTPS id 78D662007A94D for ; Tue, 28 Jul 2009 14:00:54 +0200 (CEST) From: "Julian Spittka" To: References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <20090728022002.66455hw3upkze7ya@mail.skype.net> In-Reply-To: <20090728022002.66455hw3upkze7ya@mail.skype.net> Date: Tue, 28 Jul 2009 13:59:37 +0200 Organization: Skype Message-ID: <000001ca0f7b$0f92bf70$2eb83e50$@spittka@skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPZKQ7Pn3Lp3V3RDybUDA/Id7vRwAFJgAQ Content-Language: en-us Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: julian.spittka@skype.net List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:00:55 -0000 Let's also keep in mind that it doesn't take any specific knowledge in designing a codec to come up with requirements for a new internet codec and to identify the shortcomings of existing codecs. Anybody who has dealt with VoIP systems will be able to contribute in that area and participate in the discussion. Look at it as a "wish list" that will be compared against the feature set of the codec candidates. Regards, Julian. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos Sent: Tuesday, July 28, 2009 11:20 AM To: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof Clearly, we've already done much more than suggesting two codecs. For instance, we've had detailed discussions about what it takes to make a codec work on the Internet. We seemed to agree that the codec should support not only packet loss concealment, but also time compression/stretching to handle network jitter. (Incidentally, such time modification is not supported by any ITU, 3GPP or ETSI codec, which complicates their use for Internet applications.) Or take the technical discussion between Jean-Marc and myself. We went over many details of SILK and CELT, and have been making suggestions how to improve each codec. I will continue to participate actively in any technical review and quality assessment. best, koen. Quoting lars.eggert@nokia.com: > Hi, > > On 2009-7-27, at 23:48, Roni Even wrote: >> Having two codec suggested does not represent expertise to review codec >> work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, >> which you consider expertise, but no capability to do a real review and >> quality assessment > > agree with Roni. Having codec specs available that (apparently) fit > the requirements is nice, but it's not clear at all that that means > that the experts who have created these codecs will actively > participate in an IETF effort that would be based on something other > than their initial candidate submission. > > Lars _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mramalho@cisco.com Tue Jul 28 06:06:42 2009 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 540313A6D49 for ; Tue, 28 Jul 2009 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 wktda4+Txr5F for ; Tue, 28 Jul 2009 06:06:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E081B3A68E9 for ; Tue, 28 Jul 2009 06:06:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJeUbkpAZnme/2dsb2JhbAC7Tognj2IFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="52039378" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2009 13:06:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SD6fSg031487; Tue, 28 Jul 2009 09:06:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6SD6fjf027665; Tue, 28 Jul 2009 13:06:41 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:06:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 09:06:40 -0400 Message-ID: In-Reply-To: <20090728022002.66455hw3upkze7ya@mail.skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoPZJ+7HLG9DoTiT3CLfjlua1TYYwAG5mNA X-Priority: 5 Priority: Non-Urgent Importance: low References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se><4A6D6AD0.30504@usherbrooke.ca><001801ca0ea2$cc71a090$9446c80a@china.huawei.com><130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se><20090727135713.75DB0296D80@smtp-03.vtx.ch><4A6E01D3.2040600@iptego.com><4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com><594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <20090728022002.66455hw3upkze7ya@mail.skype.net> From: "Michael Ramalho (mramalho)" To: "Koen Vos" , X-OriginalArrivalTime: 28 Jul 2009 13:06:41.0586 (UTC) FILETIME=[3FE9B120:01CA0F84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4081; t=1248786401; x=1249650401; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[codec]=20Agenda=20for=20the=20Codec=20 Bof |Sender:=20 |To:=20=22Koen=20Vos=22=20,=20; bh=FsgewvxV7GhoKfK+3fxd45gR+LWrtGh4j0OVcRYvVHM=; b=SDru4soJpTl/Ymd3tWXBAWJ9y3M87FrapuoZN2ut7kwg6JdXa4ALjF/5hB NNCVIbJZVmyOKQK8/tP3Wx7Bjdif+6In7SAsPtzHR2JhVargdC2PUm4ccewA tjBPr3gSwY; Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:06:42 -0000 Re: " We seemed to agree that the codec =20 should support not only packet loss concealment, but also time =20 compression/stretching to handle network jitter. (Incidentally, such =20 time modification is not supported by any ITU, 3GPP or ETSI codec, =20 which complicates their use for Internet applications.)" Two quick comments: Comment 1: I believe the ITU-T *has* considered the time-modification ability of some codecs in P.862 (perceptual evaluation of speech quality) - so dependent on your definition of "supported" your parenthetical comment may or may not be accurate. While it is true that no ITU codec supports time modification natively (e.g., the slow-down/speed-up of model-based playout), overlap and add techniques can always be applied to such codec outputs to accomplish similar auditory ends. Comment 2: Some applications may not desire compression/stretching to be always enabled - and actually prefer "jumps in time" consistent with jitter buffer needs. For example any processing that depends on (piecewise) time-invariance of the send-to-receive path (e.g., network-based echo cancellers) can be designed to handle discrete "jumps in time" better than a some unknowable time-warping function. Also, musicians can detect extremely small deviations from perfect time (on the order of 1% change over 1/2 second from 1:1 time warping) - many music applications (classical music playout) may not desire this capability. So if "supported" means an option to enable such time warping - I would have no issue with your statement (and said attribute should be negotiated). If "supported" means a mandatory capability that cannot be turned off, then I think many applications would not desire that attribute. As an aside, the ITU-T clearly identifies "use cases" before designing a codec for reasons such as the above. You need to know if you are designing a codec for a singular use case (e.g. wideband speech with little likelihood of uses such as above) before one mandates a non-optional attribute (e.g., adaptive time playout). These use cases and resulting desired attributes should be reflected in the requirements (assuming a WG is formed). My $0.02, Michael Ramalho -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos Sent: Tuesday, July 28, 2009 5:20 AM To: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof Clearly, we've already done much more than suggesting two codecs. For instance, we've had detailed discussions about what it takes to =20 make a codec work on the Internet. We seemed to agree that the codec =20 should support not only packet loss concealment, but also time =20 compression/stretching to handle network jitter. (Incidentally, such =20 time modification is not supported by any ITU, 3GPP or ETSI codec, =20 which complicates their use for Internet applications.) Or take the technical discussion between Jean-Marc and myself. We went =20 over many details of SILK and CELT, and have been making suggestions =20 how to improve each codec. I will continue to participate actively in any technical review and =20 quality assessment. best, koen. Quoting lars.eggert@nokia.com: > Hi, > > On 2009-7-27, at 23:48, Roni Even wrote: >> Having two codec suggested does not represent expertise to review codec >> work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, >> which you consider expertise, but no capability to do a real review and >> quality assessment > > agree with Roni. Having codec specs available that (apparently) fit =20 > the requirements is nice, but it's not clear at all that that means =20 > that the experts who have created these codecs will actively =20 > participate in an IETF effort that would be based on something other =20 > than their initial candidate submission. > > Lars _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From stefan.sayer@iptego.com Tue Jul 28 06:27:01 2009 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 505BB3A6F7C for ; Tue, 28 Jul 2009 06:27:01 -0700 (PDT) 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 YzbKwXcjN+LF for ; Tue, 28 Jul 2009 06:27:00 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id CFE833A6ADD for ; Tue, 28 Jul 2009 06:26:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 138FF1154094; Tue, 28 Jul 2009 15:27:00 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e8wKcdr3Kaz; Tue, 28 Jul 2009 15:26:59 +0200 (CEST) Received: from [192.168.10.100] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id B599E1154090; Tue, 28 Jul 2009 15:26:59 +0200 (CEST) Message-ID: <4A6EFCA5.6040404@iptego.com> Date: Tue, 28 Jul 2009 15:27:01 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "Michael Ramalho (mramalho)" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se><4A6D6AD0.30504@usherbrooke.ca><001801ca0ea2$cc71a090$9446c80a@china.huawei.com><130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se><20090727135713.75DB0296D80@smtp-03.vtx.ch><4A6E01D3.2040600@iptego.com><4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com><594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <20090728022002.66455hw3upkze7ya@mail.skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:27:01 -0000 Hello, o Michael Ramalho (mramalho) [07/28/09 15:06]: > Re: " We seemed to agree that the codec > should support not only packet loss concealment, but also time > compression/stretching to handle network jitter. (Incidentally, such > time modification is not supported by any ITU, 3GPP or ETSI codec, > which complicates their use for Internet applications.)" > > Two quick comments: > > Comment 1: I believe the ITU-T *has* considered the time-modification > ability of some codecs in P.862 (perceptual evaluation of speech > quality) - so dependent on your definition of "supported" your > parenthetical comment may or may not be accurate. While it is true that > no ITU codec supports time modification natively (e.g., the > slow-down/speed-up of model-based playout), overlap and add techniques > can always be applied to such codec outputs to accomplish similar > auditory ends. I expect better performance of time scale modification natively in the codec ("supported" in the second sense), especially where extremely low playout delay is desired and with short frame sizes (e.g. 5ms) where OLA techniques (TD-WSOLA, PICOLA) do not work properly due to fundamental frequency of voice. > > Comment 2: Some applications may not desire compression/stretching to be > always enabled - and actually prefer "jumps in time" consistent with > jitter buffer needs. For example any processing that depends on Agreed. This needs to be parametrized between the dejitter buffer and the decoder, and thus be possible to disable. > (piecewise) time-invariance of the send-to-receive path (e.g., > network-based echo cancellers) can be designed to handle discrete "jumps > in time" better than a some unknowable time-warping function. Also, > musicians can detect extremely small deviations from perfect time (on > the order of 1% change over 1/2 second from 1:1 time warping) - many > music applications (classical music playout) may not desire this > capability. > > So if "supported" means an option to enable such time warping - I would > have no issue with your statement (and said attribute should be > negotiated). If "supported" means a mandatory capability that cannot be sorry, I don't understand this: "negotiated" in the codec development/selection process? Thanks Stefan > turned off, then I think many applications would not desire that > attribute. > > As an aside, the ITU-T clearly identifies "use cases" before designing a > codec for reasons such as the above. You need to know if you are > designing a codec for a singular use case (e.g. wideband speech with > little likelihood of uses such as above) before one mandates a > non-optional attribute (e.g., adaptive time playout). These use cases > and resulting desired attributes should be reflected in the requirements > (assuming a WG is formed). > > My $0.02, > > Michael Ramalho > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Tuesday, July 28, 2009 5:20 AM > To: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof > > Clearly, we've already done much more than suggesting two codecs. > > For instance, we've had detailed discussions about what it takes to > make a codec work on the Internet. We seemed to agree that the codec > should support not only packet loss concealment, but also time > compression/stretching to handle network jitter. (Incidentally, such > time modification is not supported by any ITU, 3GPP or ETSI codec, > which complicates their use for Internet applications.) > > Or take the technical discussion between Jean-Marc and myself. We went > over many details of SILK and CELT, and have been making suggestions > how to improve each codec. > > I will continue to participate actively in any technical review and > quality assessment. > > best, > koen. > > > Quoting lars.eggert@nokia.com: >> Hi, >> >> On 2009-7-27, at 23:48, Roni Even wrote: >>> Having two codec suggested does not represent expertise to review > codec >>> work. The IETF "rubber stamped" the iLBC codec. There was a proposed > codec, >>> which you consider expertise, but no capability to do a real review > and >>> quality assessment >> agree with Roni. Having codec specs available that (apparently) fit >> the requirements is nice, but it's not clear at all that that means >> that the experts who have created these codecs will actively >> participate in an IETF effort that would be based on something other >> than their initial candidate submission. >> >> Lars From mramalho@cisco.com Tue Jul 28 06:29:49 2009 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 5C3D13A6F7F for ; Tue, 28 Jul 2009 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 jCWHqxxh8tWw for ; Tue, 28 Jul 2009 06:29:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 18E683A6F78 for ; Tue, 28 Jul 2009 06:29:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPqZbkpAZnme/2dsb2JhbAC7a4gnj2EFgieBZQ X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="52089380" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2009 13:29:46 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SDTkgB011370; Tue, 28 Jul 2009 09:29:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6SDTkHr005682; Tue, 28 Jul 2009 13:29:46 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:29:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 09:29:45 -0400 Message-ID: In-Reply-To: <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Agenda for the Codec Bof Thread-Index: AcoO8ZrFjIrOG08+TKa1PFHhAtU/KwAEg6NQACCSzTA= X-Priority: 5 Priority: Non-Urgent Importance: low References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch><4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> From: "Michael Ramalho (mramalho)" To: "Roni Even" , "Stefan Sayer" , "Patrick Luthi" X-OriginalArrivalTime: 28 Jul 2009 13:29:46.0606 (UTC) FILETIME=[7972F8E0:01CA0F87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2587; t=1248787786; x=1249651786; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[codec]=20Agenda=20for=20the=20Codec=20 Bof |Sender:=20 |To:=20=22Roni=20Even=22=20,=0A=20= 20=20=20=20=20=20=20=22Stefan=20Sayer=22=20,=0A=20=20=20=20=20=20=20=20=22Patrick=20Luthi=22=20 ; bh=a53iLkgS512oSzRPO9dqIqsZHdgrwAz22Jz4b/iOfIw=; b=hXw9acUgIa5HEN5Th4dY4Axi5Nva4qIGqO+hrISiPAAYFdiEEhb1JGh68x RewwAXcYBkTEXoRErnmS10gaZKV7+Qw2pn5neC7TRQj3WVskQa2a+O61Z5/C mcuY21sUYb; Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:29:49 -0000 Hi Roni, Depends on your definition of "rubber stamped". To my knowledge iLBC is NOT a IETF standard. To be precise, iLBC is not documented in a standards track RFC (which would result in it being an IETF standard). RFC 3951 is an experimental RFC. Indeed the first significant paragraph of RFC 3951 states: " This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited." See http://www.ietf.org/tao.html for definitions of experimental RFCs. So, I believe that this IETF activity may result in the first IETF standard codec (if WG formed, work progressed, and standard process agreed). Michael Ramalho -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, July 27, 2009 5:49 PM To: 'Stefan Sayer'; 'Patrick Luthi' Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof Hi, Having two codec suggested does not represent expertise to review codec work. The IETF "rubber stamped" the iLBC codec. There was a proposed codec, which you consider expertise, but no capability to do a real review and quality assessment Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Stefan Sayer > Sent: Monday, July 27, 2009 10:37 PM > To: Patrick Luthi > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof >=20 > Hi >=20 > o Patrick Luthi [07/27/09 15:57]: > > Hi, > > > > I am surprised to still see codecs listed in item 4 of the agenda. As > I > > said before I think that it would be best to have more time to > discuss > > the other items of the agenda. So, please remove the codec > presentations > > from the agenda! > in the beginning it was questioned whether > a) there is enough expertise in the IETF to develop an IWAC > b) there is suitable RF codec technology available. >=20 > If now there is - thanks to the existence of codec candidates - > consensus that both a and b are met then it probably does not make > sense > to present the candidates themselves. >=20 > Best Regards > Stefan Sayer >=20 > _______________________________________________ > 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 jason.fischl@skype.net Tue Jul 28 11:17:58 2009 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 8F8AE3A6EF4 for ; Tue, 28 Jul 2009 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 utPhCOSxinyu for ; Tue, 28 Jul 2009 11:17:57 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 7A7233A6EF5 for ; Tue, 28 Jul 2009 11:17:57 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.43,284,1246863600"; d="scan'208";a="54700335" Received: from unknown (HELO den-exb-01.corp.ebay.com) ([10.101.44.9]) by den-mipot-002.corp.ebay.com with ESMTP; 28 Jul 2009 11:17:58 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by den-exb-01.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 12:17:57 -0600 Received: from 130.129.67.225 ([130.129.67.225]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Jul 2009 18:17:57 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 28 Jul 2009 20:17:55 +0200 From: Jason Fischl To: Message-ID: Thread-Topic: Updated Charter Proposal Take 2 Thread-Index: AcoPr7oiURwBDCVmLky6zxCPKBP5ng== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 18:17:57.0529 (UTC) FILETIME=[BBA47090:01CA0FAF] Cc: Jean-Marc Valin Subject: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 18:17:58 -0000 Jean-Marc and I have put together an update to the charter based on comments received privately and on the mailing list as well as input from Cullen and Greg. The key updates are: - added a motivation section - clarified the IPR section - added Codec Standardization Guidelines deliverable - added more detail for all of the deliverables - added specific milestones -------------- DRAFT CHARTER: Motivation: There is interest and value in having widely, easily distributable and accessible codec technology from the Internet community. Codec experts from both within and outside the IETF community have expressed an interest in contributing effort in this area. The IETF standards process provides a model for producing standards that encourages transparent design and open collaboration early on in the process. Any IETF codec designs that may emerge will also benefit from input and review from other RAI working groups and other areas of the IETF. Goals: The goal of this working group is to standardize audio codecs that can be implemented, distributed, and used broadly, and be interoperable between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs optimized for very low bit rates or for non-interactive audio are out of scope. The codecs should address the following technical considerations: * suitability for most fixed-point DSPs; * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; Beyond technical considerations, IPR issues will be handled in accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The working group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "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." Note that in accordance with BCP 79, this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; the decision will be left to the normal rough consensus of the working group. Deliverables: 1) Codec Standardization Guidelines - that define a set of metrics which can be used to evaluate a codec. These metrics would include complexity, quality vs bitrate, algorithmic delay, packet loss performance and footprint. The complete list will be specified in this document. An evaluation of these metrics should be considered by the working group in trying to come to consensus about proposed changes to one of the draft codecs. After a codec is finalized, these guidelines will be used to characterize the codec. This is an Informational track document. 2) Requirements Document - that defines the application requirements of the resulting solution. The requirements will include the exact technical considerations, the scenarios that are being addressed and the assumptions about the Internet operating environment. This is an Informational track document. 3) Algorithm descriptions for wideband Internet audio codecs. There MUST be a text description of the algorithm as well as a reference implementation. The reference implementation MUST be compliant with BCP 78 and BCP 79. The text description MUST indicate those components of the encoder and decoder which are mandatory, recommended and optional. For example, in some codec definitions only the decoder is specified whereas others have bit-exact specifications. This is a Proposed Standard document. It is not necessary to produce a single codec that solves the entire range of scenarios. A codec may be approved by the working group without addressing all of the scenarios. Milestones: Jan-2010: WG LC on Codec Standardization Guidelines Jan-2010: WG LC on Requirements Jul-2010: WG LC on codec algorithm description(s) to IESG Mar-2010: Codec Standardization Guidelines to IESG (Informational) Mar-2010: Requirements to IESG (Infomational) Jan-2011: Submit codec algorithm description(s) to IESG (Proposed Standard) From jean-marc.valin@usherbrooke.ca Tue Jul 28 11:36:50 2009 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 4C5013A6DA9 for ; Tue, 28 Jul 2009 11:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RDNS_DYNAMIC=0.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 ZE6FkLB33gyd for ; Tue, 28 Jul 2009 11:36:49 -0700 (PDT) Received: from idefix.homelinux.org (dhcp-42e3.meeting.ietf.org [130.129.66.227]) by core3.amsl.com (Postfix) with ESMTP id D2A4E3A67F6 for ; Tue, 28 Jul 2009 11:36:48 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTP id 0548F509840; Tue, 28 Jul 2009 20:36:48 +0200 (CEST) Message-ID: <4A6F4540.4080903@usherbrooke.ca> Date: Tue, 28 Jul 2009 20:36:48 +0200 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Andrew Sviridenko References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 18:36:50 -0000 Hi, We would like to include a slide describing IPMR and SBC in the codec section of the BoF. Could you please provide us with a list of codec features and characteristics for IPMR? It is typical in the IETF to submit an Internet Draft in order to receive agenda time on a specific proposal. Cheers, Jean-Marc Andrew Sviridenko a écrit : > Dear all- > > SPIRIT DSP is interested to contribute to the IETF codec WG / BOF, and > present our IPMR wideband codec on July 30, along with SILK. > > During the last 17 years (since 1992) SPIRIT DSP speech experts designed > and developed several proprietary codecs actually deployed by many > global leading telecom OEMs and semiconductor vendors- > http://www.spiritdsp.com/customers/ > > SPIRIT IPMR is multi-rate, scalable, adaptive, wideband codec > specifically designed for IP-based communications several years ago- > WGLC on draft-ietf-avt-rtp-ipmr-04 > > SPIRIT IPMR is- > - multi-rate, scalable, adaptive, wideband codec, > - low latency, > - delivers generally better voice quality than Speex, > - robust to packet loss, > - we have both PC and mobile (low MIPS) implementations, > - licensed and deployed by many leading companies, including Adobe and > Oracle, as well as multiple Asia-based telecom operators and telecom > OEMs, > - patent-free, > - payload already submitted to IETF. > > SPIRIT would like to contribute to the codec WG / BOF of IETF, and help > create wideband codec standard for IP-communications and global voice > interoperability. > > We can open-source SPIRIT IPMR if needed to make it part of the > standard. > We are also open to partner with bigger companies in this group if > needed to make IPMR codec part of the standard. > > Please let us present our SPIRIT IPMR wideband codec on July 30, along > with SILK. Slava Borilin from SPIRIT DSP will join the WG / BOF. > > Thank you, > Andrew Sviridenko > SPIRIT DSP, www.spiritDSP.com, Voice & Video Engine Experts > > > > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Friday, July 10, 2009 9:18 PM > To: Roni Even > Cc: 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin; > codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF > > On 7/10/09 10:43 AM, Roni Even wrote: >> Hi, >> I still fail to see what is the value in presenting one, two or three >> codecs. > > Present them as existence proofs (yes, we can!) and provide lessons > learned as input to the kind of work that a Codec WG would pursue. We > need to know that it is within the realm of possibility for a Codec WG > to be successful. > >> I saw that there was a request to present a third one. > > Which? > >> I can agree that there are people who can present codecs as a > suggested >> solution including existing ones. > > No. As far as I can see these are *not* suggested solutions. The point > is show that we have the expertise within the IETF to pursue this work, > to learn how those codecs were developed, and to judge whether we think > even better codecs could be developed by a Codec WG. > >> Since there is no charter yet under which >> the codecs are to be specified it may serve as a tutorial on codecs. > > Given that the IETF has not traditionally been home to codec work, I > think that a very brief tutorial on what's involved in such work would > be quite beneficial. > >> So if >> we open to codec presentation in the BOF let allow everyone to present > their >> codecs including ITU and MPEG ones and spend the whole BOF of the > different >> codecs technologies. > > Don't be ridiculous. Two or three proof points should be plenty. > >> If the idea behind this presentation is to show specific functionality > > > I don't think that's the idea. > >> than >> instead it will be more fruitful to present requirements, since I > could see >> from the list discussion that there is no consensus even between the > current >> proponents what the requirements are. > > Discussion of existence proofs and lessons learned from previous codec > work is not at odds with discussion of requirements. > > Peter > _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Tue Jul 28 11:58:29 2009 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 561953A6BFB for ; Tue, 28 Jul 2009 11:58:29 -0700 (PDT) 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 s7KT+gIy10Xv for ; Tue, 28 Jul 2009 11:58:28 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id DDCB13A6AD8 for ; Tue, 28 Jul 2009 11:58:27 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6SIwQlA029000; Tue, 28 Jul 2009 22:58:27 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 22:58:16 +0400 Message-ID: In-Reply-To: <4A6F4540.4080903@usherbrooke.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Agenda for Codec BOF Thread-Index: AcoPsmTz9FQRAGBhS5akmTZ8FpTJiwAAt1Ng References: <130EBB38279E9847BAAAE0B8F9905F8C6E40D7@esealmw109.eemea.ericsson.se> <6e9223710907091145r45add59w426f6caafe33ec8a@mail.gmail.com> <4A56496D.4060807@octasic.com> <6e9223710907100426j684bf197mbe7e1ccf827d2abe@mail.gmail.com> <4A575430.8050906@stpeter.im> <4a576fed.08b6660a.449e.4bc7@mx.google.com> <4A5777DB.4080400@stpeter.im> <4A6F4540.4080903@usherbrooke.ca> From: "Slava Borilin" To: "Jean-Marc Valin" , "Andrew Sviridenko" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 18:58:29 -0000 Jean-Marc, Jason, Yes I will share the slides tomorrow (Wed). We know we are late with the draft, but it will follow. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Jean-Marc Valin Sent: Tuesday, July 28, 2009 8:37 PM To: Andrew Sviridenko Cc: codec@ietf.org Subject: Re: [codec] Updated Agenda for Codec BOF Hi, We would like to include a slide describing IPMR and SBC in the codec section of the BoF. Could you please provide us with a list of codec features and characteristics for IPMR? It is typical in the IETF to submit an Internet Draft in order to receive agenda time on a specific proposal. Cheers, Jean-Marc Andrew Sviridenko a =E9crit : > Dear all- >=20 > SPIRIT DSP is interested to contribute to the IETF codec WG / BOF, and > present our IPMR wideband codec on July 30, along with SILK. >=20 > During the last 17 years (since 1992) SPIRIT DSP speech experts = designed > and developed several proprietary codecs actually deployed by many > global leading telecom OEMs and semiconductor vendors- > http://www.spiritdsp.com/customers/ >=20 > SPIRIT IPMR is multi-rate, scalable, adaptive, wideband codec > specifically designed for IP-based communications several years ago- > WGLC on draft-ietf-avt-rtp-ipmr-04 >=20 > SPIRIT IPMR is- > - multi-rate, scalable, adaptive, wideband codec, > - low latency, > - delivers generally better voice quality than Speex, > - robust to packet loss, > - we have both PC and mobile (low MIPS) implementations, > - licensed and deployed by many leading companies, including Adobe and > Oracle, as well as multiple Asia-based telecom operators and telecom > OEMs, > - patent-free, > - payload already submitted to IETF. >=20 > SPIRIT would like to contribute to the codec WG / BOF of IETF, and = help > create wideband codec standard for IP-communications and global voice > interoperability. >=20 > We can open-source SPIRIT IPMR if needed to make it part of the > standard. > We are also open to partner with bigger companies in this group if > needed to make IPMR codec part of the standard. >=20 > Please let us present our SPIRIT IPMR wideband codec on July 30, along > with SILK. Slava Borilin from SPIRIT DSP will join the WG / BOF. >=20 > Thank you, > Andrew Sviridenko > SPIRIT DSP, www.spiritDSP.com, Voice & Video Engine Experts > =20 >=20 >=20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 > Sent: Friday, July 10, 2009 9:18 PM > To: Roni Even > Cc: 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin; > codec@ietf.org > Subject: Re: [codec] Updated Agenda for Codec BOF >=20 > On 7/10/09 10:43 AM, Roni Even wrote: >> Hi, >> I still fail to see what is the value in presenting one, two or three >> codecs.=20 >=20 > Present them as existence proofs (yes, we can!) and provide lessons > learned as input to the kind of work that a Codec WG would pursue. We > need to know that it is within the realm of possibility for a Codec WG > to be successful. >=20 >> I saw that there was a request to present a third one.=20 >=20 > Which? >=20 >> I can agree that there are people who can present codecs as a > suggested >> solution including existing ones.=20 >=20 > No. As far as I can see these are *not* suggested solutions. The point > is show that we have the expertise within the IETF to pursue this = work, > to learn how those codecs were developed, and to judge whether we = think > even better codecs could be developed by a Codec WG. >=20 >> Since there is no charter yet under which >> the codecs are to be specified it may serve as a tutorial on codecs.=20 >=20 > Given that the IETF has not traditionally been home to codec work, I > think that a very brief tutorial on what's involved in such work would > be quite beneficial. >=20 >> So if >> we open to codec presentation in the BOF let allow everyone to = present > their >> codecs including ITU and MPEG ones and spend the whole BOF of the > different >> codecs technologies.=20 >=20 > Don't be ridiculous. Two or three proof points should be plenty. >=20 >> If the idea behind this presentation is to show specific = functionality >=20 >=20 > I don't think that's the idea. >=20 >> than >> instead it will be more fruitful to present requirements, since I > could see >> from the list discussion that there is no consensus even between the > current >> proponents what the requirements are. >=20 > Discussion of existence proofs and lessons learned from previous codec > work is not at odds with discussion of requirements. >=20 > Peter >=20 _______________________________________________ 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 stpeter@stpeter.im Tue Jul 28 13:50:44 2009 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 4BF523A6E77 for ; Tue, 28 Jul 2009 13:50:44 -0700 (PDT) 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 K9z7YG+ERThZ for ; Tue, 28 Jul 2009 13:50:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AD1623A69A3 for ; Tue, 28 Jul 2009 13:50:42 -0700 (PDT) Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 543A84007B; Tue, 28 Jul 2009 14:50:31 -0600 (MDT) Message-ID: <4A6F6491.8030605@stpeter.im> Date: Tue, 28 Jul 2009 22:50:25 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4A69CB27.9060904@acm.org> In-Reply-To: <4A69CB27.9060904@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Support for the codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 20:50:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/24/09 4:54 PM, Marc Petit-Huguenin wrote: > I am writing this as a potential user and implementer of an Internet > patent free audio codec in a widely distributed situation. > Unfortunately, I won't be able to attend the Stockholm meeting. I > am in favor of the creation of a codec WG and, even if some of my > arguments for it may have been heard before, it may not be > completely useless to state them again: Do feel free to "join" the meeting by listening to the audio and joining the chatroom (I'm sure we will have people who can relay questions from the chatroom to the physical room): http://feed.verilan.com/ietf/stream02.m3u xmpp:codec@jabber.ietf.org Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpvZJEACgkQNL8k5A2w/vyeHwCfWpOMpgRWsrD4ZmNRXdT7FLh9 dJEAn2QTDnHrecolKgUcIpoSZcx3cO8z =DgMz -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Tue Jul 28 15:24:06 2009 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 964053A6C21 for ; Tue, 28 Jul 2009 15:24:06 -0700 (PDT) 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 kGMiQsaZt1RD for ; Tue, 28 Jul 2009 15:24:05 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id BA65C3A6359 for ; Tue, 28 Jul 2009 15:23:39 -0700 (PDT) Received: by ewy26 with SMTP id 26so407751ewy.37 for ; Tue, 28 Jul 2009 15:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=AMFBHzz65P+vFusn4WjhwDHHAB2IN+vKzGxnBDMILzY=; b=izPdtrzq739f98YD+vdWoD5+Yem2445gg4nM4xZ6BO/yEdRhwHwodWl5/qQT3ZdLZd gwP8rCe4vm0+gh2cu2kkZ8ursuIVpkazLhDNDMfTYpukPeHFdzeKP8jsbhKAa1ScN2Op kny7pq4SgtSIjTH2jcSYQqVi7ZOGsxuQbLaqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=DWapIIYVNCZn6xu5UryON9HGLsjZIqw7DVsfw7istHVs4I9lzid/oAXzkX0oOqnrQV sM4xDRSTEV31wLSttirB3qwjtzhxqB0GnMixam69YXvl1idBAo4T8bXvN00E2iLhO3ZC Ptu/7+pbQPyL8QLnhdaQMj41ofbhcokgiBZzs= Received: by 10.210.118.13 with SMTP id q13mr7308865ebc.48.1248819818345; Tue, 28 Jul 2009 15:23:38 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id 10sm679218eyz.51.2009.07.28.15.23.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 15:23:37 -0700 (PDT) From: "Roni Even" To: "'Jason Fischl'" , References: In-Reply-To: Date: Wed, 29 Jul 2009 01:21:47 +0300 Message-ID: <4a6f7a69.0a1ad00a.35f9.ffffaa47@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoPr7oiURwBDCVmLky6zxCPKBP5ngAHxT6Q Content-Language: en-us Cc: 'Jean-Marc Valin' Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 22:24:06 -0000 Hi, I am a bit confused about the charter, it says that the group will standardize audio codecs which means 1 to infinity. Yet there will be one codec standardization guideline document that will define the metric to evaluate the codec. I am not sure where the values for this metrics are specified is it here or is it in the requirement document. The result is that either the values will be very vague or we will have many codecs with similar capabilities - I fail to see how this achieves the objective of being used broadly and be interoperable. I see that the codec will be characterized after it is finalized. Does it mean that we first publish a codec and afterward test the quality. I do not see any mention of a document that will describe the tests and the fail/pass requirements unless it is the guidelines that will be used to all proposed codecs I do not see any mention of a reference codec selection in order to evaluate the quality of the proposed codec. I find it strange that when talking about the open Internet environment and with an objective to achieve a broadly used and interoperable solutions the suggestion is to allow to standardize only the decoder side. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jason Fischl > Sent: Tuesday, July 28, 2009 9:18 PM > To: codec@ietf.org > Cc: Jean-Marc Valin > Subject: [codec] Updated Charter Proposal Take 2 > > Jean-Marc and I have put together an update to the charter based on > comments > received privately and on the mailing list as well as input from Cullen > and > Greg. > > The key updates are: > - added a motivation section > - clarified the IPR section > - added Codec Standardization Guidelines deliverable > - added more detail for all of the deliverables > - added specific milestones > > -------------- > DRAFT CHARTER: > > Motivation: > > There is interest and value in having widely, easily distributable and > accessible codec technology from the Internet community. Codec experts > from > both within and outside the IETF community have expressed an interest > in > contributing effort in this area. The IETF standards process provides a > model for producing standards that encourages transparent design and > open > collaboration early on in the process. Any IETF codec designs that may > emerge will also benefit from input and review from other RAI working > groups > and other areas of the IETF. > > Goals: > > The goal of this working group is to standardize audio codecs that can > be > implemented, distributed, and used broadly, and be interoperable > between a > wide set of interested parties. The group is chartered to work on audio > codecs for interactive communication over the Internet. Codecs > optimized for > very low bit rates or for non-interactive audio are out of scope. The > codecs > should address the following technical considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > Beyond technical considerations, IPR issues will be handled in > accordance > with BCP 78 and BCP 79. Specifically, many existing codecs with the > technical attributes listed above are encumbered with licensing fees > and > other IPR claims that make royalty-free and wide distribution and use > across > the Internet community difficult. The working group will try to > standardize > codecs that can be relatively freely and easily distributed, and > employed as > much as possible. In doing so, it will adhere closely to these BCPs. > More > specifically, "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." Note that in accordance with BCP 79, this > working > group will not explicitly rule out the possibility of adopting > technology > that does not meet these IPR requirements; the decision will be left to > the > normal rough consensus of the working group. > > Deliverables: > > 1) Codec Standardization Guidelines - that define a set of metrics > which can > be used to evaluate a codec. These metrics would include complexity, > quality > vs bitrate, algorithmic delay, packet loss performance and footprint. > The > complete list will be specified in this document. An evaluation of > these > metrics should be considered by the working group in trying to come to > consensus about proposed changes to one of the draft codecs. After a > codec > is finalized, these guidelines will be used to characterize the codec. > This > is an Informational track document. > > 2) Requirements Document - that defines the application requirements of > the > resulting solution. The requirements will include the exact technical > considerations, the scenarios that are being addressed and the > assumptions > about the Internet operating environment. This is an Informational > track > document. > > 3) Algorithm descriptions for wideband Internet audio codecs. There > MUST be > a text description of the algorithm as well as a reference > implementation. > The reference implementation MUST be compliant with BCP 78 and BCP 79. > The > text description MUST indicate those components of the encoder and > decoder > which are mandatory, recommended and optional. For example, in some > codec > definitions only the decoder is specified whereas others have bit-exact > specifications. This is a Proposed Standard document. > > It is not necessary to produce a single codec that solves the entire > range > of scenarios. A codec may be approved by the working group without > addressing all of the scenarios. > > Milestones: > > Jan-2010: WG LC on Codec Standardization Guidelines > Jan-2010: WG LC on Requirements > Jul-2010: WG LC on codec algorithm description(s) to IESG > Mar-2010: Codec Standardization Guidelines to IESG (Informational) > Mar-2010: Requirements to IESG (Infomational) > Jan-2011: Submit codec algorithm description(s) to IESG (Proposed > Standard) > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Tue Jul 28 17:41:37 2009 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 12B1A3A68C5 for ; Tue, 28 Jul 2009 17:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.991, 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 fHDHF8Uh9EwB for ; Tue, 28 Jul 2009 17:41:35 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 6503B3A6867 for ; Tue, 28 Jul 2009 17:41:34 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 362855-1743317 for multiple; Wed, 29 Jul 2009 02:41:20 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 28 Jul 2009 17:40:58 -0700 From: Stephan Wenger To: Jason Fischl , Message-ID: Thread-Topic: [codec] Updated Charter Proposal Take 2 Thread-Index: AcoPr7oiURwBDCVmLky6zxCPKBP5ngANYLyF In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: Jean-Marc Valin Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 00:41:37 -0000 Hi, I have two comments with respect to IPR and deliverable 3 (and a possible hidden IPR aspect), and a third comment re timing. Both IPR related comments have been raised before, but let me re-iterate them: First, it is my understanding that the language in the charter related to IPR is in full compliance with the relevant BCPs, and, therefore, I cannot have a hard objection based on process or policy violation. Still, explicitly citing only one of many preferences and rules of BCP 79 is clearly setting the tone in one direction, and may discourage contributions by those whose business model is not overly aligned with this very section of BCP 79 (but fully aligned with others). It would be easy to selectively quote other parts of BCP 79 supporting a completely different business model. For example, I could quote (in isolation) section 3.1: "General Policy / In all matters of Intellectual Property Rights, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others." Or, to be more specific, wouldn't the inclusion of the second sentence of section 8 (from which you have taken only the first sentence) also create a more balanced picture? It reads: " But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses." I continue to prefer not to mention the IPR topic at all (which is the norm in IETF charters), or state the required compliance with BCP 78 and 79 without further commentary, interpretation, or citation. Please consider this input. My second issue is a bit more subtle and (I fear) quite a bit harder to understand (especially for those not at least somewhat familiar with open source licenses), but may also be more critical. It relates to the hard requirement for code. In parts, I have already discussed the problem in my messages sent around 7/15, but let me explain once more. At present, the RFC editor, per a requirement set by the IETF trust, inserts a BSD-style license template into the source code. This templates include a phrase "[...] Redistribution and use in source and binary forms, with or without modification, are permitted [...]". There are scholars and corporate lawyers (I personally know quite a few of the latter) suggesting that this language---specifically the unqualified use of the term "use"---may imply a patent license grant. In my recollection, supported by the private conversation I had around this topic, allowing such an implied license was not the intention of the IPR WG at the time, but we may still have it. It would not be the first mistake we made in the RFC 5378 mess. A few of us more sensitive to these matters have started discussing this problem with the IETF trust. I do hope that we can find a solution that makes those of us sensitive to implied patent licensing comfortable. There are a number of ways how this can be done, but I think this is not the right forum for this discussion. Personally, I believe that all those ways require some form of a public statement by the IETF trust and/or its lawyer. At this point, no such statement has been made. The charter currently requires source code for the codec. Quoting from the draft charter, section deliverable 3: "There MUST be a text description of the algorithm as well as a reference implementation. The reference implementation MUST be compliant with BCP 78 and BCP 79." I object to the code requirement on the procedural ground that it may imply the grant of an implicit patent license by anyone contributing to the I-D and/or the code part thereof, which can be seen an introduction of a royalty-free licensing requirement through the back door. This is currently a hard objection, and, if the subject is not resolved, I will go down the appeals process. However, I do hope very much that a viable solution can be found by the trust, which may be anywhere from a good legal argument by the trust to convince me that this is a non-issue to a change of the outbound license. If the trust finds such a solution, I will promptly remove my objection. As a quick solution to this mess, I would suggest the following change in the charter language (which would give those parties interested more time to work with the trust on a "permanent" solution---famous last words :-) "There MUST be a text description. There SHOULD be a reference implementation, which MUST be compliant with BCP 78 and BCP 79." If that's not acceptable, then I would suggest to split documents: text description in one standard's track RFC and a reference implementation in another, whereby the reference implementation MUST be derived from the textual description. This would allow interested parties to contribute to the text version only, thereby practicing code hygiene and avoiding implicit patent licensing. As said, I will remove this objection promptly as soon as a satisfactory solution is found, at which point I would have no problem in going back to the (technically sensitive) choice of requiring reference code. Finally, the timing. Rarely I have seen such unrealistically ambitious milestone goals. In other SDOs, setting the Terms of Reference (Codec Standardization Guidelines and Requirements are the equivalent) is a process that can take many years. In fact, it's the hardest part of the whole exercise, as every interested party will try to fine-tune the requirements to their preferred technology. I have witnessed some of this maneuvering even on this very mailing list. This is not only an IPR game, it also covers other very legitimate interests. Attempting to run such a process in half a year cannot lead to good results. IMHO, it WILL lead to rubberstamping. Please give yourself at least a year for the requirements and procedures work to get those right. I don't care how quickly you speed through the codec specs themselves. Regards, Stephan On 7/28/09 11:17 AM, "Jason Fischl" wrote: > Jean-Marc and I have put together an update to the charter based on comments > received privately and on the mailing list as well as input from Cullen and > Greg. > > The key updates are: > - added a motivation section > - clarified the IPR section > - added Codec Standardization Guidelines deliverable > - added more detail for all of the deliverables > - added specific milestones > > -------------- > DRAFT CHARTER: > > Motivation: > > There is interest and value in having widely, easily distributable and > accessible codec technology from the Internet community. Codec experts from > both within and outside the IETF community have expressed an interest in > contributing effort in this area. The IETF standards process provides a > model for producing standards that encourages transparent design and open > collaboration early on in the process. Any IETF codec designs that may > emerge will also benefit from input and review from other RAI working groups > and other areas of the IETF. > > Goals: > > The goal of this working group is to standardize audio codecs that can be > implemented, distributed, and used broadly, and be interoperable between a > wide set of interested parties. The group is chartered to work on audio > codecs for interactive communication over the Internet. Codecs optimized for > very low bit rates or for non-interactive audio are out of scope. The codecs > should address the following technical considerations: > > * suitability for most fixed-point DSPs; > * medium- to high-quality speech at moderate bit-rate; > * high-quality music encoding at higher bit-rates; > * sampling rate profiles from narrow-band to full audio bandwidth; > * real-time adaptive bit rate; > * source-controlled variable bit-rate (VBR); > * low algorithmic delay; > > Beyond technical considerations, IPR issues will be handled in accordance > with BCP 78 and BCP 79. Specifically, many existing codecs with the > technical attributes listed above are encumbered with licensing fees and > other IPR claims that make royalty-free and wide distribution and use across > the Internet community difficult. The working group will try to standardize > codecs that can be relatively freely and easily distributed, and employed as > much as possible. In doing so, it will adhere closely to these BCPs. More > specifically, "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." Note that in accordance with BCP 79, this working > group will not explicitly rule out the possibility of adopting technology > that does not meet these IPR requirements; the decision will be left to the > normal rough consensus of the working group. > > Deliverables: > > 1) Codec Standardization Guidelines - that define a set of metrics which can > be used to evaluate a codec. These metrics would include complexity, quality > vs bitrate, algorithmic delay, packet loss performance and footprint. The > complete list will be specified in this document. An evaluation of these > metrics should be considered by the working group in trying to come to > consensus about proposed changes to one of the draft codecs. After a codec > is finalized, these guidelines will be used to characterize the codec. This > is an Informational track document. > > 2) Requirements Document - that defines the application requirements of the > resulting solution. The requirements will include the exact technical > considerations, the scenarios that are being addressed and the assumptions > about the Internet operating environment. This is an Informational track > document. > > 3) Algorithm descriptions for wideband Internet audio codecs. There MUST be > a text description of the algorithm as well as a reference implementation. > The reference implementation MUST be compliant with BCP 78 and BCP 79. The > text description MUST indicate those components of the encoder and decoder > which are mandatory, recommended and optional. For example, in some codec > definitions only the decoder is specified whereas others have bit-exact > specifications. This is a Proposed Standard document. > > It is not necessary to produce a single codec that solves the entire range > of scenarios. A codec may be approved by the working group without > addressing all of the scenarios. > > Milestones: > > Jan-2010: WG LC on Codec Standardization Guidelines > Jan-2010: WG LC on Requirements > Jul-2010: WG LC on codec algorithm description(s) to IESG > Mar-2010: Codec Standardization Guidelines to IESG (Informational) > Mar-2010: Requirements to IESG (Infomational) > Jan-2011: Submit codec algorithm description(s) to IESG (Proposed Standard) > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From markus.vaalgamaa@skype.net Tue Jul 28 17:41:02 2009 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 B8D613A68C5 for ; Tue, 28 Jul 2009 17:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, 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 tjWM8kuxHN3H for ; Tue, 28 Jul 2009 17:41:00 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 222EA3A6867 for ; Tue, 28 Jul 2009 17:40:59 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9A40B2007AB0A; Wed, 29 Jul 2009 02:41:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=from:to:cc :references:subject:date:message-id:mime-version:content-type :content-transfer-encoding:in-reply-to; s=mail; bh=0wlTYQnLdmfd/ /CnevS5kXmWywE=; b=jNPGDctlYQ2XVUNzsG8BDmjnKoKIDBJrV6Sdx2gt17f4j /6rpnreCCBHnuewFs9h8bwm47m14af46sP4TTnhn4Obb5vRnKudzK7Lo1d3ttaZp gbPSIPbgbVLC4vBKeNqo5r5BjZkPYaA3OUpxtpH64JwfYq0cU/kvHbIoUna4rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=from:to:cc :references:subject:date:message-id:mime-version:content-type :content-transfer-encoding:in-reply-to; q=dns; s=mail; b=qWxdNOU tfZi7iIlA+w7YqHTMhrYDvxmhzlB/rwfPwjQ9AGvB9dcDtz8Oyb+dB7+S2jGsfvb QMdm+SMUJJmosLgYTtnPf+lDIBMNTLwwXL4+MEfq63Qd/qfshxnsgbUuMYsVK9T0 DC1SbSGn6yBPnLSMWE9CL71I8Q6/nNgoM27M= Received: from TLLT610928 (dsl-hkibrasgw2-ff7fc300-106.dhcp.inet.fi [88.195.127.106]) by mail.skype.net (Postfix) with ESMTPSA id 5E97C2007A96C; Wed, 29 Jul 2009 02:41:00 +0200 (CEST) From: "Markus Vaalgamaa" To: "'Lars Eggert'" , "'Roni Even'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se><4A6D6AD0.30504@usherbrooke.ca><001801ca0ea2$cc71a090$9446c80a@china.huawei.com><130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se><20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com><4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> Date: Wed, 29 Jul 2009 03:40:58 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoPS+o489uJpWSJSwydfCZeUmeplAAk1bZA In-Reply-To: <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 00:42:25 -0000 Hi Lars, Roni and all, Roni and Lars wrote: >> but no capability to do a real review and quality assessment > agree with Roni. Having codec specs available that (apparently) fit > the requirements is nice, but it's not clear at all that that means > that the experts who have created these codecs will actively > participate in an IETF effort that would be based on something other > than their initial candidate submission. I'm very willing to contribute to the reviewing and quality assessments. I have the lead Call/Audio/Speech Quality Assessment role at Skype and I'm working daily with subjective user feedbacks, stats, objective quality measurement tools (such as PESQ/P.862), audio measurements, lab, informal & formal listening tests, user centric and tech. requirements, even codec & other processing algorithm details etc... I also actively follow and participate (as an invited expert) to the key standardization forums of these matters - ITU-T SG 12 (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ (http://portal.etsi.org/stq/Summary.asp). So I hope I have something to bring to the common work. I'm also sure there are ways to run a part of formal listening tests at Skype facilities if that's seen beneficial later. (or we can arrange tests with some of the 3rd party labs) Before I moved to Skype a bit more than 3 years ago, I worked for around 8 years in/for Nokia on the similar Speech/Audio Quality Assessment matters + audio SW algorithms & audio&speech codecs... and the most of that time I've worked at the same building that Lars appears to be working today ;-) Best regards with my few Euro cents... Markus Vaalgamaa -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Tuesday, July 28, 2009 9:23 AM To: Roni Even Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof Hi, On 2009-7-27, at 23:48, Roni Even wrote: > Having two codec suggested does not represent expertise to review > codec > work. The IETF "rubber stamped" the iLBC codec. There was a proposed > codec, > which you consider expertise, but no capability to do a real review > and > quality assessment agree with Roni. Having codec specs available that (apparently) fit the requirements is nice, but it's not clear at all that that means that the experts who have created these codecs will actively participate in an IETF effort that would be based on something other than their initial candidate submission. Lars From ron.even.tlv@gmail.com Tue Jul 28 22:39:03 2009 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 0567F3A6E3A for ; Tue, 28 Jul 2009 22:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 RWzFmwgOY+0T for ; Tue, 28 Jul 2009 22:39:01 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 61AC83A690A for ; Tue, 28 Jul 2009 22:38:40 -0700 (PDT) Received: by ewy26 with SMTP id 26so568840ewy.37 for ; Tue, 28 Jul 2009 22:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=/bCOBnHo/2mb/qW0F+JXkr8kS1EnJsA/9q0ExO9bAJY=; b=kA/R7GZEzVnsGcp6Xw9DxI/8TMke/U828KOWGk7fMRDiEfb32cahw1S+mTFYWz5FVA OKbOq2iYUzqEiUaO3KH84A4seSvQfKm0plDXcmYVRjU6MgxubbBpEzw0nPf7YTjeon9S 8mXd0wmW/7MfQCxJXqKD0Bnsvbr/kfr1Pf8z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=VDr7Kr5n8ssaPnifsW29F926dXZ5+/88lCOaCn8BYzKxbVZhhXr5EbuPAN2UWahT0p nGzUdXCsZCPCCcDSpJikCk2ZA0/pbX1DLuLbF1FznDCxTSxPjCZszWY8ILkNrl0r+D7N sTm3fqAZJnN263JHO7uyQ38LXvAV36Vjs/i14= Received: by 10.210.44.12 with SMTP id r12mr1943900ebr.24.1248845920069; Tue, 28 Jul 2009 22:38:40 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id 10sm1420277eyz.51.2009.07.28.22.38.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 22:38:39 -0700 (PDT) From: "Roni Even" To: "'Markus Vaalgamaa'" , "'Lars Eggert'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se><4A6D6AD0.30504@usherbrooke.ca><001801ca0ea2$cc71a090$9446c80a@china.huawei.com><130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se><20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com><4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> In-Reply-To: Date: Wed, 29 Jul 2009 08:36:55 +0300 Message-ID: <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoPS+o489uJpWSJSwydfCZeUmeplAAk1bZAAAumo8A= Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 05:39:03 -0000 Markus, I am happy to hear it, so here is the challenge for you, I assume you are following the email discussion and one of the topic is how to define metrics and test the quality of the audio candidate. I will be interested to see you position about it. Regards Roni Even -----Original Message----- > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > Sent: Wednesday, July 29, 2009 3:41 AM > To: 'Lars Eggert'; 'Roni Even' > Cc: codec@ietf.org > Subject: RE: [codec] Agenda for the Codec Bof > > > Hi Lars, Roni and all, > > Roni and Lars wrote: > >> but no capability to do a real review and quality assessment > > > agree with Roni. Having codec specs available that (apparently) fit > > the requirements is nice, but it's not clear at all that that means > > that the experts who have created these codecs will actively > > participate in an IETF effort that would be based on something other > > than their initial candidate submission. > > I'm very willing to contribute to the reviewing and quality > assessments. > > I have the lead Call/Audio/Speech Quality Assessment role at Skype and > I'm > working daily with subjective user feedbacks, stats, objective quality > measurement tools (such as PESQ/P.862), audio measurements, lab, > informal & > formal listening tests, user centric and tech. requirements, even codec > & > other processing algorithm details etc... I also actively follow and > participate (as an invited expert) to the key standardization forums of > these matters - ITU-T SG 12 > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ > (http://portal.etsi.org/stq/Summary.asp). So I hope I have something to > bring to the common work. > > I'm also sure there are ways to run a part of formal listening tests at > Skype facilities if that's seen beneficial later. (or we can arrange > tests > with some of the 3rd party labs) > > Before I moved to Skype a bit more than 3 years ago, I worked for > around 8 > years in/for Nokia on the similar Speech/Audio Quality Assessment > matters + > audio SW algorithms & audio&speech codecs... and the most of that time > I've > worked at the same building that Lars appears to be working today ;-) > > Best regards with my few Euro cents... > > Markus Vaalgamaa > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of > Lars Eggert > Sent: Tuesday, July 28, 2009 9:23 AM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof > > Hi, > > On 2009-7-27, at 23:48, Roni Even wrote: > > Having two codec suggested does not represent expertise to review > > codec > > work. The IETF "rubber stamped" the iLBC codec. There was a proposed > > codec, > > which you consider expertise, but no capability to do a real review > > and > > quality assessment > > agree with Roni. Having codec specs available that (apparently) fit > the requirements is nice, but it's not clear at all that that means > that the experts who have created these codecs will actively > participate in an IETF effort that would be based on something other > than their initial candidate submission. > > Lars From hoene@uni-tuebingen.de Wed Jul 29 01:11:24 2009 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 A680B3A6E9E for ; Wed, 29 Jul 2009 01:11:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgbxseqfY7Jz for ; Wed, 29 Jul 2009 01:11:23 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 5F3713A6D1D for ; Wed, 29 Jul 2009 01:11:23 -0700 (PDT) Received: from hoeneLenovoT60 (dhcp-11fe.meeting.ietf.org [130.129.17.254]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6T8BGli003133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2009 10:11:22 +0200 From: "Christian Hoene" To: "'Stephan Wenger'" , "'Jason Fischl'" , References: In-Reply-To: Date: Wed, 29 Jul 2009 10:11:16 +0200 Message-ID: <004e01ca1024$29994ca0$7ccbe5e0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPr7oiURwBDCVmLky6zxCPKBP5ngANYLyFAA7mCiA= Content-Language: de x-cr-hashedpuzzle: Gm6X HUDz JJyN JQDV Jgka OgYp dx3d gHYF iYFT mDl9 nwdD pqry sHXd vNGk wJCC yEvC; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAagBhAHMAbwBuAC4AZgBpAHMAYwBoAGwAQABzAGsAeQBwAGUALgBuAGUAdAA7AGoAZQBhAG4ALQBtAGEAcgBjAC4AdgBhAGwAaQBuAEAAdQBzAGgAZQByAGIAcgBvAG8AawBlAC4AYwBhADsAcwB0AGUAdwBlAEAAcwB0AGUAdwBlAC4AbwByAGcA; Sosha1_v1; 7; {315A2118-DBEF-4D81-9CAC-ACE0E8CFEC32}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Wed, 29 Jul 2009 08:07:26 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAVQBwAGQAYQB0AGUAZAAgAEMAaABhAHIAdABlAHIAIABQAHIAbwBwAG8AcwBhAGwAIABUAGEAawBlACAAMgA= x-cr-puzzleid: {315A2118-DBEF-4D81-9CAC-ACE0E8CFEC32} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: 'Jean-Marc Valin' Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:11:24 -0000 Dear Stephan Wenger, comments inline: > I continue to prefer not to mention the IPR topic at all (which is the norm > in IETF charters), or state the required compliance with BCP 78 and 79 > without further commentary, interpretation, or citation. Please consider > this input. Let me object your request. Mentioning the IPR topic is fair way of warning all potential contributors that it will be very hard to include a solution that requires the payment of license fees. At least I would vote for a codec that is believed to be license free instead one that you have to buy even if the first performs slightly worse than the second. To my understand, most of the other IETF folks will act similar. > At present, the RFC editor, per a requirement set by the IETF trust, inserts > a BSD-style license template into the source code. This templates include a > phrase "[...] Redistribution and use in source and binary forms, with or > without modification, are permitted [...]". There are scholars and > corporate lawyers (I personally know quite a few of the latter) suggesting > that this language---specifically the unqualified use of the term > "use"---may imply a patent license grant. > In my recollection, supported by > the private conversation I had around this topic, allowing such an implied > license was not the intention of the IPR WG at the time, but we may still > have it. It would not be the first mistake we made in the RFC 5378 mess. > > A few of us more sensitive to these matters have started discussing this > problem with the IETF trust. I do hope that we can find a solution that > makes those of us sensitive to implied patent licensing comfortable. There > are a number of ways how this can be done, but I think this is not the right > forum for this discussion. Personally, I believe that all those ways > require some form of a public statement by the IETF trust and/or its lawyer. > At this point, no such statement has been made. This concern might be valid. However, I do not think this will be an issue if we can agree on a license free codec. > The charter currently requires source code for the codec. Quoting from the > draft charter, section deliverable 3: "There MUST be a text description of > the algorithm as well as a reference implementation. The reference > implementation MUST be compliant with BCP 78 and BCP 79." I object to the > code requirement on the procedural ground that it may imply the grant of an > implicit patent license by anyone contributing to the I-D and/or the code > part thereof, which can be seen an introduction of a royalty-free licensing > requirement through the back door. Again, if we agree on an open development process with license free terms, than the requirement of an open source reference implementation should not be an issue. > Finally, the timing. Rarely I have seen such unrealistically ambitious > milestone goals. In other SDOs, setting the Terms of Reference (Codec > Standardization Guidelines and Requirements are the equivalent) is a process > that can take many years. Doesn't the IETF work at "Internet speed" ;-) > In fact, it's the hardest part of the whole > exercise, as every interested party will try to fine-tune the requirements > to their preferred technology. I have witnessed some of this maneuvering > even on this very mailing list. Your point is right. I would suggest to include other parties such as the AVT working group or user groups into the requirement definition. If you let the codec developers write their own requirement document, if will end up in rubber stamping. This is not only an IPR game, it also > covers other very legitimate interests. Attempting to run such a process in > half a year cannot lead to good results. IMHO, it WILL lead to > rubberstamping. Please give yourself at least a year for the requirements > and procedures work to get those right. I don't care how quickly you speed > through the codec specs themselves. To my understanding, these dates are not hard deadlines. I am always a friend of a tough schedule to motivate the contributors to speed up their work. With best regards, Christian From hoene@uni-tuebingen.de Wed Jul 29 01:46:24 2009 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 2C1443A6F3D for ; Wed, 29 Jul 2009 01:46:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuDE5JBrT-9m for ; Wed, 29 Jul 2009 01:46:23 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 8EC363A6BCF for ; Wed, 29 Jul 2009 01:46:21 -0700 (PDT) Received: from hoeneLenovoT60 (dhcp-11fe.meeting.ietf.org [130.129.17.254]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n6T8kDne008827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2009 10:46:20 +0200 From: "Christian Hoene" To: "'Roni Even'" , "'Jason Fischl'" , References: <4a6f7a69.0a1ad00a.35f9.ffffaa47@mx.google.com> In-Reply-To: <4a6f7a69.0a1ad00a.35f9.ffffaa47@mx.google.com> Date: Wed, 29 Jul 2009 10:46:14 +0200 Message-ID: <005001ca1029$0c6d6580$25483080$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPr7oiURwBDCVmLky6zxCPKBP5ngAHxT6QABU01WA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: 'Jean-Marc Valin' Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:46:24 -0000 Hello Roni, > I am a bit confused about the charter, it says that the group will > standardize audio codecs which means 1 to infinity. Yet there will be = one > codec standardization guideline document that will define the metric = to > evaluate the codec. I am not sure where the values for this metrics = are > specified is it here or is it in the requirement document. > The result is that either the values will be very vague or we will = have many > codecs with similar capabilities - I fail to see how this achieves the > objective of being used broadly and be interoperable. > ... To my understanding, the goal of the charter is provide one solution for = the Internet that might consist of one codec with multiple "profiles" or of multiple codecs that are intended for different network conditions.=20 Please allow me to explain the need for this requirement by comparing = the audio solution with TCP. As you know, TCP works well regardless of the available bandwidth and scales from a few bytes per second to up gigabit speeds. This feature of TCP is important because the Internet does not = give any guaranties on bandwidth.=20 Similar, an audio solution for the Internet shall work in a wide range = of different network conditions because nobody can guaranty a minimal = bandwidth on the public Internet at all times. As TCP, an audio solution for the Internet would try to achieve the best quality that is currently = possible.=20 More precisely, 1. At very low transmission delays and at very high transmission rates, quasi-synchronous audio transmissions would allow distributed ensemble performances having a close to perfect Hi-Fi quality. 2. At modest bandwidths, an interactive audio transmission of music and speech shall be possible. 3. If the bandwidth gets lower, than an interactive speech transmission = can still be supported (at wide- or narrowband) 4. If transmission capacity hardly exists, one still can degraded the quality of a telephone call to something like a push-to-talk (PTT) like service having very high latencies (or use text messages instead). Then, an Internet audio solution provides the best possible service = quality at the given network constrains.=20 Also, the measures of quality requirements change with the available transmission capacity. In case of 1.) you might want to measure quality with the MUSHRA tests given in ITU BS.1534-1 (http://www.itu.int/rec/R-REC-BS.1534-1-200301-I/e). Also, research literature (e.g. by Alexander Car=F4t or Chris Chafe) gives you guidelines on the latency requirements. At 2.) Again, the BS1534-1 can be used for the assessment of the music quality. During the characterization of G.718, the ITU used the Absolute Category Rating (ACR) for music, too. (refer to ITU-T P.800 and ITU-T P.910). 3.) At low bandwidth music transmission cannot be support anymore but = only speech. Then, the classic procedure of the ITU Study Group 12 needs to = be considered (P.800 and others). 4.) In this case, only not the speech quality but understandability = should be considered. I do not know any standard on this but in research literature, the performance of automatic speech recognition (ASR) = systems is usually taken a metric. To my understanding these diverse requirements cannot be achieved with a single algorithm but requires different codecs or different algorithmic profiles in one common codec. If multiple audio codecs are proposed, than the overlap between them = should be minimal. Nobody wins, if we have multiple different codecs for the = same network condition but all benefit on having a solution that is scalable = and reliable. With best regards, Christian From gregory.ietf@gmail.com Wed Jul 29 01:51:43 2009 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 6D1153A6EF0 for ; Wed, 29 Jul 2009 01:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 i9FAmw4vt3dc for ; Wed, 29 Jul 2009 01:51:42 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 5E9463A6F6A for ; Wed, 29 Jul 2009 01:51:29 -0700 (PDT) Received: by fxm18 with SMTP id 18so247017fxm.37 for ; Wed, 29 Jul 2009 01:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=Kag83mxdk4DBXFvISMuhvf6GaEThZpPIrDtnZa4xwXk=; b=NdiggJvGKqkvdl1H+zXEywP/VGzQg+9DzsSqd/xOEnIKkffJ7gnfdEuFl+vmyhjxWL huP48wCx8w/eEqBIeqaHDX/Zn2WXTCMTjiGoof4YPjjZqlfSwJTnTI2PkzXFK6TvpRxv jbzrpcHa8rECxzyzg26MREG7rWYVu57+wIpKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=cMWEXqOUc28XkfzNyVdxjLFTQqUp/90DGrwxVkeeVIPcqzzAwd+zYFJV9KmMdzFUIX MG3a1tdkoAtYNhLuaDgjymdSfW4UC3PEcECrUxHLKdy7w8Z2ovSwlzid1I4AaCocv7Wf D3FIug1NxA1Um+csWflWlbOHZ5bW9Y+B77fjY= Received: by 10.103.52.13 with SMTP id e13mr4411751muk.51.1248857485961; Wed, 29 Jul 2009 01:51:25 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id j9sm3376989mue.26.2009.07.29.01.51.24 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 01:51:24 -0700 (PDT) Message-ID: <4a700d8c.09a1660a.2552.2ee1@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 01:51:14 -0700 To: "Roni Even" From: "Gregory M. Lebovitz" In-Reply-To: <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:51:43 -0000 Roni, Just to clarify how I read the latest charter... It's not that a WG would "test" the quality of the audio of a candidate mechanism or codec. It's not a pass vs fail thing. There doesn't need to be a winner and a loser. In fact, the word "test" does not appear in the charter. The charter does say: "define a set of metrics which can be used to evaluate a codec. " The word "evaluate" is very different. I read it to mean "how will a group of people normalize their collective subjective opinion on an observed condition". By example, consider the way cars are reviewed in magazines. Judges who have been trained on a set of metrics about performance under different conditions (say top end speed, or cornering, or acceleration, or storage space) have a shared set of definitions of performance they might observe, both good and impressive performance as well as poor/faulty performance. They also have a standard measurement scale -- in this example scoring by points -- by which they record their observations of performance. The measurement scale includes different values for different performance elements, i.e. certain observations cost 1/2 point deduction, others cost 1/4 point, and some gain points because they are more difficult or beneficial. When comparing two sports cars one might be better at sharp turns at high speeds and acceleration, while another might be better at sustained high speeds on straight aways. But both are terrible at fitting your family of 6 and all your luggage for a 10 hr road trip over dirt and rock terrain, towing a ski boat. Likewise, this WG will need to come up with a shared set of "performance" metrics that they might observe from a codec or its sub-mechanisms. And it will need to agree on a system for valuing these metrics. Like the vehicle example, the WG may not determine one winner, and determine all others losers. But might simply evaluate two and agree that X codec/mechanism is better at Alpha and Beta, where as Y codec/mechanism just as good at Beta, but not as good in Alpha, but much better in Delta, and thus is better applied to environment 3, but not as good as X in environment 2. My point is that the word "evaluate" is intended to have a far different meaning than purely "test". We may do many tests in order to form a unified evaluation. This might be a very subtle difference, but I think it important to tease out. Hope it helps, Gregory At 10:36 PM 7/28/2009, Roni Even wrote: >Markus, >I am happy to hear it, so here is the challenge for you, I assume you are >following the email discussion and one of the topic is how to define metrics >and test the quality of the audio candidate. I will be interested to see you >position about it. >Regards >Roni Even > > > > >-----Original Message----- > > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > > Sent: Wednesday, July 29, 2009 3:41 AM > > To: 'Lars Eggert'; 'Roni Even' > > Cc: codec@ietf.org > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > Hi Lars, Roni and all, > > > > Roni and Lars wrote: > > >> but no capability to do a real review and quality assessment > > > > > agree with Roni. Having codec specs available that (apparently) fit > > > the requirements is nice, but it's not clear at all that that means > > > that the experts who have created these codecs will actively > > > participate in an IETF effort that would be based on something other > > > than their initial candidate submission. > > > > I'm very willing to contribute to the reviewing and quality > > assessments. > > > > I have the lead Call/Audio/Speech Quality Assessment role at Skype and > > I'm > > working daily with subjective user feedbacks, stats, objective quality > > measurement tools (such as PESQ/P.862), audio measurements, lab, > > informal & > > formal listening tests, user centric and tech. requirements, even codec > > & > > other processing algorithm details etc... I also actively follow and > > participate (as an invited expert) to the key standardization forums of > > these matters - ITU-T SG 12 > > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ > > (http://portal.etsi.org/stq/Summary.asp). So I hope I have something to > > bring to the common work. > > > > I'm also sure there are ways to run a part of formal listening tests at > > Skype facilities if that's seen beneficial later. (or we can arrange > > tests > > with some of the 3rd party labs) > > > > Before I moved to Skype a bit more than 3 years ago, I worked for > > around 8 > > years in/for Nokia on the similar Speech/Audio Quality Assessment > > matters + > > audio SW algorithms & audio&speech codecs... and the most of that time > > I've > > worked at the same building that Lars appears to be working today ;-) > > > > Best regards with my few Euro cents... > > > > Markus Vaalgamaa > > > > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of > > Lars Eggert > > Sent: Tuesday, July 28, 2009 9:23 AM > > To: Roni Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > > Hi, > > > > On 2009-7-27, at 23:48, Roni Even wrote: > > > Having two codec suggested does not represent expertise to review > > > codec > > > work. The IETF "rubber stamped" the iLBC codec. There was a proposed > > > codec, > > > which you consider expertise, but no capability to do a real review > > > and > > > quality assessment > > > > agree with Roni. Having codec specs available that (apparently) fit > > the requirements is nice, but it's not clear at all that that means > > that the experts who have created these codecs will actively > > participate in an IETF effort that would be based on something other > > than their initial candidate submission. > > > > Lars > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jason.fischl@skype.net Wed Jul 29 02:14:07 2009 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 656F33A67D0 for ; Wed, 29 Jul 2009 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 4ybUcc86KOmj for ; Wed, 29 Jul 2009 02:14:06 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id C1B493A6FB1 for ; Wed, 29 Jul 2009 02:13:35 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.43,288,1246863600"; d="scan'208";a="54723342" Received: from den-exb-02.corp.ebay.com ([10.101.44.10]) by den-mipot-001.corp.ebay.com with ESMTP; 29 Jul 2009 02:13:36 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by DEN-EXB-02.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 03:13:36 -0600 Received: from 84.55.127.131 ([84.55.127.131]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Jul 2009 09:13:29 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 29 Jul 2009 11:13:25 +0200 From: Jason Fischl To: Roni Even , Message-ID: Thread-Topic: [codec] Updated Charter Proposal Take 2 Thread-Index: AcoPr7oiURwBDCVmLky6zxCPKBP5ngAHxT6QABeBJnc= In-Reply-To: <4a6f7a69.0a1ad00a.35f9.ffffaa47@mx.google.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 29 Jul 2009 09:13:36.0151 (UTC) FILETIME=[DA5B6A70:01CA102C] Cc: 'Jean-Marc Valin' Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:14:07 -0000 Hi Roni, Thank you for thoroughly reviewing the updated charter. We have made minor modifications to the charter to address the issues you point out. See below= : Roni Even wrote : > I am a bit confused about the charter, it says that the group will > standardize audio codecs which means 1 to infinity. Yet there will be one > codec standardization guideline=A0 document that will define the metric to > evaluate the codec. I am not sure where the values for this metrics are > specified is it here or is it in the requirement document. > The result is that either the values will be very vague or we will have m= any > codecs with similar capabilities - I fail to see how this achieves the > objective of being used broadly and be interoperable. Thanks for pointing this out. We have clarified that the guidelines define the metrics but not the target values. The target values are defined in the requirements.=20 > I see that the codec will be characterized after it is finalized. Does it > mean that we first publish a codec and afterward test the quality. This means nothing more than final testing has to be done after the codec i= s finalized, or the final testing wouldn't be final. Of course, there will also be continuous testing, as we have now clarified. > I do not see any mention of a document that will describe the tests and t= he > fail/pass requirements unless it is the guidelines that will be used to a= ll > proposed codecs Thanks, we have added that "A set of pass/fail requirements MAY be specifie= d in the requirements document". > I do not see any mention of a reference codec selection in order to evalu= ate > the quality of the proposed codec. We have now mentioned an "optional reference codec". > I find it strange that when talking about the open Internet environment a= nd > with an objective to achieve a broadly used and interoperable solutions t= he > suggestion is to allow to standardize only the decoder side. Thanks for pointing this out. We have clarified that "Any characterization MUST be performed with the reference encoder. This is a Proposed Standard document." Basically, any codec that allows the encoder multiple axes of freedom on th= e encode side tends to specify only decode as normative.=A0 This is standard practice in other SDOs (though not the only standard practice). What is different (and what may have alarmed you) is that SDOs that make decode normative also typically hold back all the 'good' encoders entirely from the process, keeping them closed to be sold later.=A0 We intend, and it should be made clear in the document, that a high-quality reference encoder must be described in detail and provided with the reference implementation.= =A0 This fully open reference encoder will be the one used for characterization= , performance and comparative testing. =A0=A0 =A0Jean-Marc and Jason > Thanks > Roni Even >=20 >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Jason Fischl >> Sent: Tuesday, July 28, 2009 9:18 PM >> To: codec@ietf.org >> Cc: Jean-Marc Valin >> Subject: [codec] Updated Charter Proposal Take 2 >> >> Jean-Marc and I have put together an update to the charter based on >> comments >> received privately and on the mailing list as well as input from Cullen >> and >> Greg. >> >> The key updates are: >> - added a motivation section >> - clarified the IPR section >> - added Codec Standardization Guidelines deliverable >> - added more detail for all of the deliverables >> - added specific milestones >> >> -------------- >> DRAFT CHARTER: >> >> Motivation: >> >> There is interest and value in having widely, easily distributable and >> accessible codec technology from the Internet community. Codec experts >> from >> both within and outside the IETF community have expressed an interest >> in >> contributing effort in this area. The IETF standards process provides a >> model for producing standards that encourages transparent design and >> open >> collaboration early on in the process. Any IETF codec designs that may >> emerge will also benefit from input and review from other RAI working >> groups >> and other areas of the IETF. >> >> Goals: >> >> The goal of this working group is to standardize audio codecs that can >> be >> implemented, distributed, and used broadly, and be interoperable >> between a >> wide set of interested parties. The group is chartered to work on audio >> codecs for interactive communication over the Internet. Codecs >> optimized for >> very low bit rates or for non-interactive audio are out of scope. The >> codecs >> should address the following technical considerations: >> >> * suitability for most fixed-point DSPs; >> * medium- to high-quality speech at moderate bit-rate; >> * high-quality music encoding at higher bit-rates; >> * sampling rate profiles from narrow-band to full audio bandwidth; >> * real-time adaptive bit rate; >> * source-controlled variable bit-rate (VBR); >> * low algorithmic delay; >> >> Beyond technical considerations, IPR issues will be handled in >> accordance >> with BCP 78 and BCP 79. Specifically, many existing codecs with the >> technical attributes listed above are encumbered with licensing fees >> and >> other IPR claims that make royalty-free and wide distribution and use >> across >> the Internet community difficult. The working group will try to >> standardize >> codecs that can be relatively freely and easily distributed, and >> employed as >> much as possible. In doing so, it will adhere closely to these BCPs. >> More >> specifically, "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." Note that in accordance with BCP 79, this >> working >> group will not explicitly rule out the possibility of adopting >> technology >> that does not meet these IPR requirements; the decision will be left to >> the >> normal rough consensus of the working group. >> >> Deliverables: >> >> 1) Codec Standardization Guidelines - that define a set of metrics >> which can >> be used to evaluate a codec. These metrics would include complexity, >> quality >> vs bitrate, algorithmic delay, packet loss performance and footprint. >> The >> complete list will be specified in this document. An evaluation of >> these >> metrics should be considered by the working group in trying to come to >> consensus about proposed changes to one of the draft codecs. After a >> codec >> is finalized, these guidelines will be used to characterize the codec. >> This >> is an Informational track document. >> >> 2) Requirements Document - that defines the application requirements of >> the >> resulting solution. The requirements will include the exact technical >> considerations, the scenarios that are being addressed and the >> assumptions >> about the Internet operating environment. This is an Informational >> track >> document. >> >> 3) Algorithm descriptions for wideband Internet audio codecs. There >> MUST be >> a text description of the algorithm as well as a reference >> implementation. >> The reference implementation MUST be compliant with BCP 78 and BCP 79. >> The >> text description MUST indicate those components of the encoder and >> decoder >> which are mandatory, recommended and optional. For example, in some >> codec >> definitions only the decoder is specified whereas others have bit-exact >> specifications. This is a Proposed Standard document. >> >> It is not necessary to produce a single codec that solves the entire >> range >> of scenarios. A codec may be approved by the working group without >> addressing all of the scenarios. >> >> Milestones: >> >> Jan-2010: WG LC on Codec Standardization Guidelines >> Jan-2010: WG LC on Requirements >> Jul-2010: WG LC on codec algorithm description(s) to IESG >> Mar-2010: Codec Standardization Guidelines to IESG (Informational) >> Mar-2010: Requirements to IESG (Infomational) >> Jan-2011: Submit codec algorithm description(s) to IESG (Proposed >> Standard) >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 From jason.fischl@skype.net Wed Jul 29 02:14:07 2009 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 D1F013A67D0 for ; Wed, 29 Jul 2009 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 jwtb8FeJq51R for ; Wed, 29 Jul 2009 02:14:06 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 7CD563A6EAB for ; Wed, 29 Jul 2009 02:13:41 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.43,288,1246863600"; d="scan'208";a="54769273" Received: from den-exb-03.corp.ebay.com ([10.101.44.11]) by den-mipot-002.corp.ebay.com with ESMTP; 29 Jul 2009 02:13:42 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by DEN-EXB-03.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 03:13:42 -0600 Received: from 84.55.127.131 ([84.55.127.131]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Jul 2009 09:13:38 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 29 Jul 2009 11:13:32 +0200 From: Jason Fischl To: "codec@ietf.org" Message-ID: Thread-Topic: Updated Charter Proposal Take 3 Thread-Index: AcoQLNfi0xNyUdB/DEig39yrPMSGvA== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 29 Jul 2009 09:13:42.0634 (UTC) FILETIME=[DE38A4A0:01CA102C] Cc: Jean-Marc Valin Subject: [codec] Updated Charter Proposal Take 3 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:14:07 -0000 Jean-Marc and I have updated the charter based on the comments from Roni an= d a few private replies. -------------- DRAFT CHARTER: Motivation: There is interest and value in having widely, easily distributable and accessible codec technology from the Internet community. Codec experts=A0from both within and outside=A0the IETF community have expressed an interest in contributing effort in this area. The IETF standards process provides a model for producing standards that encourages=A0transparent design and open collaboration early on in the process. Any IETF codec designs that may emerge will also benefit from input and review from other RAI working group= s and other areas of the IETF. Goals: =20 The goal of this working group is to standardize audio codecs that can be implemented, distributed, and used broadly, and be interoperable between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs optimized fo= r very low bit rates or for non-interactive audio are out of scope. The codec= s should address the following technical considerations: =20 * suitability for most fixed-point Digital Signal Processors (DSP); * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; =20 Beyond technical considerations, IPR issues will be handled in accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use acros= s the Internet community difficult. The working group will try to standardize codecs that can be relatively freely and easily distributed, and employed a= s much as possible. In doing so, it=A0will adhere closely to these BCPs. More specifically, "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." Note that in accordance with BCP 79, this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; the decision will be left to the normal rough consensus of the working group.=A0 =20 Deliverables: =20 =20 1) Codec Standardization Guidelines - that define a set of metrics which ca= n be used to evaluate a codec. These metrics would include=A0complexity, qualit= y vs bitrate, algorithmic delay, packet loss performance and footprint. The complete list will be specified in this document. An evaluation of these metrics should be considered by the working group in trying to come to consensus about proposed changes to one of the draft codecs. A set of pass/fail requirements MAY be specified in the requirements document. It will be up to the working group to evaluate whether or not the proposed codec is better than the reference codec. Continuous testing will be done throughout the process. After a codec is finalized, these guidelines will b= e used to characterize the codec. This is an Informational track document. =20 2) Requirements Document - that defines the application requirements of the resulting solution. The requirements will include the exact technical considerations including the target values for metrics defined in the Codec Standardization Guidelines, any pass/fail requirements, an optional reference codec, the scenarios that are being addressed and the assumptions about the Internet operating environment. This is an Informational track document. 3) Algorithm description for one or more wideband=A0Internet audio codecs. There MUST be a text description of the algorithm as well as a reference implementation.=A0The reference implementation MUST include an encoder and a decoder, and MUST be compliant with BCP 78 and BCP 79. The text description MUST indicate those components of the encoder and decoder which are mandatory, recommended and optional. For example, in some codec definitions only the decoder is specified whereas others have bit-exact specifications. Any characterization MUST be performed with the reference encoder. This is = a Proposed Standard document.=A0 =20 It is not necessary to produce a single codec that solves the entire range of scenarios. A codec may be approved by the working group without addressing all of the scenarios. Milestones: =20 Jan-2010: WGLC on Codec Standardization Guidelines=A0 Jan-2010: WGLC on Requirements=A0 Jul-2010: WGLC on codec algorithm description(s) to IESG Mar-2010: Codec Standardization Guidelines to IESG (Informational) Mar-2010: Requirements to IESG (Infomational) Jan-2011: Submit codec algorithm description(s) to IESG (Standards Track) From hsinnrei@adobe.com Wed Jul 29 04:59:42 2009 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 B03643A6F75 for ; Wed, 29 Jul 2009 04:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEzbvBdCrAVo for ; Wed, 29 Jul 2009 04:59:41 -0700 (PDT) Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id 194A03A67B4 for ; Wed, 29 Jul 2009 04:59:37 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSnA5n3GHlpEP6ZPdUePicO/tFx8RdyrW@postini.com; Wed, 29 Jul 2009 04:59:42 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6TBquao021213; Wed, 29 Jul 2009 04:52:56 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6TBxQiq000750; Wed, 29 Jul 2009 04:59:26 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 29 Jul 2009 04:59:26 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 29 Jul 2009 04:59:26 -0700 From: Henry Sinnreich To: Jason Fischl , "codec@ietf.org" Date: Wed, 29 Jul 2009 04:59:23 -0700 Thread-Topic: [codec] Updated Charter Proposal Take 3 Thread-Index: AcoQLNfi0xNyUdB/DEig39yrPMSGvAAFytBo Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C696063BEFE2hsinnreiadobecom_" MIME-Version: 1.0 Cc: Jean-Marc Valin Subject: Re: [codec] Updated Charter Proposal Take 3 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:59:42 -0000 --_000_C696063BEFE2hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a very useful approach in the IETF. Unless the IETF steps up to a standard, nobody can stop the proliferation o= f free audio (and video) codecs and the ensuing interoperability problems. Henry On 7/29/09 11:13 AM, "Jason Fischl" wrote: Jean-Marc and I have updated the charter based on the comments from Roni an= d a few private replies. -------------- DRAFT CHARTER: Motivation: There is interest and value in having widely, easily distributable and accessible codec technology from the Internet community. Codec experts from both within and outside the IETF community have expressed an interest in contributing effort in this area. The IETF standards process provides a model for producing standards that encourages transparent design and open collaboration early on in the process. Any IETF codec designs that may emerge will also benefit from input and review from other RAI working group= s and other areas of the IETF. Goals: The goal of this working group is to standardize audio codecs that can be implemented, distributed, and used broadly, and be interoperable between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs optimized fo= r very low bit rates or for non-interactive audio are out of scope. The codec= s should address the following technical considerations: * suitability for most fixed-point Digital Signal Processors (DSP); * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; Beyond technical considerations, IPR issues will be handled in accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use acros= s the Internet community difficult. The working group will try to standardize codecs that can be relatively freely and easily distributed, and employed a= s much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "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." Note that in accordance with BCP 79, this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; the decision will be left to the normal rough consensus of the working group. Deliverables: 1) Codec Standardization Guidelines - that define a set of metrics which ca= n be used to evaluate a codec. These metrics would include complexity, qualit= y vs bitrate, algorithmic delay, packet loss performance and footprint. The complete list will be specified in this document. An evaluation of these metrics should be considered by the working group in trying to come to consensus about proposed changes to one of the draft codecs. A set of pass/fail requirements MAY be specified in the requirements document. It will be up to the working group to evaluate whether or not the proposed codec is better than the reference codec. Continuous testing will be done throughout the process. After a codec is finalized, these guidelines will b= e used to characterize the codec. This is an Informational track document. 2) Requirements Document - that defines the application requirements of the resulting solution. The requirements will include the exact technical considerations including the target values for metrics defined in the Codec Standardization Guidelines, any pass/fail requirements, an optional reference codec, the scenarios that are being addressed and the assumptions about the Internet operating environment. This is an Informational track document. 3) Algorithm description for one or more wideband Internet audio codecs. There MUST be a text description of the algorithm as well as a reference implementation. The reference implementation MUST include an encoder and a decoder, and MUST be compliant with BCP 78 and BCP 79. The text description MUST indicate those components of the encoder and decoder which are mandatory, recommended and optional. For example, in some codec definitions only the decoder is specified whereas others have bit-exact specifications. Any characterization MUST be performed with the reference encoder. This is = a Proposed Standard document. It is not necessary to produce a single codec that solves the entire range of scenarios. A codec may be approved by the working group without addressing all of the scenarios. Milestones: Jan-2010: WGLC on Codec Standardization Guidelines Jan-2010: WGLC on Requirements Jul-2010: WGLC on codec algorithm description(s) to IESG Mar-2010: Codec Standardization Guidelines to IESG (Informational) Mar-2010: Requirements to IESG (Infomational) Jan-2011: Submit codec algorithm description(s) to IESG (Standards Track) _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C696063BEFE2hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Updated Charter Proposal Take 3 This is a very useful approach in the IETF.
 
Unless the IETF steps up to a standard, nobody can stop the proliferation o= f free audio (and video) codecs and the ensuing interoperability problems.<= BR>
Henry


On 7/29/09 11:13 AM, "Jason Fischl" <jason.fischl@skype.net> wrote:

Jean-Marc and I have updated the charter ba= sed on the comments from Roni and
a few private replies.

--------------
DRAFT CHARTER:

Motivation:

There is interest and value in having widely, easily distributable and
accessible codec technology from the Internet community. Codec experts=A0fr= om
both within and outside=A0the IETF community have expressed an interest in<= BR> contributing effort in this area. The IETF standards process provides a
model for producing standards that encourages=A0transparent design and open=
collaboration early on in the process. Any IETF codec designs that may
emerge will also benefit from input and review from other RAI working group= s
and other areas of the IETF.

Goals:

The goal of this working group is to standardize audio codecs that can be implemented, distributed, and used broadly, and be interoperable between a<= BR> wide set of interested parties. The group is chartered to work on audio
codecs for interactive communication over the Internet. Codecs optimized fo= r
very low bit rates or for non-interactive audio are out of scope. The codec= s
should address the following technical considerations:

 * suitability for most fixed-point Digital Signal Processors (DSP);  * medium- to high-quality speech at moderate bit-rate;
 * high-quality music encoding at higher bit-rates;
 * sampling rate profiles from narrow-band to full audio bandwidth;  * real-time adaptive bit rate;
 * source-controlled variable bit-rate (VBR);
 * low algorithmic delay;

Beyond technical considerations, IPR issues will be handled in accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the
technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use acros= s
the Internet community difficult. The working group will try to standardize=
codecs that can be relatively freely and easily distributed, and employed a= s
much as possible. In doing so, it=A0will adhere closely to these BCPs. More=
specifically, "In general, IETF working groups prefer technologies wit= h no
known IPR claims or, for technologies with claims against them, an offer of=
royalty-free licensing." Note that in accordance with BCP 79, this wor= king
group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; the decision will be left to the=
normal rough consensus of the working group.=A0

Deliverables:

1) Codec Standardization Guidelines - that define a set of metrics which ca= n
be used to evaluate a codec. These metrics would include=A0complexity, qual= ity
vs bitrate, algorithmic delay, packet loss performance and footprint. The complete list will be specified in this document. An evaluation of these metrics should be considered by the working group in trying to come to
consensus about proposed changes to one of the draft codecs. A set of
pass/fail requirements MAY be specified in the requirements document. It will be up to the working group to evaluate whether or not the proposed
codec is better than the reference codec. Continuous testing will be done throughout the process. After a codec is finalized, these guidelines will b= e
used to characterize the codec. This is an Informational track document.
2) Requirements Document - that defines the application requirements of the=
resulting solution. The requirements will include the exact technical
considerations including the target values for metrics defined in the Codec=
Standardization Guidelines, any pass/fail requirements, an optional
reference codec, the scenarios that are being addressed and the assumptions=
about the Internet operating environment. This is an Informational track document.

3) Algorithm description for one or more wideband=A0Internet audio codecs.<= BR> There MUST be a text description of the algorithm as well as a reference implementation.=A0The reference implementation MUST include an encoder and = a
decoder, and MUST be compliant with BCP 78 and BCP 79. The text description=
MUST indicate those components of the encoder and decoder which are
mandatory, recommended and optional. For example, in some codec definitions=
only the decoder is specified whereas others have bit-exact specifications.=
Any characterization MUST be performed with the reference encoder. This is = a
Proposed Standard document.=A0

It is not necessary to produce a single codec that solves the entire range<= BR> of scenarios. A codec may be approved by the working group without
addressing all of the scenarios.

Milestones:

Jan-2010: WGLC on Codec Standardization Guidelines=A0
Jan-2010: WGLC on Requirements=A0
Jul-2010: WGLC on codec algorithm description(s) to IESG
Mar-2010: Codec Standardization Guidelines to IESG (Informational)
 Mar-2010: Requirements to IESG (Infomational)
Jan-2011: Submit codec algorithm description(s) to IESG (Standards Track)
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C696063BEFE2hsinnreiadobecom_-- From ron.even.tlv@gmail.com Wed Jul 29 05:05:42 2009 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 A1D243A6D3B for ; Wed, 29 Jul 2009 05:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 3crkQItBD+nv for ; Wed, 29 Jul 2009 05:05:41 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id CCD063A7011 for ; Wed, 29 Jul 2009 05:05:40 -0700 (PDT) Received: by bwz21 with SMTP id 21so640708bwz.37 for ; Wed, 29 Jul 2009 05:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=2yCOZexVRd9zHcq5E9efPMxG1rPT2i9QWz4jox6D8Ns=; b=cbxZVINGpjAqO1wNXr1U9LvhyuyICrSAo9JjiaatSFVpT1f2TIRZxLzH98+cUIBuJ5 Dom18Elu6ZXVgR9Wb7hueNaxWjf/9bjsybY7JKgbrL7HUXnp/AieoD9CrF2ZPQnrUGVC 2poUeB5u96BZitLhgdXcPX10T7ps3VYtVWJ0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Z0QMfSvGz0KpYLPwJjgJD4OozidB3ou91K3Sg9KD41Bh1WUQU9mHf+wJ4QpP9V3Hi4 VhSMOxNV3+CueFa4LUeVORMqhf2WYkmvMlQTjzJ5kkrwwKp3z41+bN8LQ0oCeVHGpy9p 3Yp4qbky0ElJfNBEtmz98iaXMgrqyxGteyIwU= Received: by 10.103.189.18 with SMTP id r18mr4588186mup.98.1248869139728; Wed, 29 Jul 2009 05:05:39 -0700 (PDT) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by mx.google.com with ESMTPS id 23sm4958613mun.43.2009.07.29.05.05.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 05:05:38 -0700 (PDT) From: "Roni Even" To: "'Gregory M. Lebovitz'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> In-Reply-To: <4a700d8c.09a1660a.2552.2ee1@mx.google.com> Date: Wed, 29 Jul 2009 15:03:53 +0300 Message-ID: <4a703b12.170e660a.5ab0.ffffc643@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoQKcIfbtfDbLbSRN6AUE2ea7IroAAGVQRw Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:05:42 -0000 Gregory, I think that the charter should be clear and should not depend so much on personal views. In general I have no problem with your analysis and example. The thing is that by the end we need to approve each codec and if it is going through multiple tests will it need to pass all of them, will there be one that are mandatory to pass and other are optional, this will compose what you call as the final score. I believe that in order to approve a codec the wg should see the test results before they accept it in a WGLC. If the tests results provided to the working group are just for information and are not relevant for last call a codec than we do not need requirements or tests and just need to read the codec description and do last call. Roni Even > -----Original Message----- > From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] > Sent: Wednesday, July 29, 2009 11:51 AM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Agenda for the Codec Bof > > Roni, > Just to clarify how I read the latest charter... > > It's not that a WG would "test" the quality of the audio of a > candidate mechanism or codec. It's not a pass vs fail thing. There > doesn't need to be a winner and a loser. In fact, the word "test" > does not appear in the charter. The charter does say: > > "define a set of metrics which can be used to evaluate a codec. " > > The word "evaluate" is very different. I read it to mean "how will a > group of people normalize their collective subjective opinion on an > observed condition". By example, consider the way cars are reviewed > in magazines. Judges who have been trained on a set of metrics about > performance under different conditions (say top end speed, or > cornering, or acceleration, or storage space) have a shared set of > definitions of performance they might observe, both good and > impressive performance as well as poor/faulty performance. They also > have a standard measurement scale -- in this example scoring by > points -- by which they record their observations of performance. The > measurement scale includes different values for different performance > elements, i.e. certain observations cost 1/2 point deduction, others > cost 1/4 point, and some gain points because they are more difficult > or beneficial. When comparing two sports cars one might be better at > sharp turns at high speeds and acceleration, while another might be > better at sustained high speeds on straight aways. But both are > terrible at fitting your family of 6 and all your luggage for a 10 hr > road trip over dirt and rock terrain, towing a ski boat. > > Likewise, this WG will need to come up with a shared set of > "performance" metrics that they might observe from a codec or its > sub-mechanisms. And it will need to agree on a system for valuing > these metrics. Like the vehicle example, the WG may not determine one > winner, and determine all others losers. But might simply evaluate > two and agree that X codec/mechanism is better at Alpha and Beta, > where as Y codec/mechanism just as good at Beta, but not as good in > Alpha, but much better in Delta, and thus is better applied to > environment 3, but not as good as X in environment 2. > > My point is that the word "evaluate" is intended to have a far > different meaning than purely "test". We may do many tests in order > to form a unified evaluation. > > This might be a very subtle difference, but I think it important to > tease out. > > Hope it helps, > Gregory > > At 10:36 PM 7/28/2009, Roni Even wrote: > >Markus, > >I am happy to hear it, so here is the challenge for you, I assume you > are > >following the email discussion and one of the topic is how to define > metrics > >and test the quality of the audio candidate. I will be interested to > see you > >position about it. > >Regards > >Roni Even > > > > > > > > > >-----Original Message----- > > > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > > > Sent: Wednesday, July 29, 2009 3:41 AM > > > To: 'Lars Eggert'; 'Roni Even' > > > Cc: codec@ietf.org > > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > > > > Hi Lars, Roni and all, > > > > > > Roni and Lars wrote: > > > >> but no capability to do a real review and quality assessment > > > > > > > agree with Roni. Having codec specs available that (apparently) > fit > > > > the requirements is nice, but it's not clear at all that that > means > > > > that the experts who have created these codecs will actively > > > > participate in an IETF effort that would be based on something > other > > > > than their initial candidate submission. > > > > > > I'm very willing to contribute to the reviewing and quality > > > assessments. > > > > > > I have the lead Call/Audio/Speech Quality Assessment role at Skype > and > > > I'm > > > working daily with subjective user feedbacks, stats, objective > quality > > > measurement tools (such as PESQ/P.862), audio measurements, lab, > > > informal & > > > formal listening tests, user centric and tech. requirements, even > codec > > > & > > > other processing algorithm details etc... I also actively follow > and > > > participate (as an invited expert) to the key standardization > forums of > > > these matters - ITU-T SG 12 > > > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ > > > (http://portal.etsi.org/stq/Summary.asp). So I hope I have > something to > > > bring to the common work. > > > > > > I'm also sure there are ways to run a part of formal listening > tests at > > > Skype facilities if that's seen beneficial later. (or we can > arrange > > > tests > > > with some of the 3rd party labs) > > > > > > Before I moved to Skype a bit more than 3 years ago, I worked for > > > around 8 > > > years in/for Nokia on the similar Speech/Audio Quality Assessment > > > matters + > > > audio SW algorithms & audio&speech codecs... and the most of that > time > > > I've > > > worked at the same building that Lars appears to be working today > ;-) > > > > > > Best regards with my few Euro cents... > > > > > > Markus Vaalgamaa > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf > > > Of > > > Lars Eggert > > > Sent: Tuesday, July 28, 2009 9:23 AM > > > To: Roni Even > > > Cc: codec@ietf.org > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > Hi, > > > > > > On 2009-7-27, at 23:48, Roni Even wrote: > > > > Having two codec suggested does not represent expertise to review > > > > codec > > > > work. The IETF "rubber stamped" the iLBC codec. There was a > proposed > > > > codec, > > > > which you consider expertise, but no capability to do a real > review > > > > and > > > > quality assessment > > > > > > agree with Roni. Having codec specs available that (apparently) fit > > > the requirements is nice, but it's not clear at all that that means > > > that the experts who have created these codecs will actively > > > participate in an IETF effort that would be based on something > other > > > than their initial candidate submission. > > > > > > Lars > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec From simon.perreault@viagenie.ca Wed Jul 29 05:10:55 2009 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 BF0CE3A7062 for ; Wed, 29 Jul 2009 05:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 5PDwjQYzvyvu for ; Wed, 29 Jul 2009 05:10:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 525E33A7060 for ; Wed, 29 Jul 2009 05:10:52 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 3DD1829E15DE; Wed, 29 Jul 2009 08:10:52 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id A22E229E15D5 for ; Wed, 29 Jul 2009 08:10:49 -0400 (EDT) Message-ID: <4A703C43.90404@viagenie.ca> Date: Wed, 29 Jul 2009 14:10:43 +0200 From: Simon Perreault User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [codec] Voicing my support X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:10:56 -0000 I, for one, hope this will evolve into a large, long-lived, and legendary working-group where patent-free Internet codecs will be developed for all purposes: the Internet's codec foundry. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jmh@joelhalpern.com Wed Jul 29 05:17:05 2009 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 8775B3A6FFF for ; Wed, 29 Jul 2009 05:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 k6hNixht1Wiz for ; Wed, 29 Jul 2009 05:17:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 557F13A62C1 for ; Wed, 29 Jul 2009 05:17:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3AB324300AA; Wed, 29 Jul 2009 05:17:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.17.160] (dhcp-11a0.meeting.ietf.org [130.129.17.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 671034300A5; Wed, 29 Jul 2009 05:17:04 -0700 (PDT) Message-ID: <4A703DBE.3070006@joelhalpern.com> Date: Wed, 29 Jul 2009 08:17:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: United Replies , "codec@ietf.org" References: <200972965023.n6TBoNM20074@ulsmlbx01> In-Reply-To: <200972965023.n6TBoNM20074@ulsmlbx01> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Miles for your thoughts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:17:05 -0000 This suggests that some folks understand this charter as being open-ended. (I do wonder about the bounds on a charter to define an undefined number of codecs.) It has normally been understood (I would calim it is a hard and fast rule, but it is widely understood and widely taken as important) that WGs should be defined in such a way that the WG has defined scope, and has a well-defined "completion" at which point it is done. If we really want to define a new kind of beast, one with a perpetual charter, we should be very clear about that. Yours, Joel M. Halpern United Offers and Announcements wrote: > To ensure receipt of our emails, please add > email@info.united.com to your Address Book. > > ============================================================ > United Mileage Plus(R) > ============================================================ > > ************************************************************ > 100,000 MILES FOR YOUR THOUGHTS > ************************************************************ > > Dear Joel M Halpern, > > You've just traveled with us, and we'd like to know how you > enjoyed your trip. > > Please tell us how we can make your travels even more > comfortable and convenient by taking our five-minute survey, > and you'll get a chance to win 100,000 Mileage Plus(R) bonus > miles. > > Just complete this five-minute survey within seven days of > the completion of your trip, and you'll be automatically > entered in our exclusive sweepstakes giveaway. Your feedback > will help ensure that we continue to provide everything you > are looking for in a flight experience and more. > > Thanks for sharing your thoughts, and thanks for flying > United! > ---------------------- > TAKE THE SURVEY NOW > ---------------------- > http://mymileageplus.com/mmps/89998/242779/c4be1a19be19907d170c0b3402bf5381 > > ============================================================ > Terms and Conditions: > > No Purchase Necessary: This sweepstakes is open to persons > 21 years of age or older, except the employees, and their > families, of United and Pearson Assessments, and the > affiliates, subsidiaries, and advertising agencies of > either company. This offer is void wherever prohibited and > subject to all federal, state, and local laws. United > reserves the right to terminate this sweepstakes > without notice. > > 1. By filling out this questionnaire, you are automatically > entered in the WIN MILES SWEEPSTAKES. If you do not wish to > fill out this questionnaire but would like to enter the > sweepstakes, print your name, address, zip code, flight > number, date of travel and the words "WIN MILES SWEEPSTAKES" > on a plain 3" x 5" index card. Mail your entry to: Pearson > Assessments, ATTN: United Survey Sweepstakes Winners, 1313 > Lone Oak Road, Eagan, MN 55121-1334. > > 2. Winner must be a Mileage Plus(R) member in order to > receive the Prize. A Winner not currently a member will be > invited to become a member in order to receive the Prize. > Non flight bonus miles can only be credited to the winner's > Mileage Plus(R) account. Non flight Mileage Plus(R) miles > apply to base flight miles only and do not count toward > elite status. Miles accrued, awards issued and bonus offers > are subject to the rules of the United Mileage Plus(R) > program. The Mileage Plus(R) Program, including accruals, > awards and bonus miles offers is subject to change without > notice. Taxes and fees related to award travel are the > responsibility of the passenger. United and Mileage Plus(R) > are registered service marks. For complete details about the > Mileage Plus(R) program, visit mileageplus.com. > > 3. Winners will be selected in random drawings conducted by > Pearson Assessments, an independent organization whose > decisions are final on all matters relating to the > sweepstakes. All prizes are non-transferable and no > substitutes or cash equivalents are allowed. Taxes, if any, > are the responsibility of the individual winners. Winners > will be asked to execute an affidavit of eligibility and > release. Non-flight miles will be posted to the member's > account within one month from the time when the affidavit is > returned to United. > > 4. Drawings for prizes will be conducted on a quarterly > basis, starting with October-December 2006; the end date of > this sweepstakes has not been determined but can be chosen > by United at any time. Entries submitted will be eligible > for the drawing which takes place in the month immediately > subsequent to the quarter in which travel occurred. Each > drawing will have one prize, consisting of 100,000 Mileage > Plus(R) miles to be awarded to the winner's Mileage Plus(R) > account. See mileageplus.com to enroll online. > > 5. Retail value of the prize depends on the actual > itinerary flown. Chance of winning depends on the number of > eligible entrants. For a list of winners, send a stamped, > self-addressed envelope within one year of the drawing to: > WIN MILES SWEEPSTAKES WINNERS LIST, United Airlines, ATTN: > WHQLA, P.O. Box 66100, Chicago, IL 60666. > > ____________________________________________________________ > > My mileage summary > http://www.mymileageplus.com > > united.com > http://www.united.com > > Partner offers > http://www.united.com/page/article/0,8566,1176,00.html > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Change your email address > http://mymileageplus.com/mmps/99432/242779/c4be1a19be19907d170c0b3402bf5381 > > Update your email preferences > http://mymileageplus.com/mmps/89999/242779/c4be1a19be19907d170c0b3402bf5381 > > Privacy policy > http://www.united.com/privacy > > > You are subscribed to receive information and updates from > United at JMH@JOELHALPERN.COM. > > Please do not reply to this email. We cannot accept > electronic replies to this email address. > > To contact the sender, write to: > United Airlines Operations Center - WHQPW, > 1200 E. Algonquin Rd., > Elk Grove Township, > Illinois 60007 USA > > Copyright 2009 United Air Lines, Inc. All rights reserved. > From jmh@joelhalpern.com Wed Jul 29 05:21:17 2009 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 D5D963A6971 for ; Wed, 29 Jul 2009 05:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 b25bDEKR1Kov for ; Wed, 29 Jul 2009 05:21:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 270993A684C for ; Wed, 29 Jul 2009 05:21:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 14B8E4300A8 for ; Wed, 29 Jul 2009 05:21:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.17.160] (dhcp-11a0.meeting.ietf.org [130.129.17.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6E1314300A7 for ; Wed, 29 Jul 2009 05:21:18 -0700 (PDT) Message-ID: <4A703EBC.7040200@joelhalpern.com> Date: Wed, 29 Jul 2009 08:21:16 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [codec] Sorry X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:21:17 -0000 My finger slipped and I was paying sufficient attention, so I ended up forwarding a completely irrelevant note to the list. Apologetically, Joel From jmh@joelhalpern.com Wed Jul 29 05:26:43 2009 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 C42593A6F5E for ; Wed, 29 Jul 2009 05:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, 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 ZHka-k15Z64W for ; Wed, 29 Jul 2009 05:26:43 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B19803A6966 for ; Wed, 29 Jul 2009 05:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 454724300A7; Wed, 29 Jul 2009 05:26:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.17.160] (dhcp-11a0.meeting.ietf.org [130.129.17.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7A72A4300A5; Wed, 29 Jul 2009 05:26:41 -0700 (PDT) Message-ID: <4A703FFF.1090002@joelhalpern.com> Date: Wed, 29 Jul 2009 08:26:39 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Simon Perreault References: <4A703C43.90404@viagenie.ca> In-Reply-To: <4A703C43.90404@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Voicing my support X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:26:43 -0000 (This is the note I was trying to reply to.) To rephrase my response, given the wording of the charter, Simon's comment is quite understandable. The charter refers to an unbounded number of codecs being approved. I suspect that the proposer do not intend a WG that continually produces codecs. Some clarity about how many are to be produced, or how we know when we are supposed to choose as against when approving multiple is appropriate, would seem helpful in understanding the charter. Yours, Joel M. Halpern Simon Perreault wrote: > I, for one, hope this will evolve into a large, long-lived, and > legendary working-group where patent-free Internet codecs will be > developed for all purposes: the Internet's codec foundry. > > Simon From simon.perreault@viagenie.ca Wed Jul 29 05:31:01 2009 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 911923A701C for ; Wed, 29 Jul 2009 05:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 O0a8W0zv0OGW for ; Wed, 29 Jul 2009 05:31:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DD0643A7052 for ; Wed, 29 Jul 2009 05:28:56 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id F00BC14A0003; Wed, 29 Jul 2009 08:28:55 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id 9581D14A0002; Wed, 29 Jul 2009 08:28:52 -0400 (EDT) Message-ID: <4A704080.30404@viagenie.ca> Date: Wed, 29 Jul 2009 14:28:48 +0200 From: Simon Perreault User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200972965023.n6TBoNM20074@ulsmlbx01> <4A703DBE.3070006@joelhalpern.com> In-Reply-To: <4A703DBE.3070006@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] Miles for your thoughts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:31:01 -0000 Joel M. Halpern wrote: > This suggests that some folks understand this charter as being > open-ended. (I do wonder about the bounds on a charter to define an > undefined number of codecs.) No. This is not how I understood the charter. The charter is more restrictive than I would like it to be. One can always hope... Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Wed Jul 29 05:44:49 2009 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 910C93A6966 for ; Wed, 29 Jul 2009 05:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 fHmZdoBbYw30 for ; Wed, 29 Jul 2009 05:44:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A98AA3A6403 for ; Wed, 29 Jul 2009 05:44:46 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id CE14E14A0003; Wed, 29 Jul 2009 08:44:44 -0400 (EDT) Received: from dhcp-13e3.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:20a:95ff:fef7:a2af]) by jazz.viagenie.ca (Postfix) with ESMTP id B379014A0002; Wed, 29 Jul 2009 08:44:40 -0400 (EDT) Message-ID: <4A704432.8060706@viagenie.ca> Date: Wed, 29 Jul 2009 14:44:34 +0200 From: Simon Perreault User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Joel M. Halpern" References: <200972965023.n6TBoNM20074@ulsmlbx01> <4A703DBE.3070006@joelhalpern.com> <4A704080.30404@viagenie.ca> <4A7041F9.9010907@joelhalpern.com> In-Reply-To: <4A7041F9.9010907@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Charter comments X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:44:49 -0000 Joel M. Halpern wrote: > I presume you relize that perpetual working groupsa re normally against > IETF policy? Yes I know. perpetual != large, long-lived, nor legendary. I think the IETF should take on the immense task of creating patent-free Internet codecs for all purposes. And when the WG is done with that, dissolve. (The current charter is not this broad. Examples: "Codecs optimized for very low bit rates or for non-interactive audio are out of scope." "medium- to high-quality speech at moderate bit-rate" "real-time adaptive bit rate" etc.) (Maybe it is better to take it in strides and recharter along the way. I don't think the first step should make anyone queasy, and it can even serve as a test.) Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From sjoerd.simons@collabora.co.uk Wed Jul 29 06:48:20 2009 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 C5FCB3A70C0 for ; Wed, 29 Jul 2009 06:48:20 -0700 (PDT) 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 tVMBNzlaLyMi for ; Wed, 29 Jul 2009 06:48:19 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.131.97]) by core3.amsl.com (Postfix) with ESMTP id 72B443A70C7 for ; Wed, 29 Jul 2009 06:48:19 -0700 (PDT) Received: from night.luon.net (unknown [194.224.98.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 6986EB357; Wed, 29 Jul 2009 14:48:19 +0100 (BST) Received: by night.luon.net (Postfix, from userid 1000) id 6D54D755A7; Wed, 29 Jul 2009 15:48:18 +0200 (CEST) Date: Wed, 29 Jul 2009 15:48:18 +0200 From: Sjoerd Simons To: codec@ietf.org Message-ID: <20090729134818.GA30728@night.luon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: robert.mcqueen@collabora.co.uk, christian.schaller@collabora.co.uk Subject: [codec] Collabora's position on the Codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:48:20 -0000 Collabora Ltd. and Collabora Multimedia support the formation of an IETF open codecs working group. Standardising best-of-breed audio and video codecs for use in Internet protocols, that are compatible for use in open source projects (meaning royalty and patent-free and implementable under a free and open source software license), will be of extensive benefit to the Internet community. Collabora Ltd. is the primary developer of the Telepathy real-time instant messaging framework and the associated Farsight VoIP framework, tools which allow for the development of, among other things, voice and video communication clients. Collabora also develops the Empathy instant messaging client, part of the GNOME Desktop, and now included in many popular GNU/Linux software distributions (including Fedora and Ubuntu), that uses Telepathy to provide voice and video calling. With the exception of the Speex codec, the licenses and obligations of existing Internet telephony codecs prevent them from being provided as part of a free and open software distribution; either as part of a GNU/Linux distribution, or a software package such as Empathy. This significantly raises the barrier for users to communicate. We believe that an IETF Working Group will be able to build upon the existing work done by groups such as Xiph.org to bring standardised, royalty-free codecs to the wider community. The track record of IPR-free codecs such as Speex, Vorbis, Theora, Dirac, FLAC and CELT demonstrate that it is possible to develop good quality, patent-free codecs using an open-source methodology. Although it can never be completely guaranteed that any given codec certainly does not infringe on a patent, regardless of the organisation that builds it, the codecs mentioned above have been available to the public for some time and are still considered IPR-free. Thus we believe that with sufficient prior research, patent issues for codecs can be avoided. By bringing together the relevant stakeholders: codec designers, protocol engineers, device manufacturers, and framework and application developers; we believe that significant progress could be made towards standardising a set of acceptable free and unencumbered protocols to foster much greater interoperability. Robert McQueen (Director Collabora Ltd.) Christian Schaller (Director Collabora Multimedia) Sjoerd Simons (R&D Lead Collabora Ltd.) From stephen.botzko@gmail.com Wed Jul 29 06:54:08 2009 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 BF7753A6EB7 for ; Wed, 29 Jul 2009 06:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] 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 JdkJhIITUUQz for ; Wed, 29 Jul 2009 06:54:07 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 9FE133A6903 for ; Wed, 29 Jul 2009 06:53:34 -0700 (PDT) Received: by fxm18 with SMTP id 18so403649fxm.37 for ; Wed, 29 Jul 2009 06:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7NKNVJvKLFr0GaSqXUaNlwCB21PVUT98YHbI5UNIbVk=; b=u96s7Hfui3TkQRPwykeHgjQxqyFB1dhbZ/5DkuOJXmTSJP1t+M9BG1jEUD87GpB4g/ MJqE3Swshpcb4ZAg4bpyntytLoKL0/8lxjGtnmsuAgb8+XIM/Vhxy84ciFlf5x03aXcd PMHIp351FRdMIloJIYn5ceqZr26yXczs8Ts+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vkZcT3GRA3qoRTGfpRaTLDkG4+x7cfOLwUrlSkZrjsSWDK4lnfZ55Nkhk3+36kBDyS QI/svCdIoc2MY40v7cHBaZR9NvuG+E6ERxJ3UOwMYszXQb0KdPO8YW9aC1fdiq90Mc9b Br9K9C2Wfi8sT6zrmCtbMwTxC60UBpekP38y0= MIME-Version: 1.0 Received: by 10.103.167.14 with SMTP id u14mr4693476muo.81.1248875609597; Wed, 29 Jul 2009 06:53:29 -0700 (PDT) In-Reply-To: <4a700d8c.09a1660a.2552.2ee1@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> Date: Wed, 29 Jul 2009 09:53:27 -0400 Message-ID: <6e9223710907290653p3c1561cckb9c792d190d418cd@mail.gmail.com> From: stephen botzko To: "Gregory M. Lebovitz" Content-Type: multipart/alternative; boundary=0016e659fa661462ab046fd8839b Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:54:08 -0000 --0016e659fa661462ab046fd8839b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I suggest the dictionary definition of "evaluate" is sufficient for the charter. Evaluate: 1 *:* to determine or fix the value of 2 *:* to determine the significance, worth, or condition of; usually by careful appraisal and study I'd say there is a distinction between what you are calling evaluation and what in other SDOs is called characterization. Characterization (in my view) is not a tracking document and is not a weighted scoring system. It is a deliverable that describes the codec behavior that has lasting value. One example from 3GPP is found here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip I would prefer to see a characterization deliverable either as a section of the codec RFC, or as a separate informational RFC. Regards Stephen Botzko Polycom On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz wrote: > Roni, > Just to clarify how I read the latest charter... > > It's not that a WG would "test" the quality of the audio of a candidate > mechanism or codec. It's not a pass vs fail thing. There doesn't need to be > a winner and a loser. In fact, the word "test" does not appear in the > charter. The charter does say: > > "define a set of metrics which can be used to evaluate a codec. " > > The word "evaluate" is very different. I read it to mean "how will a group > of people normalize their collective subjective opinion on an observed > condition". By example, consider the way cars are reviewed in magazines. > Judges who have been trained on a set of metrics about performance under > different conditions (say top end speed, or cornering, or acceleration, or > storage space) have a shared set of definitions of performance they might > observe, both good and impressive performance as well as poor/faulty > performance. They also have a standard measurement scale -- in this example > scoring by points -- by which they record their observations of performance. > The measurement scale includes different values for different performance > elements, i.e. certain observations cost 1/2 point deduction, others cost > 1/4 point, and some gain points because they are more difficult or > beneficial. When comparing two sports cars one might be better at sharp > turns at high speeds and acceleration, while another might be better at > sustained high speeds on straight aways. But both are terrible at fitting > your family of 6 and all your luggage for a 10 hr road trip over dirt and > rock terrain, towing a ski boat. > > Likewise, this WG will need to come up with a shared set of "performance" > metrics that they might observe from a codec or its sub-mechanisms. And it > will need to agree on a system for valuing these metrics. Like the vehicle > example, the WG may not determine one winner, and determine all others > losers. But might simply evaluate two and agree that X codec/mechanism is > better at Alpha and Beta, where as Y codec/mechanism just as good at Beta, > but not as good in Alpha, but much better in Delta, and thus is better > applied to environment 3, but not as good as X in environment 2. > > My point is that the word "evaluate" is intended to have a far different > meaning than purely "test". We may do many tests in order to form a unified > evaluation. > > This might be a very subtle difference, but I think it important to tease > out. > > Hope it helps, > Gregory > > > At 10:36 PM 7/28/2009, Roni Even wrote: > >> Markus, >> I am happy to hear it, so here is the challenge for you, I assume you are >> following the email discussion and one of the topic is how to define >> metrics >> and test the quality of the audio candidate. I will be interested to see >> you >> position about it. >> Regards >> Roni Even >> >> >> >> >> -----Original Message----- >> > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] >> > Sent: Wednesday, July 29, 2009 3:41 AM >> > To: 'Lars Eggert'; 'Roni Even' >> > Cc: codec@ietf.org >> > Subject: RE: [codec] Agenda for the Codec Bof >> > >> > >> > Hi Lars, Roni and all, >> > >> > Roni and Lars wrote: >> > >> but no capability to do a real review and quality assessment >> > >> > > agree with Roni. Having codec specs available that (apparently) fit >> > > the requirements is nice, but it's not clear at all that that means >> > > that the experts who have created these codecs will actively >> > > participate in an IETF effort that would be based on something other >> > > than their initial candidate submission. >> > >> > I'm very willing to contribute to the reviewing and quality >> > assessments. >> > >> > I have the lead Call/Audio/Speech Quality Assessment role at Skype and >> > I'm >> > working daily with subjective user feedbacks, stats, objective quality >> > measurement tools (such as PESQ/P.862), audio measurements, lab, >> > informal & >> > formal listening tests, user centric and tech. requirements, even codec >> > & >> > other processing algorithm details etc... I also actively follow and >> > participate (as an invited expert) to the key standardization forums of >> > these matters - ITU-T SG 12 >> > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ >> > (http://portal.etsi.org/stq/Summary.asp). So I hope I have something to >> > bring to the common work. >> > >> > I'm also sure there are ways to run a part of formal listening tests at >> > Skype facilities if that's seen beneficial later. (or we can arrange >> > tests >> > with some of the 3rd party labs) >> > >> > Before I moved to Skype a bit more than 3 years ago, I worked for >> > around 8 >> > years in/for Nokia on the similar Speech/Audio Quality Assessment >> > matters + >> > audio SW algorithms & audio&speech codecs... and the most of that time >> > I've >> > worked at the same building that Lars appears to be working today ;-) >> > >> > Best regards with my few Euro cents... >> > >> > Markus Vaalgamaa >> > >> > >> > -----Original Message----- >> > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> > Of >> > Lars Eggert >> > Sent: Tuesday, July 28, 2009 9:23 AM >> > To: Roni Even >> > Cc: codec@ietf.org >> > Subject: Re: [codec] Agenda for the Codec Bof >> > >> > Hi, >> > >> > On 2009-7-27, at 23:48, Roni Even wrote: >> > > Having two codec suggested does not represent expertise to review >> > > codec >> > > work. The IETF "rubber stamped" the iLBC codec. There was a proposed >> > > codec, >> > > which you consider expertise, but no capability to do a real review >> > > and >> > > quality assessment >> > >> > agree with Roni. Having codec specs available that (apparently) fit >> > the requirements is nice, but it's not clear at all that that means >> > that the experts who have created these codecs will actively >> > participate in an IETF effort that would be based on something other >> > than their initial candidate submission. >> > >> > Lars >> >> _______________________________________________ >> 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 > --0016e659fa661462ab046fd8839b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suggest the dictionary definition of "evaluate" is sufficient f= or the charter.

Evaluate:
1 :=20 to determine or fix the value of
2 :=20 to determine the significance, worth, or condition of; usually by careful= =20 appraisal and study

I'd say there is a distinction bet= ween what you are calling evaluation and what in other SDOs is called chara= cterization.=A0

Characterization (in my view) is not a tracking doc= ument and is not a weighted scoring system. It is a deliverable that descri= bes the codec behavior that has lasting value. One example from 3GPP is fou= nd here:

http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.= zip

I would prefer to see a characterization deliverable either = as a section of the codec RFC, or as a separate informational RFC.

Regards
Stephen Botzko
Polycom

= On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz <= gregory.ietf@gmail.com> wrote:
Roni,
Just to clarify how I read the latest charter...

It's not that a WG would "test" the quality of the audio of a= candidate mechanism or codec. It's not a pass vs fail thing. There doe= sn't need to be a winner and a loser. In fact, the word "test"= ; does not appear in the charter. The charter does say:

"define a set of metrics which can be used to evaluate a codec. "=

The word "evaluate" is very different. I read it to mean "ho= w will a group of people normalize their collective subjective opinion on a= n observed condition". By example, consider the way cars are reviewed = in magazines. Judges who have been trained on a set of metrics about perfor= mance under different conditions (say top end =A0speed, or cornering, or ac= celeration, or storage space) have a shared set of definitions of performan= ce they might observe, both good and impressive performance as well as poor= /faulty performance. They also have a standard measurement scale -- in this= example scoring by points -- by which they record their observations of pe= rformance. The measurement scale includes different values for different pe= rformance elements, i.e. certain observations cost 1/2 point deduction, oth= ers cost 1/4 point, and some gain points because they are more difficult or= beneficial. When comparing two sports cars one might be better at sharp tu= rns at high speeds and acceleration, while another might be better at susta= ined high speeds on straight aways. But both are terrible at fitting your f= amily of 6 and all your luggage for a 10 hr road trip over dirt and rock te= rrain, towing a ski boat.

Likewise, this WG will need to come up with a shared set of "performan= ce" metrics that they might observe from a codec or its sub-mechanisms= . And it will need to agree on a system for valuing these metrics. Like the= vehicle example, the WG may not determine one winner, and determine all ot= hers losers. But might simply evaluate two and agree that X codec/mechanism= is better at Alpha and Beta, where as Y codec/mechanism just as good at Be= ta, but not as good in Alpha, but much better in Delta, and thus is better = applied to environment 3, but not as good as X in environment 2.

My point is that the word "evaluate" is intended to have a far di= fferent meaning than purely "test". We may do many tests in order= to form a unified evaluation.

This might be a very subtle difference, but I think it important to tease o= ut.

Hope it helps,
Gregory


At 10:36 PM 7/28/2009, Roni Even wrote:
Markus,
I am happy to hear it, so here is the challenge for you, I assume you are following the email discussion and one of the topic is how to define metric= s
and test the quality of the audio candidate. I will be interested to see yo= u
position about it.
Regards
Roni Even




-----Original Message-----
> From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net]
> Sent: Wednesday, July 29, 2009 3:41 AM
> To: 'Lars Eggert'; 'Roni Even'
> Cc: codec@ietf.org=
> Subject: RE: [codec] Agenda for the Codec Bof
>
>
> Hi Lars, Roni and all,
>
> Roni and Lars wrote:
> >> but no capability to do a real review and quality assessment<= br> >
> > agree with Roni. Having codec specs available that (apparently) f= it
> > the requirements is nice, but it's not clear at all that that= means
> > that the experts who have created these codecs will actively
> > participate in an IETF effort that would be based on something ot= her
> > than their initial candidate submission.
>
> I'm very willing to contribute to the reviewing and quality
> assessments.
>
> I have the lead Call/Audio/Speech Quality Assessment role at Skype and=
> I'm
> working daily with subjective user feedbacks, stats, objective quality=
> measurement tools (such as PESQ/P.862), audio measurements, lab,
> informal &
> formal listening tests, user centric and tech. requirements, even code= c
> &
> other processing algorithm details etc... I also actively follow and > participate (as an invited expert) to the key standardization forums o= f
> these matters - ITU-T SG 12
> (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and= ETSI STQ
> (= http://portal.etsi.org/stq/Summary.asp). So I hope I have something to<= br> > bring to the common work.
>
> I'm also sure there are ways to run a part of formal listening tes= ts at
> Skype facilities if that's seen beneficial later. (or we can arran= ge
> tests
> with some of the 3rd party labs)
>
> Before I moved to Skype a bit more than 3 years ago, I worked for
> around 8
> years in/for Nokia on the similar Speech/Audio Quality Assessment
> matters +
> audio SW algorithms & audio&speech codecs... and the most of t= hat time
> I've
> worked at the same building that Lars appears to be working today ;-)<= br> >
> Best regards with my few Euro cents...
>
> =A0 =A0 =A0 Markus Vaalgamaa
>
>
> -----Original Message-----
> From: code= c-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
> Of
> Lars Eggert
> Sent: Tuesday, July 28, 2009 9:23 AM
> To: Roni Even
> Cc: codec@ietf.org=
> Subject: Re: [codec] Agenda for the Codec Bof
>
> Hi,
>
> On 2009-7-27, at 23:48, Roni Even wrote:
> > Having two codec suggested does not represent expertise to review=
> > codec
> > work. The IETF "rubber stamped" the iLBC codec. There w= as a proposed
> > codec,
> > which you consider expertise, but no capability to do a real revi= ew
> > and
> > quality assessment
>
> agree with Roni. Having codec specs available that (apparently) fit > the requirements is nice, but it's not clear at all that that mean= s
> that the experts who have created these codecs will actively
> participate in an IETF effort that would be based on something other > than their initial candidate submission.
>
> Lars

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

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

--0016e659fa661462ab046fd8839b-- From herve.taddei@huawei.com Wed Jul 29 06:54:40 2009 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 B444D3A6358 for ; Wed, 29 Jul 2009 06:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, 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 37aATOty9hg6 for ; Wed, 29 Jul 2009 06:54:36 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id E50EC3A6EB7 for ; Wed, 29 Jul 2009 06:54:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ00JDPQMX2S@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 29 Jul 2009 14:54:34 +0100 (BST) Received: from PCHERVE ([10.200.70.146]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNJ00LZ0QMW4P@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 29 Jul 2009 14:54:33 +0100 (BST) Date: Wed, 29 Jul 2009 15:54:32 +0200 From: Herve Taddei In-reply-to: <4A704432.8060706@viagenie.ca> To: codec@ietf.org Message-id: <00e701ca1054$1a03bbb0$9446c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ItLB4Rd0bfZ0xLYLF8A3eg)" Thread-index: AcoQSmKFQB079QqlT7i6dKAFh9Eo2AAA9Xmw References: <200972965023.n6TBoNM20074@ulsmlbx01> <4A703DBE.3070006@joelhalpern.com> <4A704080.30404@viagenie.ca> <4A7041F9.9010907@joelhalpern.com> <4A704432.8060706@viagenie.ca> Subject: Re: [codec] Charter comments X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:54:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ItLB4Rd0bfZ0xLYLF8A3eg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, > I think the IETF should take on the immense task of creating > patent-free Internet codecs for all purposes. Usually an SDO tries to focus a bit, especially to avoid overlapping with other SDOs where there could be more expertise. What are all purposes? BTW, who will have the responsibility to ensure that the codec is really RF? In case the codec gets deployed and that this codec is supposed to be RF but it turns out after its deployment that it infringes an essential patent that cannot be suppressed (for interoperability reason), who will pay the company that claims license, the IETF or the codec proponent? I imagine that a company who implements the IETF RF codec must get an insurance that the codec is really RF as they could base their decision to use that codec on that RF reason. If we end up having codecs which were supposed to be RF that would become RAND, the whole activity would not have been useful. It is certainly something to be discussed in the BOF also. >From the charter I understood that RF is not even sure to be provided "this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements". What is then the difference with other SDOs? With regard to the charter, both encoder and decoder reference implementations must be provided (in readable C-code and not in libraries). Is the reference implementation encoder/decoder as listed in the charter a C-code implementation? The current charter is extremely broad. Best regards Herve --Boundary_(ID_ItLB4Rd0bfZ0xLYLF8A3eg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

> I think the IETF should take on the immense task of creating

> patent-free Internet codecs for all purposes.

 

Usually an SDO tries to focus a bit, especially to avoid overlapping with other SDOs where there could be more expertise.

What are all purposes?

 

BTW, who will have the responsibility to ensure that the codec is really RF? In case the codec gets deployed and that this codec is supposed to be RF but it turns out after its deployment that it infringes an essential patent that cannot be suppressed (for interoperability reason), who will pay the company that claims license, the IETF or the codec proponent?

I imagine that a company who implements the IETF RF codec must get an insurance that the codec is really RF as they could base their decision to use that codec on that RF reason. If we end up having codecs which were supposed to be RF that would become RAND, the whole activity would not have been useful.  It is certainly something to be discussed in the BOF also.

 

From the charter I understood that RF is not even sure to be provided “this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements”. What is then the difference with other SDOs?

 

With regard to the charter, both encoder and decoder reference implementations must be provided (in readable C-code and not in libraries). Is the reference implementation encoder/decoder as listed in the charter a C-code implementation?

The current charter is extremely broad.

 

Best regards

 

Herve

--Boundary_(ID_ItLB4Rd0bfZ0xLYLF8A3eg)-- From Borilin@spiritdsp.com Wed Jul 29 08:13:06 2009 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 832363A6F16 for ; Wed, 29 Jul 2009 08:13:06 -0700 (PDT) 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 dI5FKZnl7lbp for ; Wed, 29 Jul 2009 08:13:05 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 0E2CC3A6F15 for ; Wed, 29 Jul 2009 08:13:03 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6TFD1Nu049818; Wed, 29 Jul 2009 19:13:03 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jul 2009 19:12:51 +0400 Message-ID: In-Reply-To: <20090729134818.GA30728@night.luon.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Collabora's position on the Codec WG Thread-Index: AcoQU0Kvt6e2YKltQz+LSy4PZMPOuwAC3LlQ References: <20090729134818.GA30728@night.luon.net> From: "Slava Borilin" To: "Sjoerd Simons" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: robert.mcqueen@collabora.co.uk, christian.schaller@collabora.co.uk Subject: Re: [codec] Collabora's position on the Codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:13:06 -0000 The below is a great format of how people on IETF who are interested in IWAC can provide direct and specific support for forming this group. More such formal emails on the list (even without humming or visiting BOF in person) will make it more clear to the rest of IETF people that WG make sense. Thank you. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Sjoerd Simons Sent: Wednesday, July 29, 2009 3:48 PM To: codec@ietf.org Cc: robert.mcqueen@collabora.co.uk; christian.schaller@collabora.co.uk Subject: [codec] Collabora's position on the Codec WG Collabora Ltd. and Collabora Multimedia support the formation of an IETF open codecs working group. Standardising best-of-breed audio and video codecs for use in Internet protocols, that are compatible for use in open source projects (meaning royalty and patent-free and implementable under a free and open source software license), will be of extensive benefit to the Internet community. Collabora Ltd. is the primary developer of the Telepathy real-time instant messaging framework and the associated Farsight VoIP framework, tools which allow for the development of, among other things, voice and video communication clients. Collabora also develops the Empathy instant messaging client, part of the GNOME Desktop, and now included in many popular GNU/Linux software distributions (including Fedora and Ubuntu), that uses Telepathy to provide voice and video calling. With the exception of the Speex codec, the licenses and obligations of existing Internet telephony codecs prevent them from being provided as part of a free and open software distribution; either as part of a GNU/Linux distribution, or a software package such as Empathy. This significantly raises the barrier for users to communicate. We believe that an IETF Working Group will be able to build upon the existing work done by groups such as Xiph.org to bring standardised, royalty-free codecs to the wider community. The track record of IPR-free codecs such as Speex, Vorbis, Theora, Dirac, FLAC and CELT demonstrate that it is possible to develop good quality, patent-free codecs using an open-source methodology. Although it can never be completely guaranteed that any given codec certainly does not infringe on a patent, regardless of the organisation that builds it, the codecs mentioned above have been available to the public for some time and are still considered IPR-free. Thus we believe that with sufficient prior research, patent issues for codecs can be avoided. By bringing together the relevant stakeholders: codec designers, protocol engineers, device manufacturers, and framework and application developers; we believe that significant progress could be made towards standardising a set of acceptable free and unencumbered protocols to foster much greater interoperability. Robert McQueen (Director Collabora Ltd.) Christian Schaller (Director Collabora Multimedia) Sjoerd Simons (R&D Lead Collabora Ltd.) _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From Anisse.Taleb@huawei.com Wed Jul 29 08:15:58 2009 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 E9E213A6940 for ; Wed, 29 Jul 2009 08:15:58 -0700 (PDT) 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 uh4jY9ZuHxHw for ; Wed, 29 Jul 2009 08:15:57 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id 918953A6D46 for ; Wed, 29 Jul 2009 08:15:57 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ00J4YUEE2S@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 29 Jul 2009 16:15:51 +0100 (BST) Received: from A73076 ([10.202.34.40]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNJ00LQCUEC4P@lhrga04-in.huawei.com> for codec@ietf.org; Wed, 29 Jul 2009 16:15:50 +0100 (BST) Date: Wed, 29 Jul 2009 17:15:48 +0200 From: Anisse Taleb In-reply-to: To: 'Henry Sinnreich' , 'Jason Fischl' , codec@ietf.org Message-id: <006001ca105f$746da240$2822ca0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoQLNfi0xNyUdB/DEig39yrPMSGvAAFytBoAAQ7awA= Cc: 'Jean-Marc Valin' Subject: Re: [codec] Updated Charter Proposal Take 3 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:15:59 -0000 Hi Henry, all, I fail to understand your argument. How is the IETF to stop (free) audio codec proliferation and avoid interoperability problems by creating yet another (free?) audio codec? This concerns me even more when I read the Charter. I have the feeling that it does not have any limitation on how many codecs it intends to standardize and, if more than one codec, how much application-overlap will they have between them (inside "ietf") and with other (3gpp, itu, mpeg) existing codecs. The charter somewhat hints, at several instances, to more than ONE wideband Internet audio codec being adopted... "Algorithm description for one or more wideband Internet audio codecs." "A codec may be approved by the working group without addressing all of the scenarios." [ Btw, still puzzled as to the meaning of the word internet? are other codecs from other SDOs unusable as "internet" codecs? ] As it stands, the current charter would, on the contrary, exacerbate codec proliferation and add even more interoperability problems than stop or prevent them... Kind regards, /Anisse ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: den 29 juli 2009 13:59 To: Jason Fischl; codec@ietf.org Cc: Jean-Marc Valin Subject: Re: [codec] Updated Charter Proposal Take 3 This is a very useful approach in the IETF. Unless the IETF steps up to a standard, nobody can stop the proliferation of free audio (and video) codecs and the ensuing interoperability problems. Henry On 7/29/09 11:13 AM, "Jason Fischl" wrote: Jean-Marc and I have updated the charter based on the comments from Roni and a few private replies. -------------- DRAFT CHARTER: Motivation: There is interest and value in having widely, easily distributable and accessible codec technology from the Internet community. Codec experts from both within and outside the IETF community have expressed an interest in contributing effort in this area. The IETF standards process provides a model for producing standards that encourages transparent design and open collaboration early on in the process. Any IETF codec designs that may emerge will also benefit from input and review from other RAI working groups and other areas of the IETF. Goals: The goal of this working group is to standardize audio codecs that can be implemented, distributed, and used broadly, and be interoperable between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs optimized for very low bit rates or for non-interactive audio are out of scope. The codecs should address the following technical considerations: * suitability for most fixed-point Digital Signal Processors (DSP); * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; Beyond technical considerations, IPR issues will be handled in accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The working group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "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." Note that in accordance with BCP 79, this working group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; the decision will be left to the normal rough consensus of the working group. Deliverables: 1) Codec Standardization Guidelines - that define a set of metrics which can be used to evaluate a codec. These metrics would include complexity, quality vs bitrate, algorithmic delay, packet loss performance and footprint. The complete list will be specified in this document. An evaluation of these metrics should be considered by the working group in trying to come to consensus about proposed changes to one of the draft codecs. A set of pass/fail requirements MAY be specified in the requirements document. It will be up to the working group to evaluate whether or not the proposed codec is better than the reference codec. Continuous testing will be done throughout the process. After a codec is finalized, these guidelines will be used to characterize the codec. This is an Informational track document. 2) Requirements Document - that defines the application requirements of the resulting solution. The requirements will include the exact technical considerations including the target values for metrics defined in the Codec Standardization Guidelines, any pass/fail requirements, an optional reference codec, the scenarios that are being addressed and the assumptions about the Internet operating environment. This is an Informational track document. 3) Algorithm description for one or more wideband Internet audio codecs. There MUST be a text description of the algorithm as well as a reference implementation. The reference implementation MUST include an encoder and a decoder, and MUST be compliant with BCP 78 and BCP 79. The text description MUST indicate those components of the encoder and decoder which are mandatory, recommended and optional. For example, in some codec definitions only the decoder is specified whereas others have bit-exact specifications. Any characterization MUST be performed with the reference encoder. This is a Proposed Standard document. It is not necessary to produce a single codec that solves the entire range of scenarios. A codec may be approved by the working group without addressing all of the scenarios. Milestones: Jan-2010: WGLC on Codec Standardization Guidelines Jan-2010: WGLC on Requirements Jul-2010: WGLC on codec algorithm description(s) to IESG Mar-2010: Codec Standardization Guidelines to IESG (Informational) Mar-2010: Requirements to IESG (Infomational) Jan-2011: Submit codec algorithm description(s) to IESG (Standards Track) _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Wed Jul 29 08:49:59 2009 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 4A1C13A6A14 for ; Wed, 29 Jul 2009 08:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 KkPOkcQowiQc for ; Wed, 29 Jul 2009 08:49:58 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id B61843A6ED2 for ; Wed, 29 Jul 2009 08:49:57 -0700 (PDT) Received: by bwz19 with SMTP id 19so49680bwz.37 for ; Wed, 29 Jul 2009 08:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+IeH+VAFIG02SpuaL1uWTLQZL1PuXFNqKTAEAZRyI+M=; b=r/XGs+oRXWPmxodfYYRG8neiuby4VepBi74r+7nqBtVg5oIxoQ1ssNtgFvGPQEvLem /I9dGF+G1E871mOkq74NXJLdlqgSHPgbEUov68U5OYrR0MlUVo29KUbObyz8I7WXordL AO9WLkaJVx1XVTKyG+OKQI5gPD3JHH4Air0B8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=HzOhUI8FjVOFMAYE59k/4o93J2a0XUDceFxMzIMGxV9RhVdigX5YOsjwh+b0cdX0Vl yyBs0KiEwseLvy7IFd4FMGpp+GW3Yo4dLf3n95q7K00mjCZHhY0QiwrOV0+ubUgG/vdw mLd9gIoQLzIqRk1MiZ6/3LitpJLegnS9LoV44= Received: by 10.103.223.2 with SMTP id a2mr458820mur.49.1248882595471; Wed, 29 Jul 2009 08:49:55 -0700 (PDT) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by mx.google.com with ESMTPS id j6sm6633464mue.31.2009.07.29.08.49.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 08:49:54 -0700 (PDT) From: "Roni Even" To: "'Slava Borilin'" , "'Sjoerd Simons'" , References: <20090729134818.GA30728@night.luon.net> In-Reply-To: Date: Wed, 29 Jul 2009 18:48:09 +0300 Message-ID: <4a706fa2.06a1660a.5647.ffffa2d1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoQU0Kvt6e2YKltQz+LSy4PZMPOuwAC3LlQAAFHdXA= Content-Language: en-us Cc: robert.mcqueen@collabora.co.uk, christian.schaller@collabora.co.uk Subject: Re: [codec] Collabora's position on the Codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:49:59 -0000 Hi, I see that the support is for a WG that will create a codec that is royalty and patent-free and implementable under a free and open source software license, since this is not the charter of the wg I can assume that they do not care for this WG Roni > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Slava Borilin > Sent: Wednesday, July 29, 2009 6:13 PM > To: Sjoerd Simons; codec@ietf.org > Cc: robert.mcqueen@collabora.co.uk; christian.schaller@collabora.co.uk > Subject: Re: [codec] Collabora's position on the Codec WG > > The below is a great format of how people on IETF who are interested in > IWAC can provide direct and specific support for forming this group. > > More such formal emails on the list (even without humming or visiting > BOF in person) will make it more clear to the rest of IETF people that > WG make sense. > > Thank you. > > best regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Sjoerd Simons > Sent: Wednesday, July 29, 2009 3:48 PM > To: codec@ietf.org > Cc: robert.mcqueen@collabora.co.uk; christian.schaller@collabora.co.uk > Subject: [codec] Collabora's position on the Codec WG > > Collabora Ltd. and Collabora Multimedia support the formation of an > IETF > open > codecs working group. Standardising best-of-breed audio and video > codecs > for > use in Internet protocols, that are compatible for use in open source > projects > (meaning royalty and patent-free and implementable under a free and > open > source > software license), will be of extensive benefit to the Internet > community. > > Collabora Ltd. is the primary developer of the Telepathy real-time > instant > messaging framework and the associated Farsight VoIP framework, tools > which > allow for the development of, among other things, voice and video > communication > clients. Collabora also develops the Empathy instant messaging client, > part of > the GNOME Desktop, and now included in many popular GNU/Linux software > distributions (including Fedora and Ubuntu), that uses Telepathy to > provide > voice and video calling. > > With the exception of the Speex codec, the licenses and obligations of > existing > Internet telephony codecs prevent them from being provided as part of a > free > and open software distribution; either as part of a GNU/Linux > distribution, or > a software package such as Empathy. This significantly raises the > barrier for > users to communicate. > > We believe that an IETF Working Group will be able to build upon the > existing > work done by groups such as Xiph.org to bring standardised, royalty- > free > codecs > to the wider community. The track record of IPR-free codecs such as > Speex, > Vorbis, Theora, Dirac, FLAC and CELT demonstrate that it is possible to > develop > good quality, patent-free codecs using an open-source methodology. > > Although it can never be completely guaranteed that any given codec > certainly > does not infringe on a patent, regardless of the organisation that > builds it, > the codecs mentioned above have been available to the public for some > time and > are still considered IPR-free. Thus we believe that with sufficient > prior > research, patent issues for codecs can be avoided. > > By bringing together the relevant stakeholders: codec designers, > protocol > engineers, device manufacturers, and framework and application > developers; we > believe that significant progress could be made towards standardising a > set of > acceptable free and unencumbered protocols to foster much greater > interoperability. > > Robert McQueen (Director Collabora Ltd.) > Christian Schaller (Director Collabora Multimedia) > Sjoerd Simons (R&D Lead Collabora Ltd.) > _______________________________________________ > 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 stephane.proust@orange-ftgroup.com Wed Jul 29 12:00:52 2009 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 6500C3A70DD for ; Wed, 29 Jul 2009 12:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6] 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 ckcjtdK26hEa for ; Wed, 29 Jul 2009 12:00:51 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 8430C3A6F84 for ; Wed, 29 Jul 2009 12:00:30 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 21:00:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jul 2009 21:00:27 +0200 Message-ID: <4D1AA2A55522044480C9B9CF97A9340938A2E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <006001ca105f$746da240$2822ca0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Updated Charter Proposal Take 3 Thread-Index: AcoQLNfi0xNyUdB/DEig39yrPMSGvAAFytBoAAQ7awAABhBjsA== From: To: , , , X-OriginalArrivalTime: 29 Jul 2009 19:00:30.0706 (UTC) FILETIME=[D7DE1520:01CA107E] Cc: jean-marc.valin@usherbrooke.ca Subject: Re: [codec] Updated Charter Proposal Take 3 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:00:52 -0000 Hi all In line with the comments below from Anisse Taleb. Indeed, my understanding of what IETF would intent to do with such a = Charter proposal is as follows :=20 1) Set some requirements that are already met by many existing = standardized or proprietary codecs : the first "technical = considerations" listed in the proposed Charter text seem to be a good = start for this ! 2) Put a "IETF standardized" label on a collection of proprietary codecs = : the ones that will be submitted to this WG : of course not = interoperable between themselves nor with any other already standardized = codecs and without taking into account works from other SDOs nor already = existing standards 3) Run some tests to characterize those codecs and give some information = about their performance once standardized. 4) Let the organizations interested in these codecs deploy them = (hopefully, at least, the proponents chosing their favourite ones) with = possibly several different codecs needed to cover all the application = needs (and again not interoperable between themselves).=20 5) Then cross your fingers and hope that some IPRs will not be declared = and license fees requested by any other organizations than the = proponent(s) of the codecs (possibly not even member of IETF...) which = is more or less captured in the Charter text by the very weak statement = about Royalty Free issue : The working group will TRY to standardize = codecs that can be RELATIVELY FREELY and easily distributed. Indeed, RF = cannot be ensured ! As a result, what is the value added by Standardization with respect to = the previous situation with non standardized codecs ? The situation in terms of interoperability is in fact even worse : you = have just added new standardized codecs to the already too large = existing portfolio (the opposite of the standardization goals)and the = result would just be to weaken the whole voice and audio standardization = area and confuse the market. Stephane=20 -----Message d'origine----- De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part = de Anisse Taleb Envoy=E9 : mercredi 29 juillet 2009 17:16 =C0 : 'Henry Sinnreich'; 'Jason Fischl'; codec@ietf.org Cc : 'Jean-Marc Valin' Objet : Re: [codec] Updated Charter Proposal Take 3 Hi Henry, all, I fail to understand your argument. How is the IETF to stop (free) audio = codec proliferation and avoid interoperability problems by creating yet = another (free?) audio codec?=20 This concerns me even more when I read the Charter. I have the feeling = that it does not have any limitation on how many codecs it intends to = standardize and, if more than one codec, how much application-overlap = will they have between them (inside "ietf") and with other (3gpp, itu, = mpeg) existing codecs.=20 The charter somewhat hints, at several instances, to more than ONE = wideband Internet audio codec being adopted... "Algorithm description for one or more wideband Internet audio codecs."=20 "A codec may be approved by the working group without addressing all of = the scenarios." [ Btw, still puzzled as to the meaning of the word internet? are other = codecs from other SDOs unusable as "internet" codecs? ] As it stands, the current charter would, on the contrary, exacerbate = codec proliferation and add even more interoperability problems than = stop or prevent them...=20 Kind regards, /Anisse ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: den 29 juli 2009 13:59 To: Jason Fischl; codec@ietf.org Cc: Jean-Marc Valin Subject: Re: [codec] Updated Charter Proposal Take 3 This is a very useful approach in the IETF. =20 Unless the IETF steps up to a standard, nobody can stop the = proliferation of free audio (and video) codecs and the ensuing = interoperability problems. Henry On 7/29/09 11:13 AM, "Jason Fischl" wrote: Jean-Marc and I have updated the charter based on the comments from = Roni and a few private replies. =09 -------------- DRAFT CHARTER: =09 Motivation: =09 There is interest and value in having widely, easily distributable and accessible codec technology from the Internet community. Codec experts = from both within and outside the IETF community have expressed an interest = in contributing effort in this area. The IETF standards process provides a model for producing standards that encourages transparent design and = open collaboration early on in the process. Any IETF codec designs that may emerge will also benefit from input and review from other RAI working = groups and other areas of the IETF. =09 Goals: =09 The goal of this working group is to standardize audio codecs that can = be implemented, distributed, and used broadly, and be interoperable = between a wide set of interested parties. The group is chartered to work on audio codecs for interactive communication over the Internet. Codecs = optimized for very low bit rates or for non-interactive audio are out of scope. The codecs should address the following technical considerations: =09 * suitability for most fixed-point Digital Signal Processors (DSP); * medium- to high-quality speech at moderate bit-rate; * high-quality music encoding at higher bit-rates; * sampling rate profiles from narrow-band to full audio bandwidth; * real-time adaptive bit rate; * source-controlled variable bit-rate (VBR); * low algorithmic delay; =09 Beyond technical considerations, IPR issues will be handled in = accordance with BCP 78 and BCP 79. Specifically, many existing codecs with the technical attributes listed above are encumbered with licensing fees = and other IPR claims that make royalty-free and wide distribution and use = across the Internet community difficult. The working group will try to = standardize codecs that can be relatively freely and easily distributed, and = employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "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." Note that in accordance with BCP 79, this = working group will not explicitly rule out the possibility of adopting = technology that does not meet these IPR requirements; the decision will be left to = the normal rough consensus of the working group.=20 =09 Deliverables:=20 =09 1) Codec Standardization Guidelines - that define a set of metrics = which can be used to evaluate a codec. These metrics would include complexity, = quality vs bitrate, algorithmic delay, packet loss performance and footprint. = The complete list will be specified in this document. An evaluation of = these metrics should be considered by the working group in trying to come to consensus about proposed changes to one of the draft codecs. A set of pass/fail requirements MAY be specified in the requirements document. = It will be up to the working group to evaluate whether or not the proposed codec is better than the reference codec. Continuous testing will be = done throughout the process. After a codec is finalized, these guidelines = will be used to characterize the codec. This is an Informational track = document. =09 2) Requirements Document - that defines the application requirements of = the resulting solution. The requirements will include the exact technical considerations including the target values for metrics defined in the = Codec Standardization Guidelines, any pass/fail requirements, an optional reference codec, the scenarios that are being addressed and the = assumptions about the Internet operating environment. This is an Informational = track document. =09 3) Algorithm description for one or more wideband Internet audio = codecs. There MUST be a text description of the algorithm as well as a = reference implementation. The reference implementation MUST include an encoder = and a decoder, and MUST be compliant with BCP 78 and BCP 79. The text = description MUST indicate those components of the encoder and decoder which are mandatory, recommended and optional. For example, in some codec = definitions only the decoder is specified whereas others have bit-exact = specifications. Any characterization MUST be performed with the reference encoder. This is a Proposed Standard document.=20 =09 It is not necessary to produce a single codec that solves the entire = range of scenarios. A codec may be approved by the working group without addressing all of the scenarios. =09 Milestones: =09 Jan-2010: WGLC on Codec Standardization Guidelines=20 Jan-2010: WGLC on Requirements=20 Jul-2010: WGLC on codec algorithm description(s) to IESG Mar-2010: Codec Standardization Guidelines to IESG (Informational) Mar-2010: Requirements to IESG (Infomational) Jan-2011: Submit codec algorithm description(s) to IESG (Standards Track) =09 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =09 =09 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From ron@debian.org Wed Jul 29 12:20:17 2009 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 705C33A6FE4 for ; Wed, 29 Jul 2009 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SARE_LWSHORTT=1.24] 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 xz+-Opk73Uca for ; Wed, 29 Jul 2009 12:20:13 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id 38C5D3A6F11 for ; Wed, 29 Jul 2009 12:20:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFc8cEp5LTZ7/2dsb2JhbACBUtNEhBEF X-IronPort-AV: E=Sophos;i="4.43,290,1246804200"; d="scan'208";a="425071857" Received: from ppp121-45-54-123.lns11.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.54.123]) by ipmail04.adl2.internode.on.net with ESMTP; 30 Jul 2009 04:50:12 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 49A3D4F8F3 for ; Thu, 30 Jul 2009 04:47:59 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HLUFZ6QDY8RA for ; Thu, 30 Jul 2009 04:47:58 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BD8AF4F8FD; Thu, 30 Jul 2009 04:47:58 +0930 (CST) Date: Thu, 30 Jul 2009 04:47:58 +0930 From: Ron To: codec@ietf.org Message-ID: <20090729191758.GB4904@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [codec] Expression of support for an IETF Codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:26:38 -0000 Hi, I've never had much to do with the internal workings of the IETF, though I've long been a beneficiary of its work. Mostly that is probably because you have usually been two steps ahead of what I've needed at any point in time, until now. So I'd like to add my voice to those supporting the formation of this working group, because my daily experience is that this is one area where we are still sorely lacking in standards for interoperability, in the manner of which the internet has so successfully grown as a hub of open communication in so many of its various forms. With the rapid increase in bandwidth that is available to many users now, this is a mode of communication thats time is well upon us. Without genuine open standards, it will however remain as limited as things were in the heyday of uucp. People will remain tied into small groups, that may have effective communication with each other, but are limited in their ability to communicate with those on the 'outside'. If the internet traditionally views such things as damage, then it seems well within the scope of the IETF to standardise effective ways to route around it. High quality, unencumbered, codecs are one of the cornerstones of doing just that. I speak with a number of hats on my hatrack. Personally, as a software developer, the standards refined and published by the IETF give me certainty that my work can be interoperable with that of others. More than that, they give me certainty that this work can be freely shared with others, without the burden, or even potentially the impossibility, of them being able to obtain a licence from a third party to actually use that work. The benefits of collaborative and cooperative development are well known, so I won't rehash them here, except to say that it seems clear that such work has already proven it can create state of the art codecs, and it would seem foolish to me to not recognise and formalise that work as appropriate internet standards that we all can build on with the same certainty as we have enjoyed since the Internet Protocol became the accepted way to push packets around between otherwise dissimilar machines. In a lesser sense I speak as an Operating System vendor. In particular as the maintainer of the Speex and Celt codecs for one of the larger branches of the GNU/Linux distributions. I won't reiterate the eloquent points made by the folks from Collabora and others about the importance of such support to our users, from home users of desktop systems to the manufacturers of appliances, and service providers, for whom we provide a base to build upon and meet their own needs. While there is resistance to standardising the best codecs that we are able to provide to these people, they will remain unnecessarily limited in their ability to facilitate audio communication with other devices and users. Last but not least, I speak with a commercial interest as a stakeholder in Voicetronix, a designer and manufacturer of telephony hardware since 1999. We've had a long and successful history of providing patent and royalty free software to the VARs who develop products upon our hardware. The current state of affairs with respect to (lack of) interoperability of VoIP systems is without doubt the single largest factor currently stifling its broader uptake in the community. While this may provide us with a short term benefit in prolonging sales of our traditional telephony devices, it is clear to us that this is not a situation that it is in the interest of any but a handful of patent holders to prolong for any longer than necessary. While codecs are not the only sticking point for such systems becoming much more ubiquitous than they currently are, they are clearly a required component, and this working group will be addressing a very essential need for the future growth of our company, and the future development of products by our customers, who range from Fortune 500 companies, to small backyard developers creating innovative tools for their own niche markets. I firmly believe, with an open heart and clean hands, that the time is right, and the expertise available, for such a working group to provide some priceless additions to the stable of IETF standards upon which all future communications will be built. Thanks for listening, Ron Lee From rchen@broadcom.com Wed Jul 29 14:12:13 2009 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 9B5CB3A6B96 for ; Wed, 29 Jul 2009 14:12:13 -0700 (PDT) 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 osmOvzEPGABr for ; Wed, 29 Jul 2009 14:12:12 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 4BEF63A6917 for ; Wed, 29 Jul 2009 14:12:12 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 29 Jul 2009 14:12:02 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 29 Jul 2009 14:12:01 -0700 From: "Raymond (Juin-Hwey) Chen" To: "codec@ietf.org" Date: Wed, 29 Jul 2009 14:12:01 -0700 Thread-Topic: Broadcom submits BroadVoice codecs and offers its patent rights and C source codes of BV16/BV32 royalty free Thread-Index: AcoBGqVmgpoTb8KVToaAgsBd8r5MggPc527Q Message-ID: References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> In-Reply-To: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 666E64A83WW13245477-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [codec] Broadcom submits BroadVoice codecs and offers its patent rights and C source codes of BV16/BV32 royalty free X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:12:13 -0000 All, If the IETF codec WG is formed, Broadcom Corporation would like to submit i= ts family of BroadVoice=AE16 (BV16) and BroadVoice32 (BV32) standard codecs= to the IETF codec WG for consideration as a candidate codec or a candidate= building block for the proposed Internet Wideband Audio Codec (IWAC) stand= ard. Currently Broadcom is already offering its patent rights, floating-po= int C source codes, and fixed-point C source codes of BV16/BV32 on a royalt= y-free basis, and Broadcom is even willing to make BV16/BV32 open source. A little background on BV16/BV32. BV16 and BV32 have been standardized by multiple standard organizations for= VoIP applications in cable telephony. BV16 is a 16 kb/s codec for 8 kHz n= arrowband signals; it is a standard codec in the following standards: Packe= tCableT 1.5, PacketCable 2.0, ANSI/SCTE 24-21 2006, and ITU-T Recommendatio= n J.161. Similarly, BV32 is a 32 kb/s codec for 16 kHz wideband signals, = and it is a standard codec in PacketCable 2.0, ANSI/SCTE 24-23 2007, and IT= U-T Recommendation J.361. The RTP payload formats for BV16 and BV32 are sp= ecified in RFC4298. BV16 and BV32 belong to the same family of codecs. Th= ey have very similar codec structures and share most of the algorithm modul= es, so if the two are implemented together, substantial code sharing and me= mory reduction can be achieved. Broadcom developed BV16 and BV32 from the ground up with a goal of avoiding= known third-party intellectual property rights (IPR). Although it was cor= rectly pointed out earlier in the IETF codec WG email discussion that no on= e can be absolutely sure that a given codec is completely free of third-par= ty IPR, we took two steps to help increase our confidence. First, to help = avoid the codec IPR minefield, we purposely avoided the popular and heavily= -patented CELP coding paradigm, and instead took an "ancient art" (circa. 1= 954) technique of noise feedback coding (NFC) that nobody seemed to be inte= rested in (i.e., it was the subject of very few recent publications) and im= proved it to get BV16/BV32. Any patent on the fundamental NFC presumably e= xpired long ago. Second, several extensive patent searches were performed = during the development of BV16/BV32 to help avoid third-party IPR. To the = best of our knowledge, BV16 and BV32 do not infringe on any valid unexpired= third-party patent claim. =20 BV16 and BV32 were also designed from the ground up to be optimized for voi= ce transmission over IP networks, with high speech quality, low latency, lo= w complexity, and high robustness to packet loss as primary design goals. = Thus, BV16 and BV32 are ideally suited for low-latency, high-quality voice = transmission over the Internet. The following summarizes the attributes of= BV16 and BV32: . Low Delay (Latency): algorithmic buffering delay of merely 5 ms (compared= with 15 to 40 ms of competing codecs) . Low Complexity: much lower MIPS requirements than most competing codecs (= typically =BD to 1/3 of comparable ITU-T G.72x codecs), also lower memory r= equirement than most other competing codecs . High Quality: equivalent or better speech quality than competing codecs i= n extensive formal subjective MOS listening tests conducted by AT&T Labs, C= OMSAT Labs, and Dynastat, Inc. . Availability: Broadcom is offering its patent rights, floating-point and = fixed-point C source codes of BV16/BV32 on a royalty-free basis; BV16/BV32 = to become open source soon. For comprehensive comparisons between BV16/BV32 and other codecs, please se= e the codec comparison tables in Annexes C and D (pages 73 - 81) of the Pac= ketCable 2.0 Codec and Media Specification, available at: http://www.packetcable.com/downloads/specs/PKT-SP-CODEC-MEDIA-I02-061013.pd= f Broadcom believes that as compared to the other nearly two dozen dominant c= odecs listed there, BV16 and BV32 offer the most compelling combinations of= low delay, low complexity, high quality, moderate bit-rate, and royalty-fr= ee patent rights and C source codes. The algorithm descriptions of BV16 an= d BV32 can be found in the two ANSI/SCTE standard documents below: http://www.scte.org/documents/pdf/Standards/ANSISCTE24212006.pdf http://www.scte.org/documents/pdf/Standards/ANSI_SCTE24-232007.pdf It seems clear from the previous email discussion in the IETF codec WG refl= ector that voice transmission over the Internet is the primary application = of the proposed IWAC, although transmitting general audio (music, etc.) at = high fidelity is also desirable/necessary. It is also clear from the emails= that royalty-free, low latency, and high quality are all highly desirable.= Given what was described above about BV16/BV32, it would seem that BV16/B= V32 is an ideal candidate and is sufficient to cover the narrowband (8 kHz)= and wideband (16 kHz) voice transmission aspects of the applications of IW= AC. To get higher sampling rates and higher audio bandwidths, it is possib= le to use BV16 and BV32 as the base layers and add additional bits on top o= f the BV16/BV32 bit-streams to encode an appropriately formulated differenc= e signal to get a scalable, embedded codec that goes from 8 kHz sampling at= 16 kb/s all the way to 48 kHz sampling at a much higher bit-rate. One adv= antage of doing so is that the resulting IWAC will be interoperable with th= e BV16/BV32 in the PacketCable, ANSI/SCTE, and ITU-T J.161/J.361 standards.= This is similar to the relationship between ITU-T G.729.1 and G.729. Juin-Hwey (Raymond) Chen Broadcom Corporation From gregory.ietf@gmail.com Wed Jul 29 16:37:25 2009 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 762783A68D5 for ; Wed, 29 Jul 2009 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=1.396] 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 pF315HKZ4kZB for ; Wed, 29 Jul 2009 16:37:23 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 9B34A3A6989 for ; Wed, 29 Jul 2009 16:37:23 -0700 (PDT) Received: by pxi42 with SMTP id 42so88218pxi.29 for ; Wed, 29 Jul 2009 16:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=wPaS5huWECZYTh8RF1pJaqKY/NEwBYYgeDjZSLrM4zg=; b=d13gCtMkUx3htSdYFyEb5J2sDe1ZTZwyf778jy29TAInOePqDmmMg5P7HZz3TkQmqi 988Vcpxzbc5bnGrnBbpO2sGx6rwvRHRHkv3hOUUKjgTvgSi6Y7bswIjw1HwhG/R7yeHI LPK/KCaZwIbpMswIj5WAYwcWj1H63XBcls2i8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=pQHg2QGmf7DykQW9735XWov5H0jshFjkOE2SKkVJOCCACxZat4F19UHrrd420Z2Ews 6lNV+ZjeGt7tXn0F6XkhkpSOCskk37M8xqvmSBXD+ooYN3cNv0HbHiD3JbdDzxcED3PN RfkrtqljGFNWA/zQW88tZ9HOk6x3joHbQ6ih0= Received: by 10.114.103.15 with SMTP id a15mr560375wac.184.1248910642875; Wed, 29 Jul 2009 16:37:22 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id l30sm2189746waf.0.2009.07.29.16.37.17 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 16:37:21 -0700 (PDT) Message-ID: <4a70dd31.1ebc720a.5366.ffffac8d@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 16:37:13 -0700 To: stephen botzko From: "Gregory M. Lebovitz" In-Reply-To: <6e9223710907290653p3c1561cckb9c792d190d418cd@mail.gmail.co m> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> <6e9223710907290653p3c1561cckb9c792d190d418cd@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11427593==.ALT" Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:37:25 -0000 --=====================_11427593==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:53 AM 7/29/2009, stephen botzko wrote: >I suggest the dictionary definition of "evaluate" is sufficient for >the charter. > >Evaluate: >1 : to determine or fix the value of >2 : to determine the significance, worth, or condition of; usually >by careful appraisal and study > >I'd say there is a distinction between what you are calling >evaluation and what in other SDOs is called characterization. > >Characterization (in my view) is not a tracking document and is not >a weighted scoring system. It is a deliverable that describes the >codec behavior that has lasting value. One example from 3GPP is found here: > >http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip > >I would prefer to see a characterization deliverable either as a >section of the codec RFC, or as a separate informational RFC. I'm not quite sure I yet see the exact difference between what I (a non-codec guy just trying to assist in oversight of process issues here) called "evaluate" and you called "characterized". They seemed pretty similar. Maybe you can explain it to me tomorrow? However, I feel we are narrowing in on what it ought to be, and that is a very good thing. Thanks for your observation, Gregory. >Regards >Stephen Botzko >Polycom > >On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz ><gregory.ietf@gmail.com> wrote: >Roni, >Just to clarify how I read the latest charter... > >It's not that a WG would "test" the quality of the audio of a >candidate mechanism or codec. It's not a pass vs fail thing. There >doesn't need to be a winner and a loser. In fact, the word "test" >does not appear in the charter. The charter does say: > >"define a set of metrics which can be used to evaluate a codec. " > >The word "evaluate" is very different. I read it to mean "how will a >group of people normalize their collective subjective opinion on an >observed condition". By example, consider the way cars are reviewed >in magazines. Judges who have been trained on a set of metrics about >performance under different conditions (say top end speed, or >cornering, or acceleration, or storage space) have a shared set of >definitions of performance they might observe, both good and >impressive performance as well as poor/faulty performance. They also >have a standard measurement scale -- in this example scoring by >points -- by which they record their observations of performance. >The measurement scale includes different values for different >performance elements, i.e. certain observations cost 1/2 point >deduction, others cost 1/4 point, and some gain points because they >are more difficult or beneficial. When comparing two sports cars one >might be better at sharp turns at high speeds and acceleration, >while another might be better at sustained high speeds on straight >aways. But both are terrible at fitting your family of 6 and all >your luggage for a 10 hr road trip over dirt and rock terrain, >towing a ski boat. > >Likewise, this WG will need to come up with a shared set of >"performance" metrics that they might observe from a codec or its >sub-mechanisms. And it will need to agree on a system for valuing >these metrics. Like the vehicle example, the WG may not determine >one winner, and determine all others losers. But might simply >evaluate two and agree that X codec/mechanism is better at Alpha and >Beta, where as Y codec/mechanism just as good at Beta, but not as >good in Alpha, but much better in Delta, and thus is better applied >to environment 3, but not as good as X in environment 2. > >My point is that the word "evaluate" is intended to have a far >different meaning than purely "test". We may do many tests in order >to form a unified evaluation. > >This might be a very subtle difference, but I think it important to tease out. > >Hope it helps, >Gregory > > >At 10:36 PM 7/28/2009, Roni Even wrote: >Markus, >I am happy to hear it, so here is the challenge for you, I assume you are >following the email discussion and one of the topic is how to define metrics >and test the quality of the audio candidate. I will be interested to see you >position about it. >Regards >Roni Even > > > > >-----Original Message----- > > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > > Sent: Wednesday, July 29, 2009 3:41 AM > > To: 'Lars Eggert'; 'Roni Even' > > Cc: codec@ietf.org > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > Hi Lars, Roni and all, > > > > Roni and Lars wrote: > > >> but no capability to do a real review and quality assessment > > > > > agree with Roni. Having codec specs available that (apparently) fit > > > the requirements is nice, but it's not clear at all that that means > > > that the experts who have created these codecs will actively > > > participate in an IETF effort that would be based on something other > > > than their initial candidate submission. > > > > I'm very willing to contribute to the reviewing and quality > > assessments. > > > > I have the lead Call/Audio/Speech Quality Assessment role at Skype and > > I'm > > working daily with subjective user feedbacks, stats, objective quality > > measurement tools (such as PESQ/P.862), audio measurements, lab, > > informal & > > formal listening tests, user centric and tech. requirements, even codec > > & > > other processing algorithm details etc... I also actively follow and > > participate (as an invited expert) to the key standardization forums of > > these matters - ITU-T SG 12 > > > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) > and ETSI STQ > > > (http://portal.etsi.org/stq/Summary.asp). > So I hope I have something to > > bring to the common work. > > > > I'm also sure there are ways to run a part of formal listening tests at > > Skype facilities if that's seen beneficial later. (or we can arrange > > tests > > with some of the 3rd party labs) > > > > Before I moved to Skype a bit more than 3 years ago, I worked for > > around 8 > > years in/for Nokia on the similar Speech/Audio Quality Assessment > > matters + > > audio SW algorithms & audio&speech codecs... and the most of that time > > I've > > worked at the same building that Lars appears to be working today ;-) > > > > Best regards with my few Euro cents... > > > > Markus Vaalgamaa > > > > > > -----Original Message----- > > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On Behalf > > Of > > Lars Eggert > > Sent: Tuesday, July 28, 2009 9:23 AM > > To: Roni Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > > Hi, > > > > On 2009-7-27, at 23:48, Roni Even wrote: > > > Having two codec suggested does not represent expertise to review > > > codec > > > work. The IETF "rubber stamped" the iLBC codec. There was a proposed > > > codec, > > > which you consider expertise, but no capability to do a real review > > > and > > > quality assessment > > > > agree with Roni. Having codec specs available that (apparently) fit > > the requirements is nice, but it's not clear at all that that means > > that the experts who have created these codecs will actively > > participate in an IETF effort that would be based on something other > > than their initial candidate submission. > > > > Lars > >_______________________________________________ >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 > --=====================_11427593==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 06:53 AM 7/29/2009, stephen botzko wrote:
I suggest the dictionary definition of "evaluate" is sufficient for the charter.

Evaluate:
1 : to determine or fix the value of
2 : to determine the significance, worth, or condition of; usually by careful appraisal and study

I'd say there is a distinction between what you are calling evaluation and what in other SDOs is called characterization. 

Characterization (in my view) is not a tracking document and is not a weighted scoring system. It is a deliverable that describes the codec behavior that has lasting value. One example from 3GPP is found here:

http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip

I would prefer to see a characterization deliverable either as a section of the codec RFC, or as a separate informational RFC.

I'm not quite sure I yet see the exact difference between what I (a non-codec guy just trying to assist in oversight of process issues here) called "evaluate" and you called "characterized". They seemed pretty similar. Maybe you can explain it to me tomorrow?

However, I feel we are narrowing in on what it ought to be, and that is a very good thing. Thanks for your observation,
Gregory.


Regards
Stephen Botzko
Polycom

On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz <gregory.ietf@gmail.com > wrote:
Roni,
Just to clarify how I read the latest charter...

It's not that a WG would "test" the quality of the audio of a candidate mechanism or codec. It's not a pass vs fail thing. There doesn't need to be a winner and a loser. In fact, the word "test" does not appear in the charter. The charter does say:

"define a set of metrics which can be used to evaluate a codec. "

The word "evaluate" is very different. I read it to mean "how will a group of people normalize their collective subjective opinion on an observed condition". By example, consider the way cars are reviewed in magazines. Judges who have been trained on a set of metrics about performance under different conditions (say top end  speed, or cornering, or acceleration, or storage space) have a shared set of definitions of performance they might observe, both good and impressive performance as well as poor/faulty performance. They also have a standard measurement scale -- in this example scoring by points -- by which they record their observations of performance. The measurement scale includes different values for different performance elements, i.e. certain observations cost 1/2 point deduction, others cost 1/4 point, and some gain points because they are more difficult or beneficial. When comparing two sports cars one might be better at sharp turns at high speeds and acceleration, while another might be better at sustained high speeds on straight aways. But both are terrible at fitting your family of 6 and all your luggage for a 10 hr road trip over dirt and rock terrain, towing a ski boat.

Likewise, this WG will need to come up with a shared set of "performance" metrics that they might observe from a codec or its sub-mechanisms. And it will need to agree on a system for valuing these metrics. Like the vehicle example, the WG may not determine one winner, and determine all others losers. But might simply evaluate two and agree that X codec/mechanism is better at Alpha and Beta, where as Y codec/mechanism just as good at Beta, but not as good in Alpha, but much better in Delta, and thus is better applied to environment 3, but not as good as X in environment 2.

My point is that the word "evaluate" is intended to have a far different meaning than purely "test". We may do many tests in order to form a unified evaluation.

This might be a very subtle difference, but I think it important to tease out.

Hope it helps,
Gregory


At 10:36 PM 7/28/2009, Roni Even wrote:
Markus,
I am happy to hear it, so here is the challenge for you, I assume you are
following the email discussion and one of the topic is how to define metrics
and test the quality of the audio candidate. I will be interested to see you
position about it.
Regards
Roni Even




-----Original Message-----
> From: Markus Vaalgamaa [ mailto:markus.vaalgamaa@skype.net]
> Sent: Wednesday, July 29, 2009 3:41 AM
> To: 'Lars Eggert'; 'Roni Even'
> Cc: codec@ietf.org
> Subject: RE: [codec] Agenda for the Codec Bof
>
>
> Hi Lars, Roni and all,
>
> Roni and Lars wrote:
> >> but no capability to do a real review and quality assessment
>
> > agree with Roni. Having codec specs available that (apparently) fit
> > the requirements is nice, but it's not clear at all that that means
> > that the experts who have created these codecs will actively
> > participate in an IETF effort that would be based on something other
> > than their initial candidate submission.
>
> I'm very willing to contribute to the reviewing and quality
> assessments.
>
> I have the lead Call/Audio/Speech Quality Assessment role at Skype and
> I'm
> working daily with subjective user feedbacks, stats, objective quality
> measurement tools (such as PESQ/P.862), audio measurements, lab,
> informal &
> formal listening tests, user centric and tech. requirements, even codec
> &
> other processing algorithm details etc... I also actively follow and
> participate (as an invited expert) to the key standardization forums of
> these matters - ITU-T SG 12
> ( http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ
> ( http://portal.etsi.org/stq/Summary.asp). So I hope I have something to
> bring to the common work.
>
> I'm also sure there are ways to run a part of formal listening tests at
> Skype facilities if that's seen beneficial later. (or we can arrange
> tests
> with some of the 3rd party labs)
>
> Before I moved to Skype a bit more than 3 years ago, I worked for
> around 8
> years in/for Nokia on the similar Speech/Audio Quality Assessment
> matters +
> audio SW algorithms & audio&speech codecs... and the most of that time
> I've
> worked at the same building that Lars appears to be working today ;-)
>
> Best regards with my few Euro cents...
>
>       Markus Vaalgamaa
>
>
> -----Original Message-----
> From: codec-bounces@ietf.org [ mailto:codec-bounces@ietf.org] On Behalf
> Of
> Lars Eggert
> Sent: Tuesday, July 28, 2009 9:23 AM
> To: Roni Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Agenda for the Codec Bof
>
> Hi,
>
> On 2009-7-27, at 23:48, Roni Even wrote:
> > Having two codec suggested does not represent expertise to review
> > codec
> > work. The IETF "rubber stamped" the iLBC codec. There was a proposed
> > codec,
> > which you consider expertise, but no capability to do a real review
> > and
> > quality assessment
>
> agree with Roni. Having codec specs available that (apparently) fit
> the requirements is nice, but it's not clear at all that that means
> that the experts who have created these codecs will actively
> participate in an IETF effort that would be based on something other
> than their initial candidate submission.
>
> Lars

_______________________________________________
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

--=====================_11427593==.ALT-- From alan@sipstation.com Wed Jul 29 16:41:36 2009 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 C997B3A68D5 for ; Wed, 29 Jul 2009 16:41:36 -0700 (PDT) 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 LRWYhyxyxh0a for ; Wed, 29 Jul 2009 16:41:35 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 911DF3A68C4 for ; Wed, 29 Jul 2009 16:41:35 -0700 (PDT) Received: from [212.112.167.85] (helo=Alans-PowerBook-G4-17.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MWIm8-0001CE-Q9 for codec@ietf.org; Wed, 29 Jul 2009 23:41:36 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 212.112.167.85 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9lnP1J0KUDEcqEqX75lVl3n4/XWQjDig= Message-ID: <4A70DE2D.4000205@sipstation.com> Date: Wed, 29 Jul 2009 18:41:33 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [codec] Comments X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:41:36 -0000 I'm not going to comment on the details of the charter but instead just talk about the high level issues. The situation today is awful - there are a number of good new Internet codecs, but few have deployed them - no one wants to be the first, and in the meantime, we are stuck with G.711 et al. We need to try something to break us out of this situation, and this effort seems like it could really help. I can't see how it could harm the situation. Secondly, it seems like all previous codecs have been designed in isolation, or with the needs of some specific layer 2 transport in mind. What if we really thought hard and came up with the requirements for our ultimate Internet codec? What kinds of things could we think of? If we don't do the work, we will never know, and we may yet come up with a codec that has a compelling deployment story. And then we'd really be getting somewhere... Thanks, Alan From gregory.ietf@gmail.com Wed Jul 29 16:54:53 2009 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 B87AA3A68E0 for ; Wed, 29 Jul 2009 16:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 2siGFmjcvDIn for ; Wed, 29 Jul 2009 16:54:52 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 7C58F3A688B for ; Wed, 29 Jul 2009 16:54:52 -0700 (PDT) Received: by pxi42 with SMTP id 42so93462pxi.29 for ; Wed, 29 Jul 2009 16:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=TlggWyjQ7ZB+mYIibr24xVIuWjL2dysQ5UKVwR5Y79w=; b=OnksU/4L/m5Nwt3cZNYSIk7TkTekXZfJUGvCOI66EM9aqKV4ZCug2N+hMYs913aoYw AOBjfYpdsSyJ1f5yIZAdN6k2bp0fG9NJULNg2YhXW24veYRxi8bxfH5Ea7jGS3TmIB06 c63ztk1EUinZZhfSZvxxzgn4lUTuKM+9T+6+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=wEKzw8sMpE9zxuOekOzj8riHJOtW9muABLRGRBAWWtGpcF6W/IpoTc+wVrlLhH/hDn AMuEZJzU9UQVj0Gzp9mBNfLgKyEAROErLwdrKyMkgRMaxDUp1VtPqNGJuBy4aH+bNM3m 6A7Wgsjkhn94Rq6R+ynjuGcVZYVMjAZIwsl5Q= Received: by 10.115.54.3 with SMTP id g3mr610040wak.2.1248911692588; Wed, 29 Jul 2009 16:54:52 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id j26sm2220551waf.28.2009.07.29.16.54.48 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 16:54:51 -0700 (PDT) Message-ID: <4a70e14b.1aba720a.0d4f.ffffaf60@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 16:54:44 -0700 To: "Roni Even" From: "Gregory M. Lebovitz" In-Reply-To: <4a703b12.170e660a.5ab0.ffffc643@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> <4a703b12.170e660a.5ab0.ffffc643@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:54:53 -0000 At 05:03 AM 7/29/2009, Roni Even wrote: >Gregory, >I think that the charter should be clear and should not depend so much on >personal views. >In general I have no problem with your analysis and example. >The thing is that by the end we need to approve each codec and if it is >going through multiple tests will it need to pass all of them, will there be >one that are mandatory to pass and other are optional, this will compose >what you call as the final score. I believe that in order to approve a codec >the wg should see the test results before they accept it in a WGLC. If the >tests results provided to the working group are just for information and are >not relevant for last call a codec than we do not need requirements or tests >and just need to read the codec description and do last call. Roni, We may have an English language translation issue here, or more likely I was poorly communicating, because what you just typed above, and what I so painstakingly tried to describe below are pretty far apart. So let me try again: There is no "test" needed and final score needed. There is need of an agreed upon process for evaluation of several different attributes of a codec, and a value assigned for each attribute. When the values for the various attributes are lined up, we'll be able to see if a codec is good in a certain type of environment, and how it compares to others. Someone else on the list called this "Characterization" and I think his definition of that word sounded very similar to what I was trying to get across. Hope that helps clarify. And thanks for your persistence on the list. It appears you have a strong interest in this work, and will be an active voice on the list. That's very important for us to measure: how consistently people will be working on list. You've got a thumbs up for sure. Thanks again!! Gregory. >Roni Even > > > > -----Original Message----- > > From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] > > Sent: Wednesday, July 29, 2009 11:51 AM > > To: Roni Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Agenda for the Codec Bof > > > > Roni, > > Just to clarify how I read the latest charter... > > > > It's not that a WG would "test" the quality of the audio of a > > candidate mechanism or codec. It's not a pass vs fail thing. There > > doesn't need to be a winner and a loser. In fact, the word "test" > > does not appear in the charter. The charter does say: > > > > "define a set of metrics which can be used to evaluate a codec. " > > > > The word "evaluate" is very different. I read it to mean "how will a > > group of people normalize their collective subjective opinion on an > > observed condition". By example, consider the way cars are reviewed > > in magazines. Judges who have been trained on a set of metrics about > > performance under different conditions (say top end speed, or > > cornering, or acceleration, or storage space) have a shared set of > > definitions of performance they might observe, both good and > > impressive performance as well as poor/faulty performance. They also > > have a standard measurement scale -- in this example scoring by > > points -- by which they record their observations of performance. The > > measurement scale includes different values for different performance > > elements, i.e. certain observations cost 1/2 point deduction, others > > cost 1/4 point, and some gain points because they are more difficult > > or beneficial. When comparing two sports cars one might be better at > > sharp turns at high speeds and acceleration, while another might be > > better at sustained high speeds on straight aways. But both are > > terrible at fitting your family of 6 and all your luggage for a 10 hr > > road trip over dirt and rock terrain, towing a ski boat. > > > > Likewise, this WG will need to come up with a shared set of > > "performance" metrics that they might observe from a codec or its > > sub-mechanisms. And it will need to agree on a system for valuing > > these metrics. Like the vehicle example, the WG may not determine one > > winner, and determine all others losers. But might simply evaluate > > two and agree that X codec/mechanism is better at Alpha and Beta, > > where as Y codec/mechanism just as good at Beta, but not as good in > > Alpha, but much better in Delta, and thus is better applied to > > environment 3, but not as good as X in environment 2. > > > > My point is that the word "evaluate" is intended to have a far > > different meaning than purely "test". We may do many tests in order > > to form a unified evaluation. > > > > This might be a very subtle difference, but I think it important to > > tease out. > > > > Hope it helps, > > Gregory > > > > At 10:36 PM 7/28/2009, Roni Even wrote: > > >Markus, > > >I am happy to hear it, so here is the challenge for you, I assume you > > are > > >following the email discussion and one of the topic is how to define > > metrics > > >and test the quality of the audio candidate. I will be interested to > > see you > > >position about it. > > >Regards > > >Roni Even > > > > > > > > > > > > > > >-----Original Message----- > > > > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > > > > Sent: Wednesday, July 29, 2009 3:41 AM > > > > To: 'Lars Eggert'; 'Roni Even' > > > > Cc: codec@ietf.org > > > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > > > > > > > Hi Lars, Roni and all, > > > > > > > > Roni and Lars wrote: > > > > >> but no capability to do a real review and quality assessment > > > > > > > > > agree with Roni. Having codec specs available that (apparently) > > fit > > > > > the requirements is nice, but it's not clear at all that that > > means > > > > > that the experts who have created these codecs will actively > > > > > participate in an IETF effort that would be based on something > > other > > > > > than their initial candidate submission. > > > > > > > > I'm very willing to contribute to the reviewing and quality > > > > assessments. > > > > > > > > I have the lead Call/Audio/Speech Quality Assessment role at Skype > > and > > > > I'm > > > > working daily with subjective user feedbacks, stats, objective > > quality > > > > measurement tools (such as PESQ/P.862), audio measurements, lab, > > > > informal & > > > > formal listening tests, user centric and tech. requirements, even > > codec > > > > & > > > > other processing algorithm details etc... I also actively follow > > and > > > > participate (as an invited expert) to the key standardization > > forums of > > > > these matters - ITU-T SG 12 > > > > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ > > > > (http://portal.etsi.org/stq/Summary.asp). So I hope I have > > something to > > > > bring to the common work. > > > > > > > > I'm also sure there are ways to run a part of formal listening > > tests at > > > > Skype facilities if that's seen beneficial later. (or we can > > arrange > > > > tests > > > > with some of the 3rd party labs) > > > > > > > > Before I moved to Skype a bit more than 3 years ago, I worked for > > > > around 8 > > > > years in/for Nokia on the similar Speech/Audio Quality Assessment > > > > matters + > > > > audio SW algorithms & audio&speech codecs... and the most of that > > time > > > > I've > > > > worked at the same building that Lars appears to be working today > > ;-) > > > > > > > > Best regards with my few Euro cents... > > > > > > > > Markus Vaalgamaa > > > > > > > > > > > > -----Original Message----- > > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > > Of > > > > Lars Eggert > > > > Sent: Tuesday, July 28, 2009 9:23 AM > > > > To: Roni Even > > > > Cc: codec@ietf.org > > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > > > Hi, > > > > > > > > On 2009-7-27, at 23:48, Roni Even wrote: > > > > > Having two codec suggested does not represent expertise to review > > > > > codec > > > > > work. The IETF "rubber stamped" the iLBC codec. There was a > > proposed > > > > > codec, > > > > > which you consider expertise, but no capability to do a real > > review > > > > > and > > > > > quality assessment > > > > > > > > agree with Roni. Having codec specs available that (apparently) fit > > > > the requirements is nice, but it's not clear at all that that means > > > > that the experts who have created these codecs will actively > > > > participate in an IETF effort that would be based on something > > other > > > > than their initial candidate submission. > > > > > > > > Lars > > > > > >_______________________________________________ > > >codec mailing list > > >codec@ietf.org > > >https://www.ietf.org/mailman/listinfo/codec From stefan.sayer@iptego.com Wed Jul 29 17:21:40 2009 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 899BD3A6938 for ; Wed, 29 Jul 2009 17:21:40 -0700 (PDT) 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 4muvuG2-yQwv for ; Wed, 29 Jul 2009 17:21:39 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 793923A6866 for ; Wed, 29 Jul 2009 17:21:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 8E8DF115407D; Thu, 30 Jul 2009 02:21:39 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wJUKAEv-d2V; Thu, 30 Jul 2009 02:21:39 +0200 (CEST) Received: from [192.168.10.100] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id 35FD61154038; Thu, 30 Jul 2009 02:21:39 +0200 (CEST) Message-ID: <4A70E795.5010809@iptego.com> Date: Thu, 30 Jul 2009 02:21:41 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jean-Marc Valin , codec@ietf.org Subject: Re: [codec] Updated Charter Proposal Take 2 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 00:21:40 -0000 Hello, o Stephan Wenger [07/29/09 02:40]: > First, it is my understanding that the language in the charter related to > IPR is in full compliance with the relevant BCPs, and, therefore, I cannot > have a hard objection based on process or policy violation. > > Still, explicitly citing only one of many preferences and rules of BCP 79 is > clearly setting the tone in one direction, and may discourage contributions > by those whose business model is not overly aligned with this very section > of BCP 79 (but fully aligned with others). It would be easy to selectively > quote other parts of BCP 79 supporting a completely different business > model. For example, I could quote (in isolation) section 3.1: "General > Policy / In all matters of Intellectual Property Rights, the intent is to > benefit the Internet community and the public at large, while respecting > the legitimate rights of others." Or, to be more specific, wouldn't the > inclusion of the second sentence of section 8 (from which you have taken > only the first sentence) also create a more balanced picture? It reads: " > But IETF working groups have the discretion to adopt technology with a > commitment of fair and non-discriminatory terms, or even with no licensing > commitment, if they feel that this technology is superior enough to > alternatives with fewer IPR claims or free licensing to outweigh the > potential cost of the licenses." > > I continue to prefer not to mention the IPR topic at all (which is the norm > in IETF charters), or state the required compliance with BCP 78 and 79 > without further commentary, interpretation, or citation. Please consider > this input. My objection here, for a very simple reason: There are other SDOs who do not try to standardize RF codecs, and while they have standardized very good codecs, they have until now failed to standardize a wideband codec which is widely used in the Internet, and for VoIP in general. The G722 example (it is now royalty free, but in spite of its low quality one of the widest deployed, if not the widest deployed wideband codec for VoIP) shows that RF is one of the key requirements for widespread adoption in this situation. Thus, if possible, it makes sense to try to standardize a RF codec, and it is good to quote exactly that section from BCP79 in the charter. Best Regards Stefan Sayer From ron.even.tlv@gmail.com Wed Jul 29 21:47:01 2009 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 4571C3A67DA for ; Wed, 29 Jul 2009 21:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] 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 FgmIkapRclBa for ; Wed, 29 Jul 2009 21:46:59 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 0DB3B3A67EC for ; Wed, 29 Jul 2009 21:46:58 -0700 (PDT) Received: by ewy10 with SMTP id 10so476864ewy.37 for ; Wed, 29 Jul 2009 21:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=ldszhzbFuN7t4vfqp/DRSnmpnLntAXuJjEfoXJFDVno=; b=DAfCZxw+Fz5EoRP6rkX9Y8r8IRMgTejd5MNo6m7KLxEw9ziT7d0Diq5AGKkTQ2sZ+o yEU2WRy8pccDozQa1df7i3kxP9ZhtwhCKPnxLyrMYDs5R3l/PHiGUFjOO+oFVu0pztBT YrvVPemvM3huz3o8lntRCcCVM1jL1sZgLyUwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=GSL71SmFhUtz43hlRNHE1bhCCdCDaH8StX4qK+Ux16xE01YzAjeQUin2HMlkMd3m4y 6J8bAr30lQaSETWbAs2PPJxtQ9shipmA3e7PROduiWB4hgoN8ZvSk37K4FOUhMOsPsG9 MEMgyQ5OcYMh+pIsOpY8pi6nopkgz6RQVGsZY= Received: by 10.210.128.17 with SMTP id a17mr1084466ebd.19.1248929216689; Wed, 29 Jul 2009 21:46:56 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id 5sm43686eyf.28.2009.07.29.21.46.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 21:46:55 -0700 (PDT) From: "Roni Even" To: "'Gregory M. Lebovitz'" References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <4A6D6AD0.30504@usherbrooke.ca> <001801ca0ea2$cc71a090$9446c80a@china.huawei.com> <130EBB38279E9847BAAAE0B8F9905F8C018EC2FC@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> <4a703b12.170e660a.5ab0.ffffc643@mx.google.com> <4a70e14b.1aba720a.0d4f.ffffaf60@mx.google.com> In-Reply-To: <4a70e14b.1aba720a.0d4f.ffffaf60@mx.google.com> Date: Thu, 30 Jul 2009 07:45:09 +0300 Message-ID: <4a7125bf.0506d00a.75ab.0d67@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQp/ibDDP9fRvjT1uTWISB6lmsCgAKAvvQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 04:47:01 -0000 Hi, This is not an issue of English language translation but of audio codec standardization terminology. The charter has in the deliverable the following text "After a codec is finalized, these guidelines will be used to characterize the codec" One who is familiar with audio codecs specification terminology will understand the word characterization as for example you can see in http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip I suggest you look at it and see that it is based on test results Roni Even > -----Original Message----- > From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] > Sent: Thursday, July 30, 2009 2:55 AM > To: Roni Even > Cc: codec@ietf.org > Subject: RE: [codec] Agenda for the Codec Bof > > At 05:03 AM 7/29/2009, Roni Even wrote: > >Gregory, > >I think that the charter should be clear and should not depend so much > on > >personal views. > >In general I have no problem with your analysis and example. > >The thing is that by the end we need to approve each codec and if it > is > >going through multiple tests will it need to pass all of them, will > there be > >one that are mandatory to pass and other are optional, this will > compose > >what you call as the final score. I believe that in order to approve a > codec > >the wg should see the test results before they accept it in a WGLC. If > the > >tests results provided to the working group are just for information > and are > >not relevant for last call a codec than we do not need requirements or > tests > >and just need to read the codec description and do last call. > > Roni, > We may have an English language translation issue here, or more > likely I was poorly communicating, because what you just typed above, > and what I so painstakingly tried to describe below are pretty far > apart. > > So let me try again: > There is no "test" needed and final score needed. There is need of an > agreed upon process for evaluation of several different attributes of > a codec, and a value assigned for each attribute. When the values for > the various attributes are lined up, we'll be able to see if a codec > is good in a certain type of environment, and how it compares to > others. > > Someone else on the list called this "Characterization" and I think > his definition of that word sounded very similar to what I was trying > to get across. > > Hope that helps clarify. > > And thanks for your persistence on the list. It appears you have a > strong interest in this work, and will be an active voice on the > list. That's very important for us to measure: how consistently > people will be working on list. You've got a thumbs up for sure. > Thanks again!! > > Gregory. > > > >Roni Even > > > > > > > -----Original Message----- > > > From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] > > > Sent: Wednesday, July 29, 2009 11:51 AM > > > To: Roni Even > > > Cc: codec@ietf.org > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > Roni, > > > Just to clarify how I read the latest charter... > > > > > > It's not that a WG would "test" the quality of the audio of a > > > candidate mechanism or codec. It's not a pass vs fail thing. There > > > doesn't need to be a winner and a loser. In fact, the word "test" > > > does not appear in the charter. The charter does say: > > > > > > "define a set of metrics which can be used to evaluate a codec. " > > > > > > The word "evaluate" is very different. I read it to mean "how will > a > > > group of people normalize their collective subjective opinion on an > > > observed condition". By example, consider the way cars are reviewed > > > in magazines. Judges who have been trained on a set of metrics > about > > > performance under different conditions (say top end speed, or > > > cornering, or acceleration, or storage space) have a shared set of > > > definitions of performance they might observe, both good and > > > impressive performance as well as poor/faulty performance. They > also > > > have a standard measurement scale -- in this example scoring by > > > points -- by which they record their observations of performance. > The > > > measurement scale includes different values for different > performance > > > elements, i.e. certain observations cost 1/2 point deduction, > others > > > cost 1/4 point, and some gain points because they are more > difficult > > > or beneficial. When comparing two sports cars one might be better > at > > > sharp turns at high speeds and acceleration, while another might be > > > better at sustained high speeds on straight aways. But both are > > > terrible at fitting your family of 6 and all your luggage for a 10 > hr > > > road trip over dirt and rock terrain, towing a ski boat. > > > > > > Likewise, this WG will need to come up with a shared set of > > > "performance" metrics that they might observe from a codec or its > > > sub-mechanisms. And it will need to agree on a system for valuing > > > these metrics. Like the vehicle example, the WG may not determine > one > > > winner, and determine all others losers. But might simply evaluate > > > two and agree that X codec/mechanism is better at Alpha and Beta, > > > where as Y codec/mechanism just as good at Beta, but not as good in > > > Alpha, but much better in Delta, and thus is better applied to > > > environment 3, but not as good as X in environment 2. > > > > > > My point is that the word "evaluate" is intended to have a far > > > different meaning than purely "test". We may do many tests in order > > > to form a unified evaluation. > > > > > > This might be a very subtle difference, but I think it important to > > > tease out. > > > > > > Hope it helps, > > > Gregory > > > > > > At 10:36 PM 7/28/2009, Roni Even wrote: > > > >Markus, > > > >I am happy to hear it, so here is the challenge for you, I assume > you > > > are > > > >following the email discussion and one of the topic is how to > define > > > metrics > > > >and test the quality of the audio candidate. I will be interested > to > > > see you > > > >position about it. > > > >Regards > > > >Roni Even > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > From: Markus Vaalgamaa [mailto:markus.vaalgamaa@skype.net] > > > > > Sent: Wednesday, July 29, 2009 3:41 AM > > > > > To: 'Lars Eggert'; 'Roni Even' > > > > > Cc: codec@ietf.org > > > > > Subject: RE: [codec] Agenda for the Codec Bof > > > > > > > > > > > > > > > Hi Lars, Roni and all, > > > > > > > > > > Roni and Lars wrote: > > > > > >> but no capability to do a real review and quality assessment > > > > > > > > > > > agree with Roni. Having codec specs available that > (apparently) > > > fit > > > > > > the requirements is nice, but it's not clear at all that that > > > means > > > > > > that the experts who have created these codecs will actively > > > > > > participate in an IETF effort that would be based on > something > > > other > > > > > > than their initial candidate submission. > > > > > > > > > > I'm very willing to contribute to the reviewing and quality > > > > > assessments. > > > > > > > > > > I have the lead Call/Audio/Speech Quality Assessment role at > Skype > > > and > > > > > I'm > > > > > working daily with subjective user feedbacks, stats, objective > > > quality > > > > > measurement tools (such as PESQ/P.862), audio measurements, > lab, > > > > > informal & > > > > > formal listening tests, user centric and tech. requirements, > even > > > codec > > > > > & > > > > > other processing algorithm details etc... I also actively > follow > > > and > > > > > participate (as an invited expert) to the key standardization > > > forums of > > > > > these matters - ITU-T SG 12 > > > > > (http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI > STQ > > > > > (http://portal.etsi.org/stq/Summary.asp). So I hope I have > > > something to > > > > > bring to the common work. > > > > > > > > > > I'm also sure there are ways to run a part of formal listening > > > tests at > > > > > Skype facilities if that's seen beneficial later. (or we can > > > arrange > > > > > tests > > > > > with some of the 3rd party labs) > > > > > > > > > > Before I moved to Skype a bit more than 3 years ago, I worked > for > > > > > around 8 > > > > > years in/for Nokia on the similar Speech/Audio Quality > Assessment > > > > > matters + > > > > > audio SW algorithms & audio&speech codecs... and the most of > that > > > time > > > > > I've > > > > > worked at the same building that Lars appears to be working > today > > > ;-) > > > > > > > > > > Best regards with my few Euro cents... > > > > > > > > > > Markus Vaalgamaa > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > > Behalf > > > > > Of > > > > > Lars Eggert > > > > > Sent: Tuesday, July 28, 2009 9:23 AM > > > > > To: Roni Even > > > > > Cc: codec@ietf.org > > > > > Subject: Re: [codec] Agenda for the Codec Bof > > > > > > > > > > Hi, > > > > > > > > > > On 2009-7-27, at 23:48, Roni Even wrote: > > > > > > Having two codec suggested does not represent expertise to > review > > > > > > codec > > > > > > work. The IETF "rubber stamped" the iLBC codec. There was a > > > proposed > > > > > > codec, > > > > > > which you consider expertise, but no capability to do a real > > > review > > > > > > and > > > > > > quality assessment > > > > > > > > > > agree with Roni. Having codec specs available that (apparently) > fit > > > > > the requirements is nice, but it's not clear at all that that > means > > > > > that the experts who have created these codecs will actively > > > > > participate in an IETF effort that would be based on something > > > other > > > > > than their initial candidate submission. > > > > > > > > > > Lars > > > > > > > >_______________________________________________ > > > >codec mailing list > > > >codec@ietf.org > > > >https://www.ietf.org/mailman/listinfo/codec From gregory.ietf@gmail.com Wed Jul 29 23:35:37 2009 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 ED8763A6DC8 for ; Wed, 29 Jul 2009 23:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=1.396] 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 bU-mBzJlQaRX for ; Wed, 29 Jul 2009 23:35:35 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id D214C3A68E3 for ; Wed, 29 Jul 2009 23:35:34 -0700 (PDT) Received: by fxm26 with SMTP id 26so449358fxm.42 for ; Wed, 29 Jul 2009 23:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=QANPjRfzqA+WliUu7IsuCzV0bKp4f33Epkp7W5gX3+w=; b=umTX6+mcMTYPp/RUs447ciNtPb6YTjXCtt0Bh1rw/sC8o897DwwY7kVyQc/FGFqEZO gzj1UHFSJEjy/ZB8LeZkLmtEx1GoISIoqi8SFXqySqJVcWqU1PvGmOz7ILFli2vN5q0M TeYjQ4+HDSbMaXDelmUCddOs/UsiIP1TCzAes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=Hgz4H/ZyyK+SlKji1f1SRjV6rdE4FOGjZjdsFAYTvkBTVltT77XBIb+/BYzLXPBaIS S8wWTG8BKLbCKTlSHtsKXifZVLF2nCQuQgpGTxd0c/sUgo3E6Xfxg9ZUECqAB5zMtqHB wv+UsP1jlqQZCYazmGBG86X70H6St1sXqugc0= Received: by 10.103.182.3 with SMTP id j3mr428894mup.54.1248935732194; Wed, 29 Jul 2009 23:35:32 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id g1sm10801356muf.16.2009.07.29.23.35.30 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 23:35:31 -0700 (PDT) Message-ID: <4a713f33.01b7660a.0dc3.4e58@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 23:35:27 -0700 To: stephen botzko From: "Gregory M. Lebovitz" In-Reply-To: <6e9223710907291940p6a635a67x83d7a5282cb7fbd9@mail.gmail.co m> References: <130EBB38279E9847BAAAE0B8F9905F8C018EC0A6@esealmw109.eemea.ericsson.se> <20090727135713.75DB0296D80@smtp-03.vtx.ch> <4A6E01D3.2040600@iptego.com> <4a6e211c.0a1ad00a.4a28.4ae6@mx.google.com> <594113F1-DCD1-438B-8AC9-ED92FC79170B@nokia.com> <4a6fe05f.0a1ad00a.35f9.7059@mx.google.com> <4a700d8c.09a1660a.2552.2ee1@mx.google.com> <6e9223710907290653p3c1561cckb9c792d190d418cd@mail.gmail.com> <4a70dd31.1ebc720a.5366.ffffac8d@mx.google.com> <6e9223710907291940p6a635a67x83d7a5282cb7fbd9@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_36521671==.ALT" Cc: codec@ietf.org Subject: Re: [codec] Agenda for the Codec Bof X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 06:35:38 -0000 --=====================_36521671==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:40 PM 7/29/2009, stephen botzko wrote: >I'm not in Stockholm, so we won't be able to connect so easily! > > From the examples in your email, "evaluation" seemed to me to be > about scoring/assessing the relative performance of proposals in > order to guide decision making. Once the standardization process > for the codec is completed, the evaluation results are no longer > needed (in the charter draft, it is described being in a tracking document). Ahh. This illuminates that I did a poor job of expressing my thoughts originally. "Evaluation" to me meant more of what you describe as "characterization", because once the comparison is done about a mechanism within a codec, or a codec as a whole, that comparison info needs to be included in its RFC so that everyone going forward knows on which attributes that mech/codec is relatively strong (scored high) and relatively weak (scored low). So I guess your industry uses "characterization" for that? If so, then that's probably a better word to use going forward. >I agree that evaluation in your sense has to be part of the >process. What I was trying to say is that the characterization >report has value even after the standard is complete - it provides >valuable tested results on how the codec performs under a variety of >conditions that really occur. So it should be viewed as a >deliverable in its own right, not as an intermediate result that is >discarded. 100% agree. >The current charter doesn't seem to say that. It talks about how >the metric definitions (and presumably test methods) are >deliverables, but does not clearly say that the test results on the >final codec are a deliverable. As I've talked with the BoF operators, I think they intended it to say what you and I are refining as "characterization" in addition to a scoring for the purpose of preference comparison w/in the work group. I assume they will read this, and take action to edit the charter appropriately. Would you like to propose what you feel is better text to capture this? VERY USEFUL DISCUSSION HERE. Thx, Gregory. (PS - this list would be well served by more of this type of constructive clarification discussion) >Regards, >Stephen Botzko >Polycom > >On Wed, Jul 29, 2009 at 7:37 PM, Gregory M. Lebovitz ><gregory.ietf@gmail.com> wrote: >At 06:53 AM 7/29/2009, stephen botzko wrote: >>I suggest the dictionary definition of "evaluate" is sufficient for >>the charter. >> >>Evaluate: >>1 : to determine or fix the value of >>2 : to determine the significance, worth, or condition of; usually >>by careful appraisal and study >> >>I'd say there is a distinction between what you are calling >>evaluation and what in other SDOs is called characterization. >> >>Characterization (in my view) is not a tracking document and is not >>a weighted scoring system. It is a deliverable that describes the >>codec behavior that has lasting value. One example from 3GPP is found here: >> >>http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip >> >> >>I would prefer to see a characterization deliverable either as a >>section of the codec RFC, or as a separate informational RFC. > >I'm not quite sure I yet see the exact difference between what I (a >non-codec guy just trying to assist in oversight of process issues >here) called "evaluate" and you called "characterized". They seemed >pretty similar. Maybe you can explain it to me tomorrow? > >However, I feel we are narrowing in on what it ought to be, and that >is a very good thing. Thanks for your observation, >Gregory. > > > >>Regards >>Stephen Botzko >>Polycom >> >>On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz >><gregory.ietf@gmail.com > wrote: >>Roni, >>Just to clarify how I read the latest charter... >>It's not that a WG would "test" the quality of the audio of a >>candidate mechanism or codec. It's not a pass vs fail thing. There >>doesn't need to be a winner and a loser. In fact, the word "test" >>does not appear in the charter. The charter does say: >>"define a set of metrics which can be used to evaluate a codec. " >>The word "evaluate" is very different. I read it to mean "how will >>a group of people normalize their collective subjective opinion on >>an observed condition". By example, consider the way cars are >>reviewed in magazines. Judges who have been trained on a set of >>metrics about performance under different conditions (say top >>end speed, or cornering, or acceleration, or storage space) have a >>shared set of definitions of performance they might observe, both >>good and impressive performance as well as poor/faulty performance. >>They also have a standard measurement scale -- in this example >>scoring by points -- by which they record their observations of >>performance. The measurement scale includes different values for >>different performance elements, i.e. certain observations cost 1/2 >>point deduction, others cost 1/4 point, and some gain points >>because they are more difficult or beneficial. When comparing two >>sports cars one might be better at sharp turns at high speeds and >>acceleration, while another might be better at sustained high >>speeds on straight aways. But both are terrible at fitting your >>family of 6 and all your luggage for a 10 hr road trip over dirt >>and rock terrain, towing a ski boat. >> >>Likewise, this WG will need to come up with a shared set of >>"performance" metrics that they might observe from a codec or its >>sub-mechanisms. And it will need to agree on a system for valuing >>these metrics. Like the vehicle example, the WG may not determine >>one winner, and determine all others losers. But might simply >>evaluate two and agree that X codec/mechanism is better at Alpha >>and Beta, where as Y codec/mechanism just as good at Beta, but not >>as good in Alpha, but much better in Delta, and thus is better >>applied to environment 3, but not as good as X in environment 2. >>My point is that the word "evaluate" is intended to have a far >>different meaning than purely "test". We may do many tests in order >>to form a unified evaluation. >>This might be a very subtle difference, but I think it important to >>tease out. >>Hope it helps, >>Gregory >> >>At 10:36 PM 7/28/2009, Roni Even wrote: >>Markus, >>I am happy to hear it, so here is the challenge for you, I assume you are >>following the email discussion and one of the topic is how to define metrics >>and test the quality of the audio candidate. I will be interested to see you >>position about it. >>Regards >>Roni Even >> >> >> >>-----Original Message----- >> > From: Markus Vaalgamaa [ mailto:markus.vaalgamaa@skype.net] >> > Sent: Wednesday, July 29, 2009 3:41 AM >> > To: 'Lars Eggert'; 'Roni Even' >> > Cc: codec@ietf.org >> > Subject: RE: [codec] Agenda for the Codec Bof >> > >> > >> > Hi Lars, Roni and all, >> > >> > Roni and Lars wrote: >> > >> but no capability to do a real review and quality assessment >> > >> > > agree with Roni. Having codec specs available that (apparently) fit >> > > the requirements is nice, but it's not clear at all that that means >> > > that the experts who have created these codecs will actively >> > > participate in an IETF effort that would be based on something other >> > > than their initial candidate submission. >> > >> > I'm very willing to contribute to the reviewing and quality >> > assessments. >> > >> > I have the lead Call/Audio/Speech Quality Assessment role at Skype and >> > I'm >> > working daily with subjective user feedbacks, stats, objective quality >> > measurement tools (such as PESQ/P.862), audio measurements, lab, >> > informal & >> > formal listening tests, user centric and tech. requirements, even codec >> > & >> > other processing algorithm details etc... I also actively follow and >> > participate (as an invited expert) to the key standardization forums of >> > these matters - ITU-T SG 12 >> > ( http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ >> > ( http://portal.etsi.org/stq/Summary.asp). So I hope I have something to >> > bring to the common work. >> > >> > I'm also sure there are ways to run a part of formal listening tests at >> > Skype facilities if that's seen beneficial later. (or we can arrange >> > tests >> > with some of the 3rd party labs) >> > >> > Before I moved to Skype a bit more than 3 years ago, I worked for >> > around 8 >> > years in/for Nokia on the similar Speech/Audio Quality Assessment >> > matters + >> > audio SW algorithms & audio&speech codecs... and the most of that time >> > I've >> > worked at the same building that Lars appears to be working today ;-) >> > >> > Best regards with my few Euro cents... >> > >> > Markus Vaalgamaa >> > >> > >> > -----Original Message----- >> > From: codec-bounces@ietf.org [ >> mailto:codec-bounces@ietf.org] On Behalf >> > Of >> > Lars Eggert >> > Sent: Tuesday, July 28, 2009 9:23 AM >> > To: Roni Even >> > Cc: codec@ietf.org >> > Subject: Re: [codec] Agenda for the Codec Bof >> > >> > Hi, >> > >> > On 2009-7-27, at 23:48, Roni Even wrote: >> > > Having two codec suggested does not represent expertise to review >> > > codec >> > > work. The IETF "rubber stamped" the iLBC codec. There was a proposed >> > > codec, >> > > which you consider expertise, but no capability to do a real review >> > > and >> > > quality assessment >> > >> > agree with Roni. Having codec specs available that (apparently) fit >> > the requirements is nice, but it's not clear at all that that means >> > that the experts who have created these codecs will actively >> > participate in an IETF effort that would be based on something other >> > than their initial candidate submission. >> > >> > Lars >>_______________________________________________ >>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 --=====================_36521671==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 07:40 PM 7/29/2009, stephen botzko wrote:
I'm not in Stockholm, so we won't be able to connect so easily!

From the examples in your email, "evaluation" seemed to me to be about scoring/assessing the relative performance of proposals in order to guide decision making.   Once the standardization process for the codec is completed, the evaluation results are no longer needed (in the charter draft, it is described being in a tracking document).

Ahh. This illuminates that I did a poor job of expressing my thoughts originally. "Evaluation" to me meant more of what you describe as "characterization", because once the comparison is done about a mechanism within a codec, or a codec as a whole, that comparison info needs to be included in its RFC so that everyone going forward knows on which attributes that mech/codec is relatively strong (scored high) and relatively weak (scored low). So I guess your industry uses "characterization" for that? If so, then that's probably a better word to use going forward.


I agree that evaluation in yo= ur sense has to be part of the process.  What I was trying to say is that the characterization report has value even after the standard is complete - it provides valuable tested results on how the codec performs under a variety of conditions that really occur.  So it should be viewed as a deliverable in its own right, not as an intermediate result that is discarded. 

100% agree.


The current charter doesn't s= eem to say that.  It talks about how the metric definitions (and presumably test methods) are deliverables, but does not clearly say that the test results on the final codec are a deliverable.

As I've talked with the BoF operators, I think they intended it to say what you and I are refining as "characterization" in addition to a scoring for the purpose of preference comparison w/in the work group. I assume they will read this, and take action to edit the charter appropriately.

Would you like to propose what you feel is better text to capture this?

VERY USEFUL DISCUSSION HERE. Thx,
Gregory.
(PS - this list would be well served by more of this type of constructive clarification discussion)


Regards,
Stephen Botzko
Polycom

On Wed, Jul 29, 2009 at 7:37 PM, Gregory M. Lebovitz <gregory.ietf@gmail.com > wrote:
At 06:53 AM 7/29/2009, stephen botzko wrote:
I suggest the dictionary definition of "evaluate" is sufficient for the charter.

Evaluate:
1 : to determine or fix the value of
2 : to determine the significance, worth, or condition of; usually by careful appraisal and study

I'd say there is a distinction between what you are calling evaluation and what in other SDOs is called characterization. 

Characterization (in my view) is not a tracking document and is not a weighted scoring system. It is a deliverable that describes the codec behavior that has lasting value. One example from 3GPP is found here:

http://www.3gpp.org/ftp/Specs/archive/26_series/26.975/26975-800.zip

I would prefer to see a characterization deliverable either as a section of the codec RFC, or as a separate informational RFC.

I'm not quite sure I yet see the exact difference between what I (a non-codec guy just trying to assist in oversight of process issues here) called "evaluate" and you called "characterized". They seemed pretty similar. Maybe you can explain it to me tomorrow?

However, I feel we are narrowing in on what it ought to be, and that is a very good thing. Thanks for your observation,
Gregory.



Regards
Stephen Botzko
Polycom

On Wed, Jul 29, 2009 at 4:51 AM, Gregory M. Lebovitz <gregory.ietf@gmail.com > wrote:
Roni,
Just to clarify how I read the latest charter...
It's not that a WG would "test" the quality of the audio of a candidate mechanism or codec. It's not a pass vs fail thing. There doesn't need to be a winner and a loser. In fact, the word "test" does not appear in the charter. The charter does say:
"define a set of metrics which can be used to evaluate a codec. "
The word "evaluate" is very different. I read it to mean "how will a group of people normalize their collective subjective opinion on an observed condition". By example, consider the way cars are reviewed in magazines. Judges who have been trained on a set of metrics about performance under different conditions (say top end  speed, or cornering, or acceleration, or storage space) have a shared set of definitions of performance they might observe, both good and impressive performance as well as poor/faulty performance. They also have a standard measurement scale -- in this example scoring by points -- by which they record their observations of performance. The measurement scale includes different values for different performance elements, i.e. certain observations cost 1/2 point deduction, others cost 1/4 point, and some gain points because they are more difficult or beneficial. When comparing two sports cars one might be better at sharp turns at high speeds and acceleration, while another might be better at sustained high speeds on straight aways. But both are terrible at fitting your family of 6 and all your luggage for a 10 hr road trip over dirt and rock terrain, towing a ski boat.

Likewise, this WG will need to come up with a shared set of "performance" metrics that they might observe from a codec or its sub-mechanisms. And it will need to agree on a system for valuing these metrics. Like the vehicle example, the WG may not determine one winner, and determine all others losers. But might simply evaluate two and agree that X codec/mechanism is better at Alpha and Beta, where as Y codec/mechanism just as good at Beta, but not as good in Alpha, but much better in Delta, and thus is better applied to environment 3, but not as good as X in environment 2.
My point is that the word "evaluate" is intended to have a far different meaning than purely "test". We may do many tests in order to form a unified evaluation.
This might be a very subtle difference, but I think it important to tease out.
Hope it helps,
Gregory

At 10:36 PM 7/28/2009, Roni Even wrote:
Markus,
I am happy to hear it, so here is the challenge for you, I assume you are
following the email discussion and one of the topic is how to define metrics
and test the quality of the audio candidate. I will be interested to see you
position about it.
Regards
Roni Even



-----Original Message-----
> From: Markus Vaalgamaa [ mailto:markus.vaalgamaa@skype.net]
> Sent: Wednesday, July 29, 2009 3:41 AM
> To: 'Lars Eggert'; 'Roni Even'
> Cc: codec@ietf.org
> Subject: RE: [codec] Agenda for the Codec Bof
>
>
> Hi Lars, Roni and all,
>
> Roni and Lars wrote:
> >> but no capability to do a real review and quality assessment
>
> > agree with Roni. Having codec specs available that (apparently) fit
> > the requirements is nice, but it's not clear at all that that means
> > that the experts who have created these codecs will actively
> > participate in an IETF effort that would be based on something other
> > than their initial candidate submission.
>
> I'm very willing to contribute to the reviewing and quality
> assessments.
>
> I have the lead Call/Audio/Speech Quality Assessment role at Skype and
> I'm
> working daily with subjective user feedbacks, stats, objective quality
> measurement tools (such as PESQ/P.862), audio measurements, lab,
> informal &
> formal listening tests, user centric and tech. requirements, even codec
> &
> other processing algorithm details etc... I also actively follow and
> participate (as an invited expert) to the key standardization forums of
> these matters - ITU-T SG 12
> ( http://www.itu.int/ITU-T/studygroups/com12/index.asp) and ETSI STQ
> ( http://portal.etsi.org/stq/Summary.asp). So I hope I have something to
> bring to the common work.
>
> I'm also sure there are ways to run a part of formal listening tests at
> Skype facilities if that's seen beneficial later. (or we can arrange
> tests
> with some of the 3rd party labs)
>
> Before I moved to Skype a bit more than 3 years ago, I worked for
> around 8
> years in/for Nokia on the similar Speech/Audio Quality Assessment
> matters +
> audio SW algorithms & audio&speech codecs... and the most of that time
> I've
> worked at the same building that Lars appears to be working today ;-)
>
> Best regards with my few Euro cents...
>
>       Markus Vaalgamaa
>
>
> -----Original Message-----
> From: codec-bounces@ietf.org [ mailto:codec-bounces@ietf.org] On Behalf
> Of
> Lars Eggert
> Sent: Tuesday, July 28, 2009 9:23 AM
> To: Roni Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Agenda for the Codec Bof
>
> Hi,
>
> On 2009-7-27, at 23:48, Roni Even wrote:
> > Having two codec suggested does not represent expertise to review
> > codec
> > work. The IETF "rubber stamped" the iLBC codec. There was a proposed
> > codec,
> > which you consider expertise, but no capability to do a real review
> > and
> > quality assessment
>
> agree with Roni. Having codec specs available that (apparently) fit
> the requirements is nice, but it's not clear at all that that means
> that the experts who have created these codecs will actively
> participate in an IETF effort that would be based on something other
> than their initial candidate submission.
>
> Lars
_______________________________________________
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
--=====================_36521671==.ALT-- From Gerard.Fernando@sun.com Wed Jul 29 23:39:05 2009 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 7F8F03A6BEE for ; Wed, 29 Jul 2009 23:39:05 -0700 (PDT) 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 9ndOjoKCF6Eb for ; Wed, 29 Jul 2009 23:39:04 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 129583A68E3 for ; Wed, 29 Jul 2009 23:38:43 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNL00CLV145EU00@mail-mta.sfvic.sunlabs.com> for codec@ietf.org; Wed, 29 Jul 2009 23:38:29 -0700 (PDT) Received: from [192.168.1.6] ([67.169.183.170]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNL00FG5144X9U1@mail.sunlabs.com> for codec@ietf.org; Wed, 29 Jul 2009 23:38:29 -0700 (PDT) Date: Wed, 29 Jul 2009 23:38:09 -0700 From: Gerard Fernando To: codec@ietf.org Message-id: <4A713FD1.6050404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Cc: Kelly Kishore , Gerard.Fernando@sun.com, Michael DeMoney Subject: [codec] Commitment to a royalty-free outcome by IETF codec WG X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 06:39:05 -0000 All, Assuming this codec standardization effort fits within the scope of the IETF, we suggest that this effort needs to be distinguished from all other codec standardization efforts by a commitment to a royalty-free outcome. To this end we suggest that the work items include the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome. Kind regards Gerard Fernando, Mike DeMoney, Kelly Kishore Sun Microsystems Laboratories From fluffy@cisco.com Thu Jul 30 00:51:55 2009 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 BA2193A6AFC for ; Thu, 30 Jul 2009 00:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 k2DZdW4RtjI6 for ; Thu, 30 Jul 2009 00:51:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7CF133A6E1D for ; Thu, 30 Jul 2009 00:51:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQAAMPtcEqQ/uCKe2dsb2JhbACBUpg6FiQGnw+IJ5ASBYQR X-IronPort-AV: E=Sophos;i="4.43,293,1246838400"; d="scan'208";a="46114845" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2009 07:51:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6U7ptWB027065; Thu, 30 Jul 2009 09:51:55 +0200 Received: from dhcp-50d6.meeting.ietf.org (ams3-vpn-dhcp1335.cisco.com [10.61.69.55]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6U7psjt001366; Thu, 30 Jul 2009 07:51:54 GMT Message-Id: <52CCE37C-3049-4B12-8E4A-A5013E60D83B@cisco.com> From: Cullen Jennings To: Stephan Wenger In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 09:51:53 +0200 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1876; t=1248940315; x=1249804315; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Charter=20Take=202=20-=20BSD=20License=20 |Sender:=20; bh=7Nf7DLVVE/xm94g7gvi6YO8Apv94yknvZeW6LbgXUA8=; b=kuIzYbMOwEGLXfBXOqHZTmJN2oE/VEn9cbMqT0+yU35PnX2x/O0e4wAZLs SSj35jj6rMwgqu5AifQoSW01dMQFbijphxgizwOiwe/b9jwoqJdlT/Coaew8 Ar7tMEleMY; Authentication-Results: ams-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Jean-Marc Valin , codec@ietf.org Subject: [codec] Charter Take 2 - BSD License X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:51:55 -0000 On Jul 29, 2009, at 2:40 , Stephan Wenger wrote: > At present, the RFC editor, per a requirement set by the IETF trust, > inserts > a BSD-style license template into the source code. This templates > include a > phrase "[...] Redistribution and use in source and binary forms, > with or > without modification, are permitted [...]". There are scholars and > corporate lawyers (I personally know quite a few of the latter) > suggesting > that this language---specifically the unqualified use of the term > "use"---may imply a patent license grant. Stephan, at a high level, I don't think this will poses a problem for this BOF. When selecting the BSD license, the IETF did not intent to include patents licenses as part of the "use". If there is a real problem with the BSD license possibly granting patent licenses, the obvious thing to do would be for the Trustees to "qualify" the meaning of "use" in the license. For purposes of this BOF, I think we can assume that if there is any community consensus this is a problem, then it will be fixed. That said, I'm glad to see input on questions such as: should the normative specification should be in source code or not; and if that decision would need to be in charter or be something that a WG might decide if was formed. Cullen PS - Clearly this would be the wrong mailing lists for discussion of the topic but I note Herald, the previous IPR WG chair, did not seem to share your concern. I also note it's not clear if you actually believe this is an issue. I'd certainly be interested i knowing if you personally believed that it was likely that courts would interpret BSD this ways but it's pretty hard to decide how to evaluate the vague reporting of other unnamed peoples opinions. Anyways, all topics for another mail list. From stephane.proust@orange-ftgroup.com Thu Jul 30 00:57:07 2009 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 3A40C3A69A0 for ; Thu, 30 Jul 2009 00:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, SARE_MILLIONSOF=0.315] 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 0hMIwZPV+d19 for ; Thu, 30 Jul 2009 00:57:05 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2259E3A715F for ; Thu, 30 Jul 2009 00:57:02 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 09:57:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA10EB.51B9E8C2" Date: Thu, 30 Jul 2009 09:57:00 +0200 Message-ID: <4D1AA2A55522044480C9B9CF97A9340938A323@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcoQ61G5E4qCQcQnRVq4GlCp/8BYKA== From: To: , X-OriginalArrivalTime: 30 Jul 2009 07:57:03.0062 (UTC) FILETIME=[53136760:01CA10EB] Subject: [codec] (no subject) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:57:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10EB.51B9E8C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable G.722 is already massively deployed and used for mass market WB = telephony services overs IP and provides a very good wideband voice = quality at 64 kbit/s confirmed by the feedback from customers. Please have a look on the LS from DECT (distributed by Cullen Jenning on = this e-mail reflector in attached e-mail in = "DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf") Extract : "Additionally, ETSI TC DECT would like to point out that millions of = devices implementing ITU-T G.722 codec were manufactured, sold in several countries and are available = worldwide now" St=E9phane -----Message d'origine----- De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part = de Alan Johnston Envoy=E9 : jeudi 30 juillet 2009 01:42 =C0 : codec@ietf.org Objet : [codec] Comments I'm not going to comment on the details of the charter but instead just = talk about the high level issues. The situation today is awful - there are a number of good new Internet = codecs, but few have deployed them - no one wants to be the first, and = in the meantime, we are stuck with G.711 et al. We need to try = something to break us out of this situation, and this effort seems like = it could really help. I can't see how it could harm the situation. Secondly, it seems like all previous codecs have been designed in = isolation, or with the needs of some specific layer 2 transport in mind. = What if we really thought hard and came up with the requirements for = our ultimate Internet codec? What kinds of things could we think of? = If we don't do the work, we will never know, and we may yet come up with = a codec that has a compelling deployment story. And then we'd really be getting somewhere... Thanks, Alan _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA10EB.51B9E8C2 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from ftrdsmtp3.rd.francetelecom.fr ([10.192.128.48]) by ftrdmel0.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 17:02:52 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01CA0ADD.7C1FF600" Received: from omfedm08.si.francetelecom.fr ([10.98.84.132]) by ftrdsmtp3.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 17:02:52 +0200 Received: from omfedm12.si.francetelecom.fr (unknown [10.98.62.20]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 205EF68009; Wed, 22 Jul 2009 17:02:52 +0200 (CEST) Received: from omfedm12.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with SMTP id 1A349248223; Wed, 22 Jul 2009 17:02:52 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 87F78248224; Wed, 22 Jul 2009 17:02:47 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C9F3A6973; Wed, 22 Jul 2009 08:02:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5293A698C for ; Wed, 22 Jul 2009 08:02:43 -0700 (PDT) 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 D8CYSIZkgRRp for ; Wed, 22 Jul 2009 08:02:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7BCB63A68AE for ; Wed, 22 Jul 2009 08:02:42 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2009 15:01:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6MF1ctw005099 for ; Wed, 22 Jul 2009 08:01:38 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6MF0bmh022976 for ; Wed, 22 Jul 2009 15:01:28 GMT Content-class: urn:content-classes:message Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10July 2009) Date: Wed, 22 Jul 2009 17:01:28 +0200 Message-ID: <2F73DAAD-E503-4DC8-A329-4F40FDFD5723@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10July 2009) Thread-Index: AcoK3Xy0yA9TDUKfQwan9rdogV2lsg== References: <334A4109C6BEA14ABB48EBCF274A6C8A04E339C7@MAILBOX1.blue.itu.ch> List-Help: List-Subscribe: , List-Unsubscribe: , From: Sender: To: This is a multi-part message in MIME format. ------_=_NextPart_002_01CA0ADD.7C1FF600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: > Date: July 22, 2009 8:53:31 AM MDT (CA) > To: , > Cc: , > Subject: RE: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 =20 > July 2009) > > Dear Cullen, Russ > > I have been asked to forward you information we just received from =20 > ETSI DECT on the usage of ITU-T codecs in next generation ETSI DECT =20 > systems, in the hope it may assist in the discussions in the codec =20 > mailing list, as well as on the deliberations whether or not to =20 > create a WG under RAI for a wideband internet codec. > > I attach two derivative formats of the original document (the =20 > original was winword), PDF and HTML, I am not sure which format will =20 > render better. Will you, or should I, forward =20 > <> i =20 > <> t to the codec =20 > mailing list? > > Best regards, > Sim=E3o > > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm >> > << DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf >> > > _____________________________________________ > From: TSBSG16, ITU [mailto:tsbsg16@itu.int] > Sent: 14 July 2009 16:51 > To: housley@vigilsec.com; fluffy@cisco.com; statements@ietf.org > Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com > Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July =20 > 2009) > > > > Kindly find attached the Liaison Statement COM16 - LS 71 on =20 > "information on ITU-T Speech and audio coding standardisation" =20 > addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting =20 > (10 July 2009). > > Please take note that we are sending herewith the word version as =20 > well as the pdf version of the LS. In addition, there is an =20 > attachment, which is in excel. Since it is quite complex with =20 > different sheets, we preferred to keep the excel file in the =20 > original version. > > << ls071-16.doc >> > << ls071-16.pdf >> > << ls071_Att.1_Copy of MCSD-Database-V20081003.xls >> > > > Best regards, > Rosa Angeles-Le=F3n de Vivero > Assistant for ITU-T Study Group 16 > ITU - Telecommunication Standardization Bureau (TSB) > SG 16 e-mail: tsbsg16@itu.int > Tel. 41-22 730 5445 > Fax 41-22 730 5853 > > ------_=_NextPart_002_01CA0ADD.7C1FF600 Content-Type: text/html; name="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm" Content-Transfer-Encoding: base64 Content-Description: DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm Content-Disposition: attachment; filename="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.htm" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQ0KeG1sbnM6bz0i dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIg0NCnhtbG5zOnc9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiDQ0KeG1sbnM9Imh0dHA6Ly93d3cudzMu b3JnL1RSL1JFQy1odG1sNDAiPg0NCg0NCjxoZWFkPg0NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVu dC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0NCjxtZXRh IG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NDQo8bWV0YSBuYW1lPUdlbmVyYXRv ciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSI+DQ0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIj4NDQo8bGluayByZWw9RmlsZS1MaXN0DQ0KaHJlZj0i REVDVDM4XzAxN3IxX0xpYWlzb25fdG9fSVRVX1NHMTZfb25fY29kZWNzLWNsZWFuX2ZpbGVzL2Zp bGVsaXN0LnhtbCI+DQ0KPHRpdGxlPkVUU0kgREVDVCMzOCAvIERFQ1QzOF8wMTcgLSBMUyB0byBJ VFUtVCBTRyAxNjwvdGl0bGU+DQ0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQ0KIDxvOkRvY3Vt ZW50UHJvcGVydGllcz4NDQogIDxvOlN1YmplY3Q+VElTUEFOIzEwYmlzIE1lZXRpbmcsIFNBLCAz MCBKYW4tMTAgRmViIDIwMDY8L286U3ViamVjdD4NDQogIDxvOkF1dGhvcj5BbGluZSBMdXRoZXI8 L286QXV0aG9yPg0NCiAgPG86TGFzdEF1dGhvcj5TaW3jbyBDYW1wb3MtTmV0bzwvbzpMYXN0QXV0 aG9yPg0NCiAgPG86UmV2aXNpb24+MjwvbzpSZXZpc2lvbj4NDQogIDxvOlRvdGFsVGltZT44PC9v OlRvdGFsVGltZT4NDQogIDxvOkNyZWF0ZWQ+MjAwOS0wNy0yMlQxNDo0MzowMFo8L286Q3JlYXRl ZD4NDQogIDxvOkxhc3RTYXZlZD4yMDA5LTA3LTIyVDE0OjQzOjAwWjwvbzpMYXN0U2F2ZWQ+DQ0K ICA8bzpQYWdlcz4yPC9vOlBhZ2VzPg0NCiAgPG86V29yZHM+NTEyPC9vOldvcmRzPg0NCiAgPG86 Q2hhcmFjdGVycz4yOTIyPC9vOkNoYXJhY3RlcnM+DQ0KICA8bzpDb21wYW55PkVUU0kgU2VjcmV0 YXJpYXQ8L286Q29tcGFueT4NDQogIDxvOkxpbmVzPjI0PC9vOkxpbmVzPg0NCiAgPG86UGFyYWdy YXBocz42PC9vOlBhcmFncmFwaHM+DQ0KICA8bzpDaGFyYWN0ZXJzV2l0aFNwYWNlcz4zNDI4PC9v OkNoYXJhY3RlcnNXaXRoU3BhY2VzPg0NCiAgPG86VmVyc2lvbj4xMS45OTk5PC9vOlZlcnNpb24+ DQ0KIDwvbzpEb2N1bWVudFByb3BlcnRpZXM+DQ0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQ0KIDx3OldvcmREb2N1bWVudD4NDQogIDx3OlNwZWxsaW5nU3RhdGU+ Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NDQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFt bWFyU3RhdGU+DQ0KICA8dzpQdW5jdHVhdGlvbktlcm5pbmcvPg0NCiAgPHc6VmFsaWRhdGVBZ2Fp bnN0U2NoZW1hcy8+DQ0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTElu dmFsaWQ+DQ0KICA8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250 ZW50Pg0NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93 UGxhY2Vob2xkZXJUZXh0Pg0NCiAgPHc6Q29tcGF0aWJpbGl0eT4NDQogICA8dzpTZWxlY3RFbnRp cmVGaWVsZFdpdGhTdGFydE9yRW5kLz4NDQogICA8dzpVc2VXb3JkMjAwMlRhYmxlU3R5bGVSdWxl cy8+DQ0KICA8L3c6Q29tcGF0aWJpbGl0eT4NDQogIDx3OkJyb3dzZXJMZXZlbD5NaWNyb3NvZnRJ bnRlcm5ldEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQ0KIDwvdzpXb3JkRG9jdW1lbnQ+DQ0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQ0KIDx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIExhdGVudFN0eWxlQ291bnQ9IjE1NiI+DQ0KIDwv dzpMYXRlbnRTdHlsZXM+DQ0KPC94bWw+PCFbZW5kaWZdLS0+DQ0KPHN0eWxlPg0NCjwhLS0NDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0NCiBAZm9udC1mYWNlDQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQ0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7DQ0KCW1zby1mb250LWNoYXJz ZXQ6MjsNDQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNDQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQ0KCW1zby1mb250LXNpZ25hdHVyZTowIDI2ODQzNTQ1NiAwIDAgLTIxNDc0ODM2 NDggMDt9DQ0KQGZvbnQtZmFjZQ0NCgl7Zm9udC1mYW1pbHk6VGFob21hOw0NCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDsNDQoJbXNvLWZvbnQtY2hhcnNldDowOw0NCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTpzd2lzczsNDQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQ0KCW1zby1m b250LXNpZ25hdHVyZToxNjI3NDIxMzE5IC0yMTQ3NDgzNjQ4IDggMCA2NjA0NyAwO30NDQogLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0NCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNDQoJbWFyZ2luOjBjbTsNDQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0NCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQ0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNDQoJdGFiLXN0b3BzOjcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRw dDsNDQoJbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7DQ0KCXB1bmN0dWF0aW9uLXdyYXA6c2lt cGxlOw0NCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0NCglmb250LXNpemU6MTAuMHB0Ow0NCglmb250 LWZhbWlseTpBcmlhbDsNDQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7DQ0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYW5z aS1sYW5ndWFnZTpFTi1HQjt9DQ0KaDENDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQ0KCW1zby1z dHlsZS1uZXh0Ok5vcm1hbDsNDQoJbWFyZ2luLXRvcDowY207DQ0KCW1hcmdpbi1yaWdodDowY207 DQ0KCW1hcmdpbi1ib3R0b206MTIuMHB0Ow0NCgltYXJnaW4tbGVmdDozNS40NXB0Ow0NCgl0ZXh0 LWFsaWduOmp1c3RpZnk7DQ0KCXRleHQtaW5kZW50Oi0zNS40NXB0Ow0NCglsaW5lLWhlaWdodDox Mi4wcHQ7DQ0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbiBsaW5lcy10b2dldGhlcjsNDQoJ cGFnZS1icmVhay1hZnRlcjphdm9pZDsNDQoJbXNvLW91dGxpbmUtbGV2ZWw6MTsNDQoJdGFiLXN0 b3BzOjM1LjQ1cHQ7DQ0KCW1zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lOw0NCglwdW5jdHVhdGlv bi13cmFwOnNpbXBsZTsNDQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNDQoJZm9udC1zaXplOjEyLjBw dDsNDQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNDQoJZm9udC1mYW1pbHk6QXJpYWw7DQ0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tZm9udC1rZXJu aW5nOjBwdDsNDQoJbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0I7DQ0KCW1zby1iaWRpLWZvbnQtd2Vp Z2h0Om5vcm1hbDt9DQ0KaDINDQoJe21zby1zdHlsZS1uZXh0Ok5vcm1hbDsNDQoJbWFyZ2luLXRv cDozLjBwdDsNDQoJbWFyZ2luLXJpZ2h0OjBjbTsNDQoJbWFyZ2luLWJvdHRvbToyLjBwdDsNDQoJ bWFyZ2luLWxlZnQ6MGNtOw0NCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQ0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNDQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNDQoJbXNvLW91dGxpbmUt bGV2ZWw6MjsNDQoJdGFiLXN0b3BzOjcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdDsNDQoJ bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7DQ0KCXB1bmN0dWF0aW9uLXdyYXA6c2ltcGxlOw0N Cgl0ZXh0LWF1dG9zcGFjZTpub25lOw0NCglmb250LXNpemU6MTAuMHB0Ow0NCglmb250LWZhbWls eTpBcmlhbDsNDQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1z by1hbnNpLWxhbmd1YWdlOkVOLUdCOw0NCgltc28tYmlkaS1mb250LXdlaWdodDpub3JtYWw7DQ0K CWZvbnQtc3R5bGU6aXRhbGljO30NDQpwLk1zb0NvbW1lbnRUZXh0LCBsaS5Nc29Db21tZW50VGV4 dCwgZGl2Lk1zb0NvbW1lbnRUZXh0DQ0KCXttc28tc3R5bGUtbm9zaG93OnllczsNDQoJbWFyZ2lu OjBjbTsNDQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0NCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQ0K CW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNDQoJdGFiLXN0b3BzOjcwLjlwdCAyMzMuOXB0 IDI5Ny43cHQgMzU0LjRwdDsNDQoJbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7DQ0KCXB1bmN0 dWF0aW9uLXdyYXA6c2ltcGxlOw0NCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0NCglmb250LXNpemU6 MTAuMHB0Ow0NCglmb250LWZhbWlseTpBcmlhbDsNDQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iOw0NCgltc28tYW5zaS1sYW5ndWFnZTpFTi1HQjt9DQ0KcC5Nc29IZWFkZXIsIGxpLk1zb0hl YWRlciwgZGl2Lk1zb0hlYWRlcg0NCgl7bWFyZ2luOjBjbTsNDQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0NCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQ0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhh bjsNDQoJdGFiLXN0b3BzOjcwLjlwdCBjZW50ZXIgMjA3LjY1cHQgbGVmdCAyMzMuOXB0IDI5Ny43 cHQgMzU0LjRwdCByaWdodCA0MTUuM3B0Ow0NCgltc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTsN DQoJcHVuY3R1YXRpb24td3JhcDpzaW1wbGU7DQ0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQ0KCWZv bnQtc2l6ZToxMC4wcHQ7DQ0KCWZvbnQtZmFtaWx5OkFyaWFsOw0NCgltc28tZmFyZWFzdC1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNDQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQ0KCW1zby1hbnNpLWxhbmd1YWdlOkVOLUdCO30NDQpwLk1zb0Zvb3Rlciwg bGkuTXNvRm9vdGVyLCBkaXYuTXNvRm9vdGVyDQ0KCXttYXJnaW46MGNtOw0NCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQ0KCXRleHQtYWxpZ246anVzdGlmeTsNDQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0NCgl0YWItc3RvcHM6NzAuOXB0IGNlbnRlciAyMDcuNjVwdCBsZWZ0IDIzMy45 cHQgMjk3LjdwdCAzNTQuNHB0IHJpZ2h0IDQxNS4zcHQ7DQ0KCW1zby1sYXlvdXQtZ3JpZC1hbGln bjpub25lOw0NCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNDQoJdGV4dC1hdXRvc3BhY2U6bm9u ZTsNDQoJZm9udC1zaXplOjEwLjBwdDsNDQoJZm9udC1mYW1pbHk6QXJpYWw7DQ0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNDQoJbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0I7fQ0NCnNwYW4u TXNvQ29tbWVudFJlZmVyZW5jZQ0NCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQ0KCW1zby1hbnNp LWZvbnQtc2l6ZTo4LjBwdDsNDQoJbXNvLWJpZGktZm9udC1zaXplOjguMHB0O30NDQpwLk1zb0xp c3QsIGxpLk1zb0xpc3QsIGRpdi5Nc29MaXN0DQ0KCXttYXJnaW4tdG9wOjBjbTsNDQoJbWFyZ2lu LXJpZ2h0OjBjbTsNDQoJbWFyZ2luLWJvdHRvbTowY207DQ0KCW1hcmdpbi1sZWZ0OjE0LjE1cHQ7 DQ0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNDQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0NCgl0ZXh0 LWluZGVudDotMTQuMTVwdDsNDQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0NCgl0YWIt c3RvcHM6NzAuOXB0IDIzMy45cHQgMjk3LjdwdCAzNTQuNHB0Ow0NCgltc28tbGF5b3V0LWdyaWQt YWxpZ246bm9uZTsNDQoJcHVuY3R1YXRpb24td3JhcDpzaW1wbGU7DQ0KCXRleHQtYXV0b3NwYWNl Om5vbmU7DQ0KCWZvbnQtc2l6ZToxMC4wcHQ7DQ0KCWZvbnQtZmFtaWx5OkFyaWFsOw0NCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNDQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1zby1hbnNpLWxhbmd1YWdlOkVOLUdCO30NDQpw Lk1zb0JvZHlUZXh0LCBsaS5Nc29Cb2R5VGV4dCwgZGl2Lk1zb0JvZHlUZXh0DQ0KCXttYXJnaW46 MGNtOw0NCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQ0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9y cGhhbjsNDQoJdGFiLXN0b3BzOjcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdDsNDQoJbXNv LWxheW91dC1ncmlkLWFsaWduOm5vbmU7DQ0KCXB1bmN0dWF0aW9uLXdyYXA6c2ltcGxlOw0NCgl0 ZXh0LWF1dG9zcGFjZTpub25lOw0NCglmb250LXNpemU6MTAuMHB0Ow0NCglmb250LWZhbWlseTpB cmlhbDsNDQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYW5zaS1sYW5ndWFn ZTpFTi1HQjsNDQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQ0KcC5Nc29Cb2R5VGV4dDIsIGxpLk1zb0Jv ZHlUZXh0MiwgZGl2Lk1zb0JvZHlUZXh0Mg0NCgl7bWFyZ2luOjBjbTsNDQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0NCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQ0KCXRhYi1zdG9wczo3 MC45cHQgMjMzLjlwdCAyOTcuN3B0IDM1NC40cHQ7DQ0KCW1zby1sYXlvdXQtZ3JpZC1hbGlnbjpu b25lOw0NCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNDQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsN DQoJZm9udC1zaXplOjEwLjBwdDsNDQoJZm9udC1mYW1pbHk6QXJpYWw7DQ0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjsNDQoJbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0I7fQ0NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNDQoJe2NvbG9yOmJsdWU7DQ0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQ0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQ0KCXtjb2xvcjojNjA2NDIwOw0NCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0NCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0NCnAuTXNvRG9jdW1lbnRNYXAsIGxp Lk1zb0RvY3VtZW50TWFwLCBkaXYuTXNvRG9jdW1lbnRNYXANDQoJe21zby1zdHlsZS1ub3Nob3c6 eWVzOw0NCgltYXJnaW46MGNtOw0NCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQ0KCXRleHQtYWxp Z246anVzdGlmeTsNDQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0NCgl0YWItc3RvcHM6 NzAuOXB0IDIzMy45cHQgMjk3LjdwdCAzNTQuNHB0Ow0NCgliYWNrZ3JvdW5kOm5hdnk7DQ0KCW1z by1sYXlvdXQtZ3JpZC1hbGlnbjpub25lOw0NCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNDQoJ dGV4dC1hdXRvc3BhY2U6bm9uZTsNDQoJZm9udC1zaXplOjEwLjBwdDsNDQoJZm9udC1mYW1pbHk6 VGFob21hOw0NCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNDQoJ bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0I7fQ0NCnAuTXNvQ29tbWVudFN1YmplY3QsIGxpLk1zb0Nv bW1lbnRTdWJqZWN0LCBkaXYuTXNvQ29tbWVudFN1YmplY3QNDQoJe21zby1zdHlsZS1ub3Nob3c6 eWVzOw0NCgltc28tc3R5bGUtcGFyZW50OiJDb21tZW50IFRleHQiOw0NCgltc28tc3R5bGUtbmV4 dDoiQ29tbWVudCBUZXh0IjsNDQoJbWFyZ2luOjBjbTsNDQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0NCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQ0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsN DQoJdGFiLXN0b3BzOjcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdDsNDQoJbXNvLWxheW91 dC1ncmlkLWFsaWduOm5vbmU7DQ0KCXB1bmN0dWF0aW9uLXdyYXA6c2ltcGxlOw0NCgl0ZXh0LWF1 dG9zcGFjZTpub25lOw0NCglmb250LXNpemU6MTAuMHB0Ow0NCglmb250LWZhbWlseTpBcmlhbDsN DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYW5zaS1sYW5ndWFnZTpFTi1H QjsNDQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk aXYuTXNvQWNldGF0ZQ0NCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQ0KCW1hcmdpbjowY207DQ0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNDQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0NCgltc28tcGFn aW5hdGlvbjp3aWRvdy1vcnBoYW47DQ0KCXRhYi1zdG9wczo3MC45cHQgMjMzLjlwdCAyOTcuN3B0 IDM1NC40cHQ7DQ0KCW1zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lOw0NCglwdW5jdHVhdGlvbi13 cmFwOnNpbXBsZTsNDQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNDQoJZm9udC1zaXplOjguMHB0Ow0N Cglmb250LWZhbWlseTpUYWhvbWE7DQ0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0NCgltc28tYW5zaS1sYW5ndWFnZTpFTi1HQjt9DQ0Kc3Bhbi5aR1NNDQ0KCXtt c28tc3R5bGUtbmFtZTpaR1NNOw0NCgltc28tc3R5bGUtcGFyZW50OiIiO30NDQpwLk5PLCBsaS5O TywgZGl2Lk5PDQ0KCXttc28tc3R5bGUtbmFtZTpOTzsNDQoJbWFyZ2luLXRvcDowY207DQ0KCW1h cmdpbi1yaWdodDowY207DQ0KCW1hcmdpbi1ib3R0b206OS4wcHQ7DQ0KCW1hcmdpbi1sZWZ0OjU2 Ljc1cHQ7DQ0KCXRleHQtaW5kZW50Oi00Mi41NXB0Ow0NCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW4gbGluZXMtdG9nZXRoZXI7DQ0KCW1zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lOw0NCglw dW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNDQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNDQoJZm9udC1z aXplOjEwLjBwdDsNDQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0NCgltc28tYW5zaS1sYW5ndWFnZTpF Ti1HQjt9DQ0KcC5CMSwgbGkuQjEsIGRpdi5CMQ0NCgl7bXNvLXN0eWxlLW5hbWU6QjE7DQ0KCW1z by1zdHlsZS1wYXJlbnQ6TGlzdDsNDQoJbWFyZ2luLXRvcDowY207DQ0KCW1hcmdpbi1yaWdodDow Y207DQ0KCW1hcmdpbi1ib3R0b206OS4wcHQ7DQ0KCW1hcmdpbi1sZWZ0OjM2LjlwdDsNDQoJdGV4 dC1pbmRlbnQ6LTIyLjdwdDsNDQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0NCgltc28t bGF5b3V0LWdyaWQtYWxpZ246bm9uZTsNDQoJcHVuY3R1YXRpb24td3JhcDpzaW1wbGU7DQ0KCXRl eHQtYXV0b3NwYWNlOm5vbmU7DQ0KCWZvbnQtc2l6ZToxMC4wcHQ7DQ0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0NCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNDQoJbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0I7fQ0NCnNwYW4ubXNvSW5zDQ0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNDQoJbXNvLXN0eWxlLW5hbWU6IiI7DQ0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7DQ0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTsNDQoJY29sb3I6dGVh bDt9DQ0Kc3Bhbi5tc29EZWwNDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0NCgltc28t c3R5bGUtbmFtZToiIjsNDQoJdGV4dC1kZWNvcmF0aW9uOmxpbmUtdGhyb3VnaDsNDQoJY29sb3I6 cmVkO30NDQpzcGFuLlNwZWxsRQ0NCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQ0KCW1zby1zcGwtZTp5 ZXM7fQ0NCnNwYW4uR3JhbUUNDQoJe21zby1zdHlsZS1uYW1lOiIiOw0NCgltc28tZ3JhbS1lOnll czt9DQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NDQogQHBhZ2UNDQoJe21zby1mb290bm90ZS1z ZXBhcmF0b3I6dXJsKCJERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9vbl9jb2RlY3Mt Y2xlYW5fZmlsZXMvaGVhZGVyLmh0bSIpIGZzOw0NCgltc28tZm9vdG5vdGUtY29udGludWF0aW9u LXNlcGFyYXRvcjp1cmwoIkRFQ1QzOF8wMTdyMV9MaWFpc29uX3RvX0lUVV9TRzE2X29uX2NvZGVj cy1jbGVhbl9maWxlcy9oZWFkZXIuaHRtIikgZmNzOw0NCgltc28tZW5kbm90ZS1zZXBhcmF0b3I6 dXJsKCJERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9vbl9jb2RlY3MtY2xlYW5fZmls ZXMvaGVhZGVyLmh0bSIpIGVzOw0NCgltc28tZW5kbm90ZS1jb250aW51YXRpb24tc2VwYXJhdG9y OnVybCgiREVDVDM4XzAxN3IxX0xpYWlzb25fdG9fSVRVX1NHMTZfb25fY29kZWNzLWNsZWFuX2Zp bGVzL2hlYWRlci5odG0iKSBlY3M7fQ0NCkBwYWdlIFNlY3Rpb24xDQ0KCXtzaXplOjU5NS4zcHQg ODQxLjlwdDsNDQoJbWFyZ2luOjI3LjBwdCA4OS44NXB0IDcyLjBwdCA1My44NXB0Ow0NCgltc28t aGVhZGVyLW1hcmdpbjozNS40NXB0Ow0NCgltc28tZm9vdGVyLW1hcmdpbjozNS40NXB0Ow0NCglt c28tZXZlbi1oZWFkZXI6dXJsKCJERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9vbl9j b2RlY3MtY2xlYW5fZmlsZXMvaGVhZGVyLmh0bSIpIGVoMTsNDQoJbXNvLXBhcGVyLXNvdXJjZTow O30NDQpkaXYuU2VjdGlvbjENDQoJe3BhZ2U6U2VjdGlvbjE7fQ0NCiAvKiBMaXN0IERlZmluaXRp b25zICovDQ0KIEBsaXN0IGwwDQ0KCXttc28tbGlzdC1pZDoyMTc4ODg4OTsNDQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQ0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDg0OTI4NzYyIC0xNzQ3MDEw NzU2IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3 IDY3NTY3NjE5IDY3NTY3NjIxO30NDQpAbGlzdCBsMDpsZXZlbDENDQoJe21zby1sZXZlbC1zdGFy dC1hdDo1Ow0NCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQ0KCW1zby1sZXZlbC10 ZXh0Oi07DQ0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQ0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNDQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0NCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0NCglmb250LWZhbWlseTpBcmlhbDsNDQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0NCkBsaXN0IGwxDQ0KCXttc28tbGlzdC1pZDo4NzUwNDI3ODsNDQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQ0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTMxNjMzMjY4 IC0xNzQ3MDEwNzU2IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAx IDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NDQpAbGlzdCBsMTpsZXZlbDENDQoJe21zby1s ZXZlbC1zdGFydC1hdDo1Ow0NCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQ0KCW1z by1sZXZlbC10ZXh0Oi07DQ0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQ0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNDQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0NCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0NCglmb250LWZhbWlseTpBcmlhbDsNDQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0NCkBsaXN0IGwyDQ0KCXttc28tbGlzdC1pZDo3ODc0 Mjc4OTQ7DQ0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0NCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MjEwNjQwMTQ2IC0xNzQ3MDEwNzU2IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5 IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NDQpAbGlzdCBsMjpsZXZlbDEN DQoJe21zby1sZXZlbC1zdGFydC1hdDo1Ow0NCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQ0KCW1zby1sZXZlbC10ZXh0Oi07DQ0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQ0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNDQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0N Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0NCglmb250LWZhbWlseTpBcmlhbDsNDQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0NCkBsaXN0IGwzDQ0KCXttc28tbGlz dC1pZDoyMDg0OTEyODc3Ow0NCgltc28tbGlzdC10eXBlOmh5YnJpZDsNDQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0yMTA0Njk3NjM2IC0xNzQ3MDEwNzU2IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3 NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NDQpAbGlz dCBsMzpsZXZlbDENDQoJe21zby1sZXZlbC1zdGFydC1hdDo1Ow0NCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQ0KCW1zby1sZXZlbC10ZXh0Oi07DQ0KCW1zby1sZXZlbC10YWItc3Rv cDo4OS4yNXB0Ow0NCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQ0KCW1hcmdpbi1s ZWZ0Ojg5LjI1cHQ7DQ0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQ0KCWZvbnQtZmFtaWx5OkFyaWFs Ow0NCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQ0Kb2wNDQoJ e21hcmdpbi1ib3R0b206MGNtO30NDQp1bA0NCgl7bWFyZ2luLWJvdHRvbTowY207fQ0NCi0tPg0N Cjwvc3R5bGU+DQ0KPCEtLVtpZiBndGUgbXNvIDEwXT4NDQo8c3R5bGU+DQ0KIC8qIFN0eWxlIERl ZmluaXRpb25zICovDQ0KIHRhYmxlLk1zb05vcm1hbFRhYmxlDQ0KCXttc28tc3R5bGUtbmFtZToi VGFibGUgTm9ybWFsIjsNDQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNDQoJbXNvLXRzdHls ZS1jb2xiYW5kLXNpemU6MDsNDQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQ0KCW1zby1zdHlsZS1w YXJlbnQ6IiI7DQ0KCW1zby1wYWRkaW5nLWFsdDowY20gNS40cHQgMGNtIDUuNHB0Ow0NCgltc28t cGFyYS1tYXJnaW46MGNtOw0NCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQ0KCW1z by1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNDQoJZm9udC1zaXplOjEwLjBwdDsNDQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQ0KCW1zby1hbnNpLWxhbmd1YWdlOiMwNDAwOw0NCglt c28tZmFyZWFzdC1sYW5ndWFnZTojMDQwMDsNDQoJbXNvLWJpZGktbGFuZ3VhZ2U6IzA0MDA7fQ0N Cjwvc3R5bGU+DQ0KPCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQ0KIDxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjMwNzQiLz4NDQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NDQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiLz4NDQogPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0NCjwvaGVhZD4NDQoNDQo8Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz0iIzYwNjQyMCIgc3R5bGU9J3RhYi1pbnRlcnZhbDozNi4wcHQnPg0NCg0N CjxkaXYgY2xhc3M9U2VjdGlvbjE+DQ0KDQ0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tcmlnaHQ6LjI1cHQ7bGluZS1oZWlnaHQ6MTUuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOg0N CmV4YWN0bHk7dGFiLXN0b3BzOjcwLjlwdCAxMS4wY20gcmlnaHQgNDE0LjBwdCc+PGIgc3R5bGU9 J21zby1iaWRpLWZvbnQtd2VpZ2h0Og0NCm5vcm1hbCc+PHNwYW4gbGFuZz1GSSBzdHlsZT0nZm9u dC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0NCm1zby1iaWRpLWZvbnQt ZmFtaWx5OkFyaWFsO21zby1hbnNpLWxhbmd1YWdlOkZJJz5FVFNJIERFQ1QjMzg8c3Bhbg0NCnN0 eWxlPSdtc28tdGFiLWNvdW50OjEnPqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgIDwvc3Bhbj5ERUNUMzhfMDE3PC9zcGFuPjwvYj48Yg0NCnN0eWxlPSdtc28tYmlk aS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIGxhbmc9Rkkgc3R5bGU9J2ZvbnQtc2l6ZToxNC4w cHQ7DQ0KbXNvLWJpZGktZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlh bDtjb2xvcjpibGFjazttc28tYW5zaS1sYW5ndWFnZToNDQpGSSc+PG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0 LWFsaWduOmNlbnRlcic+PHNwYW4NDQpzdHlsZT0nZm9udC1zaXplOjIwLjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0NCnRleHQtdHJhbnNm b3JtOnVwcGVyY2FzZTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0NCg0NCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3Rl eHQtYWxpZ246Y2VudGVyO21zby1vdXRsaW5lLWxldmVsOg0NCjEnPjxiIHN0eWxlPSdtc28tYmlk aS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MjAuMHB0Ow0NCm1z by1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO3RleHQtdHJhbnNmb3JtOnVwcGVyY2FzZTttc28tYW5z aS1sYW5ndWFnZTpFTi1VUyc+TGlhaXNvbg0NClN0YXRlbWVudDwvc3Bhbj48L2I+PGIgc3R5bGU9 J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4NDQpzdHlsZT0nZm9udC1zaXplOjE2 LjBwdDttc28tYmlkaS1mb250LXNpemU6MjAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFs Ow0NCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0N Cg0NCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNl bGxwYWRkaW5nPTANDQogc3R5bGU9J21hcmdpbi1sZWZ0OjE0LjRwdDtib3JkZXItY29sbGFwc2U6 Y29sbGFwc2U7bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiA8dHIgc3R5 bGU9J21zby15ZnRpLWlyb3c6MDttc28teWZ0aS1maXJzdHJvdzp5ZXM7bXNvLXlmdGktbGFzdHJv dzp5ZXMnPg0NCiAgPHRkIHdpZHRoPTczIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjU0LjhwdDtw YWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWdu PWxlZnQgc3R5bGU9J21hcmdpbi10b3A6My4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTsNDQogIG1hcmdp bi1ib3R0b206Mi4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYWxpZ246bGVmdCc+PGIgc3R5bGU9 J21zby1iaWRpLWZvbnQtd2VpZ2h0Og0NCiAgbm9ybWFsJz48aSBzdHlsZT0nbXNvLWJpZGktZm9u dC1zdHlsZTpub3JtYWwnPjxzcGFuIHN0eWxlPSdtc28tYmlkaS1mb250LWZhbWlseToNDQogIEFy aWFsO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz5UaXRsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NDQogIDwvdGQ+DQ0KICA8dGQgd2lkdGg9NDc5IHZhbGlnbj10b3Agc3R5bGU9J3dp ZHRoOjM1OS4ycHQ7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0Ow0NCiAgbXNvLWJvcmRlci1ib3R0b20tYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDtwYWRk aW5nOjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiAgPGgyPjxzcGFuIHN0eWxlPSdtc28tYmlkaS1m b250LWZhbWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzsNDQogIG1zby1iaWRpLWZv bnQtd2VpZ2h0OmJvbGQnPkxpYWlzb24gc3RhdGVtZW50IHJlZ2FyZGluZyB0aGUgdXNlIG9mIHdp ZGViYW5kDQ0KICBjb2RlY3Mgd2l0aCBERUNUIG5ldyBnZW5lcmF0aW9uPC9zcGFuPjxzcGFuIHN0 eWxlPSdtc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1zby1hbnNpLWxhbmd1YWdlOkVO LVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0NCiAgPC90ZD4NDQogPC90cj4NDQo8L3RhYmxl Pg0NCg0NCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxl ZnQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQ0KOC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZToNDQpFTi1V Uyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0NCg0NCjx0YWJsZSBjbGFzcz1Nc29Ob3Jt YWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTANDQogc3R5bGU9J21h cmdpbi1sZWZ0OjE0LjRwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7bXNvLXBhZGRpbmctYWx0 OjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiA8dHIgc3R5bGU9J21zby15ZnRpLWlyb3c6MDttc28t eWZ0aS1maXJzdHJvdzp5ZXMnPg0NCiAgPHRkIHdpZHRoPTE1MCB2YWxpZ249dG9wIHN0eWxlPSd3 aWR0aDoxMTIuNXB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1N c29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOmxl ZnQnPjxiDQ0KICBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48aSBzdHlsZT0n bXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwnPjxzcGFuDQ0KICBzdHlsZT0nbXNvLWJpZGktZm9u dC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkZyb208L3NwYW4+PC9pPjwv Yj48aQ0NCiAgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDttc28tYmlkaS1m b250LWZhbWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+OjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxl PSd3aWR0aDozMDEuNXB0O2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDsNDQogIGJv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl ci1yaWdodDpub25lOw0NCiAgbXNvLWJvcmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVw dDttc28tYm9yZGVyLWJvdHRvbS1hbHQ6c29saWQgd2luZG93dGV4dCAuNXB0Ow0NCiAgcGFkZGlu ZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLXRvcDoxLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDsNDQogIG1zby1iaWRp LWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NDQogIDwvdGQ+DQ0KIDwv dHI+DQ0KIDx0ciBzdHlsZT0nbXNvLXlmdGktaXJvdzoxJz4NDQogIDx0ZCB3aWR0aD0xNTAgdmFs aWduPXRvcCBzdHlsZT0nd2lkdGg6MTEyLjVwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQn Pg0NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSdtYXJnaW4tdG9wOjEu MHB0O3RleHQtYWxpZ246cmlnaHQnPjxzcGFuDQ0KICBjbGFzcz1TcGVsbEU+PGkgc3R5bGU9J21z by1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0NCiAgOS4w cHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtt c28tYW5zaS1sYW5ndWFnZToNDQogIEVOLVVTJz5PcmdhbmlzYXRpb248L3NwYW4+PC9pPjwvc3Bh bj48aSBzdHlsZT0nbXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwnPjxzcGFuDQ0KICBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1m YW1pbHk6QXJpYWw7DQ0KICBtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+OjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxl PSd3aWR0aDozMDEuNXB0O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4 dCAxLjBwdDsNDQogIG1zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7bXNv LWJvcmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDsNDQogIG1zby1ib3JkZXItYm90 dG9tLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0 Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDsNDQogIG1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNv LWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkVUU0kNDQog IFRDIERFQ1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQ0KICA8L3RkPg0NCiA8L3RyPg0NCiA8dHIg c3R5bGU9J21zby15ZnRpLWlyb3c6Mic+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5 bGU9J3dpZHRoOjExMi41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNs YXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFs aWduOnJpZ2h0Jz48aQ0NCiAgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDtt c28tYmlkaS1mb250LWZhbWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+Q29udGFj dDo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0NCiAgPC90ZD4NDQogIDx0ZCB3aWR0aD00MDIg dmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MzAxLjVwdDtib3JkZXI6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7DQ0KICBtc28tYm9yZGVyLXRvcC1hbHQ6c29saWQgd2lu ZG93dGV4dCAuNXB0O21zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7DQ0K ICBtc28tYm9yZGVyLWJvdHRvbS1hbHQ6c29saWQgd2luZG93dGV4dCAuNXB0O3BhZGRpbmc6MGNt IDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHls ZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOmxlZnQnPjxzcGFuDQ0KICBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1p bHk6QXJpYWw7DQ0KICBtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+RHIuIEf8bnRlciA8c3BhbiBj bGFzcz1TcGVsbEU+S2xlaW5kbDwvc3Bhbj48L3NwYW4+PHNwYW4NDQogIHN0eWxlPSdmb250LXNp emU6OS4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2s7bXNvLWFuc2kt bGFuZ3VhZ2U6DQ0KICBFTi1VUyc+PG86cD48L286cD48L3NwYW4+PC9wPg0NCiAgPC90ZD4NDQog PC90cj4NDQogPHRyIHN0eWxlPSdtc28teWZ0aS1pcm93OjMnPg0NCiAgPHRkIHdpZHRoPTE1MCB2 YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoxMTIuNXB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRw dCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J21hcmdpbi10b3A6 MS4wcHQ7dGV4dC1hbGlnbjpyaWdodCc+PGkNDQogIHN0eWxlPSdtc28tYmlkaS1mb250LXN0eWxl Om5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28tYmlkaS1mb250LXNpemU6 DQ0KICAxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVMnPmUtbWFpbDo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0NCiAgPC90ZD4NDQogIDx0 ZCB3aWR0aD00MDIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MzAxLjVwdDtib3JkZXI6bm9uZTti b3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7DQ0KICBtc28tYm9yZGVyLXRvcC1h bHQ6c29saWQgd2luZG93dGV4dCAuNXB0O21zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0 ZXh0IC41cHQ7DQ0KICBtc28tYm9yZGVyLWJvdHRvbS1hbHQ6c29saWQgd2luZG93dGV4dCAuNXB0 O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxp Z249bGVmdCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOmxlZnQnPjxzcGFuDQ0K ICBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjxhIGhyZWY9Im1haWx0bzpndWVudGVy LmtsZWluZGxAc2llbWVucy5jb20iPmd1ZW50ZXIua2xlaW5kbEBzaWVtZW5zLmNvbTwvYT48L3Nw YW4+PHNwYW4NDQogIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1zby1hbnNpLWxhbmd1YWdlOkVO LVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQ0KICA8L3RkPg0NCiA8L3RyPg0NCiA8dHIgc3R5 bGU9J21zby15ZnRpLWlyb3c6NCc+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5bGU9 J3dpZHRoOjExMi41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNz PU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWdu OnJpZ2h0Jz48aQ0NCiAgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDttc28t YmlkaS1mb250LWZhbWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+VGVjaG5pY2Fs IE9mZmljZXI6PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NDQogIDwvdGQ+DQ0KICA8dGQgd2lk dGg9NDAyIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjMwMS41cHQ7Ym9yZGVyOm5vbmU7Ym9yZGVy LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0Ow0NCiAgbXNvLWJvcmRlci10b3AtYWx0OnNv bGlkIHdpbmRvd3RleHQgLjVwdDttc28tYm9yZGVyLXRvcC1hbHQ6c29saWQgd2luZG93dGV4dCAu NXB0Ow0NCiAgbXNvLWJvcmRlci1ib3R0b20tYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDtwYWRk aW5nOjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxl ZnQgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQ7dGV4dC1hbGlnbjpsZWZ0Jz48c3Bhbg0NCiAgc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZv bnQtZmFtaWx5OkFyaWFsOw0NCiAgbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkFuZHJlYSA8c3Bh biBjbGFzcz1TcGVsbEU+bG9yZWxsaTwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQ0KICA8 L3RkPg0NCiA8L3RyPg0NCiA8dHIgc3R5bGU9J21zby15ZnRpLWlyb3c6NTttc28teWZ0aS1sYXN0 cm93Onllcyc+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjExMi41 cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOnJpZ2h0Jz48aQ0N CiAgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDttc28tYmlkaS1mb250LWZh bWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+ZS1tYWlsOjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxl PSd3aWR0aDozMDEuNXB0O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4 dCAxLjBwdDsNDQogIG1zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7bXNv LWJvcmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDsNDQogIG1zby1ib3JkZXItYm90 dG9tLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0 Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0eWxlPSdtYXJnaW4tdG9wOjEu MHB0O3RleHQtYWxpZ246bGVmdCc+PHNwYW4NDQogIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNv LWJpZGktZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1z by1hbnNpLWxhbmd1YWdlOkVOLVVTJz48YSBocmVmPSJtYWlsdG86QW5kcmVhLmxvcmVsbGlAZXRz aS5vcmciPkFuZHJlYS5sb3JlbGxpQGV0c2kub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N DQogIDwvdGQ+DQ0KIDwvdHI+DQ0KPC90YWJsZT4NDQoNDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi10b3A6MS4wcHQ7dGFiLXN0b3BzOjcwLjlwdCA5Ny41NXB0IDE2OC40NXB0IDIw My44NXB0IDIzMy45cHQgMjk3LjdwdCAzNTQuNHB0Jz48c3Bhbg0NCnN0eWxlPSdmb250LXNpemU6 OC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlh bDsNDQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0NCg0NCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0w IGNlbGxwYWRkaW5nPTANDQogc3R5bGU9J21hcmdpbi1sZWZ0OjE0LjRwdDtib3JkZXItY29sbGFw c2U6Y29sbGFwc2U7bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiA8dHIg c3R5bGU9J21zby15ZnRpLWlyb3c6MDttc28teWZ0aS1maXJzdHJvdzp5ZXMnPg0NCiAgPHRkIHdp ZHRoPTE1MCB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoxMTIuNXB0O3BhZGRpbmc6MGNtIDUuNHB0 IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0nbWFy Z2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOmxlZnQnPjxiDQ0KICBzdHlsZT0nbXNvLWJpZGktZm9u dC13ZWlnaHQ6bm9ybWFsJz48aSBzdHlsZT0nbXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwnPjxz cGFuDQ0KICBzdHlsZT0nbXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMnPlRvPC9zcGFuPjwvaT48L2I+PGkNDQogIHN0eWxlPSdtc28tYmlkaS1mb250LXN0 eWxlOm5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28tYmlkaS1mb250LXNp emU6DQ0KICAxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMnPjo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0NCiAgPC90ZD4NDQogIDx0ZCB3 aWR0aD00MDIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MzAxLjVwdDtib3JkZXI6bm9uZTtib3Jk ZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7DQ0KICBtc28tYm9yZGVyLWJvdHRvbS1h bHQ6c29saWQgd2luZG93dGV4dCAuNXB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCc+DQ0K ICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OS4wcHQ7DQ0KICBtc28tYmlkaS1mb250LXNpemU6MTAuMHB0O21zby1iaWRp LWZvbnQtZmFtaWx5OkFyaWFsO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQ0KICA8L3RkPg0NCiA8L3RyPg0NCiA8dHIgc3R5bGU9J21zby15ZnRp LWlyb3c6MSc+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjExMi41 cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOnJpZ2h0Jz48c3Bh bg0NCiAgY2xhc3M9U3BlbGxFPjxpIHN0eWxlPSdtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNDQogIDkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4w cHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6DQ0KICBFTi1V Uyc+T3JnYW5pc2F0aW9uPC9zcGFuPjwvaT48L3NwYW4+PGkgc3R5bGU9J21zby1iaWRpLWZvbnQt c3R5bGU6bm9ybWFsJz48c3Bhbg0NCiAgc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0NCiAgbXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMnPjo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0NCiAgPC90ZD4NDQog IDx0ZCB3aWR0aD00MDIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MzAxLjVwdDtib3JkZXI6bm9u ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7DQ0KICBtc28tYm9yZGVyLXRv cC1hbHQ6c29saWQgd2luZG93dGV4dCAuNXB0O21zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5k b3d0ZXh0IC41cHQ7DQ0KICBtc28tYm9yZGVyLWJvdHRvbS1hbHQ6c29saWQgd2luZG93dGV4dCAu NXB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi10b3A6MS4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7DQ0K ICBtc28tYmlkaS1mb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21z by1hbnNpLWxhbmd1YWdlOkVOLVVTJz5JVFUtVA0NCiAgU0cxNiBROCwgOSwgMTAvMTY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQ0KICA8L3RkPg0NCiA8L3RyPg0NCiA8dHIgc3R5bGU9J21zby15ZnRp LWlyb3c6Mic+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjExMi41 cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDttYXJnaW4tcmlnaHQ6NC41cHQ7DQ0K ICBtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 O3RleHQtYWxpZ246cmlnaHQnPjxpDQ0KICBzdHlsZT0nbXNvLWJpZGktZm9udC1zdHlsZTpub3Jt YWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0NCiAg MTAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Jz5Db250YWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdp ZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDozMDEuNXB0O2JvcmRlcjpub25lO2JvcmRl ci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDsNDQogIG1zby1ib3JkZXItdG9wLWFsdDpz b2xpZCB3aW5kb3d0ZXh0IC41cHQ7bXNvLWJvcmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQg LjVwdDsNDQogIG1zby1ib3JkZXItYm90dG9tLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7cGFk ZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLXRvcDoxLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDsNDQogIG1zby1i aWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMnPkNsYXVkZQ0NCiAgTGFtYmxpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N DQogIDwvdGQ+DQ0KIDwvdHI+DQ0KIDx0ciBzdHlsZT0nbXNvLXlmdGktaXJvdzozJz4NDQogIDx0 ZCB3aWR0aD0xNTAgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MTEyLjVwdDtwYWRkaW5nOjBjbSA1 LjRwdCAwY20gNS40cHQnPg0NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxl PSdtYXJnaW4tdG9wOjEuMHB0O3RleHQtYWxpZ246cmlnaHQnPjxpDQ0KICBzdHlsZT0nbXNvLWJp ZGktZm9udC1zdHlsZTpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOg0NCiAgMTAuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1h bnNpLWxhbmd1YWdlOkVOLVVTJz5lLW1haWw6PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NDQog IDwvdGQ+DQ0KICA8dGQgd2lkdGg9NDAyIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjMwMS41cHQ7 Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0Ow0NCiAgbXNv LWJvcmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDttc28tYm9yZGVyLXRvcC1hbHQ6 c29saWQgd2luZG93dGV4dCAuNXB0Ow0NCiAgbXNvLWJvcmRlci1ib3R0b20tYWx0OnNvbGlkIHdp bmRvd3RleHQgLjVwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQnPg0NCiAgPHAgY2xhc3M9 TXNvTm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQ7dGV4dC1hbGlnbjps ZWZ0Jz48c3Bhbg0NCiAgY2xhc3M9TXNvSHlwZXJsaW5rPjxzcGFuIHN0eWxlPSdtc28tYmlkaS1m b250LXNpemU6MTIuMHB0O21zby1hbnNpLWxhbmd1YWdlOg0NCiAgRU4tVVMnPjxhIGhyZWY9Im1h aWx0bzpjbGF1ZGUubGFtYmxpbkBvcmFuZ2UtZnRncm91cC5jb20iPmNsYXVkZS5sYW1ibGluQG9y YW5nZS1mdGdyb3VwLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuDQ0KICBzdHlsZT0nZm9udC1z aXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6 QXJpYWw7DQ0KICBtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PG86cD48L286cD48L3NwYW4+PC9w Pg0NCiAgPC90ZD4NDQogPC90cj4NDQogPHRyIHN0eWxlPSdtc28teWZ0aS1pcm93OjQnPg0NCiAg PHRkIHdpZHRoPTE1MCB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoxMTIuNXB0O3BhZGRpbmc6MGNt IDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5 bGU9J21hcmdpbi10b3A6MS4wcHQ7dGV4dC1hbGlnbjpyaWdodCc+PGkNDQogIHN0eWxlPSdtc28t YmlkaS1mb250LXN0eWxlOm5vcm1hbCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28t YmlkaS1mb250LXNpemU6DQ0KICAxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPlRlY2huaWNhbCBPZmZpY2VyOjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxlPSd3 aWR0aDozMDEuNXB0O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAx LjBwdDsNDQogIG1zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7bXNvLWJv cmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDsNDQogIG1zby1ib3JkZXItYm90dG9t LWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4N DQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0eWxlPSdtYXJnaW4tdG9wOjEuMHB0 O3RleHQtYWxpZ246bGVmdCc+PHNwYW4NDQogIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1zby1h bnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQ0KICA8L3Rk Pg0NCiA8L3RyPg0NCiA8dHIgc3R5bGU9J21zby15ZnRpLWlyb3c6NTttc28teWZ0aS1sYXN0cm93 Onllcyc+DQ0KICA8dGQgd2lkdGg9MTUwIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjExMi41cHQ7 cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGln bj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOnJpZ2h0Jz48aQ0NCiAg c3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDttc28tYmlkaS1mb250LWZhbWls eTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+ZS1tYWlsOjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQwMiB2YWxpZ249dG9wIHN0eWxlPSd3 aWR0aDozMDEuNXB0O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAx LjBwdDsNDQogIG1zby1ib3JkZXItdG9wLWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7bXNvLWJv cmRlci10b3AtYWx0OnNvbGlkIHdpbmRvd3RleHQgLjVwdDsNDQogIG1zby1ib3JkZXItYm90dG9t LWFsdDpzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4N DQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0eWxlPSdtYXJnaW4tdG9wOjEuMHB0 O3RleHQtYWxpZ246bGVmdCc+PHNwYW4NDQogIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1zby1h bnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQ0KICA8L3Rk Pg0NCiA8L3RyPg0NCjwvdGFibGU+DQ0KDQ0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tdG9wOjEuMHB0O3RhYi1zdG9wczo3MC45cHQgOTcuNTVwdCAxNjguNDVwdCAyMDMuODVwdCAy MzMuOXB0IDI5Ny43cHQgMzU0LjRwdCc+PHNwYW4NDQpzdHlsZT0nZm9udC1zaXplOjguMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7DQ0KbXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQ7dGFiLXN0b3BzOjcwLjlw dCA5Ny41NXB0IDE2OC40NXB0IDIwMy44NXB0IDIzMy45cHQgMjk3LjdwdCAzNTQuNHB0Jz48c3Bh bg0NCnN0eWxlPSdmb250LXNpemU6OC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDttc28t YmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0NCg0NCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBi b3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTANDQogc3R5bGU9J21hcmdpbi1sZWZ0 OjE5LjZwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRw dCAwY20gNS40cHQnPg0NCiA8dHIgc3R5bGU9J21zby15ZnRpLWlyb3c6MDttc28teWZ0aS1maXJz dHJvdzp5ZXM7bXNvLXJvdy1tYXJnaW4tcmlnaHQ6MzYuMHB0Jz4NDQogIDx0ZCB3aWR0aD0xNDMg dmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MTA3LjNwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40 cHQnPg0NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQgc3R5bGU9J21hcmdpbi10b3A6 MS4wcHQ7dGV4dC1hbGlnbjpsZWZ0Jz48Yg0NCiAgc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0 Om5vcm1hbCc+PGkgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3Bhbg0NCiAg c3R5bGU9J21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Jz5Gb3I6PC9zcGFuPjwvaT48L2I+PGINDQogIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpu b3JtYWwnPjxzcGFuIHN0eWxlPSdtc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNDQogIG1zby1h bnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0NCiAgPC90ZD4N DQogIDx0ZCBzdHlsZT0nbXNvLWNlbGwtc3BlY2lhbDpwbGFjZWhvbGRlcjtib3JkZXI6bm9uZTti b3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQnDQ0KICB3aWR0aD00OD48cCBjbGFz cz0nTXNvTm9ybWFsJz4mbmJzcDs8L3RkPg0NCiA8L3RyPg0NCiA8dHIgc3R5bGU9J21zby15ZnRp LWlyb3c6MSc+DQ0KICA8dGQgd2lkdGg9MTQzIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjEwNy4z cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1yaWdodCBzdHlsZT0nbWFyZ2luLXRvcDoxLjBwdDt0ZXh0LWFsaWduOnJpZ2h0Jz48aQ0N CiAgc3R5bGU9J21zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNDQogIDEwLjBwdDttc28tYmlkaS1mb250LWZh bWlseTpBcmlhbDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+QWN0aW9uOjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQ4IHZhbGlnbj10b3Agc3R5bGU9 J3dpZHRoOjM2LjBwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDsNDQogIGJvcmRlci10 b3A6bm9uZTttc28tYm9yZGVyLXRvcC1hbHQ6c29saWQgd2luZG93dGV4dCAuNzVwdDttc28tYm9y ZGVyLWFsdDoNDQogIHNvbGlkIHdpbmRvd3RleHQgLjc1cHQ7cGFkZGluZzowY20gNS40cHQgMGNt IDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J21hcmdp bi10b3A6MS4wcHQ7dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQ0KICBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJp YWw7DQ0KICBtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0NCiAgPC90ZD4NDQogPC90cj4NDQogPHRyIHN0eWxlPSdtc28teWZ0aS1pcm93OjI7bXNv LXlmdGktbGFzdHJvdzp5ZXMnPg0NCiAgPHRkIHdpZHRoPTE0MyB2YWxpZ249dG9wIHN0eWxlPSd3 aWR0aDoxMDcuM3B0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCc+DQ0KICA8cCBjbGFzcz1N c29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQ7dGV4dC1hbGlnbjpy aWdodCc+PGkNDQogIHN0eWxlPSdtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdDttc28tYmlkaS1mb250LXNpemU6DQ0KICAxMC4wcHQ7bXNvLWJp ZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkluZm9ybWF0aW9u OjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQ0KICA8L3RkPg0NCiAgPHRkIHdpZHRoPTQ4IHZh bGlnbj10b3Agc3R5bGU9J3dpZHRoOjM2LjBwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBw dDsNDQogIGJvcmRlci10b3A6bm9uZTttc28tYm9yZGVyLXRvcC1hbHQ6c29saWQgd2luZG93dGV4 dCAuNzVwdDttc28tYm9yZGVyLWFsdDoNDQogIHNvbGlkIHdpbmRvd3RleHQgLjc1cHQ7cGFkZGlu ZzowY20gNS40cHQgMGNtIDUuNHB0Jz4NDQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50 ZXIgc3R5bGU9J21hcmdpbi10b3A6MS4wcHQ7dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQ0KICBz dHlsZT0nZm9udC1zaXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGkt Zm9udC1mYW1pbHk6QXJpYWw7DQ0KICBtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+WDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NDQogIDwvdGQ+DQ0KIDwvdHI+DQ0KPC90YWJsZT4NDQoNDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1h bnNpLWxhbmd1YWdlOg0NCkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdtc28tYmlkaS1mb250LWZhbWlseTpBcmlh bDttc28tYW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0NCg0NCjxwIGNsYXNzPU1zb0JvZHlUZXh0MiBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O21z by1vdXRsaW5lLWxldmVsOjEnPjxzcGFuDQ0Kc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVT Jz5FVFNJIFRDIERFQ1Qgd291bGQgbGlrZSB0byB0aGFuayBJVFUtVCBTRzE2IGZvcg0NCmluZm9y bWluZyBhYm91dCB0aGUgcG9zc2libGUgc2V0IHVwIG9mIGEgbmV3IElFVEYgd29ya2luZyBncm91 cCB0aGF0IHdvdWxkIGJlDQ0KY2hhcnRlcmVkIHdpdGggdGhlIHB1cnBvc2Ugb2YgY29sbGVjdGlu ZyBleHBlcnRpc2Ugd2l0aGluIHRoZSBJRVRGIGluIG9yZGVyIHRvDQ0KcmV2aWV3IHRoZSBkZXNp Z24gb2Ygd2lkZWJhbmQgYXVkaW8gY29kZWNzIHNwZWNpZmljYWxseSBmb3IgdXNlIHdpdGggdGhl DQ0KSW50ZXJuZXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5 VGV4dDI+PHNwYW4gc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyIHN0eWxlPSd0ZXh0LWFs aWduOmp1c3RpZnknPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+SW4g cmVzcG9uc2UgdG8gdGhpcyBsaWFpc29uIEVUQ0kgVEMgREVDVCB3b3VsZCBsaWtlIHRvIGdpdmUg dGhlDQ0KZm9sbG93aW5nIGZlZWRiYWNrIGFib3V0IHRoZSB1c2Ugb2Ygd2lkZWJhbmQgY29kZWNz IHdpdGhpbiBpdHMgc3RhbmRhcmRzIGFuZA0NCnRoZSBjb3JyZXNwb25kaW5nIGRldmljZXMuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDI+PHNwYW4gc3R5 bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxz cGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+TmV3IEdlbmVyYXRpb24gREVD VCAoTkctREVDVCkgc3RhbmRhcmRzIChFVFNJIFRTIDEwMiA1MjctMSBhbmQgLTMpIGFyZQ0NCmlu dGVuZGVkIGZvciB3aWRlYmFuZCBhdWRpbyBlbmFibGVkIGRldmljZXMgdG8gYmUgY29ubmVjdGVk IG9uIFZvSVAgbmV0d29ya3MuDQ0KVGhlc2Ugc3RhbmRhcmRzIGFyZSBhbiBldm9sdXRpb24gb2Yg dGhlIERFQ1Qgd2VsbC1rbm93biBzdGFuZGFyZCBFTiAzMDAgMTc1IGluDQ0Kb3JkZXIgdG8gc3Vw cG9ydCB3aWRlYmFuZCBzcGVlY2ggY29tbXVuaWNhdGlvbnMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDI+PHNwYW4gc3R5bGU9J21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNv Qm9keVRleHQyIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxzcGFuIHN0eWxlPSdtc28tYW5z aS1sYW5ndWFnZToNDQpFTi1VUyc+VGhlc2Ugc3RhbmRhcmRzIGFsbG93IHRoZSBzdXBwb3J0IG9m IDIgd2lkZWJhbmQgY29kZWNzIChhZGRpdGlvbmFsbHkgdG8NDQpzb21lIHBvc3NpYmxlIG90aGVy IGNvZGVjcyB3aXRoIGRpZmZlcmVudCBhdWRpbyBiYW5kd2lkdGhzKTogPG86cD48L286cD48L3Nw YW4+PC9wPg0NCg0NCjxwIGNsYXNzPU1zb0JvZHlUZXh0Mj48c3BhbiBzdHlsZT0nbXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFz cz1Nc29Cb2R5VGV4dDIgc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0Og0NCmwxIGxldmVsMSBsZm8xO3RhYi1zdG9wczpsaXN0IDE4LjBwdCBsZWZ0 IDcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4NDQpzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6QXJpYWw7bXNvLWJpZGktZm9udC1m YW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6DQ0KRU4tVVMnPjxzcGFuIHN0eWxlPSdtc28t bGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQ0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5n dWFnZTpFTi1VUyc+bWFuZGF0b3J5DQ0Kc3VwcG9ydDogSVRVLVQgRy43MjIgYXQgNjQga2JpdC9z IGNvZGVjPG86cD48L286cD48L3NwYW4+PC9wPg0NCg0NCjxwIGNsYXNzPU1zb0JvZHlUZXh0MiBz dHlsZT0nbWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6DQ0K bDEgbGV2ZWwxIGxmbzE7dGFiLXN0b3BzOmxpc3QgMTguMHB0IGxlZnQgNzAuOXB0IDIzMy45cHQg Mjk3LjdwdCAzNTQuNHB0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bhbg0NCnN0eWxlPSdtc28t ZmFyZWFzdC1mb250LWZhbWlseTpBcmlhbDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDttc28t YW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNDQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz5vcHRp b25hbA0NCnN1cHBvcnQ6IElUVS1UIEcuNzI5LjEgY29kZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyIHN0eWxlPSdtYXJnaW4tbGVmdDo3MS4yNXB0Jz48 c3BhbiBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6DQ0KRU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDI+PHNwYW4gc3R5bGU9J21zby1h bnNpLWxhbmd1YWdlOkVOLVVTJz5HLjcyMiBjb2RlYyB3YXMNDQpjaG9zZW4gbWFpbmx5IGZvciB0 aGUgZm9sbG93aW5nIHJlYXNvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0NCg0NCjxwIGNsYXNz PU1zb0JvZHlUZXh0Mj48c3BhbiBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDIgc3R5bGU9 J21hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Og0NCmwyIGxl dmVsMSBsZm80O3RhYi1zdG9wczpsaXN0IDE4LjBwdCBsZWZ0IDcwLjlwdCAyMzMuOXB0IDI5Ny43 cHQgMzU0LjRwdCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NDQpzdHlsZT0nbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6QXJpYWw7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2kt bGFuZ3VhZ2U6DQ0KRU4tVVMnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQ0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+TG93DQ0KY29t cGxleGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDIg c3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Og0N CmwyIGxldmVsMSBsZm80O3RhYi1zdG9wczpsaXN0IDE4LjBwdCBsZWZ0IDcwLjlwdCAyMzMuOXB0 IDI5Ny43cHQgMzU0LjRwdCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NDQpzdHlsZT0nbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6QXJpYWw7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNv LWFuc2ktbGFuZ3VhZ2U6DQ0KRU4tVVMnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQ0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+R29v ZA0NCnF1YWxpdHkgZm9yIHNwZWVjaCBjb21tdW5pY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDIgc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Og0NCmwyIGxldmVsMSBsZm80O3RhYi1zdG9wczps aXN0IDE4LjBwdCBsZWZ0IDcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdCc+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4NDQpzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6QXJpYWw7 bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6DQ0KRU4tVVMnPjxz cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQ0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+U3RhbmRhcmRpemVkDQ0KZW5jb2RlciBhbmQgZGVj b2RlciB3aXRoIHRlc3QgdmVjdG9ycyAoaW1wbGVtZW50YXRpb25zIGVhc3kgdG8gdmVyaWZ5KSBl bnN1cmluZw0NCmludGVyb3BlcmFiaWxpdHkgYW5kIHF1YWxpdHkgdGhhbmtzIHRvIGJpdCBleGFj dCBpbXBsZW1lbnRhdGlvbiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNv Qm9keVRleHQyIHN0eWxlPSdtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDoNDQpsMiBsZXZlbDEgbGZvNDt0YWItc3RvcHM6bGlzdCAxOC4wcHQgbGVmdCA3MC45 cHQgMjMzLjlwdCAyOTcuN3B0IDM1NC40cHQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuDQ0K c3R5bGU9J21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkFyaWFsO21zby1iaWRpLWZvbnQtZmFtaWx5 OkFyaWFsO21zby1hbnNpLWxhbmd1YWdlOg0NCkVOLVVTJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6 SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0NCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVMnPlBhY2tldA0NCmxvc3MgY29uY2VhbG1lbnQgbWVjaGFuaXNtcyBhdmFpbGFibGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyIHN0eWxlPSdtYXJn aW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDoNDQpsMiBsZXZlbDEg bGZvNDt0YWItc3RvcHM6bGlzdCAxOC4wcHQgbGVmdCA3MC45cHQgMjMzLjlwdCAyOTcuN3B0IDM1 NC40cHQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuDQ0Kc3R5bGU9J21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkFyaWFsO21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1hbnNpLWxhbmd1 YWdlOg0NCkVOLVVTJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0NCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkxvdyBkZWxheQ0NCmFu ZCBzYW1wbGUgYmFzZWQgY29kZWMgYWxsb3dpbmcgYW55IDxzcGFuIGNsYXNzPVNwZWxsRT5wYWNr ZXRpc2F0aW9uPC9zcGFuPiBvbg0NClZvSVAvIGludGVybmV0IG5ldHdvcmtzPG86cD48L286cD48 L3NwYW4+PC9wPg0NCg0NCjxwIGNsYXNzPU1zb0JvZHlUZXh0Mj48c3BhbiBzdHlsZT0nbXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBj bGFzcz1Nc29Cb2R5VGV4dDIgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9 J21zby1hbnNpLWxhbmd1YWdlOg0NCkVOLVVTJz5UaGVzZSBjaG9pY2VzIGFyZSBjb25zaXN0ZW50 IHdpdGggdGhlIEVUU0kgcmVjb21tZW5kYXRpb25zIFRTIDE4MTAwNQ0NCmZyb20gVElTUEFOIChU ZWxlY29tbXVuaWNhdGlvbnMgYW5kIEludGVybmV0IGNvbnZlcmdlZCBTZXJ2aWNlcyBhbmQgUHJv dG9jb2xzDQ0KZm9yIEFkdmFuY2VkIE5ldHdvcmtpbmc7IFNlcnZpY2UgYW5kIENhcGFiaWxpdHkg UmVxdWlyZW1lbnRzKSBmb3IgTmV4dA0NCkdlbmVyYXRpb24gTmV0d29ya3MgYW5kIGRldmljZXMg d2hlcmUgZm9sbG93aW5nIHdpZGViYW5kIGNvZGVjcyBhcmUNDQpyZWNvbW1lbmRlZDogRy43MjIs IEcuNzIyLjIsIEcuNzI5LjEgYW5kIEVWUkMtV0IuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoN DQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDIgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4g c3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOg0NCkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3Rp ZnknPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+QWRkaXRpb25hbGx5 LCBFVFNJIFRDIERFQ1Qgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhhdCBtaWxsaW9ucyBvZg0N CmRldmljZXMgaW1wbGVtZW50aW5nIElUVS1UIEcuNzIyIGNvZGVjIHdlcmUgPHNwYW4gY2xhc3M9 R3JhbUU+bWFudWZhY3R1cmVkLDwvc3Bhbj4NDQpzb2xkIGluIHNldmVyYWwgY291bnRyaWVzIGFu ZCBhcmUgYXZhaWxhYmxlIHdvcmxkd2lkZSBub3cuIEluIHBhcnRpY3VsYXIgYQ0NCmNlcnRpZmlj YXRpb24gcHJvZ3JhbSBoYW5kbGVkIGJ5IERFQ1QgRm9ydW0gZXhpc3RzIGZvciBjb3JkbGVzcyBk ZXZpY2VzOiBuYW1lbHkNDQpERUNUIEZvcnVtknMgQ0FULTxzcGFuIGNsYXNzPVNwZWxsRT5pcTwv c3Bhbj4gMS4wIChhbmQgQ0FULTxzcGFuIGNsYXNzPVNwZWxsRT5pcTwvc3Bhbj4NDQoyLjAgdG8g Y29tZSkuIFRoaXMgZW1waGFzaXplcyBzdHJvbmdseSB0aGUgbmVlZCBmb3IgYmFja3dhcmRzIGNv bXBhdGliaWxpdHkgYW5kDQ0Ka2VlcGluZyBhIGhpZ2ggbGV2ZWwgb2Ygdm9pY2UgcXVhbGl0eSBh bmQgYXZvaWRpbmcgdHJhbnNjb2Rpbmcgd2l0aCBpdHMNDQppbmhlcmVudCBkZWNyZWFzZSBpbiB2 b2ljZSBxdWFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5 VGV4dDI+PHNwYW4gc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQ0KDQ0KPHAgY2xhc3M9TXNvQm9keVRleHQyPjxzcGFuIHN0eWxlPSdt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+QXMgYSBjb25jbHVzaW9uLA0NCkVUU0kgVEMgREVDVCB3 b3VsZCBsaWtlIHRvIGhpZ2hsaWdodCB0aGF0OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0K PHAgY2xhc3M9TXNvQm9keVRleHQyPjxzcGFuIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1V Uyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0NCg0NCjxwIGNsYXNzPU1zb0JvZHlUZXh0 MiBzdHlsZT0nbWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 DQ0KbDAgbGV2ZWwxIGxmbzI7dGFiLXN0b3BzOmxpc3QgMTguMHB0IGxlZnQgNzAuOXB0IDIzMy45 cHQgMjk3LjdwdCAzNTQuNHB0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bhbg0NCnN0eWxlPSdt c28tZmFyZWFzdC1mb250LWZhbWlseTpBcmlhbDttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtt c28tYW5zaS1sYW5ndWFnZToNDQpFTi1VUyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNDQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz5U aGUNDQptb3RpdmF0aW9uIGFuZCBiZW5lZml0cyByZWxhdGVkIHRvIHRoZSBjb2RlY3Mgc2VsZWN0 ZWQgYnkgVEMgREVDVCAoYW5kDQ0KZXNwZWNpYWxseSBHLjcyMikgZm9yIHVzYWdlIG92ZXIgSVAg YW5kIGludGVybmV0IHRocm91Z2ggREVDVCBpbnRlcmZhY2Ugc2hvdWxkDQ0KcHJvYmFibHkgYWxz byBiZSB2YWxpZCBmb3IgYW55IG90aGVyIHdpZGViYW5kIGNvbW11bmljYXRpb24gbmVlZHMgb3Zl ciBJUA0NCm5ldHdvcmtzIGFuZCB0aGUgaW50ZXJuZXQgYW5kIHNob3VsZCBiZSBleHBsaWNpdGx5 IGNvbnNpZGVyZWQgYnkgSUVURiBhbmQgb3RoZXINDQpTRE9zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDIgc3R5bGU9J21hcmdpbi1sZWZ0OjE4LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Og0NCmwwIGxldmVsMSBsZm8yO3RhYi1zdG9wczps aXN0IDE4LjBwdCBsZWZ0IDcwLjlwdCAyMzMuOXB0IDI5Ny43cHQgMzU0LjRwdCc+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4NDQpzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6QXJpYWw7 bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6DQ0KRU4tVVMnPjxz cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQ0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+VXNpbmcgdGhlDQ0Kc2FtZSBjb2RlY3MgaW5jcmVh c2VzIHRoZSBjaGFuY2VzIG9mIGludGVyb3BlcmFiaWxpdHksIGFsbG93cyB0byBpbnRlcmNvbm5l Y3QNDQpuZXR3b3JrcyBvciBkZXZpY2VzIHdpdGhvdXQgY29zdCBhZGRlcnMgYW5kIGF2b2lkcyB0 cmFuc2NvZGluZyBhbmQgaXRzIGluaGVyZW50DQ0KcXVhbGl0eSBkZWdyYWRhdGlvbjxzcGFuIGNs YXNzPUdyYW1FPi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1N c29Cb2R5VGV4dDIgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4N DQpzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPl9fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NDQoNDQo8cCBjbGFzcz1Nc29Cb2R5VGV4dDI+PHNwYW4gc3R5bGU9J21z by1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQ0KDQ0K PC9kaXY+DQ0KDQ0KPC9ib2R5Pg0NCg0NCjwvaHRtbD4NDQo= ------_=_NextPart_002_01CA0ADD.7C1FF600 Content-Type: application/pdf; name="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf" Content-Transfer-Encoding: base64 Content-Description: DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf Content-Disposition: inline; filename="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nOVcWY8ctxF+318xQB4yE3hazZtUXiw7sqBE8aW1E0AOgr202lja1bGynPz2 PKTYvIpkdc/sehU4iAzBLTbPOr+qYs+b1Tgwvhr9f+nh5NXBuHoEf88P3hzYQfg/0wv8fPJq9dnh wb1vzYqpwenV4fODcXDOSSan92ylxGDtyjg5wNtXB8/WDzdbPiitpFwfbtigGXRfPy2NjzfbcRDK ar5elcc/+EfOLWcizSCdXX8em7XhMNsW9jAKzte/8c2GGS7XojzazdYOXI5G+JkZF5qleY1ReV7l 0rRTa9lknMoyZf1c+fnvYV4mzHpEzQw9m41S+m+HfwykksMoC6mEjqSSmgORMqlgk4f/gAF2xcdq ABNxADfOD1BsUByPMGXE1uphdKNabbkYGMx7erB+knrN8YyPagCeceB0ZBowBTrLUan1gw3ng5DM JU650UwMZLCmdWz91QZWGp0y6y8RGVcbbmyiwOyBtBo4Whim3bVVYwctq72CHDAxSK4l7BVobZk1 uLGw+c/+aTRKOtT4Zct7Po4Mth/27lYOb0TYxDwNIgA0Ywwol7YBog/Sy9YXGxAEDjRx6+vNVg4g C0Cnl6X1DNaREgT3fnxtlRdRbgWQWgHDwlSjwVMdpUGo7V1quypDLssjzCmAjRJ4k3umHTFTZkRt eWuvJhFg2unShqZGQ9Aqb0EWOGeyDDkvQ44mmdFMyNLvFB91C9QUQiq8zjl5GrT6i9IhL4p6vi+v MwmofoiAz8mjffDmRjNuMf1PicWPJ9HhBkTNGpAVUMFnhdToaKfk0U4alnoLSC2T+70jTkNuliYa GgXG0TNAc680YgC1G4W3janxkBx1SWwO1mdm0NrKYgi2HJrgNCvPZm/APF3OicHUhFlgKJlFZyT0 QLuozQ8PD745cEatlHFAHTBLoNEruXp7dvB8D59nobWyYrZyedrayeAWs7zDdmijwAIF4/FFMR7h pKPW+SzQ+GpjrQsWiY0rVzbBTZzTwShZzXnfmzimR66zNbNhqAXWqBHc/rS907jhiTxMKgf0YYE+ CrDB3vSZ2RhjejqtFnlnX20kHBGE8623vYpLYZ2XBDkIcEXMG4r0eFkeL/yjcXqUIPJ6EFZYg7te h/OyYEpS16uNG0Y+SoOnSqTRsiWNBplyZrWdYNEkoQ/BKYDVUuAKnz4uS6zK46F/BBMuNSgLiHaE Mun1H1Lbw88nCwf+x67TpBbLZiA+bOvuiC+AUHylATLo6KfyFq9IKiMqItqeZIKj9/NUlEBFqRQm Y6YC5vlA0vNREo9/79rhWWnF06K5/vRyY2Ev0kncGcnHZZaP0/DeG5mX8b1hPXvAtNwdeyQH+KAF 2AkeuIM2uUUnerUBhKYcCM4ReYqX5bHjyrT3sN63j+LD231Avp2zX8yOgwVjI6z/37Tv82SW33dO 9rK4/WsCAr0tdnwor3+EQbCnCTap0vlio/B8p6kdzm8Gj1Y/3QCC4pZ5t7jV/lBuGoRhDeBZoGQF a7IrTWPiVkCIQPZT41WZxApR5AJEApzAaL1cMMbcSge52D+esqR4CA/AOKJzZ6jl6O5MGJ2DE680 15mpyLBFuWRCBHoA3GcMYAQoD3Pgq2g7fULZaSSrSFGzT3he2p5ji57UGC0/o/7zdskyaNeVXXqA dn5Kz3dGeqbVBmw5MyCrL7G3mZkhGZmXpM5eLNgbMY53bW9ArEb7q7Q31J6jsYHIzkX8cGueDR+B Z/D4KdiF0UrNwiBmrYxeCkgog1UJEhvEWAgWXd/0/qo4nhoQxRwCMjJgXbwwGA2o825sjI9TALYW 8nY2ho+8FUB4oWEzo4gv7N2h6FHeDEUrx7LzRCH41UYztgiYrSd0NXweMDPQQWFsA5jL1NsEGxmf jOfp/xrIfYzRbIK73wXI5oQ3DQwoq5VEr5HxfpohGyvra2wrc9dvUk9bXn9SdGFVHl1RC7oDKx3G rHf3yPdxLz4gbg2sdOwODaxgXoqVTrHgfwlv28FZyzBH87LIZKEF3pMW9AyzLJnKJ1hmk5y98oBL WqbWx9izJyddAex50ttgzu7Qt4HJ9Fbh1+jbFrE0KNQQzVDEm0qYCfsedcj6tADgDGERdI5YWEuU 4EuoFwDGccHMKuLp2PDpZushoAHKXBHo/IgA9OcN2hfckzqNeF4yegj5nxNzX3WHfE2cbD8kDn54 kirYn7ozJA7CxRGXWicJhO2c5C8E4gATfOj+fwLEO4J6IHDHpkF4mflopiGfDaK1UQOsmT+bGrv0 2oSopMypn7tDVIDfqnIRqC7864n/12+X4JURnlrS2RwrfIHhFZGvvL8RQRd9ASfNytwgFQ9p8BY2 EWwCiZdWFaSPhOxOoI8CwZNOLDCH8YkHOpmOuVaQXqLVsNzKPZyN7Yacg26d1hsFC61O4c5d8+11 AvwBOEoJbE7hPgKBiJZI92ciJVJrrimTQUOgBaAKMMq5Ctf8dQNIlDveR8py5IrgUWzlTtZ073tD q3BibOgemrmkOnetsGBqbRckpjbkJGTrL0AYwQyAV/RepZiBUIOJduDwd89SycfoqXgKLHUAnJ/m xsfFD3tvAc7JjQx3RYUi1KGvKRmduipVTYBGffBRhmGTyGRkkFGHRy459YdGIeTjgU3JIZ4Rna9x 0ci/FtrMvH+RhqMKZkZNZRU0+PEG8IAx2uTzgR58F05tlAGnA+jZ3wXA79H4p7n89ihX8lhaUROn QVCLwm6oZwX5nodapQT9knYVa5XUBChtWk1wTuwlA8UMNXt4d01K03U5xYsGWVYrvC58yFOX3G2d +T2u5Yaq/ZYBZ8v769EpenlViJpPQVEFtV2WQ+ZNfghSIkQtT3k7kxYJO9osOkIn12ynmwv+jsQ4 ilBzjaz1O4qJiQ9FIztOgxQXeZ5j9DySd4zU10gtJ/DgSr9y1yOaAYme1N4XDEMadtxGTEHX28DC h1xI13st2FG/QFykdoE270lLGRjUm3qNFkC7f91pF9rT66Dh4HvgRafhhOSvWrvYSvRSOOYZkGsx 6KpC6ogOdZG6LYpYnuPnIJbWqXJeigfVCqo6IKId4klyNIElvf2ptOBW/GmVd7LryO5/ga9VVLu/ JOej7PNp2cLEb2bASMjEb+jIAGUyZhvzICXQFCIPfCWjc4w1R5CuZ/r/VPQnFNtaaxZAAa37i7Q7 zabjDMksMlBZaCge7RDgRiG7vIq3EsedPaDqj2hShBFQxiYLU0YoFG2RHboqY/tszwnh69A0pbFX lRPkHINlEB6cJ0lBhPIkKb3D8RWTScchsGNs1Ot/bkDWjDGVcd8JR3LP94itvSm6me3EN52WcATS THTlrHc8lH25JNiBhgzYbU3XQTlLic9tonXRtoDFPfpGRgJLsvGXUbkite5dkZbM56tOHVCvM2Li XtsnN029R24amVY/Meofsop9BrIZcUUgaTRLsJPCVfgZBRh1MKLcRJqZvmjaLhiBtvp+G8LiaRAZ i7T3Dk6JQ6QE64/FdUXrLMzAtU46t8QNxaoDnDeGRIHpVX7ETua+IOQW9aQUNii6wrxq1JDKBNOT nnVqmCmGwNlRb6V+RAYuT3zzCIOkCBFhpH47zJIVg9aKYwfj55Wj5C0Aj7zGHrbzO70LvLHbWXId 3HT23/erFLhziqw3tJX6U/62GVFbiNQJtV5jt9kartOOBBTeoQ9BBeoUJN8hDktQF22mCgHyvoKm s8HqjLuruHVhh/thYwoZ/FTFvie98HZXnLKrCredsqsKG89xY/FUXxbprYBespIobI3JC8nr273d rpF3owLAHjWBj8Lyh5NN/hFc7m77ngb9sC7sQ2dLe2cMl7T29yA/bMj0y0eRfuHmDkQGHCW7tJzU q7qi9zkTNQYh175UkIWcE4xRqY0X7pvQVpcMGTF4hwkM/fAkIr2c4QFFUirN1KshBQ6pXfVe7ka5 unKNv0SnLdBA3xv0/hOJEYqqKr8UmYb90mKp+WKjcMwC7R7203To/TNKzba0CXgzTUc5wya8PCEQ beNq4mR0KJtfH+co74x4S3nUy+6Bcqwo/CAFIa3QT4tefu+/MmMsfJsSXyN1/RorZhpDByd09iwk fgE5T19jpTRBEkKEWbHHSFltWNN53CkqgN670JmgLm63vL1rU5hW2KXpXT+KE4RzrTAySkA22aeZ KKfjf50xnl7bZGwmTEmBkzrNGxiJtXmp8oJ9FasSLkhGzsohs/L6826pZHE+Xz5UMl4VVKSwIZLQ RQNGs5/KGmXXjPw5ei3KoLG4sh4dZmdk0oMiet06UUeZfiqFQWWKirSjmkRQaQhNRAGcLVfoVOlM RrT3ObcPUGaTUoqRma0XJEnJK0C+owU3gopU7ztBotJZLcxU8/kTAjDXuZ1Adyq1gxRt1kK26Zmm NPUxgqWtNIMamShDGj2v4n6E7tFHmIvVujQ/Kavtw24BTdPNWM20K07soJNpLSlN3B9Joa81O3k8 jZGfG8AnJkVsBXx0uvZYaUIM3o867p5iab6ubRDlbFAcvJC2RRzFH1ISx31Hql/3QQ0a0TN4vlCL fOoZuXyeY1H0aCxNcmrf1Hqd0QmcpUuqe1T2KiYiIabSZVTel4pGVp1xAHv4nrDIOyoQx4TkUCpQ nbhRKQ+oKRIg64MDs/utWXXapk921+lyCsIcEyUdAFFbrrXuZxKpcCCVxgAsRJWYvsmkcAqyXm1p e6f9ag/ZVQb7eyK6SjxUuYsEw1F+BTmnjFZ494CkkK6050ddzigJOUHxwTEWZzTZPcr3L7vy3iSf ZFDDpMO3CLepDUNeWkquCt8op9/rw5z5/MhikVmzWyzI20N50L5i4dID6sUIZleR8EKyI/XjJqqv gQ1zYTtUtO1fPLuNMN96h3VGOsADjjNDdFqZuifS+rWA5Oi4L66XzJZq6mO5LwJipFHav7y6b4Kb rv/Mw8E9ykDdjQEcex9FkCRBh3PxmUAXlzlEKC/vE4XVMA+RraZNwpPCPRLjLpZVkNd5XWiFnPbP db7quqT+EjeTf5vfIdKGq07UqPjqTTnJ+0Llyn7NbOaWokWVn/syH6UyOxU3hXQjy49MLcd0fobb BHW7+FAuwNLxV29sugjMsTqPmrXqX1PtduRiJk3YgsFLgqiLYJZm3K58eo1Tq/QovfAyAJ+9wtFD eNpwEdlEOnXR18LJm2dIrhO4MKq3QWgzOCjLWRFkxVszIMA9I3hK/tYAJU57pA/J/Z11sveu4LMq 0iMKn1cE63tKoitkMWwpZoQ7/ztFri23zMsvkRF4S1CYqn7mHxPisENRw7/Khy7d45nuqbZgTRAS PBUk+5zXRe0Z97Gr+1ak36S2eSOe10YqhNdETO5VrI+TSg6XBj2BkFwZthwxNvCfEoCf+/wbqaHN NchX8U4jAH7ButRm5XpvoXJNEqUdRNfGWVM6o53H19l5tOf1NCa+T6Bp8BJvDDFpJ0jtT0PVzhoB Q9+K7kg5pDAU+ehycXLxTvUl9ofVlRA019zVjjhHtlFHjVqq+N1sr7dIVASP7AyQ8cldgEXKBVdf 4+bXpLruyDlSwIv6wJdWDDrHU3uLLImefze9ZEQk0eY4d1eBBRYnOL3WjnZ2r7sDx7SC/zRK5Ht4 5apZKUzMXiffw4AsloSouPD7XNNFJCFrvvdIO9v4v/ls4nSPtUVtaACac7EfcTVysYYcfg8wGNFI +zY1kL9Lu23lRLnRp2qXY3X6GoETTYUkzbWrjEysuRRzNCaPvlRCGdytHjkojqMLGjNp57S53ZdB U88bXRpKgyjSoGLHcrkOnXtSTMuhR84LLGZydwd4eYtz95rS+5z7sulhahFOWKJQrAjKoeiZ+nUD dGI/yBj/jLeFSFt2+HW+DP0gP/nCdrzp1lQnIukwOMnhi6u+t0Q+qv9YJ8pwiWQmpnGBsx93H5BH vRNcesdLB6pVYch3NI68Pb/zIn9v2LBcxz3QKo2uJnUhfFzDMeZ/7qfTMwz64xpPy1Ufaqf4TmcE OO3FzpAgCz7Nfxlv0N3ynpjzOykehhJfKmjEWfwKRtbVzTD9HjffQscHeR95kz3ca0Ft/ZEXcbrq 5irlzeY/jKzd2cVGDs6Z6ec2WBOi/j7AYqeLpwscwRpZskpUyLnHfTd/nXD0P9Sxu1TtUSzTDn90 jZBoj41QFfyifM6XPqqeiXPzKt8Ww4SY8SbDymwz/GSUz9g3/JipJqKt7Ja21JMSjBKrNkFtHFM+ zN5xtTnkmMBCm3xF9iYJn2abmba/HI2J6jzL9iEJG309M2rmrHlqHXJaE2ncYhn/jCDGQsVi+bOV orpUcFHfqgtcm6/0/7o+3dgBUxcLMjdJxPd6uXDxma58zxX78sp9ue+TpYlADYciEAtFQ9QLzUx9 HRpmHh2AtSG6Vg8GMypdrKeGCY0k66n75gILDi+RIbKv6S6nLwgz/wmcWv8F9uyztEKvP8tDlj/0 iIdq47Dpd1W+OfgPAO2FqGVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0ODUwCmVuZG9iagoxMyAw IG9iago8PC9MZW5ndGggMTQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytWlmP 2zYQfvevMNCHSkWsiqeovKVNWqQI0Mt5aorCu3Z2t83au90jTX9Gf3GHEo8hOZK9RbMIIEjkcO75 ZujbZdswvmztn384v160y2/h/8XidmEaYf8NH/Dz+fXyq/Xiy5+6JVNNr5fr94u26fteMjl8Z0sl GmOWXS8b+Hq9+KV6Va94o7SSslrXrNEMllc/x5ev61XbCGU0r5bx8aV95NxwJjwF2Zvqa/dadxyo rYCHVnBefWZfd6zjshLx0dQr03DZdsJSZlxo5ul2nQp0Ve/JDm8jk46UYcpYWuH5t5EuE13VotcM PXe1UvrX9XejqmTTyqgqoZ2qpOagpKAqYHL9O2wwyx6rVhidqlbDKU63L2rRgO47XW2BaylBFVuQ tAUBhKyualXd17CasxbEuapXXdOCHrvq4Ffv4+qNf/chrkOPn2rWNaAgUz2DPQx8QiqrVi4a0bcM lGlZ4cqaBXzD9JyBld2715ELtMWvbDtrAEtSg9XQgpfxbSBvV9rPzPj9cBTe9LFm1gy9jFI+EKIF hcFWoeBRWXHVoLQ/gLCxZ1Q7tMofgFR6ID7fRJWGz5YoUvU9qY5DXBAYTlZafwLfb3rDwB/WW3AA 9P2SMGV5kIHAuYZHDto0emDsg/vv/ENh73APd/VK2yyQ8eu+vicdIih4Fxl7rJXlpxvOPQ9Ed+Q5 3ip2LWL5JhpTxZ1owa5gPwkCFd9fEOZDror88+3oiX2rqlW9kg1EN0iBFiAK39q8pBk3VRNpdf4o Xjwsa96Zpm2Fte/KG9iqVPHRyk5TSqDIRep1D2gVcGNEo7XB4RAW/ukkGPw72Ab2dDbz8ajtjkVX 2hfBhMy+IXhASn/ITwbd7QpBniXO6nmJLnHAhsfh60XNoqwkYtkK5z4S7xB/G3waIuUk1EaSAUv5 HFBlGtZByrrCPou9fYht8HjDlY/tTSQ/UlVMJnJ7ljakeik9bIhQ3KQFw4qLXp1lqVMlKbF0sgPi ZRBaSWevQPJjzOpX2JI0y0GhB0zBH9ckqcfvQTG8J7gNGYRSXJYrYpJ6iOePOir3+jMUxyrM4tsZ eSK+qSDNWEJxhzi0m6m8b5ccck8a9cEMgD/AVzeEKMGOF3OxgRIFondZ6Hcfgx0pMdTiUWih06rs yZ0Nh2jdIwyCPr+MgCABCc7F0hw9bpLVN1BeGiNU2yUe6wV8yAWEsoKODEb6K3iHVXOMZ6T/Ox9n LsZlB+dyH+PIlhQf6MzzMg+ihdsYpmSCSQqrJ1mWkMdEntkC/TzJ1p7kPpo+GJoqzSGbfKp5bxXS z5qUteKYTcWcTQUXhU0V09U/NeSoVnGNzZREqzOXtZIcTYb4iPDbcwRsrGLgWiXeIo8GYqqFJcy/ QwChJda9qyItKpbKHQgdv8gBOeLNITCKN34ibxMo2H+mIAvKFsER3tWRpaZmHMJbdxj9IVuHvIKC zaEdfyzQFY3sO0MixjIx3SGHdx75t/eEnQtYBvm69wGbBJI/lQx8KpmWyBMFwpDbxl41Kjmkh8si WNG6ffwYwq4EWGjD8bwDK6HhRgAAYTynINcmmV6hikzVxW2p7tJVcGajjDdV3M6iV0jolzutvVKh s0Yv72MD9Gkq2EdT49J8WtgRDWN4QP1g1nxguOMpufP6wQ1UPwR/6vho3yVixa8dC0AG81ou8EsH af2ZE43c4AG9QSQOqSgUbEGchOzyEE2YsDDOJ0LflFR3T2QWQiR6K5Ftxu7WNdCwQ/pwnrGI52B0 N9lKGgIRPTLh0NtoQRfvZBPqz8wgMt3lI+mzRUmYeZpZd1TmE6o5mxxa+JMn21DRkwSJzLubFGlP fnks1RujHGOW0dyy4b0Z7T1O2FbQSEFRN0mc/3dndXWSaeYgnqP6xh73+WL9BR7TJVUr6HMTXSC8 owroPtOx/Yhg9EOmW/sZw3/eRQpps+2jvhjiQdWlh3jUkCQZ4oUFbognu+44Pg+bUACcOsULe9Hn yWFeWEzDGCrcxtwbkETmHC6qL1wjLyDHhCRzORFEGRNDiikhCtryHOfnYdbMmXFet/KHRq8e3X1E rm8GR0TYdLB6D3jLRIBIZYVlAGUBviFVZbU4lgrEftKt0q1oGQko9CkbnxE4Z1/wnnXKiJUiDrkC VEolrKTXR+Lu5hmcgMf+/CSjlyrPs8CQ68rziJx75xxQgy+ESdKSKg1lL4ZEOs8Q7eCbFKLEFkm7 9AHJPjlNxFn/XM8XdoUOiSzJFJ9EK3tDONN50gnndyN2TLZiPbSdrablPTYEDieGfst1Qpq3Osel kL+UkEm9mgPwQ3SXw1fk80GeiznnQy6HYSTVLoQ9ryNfP/hsn8R3Gf5bIj4SXHZPWA/NVMd1dnq0 I3YkMVl2U1SX9hC1Q0HtxGVPHlPQNxATonmWkhH7CGfA6dpw/UNMaMpYb3sd2Z+spoqMFno0WE6H g0OhxHwsRDKARQz6k/RSdrjoc8SEBGzbkluOtsDTRUnztF0v6NCAnQ6d9PJnNC+O9BPG5aUZjpTP iekMbAEUkNz/lBcbJ8+cS1YQB/tcLUn85gODDC//L4nJBuscQyl2oW84/DloEoJ7L8qDZpLevRs4 qUYwFsGjXWivfnbElqckE1pCKlEeydIEmEBejjJMEomnwjgkHTFnT25/nSt61Wdd8ET+gXhz055R z8cuWvMG33dVJQqj71VPAkvD0IPyVaojQ4PuU32sBKPTo0UbiXQMhVYQgbXvR6AjoblEChpAD+u1 8Xeb1kgty9RNtyNvI/FM5dTMZLa6z1TFJHdRk+kj6XL2/p1OW4kI56EtLboOa4B8TpIM2WjyT+wp 7G7qNyP5kGHq9xmlSyXjw0zqMbPpphXUb1coWBfI3pQZMBnElWXwKqL0qcENpAJ6BEJB/aRtjZWA 1MY9WaYKfVATAUo8Ypa4Lx6IruWeFK7ckZS4cuZS1rhepYLnv11peRLiR5qT6R8J2ZI+NWRO734I /qeHpiX+pUsgFfLoWFq9wXeoX+M57kWi1CPzwNlUXoy8iRE9efNC+SodUU8ebhM9CjnoLjR2tBuc GG+jsMoH60cm3KWQtCfcxpVPmw2n3U7pCUl/SV0tbEPio0H25M/10MihKeeEsgNQhK60w5gQTa1f rRc/wt+/gaQUjmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMjM1MwplbmRvYmoKNCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDExIDAgUgo+PgovQ29udGVu dHMgNSAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0ZvbnQgMTUgMCBSCj4+Ci9Db250ZW50cyAxMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTIgMCBSCl0gL0NvdW50IDIKL1JvdGF0ZSAw Pj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRh IDE3IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvUjEwCjEwIDAgUi9SNwo3IDAgUi9SOAo4IDAg Ui9SOQo5IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9i agoxMCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5 cGUvVHlwZTE+PgplbmRvYmoKNyAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtQm9sZC9UeXBl L0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRp Y2EvVHlwZS9Gb250Ci9FbmNvZGluZyAxNiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxNiAw IG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxNDYvcXVvdGVyaWdodAoyNTIvdWRp ZXJlc2lzXT4+CmVuZG9iago5IDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1 ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE2 MDk+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3 b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8y Mi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+ CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1 ZmY0MmQ0YWYnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlBy b2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQgOC41NCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0nYzI1ZjFmMzMtNzkyOS0xMWRlLTAwMDAtN2RiNWZmNDJkNGFmJyB4bWxuczp4YXA9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpNb2RpZnlEYXRlPScyMDA5LTA3LTIyJyB4YXA6 Q3JlYXRlRGF0ZT0nMjAwOS0wNy0yMic+PHhhcDpDcmVhdG9yVG9vbD5HUEwgR2hvc3RzY3JpcHQg OC41NCBQREYgV3JpdGVyPC94YXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0 YWYnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpE b2N1bWVudElEPSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYnLz4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2MyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZicgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9 J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gt ZGVmYXVsdCc+XDM3NlwzNzdcMDAwRFwwMDBFXDAwMENcMDAwVFwwMDAzXDAwMDhcMDAwX1wwMDAw XDAwMDFcMDAwN1wwMDByXDAwMDFcMDAwX1wwMDBMXDAwMGlcMDAwYVwwMDBpXDAwMHNcMDAwb1ww MDBuXDAwMF9cMDAwdFwwMDBvXDAwMF9cMDAwSVwwMDBUXDAwMFVcMDAwX1wwMDBTXDAwMEdcMDAw MVwwMDA2XDAwMF9cMDAwb1wwMDBuXDAwMF9cMDAwY1wwMDBvXDAwMGRcMDAwZVwwMDBjXDAwMHNc MDAwLVwwMDBjXDAwMGxcMDAwZVwwMDBhXDAwMG48L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRs ZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPlwzNzZcMzc3XDAwMGNcMDAwYVwwMDBtXDAw MHBcMDAwb1wwMDBzPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlw dGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9k dWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkKL0NyZWF0aW9uRGF0ZShEOjIwMDkwNzIyMTY0NDU4 KzAyJzAwJykKL01vZERhdGUoRDoyMDA5MDcyMjE2NDQ1OCkKL1RpdGxlKFwzNzZcMzc3XDAwMERc MDAwRVwwMDBDXDAwMFRcMDAwM1wwMDA4XDAwMF9cMDAwMFwwMDAxXDAwMDdcMDAwclwwMDAxXDAw MF9cMDAwTFwwMDBpXDAwMGFcMDAwaVwwMDBzXDAwMG9cMDAwblwwMDBfXDAwMHRcMDAwb1wwMDBf XDAwMElcMDAwVFwwMDBVXDAwMF9cMDAwU1wwMDBHXDAwMDFcMDAwNlwwMDBfXDAwMG9cMDAwblww MDBfXDAwMGNcMDAwb1wwMDBkXDAwMGVcMDAwY1wwMDBzXDAwMC1cMDAwY1wwMDBsXDAwMGVcMDAw YVwwMDBuKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAwMHJcMDAwZVww MDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBpXDAwMG9cMDAw blwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3N1wwMDBjXDAw MGFcMDAwbVwwMDBwXDAwMG9cMDAwcykKL0tleXdvcmRzKCkKL1N1YmplY3QoKT4+ZW5kb2JqCnhy ZWYKMCAxOAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDc3NjIgMDAwMDAgbiAKMDAwMDAwOTk2 MCAwMDAwMCBuIAowMDAwMDA3Njg3IDAwMDAwIG4gCjAwMDAwMDc0MDEgMDAwMDAgbiAKMDAwMDAw MDAxNSAwMDAwMCBuIAowMDAwMDA0OTM1IDAwMDAwIG4gCjAwMDAwMDc5OTggMDAwMDAgbiAKMDAw MDAwODA2NyAwMDAwMCBuIAowMDAwMDA4MjI1IDAwMDAwIG4gCjAwMDAwMDc5MjUgMDAwMDAgbiAK MDAwMDAwNzgyNyAwMDAwMCBuIAowMDAwMDA3NTQzIDAwMDAwIG4gCjAwMDAwMDQ5NTUgMDAwMDAg biAKMDAwMDAwNzM4MCAwMDAwMCBuIAowMDAwMDA3ODg2IDAwMDAwIG4gCjAwMDAwMDgxNDcgMDAw MDAgbiAKMDAwMDAwODMwMSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE4IC9Sb290IDEgMCBS IC9JbmZvIDIgMCBSCi9JRCBbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjxGQjBB MEZDOUI3QjlBMTQyQ0JFNTY5OEVEMTk2ODJFNT5dCj4+CnN0YXJ0eHJlZgoxMDU0MwolJUVPRgox IDAgb2JqPDwvTWV0YWRhdGEgMTkgMCBSL1BhZ2VzIDMgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9i ag0yIDAgb2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwOTA3MjIxNjQ0NTgrMDInMDAnKS9TdWJqZWN0 KCkvQXV0aG9yKP7/AGMAYQBtAHAAbwBzKS9DcmVhdG9yKP7/AFAARABGAEMAcgBlAGEAdABvAHIA IABWAGUAcgBzAGkAbwBuACAAMAAuADkALgAzKS9LZXl3b3JkcygpL1Byb2R1Y2VyKEdQTCBHaG9z dHNjcmlwdCA4LjU0KS9Nb2REYXRlKEQ6MjAwOTA3MjIxNjQ0NTgpL1RpdGxlKERFQ1QzOF8wMTdy MV9MaWFpc29uX3RvX0lUVV9TRzE2X29uX2NvZGVjcyk+Pg1lbmRvYmoNMTggMCBvYmo8PC9DcmVh dGlvbkRhdGUoRDoyMDA5MDcyMjE2NDQ1OCswMicwMCcpL1N1YmplY3QoKS9DcmVhdG9yKFBERkNy ZWF0b3IgVmVyc2lvbiAwLjkuMykvS2V5d29yZHMoKS9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQg OC41NCkvTW9kRGF0ZShEOjIwMDkwNzIyMTY0NjA5KzAyJzAwJykvVGl0bGUoREVDVDM4XzAxN3Ix X0xpYWlzb25fdG9fSVRVX1NHMTZfb25fY29kZWNzKT4+DWVuZG9iag0xOSAwIG9iajw8L1N1YnR5 cGUvWE1ML0xlbmd0aCAzODU1L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2lu PSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMiI+CiAgIDxyZGY6UkRGIHhtbG5zOnJk Zj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0 MmQ0YWYiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z LyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+R1BMIEdob3N0c2NyaXB0IDguNTQ8L3BkZjpQcm9k dWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRm OmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYiCiAgICAgICAgICAg IHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6 TW9kaWZ5RGF0ZT4yMDA5LTA3LTIyVDE2OjQ2OjA5KzAyOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAg ICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDktMDctMjJUMTY6NDQ6NTgrMDI6MDA8L3hhcDpDcmVh dGVEYXRlPgogICAgICAgICA8eGFwOkNyZWF0b3JUb29sPlBERkNyZWF0b3IgVmVyc2lvbiAwLjku MzwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDA5LTA3LTIy VDE2OjQ2OjA5KzAyOjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0w MDAwLTdkYjVmZjQyZDRhZiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD5jMjVmMWYzMy03 OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWY8L3hhcE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4 YXBNTTpJbnN0YW5jZUlEPnV1aWQ6NTQwYWU3YzctZWQ2My00OTM1LWFkN2QtOTM4ZWQwOGUxYmYz PC94YXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv Ij4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAg ICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjps aSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5ERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9v bl9jb2RlY3M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRp dGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAg ICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6ZGVzY3Jp cHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDps YW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOmRl c2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1w bWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDXhyZWYNCjEgMg0KMDAwMDAx MTA1NyAwMDAwMCBuDQowMDAwMDExMTE3IDAwMDAwIG4NCjE4IDINCjAwMDAwMTEzODUgMDAwMDAg bg0KMDAwMDAxMTYxMiAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDIwL1Jvb3QgMSAwIFIvSW5m byAxOCAwIFIvSURbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjwwMDk4NkIwNUUw MTM1QjQ1OUFCRDk0NzYwRjdFNzAxRj5dL1ByZXYgMTA1NDMgPj4NCnN0YXJ0eHJlZg0KMTU1NDQN CiUlRU9GDQo= ------_=_NextPart_002_01CA0ADD.7C1FF600 Content-Type: text/plain; name="ATT19709247.txt" Content-Transfer-Encoding: base64 Content-Description: ATT19709247.txt Content-Disposition: attachment; filename="ATT19709247.txt" DQo= ------_=_NextPart_002_01CA0ADD.7C1FF600 Content-Type: text/plain; name="ATT19709248.txt" Content-Transfer-Encoding: base64 Content-Description: ATT19709248.txt Content-Disposition: attachment; filename="ATT19709248.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvZGVjIG1h aWxpbmcgbGlzdA0KY29kZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29kZWMNCg== ------_=_NextPart_002_01CA0ADD.7C1FF600-- ------_=_NextPart_001_01CA10EB.51B9E8C2 Content-Type: application/octet-stream; name="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf" Content-Transfer-Encoding: base64 Content-Description: DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf Content-Disposition: attachment; filename="DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nOVcWY8ctxF+318xQB4yE3hazZtUXiw7sqBE8aW1E0AOgr202lja1bGynPz2 PKTYvIpkdc/sehU4iAzBLTbPOr+qYs+b1Tgwvhr9f+nh5NXBuHoEf88P3hzYQfg/0wv8fPJq9dnh wb1vzYqpwenV4fODcXDOSSan92ylxGDtyjg5wNtXB8/WDzdbPiitpFwfbtigGXRfPy2NjzfbcRDK ar5elcc/+EfOLWcizSCdXX8em7XhMNsW9jAKzte/8c2GGS7XojzazdYOXI5G+JkZF5qleY1ReV7l 0rRTa9lknMoyZf1c+fnvYV4mzHpEzQw9m41S+m+HfwykksMoC6mEjqSSmgORMqlgk4f/gAF2xcdq ABNxADfOD1BsUByPMGXE1uphdKNabbkYGMx7erB+knrN8YyPagCeceB0ZBowBTrLUan1gw3ng5DM JU650UwMZLCmdWz91QZWGp0y6y8RGVcbbmyiwOyBtBo4Whim3bVVYwctq72CHDAxSK4l7BVobZk1 uLGw+c/+aTRKOtT4Zct7Po4Mth/27lYOb0TYxDwNIgA0Ywwol7YBog/Sy9YXGxAEDjRx6+vNVg4g C0Cnl6X1DNaREgT3fnxtlRdRbgWQWgHDwlSjwVMdpUGo7V1quypDLssjzCmAjRJ4k3umHTFTZkRt eWuvJhFg2unShqZGQ9Aqb0EWOGeyDDkvQ44mmdFMyNLvFB91C9QUQiq8zjl5GrT6i9IhL4p6vi+v MwmofoiAz8mjffDmRjNuMf1PicWPJ9HhBkTNGpAVUMFnhdToaKfk0U4alnoLSC2T+70jTkNuliYa GgXG0TNAc680YgC1G4W3janxkBx1SWwO1mdm0NrKYgi2HJrgNCvPZm/APF3OicHUhFlgKJlFZyT0 QLuozQ8PD745cEatlHFAHTBLoNEruXp7dvB8D59nobWyYrZyedrayeAWs7zDdmijwAIF4/FFMR7h pKPW+SzQ+GpjrQsWiY0rVzbBTZzTwShZzXnfmzimR66zNbNhqAXWqBHc/rS907jhiTxMKgf0YYE+ CrDB3vSZ2RhjejqtFnlnX20kHBGE8623vYpLYZ2XBDkIcEXMG4r0eFkeL/yjcXqUIPJ6EFZYg7te h/OyYEpS16uNG0Y+SoOnSqTRsiWNBplyZrWdYNEkoQ/BKYDVUuAKnz4uS6zK46F/BBMuNSgLiHaE Mun1H1Lbw88nCwf+x67TpBbLZiA+bOvuiC+AUHylATLo6KfyFq9IKiMqItqeZIKj9/NUlEBFqRQm Y6YC5vlA0vNREo9/79rhWWnF06K5/vRyY2Ev0kncGcnHZZaP0/DeG5mX8b1hPXvAtNwdeyQH+KAF 2AkeuIM2uUUnerUBhKYcCM4ReYqX5bHjyrT3sN63j+LD231Avp2zX8yOgwVjI6z/37Tv82SW33dO 9rK4/WsCAr0tdnwor3+EQbCnCTap0vlio/B8p6kdzm8Gj1Y/3QCC4pZ5t7jV/lBuGoRhDeBZoGQF a7IrTWPiVkCIQPZT41WZxApR5AJEApzAaL1cMMbcSge52D+esqR4CA/AOKJzZ6jl6O5MGJ2DE680 15mpyLBFuWRCBHoA3GcMYAQoD3Pgq2g7fULZaSSrSFGzT3he2p5ji57UGC0/o/7zdskyaNeVXXqA dn5Kz3dGeqbVBmw5MyCrL7G3mZkhGZmXpM5eLNgbMY53bW9ArEb7q7Q31J6jsYHIzkX8cGueDR+B Z/D4KdiF0UrNwiBmrYxeCkgog1UJEhvEWAgWXd/0/qo4nhoQxRwCMjJgXbwwGA2o825sjI9TALYW 8nY2ho+8FUB4oWEzo4gv7N2h6FHeDEUrx7LzRCH41UYztgiYrSd0NXweMDPQQWFsA5jL1NsEGxmf jOfp/xrIfYzRbIK73wXI5oQ3DQwoq5VEr5HxfpohGyvra2wrc9dvUk9bXn9SdGFVHl1RC7oDKx3G rHf3yPdxLz4gbg2sdOwODaxgXoqVTrHgfwlv28FZyzBH87LIZKEF3pMW9AyzLJnKJ1hmk5y98oBL WqbWx9izJyddAex50ttgzu7Qt4HJ9Fbh1+jbFrE0KNQQzVDEm0qYCfsedcj6tADgDGERdI5YWEuU 4EuoFwDGccHMKuLp2PDpZushoAHKXBHo/IgA9OcN2hfckzqNeF4yegj5nxNzX3WHfE2cbD8kDn54 kirYn7ozJA7CxRGXWicJhO2c5C8E4gATfOj+fwLEO4J6IHDHpkF4mflopiGfDaK1UQOsmT+bGrv0 2oSopMypn7tDVIDfqnIRqC7864n/12+X4JURnlrS2RwrfIHhFZGvvL8RQRd9ASfNytwgFQ9p8BY2 EWwCiZdWFaSPhOxOoI8CwZNOLDCH8YkHOpmOuVaQXqLVsNzKPZyN7Yacg26d1hsFC61O4c5d8+11 AvwBOEoJbE7hPgKBiJZI92ciJVJrrimTQUOgBaAKMMq5Ctf8dQNIlDveR8py5IrgUWzlTtZ073tD q3BibOgemrmkOnetsGBqbRckpjbkJGTrL0AYwQyAV/RepZiBUIOJduDwd89SycfoqXgKLHUAnJ/m xsfFD3tvAc7JjQx3RYUi1KGvKRmduipVTYBGffBRhmGTyGRkkFGHRy459YdGIeTjgU3JIZ4Rna9x 0ci/FtrMvH+RhqMKZkZNZRU0+PEG8IAx2uTzgR58F05tlAGnA+jZ3wXA79H4p7n89ihX8lhaUROn QVCLwm6oZwX5nodapQT9knYVa5XUBChtWk1wTuwlA8UMNXt4d01K03U5xYsGWVYrvC58yFOX3G2d +T2u5Yaq/ZYBZ8v769EpenlViJpPQVEFtV2WQ+ZNfghSIkQtT3k7kxYJO9osOkIn12ynmwv+jsQ4 ilBzjaz1O4qJiQ9FIztOgxQXeZ5j9DySd4zU10gtJ/DgSr9y1yOaAYme1N4XDEMadtxGTEHX28DC h1xI13st2FG/QFykdoE270lLGRjUm3qNFkC7f91pF9rT66Dh4HvgRafhhOSvWrvYSvRSOOYZkGsx 6KpC6ogOdZG6LYpYnuPnIJbWqXJeigfVCqo6IKId4klyNIElvf2ptOBW/GmVd7LryO5/ga9VVLu/ JOej7PNp2cLEb2bASMjEb+jIAGUyZhvzICXQFCIPfCWjc4w1R5CuZ/r/VPQnFNtaaxZAAa37i7Q7 zabjDMksMlBZaCge7RDgRiG7vIq3EsedPaDqj2hShBFQxiYLU0YoFG2RHboqY/tszwnh69A0pbFX lRPkHINlEB6cJ0lBhPIkKb3D8RWTScchsGNs1Ot/bkDWjDGVcd8JR3LP94itvSm6me3EN52WcATS THTlrHc8lH25JNiBhgzYbU3XQTlLic9tonXRtoDFPfpGRgJLsvGXUbkite5dkZbM56tOHVCvM2Li XtsnN029R24amVY/Meofsop9BrIZcUUgaTRLsJPCVfgZBRh1MKLcRJqZvmjaLhiBtvp+G8LiaRAZ i7T3Dk6JQ6QE64/FdUXrLMzAtU46t8QNxaoDnDeGRIHpVX7ETua+IOQW9aQUNii6wrxq1JDKBNOT nnVqmCmGwNlRb6V+RAYuT3zzCIOkCBFhpH47zJIVg9aKYwfj55Wj5C0Aj7zGHrbzO70LvLHbWXId 3HT23/erFLhziqw3tJX6U/62GVFbiNQJtV5jt9kartOOBBTeoQ9BBeoUJN8hDktQF22mCgHyvoKm s8HqjLuruHVhh/thYwoZ/FTFvie98HZXnLKrCredsqsKG89xY/FUXxbprYBespIobI3JC8nr273d rpF3owLAHjWBj8Lyh5NN/hFc7m77ngb9sC7sQ2dLe2cMl7T29yA/bMj0y0eRfuHmDkQGHCW7tJzU q7qi9zkTNQYh175UkIWcE4xRqY0X7pvQVpcMGTF4hwkM/fAkIr2c4QFFUirN1KshBQ6pXfVe7ka5 unKNv0SnLdBA3xv0/hOJEYqqKr8UmYb90mKp+WKjcMwC7R7203To/TNKzba0CXgzTUc5wya8PCEQ beNq4mR0KJtfH+co74x4S3nUy+6Bcqwo/CAFIa3QT4tefu+/MmMsfJsSXyN1/RorZhpDByd09iwk fgE5T19jpTRBEkKEWbHHSFltWNN53CkqgN670JmgLm63vL1rU5hW2KXpXT+KE4RzrTAySkA22aeZ KKfjf50xnl7bZGwmTEmBkzrNGxiJtXmp8oJ9FasSLkhGzsohs/L6826pZHE+Xz5UMl4VVKSwIZLQ RQNGs5/KGmXXjPw5ei3KoLG4sh4dZmdk0oMiet06UUeZfiqFQWWKirSjmkRQaQhNRAGcLVfoVOlM RrT3ObcPUGaTUoqRma0XJEnJK0C+owU3gopU7ztBotJZLcxU8/kTAjDXuZ1Adyq1gxRt1kK26Zmm NPUxgqWtNIMamShDGj2v4n6E7tFHmIvVujQ/Kavtw24BTdPNWM20K07soJNpLSlN3B9Joa81O3k8 jZGfG8AnJkVsBXx0uvZYaUIM3o867p5iab6ubRDlbFAcvJC2RRzFH1ISx31Hql/3QQ0a0TN4vlCL fOoZuXyeY1H0aCxNcmrf1Hqd0QmcpUuqe1T2KiYiIabSZVTel4pGVp1xAHv4nrDIOyoQx4TkUCpQ nbhRKQ+oKRIg64MDs/utWXXapk921+lyCsIcEyUdAFFbrrXuZxKpcCCVxgAsRJWYvsmkcAqyXm1p e6f9ag/ZVQb7eyK6SjxUuYsEw1F+BTmnjFZ494CkkK6050ddzigJOUHxwTEWZzTZPcr3L7vy3iSf ZFDDpMO3CLepDUNeWkquCt8op9/rw5z5/MhikVmzWyzI20N50L5i4dID6sUIZleR8EKyI/XjJqqv gQ1zYTtUtO1fPLuNMN96h3VGOsADjjNDdFqZuifS+rWA5Oi4L66XzJZq6mO5LwJipFHav7y6b4Kb rv/Mw8E9ykDdjQEcex9FkCRBh3PxmUAXlzlEKC/vE4XVMA+RraZNwpPCPRLjLpZVkNd5XWiFnPbP db7quqT+EjeTf5vfIdKGq07UqPjqTTnJ+0Llyn7NbOaWokWVn/syH6UyOxU3hXQjy49MLcd0fobb BHW7+FAuwNLxV29sugjMsTqPmrXqX1PtduRiJk3YgsFLgqiLYJZm3K58eo1Tq/QovfAyAJ+9wtFD eNpwEdlEOnXR18LJm2dIrhO4MKq3QWgzOCjLWRFkxVszIMA9I3hK/tYAJU57pA/J/Z11sveu4LMq 0iMKn1cE63tKoitkMWwpZoQ7/ztFri23zMsvkRF4S1CYqn7mHxPisENRw7/Khy7d45nuqbZgTRAS PBUk+5zXRe0Z97Gr+1ak36S2eSOe10YqhNdETO5VrI+TSg6XBj2BkFwZthwxNvCfEoCf+/wbqaHN NchX8U4jAH7ButRm5XpvoXJNEqUdRNfGWVM6o53H19l5tOf1NCa+T6Bp8BJvDDFpJ0jtT0PVzhoB Q9+K7kg5pDAU+ehycXLxTvUl9ofVlRA019zVjjhHtlFHjVqq+N1sr7dIVASP7AyQ8cldgEXKBVdf 4+bXpLruyDlSwIv6wJdWDDrHU3uLLImefze9ZEQk0eY4d1eBBRYnOL3WjnZ2r7sDx7SC/zRK5Ht4 5apZKUzMXiffw4AsloSouPD7XNNFJCFrvvdIO9v4v/ls4nSPtUVtaACac7EfcTVysYYcfg8wGNFI +zY1kL9Lu23lRLnRp2qXY3X6GoETTYUkzbWrjEysuRRzNCaPvlRCGdytHjkojqMLGjNp57S53ZdB U88bXRpKgyjSoGLHcrkOnXtSTMuhR84LLGZydwd4eYtz95rS+5z7sulhahFOWKJQrAjKoeiZ+nUD dGI/yBj/jLeFSFt2+HW+DP0gP/nCdrzp1lQnIukwOMnhi6u+t0Q+qv9YJ8pwiWQmpnGBsx93H5BH vRNcesdLB6pVYch3NI68Pb/zIn9v2LBcxz3QKo2uJnUhfFzDMeZ/7qfTMwz64xpPy1Ufaqf4TmcE OO3FzpAgCz7Nfxlv0N3ynpjzOykehhJfKmjEWfwKRtbVzTD9HjffQscHeR95kz3ca0Ft/ZEXcbrq 5irlzeY/jKzd2cVGDs6Z6ec2WBOi/j7AYqeLpwscwRpZskpUyLnHfTd/nXD0P9Sxu1TtUSzTDn90 jZBoj41QFfyifM6XPqqeiXPzKt8Ww4SY8SbDymwz/GSUz9g3/JipJqKt7Ja21JMSjBKrNkFtHFM+ zN5xtTnkmMBCm3xF9iYJn2abmba/HI2J6jzL9iEJG309M2rmrHlqHXJaE2ncYhn/jCDGQsVi+bOV orpUcFHfqgtcm6/0/7o+3dgBUxcLMjdJxPd6uXDxma58zxX78sp9ue+TpYlADYciEAtFQ9QLzUx9 HRpmHh2AtSG6Vg8GMypdrKeGCY0k66n75gILDi+RIbKv6S6nLwgz/wmcWv8F9uyztEKvP8tDlj/0 iIdq47Dpd1W+OfgPAO2FqGVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0ODUwCmVuZG9iagoxMyAw IG9iago8PC9MZW5ndGggMTQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytWlmP 2zYQfvevMNCHSkWsiqeovKVNWqQI0Mt5aorCu3Z2t83au90jTX9Gf3GHEo8hOZK9RbMIIEjkcO75 ZujbZdswvmztn384v160y2/h/8XidmEaYf8NH/Dz+fXyq/Xiy5+6JVNNr5fr94u26fteMjl8Z0sl GmOWXS8b+Hq9+KV6Va94o7SSslrXrNEMllc/x5ev61XbCGU0r5bx8aV95NxwJjwF2Zvqa/dadxyo rYCHVnBefWZfd6zjshLx0dQr03DZdsJSZlxo5ul2nQp0Ve/JDm8jk46UYcpYWuH5t5EuE13VotcM PXe1UvrX9XejqmTTyqgqoZ2qpOagpKAqYHL9O2wwyx6rVhidqlbDKU63L2rRgO47XW2BaylBFVuQ tAUBhKyualXd17CasxbEuapXXdOCHrvq4Ffv4+qNf/chrkOPn2rWNaAgUz2DPQx8QiqrVi4a0bcM lGlZ4cqaBXzD9JyBld2715ELtMWvbDtrAEtSg9XQgpfxbSBvV9rPzPj9cBTe9LFm1gy9jFI+EKIF hcFWoeBRWXHVoLQ/gLCxZ1Q7tMofgFR6ID7fRJWGz5YoUvU9qY5DXBAYTlZafwLfb3rDwB/WW3AA 9P2SMGV5kIHAuYZHDto0emDsg/vv/ENh73APd/VK2yyQ8eu+vicdIih4Fxl7rJXlpxvOPQ9Ed+Q5 3ip2LWL5JhpTxZ1owa5gPwkCFd9fEOZDror88+3oiX2rqlW9kg1EN0iBFiAK39q8pBk3VRNpdf4o Xjwsa96Zpm2Fte/KG9iqVPHRyk5TSqDIRep1D2gVcGNEo7XB4RAW/ukkGPw72Ab2dDbz8ajtjkVX 2hfBhMy+IXhASn/ITwbd7QpBniXO6nmJLnHAhsfh60XNoqwkYtkK5z4S7xB/G3waIuUk1EaSAUv5 HFBlGtZByrrCPou9fYht8HjDlY/tTSQ/UlVMJnJ7ljakeik9bIhQ3KQFw4qLXp1lqVMlKbF0sgPi ZRBaSWevQPJjzOpX2JI0y0GhB0zBH9ckqcfvQTG8J7gNGYRSXJYrYpJ6iOePOir3+jMUxyrM4tsZ eSK+qSDNWEJxhzi0m6m8b5ccck8a9cEMgD/AVzeEKMGOF3OxgRIFondZ6Hcfgx0pMdTiUWih06rs yZ0Nh2jdIwyCPr+MgCABCc7F0hw9bpLVN1BeGiNU2yUe6wV8yAWEsoKODEb6K3iHVXOMZ6T/Ox9n LsZlB+dyH+PIlhQf6MzzMg+ihdsYpmSCSQqrJ1mWkMdEntkC/TzJ1p7kPpo+GJoqzSGbfKp5bxXS z5qUteKYTcWcTQUXhU0V09U/NeSoVnGNzZREqzOXtZIcTYb4iPDbcwRsrGLgWiXeIo8GYqqFJcy/ QwChJda9qyItKpbKHQgdv8gBOeLNITCKN34ibxMo2H+mIAvKFsER3tWRpaZmHMJbdxj9IVuHvIKC zaEdfyzQFY3sO0MixjIx3SGHdx75t/eEnQtYBvm69wGbBJI/lQx8KpmWyBMFwpDbxl41Kjmkh8si WNG6ffwYwq4EWGjD8bwDK6HhRgAAYTynINcmmV6hikzVxW2p7tJVcGajjDdV3M6iV0jolzutvVKh s0Yv72MD9Gkq2EdT49J8WtgRDWN4QP1g1nxguOMpufP6wQ1UPwR/6vho3yVixa8dC0AG81ou8EsH af2ZE43c4AG9QSQOqSgUbEGchOzyEE2YsDDOJ0LflFR3T2QWQiR6K5Ftxu7WNdCwQ/pwnrGI52B0 N9lKGgIRPTLh0NtoQRfvZBPqz8wgMt3lI+mzRUmYeZpZd1TmE6o5mxxa+JMn21DRkwSJzLubFGlP fnks1RujHGOW0dyy4b0Z7T1O2FbQSEFRN0mc/3dndXWSaeYgnqP6xh73+WL9BR7TJVUr6HMTXSC8 owroPtOx/Yhg9EOmW/sZw3/eRQpps+2jvhjiQdWlh3jUkCQZ4oUFbognu+44Pg+bUACcOsULe9Hn yWFeWEzDGCrcxtwbkETmHC6qL1wjLyDHhCRzORFEGRNDiikhCtryHOfnYdbMmXFet/KHRq8e3X1E rm8GR0TYdLB6D3jLRIBIZYVlAGUBviFVZbU4lgrEftKt0q1oGQko9CkbnxE4Z1/wnnXKiJUiDrkC VEolrKTXR+Lu5hmcgMf+/CSjlyrPs8CQ68rziJx75xxQgy+ESdKSKg1lL4ZEOs8Q7eCbFKLEFkm7 9AHJPjlNxFn/XM8XdoUOiSzJFJ9EK3tDONN50gnndyN2TLZiPbSdrablPTYEDieGfst1Qpq3Osel kL+UkEm9mgPwQ3SXw1fk80GeiznnQy6HYSTVLoQ9ryNfP/hsn8R3Gf5bIj4SXHZPWA/NVMd1dnq0 I3YkMVl2U1SX9hC1Q0HtxGVPHlPQNxATonmWkhH7CGfA6dpw/UNMaMpYb3sd2Z+spoqMFno0WE6H g0OhxHwsRDKARQz6k/RSdrjoc8SEBGzbkluOtsDTRUnztF0v6NCAnQ6d9PJnNC+O9BPG5aUZjpTP iekMbAEUkNz/lBcbJ8+cS1YQB/tcLUn85gODDC//L4nJBuscQyl2oW84/DloEoJ7L8qDZpLevRs4 qUYwFsGjXWivfnbElqckE1pCKlEeydIEmEBejjJMEomnwjgkHTFnT25/nSt61Wdd8ET+gXhz055R z8cuWvMG33dVJQqj71VPAkvD0IPyVaojQ4PuU32sBKPTo0UbiXQMhVYQgbXvR6AjoblEChpAD+u1 8Xeb1kgty9RNtyNvI/FM5dTMZLa6z1TFJHdRk+kj6XL2/p1OW4kI56EtLboOa4B8TpIM2WjyT+wp 7G7qNyP5kGHq9xmlSyXjw0zqMbPpphXUb1coWBfI3pQZMBnElWXwKqL0qcENpAJ6BEJB/aRtjZWA 1MY9WaYKfVATAUo8Ypa4Lx6IruWeFK7ckZS4cuZS1rhepYLnv11peRLiR5qT6R8J2ZI+NWRO734I /qeHpiX+pUsgFfLoWFq9wXeoX+M57kWi1CPzwNlUXoy8iRE9efNC+SodUU8ebhM9CjnoLjR2tBuc GG+jsMoH60cm3KWQtCfcxpVPmw2n3U7pCUl/SV0tbEPio0H25M/10MihKeeEsgNQhK60w5gQTa1f rRc/wt+/gaQUjmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMjM1MwplbmRvYmoKNCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDExIDAgUgo+PgovQ29udGVu dHMgNSAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0ZvbnQgMTUgMCBSCj4+Ci9Db250ZW50cyAxMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTIgMCBSCl0gL0NvdW50IDIKL1JvdGF0ZSAw Pj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRh IDE3IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvUjEwCjEwIDAgUi9SNwo3IDAgUi9SOAo4IDAg Ui9SOQo5IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9i agoxMCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5 cGUvVHlwZTE+PgplbmRvYmoKNyAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EtQm9sZC9UeXBl L0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRp Y2EvVHlwZS9Gb250Ci9FbmNvZGluZyAxNiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxNiAw IG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxNDYvcXVvdGVyaWdodAoyNTIvdWRp ZXJlc2lzXT4+CmVuZG9iago5IDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1 ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE2 MDk+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3 b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8y Mi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+ CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1 ZmY0MmQ0YWYnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlBy b2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQgOC41NCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0nYzI1ZjFmMzMtNzkyOS0xMWRlLTAwMDAtN2RiNWZmNDJkNGFmJyB4bWxuczp4YXA9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpNb2RpZnlEYXRlPScyMDA5LTA3LTIyJyB4YXA6 Q3JlYXRlRGF0ZT0nMjAwOS0wNy0yMic+PHhhcDpDcmVhdG9yVG9vbD5HUEwgR2hvc3RzY3JpcHQg OC41NCBQREYgV3JpdGVyPC94YXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0 YWYnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpE b2N1bWVudElEPSdjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYnLz4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2MyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZicgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9 J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gt ZGVmYXVsdCc+XDM3NlwzNzdcMDAwRFwwMDBFXDAwMENcMDAwVFwwMDAzXDAwMDhcMDAwX1wwMDAw XDAwMDFcMDAwN1wwMDByXDAwMDFcMDAwX1wwMDBMXDAwMGlcMDAwYVwwMDBpXDAwMHNcMDAwb1ww MDBuXDAwMF9cMDAwdFwwMDBvXDAwMF9cMDAwSVwwMDBUXDAwMFVcMDAwX1wwMDBTXDAwMEdcMDAw MVwwMDA2XDAwMF9cMDAwb1wwMDBuXDAwMF9cMDAwY1wwMDBvXDAwMGRcMDAwZVwwMDBjXDAwMHNc MDAwLVwwMDBjXDAwMGxcMDAwZVwwMDBhXDAwMG48L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRs ZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPlwzNzZcMzc3XDAwMGNcMDAwYVwwMDBtXDAw MHBcMDAwb1wwMDBzPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlw dGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9k dWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkKL0NyZWF0aW9uRGF0ZShEOjIwMDkwNzIyMTY0NDU4 KzAyJzAwJykKL01vZERhdGUoRDoyMDA5MDcyMjE2NDQ1OCkKL1RpdGxlKFwzNzZcMzc3XDAwMERc MDAwRVwwMDBDXDAwMFRcMDAwM1wwMDA4XDAwMF9cMDAwMFwwMDAxXDAwMDdcMDAwclwwMDAxXDAw MF9cMDAwTFwwMDBpXDAwMGFcMDAwaVwwMDBzXDAwMG9cMDAwblwwMDBfXDAwMHRcMDAwb1wwMDBf XDAwMElcMDAwVFwwMDBVXDAwMF9cMDAwU1wwMDBHXDAwMDFcMDAwNlwwMDBfXDAwMG9cMDAwblww MDBfXDAwMGNcMDAwb1wwMDBkXDAwMGVcMDAwY1wwMDBzXDAwMC1cMDAwY1wwMDBsXDAwMGVcMDAw YVwwMDBuKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAwMHJcMDAwZVww MDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBpXDAwMG9cMDAw blwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3N1wwMDBjXDAw MGFcMDAwbVwwMDBwXDAwMG9cMDAwcykKL0tleXdvcmRzKCkKL1N1YmplY3QoKT4+ZW5kb2JqCnhy ZWYKMCAxOAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDc3NjIgMDAwMDAgbiAKMDAwMDAwOTk2 MCAwMDAwMCBuIAowMDAwMDA3Njg3IDAwMDAwIG4gCjAwMDAwMDc0MDEgMDAwMDAgbiAKMDAwMDAw MDAxNSAwMDAwMCBuIAowMDAwMDA0OTM1IDAwMDAwIG4gCjAwMDAwMDc5OTggMDAwMDAgbiAKMDAw MDAwODA2NyAwMDAwMCBuIAowMDAwMDA4MjI1IDAwMDAwIG4gCjAwMDAwMDc5MjUgMDAwMDAgbiAK MDAwMDAwNzgyNyAwMDAwMCBuIAowMDAwMDA3NTQzIDAwMDAwIG4gCjAwMDAwMDQ5NTUgMDAwMDAg biAKMDAwMDAwNzM4MCAwMDAwMCBuIAowMDAwMDA3ODg2IDAwMDAwIG4gCjAwMDAwMDgxNDcgMDAw MDAgbiAKMDAwMDAwODMwMSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE4IC9Sb290IDEgMCBS IC9JbmZvIDIgMCBSCi9JRCBbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjxGQjBB MEZDOUI3QjlBMTQyQ0JFNTY5OEVEMTk2ODJFNT5dCj4+CnN0YXJ0eHJlZgoxMDU0MwolJUVPRgox IDAgb2JqPDwvTWV0YWRhdGEgMTkgMCBSL1BhZ2VzIDMgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9i ag0yIDAgb2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwOTA3MjIxNjQ0NTgrMDInMDAnKS9TdWJqZWN0 KCkvQXV0aG9yKP7/AGMAYQBtAHAAbwBzKS9DcmVhdG9yKP7/AFAARABGAEMAcgBlAGEAdABvAHIA IABWAGUAcgBzAGkAbwBuACAAMAAuADkALgAzKS9LZXl3b3JkcygpL1Byb2R1Y2VyKEdQTCBHaG9z dHNjcmlwdCA4LjU0KS9Nb2REYXRlKEQ6MjAwOTA3MjIxNjQ0NTgpL1RpdGxlKERFQ1QzOF8wMTdy MV9MaWFpc29uX3RvX0lUVV9TRzE2X29uX2NvZGVjcyk+Pg1lbmRvYmoNMTggMCBvYmo8PC9DcmVh dGlvbkRhdGUoRDoyMDA5MDcyMjE2NDQ1OCswMicwMCcpL1N1YmplY3QoKS9DcmVhdG9yKFBERkNy ZWF0b3IgVmVyc2lvbiAwLjkuMykvS2V5d29yZHMoKS9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQg OC41NCkvTW9kRGF0ZShEOjIwMDkwNzIyMTY0NjA5KzAyJzAwJykvVGl0bGUoREVDVDM4XzAxN3Ix X0xpYWlzb25fdG9fSVRVX1NHMTZfb25fY29kZWNzKT4+DWVuZG9iag0xOSAwIG9iajw8L1N1YnR5 cGUvWE1ML0xlbmd0aCAzODU1L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2lu PSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMiI+CiAgIDxyZGY6UkRGIHhtbG5zOnJk Zj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0 MmQ0YWYiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z LyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+R1BMIEdob3N0c2NyaXB0IDguNTQ8L3BkZjpQcm9k dWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRm OmFib3V0PSJjMjVmMWYzMy03OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWYiCiAgICAgICAgICAg IHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6 TW9kaWZ5RGF0ZT4yMDA5LTA3LTIyVDE2OjQ2OjA5KzAyOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAg ICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDktMDctMjJUMTY6NDQ6NTgrMDI6MDA8L3hhcDpDcmVh dGVEYXRlPgogICAgICAgICA8eGFwOkNyZWF0b3JUb29sPlBERkNyZWF0b3IgVmVyc2lvbiAwLjku MzwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDA5LTA3LTIy VDE2OjQ2OjA5KzAyOjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0w MDAwLTdkYjVmZjQyZDRhZiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD5jMjVmMWYzMy03 OTI5LTExZGUtMDAwMC03ZGI1ZmY0MmQ0YWY8L3hhcE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4 YXBNTTpJbnN0YW5jZUlEPnV1aWQ6NTQwYWU3YzctZWQ2My00OTM1LWFkN2QtOTM4ZWQwOGUxYmYz PC94YXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9ImMyNWYxZjMzLTc5MjktMTFkZS0wMDAwLTdkYjVmZjQyZDRh ZiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv Ij4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAg ICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjps aSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5ERUNUMzhfMDE3cjFfTGlhaXNvbl90b19JVFVfU0cxNl9v bl9jb2RlY3M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRp dGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAg ICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6ZGVzY3Jp cHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDps YW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOmRl c2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1w bWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDXhyZWYNCjEgMg0KMDAwMDAx MTA1NyAwMDAwMCBuDQowMDAwMDExMTE3IDAwMDAwIG4NCjE4IDINCjAwMDAwMTEzODUgMDAwMDAg bg0KMDAwMDAxMTYxMiAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDIwL1Jvb3QgMSAwIFIvSW5m byAxOCAwIFIvSURbPEZCMEEwRkM5QjdCOUExNDJDQkU1Njk4RUQxOTY4MkU1PjwwMDk4NkIwNUUw MTM1QjQ1OUFCRDk0NzYwRjdFNzAxRj5dL1ByZXYgMTA1NDMgPj4NCnN0YXJ0eHJlZg0KMTU1NDQN CiUlRU9GDQo= ------_=_NextPart_001_01CA10EB.51B9E8C2-- From stephen.botzko@gmail.com Thu Jul 30 03:41:38 2009 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 070EE3A6BF6 for ; Thu, 30 Jul 2009 03:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.604, 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 JEVeNwKz4zBn for ; Thu, 30 Jul 2009 03:41:36 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1DB533A67D7 for ; Thu, 30 Jul 2009 03:41:35 -0700 (PDT) Received: by bwz19 with SMTP id 19so497810bwz.37 for ; Thu, 30 Jul 2009 03:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GhhSJ7MM6QfH7KfenugeFIhzck6OUaEt0PixY9hiwBg=; b=qX6VM6IM1j9+mcRyvUEYEHSta60pPEDykBzAUBo04NV+99XLRsMZnDKZBQcGW3lslD O3Prxte+XpN1ESf+oURFvrRcegE3J/bewV5z2Bn3KQjHmmQjpRoigCIorPjj1nZ+rvps 6gijKRs/2rw79gwC49NNBLItPUtD/olyF7vm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UmU389IoUc2agt43UxH1r5HW+MoGh1Cuazcbaaf/EK9wQFslXTUiAVZfexmbjXRnV2 jBG0nbvnJMUgGyrJqEFnu65qY2dRnug+Z0fyhZTh8S8H7MqZ9qIRhOQ2XPvVhPqDcuFX rgMqvUr4fk6AUOohvLPaTIDC4iyknTZdUVnGk= MIME-Version: 1.0 Received: by 10.103.176.20 with SMTP id d20mr587338mup.47.1248950494011; Thu, 30 Jul 2009 03:41:34 -0700 (PDT) In-Reply-To: <52CCE37C-3049-4B12-8E4A-A5013E60D83B@cisco.com> References: <52CCE37C-3049-4B12-8E4A-A5013E60D83B@cisco.com> Date: Thu, 30 Jul 2009 06:41:33 -0400 Message-ID: <6e9223710907300341n20975c4cp54064d5d546c6550@mail.gmail.com> From: stephen botzko To: Cullen Jennings Content-Type: multipart/alternative; boundary=00163641759b89a241046fe9f257 Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Charter Take 2 - BSD License X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:41:38 -0000 --00163641759b89a241046fe9f257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe that normative source code is best for a number of reasons. One is ease of implementation (either using the reference code directly, or being able to use it to validate the ported code). Another is that it assures that the characterization tests actually measure the standard's performance. Even if it is not officially normative, readily available reference code becomes de facto normative, since most implementers will simply use the code and ignore the text in the RFC. Supplying test vectors is another possibility, but that is problematic for floating point implementations. Regards, Stephen Botzko Polycom On Thu, Jul 30, 2009 at 3:51 AM, Cullen Jennings wrote: > > On Jul 29, 2009, at 2:40 , Stephan Wenger wrote: > > At present, the RFC editor, per a requirement set by the IETF trust, >> inserts >> a BSD-style license template into the source code. This templates include >> a >> phrase "[...] Redistribution and use in source and binary forms, with or >> without modification, are permitted [...]". There are scholars and >> corporate lawyers (I personally know quite a few of the latter) suggesting >> that this language---specifically the unqualified use of the term >> "use"---may imply a patent license grant. >> > > > Stephan, at a high level, I don't think this will poses a problem for this > BOF. When selecting the BSD license, the IETF did not intent to include > patents licenses as part of the "use". If there is a real problem with the > BSD license possibly granting patent licenses, the obvious thing to do would > be for the Trustees to "qualify" the meaning of "use" in the license. For > purposes of this BOF, I think we can assume that if there is any community > consensus this is a problem, then it will be fixed. > > That said, I'm glad to see input on questions such as: should the normative > specification should be in source code or not; and if that decision would > need to be in charter or be something that a WG might decide if was formed. > > Cullen > > > PS - Clearly this would be the wrong mailing lists for discussion of the > topic but I note Herald, the previous IPR WG chair, did not seem to share > your concern. I also note it's not clear if you actually believe this is an > issue. I'd certainly be interested i knowing if you personally believed that > it was likely that courts would interpret BSD this ways but it's pretty hard > to decide how to evaluate the vague reporting of other unnamed peoples > opinions. Anyways, all topics for another mail list. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --00163641759b89a241046fe9f257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe that normative source code is best for a number of reasons.=A0 On= e is ease of implementation (either using the reference code directly, or b= eing able to use it to validate the ported code).=A0 Another is that it ass= ures that the characterization tests actually measure the standard's pe= rformance.=A0 Even if it is not officially normative, readily available ref= erence code becomes de facto normative, since most implementers will simply= use the code and ignore the text in the RFC.

Supplying test vectors is another possibility, but that is problematic = for floating point implementations.

Regards,
Stephen Botzko
Po= lycom

On Thu, Jul 30, 2009 at 3:51 AM, Cu= llen Jennings <flu= ffy@cisco.com> wrote:

On Jul 29, 2009, at 2:40 , Stephan Wenger wrote:

At present, the RFC editor, per a requirement set by the IETF trust, insert= s
a BSD-style license template into the source code. =A0This templates includ= e a
phrase "[...] Redistribution and use in source and binary forms, with = or
without modification, are permitted [...]". =A0There are scholars and<= br> corporate lawyers (I personally know quite a few of the latter) suggesting<= br> that this language---specifically the unqualified use of the term
"use"---may imply a patent license grant.


Stephan, at a high level, I don't think this will poses a problem for t= his BOF. When selecting the BSD license, the IETF did not intent to include= patents licenses as part of the "use". If there is a real proble= m with the BSD license possibly granting patent licenses, the obvious thing= to do would be for the Trustees to "qualify" the meaning of &quo= t;use" in the license. For purposes of this BOF, I think =A0we can ass= ume that if there is any community consensus this is a problem, then it wil= l be fixed.

That said, I'm glad to see input on questions such as: should the norma= tive specification should be in source code or not; and if that decision wo= uld need to be in charter or be something that a WG might decide if was for= med.

Cullen


PS - Clearly this would be the wrong mailing lists for discussion of the to= pic but I note Herald, the previous IPR WG chair, did not seem to share you= r concern. =A0I also note it's not clear if you actually believe this i= s an issue. I'd certainly be interested i knowing if you personally bel= ieved that it was likely that courts would interpret BSD this ways but it&#= 39;s pretty hard to decide how to evaluate the vague reporting of other unn= amed peoples opinions. Anyways, all topics for another mail list.

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

--00163641759b89a241046fe9f257-- From stephen.botzko@gmail.com Thu Jul 30 10:49:23 2009 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 EAF273A63EC for ; Thu, 30 Jul 2009 10:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.574, 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 9RLqiMzLhHpo for ; Thu, 30 Jul 2009 10:49:23 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 939503A71A3 for ; Thu, 30 Jul 2009 10:49:14 -0700 (PDT) Received: by fxm26 with SMTP id 26so844633fxm.42 for ; Thu, 30 Jul 2009 10:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=nH40rGGJhgcpUj6tZhn3+FJ5+Ce/HPyg5iZHFOdiDI4=; b=Z4xvdpNuqySMV/s13oM4v4x2lb9rZB456qgSE663t6NPsxPNs4vTGi2kBB86H/Yr4i 1Tr/71TQ9Ellfw7TeSZHx9YvNkrlAhnOF/Q6QJvOBwXDwR4BaRrX46YvuLhAcYUQiukq PTlTIHZ/24Tki/G+MMX+8JZ2thYE4oVmonTR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VR2SY7Z8wcEOZCa96zd3oXQslqpU0OnrzTGSrLTTnE0Ss2X4StTET/SkH07FnknkUA SdiZt//S4s0qe+d44Pe7v3h/EvimJ/2maufjFbAe9BiEW5/CKKqXIaf4EIrz42hZDcqk WoOb7s5QgnO7gLC5eo+LPrcpQf4RxS2ThO8oU= MIME-Version: 1.0 Received: by 10.103.177.1 with SMTP id e1mr886373mup.23.1248976153814; Thu, 30 Jul 2009 10:49:13 -0700 (PDT) Date: Thu, 30 Jul 2009 13:49:13 -0400 Message-ID: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636416f43fb28d9046fefebb3 Subject: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:49:24 -0000 --001636416f43fb28d9046fefebb3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Exactly what this expertise consisted of was one of the subjects in the BOF today. I have three comments - (1) The proposed WG charter appears to span several distinct ITU-T groups. SG16/Q9: "Embedded variable bit rate coding of speech signals" SG16/Q10: "Speech and audio coding and related software tools" SG12/Q7: "Methods, tools, and test plans for the subjective assessment of speech, audio, and audiovisual quality interactions" There are some other groups in SG12 which arguably are also covered in this charter, including perhaps SG12/Q9 (Perceptual-based objective methods for voice, audio, and visual quality measurements). I am not intending to say that the charter is too broad (though of course it might be argued that it is). Just that when we identify the needed expertise, we should include the full set of relevant groups in the other SDOs. So far we are asking folks if they are "codec experts". Other skills are needed. (2) Over the audio stream I heard a comment to the effect that "anyone with two ears is competent to evaluate codec quality". Lots of applause. I think this statement is naive and dangerously misleading. People with ears clearly listened to iLBC, and apparently still missed its issue with tonal languages. (Yes its experimental and wasn't adequately reviewed. That is the point). It is true that anyone who can hear can serve as a test subject. But reviewing/validating the test plan and the observed results is not something that anyone can do. This is not to say that there is no one in the IETF who has the skills. But I am still thinking that the discussions so far are seriously understating the importance of proper characterization and testing. The bulk of the time in other SDOs is spent on requirements definition and testing questions. The actual algoriithm development is treated as a homework assignment. (3) Using other organizations (such as perhaps SG12/Q7???) to evaluate our codecs also came up in the meeting. That might be an interesting collaboration if possible. But I don't think you'll get useful results without a lot of up-front discussion. (I have seen how those liason statements get written!). Regards, Stephen Botzko Polycom --001636416f43fb28d9046fefebb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Exactly what this expertise consisted of was one of the subjects in the BOF= today.

I have three comments -

(1) The proposed WG charter = appears to span several distinct ITU-T groups.=A0

SG16/Q9: "Em= bedded variable bit rate coding of speech signals"
SG16/Q10:=A0 "Speech and audio coding and related software tools"=
SG12/Q7: "Methods, tools, and test plans for the subjective assess= ment of speech, audio, and audiovisual quality interactions"

There are some other groups in SG12 which arguably are also covered in this= charter, including perhaps SG12/Q9 (Perceptual-based objective methods for= voice, audio, and visual quality measurements).

I am not intending = to say that the charter is too broad (though of course it might be argued t= hat it is).=A0 Just that when we identify the needed expertise, we should i= nclude the full set of relevant groups in the other SDOs.=A0 So far we are = asking folks if they are "codec experts".=A0 Other skills are nee= ded.

(2) Over the audio stream I heard a comment to the effect that "an= yone with two ears is competent to evaluate codec quality".=A0 Lots of= applause.=A0 I think this statement is naive and dangerously misleading.= =A0 People with ears clearly listened to iLBC, and apparently still missed = its issue with tonal languages.=A0 (Yes its experimental and wasn't ade= quately reviewed. That is the point). =A0

It is true that anyone who can hear can serve as a test subject.=A0 But= reviewing/validating the test plan and the observed results is not somethi= ng that anyone can do.=A0 This is not to say that there is no one in the IE= TF who has the skills.=A0 But I am still thinking that the discussions so f= ar are seriously understating the importance of proper characterization and= testing.=A0 The bulk of the time in other SDOs is spent on requirements de= finition and testing questions.=A0 The actual algoriithm development is tre= ated as a homework assignment.

(3) Using other organizations (such as perhaps SG12/Q7???) to evaluate = our codecs also came up in the meeting.=A0 That might be an interesting col= laboration if possible.=A0 But I don't think you'll get useful resu= lts without a lot of up-front discussion.=A0 (I have seen how those liason = statements get written!).

Regards,
Stephen Botzko
Polycom
--001636416f43fb28d9046fefebb3-- From jmh@joelhalpern.com Thu Jul 30 13:15:14 2009 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 86B573A6C67 for ; Thu, 30 Jul 2009 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, 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 SitZmLdnJZHy for ; Thu, 30 Jul 2009 13:15:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CADD93A68AB for ; Thu, 30 Jul 2009 13:15:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70A9443030B for ; Thu, 30 Jul 2009 13:15:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.43.1.29] (unknown [77.241.97.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7AEE843046A for ; Thu, 30 Jul 2009 13:15:14 -0700 (PDT) Message-ID: <4A71FF50.5020007@joelhalpern.com> Date: Thu, 30 Jul 2009 16:15:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: codec@ietf.org References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> In-Reply-To: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:15:14 -0000 (Many useful comments elided, to focus on one.) In fact, the community response to this comment (about evaluating codecs) is symptomatic of the expertise problem. I know just enough abou this space to know that random pairs of ears, even random pairs of high quality ears, are not sufficient to evaluate whether a codec does a good job, much less a good job across all of the requirements. However, like many communities, and like many problem areas, we tend to assume we understand more than we do. So folks like the idea of just using peoples ears to evaluate the codecs in some simple fashion. Yours, Joel M. Halpern stephen botzko wrote: ... > (2) Over the audio stream I heard a comment to the effect that "anyone > with two ears is competent to evaluate codec quality". Lots of > applause. I think this statement is naive and dangerously misleading. > People with ears clearly listened to iLBC, and apparently still missed > its issue with tonal languages. (Yes its experimental and wasn't > adequately reviewed. That is the point). > > It is true that anyone who can hear can serve as a test subject. But > reviewing/validating the test plan and the observed results is not > something that anyone can do. This is not to say that there is no one > in the IETF who has the skills. But I am still thinking that the > discussions so far are seriously understating the importance of proper > characterization and testing. The bulk of the time in other SDOs is > spent on requirements definition and testing questions. The actual > algoriithm development is treated as a homework assignment. ... > Regards, > Stephen Botzko > Polycom > > > ------------------------------------------------------------------------ > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Borilin@spiritdsp.com Thu Jul 30 13:31:00 2009 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 9B5CD3A6CD7 for ; Thu, 30 Jul 2009 13:31:00 -0700 (PDT) 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 Bjh1hHIqAXOJ for ; Thu, 30 Jul 2009 13:30:59 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 86C113A69D0 for ; Thu, 30 Jul 2009 13:30:59 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6UKUxTh079773; Fri, 31 Jul 2009 00:30:59 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 00:30:47 +0400 Message-ID: In-Reply-To: <4A71FF50.5020007@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRUnrTen4wFEYjTSWfzHnGmIhXtwAAdr2g References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> From: "Slava Borilin" To: "Joel M. Halpern" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:31:00 -0000 Joel, We (SPIRIT Skype XIPH at least) don't expect "ear test". We are just saying for the time being, that the methods are rather "well-defined" for judging the codec quality in terms of mos score, so there was no the main focus for todays BOF. During the work of the WG, if its formed, definitely we will deploy the correct process for codec evaluation, with the help and aids from others who are skilled in this, like you and Stephen hopefully. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, July 30, 2009 10:15 PM To: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise (Many useful comments elided, to focus on one.) In fact, the community response to this comment (about evaluating=20 codecs) is symptomatic of the expertise problem. I know just enough=20 abou this space to know that random pairs of ears, even random pairs of=20 high quality ears, are not sufficient to evaluate whether a codec does a good job, much less a good job across all of the requirements. However, like many communities, and like many problem areas, we tend to=20 assume we understand more than we do. So folks like the idea of just=20 using peoples ears to evaluate the codecs in some simple fashion. Yours, Joel M. Halpern stephen botzko wrote: ... > (2) Over the audio stream I heard a comment to the effect that "anyone > with two ears is competent to evaluate codec quality". Lots of=20 > applause. I think this statement is naive and dangerously misleading. > People with ears clearly listened to iLBC, and apparently still missed > its issue with tonal languages. (Yes its experimental and wasn't=20 > adequately reviewed. That is the point). =20 >=20 > It is true that anyone who can hear can serve as a test subject. But=20 > reviewing/validating the test plan and the observed results is not=20 > something that anyone can do. This is not to say that there is no one > in the IETF who has the skills. But I am still thinking that the=20 > discussions so far are seriously understating the importance of proper > characterization and testing. The bulk of the time in other SDOs is=20 > spent on requirements definition and testing questions. The actual=20 > algoriithm development is treated as a homework assignment. ... > Regards, > Stephen Botzko > Polycom >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 alexander.chemeris@gmail.com Thu Jul 30 11:19:36 2009 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 20C113A71A6 for ; Thu, 30 Jul 2009 11:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 N6LZsmaAhUDi for ; Thu, 30 Jul 2009 11:19:35 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id A27EC3A6B2B for ; Thu, 30 Jul 2009 11:18:50 -0700 (PDT) Received: by bwz19 with SMTP id 19so758592bwz.37 for ; Thu, 30 Jul 2009 11:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=x32Yo/Z9q1dvP3Qrr7n7ZCVAkPg8JJ7/LILyPNtEtL4=; b=p8BLMacFTm37d6tRAn7dy2K9KWlFus3V8sOc75Uzkz76xSf5i1SWXfiJ8e5I1NywMT dyF50XjkJVGbI5twdsCHMw7ussFMqxFmaNjdHdj3gsHTNLy/HQ4Wz2XjRWh440k6wJXs 7seygZMFFpx4RY11tHYupKyZSRk6GFtoEajbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=eqotL2zfPYu09Zaatlh4MniiUrYLSwBUMhG9hZ4ELNK9MlIupTED8mreZmkmAJ23qm nAjjv2MK4+3HtTbxBerT9W7iYDa69wZbjoF5CWRLHWfkJ9lQLs8dvuD6ISwmp2V30Gl0 AoUBZhnlTXyHt1MCj3x1ufaJN9Fds3x0SIkoM= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.251.20 with SMTP id d20mr902083mus.42.1248977926613; Thu, 30 Jul 2009 11:18:46 -0700 (PDT) In-Reply-To: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> From: Alexander Chemeris Date: Thu, 30 Jul 2009 22:18:26 +0400 X-Google-Sender-Auth: 81ee234bb362b7e6 Message-ID: <3d032e5d0907301118o2158748ep2bd23bcb991800a2@mail.gmail.com> To: stephen botzko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:38:30 -0000 Hello, If I understand correctly what's going on, then this WG is meant to be a recommendation and classification body, a collaboration point for everyon= e interested in the topic. ITU-T groups does their job, they standardize codecs, quality measures, etc and do their job good enough. What they do not do - they do not and can not recommend any given codec for a broad use in the voice over the Internet. That's just not their objective= . So, this group can produce a list criteria for VoIP codecs, evaluate existing codecs using existing test methods and recommend (or not recommend) some of the codecs for broad use. As a bonus, this WG promise to be a good place of collaboration among codec developers who want to outline the requirements for an ideal VoIP codec and try jointly to develop one for later standardizatio= n by this WG. So, in a fewer words: 1) This is not an opposite to ITU-T, but rather complementary. 2) This is not about codec development, but rather about specification of requirements and fixation of current state of affairs and recommendation= s. Please, correct me if I've got things incorrectly. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 On Thu, Jul 30, 2009 at 21:49, stephen botzko wro= te: > Exactly what this expertise consisted of was one of the subjects in the B= OF > today. > > I have three comments - > > (1) The proposed WG charter appears to span several distinct ITU-T groups= . > > SG16/Q9: "Embedded variable bit rate coding of speech signals" > SG16/Q10:=C2=A0 "Speech and audio coding and related software tools" > SG12/Q7: "Methods, tools, and test plans for the subjective assessment of > speech, audio, and audiovisual quality interactions" > > There are some other groups in SG12 which arguably are also covered in th= is > charter, including perhaps SG12/Q9 (Perceptual-based objective methods fo= r > voice, audio, and visual quality measurements). > > I am not intending to say that the charter is too broad (though of course= it > might be argued that it is).=C2=A0 Just that when we identify the needed > expertise, we should include the full set of relevant groups in the other > SDOs.=C2=A0 So far we are asking folks if they are "codec experts".=C2=A0= Other skills > are needed. > > (2) Over the audio stream I heard a comment to the effect that "anyone wi= th > two ears is competent to evaluate codec quality".=C2=A0 Lots of applause.= =C2=A0 I > think this statement is naive and dangerously misleading.=C2=A0 People wi= th ears > clearly listened to iLBC, and apparently still missed its issue with tona= l > languages.=C2=A0 (Yes its experimental and wasn't adequately reviewed. Th= at is > the point). > > It is true that anyone who can hear can serve as a test subject.=C2=A0 Bu= t > reviewing/validating the test plan and the observed results is not someth= ing > that anyone can do.=C2=A0 This is not to say that there is no one in the = IETF who > has the skills.=C2=A0 But I am still thinking that the discussions so far= are > seriously understating the importance of proper characterization and > testing.=C2=A0 The bulk of the time in other SDOs is spent on requirement= s > definition and testing questions.=C2=A0 The actual algoriithm development= is > treated as a homework assignment. > > (3) Using other organizations (such as perhaps SG12/Q7???) to evaluate ou= r > codecs also came up in the meeting.=C2=A0 That might be an interesting > collaboration if possible.=C2=A0 But I don't think you'll get useful resu= lts > without a lot of up-front discussion.=C2=A0 (I have seen how those liason > statements get written!). > > Regards, > Stephen Botzko > Polycom > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From swmike@swm.pp.se Thu Jul 30 13:42:22 2009 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 E322F3A6A02 for ; Thu, 30 Jul 2009 13:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 uzUwu9ckKAda for ; Thu, 30 Jul 2009 13:42:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id E25DB3A68E8 for ; Thu, 30 Jul 2009 13:42:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0F7399E; Thu, 30 Jul 2009 22:42:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0E6EC9A for ; Thu, 30 Jul 2009 22:42:22 +0200 (CEST) Date: Thu, 30 Jul 2009 22:42:22 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:42:23 -0000 On Fri, 31 Jul 2009, Slava Borilin wrote: > During the work of the WG, if its formed, definitely we will deploy the > correct process for codec evaluation, with the help and aids from others > who are skilled in this, like you and Stephen hopefully. As I stated at the microphone during the session, the most important aspect I see an a network engineer is that the Internet behaviour needs to drive both the codec design and how it's transported, not the other way around. Codecs can't set demand on how the Internet should behave, it just doesn't work in the real world. If you can't make a codec that can gracefully handle intermittent 2 second packet jitter and 10% packetloss and then go back to good quality/end-to-end delay again when conditions improve, then you have to realise what you're doing isn't not suitable to fit on the Internet. The codecs I've seen before in the ITU space has completely dropped the ball here (mainly experience from G.711 and G.729 here though). As soon as I see 20 ms jitter tolerances and 0.5% packet loss to reach decent MOS values I get.... errr.. tired. -- Mikael Abrahamsson email: swmike@swm.pp.se From Borilin@spiritdsp.com Thu Jul 30 13:44:35 2009 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 E747D3A71FC for ; Thu, 30 Jul 2009 13:44:35 -0700 (PDT) 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=[AWL=0.000, 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 jtiN8Oh4sJU6 for ; Thu, 30 Jul 2009 13:44:35 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 364953A682F for ; Thu, 30 Jul 2009 13:44:24 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6UKiP26080225; Fri, 31 Jul 2009 00:44:25 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 00:44:13 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRVkQV1eOppvopQX+1ALgqG+C9jQAACOZQ References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com> From: "Slava Borilin" To: "Mikael Abrahamsson" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:44:36 -0000 You are 100% right. This should be the step1 of the WG - to define the REAL CONDITIONS for the codec to work in. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, July 30, 2009 10:42 PM To: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise On Fri, 31 Jul 2009, Slava Borilin wrote: > During the work of the WG, if its formed, definitely we will deploy the=20 > correct process for codec evaluation, with the help and aids from others=20 > who are skilled in this, like you and Stephen hopefully. As I stated at the microphone during the session, the most important=20 aspect I see an a network engineer is that the Internet behaviour needs to=20 drive both the codec design and how it's transported, not the other way=20 around. Codecs can't set demand on how the Internet should behave, it just=20 doesn't work in the real world. If you can't make a codec that can gracefully handle intermittent 2 second=20 packet jitter and 10% packetloss and then go back to good=20 quality/end-to-end delay again when conditions improve, then you have to realise what you're doing isn't not suitable to fit on the Internet. The codecs I've seen before in the ITU space has completely dropped the=20 ball here (mainly experience from G.711 and G.729 here though). As soon as I see 20 ms jitter tolerances and 0.5% packet loss to reach=20 decent MOS values I get.... errr.. tired. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From alexander.chemeris@gmail.com Thu Jul 30 13:46:38 2009 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 5F1493A693C for ; Thu, 30 Jul 2009 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 SJXyGyE9o4An for ; Thu, 30 Jul 2009 13:46:37 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 1AB213A682F for ; Thu, 30 Jul 2009 13:46:36 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so1100747fga.18 for ; Thu, 30 Jul 2009 13:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=TCRj9nbxx1/LkwNb6Ba6SXEVTX/8Uh9OZhlnsk+mz1s=; b=O3ni0cewOFp14OKFQ2b/DkRf1lbUWsQLqXNqBBUSqbYCu6FPNnr+hhbE5nYkRr5g8C babbHzEsrGI/uicOef0+K8Vyx/FwiWJQD9N0PQr7h/M1jcOj1zNjQ/LUFYQL+89FSmVV yHVL8yf1h3pFkzto0JVrkSqECp8pVCVSHmCFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=VsJcVXMUtkG9Dx0ZhOp7qD1AC2K7LgCzcsbAKggmDF3WbZT4s5CdpzzDGTird7BECJ IWeS9O1aUi1VgdnPoSHgOMJulf85KMzERoziN+sW5XBwsDQ61mgj9u7uLQpv6E+9+qGC oEqbQliCK/SVxJTxa4kEEeBCrvsfcnI2tfjKA= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.24.11 with SMTP id b11mr966733muj.133.1248986797072; Thu, 30 Jul 2009 13:46:37 -0700 (PDT) From: Alexander Chemeris Date: Fri, 31 Jul 2009 00:46:17 +0400 X-Google-Sender-Auth: d4235fff03f629dc Message-ID: <3d032e5d0907301346q4ce3209h8de9cdad90f4bf81@mail.gmail.com> To: codec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:46:38 -0000 Hello, Just to make a note of proposed additions to technical considerations, which were seen on the jabber conference: 1) Requirement/non requirement of stereo and/or multichannel 2) Good performance in the presence of packet loss 3) Compatibility with negotiation schemes widely used over the Internet. Points (1) and (2) are obvious and seem to leak from the consideration just by occasion, but I want to slightly elaborate on point (3). A non-technical point, which was not clearly defined, but I think is very important: * Considered codecs must be standardized. In ITU, IETF, wherever, but there should be a clean standard allowing creation of compatible 3rd party implementation. = Introduction for non-VoIP developers = SIP is one of the most widely used and well known VoIP signaling and it do use venerable SDP (RFC2327) for codec negotiation. The recommended way to negotiate codecs with SDP is a so-called Offer/Answer Model (RFC3264). Simply speaking, one side offers a codec set and the other side can either accept a specific codec or reject its use. = The problem = SDP was clearly designed for the use with old-fashion codecs which supported only one or few operating modes, usually just a set of few different bitrates. But modern codecs tend to be a beasts of different kind they offer a plenty of configuration options users have to choose from. I know two examples of such codecs - Speex and AMR(-WB), probably IPMR goes a similar way, but I'm not familiar with it. For RTP payload and SDP negotiation of Speex look into RFC 5574, for AMR and AMR-WB look into RFC5574. So, the tale is about AMR(-WB) which has few horrible statements in the RFC about SDP negotiation, worst of which is: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. [...] This means that if you want to support several combinations of parameters, SDP offer will blow up into a huge list of different parameter combinations. That's the problem, because SDP plus SIP header should fit into UDP packet size (you can use TCP, but it's much better to fit into UDP, isn't it?) and wasting payload type numbers. But this problem won't be that sharp if every VoIP developer read RFC carefully with the full understanding of them and implement everything as written. Instead, many developers assume that defaults are fine and don't have time or willing to read or implement such a complex operation. No need to say I've seen implementations which ignored even "octet-align" fmtp parameter, trying to guess it from the actual data. When I implemented AMR(-WB) payload for our SIP stack I some more inconveniences and even one collision in a RFC, but alas I can't recall details now. I should have documented the problem that time and not rely on my memory.. Speex does a better job here, as it does not have incompatible sets of features. I.e. every stream, produced by an encoder can be at least correctly passed if not decoded by a decoder. The moral of that story is that ideal VoIP codec should not assume a fixed number of parameter sets in endpoints, as AMR does, and rely on SDP for features offer. Rather it should use in-band signaling as much as possible to offload SDP and make codec API "programmer-friendly". -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From Borilin@spiritdsp.com Thu Jul 30 13:52:00 2009 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 536E23A6A02 for ; Thu, 30 Jul 2009 13:52:00 -0700 (PDT) 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 iBwE0s3TF58Q for ; Thu, 30 Jul 2009 13:51:59 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id EAB703A7204 for ; Thu, 30 Jul 2009 13:51:58 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6UKpxT2080352; Fri, 31 Jul 2009 00:52:00 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 00:51:47 +0400 Message-ID: In-Reply-To: <3d032e5d0907301346q4ce3209h8de9cdad90f4bf81@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Technical Considerations additions Thread-Index: AcoRVt/jzH2hKWG5THqDDIXzba9wWwAAEteQ References: <3d032e5d0907301346q4ce3209h8de9cdad90f4bf81@mail.gmail.com> From: "Slava Borilin" To: "Alexander Chemeris" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:52:00 -0000 Thanks Alexander,=20 that's exactly the type of input which is important define the "internet" requirements to the codec, which will lead us to the either selection, or design of the one which satisfy the technical goals, while being easily accessible and freely distributable. And that's (one more) proof why BOF agreed today that we @IETF have the expertise to define the scope of work (and probably we have even more expertise in this specific area then other SDOs). best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Alexander Chemeris Sent: Thursday, July 30, 2009 10:46 PM To: codec@ietf.org Subject: [codec] Technical Considerations additions Hello, Just to make a note of proposed additions to technical considerations, which were seen on the jabber conference: 1) Requirement/non requirement of stereo and/or multichannel 2) Good performance in the presence of packet loss 3) Compatibility with negotiation schemes widely used over the Internet. Points (1) and (2) are obvious and seem to leak from the consideration just by occasion, but I want to slightly elaborate on point (3). A non-technical point, which was not clearly defined, but I think is very important: * Considered codecs must be standardized. In ITU, IETF, wherever, but there should be a clean standard allowing creation of compatible 3rd party implementation. =3D Introduction for non-VoIP developers =3D SIP is one of the most widely used and well known VoIP signaling and it do use venerable SDP (RFC2327) for codec negotiation. The recommended way to negotiate codecs with SDP is a so-called Offer/Answer Model (RFC3264). Simply speaking, one side offers a codec set and the other side can either accept a specific codec or reject its use. =3D The problem =3D SDP was clearly designed for the use with old-fashion codecs which supported only one or few operating modes, usually just a set of few different bitrates. But modern codecs tend to be a beasts of different kind they offer a plenty of configuration options users have to choose from. I know two examples of such codecs - Speex and AMR(-WB), probably IPMR goes a similar way, but I'm not familiar with it. For RTP payload and SDP negotiation of Speex look into RFC 5574, for AMR and AMR-WB look into RFC5574. So, the tale is about AMR(-WB) which has few horrible statements in the RFC about SDP negotiation, worst of which is: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. [...] This means that if you want to support several combinations of parameters, SDP offer will blow up into a huge list of different parameter combinations. That's the problem, because SDP plus SIP header should fit into UDP packet size (you can use TCP, but it's much better to fit into UDP, isn't it?) and wasting payload type numbers. But this problem won't be that sharp if every VoIP developer read RFC carefully with the full understanding of them and implement everything as written. Instead, many developers assume that defaults are fine and don't have time or willing to read or implement such a complex operation. No need to say I've seen implementations which ignored even "octet-align" fmtp parameter, trying to guess it from the actual data. When I implemented AMR(-WB) payload for our SIP stack I some more inconveniences and even one collision in a RFC, but alas I can't recall details now. I should have documented the problem that time and not rely on my memory.. Speex does a better job here, as it does not have incompatible sets of features. I.e. every stream, produced by an encoder can be at least correctly passed if not decoded by a decoder. The moral of that story is that ideal VoIP codec should not assume a fixed number of parameter sets in endpoints, as AMR does, and rely on SDP for features offer. Rather it should use in-band signaling as much as possible to offload SDP and make codec API "programmer-friendly". --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Thu Jul 30 14:02:22 2009 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 432C73A71A9 for ; Thu, 30 Jul 2009 14:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.547, 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 SUliDGNadMBe for ; Thu, 30 Jul 2009 14:02:21 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id C0BA83A6CA9 for ; Thu, 30 Jul 2009 14:02:20 -0700 (PDT) Received: by fxm26 with SMTP id 26so965700fxm.42 for ; Thu, 30 Jul 2009 14:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=dPLG5fyTtWM371pkeLaBF+boVklogwIOwfvqK5G7j/M=; b=nhTiZo9NkW3Dcm66oPSYtRYlq3g5u7Mj96ZezOed8dYqeJSsmoCqrtNQmgiesv1RK/ Y+D4O4onXlVkYVao+ykCn4ZFRpn4A4rlNFSbdVSOm5J1ycsKjI+gu+2/dPJfw5+yG7l1 sXGfbkJ3fB+EMlVIppmhr8ecH5xsVLLGKQBs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MPLGlm8Ki26UlOp0hqFMB7RrrSKgVg1pXwoyxIWI0jzhfnPoZaMScy0atm6Dyv5d+C nELUb00ndGr/UjFsJWUoU+AaelTIHRZHTgYZ3pwKhPAcGWZJoDXx/3uT1YQ+ml8dhMuN xtpeZojlQYqOxdXRFgaUUHpe7PZ2sZpMILU8Y= MIME-Version: 1.0 Received: by 10.103.198.20 with SMTP id a20mr958118muq.114.1248987740153; Thu, 30 Jul 2009 14:02:20 -0700 (PDT) In-Reply-To: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> Date: Thu, 30 Jul 2009 17:02:20 -0400 Message-ID: <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> From: stephen botzko To: Mikael Abrahamsson , codec@ietf.org Content-Type: multipart/alternative; boundary=0016369fa20d94a81e046ff29e96 Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:02:22 -0000 --0016369fa20d94a81e046ff29e96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree overall, and am happy to see some consensus on importance of the characterization and testing, But to be fair, the issues with jitter and packet loss are generally due to the packetization constraints in the RTP RFC, not the ITU-T spec itself. G.719's packetization RFC allows for interleaved and overlapped (redundant) audio frames, and permits the duplicate frames to be at lower rates. That allows for good quality to be maintained under packet loss conditions (though if the network is congested, of course you need to use an overall lower rate).. All the codecs I've used will recover state very quickly when conditions improve. I can't see how the codec can solve an end-to-end delay problem, it seems to me that if the delay doesn't heal itself when conditions improve, it is likely to be a transport problem that the codec can't influence. Regards, Stephen Botzko Polycom On Thu, Jul 30, 2009 at 4:42 PM, Mikael Abrahamsson wrote: > On Fri, 31 Jul 2009, Slava Borilin wrote: > > During the work of the WG, if its formed, definitely we will deploy the >> correct process for codec evaluation, with the help and aids from others who >> are skilled in this, like you and Stephen hopefully. >> > > As I stated at the microphone during the session, the most important aspect > I see an a network engineer is that the Internet behaviour needs to drive > both the codec design and how it's transported, not the other way around. > Codecs can't set demand on how the Internet should behave, it just doesn't > work in the real world. > > If you can't make a codec that can gracefully handle intermittent 2 second > packet jitter and 10% packetloss and then go back to good quality/end-to-end > delay again when conditions improve, then you have to realise what you're > doing isn't not suitable to fit on the Internet. > > The codecs I've seen before in the ITU space has completely dropped the > ball here (mainly experience from G.711 and G.729 here though). > > As soon as I see 20 ms jitter tolerances and 0.5% packet loss to reach > decent MOS values I get.... errr.. tired. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016369fa20d94a81e046ff29e96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree overall, and am happy to see some consensus on importance of t= he characterization and testing,
=A0
But to be fair, the issues with jitter and packet loss are generally d= ue to the packetization=A0constraints in the RTP RFC, not the ITU-T spec it= self.=A0 G.719's packetization RFC allows for interleaved and overlappe= d (redundant) audio frames, and permits the duplicate frames to be at lower= rates.=A0 That allows for good quality to be maintained under packet loss = conditions (though if the network is congested, of course you need to use a= n overall lower rate)..=A0 All the codecs I've used will recover state = very quickly when conditions improve.=A0 I can't see how the codec can = solve an end-to-end delay problem, it seems to me that if the delay doesn&#= 39;t heal itself when conditions improve, it is likely to be a transport pr= oblem that the codec can't influence.
=A0
Regards,
Stephen Botzko
Polycom

On Thu, Jul 30, 2009 at 4:42 PM, Mikael Abrahams= son <swmike@swm.pp= .se> wrote:
On Fri, 31 Jul 2009, Slava Borilin wrote:

During the work of the WG, if it= s formed, definitely we will deploy the correct process for codec evaluatio= n, with the help and aids from others who are skilled in this, like you and= Stephen hopefully.

As I stated at the microphone during the session, th= e most important aspect I see an a network engineer is that the Internet be= haviour needs to drive both the codec design and how it's transported, = not the other way around. Codecs can't set demand on how the Internet s= hould behave, it just doesn't work in the real world.

If you can't make a codec that can gracefully handle intermittent 2= second packet jitter and 10% packetloss and then go back to good quality/e= nd-to-end delay again when conditions improve, then you have to realise wha= t you're doing isn't not suitable to fit on the Internet.

The codecs I've seen before in the ITU space has completely dropped= the ball here (mainly experience from G.711 and G.729 here though).
As soon as I see 20 ms jitter tolerances and 0.5% packet loss to reach dec= ent MOS values I get.... errr.. tired.

--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se= =20

_______________________________________________
co= dec mailing list
cod= ec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

--0016369fa20d94a81e046ff29e96-- From stewe@stewe.org Thu Jul 30 14:14:59 2009 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 7DA5E3A69D4 for ; Thu, 30 Jul 2009 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.850, 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 4g+5yZIInonh for ; Thu, 30 Jul 2009 14:14:58 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 066063A67E4 for ; Thu, 30 Jul 2009 14:14:57 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 366102-1743317 for multiple; Thu, 30 Jul 2009 23:14:58 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 30 Jul 2009 14:14:50 -0700 From: Stephan Wenger To: Slava Borilin , Alexander Chemeris , Message-ID: Thread-Topic: [codec] Technical Considerations additions Thread-Index: AcoRVt/jzH2hKWG5THqDDIXzba9wWwAAEteQAADmr/w= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:14:59 -0000 Hi Slava, I don't think the BOF "agreed" to anything, nor it has a mandate to agree to anything. Hi Alexander, According to my dim recollection of the discussions at the time, the reasons for the complexity of the negotiation process in the AMR-WB payload (RFC 4867) lies in the (IMHO very desirable) backward compatibility of AMR-WB to AMR---the by far widest deployed speech codec on the planet. Whenever you have an organic and backward compatible development of a technology, you add options and make the capability exchange more complex. Assuming that this will not happen for a from-scratch designed codec is shortsighted---simply because, over time, one will want to support more modes (and or more codecs). The main issue is that SIP has been extremely weak in its capability exchange mechanisms. This is about to get fixed. With respect to the in-band signaling: I think there may be a small misunderstanding here. AMR-WB, AFAIK, contains a complete set of inband signals---the bitstream is self-contained. The designers of the AMR-WB payload format simply gave the users the option to select their preferred modes, instead of requiring the support of all of those modes. The tradeoff that matters here is between implementation complexity in the signal processing part, and implementation complexity in the capability-exchange (SDP) part. I personally believe that a lot of payload formats have gotten this tradeoff wrong, and the AMR-WB payload format may be one of those. But that's an issue that's most easily fixed in future payload designs (which clearly is in the IETF's realm), and has very little to do with the codec design itself. Regards, Stephan On 7/30/09 1:51 PM, "Slava Borilin" wrote: > Thanks Alexander, > > that's exactly the type of input which is important define the > "internet" requirements to the codec, which will lead us to the either > selection, or design of the one which satisfy the technical goals, while > being easily accessible and freely distributable. > > And that's (one more) proof why BOF agreed today that we @IETF have the > expertise to define the scope of work (and probably we have even more > expertise in this specific area then other SDOs). > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Alexander Chemeris > Sent: Thursday, July 30, 2009 10:46 PM > To: codec@ietf.org > Subject: [codec] Technical Considerations additions > > Hello, > > Just to make a note of proposed additions to technical considerations, > which were seen on the jabber conference: > > 1) Requirement/non requirement of stereo and/or multichannel > 2) Good performance in the presence of packet loss > 3) Compatibility with negotiation schemes widely used over > the Internet. > > Points (1) and (2) are obvious and seem to leak from the consideration > just by occasion, but I want to slightly elaborate on point (3). > > A non-technical point, which was not clearly defined, but I think is > very important: > > * Considered codecs must be standardized. In ITU, IETF, wherever, > but there should be a clean standard allowing creation of compatible > 3rd party implementation. > > = Introduction for non-VoIP developers = > > SIP is one of the most widely used and well known VoIP signaling and it > do use venerable SDP (RFC2327) for codec negotiation. The recommended > way to negotiate codecs with SDP is a so-called Offer/Answer Model > (RFC3264). Simply speaking, one side offers a codec set and the other > side can either accept a specific codec or reject its use. > > = The problem = > > SDP was clearly designed for the use with old-fashion codecs which > supported only one or few operating modes, usually just a set of few > different bitrates. But modern codecs tend to be a beasts of different > kind they offer a plenty of configuration options users have to choose > from. I know two examples of such codecs - Speex and AMR(-WB), > probably IPMR goes a similar way, but I'm not familiar with it. > For RTP payload and SDP negotiation of Speex look into RFC 5574, > for AMR and AMR-WB look into RFC5574. > > So, the tale is about AMR(-WB) which has few horrible statements > in the RFC about SDP negotiation, worst of which is: > > - Each combination of the RTP payload transport format > configuration parameters (octet-align, crc, robust-sorting, > interleaving, and channels) is unique in its bit-pattern and > not compatible with any other combination. [...] > > This means that if you want to support several combinations of > parameters, SDP offer will blow up into a huge list of different > parameter combinations. That's the problem, because SDP plus > SIP header should fit into UDP packet size (you can use TCP, > but it's much better to fit into UDP, isn't it?) and wasting payload > type numbers. > But this problem won't be that sharp if every VoIP developer read > RFC carefully with the full understanding of them and implement > everything as written. Instead, many developers assume that > defaults are fine and don't have time or willing to read or implement > such a complex operation. No need to say I've seen implementations > which ignored even "octet-align" fmtp parameter, trying to guess > it from the actual data. > When I implemented AMR(-WB) payload for our SIP stack I some > more inconveniences and even one collision in a RFC, but alas > I can't recall details now. I should have documented the problem > that time and not rely on my memory.. > > Speex does a better job here, as it does not have incompatible > sets of features. I.e. every stream, produced by an encoder can > be at least correctly passed if not decoded by a decoder. > > The moral of that story is that ideal VoIP codec should not > assume a fixed number of parameter sets in endpoints, as > AMR does, and rely on SDP for features offer. Rather it should > use in-band signaling as much as possible to offload SDP > and make codec API "programmer-friendly". From ingemar.s.johansson@ericsson.com Thu Jul 30 14:21:57 2009 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 22E4A3A6CB3 for ; Thu, 30 Jul 2009 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, 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 VC7tBIL4tyJx for ; Thu, 30 Jul 2009 14:21:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9F1BB3A6B54 for ; Thu, 30 Jul 2009 14:21:53 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-d1-4a720ee9e109 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C0.F7.20235.AEE027A4; Thu, 30 Jul 2009 23:21:51 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 23:21:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 23:21:37 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRW7jk2O9Ph+dqQ/aW+JYsw+8Cmw== References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com> From: "Ingemar Johansson S" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 30 Jul 2009 21:21:39.0514 (UTC) FILETIME=[BA1561A0:01CA115B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:21:57 -0000 Hi Sorry to say that this is just desinformation. If the objective is to convince the average IETF'er then you may score a few points but people who are active in speech coding in other standards foras and happen to read threads like this will only see it as narrowminded propaganda.=20 It has probably been said before...=20 Speech codec develepment and specification of speech services done in other standards foras today are mainly targeting packet switched transport, jitter and packet loss is nothing new, it makes me equally tired to see that numerous proponents of a codec WG try to convince the IETF that we are going to solve a problem that the other standards foras did not know existed, it is just wrong ! /Ingemar =20 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Sent: den 30 juli 2009 22:42 > To: codec@ietf.org > Subject: Re: [codec] Codec Standardization Expertise >=20 > On Fri, 31 Jul 2009, Slava Borilin wrote: >=20 > > During the work of the WG, if its formed, definitely we will deploy=20 > > the correct process for codec evaluation, with the help and=20 > aids from=20 > > others who are skilled in this, like you and Stephen hopefully. >=20 > As I stated at the microphone during the session, the most=20 > important aspect I see an a network engineer is that the=20 > Internet behaviour needs to drive both the codec design and=20 > how it's transported, not the other way around. Codecs can't=20 > set demand on how the Internet should behave, it just doesn't=20 > work in the real world. >=20 > If you can't make a codec that can gracefully handle=20 > intermittent 2 second packet jitter and 10% packetloss and=20 > then go back to good quality/end-to-end delay again when=20 > conditions improve, then you have to realise what you're=20 > doing isn't not suitable to fit on the Internet. >=20 > The codecs I've seen before in the ITU space has completely=20 > dropped the ball here (mainly experience from G.711 and G.729=20 > here though). >=20 > As soon as I see 20 ms jitter tolerances and 0.5% packet loss=20 > to reach decent MOS values I get.... errr.. tired. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 From Borilin@spiritdsp.com Thu Jul 30 14:24:21 2009 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 43A483A67F2 for ; Thu, 30 Jul 2009 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 7kkxV0UjbhsP for ; Thu, 30 Jul 2009 14:24:20 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id E95B83A6D2D for ; Thu, 30 Jul 2009 14:24:00 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6ULO0Rw081031; Fri, 31 Jul 2009 01:24:00 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 01:23:48 +0400 Message-ID: In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRW7jk2O9Ph+dqQ/aW+JYsw+8CmwAAEsbw References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> From: "Slava Borilin" To: "Ingemar Johansson S" , "Mikael Abrahamsson" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:24:21 -0000 ;-) best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Ingemar Johansson S Sent: Thursday, July 30, 2009 11:22 PM To: Mikael Abrahamsson; codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise Hi Sorry to say that this is just desinformation. If the objective is to convince the average IETF'er then you may score a few points but people who are active in speech coding in other standards foras and happen to read threads like this will only see it as narrowminded propaganda.=20 It has probably been said before...=20 Speech codec develepment and specification of speech services done in other standards foras today are mainly targeting packet switched transport, jitter and packet loss is nothing new, it makes me equally tired to see that numerous proponents of a codec WG try to convince the IETF that we are going to solve a problem that the other standards foras did not know existed, it is just wrong ! /Ingemar =20 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Sent: den 30 juli 2009 22:42 > To: codec@ietf.org > Subject: Re: [codec] Codec Standardization Expertise >=20 > On Fri, 31 Jul 2009, Slava Borilin wrote: >=20 > > During the work of the WG, if its formed, definitely we will deploy=20 > > the correct process for codec evaluation, with the help and=20 > aids from=20 > > others who are skilled in this, like you and Stephen hopefully. >=20 > As I stated at the microphone during the session, the most=20 > important aspect I see an a network engineer is that the=20 > Internet behaviour needs to drive both the codec design and=20 > how it's transported, not the other way around. Codecs can't=20 > set demand on how the Internet should behave, it just doesn't=20 > work in the real world. >=20 > If you can't make a codec that can gracefully handle=20 > intermittent 2 second packet jitter and 10% packetloss and=20 > then go back to good quality/end-to-end delay again when=20 > conditions improve, then you have to realise what you're=20 > doing isn't not suitable to fit on the Internet. >=20 > The codecs I've seen before in the ITU space has completely=20 > dropped the ball here (mainly experience from G.711 and G.729=20 > here though). >=20 > As soon as I see 20 ms jitter tolerances and 0.5% packet loss=20 > to reach decent MOS values I get.... errr.. tired. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jmh@joelhalpern.com Thu Jul 30 14:26:17 2009 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 1D6ED3A6B54 for ; Thu, 30 Jul 2009 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, 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 e28oTXv13qpg for ; Thu, 30 Jul 2009 14:26:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 369B43A6AFD for ; Thu, 30 Jul 2009 14:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5C10D4303E6; Thu, 30 Jul 2009 14:26:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.43.1.29] (unknown [77.241.97.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A70794302F1; Thu, 30 Jul 2009 14:26:14 -0700 (PDT) Message-ID: <4A720FF2.2040602@joelhalpern.com> Date: Thu, 30 Jul 2009 17:26:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Slava Borilin , "codec@ietf.org" References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:26:17 -0000 Slava, my apologies if you, or anyone else who works extensively with codec, understood my note as suggesting that you asked for what was suggested. Those of you who work with codecs extensively seem (to the extent I am competent to judge) to know your business. My point was rather that the community that is supposed to evaluate the working group product, outside of the WG, has serious misconceptions about what it takes to do the work, to evaluate the work, to test the work, and all the other aspects. And I was using this comment by a respected IETF participant as an exemplar of my concern about the misfit between the IETF community and this problem space. (And the real point is not even the person who said it. Rather it is the communities reaction to the statement.) Yours, Joel Slava Borilin wrote: > Joel, > > We (SPIRIT Skype XIPH at least) don't expect "ear test". > We are just saying for the time being, that the methods are rather > "well-defined" for judging the codec quality in terms of mos score, so > there was no the main focus for todays BOF. > > During the work of the WG, if its formed, definitely we will deploy the > correct process for codec evaluation, with the help and aids from others > who are skilled in this, like you and Stephen hopefully. > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Joel M. Halpern > Sent: Thursday, July 30, 2009 10:15 PM > To: codec@ietf.org > Subject: Re: [codec] Codec Standardization Expertise > > (Many useful comments elided, to focus on one.) > In fact, the community response to this comment (about evaluating > codecs) is symptomatic of the expertise problem. I know just enough > abou this space to know that random pairs of ears, even random pairs of > high quality ears, are not sufficient to evaluate whether a codec does a > > good job, much less a good job across all of the requirements. > However, like many communities, and like many problem areas, we tend to > assume we understand more than we do. So folks like the idea of just > using peoples ears to evaluate the codecs in some simple fashion. > > Yours, > Joel M. Halpern > > stephen botzko wrote: > ... >> (2) Over the audio stream I heard a comment to the effect that "anyone > >> with two ears is competent to evaluate codec quality". Lots of >> applause. I think this statement is naive and dangerously misleading. > >> People with ears clearly listened to iLBC, and apparently still missed > >> its issue with tonal languages. (Yes its experimental and wasn't >> adequately reviewed. That is the point). >> >> It is true that anyone who can hear can serve as a test subject. But >> reviewing/validating the test plan and the observed results is not >> something that anyone can do. This is not to say that there is no one > >> in the IETF who has the skills. But I am still thinking that the >> discussions so far are seriously understating the importance of proper > >> characterization and testing. The bulk of the time in other SDOs is >> spent on requirements definition and testing questions. The actual >> algoriithm development is treated as a homework assignment. > ... >> Regards, >> Stephen Botzko >> Polycom >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 simon.perreault@viagenie.ca Thu Jul 30 14:33:17 2009 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 D43593A68E0 for ; Thu, 30 Jul 2009 14:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 otFfSM5sA3Us for ; Thu, 30 Jul 2009 14:33:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9879C3A6C4F for ; Thu, 30 Jul 2009 14:33:15 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 58F9529E15E0; Thu, 30 Jul 2009 17:33:14 -0400 (EDT) Received: from powerbook-g4-15-de-simon-perreault-2.local (unknown [212.112.167.85]) by jazz.viagenie.ca (Postfix) with ESMTP id A0DC229E15B5; Thu, 30 Jul 2009 17:33:09 -0400 (EDT) Message-ID: <4A721189.5000704@viagenie.ca> Date: Thu, 30 Jul 2009 23:32:57 +0200 From: Simon Perreault User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Joel M. Halpern" References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <4A720FF2.2040602@joelhalpern.com> In-Reply-To: <4A720FF2.2040602@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Slava Borilin , "codec@ietf.org" Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:33:17 -0000 Of course the people of the IETF community know that evaluating a codec is not done by ears alone. The applause was in the same spirit as if "THIS IS SPARTA!" had been shouted. For comic relief. Can we stop with the ad hominem arguments now and get to work on the charter? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From stephen.botzko@gmail.com Thu Jul 30 14:40:59 2009 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 B56103A6A50 for ; Thu, 30 Jul 2009 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.522, 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 LZj3qTTBWd6O for ; Thu, 30 Jul 2009 14:40:57 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id CDADD3A6A4E for ; Thu, 30 Jul 2009 14:40:56 -0700 (PDT) Received: by fxm26 with SMTP id 26so990437fxm.42 for ; Thu, 30 Jul 2009 14:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KyjPEw6CaLyRm7bshJ3nyT1y1YxT6/iAw+A+rkMI/pc=; b=Ox4ERnbqqGkO7iljWoAMtmdyDWRiIVd4Q+Z7Y1uHQuIXskfpXVCjxIXaebuHMHnOaA JBscWklQuRi3JW4hjku7y1Jmd875AS/p+6llM3lvYQJRTDaHUdRQqEZ24K7nfaBVrAIJ NBFbsiP3433laMCDjnp4By2eYCuZOg7UI/qrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gy/rUmTrw57fvKveWGTnikSq9IWxCG8xc/r4Vd7rm5j+vWS4cFD7TVuXnbWtFo9UZD 8CexiCGVjhMw0HFnr52A4HQA4ZcNB23U/pqyHuMX7VxlLaB6+fdXeU7Kn06ZLmJdLQje fYqnXVOeJD9kPzLRKizwDt0QNHtm/1o0QftM4= MIME-Version: 1.0 Received: by 10.103.238.13 with SMTP id p13mr993078mur.96.1248990054352; Thu, 30 Jul 2009 14:40:54 -0700 (PDT) In-Reply-To: <4A721189.5000704@viagenie.ca> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <4A720FF2.2040602@joelhalpern.com> <4A721189.5000704@viagenie.ca> Date: Thu, 30 Jul 2009 17:40:54 -0400 Message-ID: <6e9223710907301440m7a4f438ag625c1023054725e0@mail.gmail.com> From: stephen botzko To: Simon Perreault Content-Type: multipart/alternative; boundary=0016367ed52e848a20046ff3285a Cc: "codec@ietf.org" , Slava Borilin Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 21:40:59 -0000 --0016367ed52e848a20046ff3285a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't think I made any ad hominem arguments. Hopefully that wasn't aimed at me. Listening on the audio feed, it absolutely sounded like several members thought precisely that. The comment was repeated several times, and was never contradicted. Without being there, it was hard to read the mood. But it didn't sound like comic relief over the air. Regards, Stephen Botzko Polycom On Thu, Jul 30, 2009 at 5:32 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Of course the people of the IETF community know that evaluating a codec > is not done by ears alone. > > The applause was in the same spirit as if "THIS IS SPARTA!" had been > shouted. For comic relief. > > Can we stop with the ad hominem arguments now and get to work on the > charter? > > Thanks, > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367ed52e848a20046ff3285a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think I made any ad hominem arguments.=A0 Hopefully that wasn&#= 39;t aimed at me.

Listening on the audio feed, it absolutely sounded= like several members thought precisely that.=A0 The comment was repeated s= everal times, and was never contradicted.=A0

Without being there, it was hard to read the mood. But it didn't so= und like comic relief over the air.

Regards,
Stephen Botzko
Po= lycom

On Thu, Jul 30, 2009 at 5:32 PM, Si= mon Perreault <simon.perreault@viagenie.ca> wrote:
Of course the peo= ple of the IETF community know that evaluating a codec
is not done by ears alone.

The applause was in the same spirit as if "THIS IS SPARTA!" had b= een
shouted. For comic relief.

Can we stop with the ad hominem arguments now and get to work on the
charter?

Thanks,
Simon
--
DNS64 open-source =A0 --> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0--> http://numb.viagenie.ca
vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org
__________________________________= _____________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016367ed52e848a20046ff3285a-- From alexander.chemeris@gmail.com Thu Jul 30 15:02:58 2009 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 852113A699C for ; Thu, 30 Jul 2009 15:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 J1Mf1yFJtc8D for ; Thu, 30 Jul 2009 15:02:57 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1E1853A67F2 for ; Thu, 30 Jul 2009 15:02:56 -0700 (PDT) Received: by bwz19 with SMTP id 19so886797bwz.37 for ; Thu, 30 Jul 2009 15:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=C9IRm9r9Y8gydRP+5Mtx4NyFUsw0vF2EuWUz7V2fpaU=; b=uvUL8Bqt80m01MpwqLZT3bSWei/+pId/1kv18kSqMFJFlu3uP5c8IoxzCPYLIcgjq2 Wy4fCNXpOcDfrwogfGQPNkMJBm9FSTozPAa1kpssTWHresi+7/xEe/zAcQTJiirHB5Hx Pbuw9884m163w3YtWgPY8YXX9ztfTrosLtYos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=SJsUnOOwKrHlgdxnPgnZxY9BI9YsEudaRgXZwj0qEzZVfi138njofL/iPVsmihkx+4 dGpFdHm4vIdVLvuhvxZDLNgOY1Zg2yHmMiUWydWbvAIufMoQW7/onr0v2UqyAt2rBy5R 71djSvYYImDMWyvyJnX2I87Zjrgxe4ImbvcbM= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.241.5 with SMTP id t5mr999757mur.123.1248991374748; Thu, 30 Jul 2009 15:02:54 -0700 (PDT) In-Reply-To: References: From: Alexander Chemeris Date: Fri, 31 Jul 2009 02:02:34 +0400 X-Google-Sender-Auth: 7694f88ab8cab034 Message-ID: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> To: Stephan Wenger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 22:02:58 -0000 Hi, Stephan On Fri, Jul 31, 2009 at 01:14, Stephan Wenger wrote: > According to my dim recollection of the discussions at the time, the reas= ons > for the complexity of the negotiation process in the AMR-WB payload (RFC > 4867) lies in the (IMHO very desirable) backward compatibility of AMR-WB = to > AMR---the by far widest deployed speech codec on the planet. =C2=A0Whenev= er you > have an organic and backward compatible development of a technology, you = add > options and make the capability exchange more complex. =C2=A0Assuming tha= t this > will not happen for a from-scratch designed codec is shortsighted---simpl= y > because, over time, one will want to support more modes (and or more > codecs). Yeah, mode selection is a part of the problem, but it's natural and can't be solved without a SDP. I rather blame the set of incompatible codec packaging options. If you want octet-aligned stream with crc it is not even parsable by decoder which expects octet-aligned stream without crc. Why not to specify that for VoIP we want octet-aligned (or not octet-aligned) version of the codec? I think that diversity of settings were developed by ITU-T to make every single use-case possible, to be possible to optimize for the slightly lower bandwidth in one case and for slightly less CPU power in other case, etc. But IMHO gained diversity does not cost the increased implementation burden. Look at MPEG video codecs - you may not support some features, but you are always able to at least parse the stream. What VoIP "end-developers" want is a simple codec, which produce "frames", which can be simply put into RTP without a lot of headache. Not this hell of AMR packaging. >=C2=A0The main issue is that SIP has been extremely weak in its > capability exchange mechanisms. =C2=A0This is about to get fixed. Right. But I'm not aware that it will be fixed before this Christmas. Do yo= u? ;) > With respect to the in-band signaling: I think there may be a small > misunderstanding here. =C2=A0AMR-WB, AFAIK, contains a complete set of in= band > signals---the bitstream is self-contained. =C2=A0The designers of the AMR= -WB > payload format simply gave the users the option to select their preferred > modes, instead of requiring the support of all of those modes. No, read my rants incompatible encodings above. > The tradeoff > that matters here is between implementation complexity in the signal > processing part, and implementation complexity in the capability-exchange > (SDP) part. =C2=A0I personally believe that a lot of payload formats have= gotten > this tradeoff wrong, and the AMR-WB payload format may be one of those. = =C2=A0But > that's an issue that's most easily fixed in future payload designs (which > clearly is in the IETF's realm), and has very little to do with the codec > design itself. Not exactly. This CAN be fixed in IETF by defining a cool RTP payload which will add additional in-band signalling, but isn't it nicer to have a self-contained codec, which just produces "frames" and does not need any fancy packaging and additional signaling? Look at Speex as an example of pretty good implementation of this paradigm. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From kpfleming@digium.com Thu Jul 30 15:24:39 2009 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 7FDB53A68D6 for ; Thu, 30 Jul 2009 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DTNrxxK4QBoc for ; Thu, 30 Jul 2009 15:24:38 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 83B013A6B54 for ; Thu, 30 Jul 2009 15:24:30 -0700 (PDT) Received: from kildare.digium.internal ([10.24.20.235]) by mail.digium.com with esmtp (Exim 4.63) (envelope-from ) id 1MWe2v-0000k4-D6 for codec@ietf.org; Thu, 30 Jul 2009 17:24:21 -0500 Message-ID: <4A721D9F.5000605@digium.com> Date: Thu, 30 Jul 2009 17:24:31 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 CC: codec@ietf.org References: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> In-Reply-To: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 22:24:39 -0000 Alexander Chemeris wrote: > Not exactly. This CAN be fixed in IETF by defining a cool RTP payload > which will add additional in-band signalling, but isn't it nicer to > have a self-contained codec, which just produces "frames" and does not > need any fancy packaging and additional signaling? Look at Speex as an > example of pretty good implementation of this paradigm. This is also an important issue for SIP B2BUAs, when media streams from two endpoints must be connected together even though they may not have originally been connected (think call transfers, for example). With SDP complexity of the sort present with AMR-WB (or video codecs), it's not practically possible for the B2BUA to determine whether the current media formats being used by the endpoints are compatible, even though they may be same codec and sample rate. With Speex, at least, it's always safe to send any Speex stream to a decoder, even if it wasn't produced using the parameters the decoder specified during negotiation, but I'm not aware of any other existing codecs for which that would work. This results in the B2BUA having to completely understand all the interactions of the codec parameters to determine whether two streams are 'compatible', or whether renegotiation (or worse, transcoding) is needed. Moving the codec parameter negotiation into the codec bitstream resolves this issue completely, and means that only the actual endpoints that contain implementations of the codec have to understand the interactions between its parameters. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From steveu@coppice.org Thu Jul 30 18:32:13 2009 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 698383A6B6F for ; Thu, 30 Jul 2009 18:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 1ixc8wJCxn34 for ; Thu, 30 Jul 2009 18:32:12 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 51ABB3A6A08 for ; Thu, 30 Jul 2009 18:32:11 -0700 (PDT) Received: from xeon.coppice.org (110.202.17.210.dyn.pacific.net.hk [210.17.202.110]) by cwb.pacific.net.hk with ESMTP id n6V1W7XU026800; Fri, 31 Jul 2009 09:32:08 +0800 Message-ID: <4A724997.6010908@coppice.org> Date: Fri, 31 Jul 2009 09:32:07 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> <4A721D9F.5000605@digium.com> In-Reply-To: <4A721D9F.5000605@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 01:32:13 -0000 Kevin P. Fleming wrote: > Alexander Chemeris wrote: > > >> Not exactly. This CAN be fixed in IETF by defining a cool RTP payload >> which will add additional in-band signalling, but isn't it nicer to >> have a self-contained codec, which just produces "frames" and does not >> need any fancy packaging and additional signaling? Look at Speex as an >> example of pretty good implementation of this paradigm. >> > > This is also an important issue for SIP B2BUAs, when media streams from > two endpoints must be connected together even though they may not have > originally been connected (think call transfers, for example). With SDP > complexity of the sort present with AMR-WB (or video codecs), it's not > practically possible for the B2BUA to determine whether the current > media formats being used by the endpoints are compatible, even though > they may be same codec and sample rate. With Speex, at least, it's > always safe to send any Speex stream to a decoder, even if it wasn't > produced using the parameters the decoder specified during negotiation, > but I'm not aware of any other existing codecs for which that would work. > > This results in the B2BUA having to completely understand all the > interactions of the codec parameters to determine whether two streams > are 'compatible', or whether renegotiation (or worse, transcoding) is > needed. > > Moving the codec parameter negotiation into the codec bitstream resolves > this issue completely, and means that only the actual endpoints that > contain implementations of the codec have to understand the interactions > between its parameters. > Codec mode information in the RTP stream is always fragile, due to the possibility of packet loss. However, codec mode information in the RTP stream during route switching is a truly terrible idea. It is very common for the first X packets of an RTP stream to go missing, for various reasons. Anything while relies on a perfectly clean packet flow at startup is a non-starter. Steve From swmike@swm.pp.se Thu Jul 30 22:01:30 2009 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 EF59A3A69D1 for ; Thu, 30 Jul 2009 22:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 pTNjUcyPnSTk for ; Thu, 30 Jul 2009 22:01:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 210843A6993 for ; Thu, 30 Jul 2009 22:01:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B49BA9E; Fri, 31 Jul 2009 07:01:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B2AC69A; Fri, 31 Jul 2009 07:01:29 +0200 (CEST) Date: Fri, 31 Jul 2009 07:01:29 +0200 (CEST) From: Mikael Abrahamsson To: Ingemar Johansson S In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 05:01:31 -0000 On Thu, 30 Jul 2009, Ingemar Johansson S wrote: > Speech codec develepment and specification of speech services done in > other standards foras today are mainly targeting packet switched > transport, jitter and packet loss is nothing new, it makes me equally > tired to see that numerous proponents of a codec WG try to convince the > IETF that we are going to solve a problem that the other standards foras > did not know existed, it is just wrong ! So what codec and *transport* that someone else has standardized will work in the conditions I stated? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jul 30 22:17:25 2009 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 0E6493A697A for ; Thu, 30 Jul 2009 22:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 TOyCy9oOfYma for ; Thu, 30 Jul 2009 22:17:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 0A4DE3A67C2 for ; Thu, 30 Jul 2009 22:17:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C3B6D9E; Fri, 31 Jul 2009 07:17:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C10189A for ; Fri, 31 Jul 2009 07:17:24 +0200 (CEST) Date: Fri, 31 Jul 2009 07:17:24 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 05:17:25 -0000 On Thu, 30 Jul 2009, stephen botzko wrote: > But to be fair, the issues with jitter and packet loss are generally due > to the packetization constraints in the RTP RFC, not the ITU-T spec > itself. G.719's packetization RFC allows for interleaved and overlapped > (redundant) audio frames, and permits the duplicate frames to be at > lower rates. That allows for good quality to be maintained under packet > loss conditions (though if the network is congested, of course you need > to use an overall lower rate).. All the codecs I've used will recover > state very quickly when conditions improve. I can't see how the codec > can solve an end-to-end delay problem, it seems to me that if the delay > doesn't heal itself when conditions improve, it is likely to be a > transport problem that the codec can't influence. We need to design something that works, and that involves creating a codec and a transport that handles the real world, not trying to adapt the real world to the constraints of the codec and transport. Saying you need a lower rate in case of congestion isn't the case either, that won't help yourself anything because you're most likely competing with TCP flows which will take all they can get. What you need to do is "stand your ground", perhaps go for lower sound quality but keep the bitrate so the packets you actually get through will make sounds at the other end that is as good as it can get during the conditions. G.719 might do this as you say, I don't know. We need a codec and transport that when faced with adverse network conditions will handle this gracefully and adapt its jitter buffer (if jitter increases to 1s, it should increase its jitter buffer to handle this, then when network conditions improve it needs to somehow lower the jitter buffer again which means it'll have to play sound "faster" to catch up). All this needs to work between the codec/transport layers, and information regarding sound needs to be spread across several packets in case of packet loss (degrade sound quality nicely), and to retain the low end-to-end delay when network conditions are good, it also needs to go back to the usual "all sound for these 20ms sound in one packet"-mode for that. So the codec and underlying transport cannot *influence* the network IP behavior, but it needs to be able to ADAPT to it and handle it, providing as good user experience as possible. -- Mikael Abrahamsson email: swmike@swm.pp.se From ingemar.s.johansson@ericsson.com Thu Jul 30 22:46:11 2009 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 235BF3A6999 for ; Thu, 30 Jul 2009 22:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.558 X-Spam-Level: X-Spam-Status: No, score=-5.558 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, HELO_EQ_SE=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 yVSptzoDdm+W for ; Thu, 30 Jul 2009 22:46:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4972D3A67C2 for ; Thu, 30 Jul 2009 22:46:09 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-ef-4a72851f817b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0E.A7.20235.F15827A4; Fri, 31 Jul 2009 07:46:07 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 07:46:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 07:46:05 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018ECE8A@esealmw109.eemea.ericsson.se> In-Reply-To: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Technical Considerations additions Thread-Index: AcoRojHjIELuokn+RlmwEXXGQr//8Q== References: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> From: "Ingemar Johansson S" To: "Alexander Chemeris" X-OriginalArrivalTime: 31 Jul 2009 05:46:07.0263 (UTC) FILETIME=[33115AF0:01CA11A2] X-Brightmail-Tracker: AAAAAA== Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 05:46:11 -0000 Hi I believe that in the AMR case it is very important to be able to = distinguish between the apples and the oranges. AMR was originally = designed for circuit switched access and therefore some extra parameters = such as allowed mode sets, mode change period and mode change neighbor = is in the negotiation, these parameters are there simply make = interworking between a PS and a CS domain possible (and avoid = transcoding). AMR is heavily used in mobile telephones (CS) and just = because we start to think VoIP we cannot just pretend that CS does not = exist overnight. There is even a Q bit to tell that part of the payload is bad (something = that in practice only happens in a CS environment, may happen with = UDP-Lite) Now for a PS to PS call, all that stuff is not needed anymore UDP-Lite = may be used though but I have to see evidence of it). If you envision = only PS to PS you can skip all the above things in your negotiation. The octet aligned and bandwidth efficient modes are there to satisfy the = requirements. If you look into 3GPP spec TS26.114 you will find more info about this. = =20 Or why not have a look in this book=20 http://www.wiley-vch.de/publish/dt/books/bySubjectEE00/bySubSubjectEE25/0= -470-05855-2/?sID=3Dnqk9adkt7hm033ice0kp7jh3v4 /Ingemar > -----Original Message----- > From: Alexander Chemeris [mailto:Alexander.Chemeris@sipez.com]=20 > Sent: den 31 juli 2009 00:03 > To: Stephan Wenger > Cc: Slava Borilin; codec@ietf.org > Subject: Re: [codec] Technical Considerations additions >=20 > Hi, Stephan >=20 > On Fri, Jul 31, 2009 at 01:14, Stephan Wenger wrote: > > According to my dim recollection of the discussions at the=20 > time, the=20 > > reasons for the complexity of the negotiation process in the AMR-WB=20 > > payload (RFC > > 4867) lies in the (IMHO very desirable) backward compatibility of=20 > > AMR-WB to AMR---the by far widest deployed speech codec on=20 > the planet. =A0 > > Whenever you have an organic and backward compatible=20 > development of a=20 > > technology, you add options and make the capability exchange more=20 > > complex. =A0Assuming that this will not happen for a from-scratch=20 > > designed codec is shortsighted---simply because, over time,=20 > one will=20 > > want to support more modes (and or more codecs). >=20 > Yeah, mode selection is a part of the problem, but it's=20 > natural and can't be solved without a SDP. I rather blame the=20 > set of incompatible codec packaging options. If you want=20 > octet-aligned stream with crc it is not even parsable by=20 > decoder which expects octet-aligned stream without crc. Why=20 > not to specify that for VoIP we want octet-aligned (or not=20 > octet-aligned) version of the codec? I think that diversity=20 > of settings were developed by ITU-T to make every single=20 > use-case possible, to be possible to optimize for the=20 > slightly lower bandwidth in one case and for slightly less=20 > CPU power in other case, etc. But IMHO gained diversity does=20 > not cost the increased implementation burden. Look at MPEG=20 > video codecs - you may not support some features, but you are=20 > always able to at least parse the stream. What VoIP=20 > "end-developers" want is a simple codec, which produce=20 > "frames", which can be simply put into RTP without a lot of=20 > headache. Not this hell of AMR packaging. >=20 > >=A0The main issue is that SIP has been extremely weak in its =20 > capability=20 > >exchange mechanisms. =A0This is about to get fixed. >=20 > Right. But I'm not aware that it will be fixed before this=20 > Christmas. Do you? ;) >=20 > > With respect to the in-band signaling: I think there may be a small=20 > > misunderstanding here. =A0AMR-WB, AFAIK, contains a complete set of=20 > > inband signals---the bitstream is self-contained. =A0The designers = of=20 > > the AMR-WB payload format simply gave the users the option=20 > to select=20 > > their preferred modes, instead of requiring the support of=20 > all of those modes. >=20 > No, read my rants incompatible encodings above. >=20 > > The tradeoff > > that matters here is between implementation complexity in=20 > the signal=20 > > processing part, and implementation complexity in the=20 > > capability-exchange > > (SDP) part. =A0I personally believe that a lot of payload=20 > formats have=20 > > gotten this tradeoff wrong, and the AMR-WB payload format=20 > may be one=20 > > of those. =A0But that's an issue that's most easily fixed in future=20 > > payload designs (which clearly is in the IETF's realm), and=20 > has very=20 > > little to do with the codec design itself. >=20 > Not exactly. This CAN be fixed in IETF by defining a cool RTP=20 > payload which will add additional in-band signalling, but=20 > isn't it nicer to have a self-contained codec, which just=20 > produces "frames" and does not need any fancy packaging and=20 > additional signaling? Look at Speex as an example of pretty=20 > good implementation of this paradigm. >=20 > -- > Regards, > Alexander Chemeris. >=20 > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 >=20 >=20 From ingemar.s.johansson@ericsson.com Thu Jul 30 23:17:57 2009 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 F341C3A6E80 for ; Thu, 30 Jul 2009 23:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 OKsKhsSqiR67 for ; Thu, 30 Jul 2009 23:17:56 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 86BD43A6CBF for ; Thu, 30 Jul 2009 23:17:55 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-a0-4a728c94ca36 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 51.FD.18827.49C827A4; Fri, 31 Jul 2009 08:17:56 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 08:16:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 08:16:34 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018ECEA6@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRpnQwPZ4tMnPzRcuuSZ29BUTGKg== References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> From: "Ingemar Johansson S" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 31 Jul 2009 06:16:38.0266 (UTC) FILETIME=[766E3DA0:01CA11A6] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 06:17:57 -0000 Hi > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > So what codec and *transport* that someone else has=20 > standardized will work in the conditions I stated? Please have a look at sections 8-10 in=20 http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip In addition annex C contains examples of adaptation state machines Regards Ingemar =20 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Sent: den 31 juli 2009 07:01 > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Codec Standardization Expertise >=20 > On Thu, 30 Jul 2009, Ingemar Johansson S wrote: >=20 > > Speech codec develepment and specification of speech=20 > services done in=20 > > other standards foras today are mainly targeting packet switched=20 > > transport, jitter and packet loss is nothing new, it makes=20 > me equally=20 > > tired to see that numerous proponents of a codec WG try to convince=20 > > the IETF that we are going to solve a problem that the=20 > other standards=20 > > foras did not know existed, it is just wrong ! >=20 > So what codec and *transport* that someone else has=20 > standardized will work in the conditions I stated? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 From hsinnrei@adobe.com Thu Jul 30 23:51:36 2009 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 B568F28C0D7 for ; Thu, 30 Jul 2009 23:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGnZrHPTMUCR for ; Thu, 30 Jul 2009 23:51:35 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 339713A6805 for ; Thu, 30 Jul 2009 23:51:35 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSnKUdv6WrlkpZKRZWCDv4r+fAJ1b+DEI@postini.com; Thu, 30 Jul 2009 23:51:37 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6V6j3ao009928; Thu, 30 Jul 2009 23:45:03 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n6V6pXlT023231; Thu, 30 Jul 2009 23:51:33 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Thu, 30 Jul 2009 23:51:33 -0700 From: Henry Sinnreich To: Alexander Chemeris , "codec@ietf.org" Date: Thu, 30 Jul 2009 23:51:31 -0700 Thread-Topic: [codec] Technical Considerations additions Thread-Index: AcoRVtzEOs4GHPLPS9ayTQfRPOUsKAAVHkK0 Message-ID: In-Reply-To: <3d032e5d0907301346q4ce3209h8de9cdad90f4bf81@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6986113F101hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 06:51:36 -0000 --_000_C6986113F101hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not so sure about > 2) Good performance in the presence of packet loss For two reasons: 1. Broadband networks are not plagued by significant packet loss, 2. If packet loss occurs, it is in the form of long bursts of packet loss= , cutting out words or whole sentences and no codec in the world can correc= t this. Henry On 7/30/09 10:46 PM, "Alexander Chemeris" wr= ote: Hello, Just to make a note of proposed additions to technical considerations, which were seen on the jabber conference: 1) Requirement/non requirement of stereo and/or multichannel 2) Good performance in the presence of packet loss 3) Compatibility with negotiation schemes widely used over the Internet. Points (1) and (2) are obvious and seem to leak from the consideration just by occasion, but I want to slightly elaborate on point (3). A non-technical point, which was not clearly defined, but I think is very important: * Considered codecs must be standardized. In ITU, IETF, wherever, but there should be a clean standard allowing creation of compatible 3rd party implementation. =3D Introduction for non-VoIP developers =3D SIP is one of the most widely used and well known VoIP signaling and it do use venerable SDP (RFC2327) for codec negotiation. The recommended way to negotiate codecs with SDP is a so-called Offer/Answer Model (RFC3264). Simply speaking, one side offers a codec set and the other side can either accept a specific codec or reject its use. =3D The problem =3D SDP was clearly designed for the use with old-fashion codecs which supported only one or few operating modes, usually just a set of few different bitrates. But modern codecs tend to be a beasts of different kind they offer a plenty of configuration options users have to choose from. I know two examples of such codecs - Speex and AMR(-WB), probably IPMR goes a similar way, but I'm not familiar with it. For RTP payload and SDP negotiation of Speex look into RFC 5574, for AMR and AMR-WB look into RFC5574. So, the tale is about AMR(-WB) which has few horrible statements in the RFC about SDP negotiation, worst of which is: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. [...] This means that if you want to support several combinations of parameters, SDP offer will blow up into a huge list of different parameter combinations. That's the problem, because SDP plus SIP header should fit into UDP packet size (you can use TCP, but it's much better to fit into UDP, isn't it?) and wasting payload type numbers. But this problem won't be that sharp if every VoIP developer read RFC carefully with the full understanding of them and implement everything as written. Instead, many developers assume that defaults are fine and don't have time or willing to read or implement such a complex operation. No need to say I've seen implementations which ignored even "octet-align" fmtp parameter, trying to guess it from the actual data. When I implemented AMR(-WB) payload for our SIP stack I some more inconveniences and even one collision in a RFC, but alas I can't recall details now. I should have documented the problem that time and not rely on my memory.. Speex does a better job here, as it does not have incompatible sets of features. I.e. every stream, produced by an encoder can be at least correctly passed if not decoded by a decoder. The moral of that story is that ideal VoIP codec should not assume a fixed number of parameter sets in endpoints, as AMR does, and rely on SDP for features offer. Rather it should use in-band signaling as much as possible to offload SDP and make codec API "programmer-friendly". -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6986113F101hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Technical Considerations additions I am not so sure about

> 2) Good performance in the presence of packet loss

For two reasons:

  1. Broadband networks are not plagued by significa= nt packet loss,
  2. If packet loss occurs, it is in the form of long bu= rsts of packet loss, cutting out words or whole sentences and no codec in t= he world can correct this.

Henry


On 7/30/09 10:46 PM, "Alexander Chemeris" <Alexander.Chemeris@sipez.com> wrote:

Hello,

Just to make a note of proposed additions to technical considerations,
which were seen on the jabber conference:

1) Requirement/non requirement of stereo and/or multichannel
2) Good performance in the presence of packet loss
3) Compatibility with negotiation schemes widely used over
the Internet.

Points (1) and (2) are obvious and seem to leak from the consideration
just by occasion, but I want to slightly elaborate on point (3).

A non-technical point, which was not clearly defined, but I think is
very important:

* Considered codecs must be standardized. In ITU, IETF, wherever,
but there should be a clean standard allowing creation of compatible
3rd party implementation.

=3D Introduction for non-VoIP developers =3D

SIP is one of the most widely used and well known VoIP signaling and it
do use venerable SDP (RFC2327) for codec negotiation. The recommended
way to negotiate codecs with SDP is a so-called Offer/Answer Model
(RFC3264). Simply speaking, one side offers a codec set and the other
side can either accept a specific codec or reject its use.

=3D The problem =3D

SDP was clearly designed for the use with old-fashion codecs which
supported only one or few operating modes, usually just a set of few
different bitrates. But modern codecs tend to be a beasts of different
kind they offer a plenty of configuration options users have to choose
from. I know two examples of such codecs - Speex and AMR(-WB),
probably IPMR goes a similar way, but I'm not familiar with it.
For RTP payload and SDP negotiation of Speex look into RFC 5574,
for AMR and AMR-WB look into RFC5574.

So, the tale is about AMR(-WB) which has few horrible statements
in the RFC about SDP negotiation, worst of which is:

      -  Each combination of the RTP pay= load transport format
         configuration paramet= ers (octet-align, crc, robust-sorting,
         interleaving, and cha= nnels) is unique in its bit-pattern and
         not compatible with a= ny other combination. [...]

This means that if you want to support several combinations of
parameters, SDP offer will blow up into a huge list of different
parameter combinations. That's the problem, because SDP plus
SIP header should fit into UDP packet size (you can use TCP,
but it's much better to fit into UDP, isn't it?) and wasting payload
type numbers.
But this problem won't be that sharp if every VoIP developer read
RFC carefully with the full understanding of them and implement
everything as written. Instead, many developers assume that
defaults are fine and don't have time or willing to read or implement
such a complex operation. No need to say I've seen implementations
which ignored even "octet-align" fmtp parameter, trying to guess<= BR> it from the actual data.
When I implemented AMR(-WB) payload for our SIP stack I some
more inconveniences and even one collision in a RFC, but alas
I can't recall details now. I should have documented the problem
that time and not rely on my memory..

Speex does a better job here, as it does not have incompatible
sets of features. I.e. every stream, produced by an encoder can
be at least correctly passed if not decoded by a decoder.

The moral of that story is that ideal VoIP codec should not
assume a fixed number of parameter sets in endpoints, as
AMR does, and rely on SDP for features offer. Rather it should
use in-band signaling as much as possible to offload SDP
and make codec API "programmer-friendly".

--
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6986113F101hsinnreiadobecom_-- From ron@debian.org Fri Jul 31 00:14:38 2009 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 2FBAB28C1F5 for ; Fri, 31 Jul 2009 00:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 yexaLFclRIoq for ; Fri, 31 Jul 2009 00:14:35 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id E938528C1C3 for ; Fri, 31 Jul 2009 00:14:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoEAJc2ckp5LTZ7/2dsb2JhbACBUtAohBcF X-IronPort-AV: E=Sophos;i="4.43,301,1246804200"; d="scan'208";a="425718932" Received: from ppp121-45-54-123.lns11.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.54.123]) by ipmail04.adl2.internode.on.net with ESMTP; 31 Jul 2009 16:44:15 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8552D4F8F3 for ; Fri, 31 Jul 2009 16:44:14 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ORUxYIkpX42 for ; Fri, 31 Jul 2009 16:44:13 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A2BAC4F8FD; Fri, 31 Jul 2009 16:44:13 +0930 (CST) Date: Fri, 31 Jul 2009 16:44:13 +0930 From: Ron To: codec@ietf.org Message-ID: <20090731071413.GI4904@audi.shelbyville.oz> References: <3d032e5d0907301346q4ce3209h8de9cdad90f4bf81@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:14:38 -0000 On Thu, Jul 30, 2009 at 11:51:31PM -0700, Henry Sinnreich wrote: > I am not so sure about > > > 2) Good performance in the presence of packet loss > > For two reasons: > > 1. Broadband networks are not plagued by significant packet loss, > 2. If packet loss occurs, it is in the form of long bursts of packet loss, cutting out words or whole sentences and no codec in the world can correct this. At the very low latencies that codec developers are trying achieve now (which are very important for QOS of VoIP systems), even a small increase in network delay equates to packet loss. That can be adapted to, but in the meantime, you still have packet loss to deal with, even if your throughput and reliability are generally quite high. Ron From swmike@swm.pp.se Fri Jul 31 00:15:34 2009 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 D467828C215 for ; Fri, 31 Jul 2009 00:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 nr4TFAcXVgdM for ; Fri, 31 Jul 2009 00:15:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C88283A6C27 for ; Fri, 31 Jul 2009 00:15:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9C10D9E; Fri, 31 Jul 2009 09:15:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 99B4A9A; Fri, 31 Jul 2009 09:15:30 +0200 (CEST) Date: Fri, 31 Jul 2009 09:15:30 +0200 (CEST) From: Mikael Abrahamsson To: Henry Sinnreich In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:15:34 -0000 On Thu, 30 Jul 2009, Henry Sinnreich wrote: > 2. If packet loss occurs, it is in the form of long bursts of packet > loss, cutting out words or whole sentences and no codec in the world can > correct this. In the case of wireless networks you have pretty reliable transport but you're plagued by sometimes huge intermittent jitter. So, it's also an interesting distinction whether a packet received after the receiver jitter buffer ran out should be classified as a packet loss or not. From the codec point of view, it is, as the codec didn't get this information. So, in my mind the codec needs to handle jitter buffer growth and reduction by shrinking/dragging out sound to in a graceful manner to adapt to the jitter buffer size dynamically changing over time, thus it needs to be tightly integrated with transport. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Jul 31 01:07:30 2009 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 37F073A6A6C for ; Fri, 31 Jul 2009 01:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 FQXXE1BSaaLJ for ; Fri, 31 Jul 2009 01:07:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2F9D13A6B21 for ; Fri, 31 Jul 2009 01:07:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EDC629E; Fri, 31 Jul 2009 10:07:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EA5729A for ; Fri, 31 Jul 2009 10:07:29 +0200 (CEST) Date: Fri, 31 Jul 2009 10:07:29 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018ECEA6@esealmw109.eemea.ericsson.se> Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C018ECEA6@esealmw109.eemea.ericsson.se> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:07:30 -0000 On Fri, 31 Jul 2009, Ingemar Johansson S wrote: > Please have a look at sections 8-10 in > http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip In > addition annex C contains examples of adaptation state machines So I read 8-10 (well, 8 and 9, section 10 was kind of hard to understand) and the logic seems sound and seems to do a lot of what I have been talking about. Where can I download a program to install on two PCs (linux or windows) to test in my lab if this actually works in the conditions I'm describing? (I'll put something between them that'll induce delay, jitter and packetloss) -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Jul 31 01:08:19 2009 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 506F428C2C9 for ; Fri, 31 Jul 2009 01:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 5CI7P-zeFOJn for ; Fri, 31 Jul 2009 01:08:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 7792A28C254 for ; Fri, 31 Jul 2009 01:08:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 406519E; Fri, 31 Jul 2009 10:08:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3EC509A for ; Fri, 31 Jul 2009 10:08:19 +0200 (CEST) Date: Fri, 31 Jul 2009 10:08:19 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><130EBB38279E9847BAAAE0B8F9905F8C018ECE56@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C018ECEA6@esealmw109.eemea.ericsson.se> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:08:19 -0000 On Fri, 31 Jul 2009, Mikael Abrahamsson wrote: > Where can I download a program to install on two PCs (linux or windows) > to test in my lab if this actually works in the conditions I'm > describing? (I'll put something between them that'll induce delay, > jitter and packetloss) Sorry, I should have written "program that implements this"... -- Mikael Abrahamsson email: swmike@swm.pp.se From ron.even.tlv@gmail.com Fri Jul 31 01:31:11 2009 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 7371D3A6B39 for ; Fri, 31 Jul 2009 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 nS1ZXyttnbZP for ; Fri, 31 Jul 2009 01:31:00 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id AA6E23A6805 for ; Fri, 31 Jul 2009 01:30:39 -0700 (PDT) Received: by fxm17 with SMTP id 17so1232726fxm.37 for ; Fri, 31 Jul 2009 01:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=7ns/kbjlwniSqAN6OAtcn5AAmF5qnrIT9XBFaVpsqfc=; b=Ub31tNDEEK6GW4aSjsGhJFZUG4Nsc5QyI0Z0hrIJPlbGu5V38wC7N805XEU5fvLhYm SKOwlgomFUs954hFN7B4kg4m1RT/Cqkjs+7CatyqaKDvLdFDFMqSlTITqidF3BcbkBZU m4nQfQm01K+y5H82XIE7bU05rcNETu+iUqozE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=o7U/l0lysztYWz5ahLxW2kS2bKYEQGOUyRvRq4Lxw9b51qEFiH+b0axgbk609+bD63 rnEJZbNoL1LHcjdN1bzgPlxwez0UOvIS8dBFFgJiGek0myS+rTfHFHkeZO2/M0/MJIS2 Boi4CVZ9k2v9+12vMPWLakw3mhH0xddLVcS6g= Received: by 10.103.225.15 with SMTP id c15mr1301583mur.115.1249029038995; Fri, 31 Jul 2009 01:30:38 -0700 (PDT) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by mx.google.com with ESMTPS id 23sm19187131mum.5.2009.07.31.01.30.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 01:30:38 -0700 (PDT) From: "Roni Even" To: "'Kevin P. Fleming'" References: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> <4A721D9F.5000605@digium.com> In-Reply-To: <4A721D9F.5000605@digium.com> Date: Fri, 31 Jul 2009 11:28:51 +0300 Message-ID: <4a72abae.170d660a.5c56.1e7d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRZIzLXr7nvlDORnSlbP7zq0548AAUggTQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:31:11 -0000 Hi, The issue is not negotiation the codec parameters in band. What you describe is that the decoder can accept any combination that the encoder can produce. This is easy when there is no backward compatibility or no specific profiles based on parameters. The problem with this solution is that the receiver cannot control the codec options he wants to receive. The bit rate may be controlled by b= parameter. Using RTP or RTCP to negotiate send and receive capabilities rae not the right way Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Kevin P. Fleming > Sent: Friday, July 31, 2009 1:25 AM > Cc: codec@ietf.org > Subject: Re: [codec] Technical Considerations additions > > Alexander Chemeris wrote: > > > Not exactly. This CAN be fixed in IETF by defining a cool RTP payload > > which will add additional in-band signalling, but isn't it nicer to > > have a self-contained codec, which just produces "frames" and does > not > > need any fancy packaging and additional signaling? Look at Speex as > an > > example of pretty good implementation of this paradigm. > > This is also an important issue for SIP B2BUAs, when media streams from > two endpoints must be connected together even though they may not have > originally been connected (think call transfers, for example). With SDP > complexity of the sort present with AMR-WB (or video codecs), it's not > practically possible for the B2BUA to determine whether the current > media formats being used by the endpoints are compatible, even though > they may be same codec and sample rate. With Speex, at least, it's > always safe to send any Speex stream to a decoder, even if it wasn't > produced using the parameters the decoder specified during negotiation, > but I'm not aware of any other existing codecs for which that would > work. > > This results in the B2BUA having to completely understand all the > interactions of the codec parameters to determine whether two streams > are 'compatible', or whether renegotiation (or worse, transcoding) is > needed. > > Moving the codec parameter negotiation into the codec bitstream > resolves > this issue completely, and means that only the actual endpoints that > contain implementations of the codec have to understand the > interactions > between its parameters. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kpfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ingemar.s.johansson@ericsson.com Fri Jul 31 02:12:45 2009 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 4474F3A698A for ; Fri, 31 Jul 2009 02:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_SE=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 n79o1byddmbe for ; Fri, 31 Jul 2009 02:12:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CC2913A68B4 for ; Fri, 31 Jul 2009 02:12:43 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-53-4a72b58923dc Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 36.AB.15141.985B27A4; Fri, 31 Jul 2009 11:12:41 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 11:12:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 11:12:29 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRvwe1ZsyDiCLzQJy2hYgnCAkb2Q== References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> From: "Ingemar Johansson S" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 31 Jul 2009 09:12:31.0698 (UTC) FILETIME=[08C42B20:01CA11BF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:12:45 -0000 Hi Like I said before. I really don't see why we need a codec WG in IETF to solve the issues mentioned below, please again see sections 8-10 +annex C in http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip and you'll realize that these issues are already addressed. I claim that with a codec WG in IETF we will not invent something new, we only duplicate all or a subset of other SDO's work. The only possible difference I see is the strive for royalty free or license free and AFAIK there is no guarantee of that in IETF.=20 But.... it is important to ask the question if we create this WG to solve a technical problem or to solve a business problem ? I don't see the technical "novelty" as other SDO's are aleady working on this, what is left is the business problem (or license problem or whatever). Is it enough motivation to create a WG ?. =20 /Ingemar=20 =20 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Sent: den 31 juli 2009 07:17 > To: codec@ietf.org > Subject: Re: [codec] Codec Standardization Expertise >=20 > On Thu, 30 Jul 2009, stephen botzko wrote: >=20 > > But to be fair, the issues with jitter and packet loss are=20 > generally=20 > > due to the packetization constraints in the RTP RFC, not the ITU-T=20 > > spec itself. G.719's packetization RFC allows for interleaved and=20 > > overlapped > > (redundant) audio frames, and permits the duplicate frames to be at=20 > > lower rates. That allows for good quality to be maintained under=20 > > packet loss conditions (though if the network is congested,=20 > of course=20 > > you need to use an overall lower rate).. All the codecs I've used=20 > > will recover state very quickly when conditions improve. I=20 > can't see=20 > > how the codec can solve an end-to-end delay problem, it seems to me=20 > > that if the delay doesn't heal itself when conditions=20 > improve, it is=20 > > likely to be a transport problem that the codec can't influence. >=20 > We need to design something that works, and that involves=20 > creating a codec and a transport that handles the real world,=20 > not trying to adapt the real world to the constraints of the=20 > codec and transport. Saying you need a lower rate in case of=20 > congestion isn't the case either, that won't help yourself=20 > anything because you're most likely competing with TCP flows=20 > which will take all they can get. What you need to do is=20 > "stand your ground", perhaps go for lower sound quality but=20 > keep the bitrate so the packets you actually get through will=20 > make sounds at the other end that is as good as it can get=20 > during the conditions. G.719 might do this as you say, I don't know. >=20 > We need a codec and transport that when faced with adverse=20 > network conditions will handle this gracefully and adapt its=20 > jitter buffer (if jitter increases to 1s, it should increase=20 > its jitter buffer to handle this, then when network=20 > conditions improve it needs to somehow lower the jitter=20 > buffer again which means it'll have to play sound "faster" to=20 > catch up). All this needs to work between the codec/transport=20 > layers, and information regarding sound needs to be spread=20 > across several packets in case of packet loss (degrade sound=20 > quality nicely), and to retain the low end-to-end delay when=20 > network conditions are good, it also needs to go back to the=20 > usual "all sound for these 20ms sound in one packet"-mode for that. >=20 > So the codec and underlying transport cannot *influence* the=20 > network IP behavior, but it needs to be able to ADAPT to it=20 > and handle it, providing as good user experience as possible. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 From alexander.chemeris@gmail.com Fri Jul 31 02:19:36 2009 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 6B5833A6C11 for ; Fri, 31 Jul 2009 02:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 V5ikTXnhBbjo for ; Fri, 31 Jul 2009 02:19:35 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id DC0183A6DAC for ; Fri, 31 Jul 2009 02:19:16 -0700 (PDT) Received: by fxm17 with SMTP id 17so1253164fxm.37 for ; Fri, 31 Jul 2009 02:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=QzNmPWcr+rYGgP3Qxp04Idq4HMo2bNnO+DhlqxD06Zk=; b=dBL3CmS56jO9s3kUtzmTloXnlHMfbMkscRt7Kz/7VOIwqPizDPWwiG1XEUoB8bAjGf Qqfw0wMgeF/0Im+kTJZ0uyjVYOwhpc0q+LzpYcBYD0oeDsBrlC2h3FNtLAbZ/R6yiUvC yyzvq7FezJi5Z7uQJeAaM6V0XW9OvxpRz6wtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Ikw/cWxjnXI6jL/ixryQsYW5uL914ae7i6EZnLNUbyXnV7BzyLrY0RBpxFRSKhPBi1 Yc1NYfDkYsA7+/Iry1pXKplcEwImDR5CPn0kcmYMr/r4zLFDa8KzW5GHqMpEfuNHmFYO +uUPnqflnbLFeX8RM3o8BdBjN78v28emA+84c= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.24.11 with SMTP id b11mr1198557muj.90.1249031956083; Fri, 31 Jul 2009 02:19:16 -0700 (PDT) In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018ECE8A@esealmw109.eemea.ericsson.se> References: <3d032e5d0907301502t4f0393e8w11c6dc6aed0e3e58@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECE8A@esealmw109.eemea.ericsson.se> From: Alexander Chemeris Date: Fri, 31 Jul 2009 13:18:56 +0400 X-Google-Sender-Auth: c3923dafac26877a Message-ID: <3d032e5d0907310218g633b886fw2cdeec338956ea26@mail.gmail.com> To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] Technical Considerations additions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:19:36 -0000 Hi, Ingemar On Fri, Jul 31, 2009 at 09:46, Ingemar Johansson S wrote: > I believe that in the AMR case it is very important to be able to disting= uish between the apples and the oranges. AMR was originally designed for ci= rcuit switched access and therefore some extra parameters such as allowed m= ode sets, mode change period and mode change neighbor is in the negotiation= , these parameters are there simply make interworking between a PS and a CS= domain possible (and avoid transcoding). AMR is heavily used in mobile tel= ephones (CS) and just because we start to think VoIP we cannot just pretend= that CS does not exist overnight. > There is even a Q bit to tell that part of the payload is bad (something = that in practice only happens in a CS environment, may happen with UDP-Lite= ) > Now for a PS to PS call, all that stuff is not needed anymore UDP-Lite ma= y be used though but I have to see evidence of it). Right, that's what I was talking about. May I was not very clear. > If you envision only PS to PS you can skip all the above things in your n= egotiation. True, but only in the half. Problem is that you still should offer at least two (!) modes, because they are not bitstream compatible (!). As per RFC: [...], the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel I understand the desire to make seamless integration of mobile and VoIP networks, but all this adds to implementation complexity and decrease codec popularity. Internet is all about a lot of different implementations and the Internet standards should be "as simple as possible (but no simpler)". Here is my view on two ways how AMR payload could be done better: 1) Fix octet-aligned mode as the only allowed in RTP. Convert all bandwidth efficient packets to octet-aligned ones on the border. Keep in mind, this is not transcoding, just bits moving. Other params as in (2). 2) Prepend every payload with 4 bits, by a bit for each of octet-align, crc, robust-sorting and interleaving settings. Then decoder will be able to know about bitstream format without any out-of-band means. Given that this is required only once per packet (not per frame) that's not a big addition to the bandwidth, but will greatly simplify operation. This AMR discussion is going to be off-topic. Actually I just wanted to contrast AMR to Speex as two examples of codecs less and more suitable for the "ideal VoIP codec" place by the "SDP and end-programmer friendliness" parameter. > The octet aligned and bandwidth efficient modes are there to satisfy the = requirements. > If you look into 3GPP spec TS26.114 you will find more info about this. > Or why not have a look in this book > http://www.wiley-vch.de/publish/dt/books/bySubjectEE00/bySubSubjectEE25/0= -470-05855-2/?sID=3Dnqk9adkt7hm033ice0kp7jh3v4 Sorry, I don't have the spec. Could you copy-paste here a wording which leads to the need of octet-aligned and bandwidth-efficient modes? I was always wondering about this. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From alexander.chemeris@gmail.com Fri Jul 31 02:32:28 2009 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 6C4533A6D64 for ; Fri, 31 Jul 2009 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hiIR3WcI6o80 for ; Fri, 31 Jul 2009 02:32:27 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 44EAE3A6B70 for ; Fri, 31 Jul 2009 02:32:27 -0700 (PDT) Received: by fxm17 with SMTP id 17so1258585fxm.37 for ; Fri, 31 Jul 2009 02:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=ovd0t8iIiQg36okBmVTi5Kd4V0GjRFgUvuCiloPd8U0=; b=BmuvD+ZIyOYMUVzwIbor64WfWKZvhdYBGf3B0xoBbFLFPzXcN8ogfb0eKvbtP+7EtZ LMw4wVaPxDtjY2b+zXADDxQYvn6kmJ+c4Ayw/o4hnkc7Ovxqv1oN/vR6qvGCHJYn3xtX RSuMOjWWXe6nDEIBU1ue3eXTb+uLtqzlj4NGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=MMzrsTS3WhoMog71fIvIX6oWZtJ0n/UBlVn7q05xNWhnNWgYpbDjnUiB3ceXEOYTJT dKXJ5cBMhpN7t2Ysz1W6HURPG8ir772loCj8aOy14ClG8LlmGW4BPKQznd2EWGtbf0mj ZyvvdYKlG2ilrK7kw43tEcws8pNV8djZMAsSw= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.251.20 with SMTP id d20mr1368755mus.42.1249032744773; Fri, 31 Jul 2009 02:32:24 -0700 (PDT) In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> From: Alexander Chemeris Date: Fri, 31 Jul 2009 13:32:03 +0400 X-Google-Sender-Auth: 9c24d81615719ef4 Message-ID: <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:32:28 -0000 Hi, On Fri, Jul 31, 2009 at 13:12, Ingemar Johansson S wrote: > I claim that with a codec WG in IETF we will not invent something new, > we only duplicate all or a subset of other SDO's work. > > The only possible difference I see is the strive for royalty free or > license free and AFAIK there is no guarantee of that in IETF. > But.... it is important to ask the question if we create this WG to > solve a technical problem or to solve a business problem ? I don't see > the technical "novelty" as other SDO's are aleady working on this, what > is left is the business problem (or license problem or whatever). Is it > enough motivation to create a WG ?. What about the way, I described in my first mail in this thread? I.e. this WG to be a codec evaluation and recommendation body, rather then codec-standardization. PS While your statement that there is nothing new invented here (yet) is correct, you miss that while everyone knows the problems, there are still no ideal VoIP codec. The effort to carefully specify needs of VoIP is half of the way to encouraging someone to create one. And thus is worthwhile. PPS Royalty-free requirement is not "just a some small addition to other's SDO requirements". It's a vital part. Other SDOs were failing to produce royalty-free codecs till now. Why should we rely on them for the future? -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From stephen.botzko@gmail.com Fri Jul 31 03:24:42 2009 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 5C8153A6B27 for ; Fri, 31 Jul 2009 03:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.499, 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 tA5HozswX2-o for ; Fri, 31 Jul 2009 03:24:41 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 9279E3A6805 for ; Fri, 31 Jul 2009 03:24:06 -0700 (PDT) Received: by fxm17 with SMTP id 17so1279841fxm.37 for ; Fri, 31 Jul 2009 03:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4mtO4t0UKaFlQG6FnnLJjPOxqV6/2kOYNu002vHCH4Q=; b=Cg0U9CmpERYBkqb8fvCozzQ/D/K+3WbZI3kALxs+OWD44o7zI2SgV3gt+tWt9qL0OE Pn20koDCuZSgR/xMbH4CfpM5Fc2vKx9jtl4z4GTuMxkate/KNwJuxt1RaNpsLGTh//nJ +lAt49e49M1tucipaMj71xeAGTv/nGpKMRsL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wU+uiBK5wPJQfmpGk3J60hjmRjAnxj2IB51PzCw+pJw6isJT07uJN8VUjcKYc+Vuoz IoFan0ZNtzRCq3HpcpthvN4UjTHi8w8TyISyjz/tDGyq8Mjl4L9YxVfgGrji99B0x8rr sodI/FFA4GsGeWFBfGLA1/tt7OECJKbsa4ll4= MIME-Version: 1.0 Received: by 10.103.168.3 with SMTP id v3mr1393962muo.58.1249035845443; Fri, 31 Jul 2009 03:24:05 -0700 (PDT) In-Reply-To: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> Date: Fri, 31 Jul 2009 06:24:05 -0400 Message-ID: <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> From: stephen botzko To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=0016367ed4ebe1213b046ffdd12c Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 10:24:42 -0000 --0016367ed4ebe1213b046ffdd12c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> Saying you need a lower rate in case of congestion isn't the case either, that won't help yourself anything because you're most likely competing with TCP flows which will take all they can get. What you need to do is "stand your ground" ... >>> I do not believe this is the prevailing view in the IETF. It is inconsistent with the language in newer packetization RFCs, including the language in RFC 5404. Likewise section 2.4 of RFC 3550 clearly implies that the appropriate adaptation to network congestion is to reduce bandwidth use. Ignoring congestion on the grounds that other flows might ignore it also does not seem to be a very useful approach. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 1:17 AM, Mikael Abrahamsson wrote: > On Thu, 30 Jul 2009, stephen botzko wrote: > > But to be fair, the issues with jitter and packet loss are generally due >> to the packetization constraints in the RTP RFC, not the ITU-T spec itself. >> G.719's packetization RFC allows for interleaved and overlapped (redundant) >> audio frames, and permits the duplicate frames to be at lower rates. That >> allows for good quality to be maintained under packet loss conditions >> (though if the network is congested, of course you need to use an overall >> lower rate).. All the codecs I've used will recover state very quickly when >> conditions improve. I can't see how the codec can solve an end-to-end delay >> problem, it seems to me that if the delay doesn't heal itself when >> conditions improve, it is likely to be a transport problem that the codec >> can't influence. >> > > We need to design something that works, and that involves creating a codec > and a transport that handles the real world, not trying to adapt the real > world to the constraints of the codec and transport. Saying you need a lower > rate in case of congestion isn't the case either, that won't help yourself > anything because you're most likely competing with TCP flows which will take > all they can get. What you need to do is "stand your ground", perhaps go for > lower sound quality but keep the bitrate so the packets you actually get > through will make sounds at the other end that is as good as it can get > during the conditions. G.719 might do this as you say, I don't know. > > We need a codec and transport that when faced with adverse network > conditions will handle this gracefully and adapt its jitter buffer (if > jitter increases to 1s, it should increase its jitter buffer to handle this, > then when network conditions improve it needs to somehow lower the jitter > buffer again which means it'll have to play sound "faster" to catch up). All > this needs to work between the codec/transport layers, and information > regarding sound needs to be spread across several packets in case of packet > loss (degrade sound quality nicely), and to retain the low end-to-end delay > when network conditions are good, it also needs to go back to the usual "all > sound for these 20ms sound in one packet"-mode for that. > > So the codec and underlying transport cannot *influence* the network IP > behavior, but it needs to be able to ADAPT to it and handle it, providing as > good user experience as possible. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367ed4ebe1213b046ffdd12c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
Saying you need a lower rate in case of congestion isn'= t the case either, that won't help yourself anything because you're most likel= y competing with TCP flows which will take all they can get. What you need to do is "stand your ground" ...
>>>

I do= not believe this is the prevailing view in the IETF. It is inconsistent wi= th the language in newer packetization RFCs, including the language in RFC = 5404.=A0 Likewise section 2.4 of RFC 3550 clearly implies that the appropri= ate adaptation to network congestion is to reduce bandwidth use.=A0

Ignoring congestion on the grounds that other flows might ignore it als= o does not seem to be a very useful approach.

Regards,
Stephen Bo= tzko
Polycom


On Fri, Jul 31, 2009 = at 1:17 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 30 Jul 2009, stephen botzko wrote:

But to be fair, the issues with jitter and packet loss are generally due to= the packetization constraints in the RTP RFC, not the ITU-T spec itself. G= .719's packetization RFC allows for interleaved and overlapped (redunda= nt) audio frames, and permits the duplicate frames to be at lower rates. = =A0That allows for good quality to be maintained under packet loss conditio= ns (though if the network is congested, of course you need to use an overal= l lower rate).. =A0All the codecs I've used will recover state very qui= ckly when conditions improve. =A0I can't see how the codec can solve an= end-to-end delay problem, it seems to me that if the delay doesn't hea= l itself when conditions improve, it is likely to be a transport problem th= at the codec can't influence.

We need to design something that works, and that involves creating a codec = and a transport that handles the real world, not trying to adapt the real w= orld to the constraints of the codec and transport. Saying you need a lower= rate in case of congestion isn't the case either, that won't help = yourself anything because you're most likely competing with TCP flows w= hich will take all they can get. What you need to do is "stand your gr= ound", perhaps go for lower sound quality but keep the bitrate so the = packets you actually get through will make sounds at the other end that is = as good as it can get during the conditions. G.719 might do this as you say= , I don't know.

We need a codec and transport that when faced with adverse network conditio= ns will handle this gracefully and adapt its jitter buffer (if jitter incre= ases to 1s, it should increase its jitter buffer to handle this, then when = network conditions improve it needs to somehow lower the jitter buffer agai= n which means it'll have to play sound "faster" to catch up).= All this needs to work between the codec/transport layers, and information= regarding sound needs to be spread across several packets in case of packe= t loss (degrade sound quality nicely), and to retain the low end-to-end del= ay when network conditions are good, it also needs to go back to the usual = "all sound for these 20ms sound in one packet"-mode for that.

So the codec and underlying transport cannot *influence* the network IP beh= avior, but it needs to be able to ADAPT to it and handle it, providing as g= ood user experience as possible.


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016367ed4ebe1213b046ffdd12c-- From swmike@swm.pp.se Fri Jul 31 04:06:23 2009 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 2FE123A6A3B for ; Fri, 31 Jul 2009 04:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 DJOYXIths+-G for ; Fri, 31 Jul 2009 04:06:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 5F2E13A68E8 for ; Fri, 31 Jul 2009 04:06:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 315899E; Fri, 31 Jul 2009 13:06:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 308409A; Fri, 31 Jul 2009 13:06:21 +0200 (CEST) Date: Fri, 31 Jul 2009 13:06:21 +0200 (CEST) From: Mikael Abrahamsson To: stephen botzko In-Reply-To: <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:06:23 -0000 On Fri, 31 Jul 2009, stephen botzko wrote: > I do not believe this is the prevailing view in the IETF. Ok, fair enough. I still have the opinion that it depends on the kind of problem seen, if real time (which is the general case in case of VoIP ) flow size is very small compared to others, then reducing the BW has marginal improvement potential, and since this is most likely high importance traffic to the user, yes, codec bw should be reduced but some of that reduction should be spent on improving reliability in the stream (more redundant information transmitted so a call can be sustained in acceptable quality). > Ignoring congestion on the grounds that other flows might ignore it also > does not seem to be a very useful approach. I didn't say ignore, at least I didn't mean to. Let's call it a re-allocation of resources from high quality to means of maintaining acceptable quality instead. -- Mikael Abrahamsson email: swmike@swm.pp.se From stephen.botzko@gmail.com Fri Jul 31 04:14:53 2009 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 68BCB3A6C81 for ; Fri, 31 Jul 2009 04:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.478, 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 kg7xyChEHF6d for ; Fri, 31 Jul 2009 04:14:52 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 0F6733A6C34 for ; Fri, 31 Jul 2009 04:14:51 -0700 (PDT) Received: by bwz19 with SMTP id 19so1126760bwz.37 for ; Fri, 31 Jul 2009 04:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2w9QdN1B/MauGWpBweQz/D5scAxKE+yvnkCL7CJO7HU=; b=m964E+EB71TCkTbNMAiU9PgIzL8aO7+jC/W45B/tmAJU/wjVdtUXGYMHqqxfEmoRj9 A0PfBx1dlYzCC/A22GFiC3pJTtORD59i0FFMt+c0KHziMGMpRHEKFg7+PHVrK39ELlgB zvhrqT7Xfg46vRCOgfYF39jYgNSKh9NcdZc8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YJw7Pg/A1Ik8/HBrU902+KbNzfs31nn1noDKJq8lJfuNSLVeUcbi/IV0OPcYnGz8H7 wACzHSDUNdLZMhSadi7W7mt0GT1POWazfVfsdqwFhFOd6b3sgIhdiQGnZwU7HXOvqUmu 4PfMEifOuIc9kaEFH78j86kihqaKxA0NHgJqs= MIME-Version: 1.0 Received: by 10.103.198.20 with SMTP id a20mr1384004muq.114.1249038890566; Fri, 31 Jul 2009 04:14:50 -0700 (PDT) In-Reply-To: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> Date: Fri, 31 Jul 2009 07:14:50 -0400 Message-ID: <6e9223710907310414p340ffc0fvfed4d6b883dae3a3@mail.gmail.com> From: stephen botzko To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=0016369fa20d62063c046ffe874f Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:14:53 -0000 --0016369fa20d62063c046ffe874f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ok. You ended up agreeing with what I said in my first post. I pointed out the redundant frames/interleaved frame transmission in the G.719 rfc, but said you should also switch to a lower bandwidth mode if the network were congested. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 7:06 AM, Mikael Abrahamsson wrote: > On Fri, 31 Jul 2009, stephen botzko wrote: > > I do not believe this is the prevailing view in the IETF. >> > > Ok, fair enough. I still have the opinion that it depends on the kind of > problem seen, if real time (which is the general case in case of VoIP ) flow > size is very small compared to others, then reducing the BW has marginal > improvement potential, and since this is most likely high importance traffic > to the user, yes, codec bw should be reduced but some of that reduction > should be spent on improving reliability in the stream (more redundant > information transmitted so a call can be sustained in acceptable quality). > > Ignoring congestion on the grounds that other flows might ignore it also >> does not seem to be a very useful approach. >> > > I didn't say ignore, at least I didn't mean to. Let's call it a > re-allocation of resources from high quality to means of maintaining > acceptable quality instead. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --0016369fa20d62063c046ffe874f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok.=A0 You ended up agreeing with what I said in my first post. I pointed o= ut the redundant frames/interleaved frame transmission in the G.719 rfc, bu= t said you should also switch to a lower bandwidth mode if the network were= congested.=A0

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 7:06 AM, Mikael Abrahamsson <= swmike@swm.pp.se> wrote:<= br>
On Fri, 31 Jul 2009, stephen botzko wrote:

I do not believe this is the prevailing view in the IETF.

Ok, fair enough. I still have the opinion that it depends on the kind of pr= oblem seen, if real time (which is the general case in case of VoIP ) flow = size is very small compared to others, then reducing the BW has marginal im= provement potential, and since this is most likely high importance traffic = to the user, yes, codec bw should be reduced but some of that reduction sho= uld be spent on improving reliability in the stream (more redundant informa= tion transmitted so a call can be sustained in acceptable quality).


Ignoring congestion on the grounds that other flows might ignore it also do= es not seem to be a very useful approach.

I didn't say ignore, at least I didn't mean to. Let's call it a= re-allocation of resources from high quality to means of maintaining accep= table quality instead.


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

--0016369fa20d62063c046ffe874f-- From swmike@swm.pp.se Fri Jul 31 04:22:38 2009 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 1736E3A63CB for ; Fri, 31 Jul 2009 04:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 WPvcFyxM4joV for ; Fri, 31 Jul 2009 04:22:37 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 5093528C12E for ; Fri, 31 Jul 2009 04:22:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EAD559E; Fri, 31 Jul 2009 13:22:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E786C9A for ; Fri, 31 Jul 2009 13:22:37 +0200 (CEST) Date: Fri, 31 Jul 2009 13:22:37 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <6e9223710907310414p340ffc0fvfed4d6b883dae3a3@mail.gmail.com> Message-ID: References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> <6e9223710907310414p340ffc0fvfed4d6b883dae3a3@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:22:38 -0000 On Fri, 31 Jul 2009, stephen botzko wrote: > Ok. You ended up agreeing with what I said in my first post. I pointed out > the redundant frames/interleaved frame transmission in the G.719 rfc, but > said you should also switch to a lower bandwidth mode if the network were > congested. Absolutely, I never meant to advocate *increasing* bw by means of maintaining codec bw but transmitting more redundant information, thus increasing the overall IP bits/s used. -- Mikael Abrahamsson email: swmike@swm.pp.se From herve.taddei@huawei.com Fri Jul 31 04:44:35 2009 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 87B1528C224 for ; Fri, 31 Jul 2009 04:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 vWrOxy+Kvj8D for ; Fri, 31 Jul 2009 04:44:34 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id C8F9A28C158 for ; Fri, 31 Jul 2009 04:43:42 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN00HX49WT3A@lhrga04-in.huawei.com> for codec@ietf.org; Fri, 31 Jul 2009 12:43:41 +0100 (BST) Received: from PCHERVE ([10.200.70.146]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNN00CYL9WST1@lhrga04-in.huawei.com> for codec@ietf.org; Fri, 31 Jul 2009 12:43:41 +0100 (BST) Date: Fri, 31 Jul 2009 13:43:40 +0200 From: Herve Taddei In-reply-to: <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> To: 'Alexander Chemeris' , 'Ingemar Johansson S' Message-id: <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Thread-index: AcoRwnPxJVxyWC9RQ76ur2/uetPoTgABY5Bg References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:44:35 -0000 Hi, > PPS Royalty-free requirement is not "just a some small addition to > other's SDO requirements". It's a vital part. Other SDOs were failing > to produce royalty-free codecs till now. Why should we rely on them = for > the future? I don=92t think there is any insurance that the IETF work will provide a = RF codec. What is the benefit of this work if you don=92t get RF codecs? So = far, it really seems to be the only argument to start this work.=20 And there is something some people seem to always forget/ignore is that there are already some standards that are RF codecs: G.722, G.722.1, G.722.1C, G.711 and certainly some others. Some people say they don=92t = fit their needs, but when I read the current draft charter it does not seem = to be true as these codecs perfectly fit it. The fact that these codecs = have RF conditions because either it was a company choice to offer them for free = or because their patents ran out is irrelevant to the discussion. The fact = is there are already RF codecs.=20 Then we can read that you need an Internet dedicated codec, but so far = in the charter there is nothing special that could make me thinking, yes = this is an Internet codec. To your last point, why should you rely on other SDOs: - because usually it is where main telcos, vendors and experts are, - because their codec evaluation/characterization is well defined, - because their codec applications/requirements are well organized and = codec standardization is started based on these definitions. Best regards Herv=E9 From alexander.chemeris@gmail.com Fri Jul 31 05:42:03 2009 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 0B6B83A6D02 for ; Fri, 31 Jul 2009 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 pPAlnNYMCdKB for ; Fri, 31 Jul 2009 05:42:02 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 8B2353A68EA for ; Fri, 31 Jul 2009 05:42:01 -0700 (PDT) Received: by fxm17 with SMTP id 17so1342677fxm.37 for ; Fri, 31 Jul 2009 05:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=jSubj5ojVzXMiNz6oplIAHtXwF2UhiBbprsd5VvaOns=; b=xCjOHxuHsK2jQ2O6WXDq0GRx36Fp9bY+zZwE3F6HbWyhv8sAmCon0oY6mRz9AlJUAy OYcoeNf+E37wgakkIZz744i99DYQAPA6gEj6ZPZtisV9ka61XgfkKHvmACWHdF94kaoT +Wxdq/q4sUXay1AWnNqH/afb4VfIMrXBt2uzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=dufEiIRsV4k6qgFGNr1bj8iB0w5ETLP8hqwOdBJg2im8zA21y7so5VRKA47KT5EjvK vGALax/eyHmMBq4PvF22NG4eBhlt3TRTxaQBZF6194250x9SBE+FSSRXa/hZeVUy4+po 2wjmDgMsj371Umnq2g7xp0/W38keMWiq9aAEs= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.241.5 with SMTP id t5mr1453006mur.123.1249044121134; Fri, 31 Jul 2009 05:42:01 -0700 (PDT) In-Reply-To: <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> From: Alexander Chemeris Date: Fri, 31 Jul 2009 16:41:41 +0400 X-Google-Sender-Auth: a3591983a927e774 Message-ID: <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> To: Herve Taddei Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ingemar Johansson S , codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:42:03 -0000 Hi, On Fri, Jul 31, 2009 at 15:43, Herve Taddei wrote: >> PPS Royalty-free requirement is not "just a some small addition to >> other's SDO requirements". It's a vital part. Other SDOs were failing >> to produce royalty-free codecs till now. Why should we rely on them for >> the future? > > I don=E2=80=99t think there is any insurance that the IETF work will prov= ide a RF > codec. What is the benefit of this work if you don=E2=80=99t get RF codec= s? So far, > it really seems to be the only argument to start this work. Sorry, probably you do not follow, but RF requirement was put on the very first slides and repeated several times later. Moreover, several serious companies offers to open their codecs as RF ones - you should have missed this too. After all, there is CELT, being built as RF from the ground up. T= here is a lot of willing for RF codec(s). > And there is something some people seem to always forget/ignore is that > there are already some standards that are RF codecs: G.722, G.722.1, > G.722.1C, G.711 and certainly some others. Some people say they don=E2=80= =99t fit > their needs, but when I read the current draft charter it does not seem t= o > be true as these codecs perfectly fit it. The fact that these codecs have= RF > conditions because either it was a company choice to offer them for free = or > because their patents ran out is irrelevant to the discussion. The fact i= s > there are already RF codecs. Sorry, these codecs does not meet other criteria. They're not bandwidth efficient, they do not behave well in the presence of packet loss, etc. > Then we can read that you need an Internet dedicated codec, but so far in > the charter there is nothing special that could make me thinking, yes thi= s > is an Internet codec. Please, read all requirements again. Think of them together, not about each one separately. > To your last point, why should you rely on other SDOs: > - because usually it is where main telcos, vendors and experts are, > - because their codec evaluation/characterization is well defined, > - because their codec applications/requirements are well organized and co= dec > standardization is started based on these definitions. Sounds good, with the only exception, I mentioned above - absence of RF codec they standardized. Plus lack of modern codecs, suitable for the use of the Internet programmers, not telco ones. Plus absence of really low-delay WB codec. Plus inability to participate for usual people, not belonging to big telcos. Oh, isn't there too much exceptions? And yet I don't see reasons I should not rely on IETF. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From ron@debian.org Fri Jul 31 06:08:06 2009 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 799C33A6A58 for ; Fri, 31 Jul 2009 06:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 KX9l5wcfQ+Uv for ; Fri, 31 Jul 2009 06:08:05 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id 08DA83A68EA for ; Fri, 31 Jul 2009 06:08:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAH2Hckp5LTZ7/2dsb2JhbACBUtBJgi2BawU X-IronPort-AV: E=Sophos;i="4.43,302,1246804200"; d="scan'208";a="425803684" Received: from ppp121-45-54-123.lns11.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.54.123]) by ipmail04.adl2.internode.on.net with ESMTP; 31 Jul 2009 22:38:01 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id CC4E04F8F3 for ; Fri, 31 Jul 2009 22:38:00 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W0-0VZkyY+9F for ; Fri, 31 Jul 2009 22:38:00 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 2F4454F8FD; Fri, 31 Jul 2009 22:38:00 +0930 (CST) Date: Fri, 31 Jul 2009 22:38:00 +0930 From: Ron To: codec@ietf.org Message-ID: <20090731130800.GN4904@audi.shelbyville.oz> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:08:06 -0000 On Fri, Jul 31, 2009 at 01:43:40PM +0200, Herve Taddei wrote: > > PPS Royalty-free requirement is not "just a some small addition to > > other's SDO requirements". It's a vital part. Other SDOs were failing > > to produce royalty-free codecs till now. Why should we rely on them for > > the future? > > I don’t think there is any insurance that the IETF work will provide a RF > codec. What is the benefit of this work if you don’t get RF codecs? So far, > it really seems to be the only argument to start this work. And there is likewise absolutely no warranty that the most expensive patent-pending codec you could licence today will not also be subject to further claims from other third parties, long after you've taken them to the full deployment stage. This seems like a completely neutral argument that has no relevance to either side of the debate. The IETF has well defined policies for dealing with these issues. Why do you think those are less applicable here than to any other standard it has published? > And there is something some people seem to always forget/ignore is that > there are already some standards that are RF codecs: G.722, G.722.1, > G.722.1C, G.711 and certainly some others. Some people say they don’t fit > their needs, but when I read the current draft charter it does not seem to > be true as these codecs perfectly fit it. The fact that these codecs have RF > conditions because either it was a company choice to offer them for free or > because their patents ran out is irrelevant to the discussion. The fact is > there are already RF codecs. If you really believe that G.711 is "good enough" for these purposes, and that is the opinion of other SDOs, then that seems like the most compelling argument I've seen so far for why this WG is desperately needed. > Then we can read that you need an Internet dedicated codec, but so far in > the charter there is nothing special that could make me thinking, yes this > is an Internet codec. What do you think is missing that would make you think that? I'm sure suggestions along those lines would be very well received, and was indeed what further discussion should be focussing on right now. If you know and don't want to share, that seems like politics, not engineering. > To your last point, why should you rely on other SDOs: > - because usually it is where main telcos, vendors and experts are, If they had served this purpose well do you really think there would be so much momentum behind forming this research group? There are clearly experts outside of this closed 'inner circle'. If those people feel that these groups have become obstructive or irrelevant, who do you really think could possibly be to blame for that? > - because their codec evaluation/characterization is well defined, > - because their codec applications/requirements are well organized and codec > standardization is started based on these definitions. Are you implying that they somehow have an exclusive franchise on the fundamentals of signal processing and engineering that have changed little in the last 20 years? If the argument is this group has no competence, then clearly other SDOs have nothing whatsoever to fear from it. Either it will produce nothing, or junk that will be quickly debunked by the expert science of those SDOs. Or they'll create something genuinely useful and these other groups will have the chance to prove their Ultimate Wizardlyness by improving upon it. And at the end of the day, isn't that what engineering is all about? If friendly competition is the engine room of rapid innovation, what do other SDOs possibly have to fear here except failure on their own part? If they are as unquestionably expert as has been asserted, then surely they have nothing to fear at all. But I guess we'll see about that soon enough ;) Genuinely Curious, Ron From fluffy@cisco.com Fri Jul 31 06:11:04 2009 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 31BB728C259 for ; Fri, 31 Jul 2009 06:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 QUMa2NSjrXg6 for ; Fri, 31 Jul 2009 06:11:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EF5C13A68EA for ; Fri, 31 Jul 2009 06:11:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,302,1246838400"; d="scan'208";a="46209254" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2009 13:11:02 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6VDB2x9020218; Fri, 31 Jul 2009 15:11:02 +0200 Received: from dhcp-1574.meeting.ietf.org (ams3-vpn-dhcp4857.cisco.com [10.61.82.248]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VDB2ul014393; Fri, 31 Jul 2009 13:11:02 GMT Message-Id: <34B2B0FE-0CBB-4D09-B5D7-3B920AD0CB36@cisco.com> From: Cullen Jennings To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 15:11:01 +0200 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2872; t=1249045862; x=1249909862; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Summary=20of=20CODEC=20BOF |Sender:=20; bh=PrYNgAyktNhAM6gIpzKMUGdocmqPbdlqqGrkupWrKYU=; b=mSPSXmIvE0pIcZzkAUf6Gd3jVi1CtlZ/A3C7T//QxMkOgNM74ITaCKX4qx pYZHtNq+NiMjmrLhnRt3oAhMZ0mq2cHR2yv5tYxru4N8VtyBi60qRWVU3o6w pR0fw3DSzx; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [codec] Summary of CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:11:04 -0000 Thank you all very much for your attendance at the Codec BoF yesterday (especially those on the US West Coast who were up at 04:00 to join remotely). The room was packed with interested and passionate parties. The discussion was sensible and relevant. Many helpful contributions of data and perspective were provided. Much progress was made. For our part, we -- Cullen, AD, and Gregory, IAB BoF Shepherd -- apologize for ending the BoF abruptly and without healthy closure containing a sufficient summary. This email serves to provide that summary and closure. According to the general IETF process, the next steps for this efforts are: - IESG will solicit feedback from stakeholders and advisors. This includes: - Codec mail list - the broader community (though said community really should participate on the Codec mail list) - the IAB - other SDOs - IETF liaisons to other SDOs - the IESG will then discuss and determine next steps. Options for those next steps hypothetically include: - take no additional actions (essentially, the IESG stops working on this) - form a Working Group - hold another BoF (perhaps in IETF76, Hiroshima) - suggest focus or specific action items to those on the Codec mail list. The IESG and IAB discussed the CODEC BOF this morning and came out with several observations about the BOF (in accordance with RFC2418, Sect 2.1): Accomplishments: - overall issue is clear and relevant - risks and urgency were flushed out - strong interest and participation - sufficient expertise - sufficient, if not strong, number of commitments to contribute to key work areas - large base of interested consumers for the technology - understanding that a goal would involved producing a royalty free codec - understanding it would not be possible to guarantee that resulting codecs would be royalty free - clearly an open IETF effort - excellent understanding of existing work relevant, and possibly overlapping Still needs work: - better clarification/defined goals in charter, with stronger consensus - define requirements in far better depth, (I-Ds would be nice) - further investigation on the role IETF has to play in this technology area, especially in light of other SDOs The IESG's decisions and next steps: - with IAB, respond to other SDO liaisons already sent us - continue monitoring progress The IESG and IAB considers the coordination with other interested SDO's very important, especially on this topic, and will continue open coordination with other SDOs, and respond to the Liaisons sent us to date. Thanks for your continued participation, great input, healthy discussion, and (hopefully) useful text contributions. Cullen Gregory From herve.taddei@huawei.com Fri Jul 31 07:06:33 2009 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 089243A6C2C for ; Fri, 31 Jul 2009 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 dKCyUIHMsvxV for ; Fri, 31 Jul 2009 07:06:32 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 8B6933A6BC9 for ; Fri, 31 Jul 2009 07:06:31 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN005MKGIOWZ@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 31 Jul 2009 15:06:25 +0100 (BST) Received: from PCHERVE ([10.200.70.146]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNN00EB4GIOLA@lhrga02-in.huawei.com> for codec@ietf.org; Fri, 31 Jul 2009 15:06:24 +0100 (BST) Date: Fri, 31 Jul 2009 16:06:24 +0200 From: Herve Taddei In-reply-to: <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> To: codec@ietf.org Message-id: <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_iddr8eGIq3uIK8m6ZkgWLg)" Thread-index: AcoR3bvROSjLbM8FRf6cdOnWTTVtrwAARzpA References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:06:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iddr8eGIq3uIK8m6ZkgWLg) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable > Sorry, probably you do not follow, but RF requirement was put on the = very > first slides and repeated several times later. Moreover, several = serious It is one thing to put them on the slide, it is another thing to get it. BTW, you can give a look from IESG BOF report: =93- understanding it = would not be possible to guarantee that resulting codecs would be royalty free=94 =20 > Sorry, these codecs does not meet other criteria. They're not = bandwidth > efficient, they do not behave well in the presence of packet loss, = etc. What is bandwidth efficient and robust enough? Please come up with = values I have not seen them so far. For example, from the list of codecs presented yesterday CELT has a = bitrate between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 kbit/s. = Are those the bandwidth efficient codecs? FYI, the codecs I listed have = bitrates between 32 and 64 kbit/s. =20 > Please, read all requirements again. Think of them together, not about > each one separately. Requirements? Where? There is a charter and a slide with technical considerations from the presentation yesterday that don=92t seem to be requirements to me. Or are there what you call requirements? So far we = only got some kind of very standard list of codec features, nothing special. BTW from BOF meeting report: - define requirements in far better depth, (I-Ds would be nice) At least it seems that it was agreed that it is needed to clarify that. =20 > Sounds good, with the only exception, I mentioned above - absence of > RF codec they standardized.=20 Wrong as said at the beginning of my email. =20 > the use of the Internet programmers, not telco ones. Plus absence of > really low-delay WB codec. Plus inability to participate for usual = people, > not belonging to big telcos. Oh, isn't there too much exceptions? =20 Do you know the delay of G.722? Do you think you will be able to do = less? I would be quite interested (fyi, 2 samples at 16 kHz, I let you compute). =20 Finally, small companies also participate to other SDOs, please give a = look to their member lists. =20 Best regards =20 Herv=E9 =20 --Boundary_(ID_iddr8eGIq3uIK8m6ZkgWLg) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

> Sorry, probably you do not follow, but RF = requirement was put on the very

> first slides and repeated several times later. Moreover, several serious

It is one = thing to put them on the slide, it is another thing to get = it.

BTW, you can = give a look from IESG BOF report: =93- understanding it would not be possible = to guarantee that resulting codecs would be royalty = free=94

 

> Sorry, these codecs does not meet other = criteria. They're not bandwidth

> efficient, they do not behave well in the = presence of packet loss, etc.

What is = bandwidth efficient and robust enough? Please come up with values I have not seen = them so far.

For example, = from the list of codecs presented yesterday CELT has a bitrate between 40 and 128 = kbit/s, SBC has a bitrate between 50 to 350 kbit/s. Are those the bandwidth = efficient codecs? FYI, the codecs I listed have bitrates between 32 and 64 = kbit/s.

 

> Please, read all requirements again. Think of = them together, not about

> each one = separately.

Requirements? = Where? There is a charter and a slide with technical considerations from the = presentation yesterday that don=92t seem to be requirements to me. Or are there what = you call requirements? So far we only got some kind of very standard list of codec features, = nothing special.

BTW from BOF = meeting report:

- define = requirements in far better depth, (I-Ds would be nice)

At least it = seems that it was agreed that it is needed to clarify = that.

 

> Sounds good, with the only exception, I = mentioned above - absence of

> RF codec they standardized. =

Wrong as said = at the beginning of my email.

 

> the use of the Internet programmers, not telco = ones. Plus absence of

> really low-delay WB codec. Plus inability to participate for usual people,

> not belonging to big telcos. Oh, isn't there = too much exceptions?

 

Do you know = the delay of G.722? Do you think you will be able to do less? I would be quite = interested (fyi, 2 samples at 16 kHz, I let you = compute).

 

Finally, small companies also participate to other SDOs, please give a look to their = member lists.

 

Best = regards

 

Herv=E9

 

--Boundary_(ID_iddr8eGIq3uIK8m6ZkgWLg)-- From mramalho@cisco.com Fri Jul 31 07:21:44 2009 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 E309E3A6942 for ; Fri, 31 Jul 2009 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ECj+loe3+a6 for ; Fri, 31 Jul 2009 07:21:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 82B9828C32C for ; Fri, 31 Jul 2009 07:21:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFADOackpAZnme/2dsb2JhbACCJi+3N4gpkDwFhBg X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208,217";a="52447256" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2009 14:21:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6VELWIC016800 for ; Fri, 31 Jul 2009 10:21:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VELV4a000523 for ; Fri, 31 Jul 2009 14:21:31 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 10:21:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA11EA.3370D29D" Date: Fri, 31 Jul 2009 10:20:50 -0400 Message-ID: In-Reply-To: <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoRySJmC/YId01AQ/y6tivJjpuoWAAFjHQQ X-Priority: 5 Priority: Non-Urgent Importance: low References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> From: "Michael Ramalho (mramalho)" To: X-OriginalArrivalTime: 31 Jul 2009 14:21:31.0988 (UTC) FILETIME=[33A3E940:01CA11EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25927; t=1249050092; x=1249914092; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[codec]=20Codec=20Standardization=20Exp ertise |Sender:=20 |To:=20; bh=qfWSwdL/7Yl0DyABPbYvJXhdG419RMY17krWcn4GZgQ=; b=rU4VQIo6THkl/rx6dsd4KAfITKY4kd7YJlR4irn1iEBCiXX54G2E6i0hUj SjK18vJh2lvyXPFSFfNtHL5eldaqD44izgiHuLcdWyUVDc4FSp6gDkE6nYxk 4Qr+FiWCDL; Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:21:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA11EA.3370D29D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Ideal VoIP Codec" Commentary follows: =20 1>>>From Mikael Abrahamsson Saying you need a lower rate in case of congestion isn't the case either, that won't help yourself anything because you're most likely competing with TCP flows which will take all they can get. AND So the codec and underlying transport cannot *influence* the network IP behavior, but it needs to be able to ADAPT to it and handle it, providing as good user experience as possible. >>> =20 2>>>From Alexander Chemeris PS While your statement that there is nothing new invented here (yet) is correct, you miss that while everyone knows the problems, there are still no ideal VoIP codec. >>> =20 3>>>From Stephen Botzko Ignoring congestion on the grounds that other flows might ignore it also does not seem to be a very useful approach. >>>=20 =20 To me these comments are all manifestations of the same basic fact for non-QoS Internet transport: =20 If you VoIP flow constitutes a MINORITY FLOW in a general elastic flow (i.e., more TCP or SCTP than UDP) at your bottleneck link ... then changing your VoIP rate will have minimal impact on the congestion at the bottleneck link ... as that congestion is primarily a function of the elastic traffic. This relates to Comment 1 above. =20 The problem is that you don't know by observing your flow if indeed your traffic (or your traffic type, in this case inelastic UDP) is a MAJORITY traffic or not. If the bottleneck link consisted of mostly inelastic traffic (perhaps a VoIP service provider), then reducing your rate will indeed help with congestion. If your VoIP flow is a minority traffic type in the bottleneck link - a reduction in the VoIP sending rate may have NO (significant) EFFECT on clearing congestion (owing to how the elastic protocols work). =20 Therefore reducing your rate under observed congestion MAY OR MAY NOT help the congestion on your path - but will definitely degrade your experience. Indeed, some VoIP implementations (that I do not sanction) actually increase their rate to improve their performance during poor Internet transport (shame on them). =20 If you: 1) are using non-QoS transport and 2) have no detailed knowledge of the (elastic vs. inelastic) traffic mix in the bottleneck link .... then you simply do not know if rate reduction will help regarding congestion. I think this is the reason for comment #3. =20 So what to do? What is the "ideal VoIP codec" (comment 2 above)? =20 It depends on your application space (use case). =20 If you are a VoIP service provider and your codec has the ability to reduce its rate significantly (perhaps going from wideband to narrowband), rate reduction should be a part of your ideal codec. Why? Because your VoIP traffic is likely a majority flow in some bottleneck link. =20 If you are a large VoIP user, and you know that your inelastic traffic can - at potential bottlenecks - be a majority traffic type, rate reduction should be a part of your ideal codec. =20 If you are an isolated user (perhaps an individual peer-to-peer application) where your VoIP flow is pretty much guaranteed to be a minority flow in a mostly elastic traffic (at any potential bottleneck link), then rate reduction is probably not in your best interest (as the other elastic traffic you have no control over effectively dictate your transport performance and will consume any bandwidth reduction you provide). =20 The problem is, the codec itself cannot tell - it can only observe loss. =20 Can we get off the topic of "ideal Internet codec" now? And move to what we can and should implement. =20 Appropriate options should be a part of any codec design. We already mentioned that we should be able to enable/disable time scale modification. I think we should agree that appropriate rate adaption knobs should also be provided (along with guidance on how to set them for a particular use case). =20 Not to pontificate about other SDOs ... but ... defining the USE CASES for such a codec will go a long way to designing the right knobs/options the "Internet codec" should have. Let's stop trying to convince others with email about what characteristics a singular "ideal VoIP codec" should have from the perspective of a single use case. "The Internet" ISN'T a singular use case (hopefully that should be obvious by now). =20 Rather, let's move to a requirements/use case analysis of what characteristics are needed in the anticipated VoIP environments (use cases). I would like to see a combined requirements and use case document before we progress further - as no one use case assumption should "win". =20 Off Soapbox, =20 Michael Ramalho =20 PS - If you have commentary, please respond with facts with minimal inflammatory innuendo. =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko Sent: Friday, July 31, 2009 6:24 AM To: Mikael Abrahamsson Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise =20 >>> Saying you need a lower rate in case of congestion isn't the case either, that won't help yourself anything because you're most likely competing with TCP flows which will take all they can get. What you need to do is "stand your ground" ... >>> I do not believe this is the prevailing view in the IETF. It is inconsistent with the language in newer packetization RFCs, including the language in RFC 5404. Likewise section 2.4 of RFC 3550 clearly implies that the appropriate adaptation to network congestion is to reduce bandwidth use. =20 Ignoring congestion on the grounds that other flows might ignore it also does not seem to be a very useful approach. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 1:17 AM, Mikael Abrahamsson wrote: On Thu, 30 Jul 2009, stephen botzko wrote: But to be fair, the issues with jitter and packet loss are generally due to the packetization constraints in the RTP RFC, not the ITU-T spec itself. G.719's packetization RFC allows for interleaved and overlapped (redundant) audio frames, and permits the duplicate frames to be at lower rates. That allows for good quality to be maintained under packet loss conditions (though if the network is congested, of course you need to use an overall lower rate).. All the codecs I've used will recover state very quickly when conditions improve. I can't see how the codec can solve an end-to-end delay problem, it seems to me that if the delay doesn't heal itself when conditions improve, it is likely to be a transport problem that the codec can't influence. =20 We need to design something that works, and that involves creating a codec and a transport that handles the real world, not trying to adapt the real world to the constraints of the codec and transport. Saying you need a lower rate in case of congestion isn't the case either, that won't help yourself anything because you're most likely competing with TCP flows which will take all they can get. What you need to do is "stand your ground", perhaps go for lower sound quality but keep the bitrate so the packets you actually get through will make sounds at the other end that is as good as it can get during the conditions. G.719 might do this as you say, I don't know. We need a codec and transport that when faced with adverse network conditions will handle this gracefully and adapt its jitter buffer (if jitter increases to 1s, it should increase its jitter buffer to handle this, then when network conditions improve it needs to somehow lower the jitter buffer again which means it'll have to play sound "faster" to catch up). All this needs to work between the codec/transport layers, and information regarding sound needs to be spread across several packets in case of packet loss (degrade sound quality nicely), and to retain the low end-to-end delay when network conditions are good, it also needs to go back to the usual "all sound for these 20ms sound in one packet"-mode for that. So the codec and underlying transport cannot *influence* the network IP behavior, but it needs to be able to ADAPT to it and handle it, providing as good user experience as possible. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------_=_NextPart_001_01CA11EA.3370D29D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Ideal VoIP = Codec” Commentary follows:

 

1>>>From = Mikael Abrahamsson
Saying you need a lower rate in case of congestion isn't the case = either, that won't help yourself anything because you're most likely competing with = TCP flows which will take all they can get.

AND

So the codec and underlying transport cannot *influence* = the network IP behavior, but it needs to be able to ADAPT to it and handle = it, providing as good user experience as possible.
>>>

 

2>>>From = Alexander Chemeris

PS While your statement = that there is nothing new invented here (yet) is correct, you miss that while = everyone knows the problems, there are still no ideal VoIP codec.
>>>

=

 

3>>>From Stephen Botzko

Ignoring congestion on = the grounds that other flows might ignore it also does not seem to be a very useful approach.

>>> 

 

To me these comments = are all manifestations of the same basic fact for non-QoS Internet = transport:

 

If you VoIP flow = constitutes a MINORITY FLOW in a general elastic flow (i.e., more TCP or SCTP than UDP) at your bottleneck link … then changing your VoIP rate will have minimal = impact on the congestion at the bottleneck link … as that congestion is primarily a function of the elastic traffic. This relates to Comment 1 = above.

 

The problem is that you = don’t know by observing your flow if indeed your traffic (or your traffic = type, in this case inelastic UDP) is a MAJORITY traffic or not. If the bottleneck = link consisted of mostly inelastic traffic (perhaps a VoIP service provider), = then reducing your rate will indeed help with congestion. If your VoIP flow = is a minority traffic type in the bottleneck link – a reduction in the = VoIP sending rate may have NO (significant) EFFECT on clearing congestion = (owing to how the elastic protocols work).

 

Therefore reducing your = rate under observed congestion MAY OR MAY NOT help the congestion on your path = – but will definitely degrade your experience. Indeed, some VoIP = implementations (that I do not sanction) actually increase their rate to improve their performance during poor Internet transport (shame on = them).

 

If you: 1) are using = non-QoS transport and 2) have no detailed knowledge of the (elastic vs. = inelastic) traffic mix in the bottleneck link …. then you simply do not know = if rate reduction will help regarding congestion. I think this is the reason for comment #3.

 

So what to do? What is = the “ideal VoIP codec” (comment 2 above)?

 

It depends on your = application space (use case).

 

If you are a VoIP = service provider and your codec has the ability to reduce its rate significantly (perhaps = going from wideband to narrowband), rate reduction should be a part of your = ideal codec. Why? Because your VoIP traffic is likely a majority flow in some bottleneck link.

 

If you are a large VoIP = user, and you know that your inelastic traffic can – at potential = bottlenecks – be a majority traffic type, rate reduction should be a part of your = ideal codec.

 

If you are an isolated = user (perhaps an individual peer-to-peer application) where your VoIP flow is = pretty much guaranteed to be a minority flow in a mostly elastic traffic (at = any potential bottleneck link), then rate reduction is probably not in your = best interest (as the other elastic traffic you have no control over = effectively dictate your transport performance and will consume any bandwidth reduction you provide).

 

The problem is, the = codec itself cannot tell – it can only observe loss.

 

Can we get off the = topic of “ideal Internet codec” now? And move to what we can and should = implement.

 

Appropriate options = should be a part of any codec design. We already mentioned that we should be able to = enable/disable time scale modification. I think we should agree that appropriate rate = adaption knobs should also be provided (along with guidance on how to set them = for a particular use case).

 

Not to pontificate = about other SDOs … but … defining the USE CASES for such a codec will go = a long way to designing the right knobs/options the “Internet = codec” should have. Let’s stop trying to convince others with email about = what characteristics a singular “ideal VoIP codec” should have = from the perspective of a single use case. “The Internet” ISN’T = a singular use case (hopefully that should be obvious by = now).

 

Rather, let’s = move to a requirements/use case analysis of what characteristics are needed in the = anticipated VoIP environments (use cases). I would like to see a combined = requirements and use case document before we progress further – as no one use case assumption should “win”.

 

Off = Soapbox,

 

Michael = Ramalho

 

PS – If you have = commentary, please respond with facts with minimal inflammatory = innuendo.

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Friday, July 31, 2009 6:24 AM
To: Mikael Abrahamsson
Cc: codec@ietf.org
Subject: Re: [codec] Codec Standardization = Expertise

 

>>>
Saying you need a lower rate in case of congestion isn't the case = either, that won't help yourself anything because you're most likely competing with = TCP flows which will take all they can get. What you need to do is = "stand your ground" ...
>>>

I do not believe this is the prevailing view in the IETF. It is = inconsistent with the language in newer packetization RFCs, including the language in = RFC 5404.  Likewise section 2.4 of RFC 3550 clearly implies that the appropriate adaptation to network congestion is to reduce bandwidth = use. 

Ignoring congestion on the grounds that other flows might ignore it also = does not seem to be a very useful approach.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 1:17 AM, Mikael Abrahamsson = <swmike@swm.pp.se> = wrote:

On Thu, 30 Jul 2009, = stephen botzko wrote:

But to be fair, the issues with jitter and packet = loss are generally due to the packetization constraints in the RTP RFC, not the = ITU-T spec itself. G.719's packetization RFC allows for interleaved and = overlapped (redundant) audio frames, and permits the duplicate frames to be at = lower rates.  That allows for good quality to be maintained under packet = loss conditions (though if the network is congested, of course you need to = use an overall lower rate)..  All the codecs I've used will recover state = very quickly when conditions improve.  I can't see how the codec can = solve an end-to-end delay problem, it seems to me that if the delay doesn't heal = itself when conditions improve, it is likely to be a transport problem that the = codec can't influence.

 

We need to design something that works, and that = involves creating a codec and a transport that handles the real world, not trying = to adapt the real world to the constraints of the codec and transport. = Saying you need a lower rate in case of congestion isn't the case either, that = won't help yourself anything because you're most likely competing with TCP flows = which will take all they can get. What you need to do is "stand your ground", perhaps go for lower sound quality but keep the bitrate so = the packets you actually get through will make sounds at the other end that = is as good as it can get during the conditions. G.719 might do this as you = say, I don't know.

We need a codec and transport that when faced with adverse network = conditions will handle this gracefully and adapt its jitter buffer (if jitter = increases to 1s, it should increase its jitter buffer to handle this, then when = network conditions improve it needs to somehow lower the jitter buffer again = which means it'll have to play sound "faster" to catch up). All this = needs to work between the codec/transport layers, and information regarding = sound needs to be spread across several packets in case of packet loss = (degrade sound quality nicely), and to retain the low end-to-end delay when network = conditions are good, it also needs to go back to the usual "all sound for = these 20ms sound in one packet"-mode for that.

So the codec and underlying transport cannot *influence* the network IP behavior, but it needs to be able to ADAPT to it and handle it, = providing as good user experience as possible.



--
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------_=_NextPart_001_01CA11EA.3370D29D-- From stephen.botzko@gmail.com Fri Jul 31 07:44:38 2009 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 0ADE43A6AC1 for ; Fri, 31 Jul 2009 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.459, 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 4hu+TC7OOiH5 for ; Fri, 31 Jul 2009 07:44:36 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 2F8A428C21A for ; Fri, 31 Jul 2009 07:43:52 -0700 (PDT) Received: by bwz19 with SMTP id 19so1234697bwz.37 for ; Fri, 31 Jul 2009 07:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=OcyZa1rGI13YAYT1M+n16zZYzNSHsqVWQTrm7qhWstk=; b=k5QxusT0VxUkigxuLTlEfWwN8JttUseerULUfi1L7HvjEWhPMXtSuGakS3AxZu8L2Y mydc64P20awHBA4vydtkbUzkgEL92tAM3CK+pWZCqoOmXycQDaKwS0AbXy+5hicD0efn j+1flr7oapdVKNgjiGi1nFB8P/k2IRXIuicP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oG1eVNPQDoEsR/AizcnzYwuVvGiSzYdtuitQ7Gc6oL/9os2Wd/1S4EDlCbWZFp4fnR J6Z1hQIttjLi2x32M5ixIMtI95+0LOU8zY5k7LV6+EniLHROKkqJTMbD7Imjd9ckQZqb seRNZFQmtuy+CaSfiva+8qLvhD6jAJYfTPpLc= MIME-Version: 1.0 Received: by 10.102.228.10 with SMTP id a10mr141189muh.81.1249051430722; Fri, 31 Jul 2009 07:43:50 -0700 (PDT) Date: Fri, 31 Jul 2009 10:43:50 -0400 Message-ID: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016363ba6acd59eda047001721f Subject: [codec] Architectural Considerations X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:44:38 -0000 --0016363ba6acd59eda047001721f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Now that Mikael and I have found we were in violent agreement, I would like to move on (retitling the thread). The basic architecture for SIP and RTP is well established, and I thought was well accepted. However, there are several comments on this list that make me wonder. Today, adaptation to network conditions is a shared responsibility, with some requirements on the codec layer, others on the transport layer, and still others on the application. Several comments (mostly criticism) of the ITU-T codecs indicate that many of the posters here have a different view of how this architecture is supposed to work. Many comments are about inadequate response to jitter for instance are not relevant to the codec. They *are* relevant to the RTP transport and to the application's implementation choices, but not to the codec itself. I'd like go back to the G.719 example (of course I like that codec, but the main reason is that it is representative of current work, and allows me to make my architectural point). (1) The codec itself (defined in the ITU-T) provides a range of output bitrates that is useful over a pretty wide range of link capacities. The state carried over between audio frames is limited, and self-synchronizing. So the decoder automatically re-syncs to the encoder state after packet loss. Frame erasure concealment (e.g. packet loss concealment) is built into the algorithm. (2) The packetization RFC (defined in the IETF), provides the facilities to handle jitter and congestion control. It allows multiple audio frames to be placed in a packet. These frames can be interleaved or redundant. The codec bitrate can be changed on a frame by frame basis without signaling. SDP signaling assures that the relevant facilities for the application can be negotiated. For instance, interleaved transmission is generally not appropriate for conversational applications, so the signaling allows its use to be negotiated. Also, the variable bitrate features of the algorithm might not be possible through some gateways, so it is possible to negotiate a CBR mode of operation. In addition, general RTP facilities (such as forward error correction, etc) are available in codec-independent fashion. RTCP provides feedback to the sender on the quality of the transmission. (3) Although the IETF provides the facilities to handle jitter and congestion control, the application is responsible to use them. For instance, it is the application's job to provide a suitable depth for the dejittering/packet reordering queue, and to manage any delay that the queue creates. Additional packet loss concealment (beyond what is built in) can also be implemented as a post-process. On the whole, I find this architecture to be well-reasoned. The main issue with it from a quality point of view is that there is perhaps not enough guidance for the application designer to handle (3). Let me switch to G.711/G.722, and look again at the three layers. The story is quite consistent, though comfort noise is probably done on the wrong level. (1) Although these codecs predate the internet, they are capable of running at three different bitrates (48, 56, 64 kbits). This is not as broad a range as one would like, but still it is something. They are both sample-based codecs, so they have quite low algorithmic delay. Sample-to-sample state is non-existent with G.711, and is quickly self-synchronized with G.722. Specific Packet loss procedures are recommended by the ITU, though they are not mandated (since they do not apply for all applications, and there are billions of old implementations that predate the internet). (2) The packetization RFC for both these codecs allows for basically any number of samples to be placed in an RTP packet. The reduced bitrates of 48 and 56 kbs can be used, but the *RFC* requires them to be padded to 64 kbs, so there is no benefit. General RTP facilities, including forward error concealment *and* audio redundancy encoding (RFC 2198) can be used. Average bit rate of the codecs can be reduced using the comfort noise payload specified in RFC 3389. RTCP provides feedback to the sender on the quality of the transmission. (3) Application designers have the same responsibility here as they do with G.719. Looking at what is missing here from a system design perspective, I see a couple of things. (a) There is no clear guidance on how to measure congestion, and no reference model on how to respond. The underlying tools are present, but there is no guidance on how to use them effectively or interoperably. In my view, this is mostly a transport/application issue, and not properly viewed as a codec issue. (b) Although the benefits of adaptively sized dejitter buffering, etc are well understood, they are often not implemented in real applications. Likewise RTCP support is commonly omitted in many applications, so there is no feedback to the source on packet loss, and often the application makes no attempt to adapt to it. The packet loss concealment method that is already specified is not always used. Standardization (preferably in the IETF) is a reasonable way to deal with (a). Most of that work is clearly outside the scope of a codec group. I don't see how standardization can help with (b). My main argument here is that the codec group should be focused on the first layer of the existing architecture, and not expand the work into the transport and application. Some of the posts/discussion comments seem to imply otherwise - either by explicitly indicating that transport work should be included, or by implicitly by raising deficiencies of existing implementations that are not due to the codec at all, but are properly fixed in the transport or in the applicaton implementation. Perhaps I am wrong, but I do think some clarity on this subject might be helpful in working out the charter. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 7:22 AM, Mikael Abrahamsson wrote: > On Fri, 31 Jul 2009, stephen botzko wrote: > > Ok. You ended up agreeing with what I said in my first post. I pointed >> out >> the redundant frames/interleaved frame transmission in the G.719 rfc, but >> said you should also switch to a lower bandwidth mode if the network were >> congested. >> > > Absolutely, I never meant to advocate *increasing* bw by means of > maintaining codec bw but transmitting more redundant information, thus > increasing the overall IP bits/s used. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016363ba6acd59eda047001721f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Now that Mikael and I have found we were in violent agreement, I would like= to move on (retitling the thread).

The basic architecture for SIP a= nd RTP is well established, and I thought was well accepted.=A0 However, th= ere are several comments on this list that make me wonder.=A0

Today, adaptation to network conditions is a shared responsibility, wit= h some requirements on the codec layer, others on the transport layer, and = still others on the application.=A0 Several comments (mostly criticism) of = the ITU-T codecs indicate that many of the posters here have a different vi= ew of how this architecture is supposed to work.=A0 Many comments are about= inadequate response to jitter for instance are not relevant to the codec.= =A0 They are relevant to the RTP transport and to the application= 9;s implementation choices, but not to the codec itself.

I'd like go back to the G.719 example (of course I like that codec,= but the main reason is that it is representative of current work, and allo= ws me to make my architectural point).

(1) The codec itself (defined in the ITU-T) provides a range of output bitr= ates that is useful over a pretty wide range of link capacities.=A0 The sta= te carried over between audio frames is limited, and self-synchronizing.=A0= So the decoder automatically re-syncs to the encoder state after packet lo= ss. Frame erasure concealment (e.g. packet loss concealment) is built into = the algorithm.

(2) The packetization RFC (defined in the IETF), provides the facilitie= s to handle jitter and congestion control.=A0 It allows multiple audio fram= es to be placed in a packet.=A0 These frames can be interleaved or redundan= t.=A0 The codec bitrate can be changed on a frame by frame basis without si= gnaling.=A0 SDP signaling assures that the relevant facilities for the appl= ication can be negotiated.=A0 For instance, interleaved transmission is gen= erally not appropriate for conversational applications, so the signaling al= lows its use to be negotiated.=A0 Also, the variable bitrate features of th= e algorithm might not be possible through some gateways, so it is possible = to negotiate a CBR mode of operation.=A0 In addition, general RTP facilitie= s (such as forward error correction, etc) are=A0 available in codec-indepen= dent fashion.=A0 RTCP provides feedback to the sender on the quality of the= transmission.

(3) Although the IETF provides the facilities to handle jitter and cong= estion control, the application is responsible to use them. For instance, i= t is the application's job to provide a suitable depth for the dejitter= ing/packet reordering queue, and to manage any delay that the queue creates= .=A0 Additional packet loss concealment (beyond what is built in) can also = be implemented as a post-process.

On the whole, I find this architecture to be well-reasoned.=A0 Th= e main issue with it from a quality point of view is that there is perhaps = not enough guidance for the application designer to handle (3).

Let = me switch to G.711/G.722, and look again at the three layers.=A0 The story = is quite consistent, though comfort noise is probably done on the wrong lev= el.

(1) Although these codecs predate the= internet, they are capable of running at three different bitrates (48, 56,= 64 kbits).=A0 This is not as broad a range as one would like, but still it= is something.=A0 They are both sample-based codecs, so they have quite low= algorithmic delay.=A0 Sample-to-sample state is non-existent with G.711, a= nd is quickly self-synchronized with G.722.=A0 Specific Packet loss procedu= res are recommended by the ITU, though they are not mandated (since they do= not apply for all applications, and there are billions of old implementati= ons that predate the internet).

(2) The packetization RFC for both these codecs allows for basically an= y number of samples to be placed in an RTP packet.=A0 The reduced bitrates = of 48 and 56 kbs can be used, but the RFC requires them to be padded= to 64 kbs, so there is no benefit.=A0 General RTP facilities, including fo= rward error concealment and audio redundancy encoding (RFC 2198) can= be used.=A0 Average bit rate of the codecs can be reduced using the comfor= t noise payload specified in RFC 3389.=A0 RTCP provides feedback to the sen= der on the quality of the transmission.

(3) Application designers have the same responsibility here as they do = with G.719.

Looking at what is missing here from a system desi= gn perspective, I see a couple of things.

(a) There is no clear guidance on how to measure congestion, and no referen= ce model on how to respond.=A0 The underlying tools are present, but there = is no guidance on how to use them effectively or interoperably.=A0 In my vi= ew, this is mostly a transport/application issue, and not properly viewed a= s a codec issue.

(b) Although the benefits of adaptively sized dejitter buffering, etc a= re well understood, they are often not implemented in real applications.=A0= Likewise RTCP support is commonly omitted in many applications, so there i= s no feedback to the source on packet loss, and often the application makes= no attempt to adapt to it. The packet loss concealment method that is alre= ady specified is not always used.

Standardization (preferably in the IETF) is a reasonable way to d= eal with (a).=A0 Most of that work is clearly outside the scope of a codec = group.=A0 I don't see how standardization can help with (b).=A0
My main argument here is that the codec group should be focused on the fir= st layer of the existing architecture, and not expand the work into the tra= nsport and application.=A0 Some of the posts/discussion comments seem to im= ply otherwise -=A0 either by explicitly indicating that transport work shou= ld be included, or by implicitly by raising deficiencies of existing implem= entations that are not due to the codec at all, but are properly fixed in t= he transport or in the applicaton implementation.

Perhaps I am wrong, but I do think some clarity on this subject might b= e helpful in working out the charter.

Regards,
Stephen Botzko
= Polycom






On Fri, Jul = 31, 2009 at 7:22 AM, Mikael Abrahamsson <swmike@swm.pp.se> wr= ote:
On Fri, 31 Jul 2009, stephen botzko wrote:

Ok. =A0You ended up agreeing with what I said in my first post. I pointed o= ut
the redundant frames/interleaved frame transmission in the G.719 rfc, but said you should also switch to a lower bandwidth mode if the network were congested.

Absolutely, I never meant to advocate *increasing* bw by means of maintaini= ng codec bw but transmitting more redundant information, thus increasing th= e overall IP bits/s used.


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016363ba6acd59eda047001721f-- From dpetrie@sipez.com Fri Jul 31 07:52:57 2009 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 1C87D28C334 for ; Fri, 31 Jul 2009 07:52:57 -0700 (PDT) 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 AMNw0v+sxubK for ; Fri, 31 Jul 2009 07:52:56 -0700 (PDT) Received: from web37107.mail.mud.yahoo.com (web37107.mail.mud.yahoo.com [209.191.85.109]) by core3.amsl.com (Postfix) with SMTP id 52D8228C329 for ; Fri, 31 Jul 2009 07:52:56 -0700 (PDT) Received: (qmail 78914 invoked by uid 60001); 31 Jul 2009 14:52:56 -0000 Message-ID: <595733.78861.qm@web37107.mail.mud.yahoo.com> X-YMail-OSG: 6x1ExhcVM1myUjioNAwFQWb7Nml56EbHEg60_eBkepiTnK5UgTtAcwF.8d3gjixV6miL7frzZKu0fhL8Mx60hrtb7RRbRFVYIBHYwazGR4OQ8TKUWqrY3W2WFlZ_9fp.d8qUfVYSRlrwIMfM06wpUa5yTXV0AC0A0fs4wHKi6Kx7etoRj5pKR9L3QgRY5IvdbCA25fKJxHfjBNYizZU6TmGqzQD1ffVDU90m_wt5dvGyem2d_i9oWewesHeiszKYFbYjXM4FrFgj8UMTuYs6P3qUOi.KYC7jbjKh5Q8Lu_O4RPc9dcJP Received: from [24.61.83.127] by web37107.mail.mud.yahoo.com via HTTP; Fri, 31 Jul 2009 07:52:55 PDT X-RocketYMMF: dgpetrie X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.289.15 Date: Fri, 31 Jul 2009 07:52:55 -0700 (PDT) From: Daniel Petrie To: 'Alexander Chemeris' , 'Ingemar Johansson S' , Herve Taddei In-Reply-To: <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dpetrie@sipez.com List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:52:57 -0000 Perhaps we need a better definition of the requirements here. I think the = key point is barrier to entry. A better definition of the requirement migh= t be readily available implementations and royalty free. 722.1 and 722.1C = may be royalty free, but there is a huge filter on the access to the code. = How may open source implementations do you know of for 722.1 and 722.1C? = Has someone out there actually gone through and successfully gotten 722.1 o= r 722.1C and willing to share who much time and money that it cost them jus= t to get the codec?=0A=0AI think iLBC is a fine example of the model for ro= yalty free and readily accessable codec.=0A=0A> And there is something some= people seem to always=0A> forget/ignore is that=0A> there are already some= standards that are RF codecs: G.722,=0A> G.722.1,=0A> G.722.1C, G.711 and = certainly some others. Some people say=0A> they don=E2=80=99t fit=0A> their= needs, but when I read the current draft charter it=0A> does not seem to= =0A> be true as these codecs perfectly fit it. The fact that=0A> these code= cs have RF=0A> conditions because either it was a company choice to offer= =0A> them for free or=0A> because their patents ran out is irrelevant to th= e=0A> discussion. The fact is=0A> there are already RF codecs. =0A> =0A From Borilin@spiritdsp.com Fri Jul 31 07:55:43 2009 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 C061D28C334 for ; Fri, 31 Jul 2009 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 9rWA-4OmvlmS for ; Fri, 31 Jul 2009 07:55:33 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id C1F1A28C116 for ; Fri, 31 Jul 2009 07:55:32 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n6VEtSb4095310; Fri, 31 Jul 2009 18:55:29 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA11EE.EE3675AF" Date: Fri, 31 Jul 2009 18:55:14 +0400 Message-ID: In-Reply-To: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Architectural Considerations Thread-Index: AcoR7X2w8Jq6tBhsT02mWHutqT3xdAAASyYQ References: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> From: "Slava Borilin" To: "stephen botzko" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Architectural Considerations X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 14:55:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA11EE.EE3675AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, I tend to agree with you - WG should focus on codec (as this is interop requirement), and leave the rest to transport and not even necessarily standardize the rest, but leave as "open air" for people to implement differently. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko Sent: Friday, July 31, 2009 6:44 PM To: codec@ietf.org Subject: [codec] Architectural Considerations =20 Now that Mikael and I have found we were in violent agreement, I would like to move on (retitling the thread). The basic architecture for SIP and RTP is well established, and I thought was well accepted. However, there are several comments on this list that make me wonder. =20 Today, adaptation to network conditions is a shared responsibility, with some requirements on the codec layer, others on the transport layer, and still others on the application. Several comments (mostly criticism) of the ITU-T codecs indicate that many of the posters here have a different view of how this architecture is supposed to work. Many comments are about inadequate response to jitter for instance are not relevant to the codec. They are relevant to the RTP transport and to the application's implementation choices, but not to the codec itself. I'd like go back to the G.719 example (of course I like that codec, but the main reason is that it is representative of current work, and allows me to make my architectural point). (1) The codec itself (defined in the ITU-T) provides a range of output bitrates that is useful over a pretty wide range of link capacities. The state carried over between audio frames is limited, and self-synchronizing. So the decoder automatically re-syncs to the encoder state after packet loss. Frame erasure concealment (e.g. packet loss concealment) is built into the algorithm.=20 (2) The packetization RFC (defined in the IETF), provides the facilities to handle jitter and congestion control. It allows multiple audio frames to be placed in a packet. These frames can be interleaved or redundant. The codec bitrate can be changed on a frame by frame basis without signaling. SDP signaling assures that the relevant facilities for the application can be negotiated. For instance, interleaved transmission is generally not appropriate for conversational applications, so the signaling allows its use to be negotiated. Also, the variable bitrate features of the algorithm might not be possible through some gateways, so it is possible to negotiate a CBR mode of operation. In addition, general RTP facilities (such as forward error correction, etc) are available in codec-independent fashion. RTCP provides feedback to the sender on the quality of the transmission. (3) Although the IETF provides the facilities to handle jitter and congestion control, the application is responsible to use them. For instance, it is the application's job to provide a suitable depth for the dejittering/packet reordering queue, and to manage any delay that the queue creates. Additional packet loss concealment (beyond what is built in) can also be implemented as a post-process. On the whole, I find this architecture to be well-reasoned. The main issue with it from a quality point of view is that there is perhaps not enough guidance for the application designer to handle (3). Let me switch to G.711/G.722, and look again at the three layers. The story is quite consistent, though comfort noise is probably done on the wrong level. (1) Although these codecs predate the internet, they are capable of running at three different bitrates (48, 56, 64 kbits). This is not as broad a range as one would like, but still it is something. They are both sample-based codecs, so they have quite low algorithmic delay. Sample-to-sample state is non-existent with G.711, and is quickly self-synchronized with G.722. Specific Packet loss procedures are recommended by the ITU, though they are not mandated (since they do not apply for all applications, and there are billions of old implementations that predate the internet). (2) The packetization RFC for both these codecs allows for basically any number of samples to be placed in an RTP packet. The reduced bitrates of 48 and 56 kbs can be used, but the RFC requires them to be padded to 64 kbs, so there is no benefit. General RTP facilities, including forward error concealment and audio redundancy encoding (RFC 2198) can be used. Average bit rate of the codecs can be reduced using the comfort noise payload specified in RFC 3389. RTCP provides feedback to the sender on the quality of the transmission. (3) Application designers have the same responsibility here as they do with G.719. Looking at what is missing here from a system design perspective, I see a couple of things. (a) There is no clear guidance on how to measure congestion, and no reference model on how to respond. The underlying tools are present, but there is no guidance on how to use them effectively or interoperably. In my view, this is mostly a transport/application issue, and not properly viewed as a codec issue. (b) Although the benefits of adaptively sized dejitter buffering, etc are well understood, they are often not implemented in real applications. Likewise RTCP support is commonly omitted in many applications, so there is no feedback to the source on packet loss, and often the application makes no attempt to adapt to it. The packet loss concealment method that is already specified is not always used. Standardization (preferably in the IETF) is a reasonable way to deal with (a). Most of that work is clearly outside the scope of a codec group. I don't see how standardization can help with (b). =20 My main argument here is that the codec group should be focused on the first layer of the existing architecture, and not expand the work into the transport and application. Some of the posts/discussion comments seem to imply otherwise - either by explicitly indicating that transport work should be included, or by implicitly by raising deficiencies of existing implementations that are not due to the codec at all, but are properly fixed in the transport or in the applicaton implementation. Perhaps I am wrong, but I do think some clarity on this subject might be helpful in working out the charter. Regards, Stephen Botzko Polycom=20 On Fri, Jul 31, 2009 at 7:22 AM, Mikael Abrahamsson wrote: On Fri, 31 Jul 2009, stephen botzko wrote: Ok. You ended up agreeing with what I said in my first post. I pointed out the redundant frames/interleaved frame transmission in the G.719 rfc, but said you should also switch to a lower bandwidth mode if the network were congested. =20 Absolutely, I never meant to advocate *increasing* bw by means of maintaining codec bw but transmitting more redundant information, thus increasing the overall IP bits/s used. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------_=_NextPart_001_01CA11EE.EE3675AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen, I tend = to agree with you – WG should focus on codec (as this is interop = requirement), and leave the rest to transport and not even necessarily standardize the = rest, but leave as “open air” for people to implement = differently.

 =

best regards,

Slava = Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Friday, July 31, = 2009 6:44 PM
To: codec@ietf.org
Subject: [codec] = Architectural Considerations

 

Now that = Mikael and I have found we were in violent agreement, I would like to move on = (retitling the thread).

The basic architecture for SIP and RTP is well established, and I = thought was well accepted.  However, there are several comments on this list = that make me wonder. 

Today, adaptation to network conditions is a shared responsibility, with = some requirements on the codec layer, others on the transport layer, and = still others on the application.  Several comments (mostly criticism) of = the ITU-T codecs indicate that many of the posters here have a different = view of how this architecture is supposed to work.  Many comments are about inadequate response to jitter for instance are not relevant to the = codec.  They are relevant to the RTP transport and to the application's implementation choices, but not to the codec itself.

I'd like go back to the G.719 example (of course I like that codec, but = the main reason is that it is representative of current work, and allows me = to make my architectural point).

(1) The codec itself (defined in the ITU-T) provides a range of = output bitrates that is useful over a pretty wide range of link = capacities.  The state carried over between audio frames is limited, and self-synchronizing.  So the decoder automatically re-syncs to the = encoder state after packet loss. Frame erasure concealment (e.g. packet loss concealment) is built into the algorithm.

(2) The packetization RFC (defined in the IETF), provides the facilities = to handle jitter and congestion control.  It allows multiple audio = frames to be placed in a packet.  These frames can be interleaved or redundant.  The codec bitrate can be changed on a frame by frame = basis without signaling.  SDP signaling assures that the relevant = facilities for the application can be negotiated.  For instance, interleaved = transmission is generally not appropriate for conversational applications, so the = signaling allows its use to be negotiated.  Also, the variable bitrate = features of the algorithm might not be possible through some gateways, so it is = possible to negotiate a CBR mode of operation.  In addition, general RTP = facilities (such as forward error correction, etc) are  available in = codec-independent fashion.  RTCP provides feedback to the sender on the quality of = the transmission.

(3) Although the IETF provides the facilities to handle jitter and = congestion control, the application is responsible to use them. For instance, it is = the application's job to provide a suitable depth for the dejittering/packet reordering queue, and to manage any delay that the queue creates.  Additional packet loss concealment (beyond what is built in) can also be implemented as a post-process.


On the whole, I find this architecture to be well-reasoned.  The = main issue with it from a quality point of view is that there is perhaps not = enough guidance for the application designer to handle (3).

Let me switch to G.711/G.722, and look again at the three layers.  = The story is quite consistent, though comfort noise is probably done on the = wrong level.

(1) Although these codecs predate the internet, they are capable = of running at three different bitrates (48, 56, 64 kbits).  This is = not as broad a range as one would like, but still it is something.  They = are both sample-based codecs, so they have quite low algorithmic delay.  Sample-to-sample state is non-existent with G.711, and is quickly self-synchronized with G.722.  Specific Packet loss procedures are recommended by the ITU, though they are not mandated (since they do not = apply for all applications, and there are billions of old implementations that predate the internet).

(2) The packetization RFC for both these codecs allows for basically any = number of samples to be placed in an RTP packet.  The reduced bitrates of = 48 and 56 kbs can be used, but the RFC requires them to be padded to 64 = kbs, so there is no benefit.  General RTP facilities, including forward = error concealment and audio redundancy encoding (RFC 2198) can be = used.  Average bit rate of the codecs can be reduced using the comfort noise = payload specified in RFC 3389.  RTCP provides feedback to the sender on the quality of the transmission.

(3) Application designers have the same responsibility here as they do = with G.719.


Looking at what is missing here from a system design perspective, I see = a couple of things.

(a) There is no clear guidance on how to measure congestion, and = no reference model on how to respond.  The underlying tools are = present, but there is no guidance on how to use them effectively or = interoperably.  In my view, this is mostly a transport/application issue, and not properly = viewed as a codec issue.

(b) Although the benefits of adaptively sized dejitter buffering, etc = are well understood, they are often not implemented in real applications.  = Likewise RTCP support is commonly omitted in many applications, so there is no = feedback to the source on packet loss, and often the application makes no attempt = to adapt to it. The packet loss concealment method that is already = specified is not always used.


Standardization (preferably in the IETF) is a reasonable way to deal = with (a).  Most of that work is clearly outside the scope of a codec group.  I don't see how standardization can help with (b).  =

My main argument here is that the codec group should be focused on the = first layer of the existing architecture, and not expand the work into the = transport and application.  Some of the posts/discussion comments seem to = imply otherwise -  either by explicitly indicating that transport work = should be included, or by implicitly by raising deficiencies of existing = implementations that are not due to the codec at all, but are properly fixed in the = transport or in the applicaton implementation.

Perhaps I am wrong, but I do think some clarity on this subject might be helpful in working out the charter.

Regards,
Stephen Botzko
Polycom





On Fri, Jul 31, 2009 at 7:22 AM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:

On Fri, 31 Jul = 2009, stephen botzko wrote:

Ok.  You ended up agreeing with what I said in my first = post. I pointed out
the redundant frames/interleaved frame transmission in the G.719 rfc, = but
said you should also switch to a lower bandwidth mode if the network = were
congested.

 

Absolutely, I never meant to advocate *increasing* bw by means = of maintaining codec bw but transmitting more redundant information, thus increasing the overall IP bits/s used.



--
Mikael Abrahamsson    email: swmike@swm.pp.se

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------_=_NextPart_001_01CA11EE.EE3675AF-- From brian@freeswitch.org Fri Jul 31 08:02:19 2009 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 C01FB28C2BA for ; Fri, 31 Jul 2009 08:02:19 -0700 (PDT) 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 PDRc3NI-sfw3 for ; Fri, 31 Jul 2009 08:02:18 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 928B328C358 for ; Fri, 31 Jul 2009 08:02:18 -0700 (PDT) Received: by pxi42 with SMTP id 42so705949pxi.29 for ; Fri, 31 Jul 2009 08:02:18 -0700 (PDT) Received: by 10.115.94.11 with SMTP id w11mr2580867wal.121.1249052538093; Fri, 31 Jul 2009 08:02:18 -0700 (PDT) Received: from imac.bkw.org (imac.bkw.org [99.185.85.1]) by mx.google.com with ESMTPS id v9sm5446017wah.36.2009.07.31.08.02.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 08:02:17 -0700 (PDT) Message-Id: From: Brian West To: dpetrie@sipez.com In-Reply-To: <595733.78861.qm@web37107.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 10:02:14 -0500 References: <595733.78861.qm@web37107.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 15:02:19 -0000 Daniel, I know of one such implementation of G.722.1 and G.722.1C that is open source and readily available. Better yet its even been wrapped up in to a nice API that you can easily use it in a Multi threaded application. I know pjsip has one in their SVN tree also. http://svn.freeswitch.org/svn/freeswitch/trunk/libs/libg722_1/ http://svn.freeswitch.org/svn/freeswitch/trunk/src/mod/codecs/mod_siren/mod_siren.c I did obtain special permission to put the code in our SVN to lower the burden on the users of FreeSWITCH to use this codec. For anyone shipping a commercial product using this codec in binary form will need to acquire a license from Polycom directly as per the notice at the top of mod_siren.c (guess I should rename this to mod_g7221 or something equally descriptive now) Thanks, Brian On Jul 31, 2009, at 9:52 AM, Daniel Petrie wrote: > > Perhaps we need a better definition of the requirements here. I > think the key point is barrier to entry. A better definition of the > requirement might be readily available implementations and royalty > free. 722.1 and 722.1C may be royalty free, but there is a huge > filter on the access to the code. How may open source > implementations do you know of for 722.1 and 722.1C? Has someone > out there actually gone through and successfully gotten 722.1 or > 722.1C and willing to share who much time and money that it cost > them just to get the codec? > > I think iLBC is a fine example of the model for royalty free and > readily accessable codec. From alexander.chemeris@gmail.com Fri Jul 31 08:40:24 2009 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 80FBD3A6E61 for ; Fri, 31 Jul 2009 08:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 DISbsA2Ipz7P for ; Fri, 31 Jul 2009 08:40:23 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id B28C93A6C98 for ; Fri, 31 Jul 2009 08:40:22 -0700 (PDT) Received: by bwz19 with SMTP id 19so1266742bwz.37 for ; Fri, 31 Jul 2009 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=M3Oal53XOW7TWnk1y7zAnk15fls6p31uQhWk1rHiepk=; b=mioJG1S2VaYrzdOgRKGRgdRluJldiN3TEh78shYmOP4QErphmvh9lOCDbilm7FUwVm lmMwWMMTG73BvUp5K4JmSngDx+cee34m4dejyL3d+BNndn65Xztb04oSoVFpyZAHxyrH KV2f1GGN1CHoqRAE5J2nLvGlK+7bLyarlMNNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=v5e05JTSKbMoIBB9V65To89oy1/aBFcOnQgnic5mrsloGyadqfDztfUZIGTuvbSUcD ds7stiYkOAA79zqDbXfEUzykjDrBY55xcUvTVXHQSUBMN/27rvxA/v10VOKSAvbL9Xiw H202OTY9ToLexClObYyRL8LMGZTG0nFOPzwf4= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.6.11 with SMTP id j11mr1574882mui.107.1249054822087; Fri, 31 Jul 2009 08:40:22 -0700 (PDT) In-Reply-To: <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> From: Alexander Chemeris Date: Fri, 31 Jul 2009 19:40:01 +0400 X-Google-Sender-Auth: d4d74865bbb75135 Message-ID: <3d032e5d0907310840j54276e19xc33c04c74c813f17@mail.gmail.com> To: Herve Taddei Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 15:40:24 -0000 I should admit you're very good in manipulating facts and words to prove your POV. On Fri, Jul 31, 2009 at 18:06, Herve Taddei wrote: >> Sorry, these codecs does not meet other criteria. They're not bandwidth >> efficient, they do not behave well in the presence of packet loss, etc. > > What is bandwidth efficient and robust enough? Please come up with values I > have not seen them so far. > > For example, from the list of codecs presented yesterday CELT has a bitrate > between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 kbit/s. Are > those the bandwidth efficient codecs? FYI, the codecs I listed have bitrates > between 32 and 64 kbit/s. > >> the use of the Internet programmers, not telco ones. Plus absence of >> really low-delay WB codec. Plus inability to participate for usual people, >> not belonging to big telcos. Oh, isn't there too much exceptions? > > Do you know the delay of G.722? Do you think you will be able to do less? I > would be quite interested (fyi, 2 samples at 16 kHz, I let you compute). In the above statements you refer to different codecs. One (G.722) has a small latency (but high bitrate), other (G.722.1) is low-bandwidth, but high latency. We need more advanced codec, sorry. > Finally, small companies also participate to other SDOs, please give a look > to their member lists. What about individuals? Is is that easy as in IETF? Where are their mailing lists? Audio translations from meetings? How much should I pay to attend? -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From Gerard.Fernando@sun.com Fri Jul 31 09:09:38 2009 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 05AD93A6BDB for ; Fri, 31 Jul 2009 09:09:38 -0700 (PDT) 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=[AWL=-0.001, 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 2sg0NaKlOB1T for ; Fri, 31 Jul 2009 09:09:37 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 946E628C325 for ; Fri, 31 Jul 2009 09:08:59 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNN00E6AM6PQA10@mail-mta.sfvic.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 09:08:49 -0700 (PDT) Received: from [192.168.1.4] ([67.169.183.170]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNN00FK4M6OX561@mail.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 09:08:49 -0700 (PDT) Date: Fri, 31 Jul 2009 09:08:26 -0700 From: Gerard Fernando In-reply-to: <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> To: codec@ietf.org Message-id: <4A7316FA.5010100@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sH2j+l+gtN2t3R+g7Fleag)" References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Cc: Gerard.Fernando@sun.com Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:09:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sH2j+l+gtN2t3R+g7Fleag) Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT RF requirements: Herve Taddei wrote: > > > Sorry, probably you do not follow, but RF requirement was put on the very > > > first slides and repeated several times later. Moreover, several serious > > It is one thing to put them on the slide, it is another thing to get it. > > BTW, you can give a look from IESG BOF report: “- understanding it > would not be possible to guarantee that resulting codecs would be > royalty free” > > > I also feel that having the RF requirement on slides does not ensure such an outcome. If the WG considers this to be important then there should be a well defined methodology which includes the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome. Kind regards Gerard Fernando Sun Labs Sun Microsystems, Inc. 16 Network Circle, UMPK16 Menlo Park, CA 94025 USA --Boundary_(ID_sH2j+l+gtN2t3R+g7Fleag) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 8BIT RF requirements:

Herve Taddei wrote:

> Sorry, probably you do not follow, but RF requirement was put on the very

> first slides and repeated several times later. Moreover, several serious

It is one thing to put them on the slide, it is another thing to get it.

BTW, you can give a look from IESG BOF report: “- understanding it would not be possible to guarantee that resulting codecs would be royalty free”

 


I also feel that having the RF requirement on slides does not ensure such an outcome. If the WG considers this to be important then there should be a well defined methodology which includes the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome.

Kind regards
Gerard Fernando
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA


--Boundary_(ID_sH2j+l+gtN2t3R+g7Fleag)-- From alexander.chemeris@gmail.com Fri Jul 31 09:17:11 2009 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 7A26728C3B4 for ; Fri, 31 Jul 2009 09:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 e7nI8E6OCMMf for ; Fri, 31 Jul 2009 09:17:10 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 5583828C3B8 for ; Fri, 31 Jul 2009 09:16:47 -0700 (PDT) Received: by fxm17 with SMTP id 17so1463809fxm.37 for ; Fri, 31 Jul 2009 09:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=GLtWxMrX/HcX18jgHg1GNADZxaG2P8nSUIjsssC6qBs=; b=lqL5AKwBIBibIg/4jJp54fsKVd/SVWOYQ2podsJa4cfzwZUineJOVruAz+rRcwtalC 8BR+lqF/1ED/H+nBPDhgkPCWbfZmm3YhO82Mh6VjNTHz5Dr/qtza14hym3RUo3aqUgpV wGc0/lC1HKsb/Vfy+/p70DQSGE9hPYIQXzHpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=g+6MTyGBiowqXjb+SE4zeHvVFVol05rL40O0Em8oQQL2+5GZgIeUkZJ6MhH4r3xioB QWJXudJ98nCx3vUz6MPEeG+oNxIfbA2ycjhXfgZ1AA+UosFZppsuxzjP5lzhLUuh6go7 bP5CXjJT3Qo4M78BIBaXAHBq27/y9ddyNu5ek= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.213.10 with SMTP id p10mr1622042muq.30.1249057005184; Fri, 31 Jul 2009 09:16:45 -0700 (PDT) In-Reply-To: <4A7316FA.5010100@sun.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> From: Alexander Chemeris Date: Fri, 31 Jul 2009 20:16:25 +0400 X-Google-Sender-Auth: 5437f62829b03ff5 Message-ID: <3d032e5d0907310916x2978ef48u87e26e6063adc22a@mail.gmail.com> To: Gerard Fernando Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:17:11 -0000 On Fri, Jul 31, 2009 at 20:08, Gerard Fernando wro= te: > Herve Taddei wrote: >>> Sorry, probably you do not follow, but RF requirement was put on the ve= ry >>> first slides and repeated several times later. Moreover, several seriou= s >> >> It is one thing to put them on the slide, it is another thing to get it. >> >> BTW, you can give a look from IESG BOF report: =E2=80=9C- understanding = it would not >> be possible to guarantee that resulting codecs would be royalty free=E2= =80=9D > > I also feel that having the RF requirement on slides does not ensure such= an > outcome. If the WG considers this to be important then there should be a > well defined methodology which includes the development of an IP > (intellectual property) disclosure and review process appropriate to > producing a royalty-free outcome. Right. I just wanted to point that there is such intention. How to achieve it is a question for further evaluation. I clearly see it's not the easiest problem to solve, but it should be possible to solve it. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From stewe@stewe.org Fri Jul 31 09:17:58 2009 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 6F0FB28C385 for ; Fri, 31 Jul 2009 09:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 5OdCM0H3Gark for ; Fri, 31 Jul 2009 09:17:54 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 6221828C388 for ; Fri, 31 Jul 2009 09:17:36 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 367594-1743317 for multiple; Fri, 31 Jul 2009 18:17:36 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 31 Jul 2009 09:17:26 -0700 From: Stephan Wenger To: Gerard Fernando , Message-ID: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoR+mSNUHSGGlM/Aki28AgWNKAPCg== In-Reply-To: <4A7316FA.5010100@sun.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331876656_2407151" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:17:58 -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_3331876656_2407151 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable With the possible exception of certain mandatory-to-implement security technologies, there is no such thing as a Royalty-Free REQUIREMENT in the IETF . Some working groups strive harder to create unencumbered or royalty-free RFC, some don=B9t care overly much, but none has such a requirement. Please stop talking about it. Stephan On 7/31/09 9:08 AM, "Gerard Fernando" wrote: > RF requirements: >=20 > Herve Taddei wrote: >> =20 >> =20 >>=20 >>> > Sorry, probably you do not follow, but RF requirement was put on the = very >> =20 >>> > first slides and repeated several times later. Moreover, several seri= ous >> =20 >> It is one thing to put them on the slide, it is another thing to get it. >> =20 >> BTW, you can give a look from IESG BOF report: =B3- understanding it would= not >> be possible to guarantee that resulting codecs would be royalty free=B2 >> =20 >> =A0 >> =20 >=20 > I also feel that having the RF requirement on slides does not ensure such= an > outcome. If the WG considers this to be important then there should be a = well > defined methodology which includes the development of an IP (intellectual > property) disclosure and review process appropriate to producing a > royalty-free outcome. >=20 > Kind regards > Gerard Fernando > Sun Labs > Sun Microsystems, Inc. > 16 Network Circle, UMPK16 > Menlo Park, CA 94025 > USA >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3331876656_2407151 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec Standardization Expertise With the possible exception of certain mandatory-to-implement security tec= hnologies, there is no such thing as a Royalty-Free REQUIREMENT in the IETF = .  Some working groups strive harder to create unencumbered or royalty-= free RFC, some don’t care overly much, but none has such a requirement= .  Please stop talking about it.
Stephan



On 7/31/09 9:08 AM, "Gerard Fernando" <Gerard.Fernando@sun.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>RF requirements:

Herve Taddei wrote:
<= SPAN STYLE=3D'font-size:11pt'>    
 

> Sorry, probably you do not follow, but RF requirement wa= s put on the very
> first slides and repeated several times later. Moreover,= several serious
It is one thing to put them on the slide, it is another thing= to get it.
BTW, you can give a look from IESG BOF report: “- under= standing it would not be possible to guarantee that resulting codecs would b= e royalty free”
=A0
=
I also feel that having the RF requirement on slides does not ensure such a= n outcome. If the WG considers this to be important then there should be a w= ell defined methodology which includes the development of an IP (intellectua= l property) disclosure and review process appropriate to producing a royalty= -free outcome.

Kind regards
Gerard Fernando
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA




___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3331876656_2407151-- From stephen.botzko@gmail.com Fri Jul 31 09:24:42 2009 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 72E953A684F for ; Fri, 31 Jul 2009 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.442, 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 Mus10Ptf2H3T for ; Fri, 31 Jul 2009 09:24:41 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 77FA13A6A40 for ; Fri, 31 Jul 2009 09:24:12 -0700 (PDT) Received: by bwz19 with SMTP id 19so1289908bwz.37 for ; Fri, 31 Jul 2009 09:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=a96VlI7fGoBqdBulvaGquKHKGYQXlhtmuLprZ2yX9Ww=; b=k74X0V+MdB3XsJUjBuNbiTiRKQ803j866z85nIsEoQwv403yf5Sq0YAdI/UW5UB8IU pWoFbJY+hUyB/nj5EVQ5bq0TlUy7WclyqnIU/5vfsPD1MNUozVFa+VmFXgAVZPE2q7TW pK3IhOmDGAxESnMMFBXaGLP3Ar3lDqKlzSQu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AVf3+qnOXgIeafGZ3O3tcE35KtzVjQhbqwsAE/xiCKqizsXvIgArQX0Su8B4Is+IME 8iFrETMetg5iJDK1PCPzVZZMw0i3+kaTU97T/2UysdrotwEV9/btGXFyiWL7QdgLOELl +CYOGNNM+34z4WKBGU/6Q42Unbq0d17lWhJ6s= MIME-Version: 1.0 Received: by 10.103.243.7 with SMTP id v7mr1626606mur.37.1249057450339; Fri, 31 Jul 2009 09:24:10 -0700 (PDT) In-Reply-To: <4A7316FA.5010100@sun.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> Date: Fri, 31 Jul 2009 12:24:10 -0400 Message-ID: <6e9223710907310924q5a495738reb87c74ad7c43454@mail.gmail.com> From: stephen botzko To: Gerard Fernando Content-Type: multipart/alternative; boundary=001636b4312da1ae22047002d9c2 Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:24:42 -0000 --001636b4312da1ae22047002d9c2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Though I am getting weary on RF discussions, and *very* tired of having every thread turn into an IPR debate, I do have one request. It would be helpful to have clearer picture of the proposed WG process before the next BOF. I can envision some approaches to IPR management that could result in many companies backing out from participation. For example, the process might require us to study other companies' patents in order to design work-arounds. As Stephan Wenger noted a while ago, amon= g other things this can create a risk of triple-damages liability for participants. This could create issues for some. Understanding / gaining rough concensus on the proposed process might make it easier to gauge if this will be a problem or not. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando wrote: > RF requirements: > > Herve Taddei wrote: > > > Sorry, probably you do not follow, but RF requirement was put on the > very > > > first slides and repeated several times later. Moreover, several seriou= s > > It is one thing to put them on the slide, it is another thing to get it. > > BTW, you can give a look from IESG BOF report: =93- understanding it woul= d > not be possible to guarantee that resulting codecs would be royalty free= =94 > > > > > I also feel that having the RF requirement on slides does not ensure such > an outcome. If the WG considers this to be important then there should be= a > well defined methodology which includes the development of an IP > (intellectual property) disclosure and review process appropriate to > producing a royalty-free outcome. > > Kind regards > > Gerard Fernando > > Sun Labs > Sun Microsystems, Inc. > 16 Network Circle, UMPK16 > Menlo Park, CA 94025 > USA > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --001636b4312da1ae22047002d9c2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Though I am getting weary on RF discussions, and very tired of havin= g every thread turn into an IPR debate, I do have one request.

It wo= uld be helpful to have clearer picture of the proposed WG process before th= e next BOF.

I can envision some approaches to IPR management that could result in m= any companies backing out from participation.=A0

For example, the p= rocess might require us to study other companies' patents in order to d= esign work-arounds.=A0 As Stephan Wenger noted a while ago, among other thi= ngs this can create a risk of triple-damages liability for participants.=A0= This could create issues for some.

Understanding / gaining rough concensus on the proposed process might m= ake it easier to gauge if this will be a problem or not.

Regards,Stephen Botzko
Polycom

On Fri, Jul 31= , 2009 at 12:08 PM, Gerard Fernando <Gerard.Fernando@sun.com> wrote:
=20
RF requirements:


Herve Taddei wrote:
=20 =20 =20

> Sorry, probably you do not follow, but RF requirement was put on the very

> first slides and repeated several times later. Moreover, several serious

It is one thing to put them on the slide, it is another thing to get it.

BTW, you can give a look from IESG BOF report: =93- understanding it would not be possible to guarantee that resulting codecs would be royalty free=94

=A0


I also feel that having the RF requirement on slides does not ensure such an outcome. If the WG considers this to be important then there should be a well defined methodology which includes the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome.

Kind regards
Gerard Fernando
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA



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


--001636b4312da1ae22047002d9c2-- From stephen.botzko@gmail.com Fri Jul 31 10:00:55 2009 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 D06B93A6CEE for ; Fri, 31 Jul 2009 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.425, 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 FO0XREcYhP7J for ; Fri, 31 Jul 2009 10:00:54 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 443C93A6B7D for ; Fri, 31 Jul 2009 10:00:54 -0700 (PDT) Received: by fxm17 with SMTP id 17so1485961fxm.37 for ; Fri, 31 Jul 2009 10:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oT4Ba/g15bAYSKHgjwqlurhI0sQ1DO4t+O8pWxQLBiA=; b=LioO/4zV9s/kjdyQVasiWTjcjI0ggg/tJ8fX7eMZ/9NJlbad6Neea7B4gpYKpquaNG 2VlnPwcyHjvJYPA78fnIU2b4OGwo4n0TOUgkBYQYKU8cnQ3SvRDx6jVcJAnm9hf/oI94 r1Nhb6elVpvbatpiJe1PqNEZtvwJv/p0R3wX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qzgppARra3vA4D7VCpsZlyLamogsPGuPOShLh5UDx+x4E4j1Uxe8Vi5sud0jUojFvf QntIQxondzjPtK01c1fUaHoTq3aFNWqC9HK5F+i5HlvADIY5KeizGAWiawQ3CM2hEEBC tQyG/Ue2UAx21VIOkxJVTs4irM0FI1ZEZLGAo= MIME-Version: 1.0 Received: by 10.102.228.10 with SMTP id a10mr222300muh.81.1249059653294; Fri, 31 Jul 2009 10:00:53 -0700 (PDT) In-Reply-To: <3d032e5d0907310840j54276e19xc33c04c74c813f17@mail.gmail.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <3d032e5d0907310840j54276e19xc33c04c74c813f17@mail.gmail.com> Date: Fri, 31 Jul 2009 13:00:53 -0400 Message-ID: <6e9223710907311000x4c2f4477s56de1eac7ea256f7@mail.gmail.com> From: stephen botzko To: Alexander Chemeris Content-Type: multipart/alternative; boundary=0016363ba6acf0191a0470035c57 Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:00:55 -0000 --0016363ba6acf0191a0470035c57 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> In the above statements you refer to different codecs. One (G.722) has a small latency (but high bitrate), other (G.722.1) is low-bandwidth, but high latency. We need more advanced codec, >>> Though obviously latency is an important requirement for a codec application, higher latencies do not necessarily mean that the codec is less advanced. I would classify G.722.1 as a moderate latency codec (40 ms). It is particularly suited to videoconferencing, where the video latency usually is greater than 40 ms. Also, It is low complexity (< 5.5 WMOPS for encoder+decoder).. Annex C doubles the complexity, but also provides superwideband audio (32 kHz sampling) Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 11:40 AM, Alexander Chemeris < Alexander.Chemeris@sipez.com> wrote: > I should admit you're very good in manipulating facts and words > to prove your POV. > > On Fri, Jul 31, 2009 at 18:06, Herve Taddei > wrote: > >> Sorry, these codecs does not meet other criteria. They're not bandwidth > >> efficient, they do not behave well in the presence of packet loss, etc. > > > > What is bandwidth efficient and robust enough? Please come up with values > I > > have not seen them so far. > > > > For example, from the list of codecs presented yesterday CELT has a > bitrate > > between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 kbit/s. > Are > > those the bandwidth efficient codecs? FYI, the codecs I listed have > bitrates > > between 32 and 64 kbit/s. > > > >> the use of the Internet programmers, not telco ones. Plus absence of > >> really low-delay WB codec. Plus inability to participate for usual > people, > >> not belonging to big telcos. Oh, isn't there too much exceptions? > > > > Do you know the delay of G.722? Do you think you will be able to do less? > I > > would be quite interested (fyi, 2 samples at 16 kHz, I let you compute). > > In the above statements you refer to different codecs. > One (G.722) has a small latency (but high bitrate), other (G.722.1) is > low-bandwidth, > but high latency. We need more advanced codec, sorry. > > > Finally, small companies also participate to other SDOs, please give a > look > > to their member lists. > > What about individuals? Is is that easy as in IETF? > Where are their mailing lists? Audio translations from meetings? > How much should I pay to attend? > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016363ba6acf0191a0470035c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
In the above statements you refer to different codecs.
One (G.722) has a small latency (but high bitrate), other (G.722.1) is
low-bandwidth, but high latency. We need more advanced codec,
>>&g= t;

Though obviously latency is an important requirement for a codec = application, higher latencies do not necessarily mean that the codec is les= s advanced.

I would classify G.722.1 as a moderate latency codec (40 ms).=A0 It is = particularly suited to videoconferencing, where the video latency usually i= s greater than 40 ms. Also, It is low complexity (< 5.5 WMOPS for encode= r+decoder)..=A0 Annex C doubles the complexity, but also provides superwide= band audio (32 kHz sampling)

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 11:40 AM, Alexander Chemeris <= ;Alexander.Chemeris@sipez.c= om> wrote:
I should admit yo= u're very good in manipulating facts and words
to prove your POV.

On Fri, Jul 31, 2009 at 18:06, Herve Taddei<herve.taddei@huawei.com> wrote:
>> Sorry, these codecs does not meet other criteria. They're not = bandwidth
>> efficient, they do not behave well in the presence of packet loss,= etc.
>
> What is bandwidth efficient and robust enough? Please come up with val= ues I
> have not seen them so far.
>
> For example, from the list of codecs presented yesterday CELT has a bi= trate
> between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 kbit/s.= Are
> those the bandwidth efficient codecs? FYI, the codecs I listed have bi= trates
> between 32 and 64 kbit/s.
>
>> the use of the Internet programmers, not t= elco ones. Plus absence of
>> really low-delay WB codec. Plus inability to participate for usual= people,
>> not belonging to big telcos. Oh, isn't there too much exceptio= ns?
>
> Do you know the delay of G.722? Do you think you will be able to do le= ss? I
> would be quite interested (fyi, 2 samples at 16 kHz, I let you compute= ).

In the above statements you refer to different codecs.
One (G.722) has a small latency (but high bitrate), other (G.722.1) is
low-bandwidth,
but high latency. We need more advanced codec, sorry.

> Finally, small companies also participate to other SDOs, please give a= look
> to their member lists.

What about individuals? Is is that easy as in IETF?
Where are their mailing lists? Audio translations from meetings?
How much should I pay to attend?

--
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com=
tel: +1 (617) 273-4000
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016363ba6acf0191a0470035c57-- From tme@americafree.tv Fri Jul 31 10:06:55 2009 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 649893A6F42 for ; Fri, 31 Jul 2009 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 qmSnxDa2kxf4 for ; Fri, 31 Jul 2009 10:06:54 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 1F7273A6D92 for ; Fri, 31 Jul 2009 10:06:54 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 780CC45EA6FB; Fri, 31 Jul 2009 13:06:55 -0400 (EDT) Message-Id: <2AA28C2D-9912-4066-BE68-C35E5DFBEB78@americafree.tv> From: Marshall Eubanks To: Alexander Chemeris In-Reply-To: <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 13:06:54 -0400 References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Ingemar Johansson S , codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:06:55 -0000 On Jul 31, 2009, at 8:41 AM, Alexander Chemeris wrote: > Hi, > > On Fri, Jul 31, 2009 at 15:43, Herve Taddei =20= > wrote: >>> PPS Royalty-free requirement is not "just a some small addition to >>> other's SDO requirements". It's a vital part. Other SDOs were =20 >>> failing >>> to produce royalty-free codecs till now. Why should we rely on =20 >>> them for >>> the future? >> >> I don=92t think there is any insurance that the IETF work will =20 >> provide a RF >> codec. What is the benefit of this work if you don=92t get RF codecs? = =20 >> So far, >> it really seems to be the only argument to start this work. > > Sorry, probably you do not follow, but RF requirement was put on the =20= > very > first slides and repeated several times later. Moreover, several =20 > serious > companies offers to open their codecs as RF ones - you should have =20 > missed > this too. After all, there is CELT, being built as RF from the =20 > ground up. There > is a lot of willing for RF codec(s). In the absence of a requirements draft that has gone through the =20 consensus process, slides on a viewgraph presentation are suggestions, =20= nothing more. I wish that people would stop claiming consensus on this point when it has not been called and seems clearly not to have =20 developed. Regards Marshall > > >> And there is something some people seem to always forget/ignore is =20= >> that >> there are already some standards that are RF codecs: G.722, G.722.1, >> G.722.1C, G.711 and certainly some others. Some people say they =20 >> don=92t fit >> their needs, but when I read the current draft charter it does not =20= >> seem to >> be true as these codecs perfectly fit it. The fact that these =20 >> codecs have RF >> conditions because either it was a company choice to offer them for =20= >> free or >> because their patents ran out is irrelevant to the discussion. The =20= >> fact is >> there are already RF codecs. > > Sorry, these codecs does not meet other criteria. They're not =20 > bandwidth > efficient, they do not behave well in the presence of packet loss, =20 > etc. > >> Then we can read that you need an Internet dedicated codec, but so =20= >> far in >> the charter there is nothing special that could make me thinking, =20 >> yes this >> is an Internet codec. > > Please, read all requirements again. Think of them together, not about > each one separately. > >> To your last point, why should you rely on other SDOs: >> - because usually it is where main telcos, vendors and experts are, >> - because their codec evaluation/characterization is well defined, >> - because their codec applications/requirements are well organized =20= >> and codec >> standardization is started based on these definitions. > > Sounds good, with the only exception, I mentioned above - absence of > RF codec they standardized. Plus lack of modern codecs, suitable for > the use of the Internet programmers, not telco ones. Plus absence of > really low-delay WB codec. Plus inability to participate for usual =20 > people, > not belonging to big telcos. Oh, isn't there too much exceptions? > > And yet I don't see reasons I should not rely on IETF. > > --=20 > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Gerard.Fernando@sun.com Fri Jul 31 10:40:09 2009 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 D683D28C2BD for ; Fri, 31 Jul 2009 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 jwi7mgvkQGr3 for ; Fri, 31 Jul 2009 10:40:07 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 399A428C356 for ; Fri, 31 Jul 2009 10:39:20 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNN00ECDQDKQA10@mail-mta.sfvic.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 10:39:20 -0700 (PDT) Received: from [192.168.1.4] ([67.169.183.170]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNN00FSRQDKXCL1@mail.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 10:39:20 -0700 (PDT) Date: Fri, 31 Jul 2009 10:38:57 -0700 From: Gerard Fernando In-reply-to: <6e9223710907310924q5a495738reb87c74ad7c43454@mail.gmail.com> To: codec@ietf.org Message-id: <4A732C31.6010202@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_el7m2+Vu1OyTHEFSk7wJIA)" References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> <6e9223710907310924q5a495738reb87c74ad7c43454@mail.gmail.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Cc: stephen botzko Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:40:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_el7m2+Vu1OyTHEFSk7wJIA) Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT Although I appreciate that many folks might be getting "weary" of RF discussion it is this very issue that will determine the value of any standard developed by this WG. I'm still firmly of the opinion that the _only_ reason for the IETF to embark on codec standardization is if such standards were to be RF. If the WG were to develop a process, as described below, for IPR management then that'll certainly help. Kind regards Sun Labs Sun Microsystems, Inc. 16 Network Circle, UMPK16 Menlo Park, CA 94025 USA stephen botzko wrote: > Though I am getting weary on RF discussions, and _very_ tired of > having every thread turn into an IPR debate, I do have one request. > > It would be helpful to have clearer picture of the proposed WG process > before the next BOF. > > I can envision some approaches to IPR management that could result in > many companies backing out from participation. > > For example, the process might require us to study other companies' > patents in order to design work-arounds. As Stephan Wenger noted a > while ago, among other things this can create a risk of triple-damages > liability for participants. This could create issues for some. > > Understanding / gaining rough concensus on the proposed process might > make it easier to gauge if this will be a problem or not. > > Regards, > Stephen Botzko > Polycom > > On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando > > wrote: > > RF requirements: > > > Herve Taddei wrote: >> >> > Sorry, probably you do not follow, but RF requirement was put on >> the very >> >> > first slides and repeated several times later. Moreover, several >> serious >> >> It is one thing to put them on the slide, it is another thing to >> get it. >> >> BTW, you can give a look from IESG BOF report: “- understanding >> it would not be possible to guarantee that resulting codecs would >> be royalty free” >> >> >> > > I also feel that having the RF requirement on slides does not > ensure such an outcome. If the WG considers this to be important > then there should be a well defined methodology which includes the > development of an IP (intellectual property) disclosure and review > process appropriate to producing a royalty-free outcome. > > Kind regards > > Gerard Fernando > > Sun Labs > Sun Microsystems, Inc. > 16 Network Circle, UMPK16 > Menlo Park, CA 94025 > USA > > > > > > > _______________________________________________ > 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 > --Boundary_(ID_el7m2+Vu1OyTHEFSk7wJIA) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 8BIT Although I appreciate that many folks might be getting "weary" of RF discussion it is this very issue that will determine the value of any standard developed by this WG. I'm still firmly of the opinion that the only reason for the IETF to embark on codec standardization is if such standards were to be RF.

If the WG were to develop a process, as described below, for IPR management  then  that'll certainly help.

Kind regards
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA
stephen botzko wrote:
Though I am getting weary on RF discussions, and very tired of having every thread turn into an IPR debate, I do have one request.

It would be helpful to have clearer picture of the proposed WG process before the next BOF.

I can envision some approaches to IPR management that could result in many companies backing out from participation. 

For example, the process might require us to study other companies' patents in order to design work-arounds.  As Stephan Wenger noted a while ago, among other things this can create a risk of triple-damages liability for participants.  This could create issues for some.

Understanding / gaining rough concensus on the proposed process might make it easier to gauge if this will be a problem or not.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando <Gerard.Fernando@sun.com> wrote:
RF requirements:


Herve Taddei wrote:

> Sorry, probably you do not follow, but RF requirement was put on the very

> first slides and repeated several times later. Moreover, several serious

It is one thing to put them on the slide, it is another thing to get it.

BTW, you can give a look from IESG BOF report: “- understanding it would not be possible to guarantee that resulting codecs would be royalty free”

 


I also feel that having the RF requirement on slides does not ensure such an outcome. If the WG considers this to be important then there should be a well defined methodology which includes the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome.

Kind regards
Gerard Fernando
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA



_______________________________________________
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

--Boundary_(ID_el7m2+Vu1OyTHEFSk7wJIA)-- From stefan.sayer@iptego.com Fri Jul 31 11:43:08 2009 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 27C4628C29F for ; Fri, 31 Jul 2009 11:43:08 -0700 (PDT) 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=[AWL=0.000, 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 Xge+48OEDChm for ; Fri, 31 Jul 2009 11:43:07 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 60F593A65A5 for ; Fri, 31 Jul 2009 11:43:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 1B1771154090; Fri, 31 Jul 2009 20:43:04 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLbCV5kLjSm2; Fri, 31 Jul 2009 20:43:03 +0200 (CEST) Received: from [192.168.5.106] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id CCE93115408E; Fri, 31 Jul 2009 20:43:03 +0200 (CEST) Message-ID: <4A733B37.3000604@iptego.com> Date: Fri, 31 Jul 2009 20:43:03 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Herve Taddei References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> In-Reply-To: <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 18:43:08 -0000 o Herve Taddei [07/31/09 16:06] in reply to Alexander Chemeris: >> Sorry, these codecs does not meet other criteria. They're not bandwidth > >> efficient, they do not behave well in the presence of packet loss, etc. > > What is bandwidth efficient and robust enough? Please come up with > values I have not seen them so far. > > For example, from the list of codecs presented yesterday CELT has a > bitrate between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 > kbit/s. Are those the bandwidth efficient codecs? FYI, the codecs I > listed have bitrates between 32 and 64 kbit/s. CELT has good quality at 32kbit/s and I would say that for speech even at around 20 kbit/s it performs quite well (all at 32 kHz). BR Stefan From stefan.sayer@iptego.com Fri Jul 31 12:07:28 2009 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 326B328C167 for ; Fri, 31 Jul 2009 12:07:28 -0700 (PDT) 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 PxN876xDOEIf for ; Fri, 31 Jul 2009 12:07:27 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 5B6273A6AC8 for ; Fri, 31 Jul 2009 12:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id B83681154090; Fri, 31 Jul 2009 21:07:28 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl0CMfFb0BVr; Fri, 31 Jul 2009 21:07:28 +0200 (CEST) Received: from [192.168.5.106] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id 72908115408E; Fri, 31 Jul 2009 21:07:28 +0200 (CEST) Message-ID: <4A7340F0.30005@iptego.com> Date: Fri, 31 Jul 2009 21:07:28 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: stephen botzko References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> In-Reply-To: <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:07:28 -0000 Hello, o stephen botzko [07/30/09 23:02]: > itself. G.719's packetization RFC allows for interleaved and overlapped > (redundant) audio frames, and permits the duplicate frames to be at > lower rates. That allows for good quality to be maintained under packet > loss conditions (though if the network is congested, of course you need How much additional packet loss resilience would be possible to achieve from a true multiple description mode for the codec and interleaved packetization, where reconstruction of a lower quality signal would be possible in the presence of one description, or some out of a few descriptions? For this to work, not only the RTP packetization has to support it so that the receiver understands what it is that was received, but the codec itself must support this mode. (I would assume that for efficiency reasons, this needs to be an alternate coding mode, which the sender could switch to if it detects, e.g. with the help of RTCP, excessive loss.) I see that in the IP-MR RTP format it is possible to reconstruct from the base layer, which may be sent redundantly. How much better could this work if reconstruction from any combination of layers would be possible? Thanks Stefan Sayer From stephen.botzko@gmail.com Fri Jul 31 12:25:15 2009 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 E38983A6C29 for ; Fri, 31 Jul 2009 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.410, 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 EL0G62dbvR8Q for ; Fri, 31 Jul 2009 12:25:15 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 9BCA23A698F for ; Fri, 31 Jul 2009 12:25:14 -0700 (PDT) Received: by fxm17 with SMTP id 17so1551887fxm.37 for ; Fri, 31 Jul 2009 12:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ey67ZwDzPsa5wknOUR1BcF3PCNXZFY9tiWm1TYoIBD8=; b=F9K/1uuSgh7+D5A7m+exqNut5MkelGnn9PCad7gEYEXL+eQD9oEMwmUQc4I2+qq0nq pGhA7TcquOq+OXK3lQosQThyOHA9GfzFsa4DqFoAvxGJ+bqg11ORJQQ6b9HZtFRn52xi 19ylT5uUdACwH0HVAHBvom2GHlCjY34Woaenk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oqTJRKSMUuP3HEFNa+8eQHJvY3m6FOO4e7Kcx4AT/NGKrNU2CPL+lM2xiZzEww3tsn qf5XMje4CN5ZiElv7pl/1Sxsn0Dd4DvhzZrZDwCSDOsSFadGRrBsdB9AIvfR56Ee5J2/ t4gzYuA/y+9eLIG2E32LG5GrQhqrEQicQvsNE= MIME-Version: 1.0 Received: by 10.103.243.7 with SMTP id v7mr1727093mur.37.1249068313339; Fri, 31 Jul 2009 12:25:13 -0700 (PDT) In-Reply-To: <4A7340F0.30005@iptego.com> References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <4A7340F0.30005@iptego.com> Date: Fri, 31 Jul 2009 15:25:13 -0400 Message-ID: <6e9223710907311225n77aafaddld2e70373771444ec@mail.gmail.com> From: stephen botzko To: Stefan Sayer Content-Type: multipart/alternative; boundary=001636b4312d1de85e04700561f8 Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:25:16 -0000 --001636b4312d1de85e04700561f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All G.719 RTP receivers are required to receive the overlap mode. The codec itself doesn't really have to "understand it", all you have to do is build a non-overlapped series of frames as you de jitter (and the overlapped frames as you packetize). If you are running at two different rates, you can run two encoder instances (or jointly optimize one instance to produce two bitstreams). I'm not an expert on the SPIRIT IP-MR codec. Regards, Stephen Botzko Polycom On Fri, Jul 31, 2009 at 3:07 PM, Stefan Sayer wrote: > Hello, > > o stephen botzko [07/30/09 23:02]: > >> itself. G.719's packetization RFC allows for interleaved and overlapped >> (redundant) audio frames, and permits the duplicate frames to be at lower >> rates. That allows for good quality to be maintained under packet loss >> conditions (though if the network is congested, of course you need >> > How much additional packet loss resilience would be possible to achieve > from a true multiple description mode for the codec and interleaved > packetization, where reconstruction of a lower quality signal would be > possible in the presence of one description, or some out of a few > descriptions? > > For this to work, not only the RTP packetization has to support it so that > the receiver understands what it is that was received, but the codec itself > must support this mode. (I would assume that for efficiency reasons, this > needs to be an alternate coding mode, which the sender could switch to if it > detects, e.g. with the help of RTCP, excessive loss.) > > I see that in the IP-MR RTP format it is possible to reconstruct from the > base layer, which may be sent redundantly. How much better could this work > if reconstruction from any combination of layers would be possible? > > Thanks > Stefan Sayer > > --001636b4312d1de85e04700561f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All G.719 RTP receivers are required to receive the overlap mode.=A0 The co= dec itself doesn't really have to "understand it", all you ha= ve to do is build a non-overlapped series of frames as you de jitter (and t= he overlapped frames as you packetize).=A0 If you are running at two differ= ent rates, you can run two encoder instances (or jointly optimize one insta= nce to produce two bitstreams).

I'm not an expert on the SPIRIT IP-MR codec.

Regards,
Ste= phen Botzko
Polycom

On Fri, Jul 31, 20= 09 at 3:07 PM, Stefan Sayer <stefan.sayer@iptego.com> wrote:
Hello,

o stephen botzko [07/30/09 23:02]:

itself. =A0G.719's packetization RFC allows for interleaved and overlap= ped (redundant) audio frames, and permits the duplicate frames to be at low= er rates. =A0That allows for good quality to be maintained under packet los= s conditions (though if the network is congested, of course you need
How much additional packet loss resilience would be possible to achieve fro= m a true multiple description mode for the codec and interleaved packetizat= ion, where reconstruction of a lower quality signal would be possible in th= e presence of one description, or some out of a few descriptions?

For this to work, not only the RTP packetization has to support it so that = the receiver understands what it is that was received, but the codec itself= must support this mode. (I would assume that for efficiency reasons, this = needs to be an alternate coding mode, which the sender could switch to if i= t detects, e.g. with the help of RTCP, excessive loss.)

I see that in the IP-MR RTP format it is possible to reconstruct from the b= ase layer, which may be sent redundantly. How much better could this work i= f reconstruction from any combination of layers would be possible?

Thanks
Stefan Sayer


--001636b4312d1de85e04700561f8-- From stefan.sayer@iptego.com Fri Jul 31 12:26:22 2009 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 3A6623A6D56 for ; Fri, 31 Jul 2009 12:26:22 -0700 (PDT) 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=[AWL=0.000, 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 Kct7Zu-DqIOl for ; Fri, 31 Jul 2009 12:26:21 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 4AB803A6D0C for ; Fri, 31 Jul 2009 12:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 7288F1154090 for ; Fri, 31 Jul 2009 21:26:18 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxXye5vboNpa for ; Fri, 31 Jul 2009 21:26:18 +0200 (CEST) Received: from [192.168.5.106] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id 3C9F0115408E for ; Fri, 31 Jul 2009 21:26:18 +0200 (CEST) Message-ID: <4A734559.3020301@iptego.com> Date: Fri, 31 Jul 2009 21:26:17 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: codec@ietf.org References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com><4A71FF50.5020007@joelhalpern.com><6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <6e9223710907310324v2380cf48gbd5d4b0cbfb6889d@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:26:22 -0000 o Michael Ramalho (mramalho) [07/31/09 16:20]: > If you VoIP flow constitutes a MINORITY FLOW in a general elastic flow > (i.e., more TCP or SCTP than UDP) at your bottleneck link … then > changing your VoIP rate will have minimal impact on the congestion at > the bottleneck link … as that congestion is primarily a function of the > elastic traffic. This relates to Comment 1 above. what could have an impact in this situation is to reduce packet length by increasing packet rate (even if relatively more bandwidth is spent on header overhead). This leads to a requirement for short or controllable frame length ("frame size adoption knobs"). Stefan From Gerard.Fernando@sun.com Fri Jul 31 12:34:46 2009 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 67FE33A6C29 for ; Fri, 31 Jul 2009 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.948, 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 IhqJmYShfkLA for ; Fri, 31 Jul 2009 12:34:40 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id AB3253A68D9 for ; Fri, 31 Jul 2009 12:34:25 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNN00EKYVPFQA10@mail-mta.sfvic.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 12:34:27 -0700 (PDT) Received: from [129.150.36.69] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNN00FMBVPEX561@mail.sunlabs.com> for codec@ietf.org; Fri, 31 Jul 2009 12:34:27 -0700 (PDT) Date: Fri, 31 Jul 2009 12:34:03 -0700 From: Gerard Fernando To: codec@ietf.org Message-id: <4A73472B.4060700@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FuOAwQwHES6FNbaCODLdBw)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Cc: stephen botzko Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:34:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FuOAwQwHES6FNbaCODLdBw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I understand that the process discussion would need to cover many aspects - not only IPR. But, the process discussion must address technical and business requirements, and from my perspective, IPR issues (more specifically developing a methodology for achieving a RF codec) should be high in the list of such business requirements. Kind regards Sun Labs Sun Microsystems, Inc. 16 Network Circle, UMPK16 Menlo Park, CA 94025 USA stephen botzko wrote: > >>> > Although I appreciate that many folks might be getting "weary" of RF > discussion it is this very issue that will determine the value of any > standard developed by this WG. I'm still firmly of the opinion that > *the _only_* *reason for the IETF to embark on codec standardization > is if such standards were to be RF*. > >>> > > I get why you care, its just that the discussion goes nowhere. > Perhaps "the only reason..." would make an interesting agree / > disagree "hum" question at the next BOF. > > Just to clarify - I was not thinking that the process discussion would > center on IPR. > > Getting consensus on the overall process in more detail needs to be > achieved at some point anyway, and would also allow companies > privately to assess their own participation. > > Knowing if the process is collaborative development or competitive > selection might also be a factor for some. Others might want to hold > back source code until a first-cut assessment is made as to whether > the proposal is under serious consideration. > > Stephen Botzko > Polycom > > > On Fri, Jul 31, 2009 at 1:38 PM, Gerard Fernando > > wrote: > > Although I appreciate that many folks might be getting "weary" of > RF discussion it is this very issue that will determine the value > of any standard developed by this WG. I'm still firmly of the > opinion that the _only_ reason for the IETF to embark on codec > standardization is if such standards were to be RF. > > If the WG were to develop a process, as described below, for IPR > management then that'll certainly help. > > Kind regards > > Sun Labs > Sun Microsystems, Inc. > 16 Network Circle, UMPK16 > Menlo Park, CA 94025 > USA > > > > stephen botzko wrote: >> Though I am getting weary on RF discussions, and _very_ tired of >> having every thread turn into an IPR debate, I do have one request. >> >> It would be helpful to have clearer picture of the proposed WG >> process before the next BOF. >> >> I can envision some approaches to IPR management that could >> result in many companies backing out from participation. >> >> For example, the process might require us to study other >> companies' patents in order to design work-arounds. As Stephan >> Wenger noted a while ago, among other things this can create a >> risk of triple-damages liability for participants. This could >> create issues for some. >> >> Understanding / gaining rough concensus on the proposed process >> might make it easier to gauge if this will be a problem or not. >> >> Regards, >> Stephen Botzko >> Polycom >> >> On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando >> > wrote: >> >> RF requirements: >> >> >> Herve Taddei wrote: >>> >>> > Sorry, probably you do not follow, but RF requirement was >>> put on the very >>> >>> > first slides and repeated several times later. Moreover, >>> several serious >>> >>> It is one thing to put them on the slide, it is another >>> thing to get it. >>> >>> BTW, you can give a look from IESG BOF report: "- >>> understanding it would not be possible to guarantee that >>> resulting codecs would be royalty free" >>> >>> >>> >> >> I also feel that having the RF requirement on slides does not >> ensure such an outcome. If the WG considers this to be >> important then there should be a well defined methodology >> which includes the development of an IP (intellectual >> property) disclosure and review process appropriate to >> producing a royalty-free outcome. >> >> Kind regards >> >> Gerard Fernando >> >> Sun Labs >> Sun Microsystems, Inc. >> 16 Network Circle, UMPK16 >> Menlo Park, CA 94025 >> USA >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --Boundary_(ID_FuOAwQwHES6FNbaCODLdBw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
I understand that the process discussion would need to cover many aspects - not only IPR. But, the process discussion must address technical and business requirements, and from my perspective, IPR issues (more specifically developing a methodology for achieving a RF codec) should be high in the list of such business requirements.

Kind regards

Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA


stephen botzko wrote:
>>>
Although I appreciate that many folks might be getting "weary" of RF discussion it is this very issue that will determine the value of any standard developed by this WG. I'm still firmly of the opinion that the only reason for the IETF to embark on codec standardization is if such standards were to be RF.
>>>

I get why you care, its just that the discussion goes nowhere.  Perhaps "the only reason..." would make an interesting agree / disagree "hum" question at the next BOF.

Just to clarify - I was not thinking that the process discussion would center on IPR. 

Getting consensus on the overall process in more detail needs to be achieved at some point anyway, and would also allow companies privately to assess their own participation.

Knowing if the process is collaborative development or competitive selection might also be a factor for some.  Others might want to hold back source code until a first-cut assessment is made as to whether the proposal is under serious consideration.

Stephen Botzko
Polycom


On Fri, Jul 31, 2009 at 1:38 PM, Gerard Fernando <Gerard.Fernando@sun.com> wrote:
Although I appreciate that many folks might be getting "weary" of RF discussion it is this very issue that will determine the value of any standard developed by this WG. I'm still firmly of the opinion that the only reason for the IETF to embark on codec standardization is if such standards were to be RF.

If the WG were to develop a process, as described below, for IPR management  then  that'll certainly help.

Kind regards 

Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA
stephen botzko wrote:
Though I am getting weary on RF discussions, and very tired of having every thread turn into an IPR debate, I do have one request.

It would be helpful to have clearer picture of the proposed WG process before the next BOF.

I can envision some approaches to IPR management that could result in many companies backing out from participation. 

For example, the process might require us to study other companies' patents in order to design work-arounds.  As Stephan Wenger noted a while ago, among other things this can create a risk of triple-damages liability for participants.  This could create issues for some.

Understanding / gaining rough concensus on the proposed process might make it easier to gauge if this will be a problem or not.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando <Gerard.Fernando@sun.com> wrote:
RF requirements:


Herve Taddei wrote:

> Sorry, probably you do not follow, but RF requirement was put on the very

> first slides and repeated several times later. Moreover, several serious

It is one thing to put them on the slide, it is another thing to get it.

BTW, you can give a look from IESG BOF report: “- understanding it would not be possible to guarantee that resulting codecs would be royalty free”

 


I also feel that having the RF requirement on slides does not ensure such an outcome. If the WG considers this to be important then there should be a well defined methodology which includes the development of an IP (intellectual property) disclosure and review process appropriate to producing a royalty-free outcome.

Kind regards
Gerard Fernando
Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA



_______________________________________________
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



--Boundary_(ID_FuOAwQwHES6FNbaCODLdBw)-- From jean-marc.valin@usherbrooke.ca Fri Jul 31 12:51:36 2009 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 914983A6905 for ; Fri, 31 Jul 2009 12:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 67ayiAD9cz2X for ; Fri, 31 Jul 2009 12:51:36 -0700 (PDT) Received: from customer-relay.songnetworks.se (customer-relay.songnetworks.se [195.42.210.9]) by core3.amsl.com (Postfix) with ESMTP id C72173A68A5 for ; Fri, 31 Jul 2009 12:51:35 -0700 (PDT) Received: from idefix.homelinux.org (95.78.227.87.static.s-cy.siw.siwnet.net [87.227.78.95]) by customer-relay.songnetworks.se (Postfix) with ESMTP id EEF992416C for ; Fri, 31 Jul 2009 21:51:36 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTP id BEC16509840; Fri, 31 Jul 2009 21:51:36 +0200 (CEST) Message-ID: <4A734B48.2010101@usherbrooke.ca> Date: Fri, 31 Jul 2009 21:51:36 +0200 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: stephen botzko References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> <6e9223710907310924q5a495738reb87c74ad7c43454@mail.gmail.com> In-Reply-To: <6e9223710907310924q5a495738reb87c74ad7c43454@mail.gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org, Gerard Fernando Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:51:36 -0000 stephen botzko a écrit : > For example, the process might require us to study other companies' > patents in order to design work-arounds. As Stephan Wenger noted a > while ago, among other things this can create a risk of triple-damages > liability for participants. This could create issues for some. Actually, I would be curious to know how the ITU-T (and other SDOs) deals with that issue. Do companies submitting codecs to the ITU-T completely avoid searching for patents or do they accept the triple-damages liability? Jean-Marc From stewe@stewe.org Fri Jul 31 14:09:39 2009 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 320683A6977 for ; Fri, 31 Jul 2009 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 ZuzhRXUr2EH3 for ; Fri, 31 Jul 2009 14:09:38 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 73AA03A6AE7 for ; Fri, 31 Jul 2009 14:08:44 -0700 (PDT) Received: from [192.168.1.105] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 367911-1743317 for multiple; Fri, 31 Jul 2009 23:08:40 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 31 Jul 2009 14:08:29 -0700 From: Stephan Wenger To: Jean-Marc Valin , stephen botzko Message-ID: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoSIw1Q55ugjHIAIUyzF1bAMGSw8Q== In-Reply-To: <4A734B48.2010101@usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: Gerard Fernando , codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 21:09:39 -0000 Hi Jean-Marc, To directly answer it, in all RAND SDOs (and in the IETF), the technical WG= s rarely, if ever, discuss patent rights. That does not mean that back at home the very same people wouldn't check on patent rights---typically under supervision of a patent lawyer and under attorney-client privileges. This analysis may include both technical aspects---possible encumbrances--- as well as business aspects (such as "friendliness" of the possible rightholder, pre-existing licensing deals, and so on). Back in the meeting room, folks find more or less substantial technical arguments to derail contributions they don't like. I would argue that the same dynamics apply to the IETF as well; the differences between IETF and, say, the ITU in this field are rather subtle. Below please find a summary of the policy aspects relevant to your question= . I apologize for the word-count. The IETF and all other SDOs relevant in this discussion AFAIK (that are: ITU, 3GPP and its organizational partners such as ETSI, 3GPP2 and its organizational parts such as TIA, and ISO/IEC) have in common a requirement to disclose patent rights that are, or may become, essential to practice a standard. There are subtle differences how these requirements are formulated, and how they are exercised in practice. For example, in some organizations it is deemed sufficient if one were declaring one's possible essential patent claims without further information of the patent itself. There are also differences in the disclosure timing requirements---which ar= e arguably ill-defined in all mentioned organizations. Most organizations maintain a database of the declarations received, and most of them state explicitly that not submitting declarations constitutes a process violation= . In addition, all of the mentioned organization *except the IETF* do require all their members to license patent rights necessary to practice any of their standards under RAND terms. This serves as the main safety net for possible righttakers. In response to this safety net, arguably, the disclosure practice at least in some groups of the non-IETF SDOs mentioned above is somewhat more relaxed than what one could read out of a strict interpretation of the policy. In all above mentioned SDOs, when submitting a patent declaration, you have the option (and commonly, you are required) to state, in broad terms, your licensing policy. In most organizations, you have the choice between stating something like "royalty-free", "RAND", or "unwilling to license". In the IETF, you have many more choices, including the choice of free-form. The interpretation of a free-form licensing commitment will usually require some experience on the legalese. Some organizations also allow you to provide "ex ante" information of your royalty rates. Of course, those are never discussed in meetings, for antitrust reasons. The IETF does not have any form of requirement for licensing terms---not a minimum RAND requirement, and certainly not a minimum RF requirement. Ther= e are good reasons for this situation, the most commonly cited one being that the IETF does not have a membership model which could be used to bind in (corporate) members into an obligation. There have been cases where the IETF standardized I-Ds knowing that patent rights may not be available unde= r RAND terms. =20 Of the mentioned organizations, most (if not all---too lazy to double-check all those policies) prefer unencumbered over encumbered solutions by policy= . Some, for example the ITU, do prefer encumbered, but royalty-free solutions over royalty-bearing ones. All give a working group the liberty to include royalty-bearing technologies into their standards. If you look for an SDO organizational model that supports an RF standardization process, you would have to look at W3C, OASIS, and similar organizations. The have been able to maintain an RF ecosystem in their field through a number of mechanisms, that include a very strict membership model, a well-defined chartering process, and a conflict resolution model for the case of discovered patent claims not available under RF terms. Their policy is not transferable to the IETF. Finally, some of the community-driven micro-SDOs (many of which coming from the open source environment) have managed to keep their standards free of known royalty-bearing IPR, by agreeing to appropriate terms after the standard has been set, but before it was published. There is an effort ongoing in the Open Web Foundation to "standardize" a policy template for those cicro-SDOs. =20 The micro-SDO approach works well for a small group of people/companies wit= h identical goals, and sufficient community pressure to reign in those tempte= d to make a quick buck---and, if you are prepared to throw away man-years of work if your RF goal turns out to be unachievable. However, it would not work well with such diverse business interests as we appear to have here. Still, their model would be the one I would have chosen if I were aligned with an RF business model for a speech/audio codec. However, clearly, this model is not compatible with the IETF policy or IETF practice right now. Regards, Stephan =20 On 7/31/09 12:51 PM, "Jean-Marc Valin" wrote: > stephen botzko a =E9crit : >> For example, the process might require us to study other companies' >> patents in order to design work-arounds. As Stephan Wenger noted a >> while ago, among other things this can create a risk of triple-damages >> liability for participants. This could create issues for some. >=20 > Actually, I would be curious to know how the ITU-T (and other SDOs) > deals with that issue. Do companies submitting codecs to the ITU-T > completely avoid searching for patents or do they accept the > triple-damages liability? >=20 > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec