From mramalho@cisco.com Mon Nov 2 05: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 46B683A6976 for ; Mon, 2 Nov 2009 05:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 oEz1W7wF8xz9 for ; Mon, 2 Nov 2009 05:41:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4C4F33A6916 for ; Mon, 2 Nov 2009 05:41:27 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO9w7kqtJV2Y/2dsb2JhbADEcZZYhDkEgWKGCQ X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="scan'208";a="66003968" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2009 13:41:46 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nA2DfkCY020483; Mon, 2 Nov 2009 13:41: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); Mon, 2 Nov 2009 08:41:45 -0500 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, 2 Nov 2009 08:41:44 -0500 Message-ID: In-Reply-To: <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicA= References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> From: "Michael Ramalho (mramalho)" To: "Roni Even" , "Peter Saint-Andre" , X-OriginalArrivalTime: 02 Nov 2009 13:41:45.0974 (UTC) FILETIME=[384B9160:01CA5BC2] Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 13:41:29 -0000 All, I strongly agree with Roni here, re: "I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec." Let's consider two SIMPLE examples. Example 1 - Let's assume I have an application that requires a certain linearity within a certain BW ranges (need > 25 dB of waveform linearity in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application uses adaptive signal processing techniques and linearity is important. Perhaps it is a far-end echo cancellation application, or a microphone beam array processing application that processes multiple streams at the receiver end. I could go on with any number of interesting examples. Note that such an applications would generate specific REQUIREMENTS to meet these use cases. The candidate codec would probably be waveform-based (at least in the bands having the linearity requirements). Example 2 - Many voice codecs use spectral techniques (such as spectral band replication, SBR) above 4k. Such codecs, while potentially capturing the spectral content well enough, will NOT preserve the phase (as the phase information is not in the compressed representation). Such a codec would NOT meet the simple > 20 dB linearity requirement (of the 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to a human - perhaps, as the human auditory system is not as sensitive to phase in this region. Additionally, many of these codecs are speech model based - and typically have < 20 dB of linearity on unvoiced speech even in 0 - 4k region. (You could throw in an entropy coding stage after the model to fix this - at the cost of BW - but I digress). One might ask why codec manufacturers use techniques such as SBR? Answer: because they are generally more efficient (precisely because they don't require as much phase information in the compressed domain) and sound good to humans. I could go on and on ... but I sincerely doubt that ONE MAGICAL codec can satisfy both examples above ... because both APPLICATIONS would result in different REQUIREMENTS. I think the rush to a "single-codec" requirements here is premature ... I agree with Roni ... one size does not fit all. Given the simple examples above - isn't it clear that we need to define applications (one might call them use cases) - and then requirements for them - before we determine how a given candidate satisfies the requirements? At a minimum, I see two legitimate codec classes: CLASS 1) codecs that are bandwidth efficient and sound good to humans (and perhaps satisfy tendeming or tone pass-through requirements), and CLASS 2) codecs whose output may later be processed by sophisticated signal processing functions (high-quality mixing, many classification-based applications such as speaker/sound/intrusion identification) that have SNR/waveform/distortion criteria generally exceeding CLASS 1. Granted, we should make each use case as broad as possible so as not to have too many of them. Once one codec is standardized for a particular application type - a subsequent candidate codec/application would need to prove it is "sufficiently different" from the existing codec(s) to go further. The WG chairs need to exert leadership to ensure the desired result (of the smallest number of codecs spanning the greatest application space). IF a given codec meets the requirements of its use case AND that use case is valid THEN I (for one) don't have an issue with the IETF "rubber stamping" of it. If you have a specific use case - then get together with other similarly minded folks and generate a "use case" draft and then a requirements draft for that use case. Don't try to solve world hunger in one step. Off Soapbox, Michael Ramalho, Ph.D. [Flames expected ... but please try to disprove my debate above when doing so ... I dislike flames that do not disprove a thesis ;-) ] PS - I think CLASS 1 codecs should be addressed first by the WG ... and later consider other classes as people advocate for their use case. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, October 30, 2009 6:34 PM To: 'Peter Saint-Andre'; codec@ietf.org Subject: Re: [codec] questions to be answered Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: >=20 > 1. Is there a problem that needs solving? >=20 > (Yes, see problem statement in charter.) >=20 > 2. Is the scope of the problem well defined and understood? >=20 > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) >=20 > 3. Is there agreement on what the WG needs to deliver? >=20 > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) >=20 > 4. Are there enough IETF participants to do the work? >=20 > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >=20 > 5. Does the WG have a reasonable probability of success? >=20 > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) >=20 > 6. Is the IETF is the right place to do the work? >=20 > (Maybe. I think this is the major item to clarify at the BoF.) >=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 > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =3D9vPK > -----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 jean-marc.valin@octasic.com Mon Nov 2 06:23: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 10D5D28C118 for ; Mon, 2 Nov 2009 06:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VgzWE6CAhpe for ; Mon, 2 Nov 2009 06:23:46 -0800 (PST) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id EF65E28C10B for ; Mon, 2 Nov 2009 06:23:45 -0800 (PST) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 09:24:03 -0500 Message-ID: <4AEEEB83.8090007@octasic.com> Date: Mon, 02 Nov 2009 09:24:03 -0500 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Michael Ramalho (mramalho)" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2009 14:24:03.0883 (UTC) FILETIME=[2101BFB0:01CA5BC8] Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 14:23:52 -0000 Hi Michael, Defining the requirements for each set of applications is exactly what we've been trying to do in section 2 of the requirements draft. Maybe we just need to expand this section with more detailed requirements. > Example 1 - Let's assume I have an application that requires a certain > linearity within a certain BW ranges (need > 25 dB of waveform linearity > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application > uses adaptive signal processing techniques and linearity is important. > Perhaps it is a far-end echo cancellation application, or a microphone > beam array processing application that processes multiple streams at the > receiver end. Well, right now there is no application that requires waveform similarity in the draft, so if that is needed, we should add a section to the requirements draft. > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS. > > I think the rush to a "single-codec" requirements here is premature ... > I agree with Roni ... one size does not fit all. Indeed, I am now thinking that we really shouldn't set a maximum number of codecs for the proposed WG until we have a complete list of target applications and requirements. > Given the simple examples above - isn't it clear that we need to define > applications (one might call them use cases) - and then requirements for > them - before we determine how a given candidate satisfies the > requirements? As I said, this is really the intent of Section 2 of the requirements draft. Though I agree it can probably be improved with more requirements and more details on the existing ones. > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and It seems like all the applications we have so far belong to this class. > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. Can you formulate uses cases for that one? My personal opinion is that with some work it should possible to satisfy both classes you list above with a single codec (possibly with different encoding options), but of course that remains to be verified in practice. > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). I don't think mapping applications to different codecs is something that can be done in advance. In fact, I wouldn't be too surprised if we ended up with some classes of applications needing two codecs and/or having several applications covered by the same codec. > IF > a given codec meets the requirements of its use case > AND > that use case is valid > THEN > I (for one) don't have an issue with the IETF "rubber stamping" of it. Wouldn't that lead to more codecs than necessary? > PS - I think CLASS 1 codecs should be addressed first by the WG ... and > later consider other classes as people advocate for their use case. Well, your two classes above represents a split along one possible dimension, which is waveform vs perceptual-only approach. There are many more possible splits, for instance: layered vs non-layered, algorithmic delay, VBR vs CBR, speech vs music, fullband vs narrowband, ... Having one codec for each is neither desirable, nor necessary. We will need to take a more global approach to split things up. Otherwise, one can argue that all the already-submitted codecs will fall into a different class a can be rubberstamped on its own. And if we do that, Roni will not be happy :-) Nor will I. Cheers, Jean-Marc From ron.even.tlv@gmail.com Mon Nov 2 07:11: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 378373A65A6 for ; Mon, 2 Nov 2009 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 t-WccBgt2ma2 for ; Mon, 2 Nov 2009 07:11:49 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id BD2083A680C for ; Mon, 2 Nov 2009 07:11:48 -0800 (PST) Received: by bwz23 with SMTP id 23so6432315bwz.29 for ; Mon, 02 Nov 2009 07:12:05 -0800 (PST) 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=/1Q64wbyd9WUsF+I0qbIHQk+AvfAROPussz6jgQGybQ=; b=AVXkZqZYxAyDSgc02akuN70U/pAh4Qv/0qRaOlQtyYG5X4fICdwNubP2q+rxMhR++P nwF3pjKYUY2QUVRCtyiEMAoW3Ks/D6icd/txCspSZMvy1bomAs9g9bd+1r0xp3CWL1Ya TlW6CbdZ+PwqcNfEknuDIbWYhmSnCo7a4fm+8= 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=SKfsMYNn8dOhroP53uLIbCxoEEbAkyK+wv/HSxYrEGK/qIBIy1se73tfF5DtwQahgK Q+aQRsqXYf4+OvfokfBLNVUdFdhFGkBEWTkGaXjgN72e7lZk0N8x4IYD4L8k75QDFNaR z14O+NdSBk8RoFqmksXZ5ychXXs71YvMj2XwI= Received: by 10.204.34.3 with SMTP id j3mr4035869bkd.23.1257174723352; Mon, 02 Nov 2009 07:12:03 -0800 (PST) Received: from windows8d787f9 (bzq-79-183-11-49.red.bezeqint.net [79.183.11.49]) by mx.google.com with ESMTPS id 35sm7837718fkt.16.2009.11.02.07.12.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 07:12:02 -0800 (PST) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Michael Ramalho \(mramalho\)'" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> In-Reply-To: <4AEEEB83.8090007@octasic.com> Date: Mon, 2 Nov 2009 17:11:10 +0200 Message-ID: <4aeef6c2.23145e0a.7c0a.ffffbd85@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: AcpbyCLdvlItTHdGTV2iJ7DL8P86OQABcT/g Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 15:11:50 -0000 Hi Jean-Marc, I looked at section 2 and it does not provide enough information why you need multiple codecs I would like to start with editorial comment. If you want to show requirements you should start with the parameters by which you define the codec like bit rate , sampling rate, hands free support,... and build a table that will include all the values for each application you think should be addressed. This will enable to justify the need for different codecs and to be able to qualify a codec for application. I think that having such information deserves a separate requirement document for each application. The current text has some values for some of the examples and some do not have any values. Regards Roni Even > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Monday, November 02, 2009 4:24 PM > To: Michael Ramalho (mramalho) > Cc: Roni Even; Peter Saint-Andre; codec@ietf.org > Subject: Re: [codec] questions to be answered > > Hi Michael, > > Defining the requirements for each set of applications is exactly what > we've been trying to do in section 2 of the requirements draft. Maybe > we > just need to expand this section with more detailed requirements. > > > Example 1 - Let's assume I have an application that requires a > certain > > linearity within a certain BW ranges (need > 25 dB of waveform > linearity > > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this > application > > uses adaptive signal processing techniques and linearity is > important. > > Perhaps it is a far-end echo cancellation application, or a > microphone > > beam array processing application that processes multiple streams at > the > > receiver end. > > Well, right now there is no application that requires waveform > similarity > in the draft, so if that is needed, we should add a section to the > requirements draft. > > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > > can satisfy both examples above ... because both APPLICATIONS would > > result in different REQUIREMENTS. > > > > I think the rush to a "single-codec" requirements here is premature > ... > > I agree with Roni ... one size does not fit all. > > Indeed, I am now thinking that we really shouldn't set a maximum number > of > codecs for the proposed WG until we have a complete list of target > applications and requirements. > > > Given the simple examples above - isn't it clear that we need to > define > > applications (one might call them use cases) - and then requirements > for > > them - before we determine how a given candidate satisfies the > > requirements? > > As I said, this is really the intent of Section 2 of the requirements > draft. Though I agree it can probably be improved with more > requirements > and more details on the existing ones. > > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > > (and perhaps satisfy tendeming or tone pass-through requirements), > and > > It seems like all the applications we have so far belong to this class. > > > CLASS 2) codecs whose output may later be processed by sophisticated > > signal processing functions (high-quality mixing, many > > classification-based applications such as speaker/sound/intrusion > > identification) that have SNR/waveform/distortion criteria generally > > exceeding CLASS 1. > > Can you formulate uses cases for that one? > > My personal opinion is that with some work it should possible to > satisfy > both classes you list above with a single codec (possibly with > different > encoding options), but of course that remains to be verified in > practice. > > > Granted, we should make each use case as broad as possible so as not > to > > have too many of them. Once one codec is standardized for a > particular > > application type - a subsequent candidate codec/application would > need > > to prove it is "sufficiently different" from the existing codec(s) to > go > > further. The WG chairs need to exert leadership to ensure the desired > > result (of the smallest number of codecs spanning the greatest > > application space). > > I don't think mapping applications to different codecs is something > that > can be done in advance. In fact, I wouldn't be too surprised if we > ended up > with some classes of applications needing two codecs and/or having > several applications covered by the same codec. > > > IF > > a given codec meets the requirements of its use case > > AND > > that use case is valid > > THEN > > I (for one) don't have an issue with the IETF "rubber stamping" of > it. > > Wouldn't that lead to more codecs than necessary? > > > PS - I think CLASS 1 codecs should be addressed first by the WG ... > and > > later consider other classes as people advocate for their use case. > > Well, your two classes above represents a split along one possible > dimension, which is waveform vs perceptual-only approach. There are > many > more possible splits, for instance: layered vs non-layered, algorithmic > delay, VBR vs CBR, speech vs music, fullband vs narrowband, ... > > Having one codec for each is neither desirable, nor necessary. We will > need > to take a more global approach to split things up. Otherwise, one can > argue > that all the already-submitted codecs will fall into a different class > a > can be rubberstamped on its own. And if we do that, Roni will not be > happy > :-) Nor will I. > > Cheers, > > Jean-Marc From mknappe@juniper.net Mon Nov 2 07:52: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 7B67E3A6A3D for ; Mon, 2 Nov 2009 07:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 hWM-7LaG+krF for ; Mon, 2 Nov 2009 07:52:22 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 18D583A6A2F for ; Mon, 2 Nov 2009 07:52:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSu8ARW4IIJ0kkWOoKSjK1aqdHkSk25xA@postini.com; Mon, 02 Nov 2009 07:52:42 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 2 Nov 2009 07:48:56 -0800 From: Michael Knappe To: "ron.even.tlv@gmail.com" , "jean-marc.valin@octasic.com" , "mramalho@cisco.com" Date: Mon, 2 Nov 2009 07:48:56 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpbyCLdvlItTHdGTV2iJ7DL8P86OQABcT/gAAGEktc= Message-ID: <05542EC42316164383B5180707A489EE1D031D3CFF@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 15:52:23 -0000 Roni, As per my email last Friday, I will have a draft of that table out today fo= r comment. Cheers, Mike ----- Original Message ----- From: codec-bounces@ietf.org To: 'Jean-Marc Valin' ; 'Michael Ramalho (mram= alho)' Cc: codec@ietf.org Sent: Mon Nov 02 10:11:10 2009=0A= Subject: Re: [codec] questions to be answered Hi Jean-Marc, I looked at section 2 and it does not provide enough information why you need multiple codecs I would like to start with editorial comment. If you want to show requirements you should start with the parameters by which you define the codec like bit rate , sampling rate, hands free support,... and build a table that will include all the values for each application you think shoul= d be addressed. This will enable to justify the need for different codecs and to be able to qualify a codec for application. I think that having such information deserves a separate requirement document for each application. The current text has some values for some of the examples and some do not have any values.=20 Regards Roni Even > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Monday, November 02, 2009 4:24 PM > To: Michael Ramalho (mramalho) > Cc: Roni Even; Peter Saint-Andre; codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > Hi Michael, >=20 > Defining the requirements for each set of applications is exactly what > we've been trying to do in section 2 of the requirements draft. Maybe > we > just need to expand this section with more detailed requirements. >=20 > > Example 1 - Let's assume I have an application that requires a > certain > > linearity within a certain BW ranges (need > 25 dB of waveform > linearity > > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this > application > > uses adaptive signal processing techniques and linearity is > important. > > Perhaps it is a far-end echo cancellation application, or a > microphone > > beam array processing application that processes multiple streams at > the > > receiver end. >=20 > Well, right now there is no application that requires waveform > similarity > in the draft, so if that is needed, we should add a section to the > requirements draft. >=20 > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > > can satisfy both examples above ... because both APPLICATIONS would > > result in different REQUIREMENTS. > > > > I think the rush to a "single-codec" requirements here is premature > ... > > I agree with Roni ... one size does not fit all. >=20 > Indeed, I am now thinking that we really shouldn't set a maximum number > of > codecs for the proposed WG until we have a complete list of target > applications and requirements. >=20 > > Given the simple examples above - isn't it clear that we need to > define > > applications (one might call them use cases) - and then requirements > for > > them - before we determine how a given candidate satisfies the > > requirements? >=20 > As I said, this is really the intent of Section 2 of the requirements > draft. Though I agree it can probably be improved with more > requirements > and more details on the existing ones. >=20 > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > > (and perhaps satisfy tendeming or tone pass-through requirements), > and >=20 > It seems like all the applications we have so far belong to this class. >=20 > > CLASS 2) codecs whose output may later be processed by sophisticated > > signal processing functions (high-quality mixing, many > > classification-based applications such as speaker/sound/intrusion > > identification) that have SNR/waveform/distortion criteria generally > > exceeding CLASS 1. >=20 > Can you formulate uses cases for that one? >=20 > My personal opinion is that with some work it should possible to > satisfy > both classes you list above with a single codec (possibly with > different > encoding options), but of course that remains to be verified in > practice. >=20 > > Granted, we should make each use case as broad as possible so as not > to > > have too many of them. Once one codec is standardized for a > particular > > application type - a subsequent candidate codec/application would > need > > to prove it is "sufficiently different" from the existing codec(s) to > go > > further. The WG chairs need to exert leadership to ensure the desired > > result (of the smallest number of codecs spanning the greatest > > application space). >=20 > I don't think mapping applications to different codecs is something > that > can be done in advance. In fact, I wouldn't be too surprised if we > ended up > with some classes of applications needing two codecs and/or having > several applications covered by the same codec. >=20 > > IF > > a given codec meets the requirements of its use case > > AND > > that use case is valid > > THEN > > I (for one) don't have an issue with the IETF "rubber stamping" of > it. >=20 > Wouldn't that lead to more codecs than necessary? >=20 > > PS - I think CLASS 1 codecs should be addressed first by the WG ... > and > > later consider other classes as people advocate for their use case. >=20 > Well, your two classes above represents a split along one possible > dimension, which is waveform vs perceptual-only approach. There are > many > more possible splits, for instance: layered vs non-layered, algorithmic > delay, VBR vs CBR, speech vs music, fullband vs narrowband, ... >=20 > Having one codec for each is neither desirable, nor necessary. We will > need > to take a more global approach to split things up. Otherwise, one can > argue > that all the already-submitted codecs will fall into a different class > a > can be rubberstamped on its own. And if we do that, Roni will not be > happy > :-) Nor will I. >=20 > Cheers, >=20 > Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From stpeter@stpeter.im Mon Nov 2 09:35: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 E9C673A68D3 for ; Mon, 2 Nov 2009 09:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 nrWybWdI88Pl for ; Mon, 2 Nov 2009 09:35:26 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 138F93A6783 for ; Mon, 2 Nov 2009 09:35:26 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3A16540D12; Mon, 2 Nov 2009 10:35:44 -0700 (MST) Message-ID: <4AEF186E.9090504@stpeter.im> Date: Mon, 02 Nov 2009 10:35:42 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> In-Reply-To: <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 17:35:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/09 8:11 AM, Roni Even wrote: > Hi Jean-Marc, > I looked at section 2 and it does not provide enough information why you > need multiple codecs > I would like to start with editorial comment. If you want to show > requirements you should start with the parameters by which you define the > codec like bit rate , sampling rate, hands free support,... and build a > table that will include all the values for each application you think should > be addressed. This will enable to justify the need for different codecs and > to be able to qualify a codec for application. I think that having such > information deserves a separate requirement document for each application. > The current text has some values for some of the examples and some do not > have any values. Roni and all, this is a great discussion and just the kind of work that a Codec WG should be doing. So let's charter the WG and get moving. :) 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/ iEYEARECAAYFAkrvGG4ACgkQNL8k5A2w/vxRZQCfSodq7Q0OrswnkjAGncSD1hdz 9HQAoNjwao8FF8Pwem5WGWOtGFvOgvDO =5EdO -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Nov 2 09: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 514A028C17C for ; Mon, 2 Nov 2009 09:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 42OaIuIiCjZ8 for ; Mon, 2 Nov 2009 09:42:28 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 191103A68D0 for ; Mon, 2 Nov 2009 09:42:28 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EC70640D12; Mon, 2 Nov 2009 10:42:47 -0700 (MST) Message-ID: <4AEF1A16.4070604@stpeter.im> Date: Mon, 02 Nov 2009 10:42:46 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4AEB25DE.7020602@stpeter.im> <4aec571b.cf02be0a.36fb.4699@mx.google.com> In-Reply-To: <4aec571b.cf02be0a.36fb.4699@mx.google.com> 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] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 17:42:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory and all, thanks for the feedback. Taking into account all the feedback received so far (on and off the list), I've created a second draft of the agenda: ### 1. Note Well & agenda bashing (5 minutes) 2. Progress to date (10 minutes) a. BoF at IETF 75 established constituency and interest b. Open issues: work process, requirements, ITU-T coordination c. Several individual drafts have been published and discussed on the list d. Coordination has been occurring with ITU-T SG 16 e. Consensus converging around draft charter 3. Charter discussion (45 minutes) a. Problem statement b. Objectives c. Deliverables d. Milestones 4. Is it reasonable to do this work at the IETF? (45 minutes) a. Informational presentation about ITU-T Study Group 16 b. Informational presentation about IETF Codec WG c. Discussion about alternatives (including other SDOs) 5. Questions to be answered (15 minutes) a. Is there a problem that needs solving? b. Is the scope of the problem well defined and understood? c. Is there agreement on what a WG would need to deliver? d. Are there people willing to do the work? i. Writing drafts ii. Reviewing drafts iii. Implementing / testing / characterizing / other e. Would a Codec WG have a reasonable probability of success? ### I'm having trouble accessing the datatracker, but I shall upload the agenda as soon as possible. Peter On 10/31/09 9:26 AM, Gregory M. Lebovitz wrote: > At 10:43 AM 10/30/2009, Peter Saint-Andre wrote: > Eric Burger and I have created a *draft* agenda for the Codec BoF. > Feedback is welcome! > > ### > > 1. Note Well & Agenda Bashing (5 minutes) > > 2. Progress to Date (15 minutes) > a. BoF at IETF 75 established constituency and interest > b. Open issues: work process, requirements, ITU-T coordination > c. Several individual drafts published and discussed on the list > d. Coordination has occurred with ITU-T SG 16 > >> s/has occurred/is occurring > >> Justification: We have had a good call between IETF leaders and ITU-T >> SG 16 and other ITU-T leaders to ensure good coordination around this >> topic. I and Cullen are drafting a formal Liaison to the ITU-T, which is >> being reviewed by the IAB and will be sent this weekend. But this effort >> will entail continued and on-going coordination with ITU-T, as they have >> much to offer in this process. > >> Gregory. > > e. Consensus converging around draft charter > > 3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) > >> Possible restatement: > >> "Does IETF have a reasonable chance of success compared to other forums?" > >> Justification: The term "Right" is overloaded. Right based on what >> criteria? It's not that black and white. But we may or may not have a >> more reasonable chance of success _meeting the stated goals_ compared to >> other forums. That's not right or wrong, its more objective. > > > a. Informational presentation about ITU-T Study Group 16 > b. Informational presentation about IETF Codec WG > c. Discussion about alternatives > d. Determination of consensus > > 4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes) > a. Problem statement > b. Objectives > c. Deliverables > d. Milestones > > 5. Key WG Formation Hums (10 minutes) > a. Is IETF the best place to do this work? > b. If a WG is formed, will you write drafts? > c. If a WG is formed, will you review drafts? > >> Do we need to add: > >> "If a WG is formed, will you test and characterize candidate code?" >> ? > >> I think we've made a lot of progress on this agenda, and I look forward >> to a constructive and interesting BoF. > >> Gregory > > d. If a WG is formed, will you otherwise participate? > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvGhYACgkQNL8k5A2w/vxqjACg9QxaXb/uXX+jzdHmygJ09xdF mFgAn0l+L9m70cphuyPxJ7Yv1O8bWH4q =0sGr -----END PGP SIGNATURE----- From koen.vos@skype.net Mon Nov 2 09: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 60A183A6911 for ; Mon, 2 Nov 2009 09:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgaakowtN9v0 for ; Mon, 2 Nov 2009 09:52:54 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 9C0843A68CD for ; Mon, 2 Nov 2009 09:52:53 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3302A6062EF18; Mon, 2 Nov 2009 17:53:13 +0000 (GMT) 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=KR5JaHsTPggr ohSTtGIaLWFhvlM=; b=bQ9aItzRWAiPe5pYISy9GYBLSx/4P1L11dSco9zTHGCY oljAO/pQNJjMBSepmTg4MJqAD394SIvOvkWmNogOvwUA0g3UobOc6G03bSffLEh6 kfvsWMQVrG4m4+HsbgcQY8sqYRsaa9M0b22vZixx1F17lDFzOwf20DS4KaRuvz4= 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=MoF8JFJkhmAtl5vrIAmo zrDR6wvBgcxpeatltGId48rGxfl9ENpkGP+tPEsONvZJvjA224pxpe+qeWeuGfIp UMY+TBUC8XySYmXN5mUqOjYQG+i+g0WXTW4fWyQPEMKlYTBJOVogd93Bk2lCJKoe 9l7fDahWr5F9Oo6lJnRmu2k= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 30F746058B68B; Mon, 2 Nov 2009 17:53:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEnEQYz7uM7T; Mon, 2 Nov 2009 17:53:03 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id A007F605D715D; Mon, 2 Nov 2009 17:53:03 +0000 (GMT) Received: from static.kpn.net (static.kpn.net [194.45.240.105]) by mail.skype.net (Horde Framework) with HTTP; Mon, 02 Nov 2009 09:53:03 -0800 Message-ID: <20091102095303.13974pw1vpo213zz@mail.skype.net> Date: Mon, 02 Nov 2009 09:53:03 -0800 From: Koen Vos To: Roni Even References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> In-Reply-To: <4aeef6c2.23145e0a.7c0a.ffffbd85@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) Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 17:52:55 -0000 Can we be more clear about what "multiple codecs" really means. After all, two codecs can always be merged to create a new single codec (with two modes). One question is: should any implementation of the codec always support all modes? Probably not. We do need to make sure that having different modes is no problem with respect to signaling. Things like: can we indicate during call negotiation what modes are available, and can we signal mode switches during a call? (I just don't know if these are straightforward or not.) koen. Quoting Roni Even : > Hi Jean-Marc, > I looked at section 2 and it does not provide enough information why you > need multiple codecs > I would like to start with editorial comment. If you want to show > requirements you should start with the parameters by which you define the > codec like bit rate , sampling rate, hands free support,... and build a > table that will include all the values for each application you think should > be addressed. This will enable to justify the need for different codecs and > to be able to qualify a codec for application. I think that having such > information deserves a separate requirement document for each application. > The current text has some values for some of the examples and some do not > have any values. > > Regards > Roni Even > > > >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >> Sent: Monday, November 02, 2009 4:24 PM >> To: Michael Ramalho (mramalho) >> Cc: Roni Even; Peter Saint-Andre; codec@ietf.org >> Subject: Re: [codec] questions to be answered >> >> Hi Michael, >> >> Defining the requirements for each set of applications is exactly what >> we've been trying to do in section 2 of the requirements draft. Maybe >> we >> just need to expand this section with more detailed requirements. >> >> > Example 1 - Let's assume I have an application that requires a >> certain >> > linearity within a certain BW ranges (need > 25 dB of waveform >> linearity >> > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this >> application >> > uses adaptive signal processing techniques and linearity is >> important. >> > Perhaps it is a far-end echo cancellation application, or a >> microphone >> > beam array processing application that processes multiple streams at >> the >> > receiver end. >> >> Well, right now there is no application that requires waveform >> similarity >> in the draft, so if that is needed, we should add a section to the >> requirements draft. >> >> > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec >> > can satisfy both examples above ... because both APPLICATIONS would >> > result in different REQUIREMENTS. >> > >> > I think the rush to a "single-codec" requirements here is premature >> ... >> > I agree with Roni ... one size does not fit all. >> >> Indeed, I am now thinking that we really shouldn't set a maximum number >> of >> codecs for the proposed WG until we have a complete list of target >> applications and requirements. >> >> > Given the simple examples above - isn't it clear that we need to >> define >> > applications (one might call them use cases) - and then requirements >> for >> > them - before we determine how a given candidate satisfies the >> > requirements? >> >> As I said, this is really the intent of Section 2 of the requirements >> draft. Though I agree it can probably be improved with more >> requirements >> and more details on the existing ones. >> >> > CLASS 1) codecs that are bandwidth efficient and sound good to humans >> > (and perhaps satisfy tendeming or tone pass-through requirements), >> and >> >> It seems like all the applications we have so far belong to this class. >> >> > CLASS 2) codecs whose output may later be processed by sophisticated >> > signal processing functions (high-quality mixing, many >> > classification-based applications such as speaker/sound/intrusion >> > identification) that have SNR/waveform/distortion criteria generally >> > exceeding CLASS 1. >> >> Can you formulate uses cases for that one? >> >> My personal opinion is that with some work it should possible to >> satisfy >> both classes you list above with a single codec (possibly with >> different >> encoding options), but of course that remains to be verified in >> practice. >> >> > Granted, we should make each use case as broad as possible so as not >> to >> > have too many of them. Once one codec is standardized for a >> particular >> > application type - a subsequent candidate codec/application would >> need >> > to prove it is "sufficiently different" from the existing codec(s) to >> go >> > further. The WG chairs need to exert leadership to ensure the desired >> > result (of the smallest number of codecs spanning the greatest >> > application space). >> >> I don't think mapping applications to different codecs is something >> that >> can be done in advance. In fact, I wouldn't be too surprised if we >> ended up >> with some classes of applications needing two codecs and/or having >> several applications covered by the same codec. >> >> > IF >> > a given codec meets the requirements of its use case >> > AND >> > that use case is valid >> > THEN >> > I (for one) don't have an issue with the IETF "rubber stamping" of >> it. >> >> Wouldn't that lead to more codecs than necessary? >> >> > PS - I think CLASS 1 codecs should be addressed first by the WG ... >> and >> > later consider other classes as people advocate for their use case. >> >> Well, your two classes above represents a split along one possible >> dimension, which is waveform vs perceptual-only approach. There are >> many >> more possible splits, for instance: layered vs non-layered, algorithmic >> delay, VBR vs CBR, speech vs music, fullband vs narrowband, ... >> >> Having one codec for each is neither desirable, nor necessary. We will >> need >> to take a more global approach to split things up. Otherwise, one can >> argue >> that all the already-submitted codecs will fall into a different class >> a >> can be rubberstamped on its own. And if we do that, Roni will not be >> happy >> :-) Nor will I. >> >> Cheers, >> >> Jean-Marc > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From gmaxwell@juniper.net Mon Nov 2 10:03: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 23BFF3A6A51 for ; Mon, 2 Nov 2009 10:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q15ekKaCPA6n for ; Mon, 2 Nov 2009 10:03:05 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 2248C3A6A62 for ; Mon, 2 Nov 2009 10:03:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSu8e6ur61RzMrn/HyWxyhXSebcR916Jc@postini.com; Mon, 02 Nov 2009 10:03:25 PST 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; Mon, 2 Nov 2009 10:02:51 -0800 From: Gregory Maxwell To: Koen Vos , Roni Even Date: Mon, 2 Nov 2009 10:02:51 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: Acpb5VvJ+2YGX9OETSOMTX4bdbZIRwAADf5a Message-ID: References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com>, <20091102095303.13974pw1vpo213zz@mail.skype.net> In-Reply-To: <20091102095303.13974pw1vpo213zz@mail.skype.net> 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: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 18:03:06 -0000 Koen Vos [koen.vos@skype.net] wrote: > Can we be more clear about what "multiple codecs" really means. After > all, two codecs can always be merged to create a new single codec > (with two modes). One question is: should any implementation of the > codec always support all modes? Probably not. "should any implementation of the codec always support all modes" Is a key question. My basic view on the matter is that if a mode is something that we wouldn't expect to make mandatory for all conforming implementations *and* taking it out or implementing only that mode substantially reduces implementation complexity, then we should have two codecs instead. If, on the other hand, there is some kind of mode which will either be so widely useful that it would be mandatory or doesn't have much impact on implementation complexity, then we should just have one codec which signals the mode in use in-band. From ron.even.tlv@gmail.com Mon Nov 2 11:48: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 419EE28C0D6 for ; Mon, 2 Nov 2009 11:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3C7aureSAbzG for ; Mon, 2 Nov 2009 11:48:08 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 32C473A6A77 for ; Mon, 2 Nov 2009 11:48:07 -0800 (PST) Received: by bwz23 with SMTP id 23so6727497bwz.29 for ; Mon, 02 Nov 2009 11:48:24 -0800 (PST) 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=Gzmb92OmaZTcWTTanFGXOBNYaGS/MxuTsfMTxITN/sk=; b=W2DL2XO631kqyhjRCCFb8Ki89YTIfISjJgGAL8+SEp1KecJuWgXJqtn3Cu8jKLecDI KvsYLndSxI3Y9vg5b6/9gn9VwUBf06Ei99sLA7vp7DlVfTKC10OZ8JMk8poxSJLwgmHF Qw/toJmcHG0CM3ScS9h4f8aptLXT2VMI0yr+4= 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=mn7AUPzCrWCVCwoNnBVIx2sgYuj914cUjrZYbK8taosW8cVm2zQJ6PDEeQUk8DIyZQ H/Bz+ebn0T5isMHXee8UD554n4+Oy/KHfkbaTeuBfz3BiQh437Wd4t69elliYphh5/va 36eVoRJl1Qc1T80XyU/gqI6GVObWPxoK2c9ag= Received: by 10.204.49.79 with SMTP id u15mr4254667bkf.117.1257191304156; Mon, 02 Nov 2009 11:48:24 -0800 (PST) Received: from windows8d787f9 (bzq-79-183-11-49.red.bezeqint.net [79.183.11.49]) by mx.google.com with ESMTPS id h2sm6861470fkh.6.2009.11.02.11.48.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 11:48:22 -0800 (PST) From: "Roni Even" To: "'Peter Saint-Andre'" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> <4AEF186E.9090504@stpeter.im> In-Reply-To: <4AEF186E.9090504@stpeter.im> Date: Mon, 2 Nov 2009 21:47:26 +0200 Message-ID: <4aef3786.02225e0a.09f9.0d90@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: Acpb4ujNLWHEemgTRFeNZu5F7l+tPwAEgWPA Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 19:48:09 -0000 Peter, This has to do with the charter, there need to be a decision how many = codec are developed for one requirement document. It looks to me based on the discussion that there is no consensus = between the people who propose this charter since all have similar = codecs they want to approve and are not looking at collaboration. Roni Even > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Monday, November 02, 2009 7:36 PM > To: Roni Even > Cc: 'Jean-Marc Valin'; 'Michael Ramalho (mramalho)'; codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/2/09 8:11 AM, Roni Even wrote: > > Hi Jean-Marc, > > I looked at section 2 and it does not provide enough information why > you > > need multiple codecs > > I would like to start with editorial comment. If you want to show > > requirements you should start with the parameters by which you = define > the > > codec like bit rate , sampling rate, hands free support,... and = build > a > > table that will include all the values for each application you = think > should > > be addressed. This will enable to justify the need for different > codecs and > > to be able to qualify a codec for application. I think that having > such > > information deserves a separate requirement document for each > application. > > The current text has some values for some of the examples and some = do > not > > have any values. >=20 > Roni and all, this is a great discussion and just the kind of work = that > a Codec WG should be doing. So let's charter the WG and get moving. :) >=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 > iEYEARECAAYFAkrvGG4ACgkQNL8k5A2w/vxRZQCfSodq7Q0OrswnkjAGncSD1hdz > 9HQAoNjwao8FF8Pwem5WGWOtGFvOgvDO > =3D5EdO > -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Mon Nov 2 11:50: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 509D23A6A79 for ; Mon, 2 Nov 2009 11:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7fLIFTKic8dp for ; Mon, 2 Nov 2009 11:50:36 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CF76B3A677E for ; Mon, 2 Nov 2009 11:50:35 -0800 (PST) Received: by bwz23 with SMTP id 23so6730067bwz.29 for ; Mon, 02 Nov 2009 11:50:52 -0800 (PST) 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=WxzP5Rvz8nPN2FBJXbnPOpLX9aLEWbvPrYJZ9LWs9ls=; b=EBlj7uSRHADg5axhl3wXNrRdHg0S01cyw/mwc+/gVJjZcVORxjqGIFRb4TNhhfg8wY OXNtkm5c1KWh6mpLTT1GJPTHddzqbI0I4381/MMlxToZLX74uAERfhC/eXns8eDeNoA1 S303fCU68V/UmWOUd4qGGLYkV1Dm5c+pPFWPc= 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=i1J8ZUZwrsxe/ESDCy2PHwhob++7iTl36ModuOuUr8e1H7qis1OKqOMR3NT6jB2w5U 2eMExXeiRZey95RIQj9kfBzSjkoqGpvlSOaldQGF7x7z4YMkaMToMK7WOG2xKgOjqhX4 vLVeC9XEmM5Sr6b7fL/fyFty3GOY2EriyiDfM= Received: by 10.204.24.2 with SMTP id t2mr4269490bkb.65.1257191452498; Mon, 02 Nov 2009 11:50:52 -0800 (PST) Received: from windows8d787f9 (bzq-79-183-11-49.red.bezeqint.net [79.183.11.49]) by mx.google.com with ESMTPS id 12sm397230fks.8.2009.11.02.11.50.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 11:50:50 -0800 (PST) From: "Roni Even" To: "'Peter Saint-Andre'" , "'Gregory M. Lebovitz'" References: <4AEB25DE.7020602@stpeter.im> <4aec571b.cf02be0a.36fb.4699@mx.google.com> <4AEF1A16.4070604@stpeter.im> In-Reply-To: <4AEF1A16.4070604@stpeter.im> Date: Mon, 2 Nov 2009 21:49:55 +0200 Message-ID: <4aef381a.0c135e0a.02bc.2f37@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: Acpb4+kaWR1Wn/jfQkCvMkcM1lsvHAAEZAtw Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 19:50:37 -0000 Hi Peter, Who is going to give all these presentations, I am used to see the presenters in agendas Regards Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Monday, November 02, 2009 7:43 PM > To: Gregory M. Lebovitz > Cc: codec@ietf.org > Subject: Re: [codec] *draft* agenda > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gregory and all, thanks for the feedback. Taking into account all the > feedback received so far (on and off the list), I've created a second > draft of the agenda: > > ### > > 1. Note Well & agenda bashing (5 minutes) > > 2. Progress to date (10 minutes) > a. BoF at IETF 75 established constituency and interest > b. Open issues: work process, requirements, ITU-T coordination > c. Several individual drafts have been published and discussed on > the > list > d. Coordination has been occurring with ITU-T SG 16 > e. Consensus converging around draft charter > > 3. Charter discussion (45 minutes) > a. Problem statement > b. Objectives > c. Deliverables > d. Milestones > > 4. Is it reasonable to do this work at the IETF? (45 minutes) > a. Informational presentation about ITU-T Study Group 16 > b. Informational presentation about IETF Codec WG > c. Discussion about alternatives (including other SDOs) > > 5. Questions to be answered (15 minutes) > a. Is there a problem that needs solving? > b. Is the scope of the problem well defined and understood? > c. Is there agreement on what a WG would need to deliver? > d. Are there people willing to do the work? > i. Writing drafts > ii. Reviewing drafts > iii. Implementing / testing / characterizing / other > e. Would a Codec WG have a reasonable probability of success? > > ### > > I'm having trouble accessing the datatracker, but I shall upload the > agenda as soon as possible. > > Peter > > On 10/31/09 9:26 AM, Gregory M. Lebovitz wrote: > > At 10:43 AM 10/30/2009, Peter Saint-Andre wrote: > > Eric Burger and I have created a *draft* agenda for the Codec BoF. > > Feedback is welcome! > > > > ### > > > > 1. Note Well & Agenda Bashing (5 minutes) > > > > 2. Progress to Date (15 minutes) > > a. BoF at IETF 75 established constituency and interest > > b. Open issues: work process, requirements, ITU-T coordination > > c. Several individual drafts published and discussed on the list > > d. Coordination has occurred with ITU-T SG 16 > > > >> s/has occurred/is occurring > > > >> Justification: We have had a good call between IETF leaders and > ITU-T > >> SG 16 and other ITU-T leaders to ensure good coordination around > this > >> topic. I and Cullen are drafting a formal Liaison to the ITU-T, > which is > >> being reviewed by the IAB and will be sent this weekend. But this > effort > >> will entail continued and on-going coordination with ITU-T, as they > have > >> much to offer in this process. > > > >> Gregory. > > > > e. Consensus converging around draft charter > > > > 3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) > > > >> Possible restatement: > > > >> "Does IETF have a reasonable chance of success compared to other > forums?" > > > >> Justification: The term "Right" is overloaded. Right based on what > >> criteria? It's not that black and white. But we may or may not have > a > >> more reasonable chance of success _meeting the stated goals_ > compared to > >> other forums. That's not right or wrong, its more objective. > > > > > > a. Informational presentation about ITU-T Study Group 16 > > b. Informational presentation about IETF Codec WG > > c. Discussion about alternatives > > d. Determination of consensus > > > > 4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 > minutes) > > a. Problem statement > > b. Objectives > > c. Deliverables > > d. Milestones > > > > 5. Key WG Formation Hums (10 minutes) > > a. Is IETF the best place to do this work? > > b. If a WG is formed, will you write drafts? > > c. If a WG is formed, will you review drafts? > > > >> Do we need to add: > > > >> "If a WG is formed, will you test and characterize candidate code?" > >> ? > > > >> I think we've made a lot of progress on this agenda, and I look > forward > >> to a constructive and interesting BoF. > > > >> Gregory > > > > d. If a WG is formed, will you otherwise participate? > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrvGhYACgkQNL8k5A2w/vxqjACg9QxaXb/uXX+jzdHmygJ09xdF > mFgAn0l+L9m70cphuyPxJ7Yv1O8bWH4q > =0sGr > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Mon Nov 2 11: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 C86003A6A79 for ; Mon, 2 Nov 2009 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FDWSkgdg6f8a for ; Mon, 2 Nov 2009 11:53:32 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CD6223A6A77 for ; Mon, 2 Nov 2009 11:53:31 -0800 (PST) Received: by bwz23 with SMTP id 23so6732999bwz.29 for ; Mon, 02 Nov 2009 11:53:48 -0800 (PST) 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=GjwYFtAr7zRvH8F2AJ9D9SbYX5Lz5Lr5Jpy1x4BHwLk=; b=rb0ceOSQE+3ub39+hW3DUzIf7t7IgdyTXiPj+Pz1X6jWg5qw+zOeDuzJzN/XceJMOw HWbPvkXkaGmR9rwRnGDMNkcs8PYun5AzLBIANCB5ZYZGUMecAXayEdzkAHsESqZ8PUeK PpUHfir365EstiW/LxzJPbtjESTKaoOLCQomY= 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=H+jo6ejBz3Jp57uoNXg/Ug20EtlV3qs4KwzQfR0wXAd7xC/F6H+GBnkxOEzLGLkOHY HX/A2G5Id3zMLVjqzL/T0KqeIVcgTnXBOARGtUe/2nu0OPmALovgb+ADf3ghfnb5R90x S+439C6cfJGvbILyWXx6EtkoV9EhLVAXz7u14= Received: by 10.204.154.150 with SMTP id o22mr4258497bkw.154.1257191627951; Mon, 02 Nov 2009 11:53:47 -0800 (PST) Received: from windows8d787f9 (bzq-79-183-11-49.red.bezeqint.net [79.183.11.49]) by mx.google.com with ESMTPS id 35sm81037fkt.16.2009.11.02.11.53.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 11:53:47 -0800 (PST) From: "Roni Even" To: "'Gregory Maxwell'" , "'Koen Vos'" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com>, <20091102095303.13974pw1vpo213zz@mail.skype.net> In-Reply-To: Date: Mon, 2 Nov 2009 21:52:50 +0200 Message-ID: <4aef38cb.23145e0a.5ff9.08f6@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: Acpb5VvJ+2YGX9OETSOMTX4bdbZIRwAADf5aAAQOidA= Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 19:53:32 -0000 Hi, I thought that the group will not make mandatory requirements for implementation so having a codec with extensions that can be negotiated is the preferred direction. Roni > -----Original Message----- > From: Gregory Maxwell [mailto:gmaxwell@juniper.net] > Sent: Monday, November 02, 2009 8:03 PM > To: Koen Vos; Roni Even > Cc: codec@ietf.org > Subject: RE: [codec] questions to be answered > > Koen Vos [koen.vos@skype.net] wrote: > > Can we be more clear about what "multiple codecs" really means. After > > all, two codecs can always be merged to create a new single codec > > (with two modes). One question is: should any implementation of the > > codec always support all modes? Probably not. > > "should any implementation of the codec always support all modes" > Is a key question. > > My basic view on the matter is that if a mode is something that we > wouldn't > expect to make mandatory for all conforming implementations *and* > taking > it out or implementing only that mode substantially reduces > implementation > complexity, then we should have two codecs instead. > > If, on the other hand, there is some kind of mode which will either be > so > widely useful that it would be mandatory or doesn't have much impact on > implementation complexity, then we should just have one codec which > signals the mode in use in-band. From stpeter@stpeter.im Mon Nov 2 11:56: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 C1F703A68C7 for ; Mon, 2 Nov 2009 11:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Z4+n5MhjohU6 for ; Mon, 2 Nov 2009 11:56:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D2CC73A6833 for ; Mon, 2 Nov 2009 11:56:08 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6C25A40D12; Mon, 2 Nov 2009 12:56:28 -0700 (MST) Message-ID: <4AEF396B.5080707@stpeter.im> Date: Mon, 02 Nov 2009 12:56:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> <4AEF186E.9090504@stpeter.im> <4aef3786.02225e0a.09f9.0d90@mx.google.com> In-Reply-To: <4aef3786.02225e0a.09f9.0d90@mx.google.com> 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 19:56:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/09 12:47 PM, Roni Even wrote: > Peter, This has to do with the charter, there need to be a decision > how many codec are developed for one requirement document. It looks > to me based on the discussion that there is no consensus between the > people who propose this charter since all have similar codecs they > want to approve and are not looking at collaboration. I see no evidence for that statement. All of the individuals and teams who have submitted codecs have done so with the understanding that each contribution will probably not be approved, and even if approved would undergo modification (i.e., even a codec that functioned as a "starting point" codec would be *adapted*, not *adopted*). This is consistent with the following statement in draft-valin-codec-guidelines-02: Furthermore, contributors need to be aware that any codec that results from work within the IETF is likely to be different from any existing codec that was contributed to the Internet Standards Process. All of the speakers I heard at the BoF in Stockholm made it clear that they expect to and are eager to collaborate on a codec that meets the requirements, and that they do not expect to simply get their own codecs approved as-is. 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/ iEYEARECAAYFAkrvOWoACgkQNL8k5A2w/vyTagCbBEaXVzB2i5W+eY13RuEI3dPR /2cAoIl3k1ih6Wb05EtVeEzlWIQ6g9lm =Cswk -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Mon Nov 2 12:09: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 649B93A68FC for ; Mon, 2 Nov 2009 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 J1wblvV9fx9H for ; Mon, 2 Nov 2009 12:09:06 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 1CD233A6782 for ; Mon, 2 Nov 2009 12:09:05 -0800 (PST) Received: by bwz23 with SMTP id 23so6749305bwz.29 for ; Mon, 02 Nov 2009 12:09:22 -0800 (PST) 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=76LPkxMrfjaUAMElhJhgZ4oxjzXt5cmfZseZX0/5WBo=; b=Iz6HfjcWaarkOKOe7Evog9IIrfSwE4xv/uKCOim1H+1nG5PSZaysBo3sL1b1Lu/9Q5 nY7Z03FTMURAxZzwqSHkNh+bmxm78olUtIvd951r+ypsGwlcfp5fG+LciSB1fEdiJmio adBGy+7OLSq56kaf7au2eBYX1DFBsYSSaGl0o= 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=PG7M9TW0x6qxrgVzov9vbnj5/ZtdOmcjrgsxyazpDQop3csV9MukRYf8w/A9nyLvTS T76Ws3DUDo2cTUZ9TN8bjfMXiC++EPI1ZbzmhUYD7vR3+CDP0XpvYa5cWU06dgJpJ9Be Q87f2Cs6fC7tXNmIme+rFm8Zm2hLtOAd5uxQQ= Received: by 10.204.13.204 with SMTP id d12mr3098876bka.61.1257192562656; Mon, 02 Nov 2009 12:09:22 -0800 (PST) Received: from windows8d787f9 (bzq-79-183-11-49.red.bezeqint.net [79.183.11.49]) by mx.google.com with ESMTPS id 15sm920071bwz.0.2009.11.02.12.09.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 12:09:21 -0800 (PST) From: "Roni Even" To: "'Peter Saint-Andre'" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> <4AEF186E.9090504@stpeter.im> <4aef3786.02225e0a.09f9.0d90@mx.google.com> <4AEF396B.5080707@stpeter.im> In-Reply-To: <4AEF396B.5080707@stpeter.im> Date: Mon, 2 Nov 2009 22:08:28 +0200 Message-ID: <4aef3c71.0f1abc0a.315e.5987@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: Acpb9pHR8/Gt4eqpTWCk2X/10b6TxQAAYiog Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Nov 2009 20:09:07 -0000 Peter, So if there is no problem have the charter reflect how many codecs there = will be.=20 I suggest one for each requirement document Roni Even > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Monday, November 02, 2009 9:56 PM > To: Roni Even > Cc: 'Jean-Marc Valin'; 'Michael Ramalho (mramalho)'; codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/2/09 12:47 PM, Roni Even wrote: > > Peter, This has to do with the charter, there need to be a decision > > how many codec are developed for one requirement document. It looks > > to me based on the discussion that there is no consensus between the > > people who propose this charter since all have similar codecs they > > want to approve and are not looking at collaboration. >=20 > I see no evidence for that statement. >=20 > All of the individuals and teams who have submitted codecs have done = so > with the understanding that each contribution will probably not be > approved, and even if approved would undergo modification (i.e., even = a > codec that functioned as a "starting point" codec would be *adapted*, > not *adopted*). This is consistent with the following statement in > draft-valin-codec-guidelines-02: >=20 > Furthermore, contributors need to be > aware that any codec that results from work within the IETF is > likely > to be different from any existing codec that was contributed to the > Internet Standards Process. >=20 > All of the speakers I heard at the BoF in Stockholm made it clear that > they expect to and are eager to collaborate on a codec that meets the > requirements, and that they do not expect to simply get their own > codecs > approved as-is. >=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 > iEYEARECAAYFAkrvOWoACgkQNL8k5A2w/vyTagCbBEaXVzB2i5W+eY13RuEI3dPR > /2cAoIl3k1ih6Wb05EtVeEzlWIQ6g9lm > =3DCswk > -----END PGP SIGNATURE----- From hoene@uni-tuebingen.de Tue Nov 3 01:30: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 E054A3A67B8 for ; Tue, 3 Nov 2009 01:30:48 -0800 (PST) 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 DvgYRQOcIRNs for ; Tue, 3 Nov 2009 01:30:48 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id BABD43A676A for ; Tue, 3 Nov 2009 01:30:47 -0800 (PST) Received: from hoeneLenovoT60 ([193.158.25.47]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id nA39U35k014802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 10:31:03 +0100 From: "Christian Hoene" To: "'Michael Ramalho \(mramalho\)'" , References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> In-Reply-To: Date: Tue, 3 Nov 2009 10:30:03 +0100 Message-ID: <00a801ca5c68$5d5ef9a0$181cece0$@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: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UA== 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.1.53; VDF: 7.1.6.180; host: mx05); id=11865-ZBgX8P Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 09:30:49 -0000 Hello Michael, > At a minimum, I see two legitimate codec classes: >=20 > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and >=20 > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing,=20 High-quality mixing? That do you have in mind? Stereo or binaural (3D = sound) mixing? > many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. You may add distributed speech recognition to the second class. However, = to my understanding the current offered codecs have not been designed with = the second class in mind. Also, class 2 might not fall in the interactive category (which implies that communication takes place between humans). By the way, are you training your classification-based applications = while taking the distortions caused by the transmission system into = consideration? You forgot: We need to add CLASS 3 for video and CLASS 4 for general content, too. > Granted, we should make each use case as broad as possible so as not = to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to = go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). Yes, actually Noll and Jayant have proposed to use =B5-Law to support = speech, audio AND video compression. But to my understanding it is common = consensus to concentrate on a limited (e.g. class 1) scenario and finished this = work first before setting up another construction site. Christian From hoene@uni-tuebingen.de Tue Nov 3 02:13: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 30BD83A68DA for ; Tue, 3 Nov 2009 02:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FRT_BEFORE=1.272, 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 JQ97fEk5z+w6 for ; Tue, 3 Nov 2009 02:13:27 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E6F813A68B9 for ; Tue, 3 Nov 2009 02:13:26 -0800 (PST) Received: from hoeneLenovoT60 ([193.158.25.47]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id nA39U35l014802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 10:31:07 +0100 From: "Christian Hoene" To: "'Peter Saint-Andre'" , "'Roni Even'" References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> <4AEF186E.9090504@stpeter.im> <4aef3786.02225e0a.09f9.0d90@mx.google.com> <4AEF396B.5080707@stpeter.im> In-Reply-To: <4AEF396B.5080707@stpeter.im> Date: Tue, 3 Nov 2009 10:30:03 +0100 Message-ID: <00a901ca5c68$6025e1d0$2071a570$@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: Acpb9pmRwXyluZh8RUKAvVchm5izFAAWPh4Q 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.1.53; VDF: 7.1.6.180; host: mx05); id=11865-jsDoYw Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 10:13:28 -0000 Hello Peter, > > Peter, This has to do with the charter, there need to be a decision > > how many codec are developed for one requirement document. It looks > > to me based on the discussion that there is no consensus between the > > people who propose this charter since all have similar codecs they > > want to approve and are not looking at collaboration. > > I see no evidence for that statement. > > All of the individuals and teams who have submitted codecs have done so > with the understanding that each contribution will probably not be > approved, and even if approved would undergo modification (i.e., even a > codec that functioned as a "starting point" codec would be *adapted*, > not *adopted*). This is consistent with the following statement in > draft-valin-codec-guidelines-02: > > Furthermore, contributors need to be > aware that any codec that results from work within the IETF is likely > to be different from any existing codec that was contributed to the > Internet Standards Process. > > All of the speakers I heard at the BoF in Stockholm made it clear that > they expect to and are eager to collaborate on a codec that meets the > requirements, and that they do not expect to simply get their own codecs > approved as-is. This all might be true. However, at the moment we are discussing the charter and not the drafts nor any oral statements, which all can be updated or revoked at any time. Thus, it would be beneficial having some high level goals in the charter that help to decide on the number of codecs. These could be for e.g. "Different codecs must have unmergable, orthogonal requirements" or "One codec and a low number of optional extensions that address additional requirements". With best regards, Christian From hoene@uni-tuebingen.de Tue Nov 3 02:13: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 C54643A696A for ; Tue, 3 Nov 2009 02:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_50=0.001, 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 0Dwkj54aNeAA for ; Tue, 3 Nov 2009 02:13:22 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id B988D3A68C6 for ; Tue, 3 Nov 2009 02:13:21 -0800 (PST) Received: from hoeneLenovoT60 ([193.158.25.47]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id nA39U35m014802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Nov 2009 10:31:10 +0100 From: "Christian Hoene" To: References: <002401ca5271$bde53e20$39afba60$@de> <130EBB38279E9847BAAAE0B8F9905F8C0214AD7A@esealmw109.eemea.ericsson.se> <001301ca52eb$7d99bce0$78cd36a0$@de> <130EBB38279E9847BAAAE0B8F9905F8C0214AE31@esealmw109.eemea.ericsson.se> <1256201655.7929.8.camel@hoene-desktop> <130EBB38279E9847BAAAE0B8F9905F8C0214B180@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C0214B180@esealmw109.eemea.ericsson.se> Date: Tue, 3 Nov 2009 10:30:03 +0100 Message-ID: <00aa01ca5c68$62958240$27c086c0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01CA5C70.C459EA40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpS9XUV9YHs9vwhQxm/Ojtknp9uuQADibcwAV4QEMA= 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.1.53; VDF: 7.1.6.180; host: mx05); id=11865-jy9hEr Subject: [codec] Switching codecs and coding mode. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 10:13:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01CA5C70.C459EA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 =20 Last week we had a discussion on the impact of switching between codecs = and between coding modes. I made a short review of related work to = understand the current state of the art. Actually, we have to distinguish multiple different effects. 1. The first is based on the fact that in case of mode or coding switching a segment of speech consists of parts having good quality and parts having bad quality. The question arises on how the overall quality = is judged. Some pioneering studies in this field have been made by AD Clark = =96 not in the case of switching the codecs/coding mode but for changing = loss rates. Refer to [1]. Also, [2] suggests an extension to the E-Model [2] = to support changing qualities. 2. The event of changing the codec/coding mode might introduce additional distortions. We can distinguish three cases: a. Changing of the bit rate, e.g. changing the frame size in CELT, = the bitpool value SBC and the coding rate in AMR/AMR-WB: I did not found any listening-test results that there is any impairment beyond those = described in point 1. For example, it has been proven that CELT AND AMR do support = the seamless switching between coding modes. b. Changes in the packet rate might require a rescheduling of the playout time because of the changed packetization delay. The resulting = time stretching or time compression might introduce additional distortions. = Refer to e.g. [3].=20 c. Switching between two different codecs or switching the = sampling rate of a codec (e.g. 16 to 48 kHz in case of SBC, 32 to 48 kHz in case = of CELT, or between AMR-NB and AMR-WB) introduces distortions caused by the needed synchronization of the decoder. Refer to [4] and [5] for listening-tests in case of G.711 and G.722.2. In these publications they noticed a notable distortion caused by switching between wideband and narrowband. You hear them especially well if other transmission = conditions are good (e.g. no packet losses) All these switching events might be concealed via various technical approaches. However, I did not found any publications or patents on it = =96 deeper literature survey might be required. To conclude, we can state that it is important that the system supports = the seamless of codecs or coding modes. If not, the distortion will be quite notable. =20 Christian =20 [1] AD Clark, =84 = Modeling the effects of burst packet loss and recency on subjective voice = quality=93, Proc. IP Telephony Workshop, 2001 for details. [2] Lewcio, B., W=E4ltermann, M., M=F6ller, S., Vidales, P. (2009). = "E-model supported Switching between Narrowband and Wideband Speech Quality". In: Proc. 1st Int. IEEE Workshop on Quality of Multimedia Experience (QoMEX '09), 29-31 July, US-San Diego CA. [3] Y. J. Liang, N. F=E4rber, and B. Girod, =93Adaptive playout = scheduling and loss concealment for voice communication over IP networks,=94 IEEE Transactions on Multimedia, vol. 5, no. 4, pp. 532=96543, Dec. 2003. [4] Lewcio, B., M=F6ller, S. ,Vidales,P. W=E4ltermann, M.,Kirschnick, N. = (2008). Methods for multimedia service adaptation in Next Generation Networks, = in Proceedings of the ETSI STQ 2008 Workshop on Effects of Transmission Performance on Multimedia QoS,CZ-Prague, 17-19 June. [5] M=F6ller, S., W=E4ltermann, M., Lewcio, B., Kirschnick, N., Vidales, = P. (2008). Handovers between Narrowband and Wideband Speech Transmission, = in: Sprachkommunikation 2008. Beitr=E4ge der 8. ITG-Fachtagung vom 8. bis = 10. Oktober 2008 in Aachen, ITG-Fachbericht 211, VDE-Verlag, DE-Berlin. =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 ------=_NextPart_000_00AB_01CA5C70.C459EA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Last week we had a discussion on = the impact of switching between codecs and between coding modes. I made a short = review of related work to understand the current state of the art. Actually, we = have to distinguish multiple different effects.

1.       The first is based on = the fact that in case of mode or coding switching a segment of speech consists of = parts having good quality and parts having bad quality. The question arises on = how the overall quality is judged. Some pioneering studies in this field have = been made by AD Clark – not in the case of switching the codecs/coding mode = but for changing loss rates. Refer to [1]. Also, [2] suggests an extension to = the E-Model [2] to support changing qualities.

2.       The event of changing = the codec/coding mode might introduce additional distortions. We can = distinguish three cases:

a.       Changing of the bit = rate, e.g. changing the frame size in CELT, the bitpool value SBC and the coding = rate in AMR/AMR-WB: I did not found any listening-test results that there is any impairment beyond those described in point 1. For example, it has been = proven that CELT AND AMR do support the seamless switching between coding = modes.

b.      Changes in the packet = rate might require a rescheduling of the playout time because of the changed packetization delay. The resulting time stretching or time compression = might introduce additional distortions. Refer to e.g. [3]. =

c.       Switching between two = different codecs or switching the sampling rate of a codec (e.g. 16 to 48 kHz in = case of SBC, 32 to 48 kHz in case of CELT, or between AMR-NB and AMR-WB) = introduces distortions caused by the needed synchronization of the decoder. Refer = to [4] and [5] for listening-tests in case of G.711 and G.722.2. In these = publications they noticed a notable distortion caused by switching between wideband = and narrowband. You hear them especially well if other transmission = conditions are good (e.g. no packet losses)

All these switching events might = be concealed via various technical approaches. However, I did not found any publications or patents on it – deeper literature survey might be required.

To conclude, we can state that = it is important that the system supports the seamless of codecs or coding = modes. If not, the distortion will be quite notable.

 

Christian

 

[1] AD Clark, „Methods for multimedia service adaptation in Next Generation = Networks, in Proceedings of the ETSI STQ 2008 Workshop on Effects = of Transmission Performance on Multimedia QoS,CZ-Prague, 17-19 = June.

[5] M=F6ller, S., W=E4ltermann, M., Lewcio, B., = Kirschnick, N., Vidales, P. (2008). Handovers between Narrowband and Wideband Speech Transmission, in: = Sprachkommunikation 2008. Beitr=E4ge der 8. ITG-Fachtagung vom 8. bis 10. Oktober 2008 in = Aachen, ITG-Fachbericht 211, VDE-Verlag, DE-Berlin.

 

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

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/

 

------=_NextPart_000_00AB_01CA5C70.C459EA40-- From ingemar.s.johansson@ericsson.com Tue Nov 3 04: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 21D593A68C9 for ; Tue, 3 Nov 2009 04:54:53 -0800 (PST) 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_SE=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 wjiYriUzKNoW for ; Tue, 3 Nov 2009 04:54:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D9A703A6891 for ; Tue, 3 Nov 2009 04:54:50 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-eb-4af0282e3267 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 07.A6.31706.E2820FA4; Tue, 3 Nov 2009 13:55:10 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:55:10 +0100 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_01CA5C84.DF9217E1" Date: Tue, 3 Nov 2009 13:55:08 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0228CD6E@esealmw109.eemea.ericsson.se> In-Reply-To: <00aa01ca5c68$62958240$27c086c0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Switching codecs and coding mode. Thread-Index: AcpchN80v6KnlxXgQE2Uf1OI3wKP4w== References: <002401ca5271$bde53e20$39afba60$@de><130EBB38279E9847BAAAE0B8F9905F8C0214AD7A@esealmw109.eemea.ericsson.se><001301ca52eb$7d99bce0$78cd36a0$@de><130EBB38279E9847BAAAE0B8F9905F8C0214AE31@esealmw109.eemea.ericsson.se><1256201655.7929.8.camel@hoene-desktop><130EBB38279E9847BAAAE0B8F9905F8C0214B180@esealmw109.eemea.ericsson.se> <00aa01ca5c68$62958240$27c086c0$@de> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 03 Nov 2009 12:55:10.0046 (UTC) FILETIME=[E0348FE0:01CA5C84] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Switching codecs and coding mode. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 12:54:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C84.DF9217E1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 Please note the observation that AMR and AMR-WB does not give any = switching artifacts when switching between codec modes. In fact the = whole idea with AMR (Adaptive MultiRate) is to be able to freely switch = between codec rates without artifacts.=20 =20 Regards Ingemar ________________________________ From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: den 3 november 2009 10:30 To: codec@ietf.org Subject: [codec] Switching codecs and coding mode. =09 =09 Hello,=20 =20 Last week we had a discussion on the impact of switching between codecs = and between coding modes. I made a short review of related work to = understand the current state of the art. Actually, we have to = distinguish multiple different effects. 1. The first is based on the fact that in case of mode or coding = switching a segment of speech consists of parts having good quality and = parts having bad quality. The question arises on how the overall quality = is judged. Some pioneering studies in this field have been made by AD = Clark - not in the case of switching the codecs/coding mode but for = changing loss rates. Refer to [1]. Also, [2] suggests an extension to = the E-Model [2] to support changing qualities. 2. The event of changing the codec/coding mode might introduce = additional distortions. We can distinguish three cases: a. Changing of the bit rate, e.g. changing the frame size in = CELT, the bitpool value SBC and the coding rate in AMR/AMR-WB: I did not = found any listening-test results that there is any impairment beyond = those described in point 1. For example, it has been proven that CELT = AND AMR do support the seamless switching between coding modes. b. Changes in the packet rate might require a rescheduling of the = playout time because of the changed packetization delay. The resulting = time stretching or time compression might introduce additional = distortions. Refer to e.g. [3].=20 c. Switching between two different codecs or switching the = sampling rate of a codec (e.g. 16 to 48 kHz in case of SBC, 32 to 48 kHz = in case of CELT, or between AMR-NB and AMR-WB) introduces distortions = caused by the needed synchronization of the decoder. Refer to [4] and = [5] for listening-tests in case of G.711 and G.722.2. In these = publications they noticed a notable distortion caused by switching = between wideband and narrowband. You hear them especially well if other = transmission conditions are good (e.g. no packet losses) All these switching events might be concealed via various technical = approaches. However, I did not found any publications or patents on it - = deeper literature survey might be required. To conclude, we can state that it is important that the system supports = the seamless of codecs or coding modes. If not, the distortion will be = quite notable. =20 Christian =20 [1] AD Clark, "Modeling the effects of burst packet loss and recency on = subjective voice quality = ", = Proc. IP Telephony Workshop, 2001 for details. [2] Lewcio, B., W=E4ltermann, M., M=F6ller, S., Vidales, P. (2009). = "E-model supported Switching between Narrowband and Wideband Speech = Quality". In: Proc. 1st Int. IEEE Workshop on Quality of Multimedia = Experience (QoMEX '09), 29-31 July, US-San Diego CA. [3] Y. J. Liang, N. F=E4rber, and B. Girod, "Adaptive playout = scheduling and loss concealment for voice communication over IP = networks," IEEE Transactions on Multimedia, vol. 5, no. 4, pp. 532-543, = Dec. 2003. [4] Lewcio, B., M=F6ller, S. ,Vidales,P. W=E4ltermann, M.,Kirschnick, = N. (2008). Methods for multimedia service adaptation in Next Generation = Networks, in Proceedings of the ETSI STQ 2008 Workshop on Effects of = Transmission Performance on Multimedia QoS,CZ-Prague, 17-19 June. [5] M=F6ller, S., W=E4ltermann, M., Lewcio, B., Kirschnick, N., = Vidales, P. (2008). Handovers between Narrowband and Wideband Speech = Transmission, in: Sprachkommunikation 2008. Beitr=E4ge der 8. = ITG-Fachtagung vom 8. bis 10. Oktober 2008 in Aachen, ITG-Fachbericht = 211, VDE-Verlag, DE-Berlin. =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 ------_=_NextPart_001_01CA5C84.DF9217E1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Please note the observation that AMR and AMR-WB = does not=20 give any switching artifacts when switching between codec modes. In fact = the=20 whole idea with AMR (Adaptive MultiRate) is to be able to freely switch = between=20 codec rates without artifacts.
 
Regards
Ingemar

From: Christian Hoene=20 [mailto:hoene@uni-tuebingen.de]
Sent: den 3 november 2009=20 10:30
To: codec@ietf.org
Subject: [codec] = Switching codecs=20 and coding mode.

Hello, =

 

Last week we had a discussion = on the=20 impact of switching between codecs and between coding modes. I made a = short=20 review of related work to understand the current state of the art. = Actually,=20 we have to distinguish multiple different = effects.

1.      =20 The first is based = on the fact=20 that in case of mode or coding switching a segment of speech consists = of parts=20 having good quality and parts having bad quality. The question arises = on how=20 the overall quality is judged. Some pioneering studies in this field = have been=20 made by AD Clark =96 not in the case of switching the codecs/coding = mode but for=20 changing loss rates. Refer to [1]. Also, [2] suggests an extension to = the=20 E-Model [2] to support changing qualities.

2.      =20 The event of = changing the=20 codec/coding mode might introduce additional distortions. We can = distinguish=20 three cases:

a.      =20 Changing of the bit = rate, e.g.=20 changing the frame size in CELT, the bitpool value SBC and the coding = rate in=20 AMR/AMR-WB: I did not found any listening-test results that there is = any=20 impairment beyond those described in point 1. For example, it has been = proven=20 that CELT AND AMR do support the seamless switching between coding=20 modes.

b.     =20 Changes in the = packet rate=20 might require a rescheduling of the playout time because of the = changed=20 packetization delay. The resulting time stretching or time compression = might=20 introduce additional distortions. Refer to e.g. [3]. =

c.      =20 Switching between = two=20 different codecs or switching the sampling rate of a codec (e.g. 16 to = 48 kHz=20 in case of SBC, 32 to 48 kHz in case of CELT, or between AMR-NB and = AMR-WB)=20 introduces distortions caused by the needed synchronization of the = decoder.=20 Refer to [4] and [5] for listening-tests in case of G.711 and G.722.2. = In=20 these publications they noticed a notable distortion caused by = switching=20 between wideband and narrowband. You hear them especially well if = other=20 transmission conditions are good (e.g. no packet = losses)

All these switching events = might be=20 concealed via various technical approaches. However, I did not found = any=20 publications or patents on it =96 deeper literature survey might be=20 required.

To conclude, we can state that = it is=20 important that the system supports the seamless of codecs or coding = modes. If=20 not, the distortion will be quite notable.

 

Christian

 

[1] AD Clark, =84Modeling the = effects of burst=20 packet loss and recency on subjective voice quality=93, = Proc. IP=20 Telephony Workshop, 2001 for details.

[2] Lewcio, B., W=E4ltermann, = M., M=F6ller,=20 S., Vidales, P. (2009). "E-model supported = Switching=20 between Narrowband and Wideband Speech Quality". In: Proc. 1st Int. = IEEE=20 Workshop on Quality of Multimedia Experience (QoMEX '09), 29-31 July, = US-San=20 Diego CA.

[3] Y. J. Liang, N. F=E4rber, = and B. Girod,=20 =93Adaptive playout scheduling and loss concealment for voice = communication over=20 IP networks,=94 IEEE Transactions on Multimedia, vol. 5, no. 4, pp. = 532=96543,=20 Dec. 2003.

[4] Lewcio, B., M=F6ller, S. ,Vidales,P. = W=E4ltermann,=20 M.,Kirschnick, N. (2008). Methods for multimedia = service=20 adaptation in Next Generation Networks, = in=20 Proceedings of the ETSI STQ 2008 Workshop on Effects of Transmission=20 Performance on Multimedia QoS,CZ-Prague, 17-19 = June.

[5] M=F6ller, S., W=E4ltermann, M., Lewcio, B., = Kirschnick, N.,=20 Vidales, P. (2008). Handovers between = Narrowband and=20 Wideband Speech Transmission, in: Sprachkommunikation = 2008.=20 Beitr=E4ge der 8. ITG-Fachtagung vom 8. bis 10. Oktober 2008 in = Aachen,=20 ITG-Fachbericht 211, VDE-Verlag, DE-Berlin.

 

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

Dr.-Ing. Christian=20 Hoene

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

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

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

 

------_=_NextPart_001_01CA5C84.DF9217E1-- From mramalho@cisco.com Tue Nov 3 07:33: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 642E23A6832 for ; Tue, 3 Nov 2009 07:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 bDNQFjwtFP3b for ; Tue, 3 Nov 2009 07:33:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1CB153A6830 for ; Tue, 3 Nov 2009 07:33:34 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEGAPvb70qtJV2c/2dsb2JhbAAHxmuYB4Q9BA X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="66173215" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2009 15:33:54 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id nA3FXrXb008541; Tue, 3 Nov 2009 15:33:54 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, 3 Nov 2009 10:33:53 -0500 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, 3 Nov 2009 10:33:56 -0500 Message-ID: In-Reply-To: <00a801ca5c68$5d5ef9a0$181cece0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/Q References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <00a801ca5c68$5d5ef9a0$181cece0$@de> From: "Michael Ramalho (mramalho)" To: "Christian Hoene" , X-OriginalArrivalTime: 03 Nov 2009 15:33:53.0979 (UTC) FILETIME=[0CE968B0:01CA5C9B] Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 15:33:35 -0000 Hi Christian, My replies are in-line below (w/ MAR:). Thanks for your consideration. Michael Ramalho -----Original Message----- From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Tuesday, November 03, 2009 4:30 AM To: Michael Ramalho (mramalho); codec@ietf.org Subject: RE: [codec] questions to be answered Hello Michael, > At a minimum, I see two legitimate codec classes: >=20 > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and >=20 > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing,=20 High-quality mixing? That do you have in mind? Stereo or binaural (3D = sound) mixing? MAR: I continued in the email to say that I could potentially think of = lots of other examples that require some bounds on the linear distortion = because of the signal processing desired at the receiver. But yes, one = could conceive of mixing to reproduce the effect of where spatially the = sound came from in the sending location using only the signals rendered = at the receiver. > many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. You may add distributed speech recognition to the second class. However, = to my understanding the current offered codecs have not been designed with = the second class in mind. MAR: Precisely. I am purposely not limiting my thinking to the current = offered codecs. MAR: Please note that I am not proposing Class 2 work at this time ... = my point is that some organization in the future could advocate such in = the future and NOT burden the present "Class 1" codec work with (what I = believe are) unnecessary requirements. MAR: Personally, I think there will be a need for Class 2 codecs soon = ... but I think it is most important NOT to burden the present work with = "low-runner" or "special-application" requirements. The whole point of = my dissertation was that one codec cannot fit "all Internet = applications". We should focus first on what the WG feels is the most = pressing application - a bandwidth efficient, Internet-friendly, = human-consumable codec. This codec is likely to be model-based. If = someone has a "pet requirement" outside the general Class 1 codec = consensus - let them propose a use case (which would include a market = need statement) and let the WG consider whether that "pet requirement" = should be included in our first work or left for another day. Also, class 2 might not fall in the interactive category (which implies that communication takes place between humans). By the way, are you training your classification-based applications = while taking the distortions caused by the transmission system into = consideration? MAR: If the application is not real-time interaction ... we would send = via reliable protocols ... and such a codec need not be as robust to = packet loss. MAR: Again I am not advocating a Class 2 codec at this time ... but = apparently you are knowledgeable about matched training/testing = conditions for ASR systems and the like. You forgot: We need to add CLASS 3 for video and CLASS 4 for general content, too. MAR: No, I didn't. I'll let someone who has convinced the WG chairs of a = market need, a use case, proposed requirements for any additional = classes to be considered. I would hope that a very limited number of = codecs are developed (see next paragraph). > Granted, we should make each use case as broad as possible so as not = to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to = go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). Yes, actually Noll and Jayant have proposed to use =B5-Law to support = speech, audio MAR: This is patently false if you consider audio to have content above = 4 kHz. All natural signals with finite energy (a guitar string pluck, a = glottal speech pulse) have a spectral roll-off with increasing frequency = (e.g., speech has approximately a 6 dB roll-off per octave). G.711 has a = flat distortion characteristic with frequency. This means if you go out = far enough in frequency (depends on the signal) your SNR turns negative = at some point. I have personally interacted with Dr. Jayant at Bell Labs = Murray Hill and I can assure you that he would NOT advocate G.711 for = other than a narrowband speech audio application. AND video compression. MAR: Definitely false ... but would require too long an explanation = (luminance related) ;-). I can't tell if you sarcastic-mode is set to = on. But to my understanding it is common consensus to concentrate on a limited (e.g. class 1) scenario and finished this = work first before setting up another construction site. MAR: And that is, in essence, my proposal - except I have a tweak. If = you have a "pet requirement", I (personally) don't want it to bugger-up = the process of getting to a good a bandwidth efficient, = Internet-friendly, human-consumable codec. Christian From mknappe@juniper.net Tue Nov 3 08:42: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 E2C783A68A8 for ; Tue, 3 Nov 2009 08:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 hZO6ZVKFeDxn for ; Tue, 3 Nov 2009 08:42:30 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 901633A6832 for ; Tue, 3 Nov 2009 08:42:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBdhLdWEQqJ0eM4i+GiuJO6i/+ozT2g@postini.com; Tue, 03 Nov 2009 08:42:51 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 3 Nov 2009 08:40:19 -0800 From: Michael Knappe To: "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Tue, 3 Nov 2009 08:40:18 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERg= Message-ID: <05542EC42316164383B5180707A489EE1D031D3D11@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 16:42:33 -0000 As I've been preparing the 'application vs. criteria matrix', it's become c= lear that video-centric applications like telepresence will have audio code= cs that are at least partially tied to or driven by characteristics of the = video coding (e.g. frame size). Do we as a group want to tackle additional = non-voice considerations in the WG? Agree with MAR on G.711, logarithmic encoding with a relatively fixed SNR d= oesn't cut it for monotonically decreasing frequency content sources like s= peech beyond 3 kHz. That's why G.722 went with a simple two-band approach f= or better representation of the upper octave, and there are of course many = examples today of sub-band approaches. Mike ----- Original Message ----- From: codec-bounces@ietf.org To: Christian Hoene ; codec@ietf.org Sent: Tue Nov 03 10:33:56 2009=0A= Subject: Re: [codec] questions to be answered Hi Christian, My replies are in-line below (w/ MAR:). Thanks for your consideration. Michael Ramalho -----Original Message----- From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Tuesday, November 03, 2009 4:30 AM To: Michael Ramalho (mramalho); codec@ietf.org Subject: RE: [codec] questions to be answered Hello Michael, > At a minimum, I see two legitimate codec classes: >=20 > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and >=20 > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing,=20 High-quality mixing? That do you have in mind? Stereo or binaural (3D sound= ) mixing? MAR: I continued in the email to say that I could potentially think of lots= of other examples that require some bounds on the linear distortion becaus= e of the signal processing desired at the receiver. But yes, one could conc= eive of mixing to reproduce the effect of where spatially the sound came fr= om in the sending location using only the signals rendered at the receiver. > many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. You may add distributed speech recognition to the second class. However, to my understanding the current offered codecs have not been designed with the second class in mind. MAR: Precisely. I am purposely not limiting my thinking to the current offe= red codecs. MAR: Please note that I am not proposing Class 2 work at this time ... my p= oint is that some organization in the future could advocate such in the fut= ure and NOT burden the present "Class 1" codec work with (what I believe ar= e) unnecessary requirements. MAR: Personally, I think there will be a need for Class 2 codecs soon ... b= ut I think it is most important NOT to burden the present work with "low-ru= nner" or "special-application" requirements. The whole point of my disserta= tion was that one codec cannot fit "all Internet applications". We should f= ocus first on what the WG feels is the most pressing application - a bandwi= dth efficient, Internet-friendly, human-consumable codec. This codec is lik= ely to be model-based. If someone has a "pet requirement" outside the gener= al Class 1 codec consensus - let them propose a use case (which would inclu= de a market need statement) and let the WG consider whether that "pet requi= rement" should be included in our first work or left for another day. Also, class 2 might not fall in the interactive category (which implies that communication takes place between humans). By the way, are you training your classification-based applications while taking the distortions caused by the transmission system into consideration= ? MAR: If the application is not real-time interaction ... we would send via = reliable protocols ... and such a codec need not be as robust to packet los= s. MAR: Again I am not advocating a Class 2 codec at this time ... but apparen= tly you are knowledgeable about matched training/testing conditions for ASR= systems and the like. You forgot: We need to add CLASS 3 for video and CLASS 4 for general content, too. MAR: No, I didn't. I'll let someone who has convinced the WG chairs of a ma= rket need, a use case, proposed requirements for any additional classes to = be considered. I would hope that a very limited number of codecs are develo= ped (see next paragraph). > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). Yes, actually Noll and Jayant have proposed to use =B5-Law to support speec= h, audio MAR: This is patently false if you consider audio to have content above 4 k= Hz. All natural signals with finite energy (a guitar string pluck, a glotta= l speech pulse) have a spectral roll-off with increasing frequency (e.g., s= peech has approximately a 6 dB roll-off per octave). G.711 has a flat disto= rtion characteristic with frequency. This means if you go out far enough in= frequency (depends on the signal) your SNR turns negative at some point. I= have personally interacted with Dr. Jayant at Bell Labs Murray Hill and I = can assure you that he would NOT advocate G.711 for other than a narrowband= speech audio application. AND video compression. MAR: Definitely false ... but would require too long an explanation (lumina= nce related) ;-). I can't tell if you sarcastic-mode is set to on. But to my understanding it is common consensus to concentrate on a limited (e.g. class 1) scenario and finished this work first before setting up another construction site. MAR: And that is, in essence, my proposal - except I have a tweak. If you h= ave a "pet requirement", I (personally) don't want it to bugger-up the proc= ess of getting to a good a bandwidth efficient, Internet-friendly, human-co= nsumable codec. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Tue Nov 3 09:10:27 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4853A6A36 for ; Tue, 3 Nov 2009 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYTl2g3DRJGv for ; Tue, 3 Nov 2009 09:10:25 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 72C3428B797 for ; Tue, 3 Nov 2009 09:10:25 -0800 (PST) Received: by gxk28 with SMTP id 28so130219gxk.9 for ; Tue, 03 Nov 2009 09:10:43 -0800 (PST) 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=oKY91L3Uv+6XHlUB60XGtA6S9XuWt5ngGru0cAKuZrU=; b=k6XhIZh0k+ehZamMEoRbCro9vjdqrkmwub1n4HowZVSuBV9urrQbNPSb10SUBY6rb8 1u197gEC+Al90lYNnr4G3Xf/2U9auw1SxMWQ/yBD0/9HXGW902dxdU7aMOaGhChUa0Zm wskj8F62IEC0wjqYMGSpmx59SWXVVqSOI4M1g= 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=te7ipnf56HgPBbYhjvL3NBSpzgCE/ReKrkZZBJIphedqnqokpAg9G97fMhJr1HfnaA MebdgfBJMUJDySW0W0/hr0xfUVIKwxXp63GBV954InaDkNv/C228MVAtvlmgIDUQoyyM qt73fqlIqNTFhle+hQGwB7sdVSIXlN0YuePZQ= Received: by 10.103.126.7 with SMTP id d7mr90617mun.115.1257268242750; Tue, 03 Nov 2009 09:10:42 -0800 (PST) Received: from windows8d787f9 (bzq-79-176-122-242.red.bezeqint.net [79.176.122.242]) by mx.google.com with ESMTPS id e10sm1263259muf.21.2009.11.03.09.10.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Nov 2009 09:10:41 -0800 (PST) From: "Roni Even" To: "'Michael Knappe'" , , , References: <05542EC42316164383B5180707A489EE1D031D3D11@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D031D3D11@EMBX02-HQ.jnpr.net> Date: Tue, 3 Nov 2009 19:09:44 +0200 Message-ID: <4af06411.0ab6660a.34df.04c2@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: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcA== Content-Language: en-us Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 17:10:27 -0000 Mike, I am not sure what you mean by tied to video codec. I can think of the = delay which can be similar to the video. The general requirements is support for hands free, full band with = stereo support and optional 5.1 support. Current codecs used are AAC and G.719. BTW: there is a different between tele-presence with multiple codecs and hifh quality HD room systems with one video codec that provide tele-presence" experience for small rooms. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Michael Knappe > Sent: Tuesday, November 03, 2009 6:40 PM > To: mramalho@cisco.com; hoene@uni-tuebingen.de; codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > As I've been preparing the 'application vs. criteria matrix', it's > become clear that video-centric applications like telepresence will > have audio codecs that are at least partially tied to or driven by > characteristics of the video coding (e.g. frame size). Do we as a = group > want to tackle additional non-voice considerations in the WG? >=20 > Agree with MAR on G.711, logarithmic encoding with a relatively fixed > SNR doesn't cut it for monotonically decreasing frequency content > sources like speech beyond 3 kHz. That's why G.722 went with a simple > two-band approach for better representation of the upper octave, and > there are of course many examples today of sub-band approaches. >=20 > Mike >=20 >=20 > ----- Original Message ----- > From: codec-bounces@ietf.org > To: Christian Hoene ; codec@ietf.org > > Sent: Tue Nov 03 10:33:56 2009 > Subject: Re: [codec] questions to be answered >=20 > Hi Christian, >=20 > My replies are in-line below (w/ MAR:). >=20 > Thanks for your consideration. >=20 > Michael Ramalho >=20 > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Tuesday, November 03, 2009 4:30 AM > To: Michael Ramalho (mramalho); codec@ietf.org > Subject: RE: [codec] questions to be answered >=20 > Hello Michael, >=20 > > At a minimum, I see two legitimate codec classes: > > > > CLASS 1) codecs that are bandwidth efficient and sound good to = humans > > (and perhaps satisfy tendeming or tone pass-through requirements), > and > > > > CLASS 2) codecs whose output may later be processed by sophisticated > > signal processing functions (high-quality mixing, >=20 > High-quality mixing? That do you have in mind? Stereo or binaural (3D > sound) > mixing? >=20 > MAR: I continued in the email to say that I could potentially think of > lots of other examples that require some bounds on the linear > distortion because of the signal processing desired at the receiver. > But yes, one could conceive of mixing to reproduce the effect of where > spatially the sound came from in the sending location using only the > signals rendered at the receiver. >=20 > > many > > classification-based applications such as speaker/sound/intrusion > > identification) that have SNR/waveform/distortion criteria generally > > exceeding CLASS 1. >=20 > You may add distributed speech recognition to the second class. > However, to > my understanding the current offered codecs have not been designed = with > the > second class in mind. >=20 > MAR: Precisely. I am purposely not limiting my thinking to the current > offered codecs. >=20 > MAR: Please note that I am not proposing Class 2 work at this time ... > my point is that some organization in the future could advocate such = in > the future and NOT burden the present "Class 1" codec work with (what = I > believe are) unnecessary requirements. >=20 > MAR: Personally, I think there will be a need for Class 2 codecs soon > ... but I think it is most important NOT to burden the present work > with "low-runner" or "special-application" requirements. The whole > point of my dissertation was that one codec cannot fit "all Internet > applications". We should focus first on what the WG feels is the most > pressing application - a bandwidth efficient, Internet-friendly, = human- > consumable codec. This codec is likely to be model-based. If someone > has a "pet requirement" outside the general Class 1 codec consensus - > let them propose a use case (which would include a market need > statement) and let the WG consider whether that "pet requirement" > should be included in our first work or left for another day. >=20 > Also, class 2 might not fall in the interactive > category (which implies that communication takes place between = humans). > By the way, are you training your classification-based applications > while > taking the distortions caused by the transmission system into > consideration? >=20 > MAR: If the application is not real-time interaction ... we would send > via reliable protocols ... and such a codec need not be as robust to > packet loss. >=20 > MAR: Again I am not advocating a Class 2 codec at this time ... but > apparently you are knowledgeable about matched training/testing > conditions for ASR systems and the like. >=20 > You forgot: We need to add CLASS 3 for video and CLASS 4 for general > content, too. >=20 > MAR: No, I didn't. I'll let someone who has convinced the WG chairs of > a market need, a use case, proposed requirements for any additional > classes to be considered. I would hope that a very limited number of > codecs are developed (see next paragraph). >=20 > > Granted, we should make each use case as broad as possible so as not > to > > have too many of them. Once one codec is standardized for a > particular > > application type - a subsequent candidate codec/application would > need > > to prove it is "sufficiently different" from the existing codec(s) = to > go > > further. The WG chairs need to exert leadership to ensure the = desired > > result (of the smallest number of codecs spanning the greatest > > application space). >=20 > Yes, actually Noll and Jayant have proposed to use =B5-Law to support > speech, > audio >=20 > MAR: This is patently false if you consider audio to have content = above > 4 kHz. All natural signals with finite energy (a guitar string pluck, = a > glottal speech pulse) have a spectral roll-off with increasing > frequency (e.g., speech has approximately a 6 dB roll-off per octave). > G.711 has a flat distortion characteristic with frequency. This means > if you go out far enough in frequency (depends on the signal) your SNR > turns negative at some point. I have personally interacted with Dr. > Jayant at Bell Labs Murray Hill and I can assure you that he would NOT > advocate G.711 for other than a narrowband speech audio application. >=20 > AND video compression. >=20 > MAR: Definitely false ... but would require too long an explanation > (luminance related) ;-). I can't tell if you sarcastic-mode is set to > on. >=20 > But to my understanding it is common consensus > to concentrate on a limited (e.g. class 1) scenario and finished this > work > first before setting up another construction site. >=20 > MAR: And that is, in essence, my proposal - except I have a tweak. If > you have a "pet requirement", I (personally) don't want it to = bugger-up > the process of getting to a good a bandwidth efficient, Internet- > friendly, human-consumable codec. >=20 > Christian >=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 br@brianrosen.net Tue Nov 3 09:23: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 F01913A6A44 for ; Tue, 3 Nov 2009 09:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 VxN7qvdL16SR for ; Tue, 3 Nov 2009 09:23:12 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 81DED3A6A41 for ; Tue, 3 Nov 2009 09:23:12 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N5N6H-0001pE-CG; Tue, 03 Nov 2009 11:23:21 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Nov 2009 12:23:20 -0400 From: Brian Rosen To: Roni Even , 'Michael Knappe' , , , Message-ID: Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAAme77 In-Reply-To: <4af06411.0ab6660a.34df.04c2@mx.google.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 17:23:14 -0000 Right, and the codec doesn't have anything special to match the delay: that's done elsewhere. Similarly, there is need for stereo and 5.1 acoustic echo cancel, but that'= s not part of the codec either, although we sometimes get tempted to put some cues in the stream to help the echo cancellation. There is no attempt to match frame sizes or anything else. You match delay to get lip sync right. Everything else is pretty independent. Of course, you have to keep the delay low ("low" in video terms): under 150 ms one way end to end, including any mixers. That's usually easy for the audio, hard for the video, so you artificially delay the audio to match the video. Brian On 11/3/09 1:09 PM, "Roni Even" wrote: > Mike, I am not sure what you mean by tied to video codec. I can think of the > delay which can be similar to the video. The general requirements is support > for hands free, full band with stereo support and optional 5.1 > support. Current codecs used are AAC and G.719. BTW: there is a different > between tele-presence with multiple codecs and hifh quality HD room systems > with one video codec that provide tele-presence" experience for small > rooms. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On Behalf > Of Michael Knappe > Sent: Tuesday, > November 03, 2009 6:40 PM > To: mramalho@cisco.com; hoene@uni-tuebingen.de; > codec@ietf.org > Subject: Re: [codec] questions to be answered > > As I've > been preparing the 'application vs. criteria matrix', it's > become clear that > video-centric applications like telepresence will > have audio codecs that are > at least partially tied to or driven by > characteristics of the video coding > (e.g. frame size). Do we as a group > want to tackle additional non-voice > considerations in the WG? > > Agree with MAR on G.711, logarithmic encoding > with a relatively fixed > SNR doesn't cut it for monotonically decreasing > frequency content > sources like speech beyond 3 kHz. That's why G.722 went > with a simple > two-band approach for better representation of the upper > octave, and > there are of course many examples today of sub-band > approaches. > > Mike > > > ----- Original Message ----- > From: > codec-bounces@ietf.org > To: Christian Hoene > ; codec@ietf.org > > Sent: Tue Nov 03 > 10:33:56 2009 > Subject: Re: [codec] questions to be answered > > Hi > Christian, > > My replies are in-line below (w/ MAR:). > > Thanks for your > consideration. > > Michael Ramalho > > -----Original Message----- > From: > Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Tuesday, November 03, > 2009 4:30 AM > To: Michael Ramalho (mramalho); codec@ietf.org > Subject: RE: > [codec] questions to be answered > > Hello Michael, > > > At a minimum, I > see two legitimate codec classes: > > > > CLASS 1) codecs that are bandwidth > efficient and sound good to humans > > (and perhaps satisfy tendeming or tone > pass-through requirements), > and > > > > CLASS 2) codecs whose output may > later be processed by sophisticated > > signal processing functions > (high-quality mixing, > > High-quality mixing? That do you have in mind? > Stereo or binaural (3D > sound) > mixing? > > MAR: I continued in the email > to say that I could potentially think of > lots of other examples that require > some bounds on the linear > distortion because of the signal processing > desired at the receiver. > But yes, one could conceive of mixing to reproduce > the effect of where > spatially the sound came from in the sending location > using only the > signals rendered at the receiver. > > > many > > > classification-based applications such as speaker/sound/intrusion > > > identification) that have SNR/waveform/distortion criteria generally > > > exceeding CLASS 1. > > You may add distributed speech recognition to the > second class. > However, to > my understanding the current offered codecs have > not been designed with > the > second class in mind. > > MAR: Precisely. I am > purposely not limiting my thinking to the current > offered codecs. > > MAR: > Please note that I am not proposing Class 2 work at this time ... > my point > is that some organization in the future could advocate such in > the future > and NOT burden the present "Class 1" codec work with (what I > believe are) > unnecessary requirements. > > MAR: Personally, I think there will be a need > for Class 2 codecs soon > ... but I think it is most important NOT to burden > the present work > with "low-runner" or "special-application" requirements. > The whole > point of my dissertation was that one codec cannot fit "all > Internet > applications". We should focus first on what the WG feels is the > most > pressing application - a bandwidth efficient, Internet-friendly, > human- > consumable codec. This codec is likely to be model-based. If > someone > has a "pet requirement" outside the general Class 1 codec consensus > - > let them propose a use case (which would include a market need > > statement) and let the WG consider whether that "pet requirement" > should be > included in our first work or left for another day. > > Also, class 2 might > not fall in the interactive > category (which implies that communication takes > place between humans). > By the way, are you training your > classification-based applications > while > taking the distortions caused by > the transmission system into > consideration? > > MAR: If the application is > not real-time interaction ... we would send > via reliable protocols ... and > such a codec need not be as robust to > packet loss. > > MAR: Again I am not > advocating a Class 2 codec at this time ... but > apparently you are > knowledgeable about matched training/testing > conditions for ASR systems and > the like. > > You forgot: We need to add CLASS 3 for video and CLASS 4 for > general > content, too. > > MAR: No, I didn't. I'll let someone who has > convinced the WG chairs of > a market need, a use case, proposed requirements > for any additional > classes to be considered. I would hope that a very > limited number of > codecs are developed (see next paragraph). > > > Granted, > we should make each use case as broad as possible so as not > to > > have too > many of them. Once one codec is standardized for a > particular > > > application type - a subsequent candidate codec/application would > need > > > to prove it is "sufficiently different" from the existing codec(s) to > go > > > further. The WG chairs need to exert leadership to ensure the desired > > > result (of the smallest number of codecs spanning the greatest > > application > space). > > Yes, actually Noll and Jayant have proposed to use =B5-Law to > support > speech, > audio > > MAR: This is patently false if you consider > audio to have content above > 4 kHz. All natural signals with finite energy (a > guitar string pluck, a > glottal speech pulse) have a spectral roll-off with > increasing > frequency (e.g., speech has approximately a 6 dB roll-off per > octave). > G.711 has a flat distortion characteristic with frequency. This > means > if you go out far enough in frequency (depends on the signal) your > SNR > turns negative at some point. I have personally interacted with Dr. > > Jayant at Bell Labs Murray Hill and I can assure you that he would NOT > > advocate G.711 for other than a narrowband speech audio application. > > AND > video compression. > > MAR: Definitely false ... but would require too long > an explanation > (luminance related) ;-). I can't tell if you sarcastic-mode > is set to > on. > > But to my understanding it is common consensus > to > concentrate on a limited (e.g. class 1) scenario and finished this > work > > first before setting up another construction site. > > MAR: And that is, in > essence, my proposal - except I have a tweak. If > you have a "pet > requirement", I (personally) don't want it to bugger-up > the process of > getting to a good a bandwidth efficient, Internet- > friendly, > human-consumable codec. > > Christian > > > > _______________________________________________ > codec mailing list > > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > > codec@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/codec _________________________________ > ______________ codec mailing > list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Tue Nov 3 09:38: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 975813A6A57 for ; Tue, 3 Nov 2009 09:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 CKsAhtmJfuOp for ; Tue, 3 Nov 2009 09:38:44 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 1269D3A68E0 for ; Tue, 3 Nov 2009 09:38:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBqsBDGK9W49QywTfwgsIqWTZf3IFIN@postini.com; Tue, 03 Nov 2009 09:39:05 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 3 Nov 2009 09:33:38 -0800 From: Michael Knappe To: "ron.even.tlv@gmail.com" , "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Tue, 3 Nov 2009 09:33:37 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAA9V5h Message-ID: <05542EC42316164383B5180707A489EE1D031D3D15@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 17:38:45 -0000 Frame size is the first thing that came to mind, but I was unsure as if the= re may be other considerations that I was unaware of for video and was hopi= ng for some feedback there. Obviously you could pack and synchronize multiple short audio frames along = with a longer duration video frame, but a codec with potential compression = quality improvements with longer lookahead audio frames could take better a= dvantage of the allowed video framing time. This is just an example to explore Michael Ramalho's discussion of how far= we should go to accomodate different application spaces. Roni, for clarification, can you elaborate further on your 'BTW...' discuss= ion of different telepresence codecs below? Thanks. Cheers, Mike ----- Original Message ----- From: Roni Even To: Michael Knappe; mramalho@cisco.com ; hoene@uni-tueb= ingen.de ; codec@ietf.org Sent: Tue Nov 03 12:09:44 2009=0A= Subject: RE: [codec] questions to be answered Mike, I am not sure what you mean by tied to video codec. I can think of the dela= y which can be similar to the video. The general requirements is support for hands free, full band with stereo support and optional 5.1 support. Current codecs used are AAC and G.719. BTW: there is a different between tele-presence with multiple codecs and hifh quality HD room systems with one video codec that provide tele-presence" experience for small rooms. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Michael Knappe > Sent: Tuesday, November 03, 2009 6:40 PM > To: mramalho@cisco.com; hoene@uni-tuebingen.de; codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > As I've been preparing the 'application vs. criteria matrix', it's > become clear that video-centric applications like telepresence will > have audio codecs that are at least partially tied to or driven by > characteristics of the video coding (e.g. frame size). Do we as a group > want to tackle additional non-voice considerations in the WG? >=20 > Agree with MAR on G.711, logarithmic encoding with a relatively fixed > SNR doesn't cut it for monotonically decreasing frequency content > sources like speech beyond 3 kHz. That's why G.722 went with a simple > two-band approach for better representation of the upper octave, and > there are of course many examples today of sub-band approaches. >=20 > Mike >=20 >=20 > ----- Original Message ----- > From: codec-bounces@ietf.org > To: Christian Hoene ; codec@ietf.org > > Sent: Tue Nov 03 10:33:56 2009 > Subject: Re: [codec] questions to be answered >=20 > Hi Christian, >=20 > My replies are in-line below (w/ MAR:). >=20 > Thanks for your consideration. >=20 > Michael Ramalho >=20 > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Tuesday, November 03, 2009 4:30 AM > To: Michael Ramalho (mramalho); codec@ietf.org > Subject: RE: [codec] questions to be answered >=20 > Hello Michael, >=20 > > At a minimum, I see two legitimate codec classes: > > > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > > (and perhaps satisfy tendeming or tone pass-through requirements), > and > > > > CLASS 2) codecs whose output may later be processed by sophisticated > > signal processing functions (high-quality mixing, >=20 > High-quality mixing? That do you have in mind? Stereo or binaural (3D > sound) > mixing? >=20 > MAR: I continued in the email to say that I could potentially think of > lots of other examples that require some bounds on the linear > distortion because of the signal processing desired at the receiver. > But yes, one could conceive of mixing to reproduce the effect of where > spatially the sound came from in the sending location using only the > signals rendered at the receiver. >=20 > > many > > classification-based applications such as speaker/sound/intrusion > > identification) that have SNR/waveform/distortion criteria generally > > exceeding CLASS 1. >=20 > You may add distributed speech recognition to the second class. > However, to > my understanding the current offered codecs have not been designed with > the > second class in mind. >=20 > MAR: Precisely. I am purposely not limiting my thinking to the current > offered codecs. >=20 > MAR: Please note that I am not proposing Class 2 work at this time ... > my point is that some organization in the future could advocate such in > the future and NOT burden the present "Class 1" codec work with (what I > believe are) unnecessary requirements. >=20 > MAR: Personally, I think there will be a need for Class 2 codecs soon > ... but I think it is most important NOT to burden the present work > with "low-runner" or "special-application" requirements. The whole > point of my dissertation was that one codec cannot fit "all Internet > applications". We should focus first on what the WG feels is the most > pressing application - a bandwidth efficient, Internet-friendly, human- > consumable codec. This codec is likely to be model-based. If someone > has a "pet requirement" outside the general Class 1 codec consensus - > let them propose a use case (which would include a market need > statement) and let the WG consider whether that "pet requirement" > should be included in our first work or left for another day. >=20 > Also, class 2 might not fall in the interactive > category (which implies that communication takes place between humans). > By the way, are you training your classification-based applications > while > taking the distortions caused by the transmission system into > consideration? >=20 > MAR: If the application is not real-time interaction ... we would send > via reliable protocols ... and such a codec need not be as robust to > packet loss. >=20 > MAR: Again I am not advocating a Class 2 codec at this time ... but > apparently you are knowledgeable about matched training/testing > conditions for ASR systems and the like. >=20 > You forgot: We need to add CLASS 3 for video and CLASS 4 for general > content, too. >=20 > MAR: No, I didn't. I'll let someone who has convinced the WG chairs of > a market need, a use case, proposed requirements for any additional > classes to be considered. I would hope that a very limited number of > codecs are developed (see next paragraph). >=20 > > Granted, we should make each use case as broad as possible so as not > to > > have too many of them. Once one codec is standardized for a > particular > > application type - a subsequent candidate codec/application would > need > > to prove it is "sufficiently different" from the existing codec(s) to > go > > further. The WG chairs need to exert leadership to ensure the desired > > result (of the smallest number of codecs spanning the greatest > > application space). >=20 > Yes, actually Noll and Jayant have proposed to use =B5-Law to support > speech, > audio >=20 > MAR: This is patently false if you consider audio to have content above > 4 kHz. All natural signals with finite energy (a guitar string pluck, a > glottal speech pulse) have a spectral roll-off with increasing > frequency (e.g., speech has approximately a 6 dB roll-off per octave). > G.711 has a flat distortion characteristic with frequency. This means > if you go out far enough in frequency (depends on the signal) your SNR > turns negative at some point. I have personally interacted with Dr. > Jayant at Bell Labs Murray Hill and I can assure you that he would NOT > advocate G.711 for other than a narrowband speech audio application. >=20 > AND video compression. >=20 > MAR: Definitely false ... but would require too long an explanation > (luminance related) ;-). I can't tell if you sarcastic-mode is set to > on. >=20 > But to my understanding it is common consensus > to concentrate on a limited (e.g. class 1) scenario and finished this > work > first before setting up another construction site. >=20 > MAR: And that is, in essence, my proposal - except I have a tweak. If > you have a "pet requirement", I (personally) don't want it to bugger-up > the process of getting to a good a bandwidth efficient, Internet- > friendly, human-consumable codec. >=20 > Christian >=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 mknappe@juniper.net Tue Nov 3 09:49: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 CE5513A6ACB for ; Tue, 3 Nov 2009 09:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 dlrbRez-h5J1 for ; Tue, 3 Nov 2009 09:49:54 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 2AF8B3A6AC9 for ; Tue, 3 Nov 2009 09:49:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBtSrY5kgWA3penZF4TeEWdhQCrET4b@postini.com; Tue, 03 Nov 2009 09:50:15 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 Nov 2009 09:46:56 -0800 From: Michael Knappe To: "br@brianrosen.net" , "ron.even.tlv@gmail.com" , "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Tue, 3 Nov 2009 09:46:56 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAAme77AADSXP8= Message-ID: <05542EC42316164383B5180707A489EE1D031D3D17@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 17:49:55 -0000 Agreed, thanks. One quick note on the 150 ms end-to-end requirement. That is a general rule= -of-thumb (and ITU specified) requirement for interactive speech responsive= ness and ease of conversation, but one that digging deeper is dependent on = language, cultural, and use case factors. There are conference situations w= hich are more forgiving to longer delays, and conversely language types tha= t require tighter delay to avoid emotional misinterpretation of verbal ackn= owledgements.=20 Mike ----- Original Message ----- From: Brian Rosen To: Roni Even ; Michael Knappe; mramalho@cisco.com = ; hoene@uni-tuebingen.de ; code= c@ietf.org Sent: Tue Nov 03 11:23:20 2009=0A= Subject: Re: [codec] questions to be answered Right, and the codec doesn't have anything special to match the delay: that's done elsewhere. Similarly, there is need for stereo and 5.1 acoustic echo cancel, but that'= s not part of the codec either, although we sometimes get tempted to put some cues in the stream to help the echo cancellation. There is no attempt to match frame sizes or anything else. You match delay to get lip sync right. Everything else is pretty independent. Of course, you have to keep the delay low ("low" in video terms): under 150 ms one way end to end, including any mixers. That's usually easy for the audio, hard for the video, so you artificially delay the audio to match the video. Brian On 11/3/09 1:09 PM, "Roni Even" wrote: > Mike, I am not sure what you mean by tied to video codec. I can think of the > delay which can be similar to the video. The general requirements is support > for hands free, full band with stereo support and optional 5.1 > support. Current codecs used are AAC and G.719. BTW: there is a different > between tele-presence with multiple codecs and hifh quality HD room systems > with one video codec that provide tele-presence" experience for small > rooms. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On Behalf > Of Michael Knappe > Sent: Tuesday, > November 03, 2009 6:40 PM > To: mramalho@cisco.com; hoene@uni-tuebingen.de; > codec@ietf.org > Subject: Re: [codec] questions to be answered >=20 > As I've > been preparing the 'application vs. criteria matrix', it's > become clear that > video-centric applications like telepresence will > have audio codecs that are > at least partially tied to or driven by > characteristics of the video coding > (e.g. frame size). Do we as a group > want to tackle additional non-voice > considerations in the WG? >=20 > Agree with MAR on G.711, logarithmic encoding > with a relatively fixed > SNR doesn't cut it for monotonically decreasing > frequency content > sources like speech beyond 3 kHz. That's why G.722 went > with a simple > two-band approach for better representation of the upper > octave, and > there are of course many examples today of sub-band > approaches. >=20 > Mike >=20 >=20 > ----- Original Message ----- > From: > codec-bounces@ietf.org > To: Christian Hoene > ; codec@ietf.org > > Sent: Tue Nov 03 > 10:33:56 2009 > Subject: Re: [codec] questions to be answered >=20 > Hi > Christian, >=20 > My replies are in-line below (w/ MAR:). >=20 > Thanks for your > consideration. >=20 > Michael Ramalho >=20 > -----Original Message----- > From: > Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Tuesday, November 03, > 2009 4:30 AM > To: Michael Ramalho (mramalho); codec@ietf.org > Subject: RE: > [codec] questions to be answered >=20 > Hello Michael, >=20 > > At a minimum, I > see two legitimate codec classes: > > > > CLASS 1) codecs that are bandwidth > efficient and sound good to humans > > (and perhaps satisfy tendeming or tone > pass-through requirements), > and > > > > CLASS 2) codecs whose output may > later be processed by sophisticated > > signal processing functions > (high-quality mixing, >=20 > High-quality mixing? That do you have in mind? > Stereo or binaural (3D > sound) > mixing? >=20 > MAR: I continued in the email > to say that I could potentially think of > lots of other examples that require > some bounds on the linear > distortion because of the signal processing > desired at the receiver. > But yes, one could conceive of mixing to reproduce > the effect of where > spatially the sound came from in the sending location > using only the > signals rendered at the receiver. >=20 > > many > > > classification-based applications such as speaker/sound/intrusion > > > identification) that have SNR/waveform/distortion criteria generally > > > exceeding CLASS 1. >=20 > You may add distributed speech recognition to the > second class. > However, to > my understanding the current offered codecs have > not been designed with > the > second class in mind. >=20 > MAR: Precisely. I am > purposely not limiting my thinking to the current > offered codecs. >=20 > MAR: > Please note that I am not proposing Class 2 work at this time ... > my point > is that some organization in the future could advocate such in > the future > and NOT burden the present "Class 1" codec work with (what I > believe are) > unnecessary requirements. >=20 > MAR: Personally, I think there will be a need > for Class 2 codecs soon > ... but I think it is most important NOT to burden > the present work > with "low-runner" or "special-application" requirements. > The whole > point of my dissertation was that one codec cannot fit "all > Internet > applications". We should focus first on what the WG feels is the > most > pressing application - a bandwidth efficient, Internet-friendly, > human- > consumable codec. This codec is likely to be model-based. If > someone > has a "pet requirement" outside the general Class 1 codec consensus > - > let them propose a use case (which would include a market need > > statement) and let the WG consider whether that "pet requirement" > should be > included in our first work or left for another day. >=20 > Also, class 2 might > not fall in the interactive > category (which implies that communication takes > place between humans). > By the way, are you training your > classification-based applications > while > taking the distortions caused by > the transmission system into > consideration? >=20 > MAR: If the application is > not real-time interaction ... we would send > via reliable protocols ... and > such a codec need not be as robust to > packet loss. >=20 > MAR: Again I am not > advocating a Class 2 codec at this time ... but > apparently you are > knowledgeable about matched training/testing > conditions for ASR systems and > the like. >=20 > You forgot: We need to add CLASS 3 for video and CLASS 4 for > general > content, too. >=20 > MAR: No, I didn't. I'll let someone who has > convinced the WG chairs of > a market need, a use case, proposed requirements > for any additional > classes to be considered. I would hope that a very > limited number of > codecs are developed (see next paragraph). >=20 > > Granted, > we should make each use case as broad as possible so as not > to > > have too > many of them. Once one codec is standardized for a > particular > > > application type - a subsequent candidate codec/application would > need > > > to prove it is "sufficiently different" from the existing codec(s) to > go > > > further. The WG chairs need to exert leadership to ensure the desired > > > result (of the smallest number of codecs spanning the greatest > > application > space). >=20 > Yes, actually Noll and Jayant have proposed to use =B5-Law to > support > speech, > audio >=20 > MAR: This is patently false if you consider > audio to have content above > 4 kHz. All natural signals with finite energy (a > guitar string pluck, a > glottal speech pulse) have a spectral roll-off with > increasing > frequency (e.g., speech has approximately a 6 dB roll-off per > octave). > G.711 has a flat distortion characteristic with frequency. This > means > if you go out far enough in frequency (depends on the signal) your > SNR > turns negative at some point. I have personally interacted with Dr. > > Jayant at Bell Labs Murray Hill and I can assure you that he would NOT > > advocate G.711 for other than a narrowband speech audio application. >=20 > AND > video compression. >=20 > MAR: Definitely false ... but would require too long > an explanation > (luminance related) ;-). I can't tell if you sarcastic-mode > is set to > on. >=20 > But to my understanding it is common consensus > to > concentrate on a limited (e.g. class 1) scenario and finished this > work > > first before setting up another construction site. >=20 > MAR: And that is, in > essence, my proposal - except I have a tweak. If > you have a "pet > requirement", I (personally) don't want it to bugger-up > the process of > getting to a good a bandwidth efficient, Internet- > friendly, > human-consumable codec. >=20 > Christian >=20 >=20 > > _______________________________________________ > codec mailing list > > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > > codec@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/codec _________________________________ > ______________ codec mailing > list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From br@brianrosen.net Tue Nov 3 10:09: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 BCC913A6A4D for ; Tue, 3 Nov 2009 10:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 KCNK2uzBciz5 for ; Tue, 3 Nov 2009 10:09:10 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 26CD53A6A4A for ; Tue, 3 Nov 2009 10:09:10 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N5Nom-0005mY-3S; Tue, 03 Nov 2009 12:09:20 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Nov 2009 13:09:24 -0400 From: Brian Rosen To: Michael Knappe , "ron.even.tlv@gmail.com" , "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Message-ID: Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAAme77AADSXP8AAMmC3A== In-Reply-To: <05542EC42316164383B5180707A489EE1D031D3D17@EMBX02-HQ.jnpr.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 18:09:11 -0000 Could you cite the research for that? We did some work in that space and discovered there were no cultural biases= ; the timing was a factor in having arguments, interruptions, or fast change of speaker, where turn taking behavior is not as controlled as it is usually. With delay longer than 150, arguments weren't possible naturally, and behavior suffered significantly. We only tested a limited range of cultural differences, but they included US/Canada, Europe and Asia. Granted, arguments in say, many Asian environments were much less common, but our work suggested that it still mattered a whole lot. Of course if th= e entire interaction is one way (a lecture with no questions), then delay is not important as long as lip sync is achieved. We did not find any advantage of having delay less than around 150. Of course, there is a range of human responses, so that 150 is a 95% or so threshold. We found the affect of delay is a cliff: once you go over the edge, you can't converse normally (under some amount of stress), and making it, say, 250ms vs 400 ms didn't help much. We noticed no difference under 100ms down to effectively zero. Lip sync was an issue, but factoring out the delay for the audio, we did no= t notice any delay issues for the video itself until it got really big (up around 1/2 sec). Then you see some artifacts. Our research (it was at Marconi, not where I am presently) was not published, but it was pretty thorough. We also concluded that delay was much more important than image quality: in our experiments, a QCIF image with low delay was preferred overwhelmingly compared to a very high quality image with lots of delay. Brian On 11/3/09 1:46 PM, "Michael Knappe" wrote: > Agreed, thanks. >=20 > One quick note on the 150 ms end-to-end requirement. That is a general > rule-of-thumb (and ITU specified) requirement for interactive speech > responsiveness and ease of conversation, but one that digging deeper is > dependent on language, cultural, and use case factors. There are conferen= ce > situations which are more forgiving to longer delays, and conversely lang= uage > types that require tighter delay to avoid emotional misinterpretation of > verbal acknowledgements. >=20 > Mike >=20 >=20 >=20 > ----- Original Message ----- > From: Brian Rosen > To: Roni Even ; Michael Knappe; mramalho@cisco.co= m > ; hoene@uni-tuebingen.de ; > codec@ietf.org > Sent: Tue Nov 03 11:23:20 2009 > Subject: Re: [codec] questions to be answered >=20 > Right, and the codec doesn't have anything special to match the delay: > that's done elsewhere. >=20 > Similarly, there is need for stereo and 5.1 acoustic echo cancel, but tha= t's > not part of the codec either, although we sometimes get tempted to put so= me > cues in the stream to help the echo cancellation. >=20 > There is no attempt to match frame sizes or anything else. You match del= ay > to get lip sync right. Everything else is pretty independent. >=20 > Of course, you have to keep the delay low ("low" in video terms): under 1= 50 > ms one way end to end, including any mixers. That's usually easy for the > audio, hard for the video, so you artificially delay the audio to match t= he > video. >=20 > Brian >=20 >=20 > On 11/3/09 1:09 PM, "Roni Even" wrote: >=20 >> Mike, > I am not sure what you mean by tied to video codec. I can think of the >> delay > which can be similar to the video. > The general requirements is support >> for hands free, full band with stereo > support and optional 5.1 >> support. > Current codecs used are AAC and G.719. > BTW: there is a different >> between tele-presence with multiple codecs and > hifh quality HD room systems >> with one video codec that provide > tele-presence" experience for small >> rooms. >=20 > Roni Even >=20 >> -----Original Message----- >> From: codec-bounces@ietf.org >> [mailto:codec-bounces@ietf.org] On Behalf >> Of Michael Knappe >> Sent: Tuesday, >> November 03, 2009 6:40 PM >> To: mramalho@cisco.com; hoene@uni-tuebingen.de; >> codec@ietf.org >> Subject: Re: [codec] questions to be answered >>=20 >> As I've >> been preparing the 'application vs. criteria matrix', it's >> become clear that >> video-centric applications like telepresence will >> have audio codecs that are >> at least partially tied to or driven by >> characteristics of the video coding >> (e.g. frame size). Do we as a group >> want to tackle additional non-voice >> considerations in the WG? >>=20 >> Agree with MAR on G.711, logarithmic encoding >> with a relatively fixed >> SNR doesn't cut it for monotonically decreasing >> frequency content >> sources like speech beyond 3 kHz. That's why G.722 went >> with a simple >> two-band approach for better representation of the upper >> octave, and >> there are of course many examples today of sub-band >> approaches. >>=20 >> Mike >>=20 >>=20 >> ----- Original Message ----- >> From: >> codec-bounces@ietf.org >> To: Christian Hoene >> ; codec@ietf.org >> >> Sent: Tue Nov 03 >> 10:33:56 2009 >> Subject: Re: [codec] questions to be answered >>=20 >> Hi >> Christian, >>=20 >> My replies are in-line below (w/ MAR:). >>=20 >> Thanks for your >> consideration. >>=20 >> Michael Ramalho >>=20 >> -----Original Message----- >> From: >> Christian Hoene [mailto:hoene@uni-tuebingen.de] >> Sent: Tuesday, November 03, >> 2009 4:30 AM >> To: Michael Ramalho (mramalho); codec@ietf.org >> Subject: RE: >> [codec] questions to be answered >>=20 >> Hello Michael, >>=20 >>> At a minimum, I >> see two legitimate codec classes: >>>=20 >>> CLASS 1) codecs that are bandwidth >> efficient and sound good to humans >>> (and perhaps satisfy tendeming or tone >> pass-through requirements), >> and >>>=20 >>> CLASS 2) codecs whose output may >> later be processed by sophisticated >>> signal processing functions >> (high-quality mixing, >>=20 >> High-quality mixing? That do you have in mind? >> Stereo or binaural (3D >> sound) >> mixing? >>=20 >> MAR: I continued in the email >> to say that I could potentially think of >> lots of other examples that require >> some bounds on the linear >> distortion because of the signal processing >> desired at the receiver. >> But yes, one could conceive of mixing to reproduce >> the effect of where >> spatially the sound came from in the sending location >> using only the >> signals rendered at the receiver. >>=20 >>> many >>>=20 >> classification-based applications such as speaker/sound/intrusion >>>=20 >> identification) that have SNR/waveform/distortion criteria generally >>>=20 >> exceeding CLASS 1. >>=20 >> You may add distributed speech recognition to the >> second class. >> However, to >> my understanding the current offered codecs have >> not been designed with >> the >> second class in mind. >>=20 >> MAR: Precisely. I am >> purposely not limiting my thinking to the current >> offered codecs. >>=20 >> MAR: >> Please note that I am not proposing Class 2 work at this time ... >> my point >> is that some organization in the future could advocate such in >> the future >> and NOT burden the present "Class 1" codec work with (what I >> believe are) >> unnecessary requirements. >>=20 >> MAR: Personally, I think there will be a need >> for Class 2 codecs soon >> ... but I think it is most important NOT to burden >> the present work >> with "low-runner" or "special-application" requirements. >> The whole >> point of my dissertation was that one codec cannot fit "all >> Internet >> applications". We should focus first on what the WG feels is the >> most >> pressing application - a bandwidth efficient, Internet-friendly, >> human- >> consumable codec. This codec is likely to be model-based. If >> someone >> has a "pet requirement" outside the general Class 1 codec consensus >> - >> let them propose a use case (which would include a market need >>=20 >> statement) and let the WG consider whether that "pet requirement" >> should be >> included in our first work or left for another day. >>=20 >> Also, class 2 might >> not fall in the interactive >> category (which implies that communication takes >> place between humans). >> By the way, are you training your >> classification-based applications >> while >> taking the distortions caused by >> the transmission system into >> consideration? >>=20 >> MAR: If the application is >> not real-time interaction ... we would send >> via reliable protocols ... and >> such a codec need not be as robust to >> packet loss. >>=20 >> MAR: Again I am not >> advocating a Class 2 codec at this time ... but >> apparently you are >> knowledgeable about matched training/testing >> conditions for ASR systems and >> the like. >>=20 >> You forgot: We need to add CLASS 3 for video and CLASS 4 for >> general >> content, too. >>=20 >> MAR: No, I didn't. I'll let someone who has >> convinced the WG chairs of >> a market need, a use case, proposed requirements >> for any additional >> classes to be considered. I would hope that a very >> limited number of >> codecs are developed (see next paragraph). >>=20 >>> Granted, >> we should make each use case as broad as possible so as not >> to >>> have too >> many of them. Once one codec is standardized for a >> particular >>>=20 >> application type - a subsequent candidate codec/application would >> need >>>=20 >> to prove it is "sufficiently different" from the existing codec(s) to >> go >>>=20 >> further. The WG chairs need to exert leadership to ensure the desired >>>=20 >> result (of the smallest number of codecs spanning the greatest >>> application >> space). >>=20 >> Yes, actually Noll and Jayant have proposed to use =B5-Law to >> support >> speech, >> audio >>=20 >> MAR: This is patently false if you consider >> audio to have content above >> 4 kHz. All natural signals with finite energy (a >> guitar string pluck, a >> glottal speech pulse) have a spectral roll-off with >> increasing >> frequency (e.g., speech has approximately a 6 dB roll-off per >> octave). >> G.711 has a flat distortion characteristic with frequency. This >> means >> if you go out far enough in frequency (depends on the signal) your >> SNR >> turns negative at some point. I have personally interacted with Dr. >>=20 >> Jayant at Bell Labs Murray Hill and I can assure you that he would NOT >>=20 >> advocate G.711 for other than a narrowband speech audio application. >>=20 >> AND >> video compression. >>=20 >> MAR: Definitely false ... but would require too long >> an explanation >> (luminance related) ;-). I can't tell if you sarcastic-mode >> is set to >> on. >>=20 >> But to my understanding it is common consensus >> to >> concentrate on a limited (e.g. class 1) scenario and finished this >> work >>=20 >> first before setting up another construction site. >>=20 >> MAR: And that is, in >> essence, my proposal - except I have a tweak. If >> you have a "pet >> requirement", I (personally) don't want it to bugger-up >> the process of >> getting to a good a bandwidth efficient, Internet- >> friendly, >> human-consumable codec. >>=20 >> Christian >>=20 >>=20 >>=20 >> _______________________________________________ >> codec mailing list >>=20 >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >> _______________________________________________ >> codec mailing list >>=20 >> codec@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/codec >=20 > _________________________________ >> ______________ > codec mailing >> list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 From jean-marc.valin@octasic.com Tue Nov 3 10:12: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 901763A68D3 for ; Tue, 3 Nov 2009 10:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qQckJIBkfEB for ; Tue, 3 Nov 2009 10:12:08 -0800 (PST) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 9F22C3A67B0 for ; Tue, 3 Nov 2009 10:12:08 -0800 (PST) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:12:28 -0500 Message-ID: <4AF0728C.7010908@octasic.com> Date: Tue, 03 Nov 2009 13:12:28 -0500 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael Knappe References: <05542EC42316164383B5180707A489EE1D031D3D11@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D031D3D11@EMBX02-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 18:12:28.0775 (UTC) FILETIME=[342C0F70:01CA5CB1] Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 18:12:09 -0000 Michael Knappe wrote: > As I've been preparing the 'application vs. criteria matrix', it's > become clear that video-centric applications like telepresence will have > audio codecs that are at least partially tied to or driven by > characteristics of the video coding (e.g. frame size). Actually, why would the frame size of the codec be related to the video codec? I don't see any valid reason for doing that and I would have a hard time imagining how one would have an audio codec with 29.97 frames per second (without using a sampling rate of 59.94 kHz). > Do we as a group > want to tackle additional non-voice considerations in the WG? (I assume you mean non-audio considerations because we definitely want to consider music here) I'm not fundamentally opposed to the idea of including non-audio considerations, but there would have to be a good reason for that. Right now I cannot see any, but I may have missed something. Jean-Marc From mknappe@juniper.net Tue Nov 3 10:53: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 AEEB028C14B for ; Tue, 3 Nov 2009 10:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 dGP4gd5b+udY for ; Tue, 3 Nov 2009 10:53:48 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B3FAA3A6892 for ; Tue, 3 Nov 2009 10:53:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSvB8R1/XG6JwUtX64fpSdFT+fl1aIQpF@postini.com; Tue, 03 Nov 2009 10:54:09 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 Nov 2009 10:50:08 -0800 From: Michael Knappe To: "br@brianrosen.net" , "ron.even.tlv@gmail.com" , "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Tue, 3 Nov 2009 10:50:08 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAAme77AADSXP8AAMmC3AABa3TZ Message-ID: <05542EC42316164383B5180707A489EE1D031D3D1A@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 18:53:49 -0000 The language sensitivity was empirical from work in early voip deployments = I was involved with in international markets. Always made an attempt to sta= y below 100 ms if at all possible. On large deployments, the 5 percent 'out= liers' become very important in terms of customer acceptance of new technol= ogy (new at the time). You could counter that since the early days of voip,= cell phone quality has changed the delay acceptability bar as well with lo= nger delays becoming more the norm. What I really like about the proposed c= odec activity is moving internet communications towards being the high-qual= ity choice (frequency range, number of channels, etc) rather than the low-c= ost quality compromise that voip began its life as. The 150 ms 'knee' was exactly that, with the impact on conversation grew in= creasingly until you hit the 'CB radio' half-duplex asymptote past the 400-= 600 ms range. Agreed that below 150 ms, the quality impact curve quickly fo= r the average listener/speaker levels out quickly. You raise an interesting= point about argumentative speech and low delay, involved multi-party confe= rence communications should keep delay as low as possible. Codec algorithmic delay is of course just a fraction of the end-to-end dela= y equation, with the relative percent contribution of network quality (both= absolute delay and jitter) increasing as you optimize codec delay. Beyond = the scope of the proposed WG, but worth keeping in mind in assessing the im= pact of codec delay on its own. Mike ----- Original Message ----- From: Brian Rosen To: Michael Knappe; ron.even.tlv@gmail.com ; mramal= ho@cisco.com ; hoene@uni-tuebingen.de ; codec@ietf.org Sent: Tue Nov 03 12:09:24 2009=0A= Subject: Re: [codec] questions to be answered Could you cite the research for that? We did some work in that space and discovered there were no cultural biases= ; the timing was a factor in having arguments, interruptions, or fast change of speaker, where turn taking behavior is not as controlled as it is usually. With delay longer than 150, arguments weren't possible naturally, and behavior suffered significantly. We only tested a limited range of cultural differences, but they included US/Canada, Europe and Asia. Granted, arguments in say, many Asian environments were much less common, but our work suggested that it still mattered a whole lot. Of course if th= e entire interaction is one way (a lecture with no questions), then delay is not important as long as lip sync is achieved. We did not find any advantage of having delay less than around 150. Of course, there is a range of human responses, so that 150 is a 95% or so threshold. We found the affect of delay is a cliff: once you go over the edge, you can't converse normally (under some amount of stress), and making it, say, 250ms vs 400 ms didn't help much. We noticed no difference under 100ms down to effectively zero. Lip sync was an issue, but factoring out the delay for the audio, we did no= t notice any delay issues for the video itself until it got really big (up around 1/2 sec). Then you see some artifacts. Our research (it was at Marconi, not where I am presently) was not published, but it was pretty thorough. We also concluded that delay was much more important than image quality: in our experiments, a QCIF image with low delay was preferred overwhelmingly compared to a very high quality image with lots of delay. Brian On 11/3/09 1:46 PM, "Michael Knappe" wrote: > Agreed, thanks. >=20 > One quick note on the 150 ms end-to-end requirement. That is a general > rule-of-thumb (and ITU specified) requirement for interactive speech > responsiveness and ease of conversation, but one that digging deeper is > dependent on language, cultural, and use case factors. There are conferen= ce > situations which are more forgiving to longer delays, and conversely lang= uage > types that require tighter delay to avoid emotional misinterpretation of > verbal acknowledgements. >=20 > Mike >=20 >=20 >=20 > ----- Original Message ----- > From: Brian Rosen > To: Roni Even ; Michael Knappe; mramalho@cisco.co= m > ; hoene@uni-tuebingen.de ; > codec@ietf.org > Sent: Tue Nov 03 11:23:20 2009 > Subject: Re: [codec] questions to be answered >=20 > Right, and the codec doesn't have anything special to match the delay: > that's done elsewhere. >=20 > Similarly, there is need for stereo and 5.1 acoustic echo cancel, but tha= t's > not part of the codec either, although we sometimes get tempted to put so= me > cues in the stream to help the echo cancellation. >=20 > There is no attempt to match frame sizes or anything else. You match del= ay > to get lip sync right. Everything else is pretty independent. >=20 > Of course, you have to keep the delay low ("low" in video terms): under 1= 50 > ms one way end to end, including any mixers. That's usually easy for the > audio, hard for the video, so you artificially delay the audio to match t= he > video. >=20 > Brian >=20 >=20 > On 11/3/09 1:09 PM, "Roni Even" wrote: >=20 >> Mike, > I am not sure what you mean by tied to video codec. I can think of the >> delay > which can be similar to the video. > The general requirements is support >> for hands free, full band with stereo > support and optional 5.1 >> support. > Current codecs used are AAC and G.719. > BTW: there is a different >> between tele-presence with multiple codecs and > hifh quality HD room systems >> with one video codec that provide > tele-presence" experience for small >> rooms. >=20 > Roni Even >=20 >> -----Original Message----- >> From: codec-bounces@ietf.org >> [mailto:codec-bounces@ietf.org] On Behalf >> Of Michael Knappe >> Sent: Tuesday, >> November 03, 2009 6:40 PM >> To: mramalho@cisco.com; hoene@uni-tuebingen.de; >> codec@ietf.org >> Subject: Re: [codec] questions to be answered >>=20 >> As I've >> been preparing the 'application vs. criteria matrix', it's >> become clear that >> video-centric applications like telepresence will >> have audio codecs that are >> at least partially tied to or driven by >> characteristics of the video coding >> (e.g. frame size). Do we as a group >> want to tackle additional non-voice >> considerations in the WG? >>=20 >> Agree with MAR on G.711, logarithmic encoding >> with a relatively fixed >> SNR doesn't cut it for monotonically decreasing >> frequency content >> sources like speech beyond 3 kHz. That's why G.722 went >> with a simple >> two-band approach for better representation of the upper >> octave, and >> there are of course many examples today of sub-band >> approaches. >>=20 >> Mike >>=20 >>=20 >> ----- Original Message ----- >> From: >> codec-bounces@ietf.org >> To: Christian Hoene >> ; codec@ietf.org >> >> Sent: Tue Nov 03 >> 10:33:56 2009 >> Subject: Re: [codec] questions to be answered >>=20 >> Hi >> Christian, >>=20 >> My replies are in-line below (w/ MAR:). >>=20 >> Thanks for your >> consideration. >>=20 >> Michael Ramalho >>=20 >> -----Original Message----- >> From: >> Christian Hoene [mailto:hoene@uni-tuebingen.de] >> Sent: Tuesday, November 03, >> 2009 4:30 AM >> To: Michael Ramalho (mramalho); codec@ietf.org >> Subject: RE: >> [codec] questions to be answered >>=20 >> Hello Michael, >>=20 >>> At a minimum, I >> see two legitimate codec classes: >>>=20 >>> CLASS 1) codecs that are bandwidth >> efficient and sound good to humans >>> (and perhaps satisfy tendeming or tone >> pass-through requirements), >> and >>>=20 >>> CLASS 2) codecs whose output may >> later be processed by sophisticated >>> signal processing functions >> (high-quality mixing, >>=20 >> High-quality mixing? That do you have in mind? >> Stereo or binaural (3D >> sound) >> mixing? >>=20 >> MAR: I continued in the email >> to say that I could potentially think of >> lots of other examples that require >> some bounds on the linear >> distortion because of the signal processing >> desired at the receiver. >> But yes, one could conceive of mixing to reproduce >> the effect of where >> spatially the sound came from in the sending location >> using only the >> signals rendered at the receiver. >>=20 >>> many >>>=20 >> classification-based applications such as speaker/sound/intrusion >>>=20 >> identification) that have SNR/waveform/distortion criteria generally >>>=20 >> exceeding CLASS 1. >>=20 >> You may add distributed speech recognition to the >> second class. >> However, to >> my understanding the current offered codecs have >> not been designed with >> the >> second class in mind. >>=20 >> MAR: Precisely. I am >> purposely not limiting my thinking to the current >> offered codecs. >>=20 >> MAR: >> Please note that I am not proposing Class 2 work at this time ... >> my point >> is that some organization in the future could advocate such in >> the future >> and NOT burden the present "Class 1" codec work with (what I >> believe are) >> unnecessary requirements. >>=20 >> MAR: Personally, I think there will be a need >> for Class 2 codecs soon >> ... but I think it is most important NOT to burden >> the present work >> with "low-runner" or "special-application" requirements. >> The whole >> point of my dissertation was that one codec cannot fit "all >> Internet >> applications". We should focus first on what the WG feels is the >> most >> pressing application - a bandwidth efficient, Internet-friendly, >> human- >> consumable codec. This codec is likely to be model-based. If >> someone >> has a "pet requirement" outside the general Class 1 codec consensus >> - >> let them propose a use case (which would include a market need >>=20 >> statement) and let the WG consider whether that "pet requirement" >> should be >> included in our first work or left for another day. >>=20 >> Also, class 2 might >> not fall in the interactive >> category (which implies that communication takes >> place between humans). >> By the way, are you training your >> classification-based applications >> while >> taking the distortions caused by >> the transmission system into >> consideration? >>=20 >> MAR: If the application is >> not real-time interaction ... we would send >> via reliable protocols ... and >> such a codec need not be as robust to >> packet loss. >>=20 >> MAR: Again I am not >> advocating a Class 2 codec at this time ... but >> apparently you are >> knowledgeable about matched training/testing >> conditions for ASR systems and >> the like. >>=20 >> You forgot: We need to add CLASS 3 for video and CLASS 4 for >> general >> content, too. >>=20 >> MAR: No, I didn't. I'll let someone who has >> convinced the WG chairs of >> a market need, a use case, proposed requirements >> for any additional >> classes to be considered. I would hope that a very >> limited number of >> codecs are developed (see next paragraph). >>=20 >>> Granted, >> we should make each use case as broad as possible so as not >> to >>> have too >> many of them. Once one codec is standardized for a >> particular >>>=20 >> application type - a subsequent candidate codec/application would >> need >>>=20 >> to prove it is "sufficiently different" from the existing codec(s) to >> go >>>=20 >> further. The WG chairs need to exert leadership to ensure the desired >>>=20 >> result (of the smallest number of codecs spanning the greatest >>> application >> space). >>=20 >> Yes, actually Noll and Jayant have proposed to use =B5-Law to >> support >> speech, >> audio >>=20 >> MAR: This is patently false if you consider >> audio to have content above >> 4 kHz. All natural signals with finite energy (a >> guitar string pluck, a >> glottal speech pulse) have a spectral roll-off with >> increasing >> frequency (e.g., speech has approximately a 6 dB roll-off per >> octave). >> G.711 has a flat distortion characteristic with frequency. This >> means >> if you go out far enough in frequency (depends on the signal) your >> SNR >> turns negative at some point. I have personally interacted with Dr. >>=20 >> Jayant at Bell Labs Murray Hill and I can assure you that he would NOT >>=20 >> advocate G.711 for other than a narrowband speech audio application. >>=20 >> AND >> video compression. >>=20 >> MAR: Definitely false ... but would require too long >> an explanation >> (luminance related) ;-). I can't tell if you sarcastic-mode >> is set to >> on. >>=20 >> But to my understanding it is common consensus >> to >> concentrate on a limited (e.g. class 1) scenario and finished this >> work >>=20 >> first before setting up another construction site. >>=20 >> MAR: And that is, in >> essence, my proposal - except I have a tweak. If >> you have a "pet >> requirement", I (personally) don't want it to bugger-up >> the process of >> getting to a good a bandwidth efficient, Internet- >> friendly, >> human-consumable codec. >>=20 >> Christian >>=20 >>=20 >>=20 >> _______________________________________________ >> codec mailing list >>=20 >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >> _______________________________________________ >> codec mailing list >>=20 >> codec@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/codec >=20 > _________________________________ >> ______________ > codec mailing >> list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 From mknappe@juniper.net Tue Nov 3 10:59: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 663563A67B3 for ; Tue, 3 Nov 2009 10:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 B42+-ROLBY-i for ; Tue, 3 Nov 2009 10:59:16 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id D291628C0F1 for ; Tue, 3 Nov 2009 10:59:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSvB9jz6rNvbHSoBt6YahijVp4yGviQ+4@postini.com; Tue, 03 Nov 2009 10:59:37 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 3 Nov 2009 10:59:17 -0800 From: Michael Knappe To: "jean-marc.valin@octasic.com" Date: Tue, 3 Nov 2009 10:59:16 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpcsTVhDf54/p9lQIuAV7V9jEwL9gABoam6 Message-ID: <05542EC42316164383B5180707A489EE1D031D3D1B@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 18:59:17 -0000 Of course codecs have not been tied directly to the 15 / 30 fps video requi= rements from an evenly divisible sample rate perspective, but G.723.1 (30 m= s) was closely associated with video conferencing. This was just an example= of a codec that structured its processing around longer frame times. Enough said, I think its clear from discussion that we can keep audio and v= ideo requirements separate for the purpose of this effort. Simplifying the = problem space is a good thing. Mike ----- Original Message ----- From: Jean-Marc Valin To: Michael Knappe Cc: mramalho@cisco.com ; hoene@uni-tuebingen.de ; codec@ietf.org Sent: Tue Nov 03 13:12:28 2009=0A= Subject: Re: [codec] questions to be answered Michael Knappe wrote: > As I've been preparing the 'application vs. criteria matrix', it's > become clear that video-centric applications like telepresence will have > audio codecs that are at least partially tied to or driven by > characteristics of the video coding (e.g. frame size).=20 Actually, why would the frame size of the codec be related to the video=20 codec? I don't see any valid reason for doing that and I would have a hard= =20 time imagining how one would have an audio codec with 29.97 frames per=20 second (without using a sampling rate of 59.94 kHz). > Do we as a group > want to tackle additional non-voice considerations in the WG? (I assume you mean non-audio considerations because we definitely want to=20 consider music here) I'm not fundamentally opposed to the idea of including= =20 non-audio considerations, but there would have to be a good reason for=20 that. Right now I cannot see any, but I may have missed something. Jean-Marc From stpeter@stpeter.im Tue Nov 3 12:32: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 D6EE93A68F9 for ; Tue, 3 Nov 2009 12:32:09 -0800 (PST) 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 4vRSqLDkGNbC for ; Tue, 3 Nov 2009 12:32:09 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F39263A6878 for ; Tue, 3 Nov 2009 12:32:08 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3FFF40D3B; Tue, 3 Nov 2009 13:32:27 -0700 (MST) Message-ID: <4AF0935A.1060903@stpeter.im> Date: Tue, 03 Nov 2009 13:32:26 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4AEB25DE.7020602@stpeter.im> <4aec571b.cf02be0a.36fb.4699@mx.google.com> <4AEF1A16.4070604@stpeter.im> <4aef381a.0c135e0a.02bc.2f37@mx.google.com> In-Reply-To: <4aef381a.0c135e0a.02bc.2f37@mx.google.com> 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] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 20:32:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/09 12:49 PM, Roni Even wrote: > Hi Peter, > Who is going to give all these presentations, I am used to see the > presenters in agendas You are right that the agenda needs to include the speakers. The chairs, our sponsoring AD, and the IAB BoF shepherd are working to finalize the presenters. /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrwk1kACgkQNL8k5A2w/vxPiQCfaqs6Nb7yylFYNVvYfwupM6my FK8AnRk4ZAOi8EfIXhO8rKqRQmENOJxF =oBd1 -----END PGP SIGNATURE----- From gmaxwell@juniper.net Tue Nov 3 12:59: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 9FCDD3A6802 for ; Tue, 3 Nov 2009 12:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzaYFbbGIURu for ; Tue, 3 Nov 2009 12:59:11 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 7352B3A68B3 for ; Tue, 3 Nov 2009 12:59:11 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSvCZqsV4Effn2K02IGmPhERUWXd8SAJE@postini.com; Tue, 03 Nov 2009 12:59:32 PST 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; Tue, 3 Nov 2009 12:52:55 -0800 From: Gregory Maxwell To: Michael Knappe , "br@brianrosen.net" , "ron.even.tlv@gmail.com" , "mramalho@cisco.com" , "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Tue, 3 Nov 2009 12:52:54 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicAAJ4H2UAAO+x/QAARVERgAAOcwcAAAme77AADSXP8ABYJx+Q== Message-ID: References: <05542EC42316164383B5180707A489EE1D031D3D17@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D031D3D17@EMBX02-HQ.jnpr.net> 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Nov 2009 20:59:12 -0000 Michael Knappe wrote: > One quick note on the 150 ms end-to-end requirement. That is a general ru= le-of-thumb > (and ITU specified) requirement for interactive speech responsiveness and= ease of > conversation, but one that digging deeper is dependent on language, cultu= ral, and use > case factors. There are conference situations which are more forgiving to= longer delays, > and conversely language types that require tighter delay to avoid emotion= al > misinterpretation of verbal acknowledgements. Delay has come up before. A prior post from my cites research which found t= hat 25ms one-way was the perceptual boundary for interactive music performance:=20 http://www.ietf.org/mail-archive/web/codec/current/msg00360.html One important take away is that while the codec delay is only one cause of = delays it is the *only* cause of delay which the proposed working group would be in a positi= on to influence,=20 and some of the other causes of delays are the result of natural law, or ot= her things nearly as difficult to change (like OS audio APIs). Since the user is unable to c= hange the speed of light and may have little control over their network the codec is one of= the few places where delay can be shaved off, for applications that require lower delay. Some more thoughts on delay=85 Minimizing the delay makes it easier to perform echo cancellation and with = sufficiently low=20 delay (and gain management) echo cancellation can be avoided entirely becau= se the residual=20 echo will be masked by room reflections. This can be important because man= y echo cancellation implementations perform somewhat poorly on music, especially i= n very reverberant rooms. There are video codecs which provide sub-frame latency (dirac pro, for exam= ple) and although it is challenging to find low delay video hardware there is interest in sub= frame latency video for tele-operating and tele-presence applications. =20 Another application where system latency is important is in remote-desktop = applications, as delayed audio can make the system appear less responsive. (There are other= people on this list who can comment better on the implications to online gaming than I can= ) Even if a video system is imposing a particular minimum audio latency, thi= s does not necessarily imply that larger audio frames are desirable: The frame size also implies = the minimum loss unit. Larger frame sizes make random drops look more temporally bursty. With smal= l frame sizes good loss concealment can provide intelligible speech with random loss rate= in excess of 25%, but this is much harder with larger frames or clumped losses. (an interesting challenge for internet rate control: if you are seeing loss= , do you use larger packets to reduce rate/overhead, or do you use smaller packets to decrease = gap per loss?) The maximum received codec frame sizes translates directly into codec memor= y requirements. While encoders can potentially take advantage of additional lookahead witho= ut changing the coding unit, if larger frames are used the impact on the minimum device size is a = potential consideration. From ingemar.s.johansson@ericsson.com Wed Nov 4 01:14: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 D3B7D3A6A9B for ; Wed, 4 Nov 2009 01:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.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 FA7+ggYZc8K0 for ; Wed, 4 Nov 2009 01:14:02 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 679143A6A99 for ; Wed, 4 Nov 2009 01:14:02 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-54-4af145eea1c1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0D.F9.24026.EE541FA4; Wed, 4 Nov 2009 10:14:22 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 10:14:15 +0100 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, 4 Nov 2009 10:14:15 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on BoF charter problem statement Thread-Index: AcpcpLWQWKL1pxXyQpisPLTPWGn66wAgxeGQ References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 04 Nov 2009 09:14:15.0873 (UTC) FILETIME=[2E840310:01CA5D2F] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S Subject: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Nov 2009 09:14:03 -0000 Hi I have a comment on the introduction to the Codec BoF charter. Quote: "There are no standardized, high-quality audio codecs that are optimized = for use in interactive Internet applications and that can be widely = implemented and easily distributed among application developers, service = operators, and end users." This easily gives the hurried reader the impression that there are no = codecs optimized for interactive internet applications available. This = is not a correct statement. As I see it the main issue raised = (especially on the codec list) is round the magic words "Royalty free". = The statement above mix the tecnical and legal issues and I don't like = that. I would rather have seen a statement written something like. "There exists a desire for standardized, high-quality codecs that can be = widely implemented and easily distributed among application developers, = service operators, and end users. Standards for this exists but the free = use is restricted by royalty conditions" Something like the above (perhaps with some better words) will give the = reader a much better idea of what has actually been discussed on the = codec list as well as during the last BoF =20 /Ingemar =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From alexander.chemeris@gmail.com Wed Nov 4 03:21: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 B64BF3A67CC for ; Wed, 4 Nov 2009 03:21:19 -0800 (PST) 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 QyaT-d4VFodA for ; Wed, 4 Nov 2009 03:21:19 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id B1D113A63C9 for ; Wed, 4 Nov 2009 03:21:18 -0800 (PST) Received: by bwz23 with SMTP id 23so8746995bwz.29 for ; Wed, 04 Nov 2009 03:21:35 -0800 (PST) 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=XpcCBPKsOxdzjd2aq4SzrAzrFutxnhptLsZPf5hzoRE=; b=o1XUa+o7g50z9j2bthatH8E9WQhfIkQR4iLy3iBLVHPqJSqM9rcpmU7xFsQrDhWj2H Qs/c3FtjF+nXJ4QZHfjHSU6Dh26r3/dCOQHBw8G/1DkFTpd+XmdWrAkTR02Y4kGpxJNM MZc/R9595IWir7S4sRojEw8gkDn+Qyqu1ExBE= 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=F1UrEKle/G2BlEX4zkRu/5c9ZiAXz4qALBTvcnAPOw2MECZFwqPzK6p7IeG+jicnBW +/RB0L1PClqHhjDhfQ0aFDNHxi3bUp+ZgSL5ydA0GdIkWgpV9nmceZ1VSkU7eGVKxC6N 2hKeVNZOA6WgX3VAZROZk0sbi8wzVuGcq4784= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.78.31 with SMTP id f31mr522167mul.24.1257333695097; Wed, 04 Nov 2009 03:21:35 -0800 (PST) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D031D3D17@EMBX02-HQ.jnpr.net> From: Alexander Chemeris Date: Wed, 4 Nov 2009 14:21:15 +0300 X-Google-Sender-Auth: b80a4524c352bcfb Message-ID: <3d032e5d0911040321y5ccc4d1fn6015aa968178e67e@mail.gmail.com> To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Nov 2009 11:21:19 -0000 Hi Gregory, On Tue, Nov 3, 2009 at 23:52, Gregory Maxwell wrote: > One important take away is that while the codec delay is only one cause o= f delays it is the > *only* cause of delay which the proposed working group would be in a posi= tion to influence, > and some of the other causes of delays are the result of natural law, or = other things nearly > as difficult to change (like OS audio APIs). =C2=A0Since the user is unab= le to change the speed > of light and may have little control over their network the codec is one = of the few places > where delay can be shaved off, for applications that require lower delay. Ability to perform well in presence of packet loss can also affect delay. If you can efficiently conceal lost packets, you can set lower watermark in your jitter buffer. --=20 Regards, Alexander Chemeris. From stpeter@stpeter.im Wed Nov 4 12:57: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 8815428C11E for ; Wed, 4 Nov 2009 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 gnoXzpiUWiBm for ; Wed, 4 Nov 2009 12:57:34 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A704228C133 for ; Wed, 4 Nov 2009 12:57:34 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 45CF740D23 for ; Wed, 4 Nov 2009 13:57:56 -0700 (MST) Message-ID: <4AF1EAD3.8040302@stpeter.im> Date: Wed, 04 Nov 2009 13:57:55 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.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 Subject: [codec] agenda uploaded X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Nov 2009 20:57:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric and I have uploaded a draft agenda: http://www.ietf.org/proceedings/09nov/agenda/codec.txt Further tweaking is possible, and feedback is welcome on the list or during agenda bashing at the meeting next Thursday. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrx6tMACgkQNL8k5A2w/vyeeQCgiuYOPVhqsXQ8PXQgmbaH40nT jmEAnjwcABPXn6oknWlPtlmb/SAk1CO6 =2+Gc -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Nov 4 13:16: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 182653A6896 for ; Wed, 4 Nov 2009 13:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 dViVIGypGyDg for ; Wed, 4 Nov 2009 13:16:25 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 012CC3A6915 for ; Wed, 4 Nov 2009 13:16:25 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DAA2840D23; Wed, 4 Nov 2009 14:16:46 -0700 (MST) Message-ID: <4AF1EF3D.9010503@stpeter.im> Date: Wed, 04 Nov 2009 14:16:45 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> 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] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Nov 2009 21:16:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/09 2:14 AM, Ingemar Johansson S wrote: > Hi > > I have a comment on the introduction to the Codec BoF charter. Quote: > "There are no standardized, high-quality audio codecs that are > optimized for use in interactive Internet applications and that can > be widely implemented and easily distributed among application > developers, service operators, and end users." > > This easily gives the hurried reader the impression that there are no > codecs optimized for interactive internet applications available. > This is not a correct statement. As I see it the main issue raised > (especially on the codec list) is round the magic words "Royalty > free". The statement above mix the tecnical and legal issues and I > don't like that. > > I would rather have seen a statement written something like. > > "There exists a desire for standardized, high-quality codecs that can > be widely implemented and easily distributed among application > developers, service operators, and end users. Standards for this > exists but the free use is restricted by royalty conditions" > Something like the above (perhaps with some better words) will give > the reader a much better idea of what has actually been discussed on > the codec list as well as during the last BoF Thank you for the suggested text. I see several points: 1. The text you suggest says nothing about making sure that a codec is optimized for use in Internet applications, and that is an important consideration for the proposed work. 2. There exist codecs that can be widely implemented and easily distributed, but they are not standardized through any SDO (and, according to reports from application developers and service operators, the lack of standardization and clear change control has hindered adoption). 3. There exist codecs that are standardized, but they cannot be widely implemented and easily distributed (and, again according to reports from application developers and service operators, the presence of usage restrictions in the form of licensing fees and restriction has hindered adoption). My understanding is that the people who are interested in completing this work would like to achieve a combination of (1) Internet-optimized, (2) standardized through a SDO, and (3) free of usage restrictions. I agree that this could be worded more clearly, and I'll try to do that soon. 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/ iEYEARECAAYFAkrx7z0ACgkQNL8k5A2w/vwmxgCeK/imxMeOid/SsF8GITber2Kv h0AAoIGJ5VVSIeMQrJcosUEttYk5igQg =WYju -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Nov 4 13:42: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 D90043A686C for ; Wed, 4 Nov 2009 13:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 ZX5cR2PdRGUV for ; Wed, 4 Nov 2009 13:42:33 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2D63C3A68CC for ; Wed, 4 Nov 2009 13:42:33 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CF0BE40D23; Wed, 4 Nov 2009 14:42:54 -0700 (MST) Message-ID: <4AF1F55D.1000008@stpeter.im> Date: Wed, 04 Nov 2009 14:42:53 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> In-Reply-To: <4AF1EF3D.9010503@stpeter.im> 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] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Nov 2009 21:42:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/09 2:16 PM, Peter Saint-Andre wrote: > On 11/4/09 2:14 AM, Ingemar Johansson S wrote: >> Hi > >> I have a comment on the introduction to the Codec BoF charter. Quote: >> "There are no standardized, high-quality audio codecs that are >> optimized for use in interactive Internet applications and that can >> be widely implemented and easily distributed among application >> developers, service operators, and end users." > >> This easily gives the hurried reader the impression that there are no >> codecs optimized for interactive internet applications available. >> This is not a correct statement. As I see it the main issue raised >> (especially on the codec list) is round the magic words "Royalty >> free". The statement above mix the tecnical and legal issues and I >> don't like that. > >> I would rather have seen a statement written something like. > >> "There exists a desire for standardized, high-quality codecs that can >> be widely implemented and easily distributed among application >> developers, service operators, and end users. Standards for this >> exists but the free use is restricted by royalty conditions" >> Something like the above (perhaps with some better words) will give >> the reader a much better idea of what has actually been discussed on >> the codec list as well as during the last BoF > > Thank you for the suggested text. I see several points: > > 1. The text you suggest says nothing about making sure that a codec is > optimized for use in Internet applications, and that is an important > consideration for the proposed work. > > 2. There exist codecs that can be widely implemented and easily > distributed, but they are not standardized through any SDO (and, > according to reports from application developers and service operators, > the lack of standardization and clear change control has hindered adoption). > > 3. There exist codecs that are standardized, but they cannot be widely > implemented and easily distributed (and, again according to reports from > application developers and service operators, the presence of usage > restrictions in the form of licensing fees and restriction has hindered > adoption). > > My understanding is that the people who are interested in completing > this work would like to achieve a combination of (1) Internet-optimized, > (2) standardized through a SDO, and (3) free of usage restrictions. > > I agree that this could be worded more clearly, and I'll try to do that > soon. > > Peter Unfortunately, describing this all in detailed requires more words. :) Here is proposed text... ### Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Can be widely implemented and easily distributed among application developers, service operators, and end users. 3. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, this presence of various usage restrictions (e.g., in the form of licensing fees and royalties) has hindered adoption of such codecs in interactive Internet applications. Therefore, there exists demand among application developers and service operators for audio codecs that meet all three of these criteria. According to reports, filling this perceived gap would enable protocol designers to more easily specify mandatory-to-implement codecs in their protocols and thus improve interoperability, would enable developers to more easily build innovative, interactive applications for the Internet, would enable service operators to more easily deploy affordable, high-quality audio services on the Internet, and would enable end users of Internet applications and services to enjoy an improved user experience. ### /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrx9V0ACgkQNL8k5A2w/vyWFACfboDwdLLWyzMmZFgUHRso5WHS F3wAn2Dbj9dW8S9/Exme0s3JMEt2KAVA =fCjL -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Thu Nov 5 03:59: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 4BEFB3A676A for ; Thu, 5 Nov 2009 03:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[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 g4ICMsPzj2-3 for ; Thu, 5 Nov 2009 03:59:57 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id B0C9C3A67E1 for ; Thu, 5 Nov 2009 03:59:57 -0800 (PST) Received: by pzk42 with SMTP id 42so6306665pzk.31 for ; Thu, 05 Nov 2009 04:00:15 -0800 (PST) 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=BQpLTzblqFm9NE7O/flK5vGmH+xLauDUOtoNmTgzak0=; b=RwxVxJkA6pRxpPcT7niOeRoGsXi4K7lUT8i5i10wp6NFgaKg/3nqoyU/ZDtx+hFSuk p/6hTdgxKgRIC+1JQ0WDjV0dIfXfWaQG2L3jm1ggBaEHM6KIzVojTdLOVTr5s1905svY rZZEPetbPApjxSTwYUn1/5rkj9PcCT7Bfnx/w= 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=xXRVVxeLCzzW5pYZz7bqv5QCOEjEcCUvNY6R3gu+EQcKPUpJ35HyzbR+vsUaTYSC9J 1CkTj8+7qYYeyFM+bOPTbqjlQHtghe5g2lk9y62TXSCa8q8CAx7mlNnd8jcrZCMQiEkd mYcMkobIqobcNlIlAQNmdXSNitqowxdj+cIJU= Received: by 10.115.149.4 with SMTP id b4mr4881202wao.18.1257422414840; Thu, 05 Nov 2009 04:00:14 -0800 (PST) Received: from windows8d787f9 (p5012-ipbfp403niho.hiroshima.ocn.ne.jp [123.223.213.12]) by mx.google.com with ESMTPS id 20sm639475pxi.3.2009.11.05.04.00.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 04:00:13 -0800 (PST) From: "Roni Even" To: "'Peter Saint-Andre'" , "'Ingemar Johansson S'" References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> In-Reply-To: <4AF1EF3D.9010503@stpeter.im> Date: Thu, 5 Nov 2009 13:59:15 +0200 Message-ID: <4af2be4d.141bf30a.239d.4d9a@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: AcpdlCH5D452fUpOQCWvU3qAW14VKwAeqfKA Content-language: en-us Cc: codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 11:59:59 -0000 Hi, I think that Ingemar made a good point and it should be addressed. I also do not agree that the reason for lack of deployment of wideband is because of royalties. My observation is that wideband is being used in markets where the parties that had interest in wide band audio agreed to select specific codec from the available codecs. That can be seen in video conferencing and in 3GPP. This is also tied to my view that if the group want to succeed it should define one codec. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Wednesday, November 04, 2009 11:17 PM > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Comments on BoF charter problem statement > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/4/09 2:14 AM, Ingemar Johansson S wrote: > > Hi > > > > I have a comment on the introduction to the Codec BoF charter. Quote: > > "There are no standardized, high-quality audio codecs that are > > optimized for use in interactive Internet applications and that can > > be widely implemented and easily distributed among application > > developers, service operators, and end users." > > > > This easily gives the hurried reader the impression that there are no > > codecs optimized for interactive internet applications available. > > This is not a correct statement. As I see it the main issue raised > > (especially on the codec list) is round the magic words "Royalty > > free". The statement above mix the tecnical and legal issues and I > > don't like that. > > > > I would rather have seen a statement written something like. > > > > "There exists a desire for standardized, high-quality codecs that can > > be widely implemented and easily distributed among application > > developers, service operators, and end users. Standards for this > > exists but the free use is restricted by royalty conditions" > > Something like the above (perhaps with some better words) will give > > the reader a much better idea of what has actually been discussed on > > the codec list as well as during the last BoF > > Thank you for the suggested text. I see several points: > > 1. The text you suggest says nothing about making sure that a codec is > optimized for use in Internet applications, and that is an important > consideration for the proposed work. > > 2. There exist codecs that can be widely implemented and easily > distributed, but they are not standardized through any SDO (and, > according to reports from application developers and service operators, > the lack of standardization and clear change control has hindered > adoption). > > 3. There exist codecs that are standardized, but they cannot be widely > implemented and easily distributed (and, again according to reports > from > application developers and service operators, the presence of usage > restrictions in the form of licensing fees and restriction has hindered > adoption). > > My understanding is that the people who are interested in completing > this work would like to achieve a combination of (1) Internet- > optimized, > (2) standardized through a SDO, and (3) free of usage restrictions. > > I agree that this could be worded more clearly, and I'll try to do that > soon. > > 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/ > > iEYEARECAAYFAkrx7z0ACgkQNL8k5A2w/vwmxgCeK/imxMeOid/SsF8GITber2Kv > h0AAoIGJ5VVSIeMQrJcosUEttYk5igQg > =WYju > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ingemar.s.johansson@ericsson.com Thu Nov 5 04:16: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 BE3CB3A69CC for ; Thu, 5 Nov 2009 04:16:00 -0800 (PST) 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_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 FLTlt-HPONZC for ; Thu, 5 Nov 2009 04:15:59 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C90893A69C7 for ; Thu, 5 Nov 2009 04:15:58 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-b2-4af2c213c9b0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 13.6C.31706.312C2FA4; Thu, 5 Nov 2009 13:16:19 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 13:16:19 +0100 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, 5 Nov 2009 13:16:18 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C022BD846@esealmw109.eemea.ericsson.se> In-Reply-To: <4AF1F55D.1000008@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Comments on BoF charter problem statement Thread-Index: Acpdl8XHpzPh8MfNQ6Cn2JDzlD+XLQAeU9Uw References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4AF1F55D.1000008@stpeter.im> From: "Ingemar Johansson S" To: "Peter Saint-Andre" X-OriginalArrivalTime: 05 Nov 2009 12:16:19.0550 (UTC) FILETIME=[C7F297E0:01CA5E11] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 12:16:00 -0000 Hi The rewritten intro looks much better. One remaining concern is perhaps that royalty free/licence free is not mentioned in bullet 2 but if I understand it right you wanted to keep the 3 bullets short and explain the details further down.=20 Anyway I now see that the apples and oranges (technical and legal matters) are kept separate and that is good. /Ingemar > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 > Sent: den 4 november 2009 22:43 > To: Ingemar Johansson S > Cc: codec@ietf.org > Subject: Re: [codec] Comments on BoF charter problem statement >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/4/09 2:16 PM, Peter Saint-Andre wrote: > > On 11/4/09 2:14 AM, Ingemar Johansson S wrote: > >> Hi > >=20 > >> I have a comment on the introduction to the Codec BoF=20 > charter. Quote: > >> "There are no standardized, high-quality audio codecs that are=20 > >> optimized for use in interactive Internet applications and=20 > that can=20 > >> be widely implemented and easily distributed among application=20 > >> developers, service operators, and end users." > >=20 > >> This easily gives the hurried reader the impression that=20 > there are no=20 > >> codecs optimized for interactive internet applications available. > >> This is not a correct statement. As I see it the main issue raised=20 > >> (especially on the codec list) is round the magic words "Royalty=20 > >> free". The statement above mix the tecnical and legal issues and I=20 > >> don't like that. > >=20 > >> I would rather have seen a statement written something like. > >=20 > >> "There exists a desire for standardized, high-quality=20 > codecs that can=20 > >> be widely implemented and easily distributed among application=20 > >> developers, service operators, and end users. Standards for this=20 > >> exists but the free use is restricted by royalty conditions" > >> Something like the above (perhaps with some better words)=20 > will give=20 > >> the reader a much better idea of what has actually been=20 > discussed on=20 > >> the codec list as well as during the last BoF > >=20 > > Thank you for the suggested text. I see several points: > >=20 > > 1. The text you suggest says nothing about making sure that=20 > a codec is=20 > > optimized for use in Internet applications, and that is an=20 > important=20 > > consideration for the proposed work. > >=20 > > 2. There exist codecs that can be widely implemented and easily=20 > > distributed, but they are not standardized through any SDO (and,=20 > > according to reports from application developers and service=20 > > operators, the lack of standardization and clear change=20 > control has hindered adoption). > >=20 > > 3. There exist codecs that are standardized, but they=20 > cannot be widely=20 > > implemented and easily distributed (and, again according to reports=20 > > from application developers and service operators, the presence of=20 > > usage restrictions in the form of licensing fees and=20 > restriction has=20 > > hindered adoption). > >=20 > > My understanding is that the people who are interested in=20 > completing=20 > > this work would like to achieve a combination of (1)=20 > > Internet-optimized, > > (2) standardized through a SDO, and (3) free of usage restrictions. > >=20 > > I agree that this could be worded more clearly, and I'll try to do=20 > > that soon. > >=20 > > Peter >=20 > Unfortunately, describing this all in detailed requires more=20 > words. :) Here is proposed text... >=20 > ### >=20 > Problem Statement >=20 > According to reports from developers of Internet audio=20 > applications and operators of Internet audio services, there=20 > are no standardized, high-quality audio codecs that meet all=20 > of the following three > conditions: >=20 > 1. Are optimized for use in interactive Internet applications. >=20 > 2. Can be widely implemented and easily distributed among=20 > application developers, service operators, and end users. >=20 > 3. Are published by a recognized standards development organization > (SDO) and therefore subject to clear change control. >=20 > There exist codecs that provide high quality encoding of=20 > audio information, but that are not optimized for the actual=20 > conditions of the Internet; according to reports, this=20 > mismatch between design and deployment has hindered adoption=20 > of such codecs in interactive Internet applications. >=20 > There exist codecs that can be widely implemented and easily=20 > distributed, but that are not standardized through any SDO;=20 > according to reports, this lack of standardization and clear=20 > change control has hindered adoption of such codecs in=20 > interactive Internet applications. >=20 > There exist codecs that are standardized, but that cannot be=20 > widely implemented and easily distributed; according to=20 > reports, this presence of various usage restrictions (e.g.,=20 > in the form of licensing fees and > royalties) has hindered adoption of such codecs in=20 > interactive Internet applications. >=20 > Therefore, there exists demand among application developers=20 > and service operators for audio codecs that meet all three of=20 > these criteria. > According to reports, filling this perceived gap would enable=20 > protocol designers to more easily specify=20 > mandatory-to-implement codecs in their protocols and thus=20 > improve interoperability, would enable developers to more=20 > easily build innovative, interactive applications for the=20 > Internet, would enable service operators to more easily=20 > deploy affordable, high-quality audio services on the=20 > Internet, and would enable end users of Internet applications=20 > and services to enjoy an improved user experience. >=20 > ### >=20 > /psa >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkrx9V0ACgkQNL8k5A2w/vyWFACfboDwdLLWyzMmZFgUHRso5WHS > F3wAn2Dbj9dW8S9/Exme0s3JMEt2KAVA > =3DfCjL > -----END PGP SIGNATURE----- >=20 From darren.longhorn@redembedded.com Thu Nov 5 07:12: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 3A1263A6AE0 for ; Thu, 5 Nov 2009 07:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqU0EbGxIRHt for ; Thu, 5 Nov 2009 07:12:23 -0800 (PST) Received: from smoke.redembedded.co.uk (mail.redembedded.co.uk [83.100.215.137]) by core3.amsl.com (Postfix) with ESMTP id 08AE23A6ADF for ; Thu, 5 Nov 2009 07:12:22 -0800 (PST) Received: from dhcp177.redembedded.com ([192.168.168.87]:48190) by smoke.redembedded.co.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N640n-0005dr-LR; Thu, 05 Nov 2009 15:12:38 +0000 Message-ID: <4AF2EB61.8000109@redembedded.com> Date: Thu, 05 Nov 2009 15:12:33 +0000 From: Darren Longhorn User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Roni Even References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4af2be4d.141bf30a.239d.4d9a@mx.google.com> In-Reply-To: <4af2be4d.141bf30a.239d.4d9a@mx.google.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 15:12:24 -0000 Roni Even wrote: > I also do not agree that the reason for lack of deployment of wideband is > because of royalties. > My observation is that wideband is being used in markets where the parties > that had interest in wide band audio agreed to select specific codec from > the available codecs. I would agree with that, but there is still a preference for royalty free, I have, for example, seen commercial deployments where speex was chosen over amr-wb for exactly that reason. From stpeter@stpeter.im Thu Nov 5 09:20: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 3167F3A6952 for ; Thu, 5 Nov 2009 09:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 XjlZ6UhaN-R5 for ; Thu, 5 Nov 2009 09:20:28 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0E6A23A6ACD for ; Thu, 5 Nov 2009 09:19:55 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 85E4940D1E; Thu, 5 Nov 2009 10:20:17 -0700 (MST) Message-ID: <4AF30950.1080007@stpeter.im> Date: Thu, 05 Nov 2009 10:20:16 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4AF1F55D.1000008@stpeter.im> <130EBB38279E9847BAAAE0B8F9905F8C022BD846@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C022BD846@esealmw109.eemea.ericsson.se> 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] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 17:20:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/5/09 5:16 AM, Ingemar Johansson S wrote: > Hi > > The rewritten intro looks much better. One remaining concern is perhaps > that royalty free/licence free is not mentioned in bullet 2 but if I > understand it right you wanted to keep the 3 bullets short and explain > the details further down. > Anyway I now see that the apples and oranges (technical and legal > matters) are kept separate and that is good. Yes, I think it is good to separate those concerns. I have updated the draft charter here: http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt So that we can have stable documents for review, probably Eric and I won't upload further revisions to the draft charter before the BoF next Thursday. 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/ iEYEARECAAYFAkrzCVAACgkQNL8k5A2w/vxhNQCglKg6/PL68hPIr8BVToGVD5k+ iwgAoLQGc3mnCZChKvqIToeupb5P77bB =GwIP -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Nov 5 09:23: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 F01233A69A4 for ; Thu, 5 Nov 2009 09:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 5PKcseshoQYO for ; Thu, 5 Nov 2009 09:23:51 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 155DD3A67D9 for ; Thu, 5 Nov 2009 09:23:51 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A28FF40D1E; Thu, 5 Nov 2009 10:24:13 -0700 (MST) Message-ID: <4AF30A3C.2070901@stpeter.im> Date: Thu, 05 Nov 2009 10:24:12 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Darren Longhorn References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4af2be4d.141bf30a.239d.4d9a@mx.google.com> <4AF2EB61.8000109@redembedded.com> In-Reply-To: <4AF2EB61.8000109@redembedded.com> 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: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 17:23:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/5/09 8:12 AM, Darren Longhorn wrote: > Roni Even wrote: > >> I also do not agree that the reason for lack of deployment of wideband is >> because of royalties. >> My observation is that wideband is being used in markets where the parties >> that had interest in wide band audio agreed to select specific codec from >> the available codecs. > > I would agree with that, but there is still a preference for royalty > free, I have, for example, seen commercial deployments where speex was > chosen over amr-wb for exactly that reason. Thanks for the feedback. I think that is consistent with reports received from service operators and application developers. 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/ iEYEARECAAYFAkrzCjwACgkQNL8k5A2w/vxkCACfXJruaOIEUpiqxYEPuGFeh1Qh 2UgAoJHugw0k24GfcYQ5V1WqcP8evQJx =7S2H -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Nov 5 09:25: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 35F333A6970 for ; Thu, 5 Nov 2009 09:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FRT_BEFORE=1.272] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9YCeGRqRlSJ for ; Thu, 5 Nov 2009 09:25:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7B9CF3A67D9 for ; Thu, 5 Nov 2009 09:25:06 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 190F540D1E; Thu, 5 Nov 2009 10:25:28 -0700 (MST) Message-ID: <4AF30A88.90101@stpeter.im> Date: Thu, 05 Nov 2009 10:25:28 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Hoene References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEEEB83.8090007@octasic.com> <4aeef6c2.23145e0a.7c0a.ffffbd85@mx.google.com> <4AEF186E.9090504@stpeter.im> <4aef3786.02225e0a.09f9.0d90@mx.google.com> <4AEF396B.5080707@stpeter.im> <00a901ca5c68$6025e1d0$2071a570$@de> In-Reply-To: <00a901ca5c68$6025e1d0$2071a570$@de> 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Nov 2009 17:25:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/3/09 2:30 AM, Christian Hoene wrote: > Hello Peter, > >>> Peter, This has to do with the charter, there need to be a decision >>> how many codec are developed for one requirement document. It looks >>> to me based on the discussion that there is no consensus between the >>> people who propose this charter since all have similar codecs they >>> want to approve and are not looking at collaboration. >> I see no evidence for that statement. >> >> All of the individuals and teams who have submitted codecs have done so >> with the understanding that each contribution will probably not be >> approved, and even if approved would undergo modification (i.e., even a >> codec that functioned as a "starting point" codec would be *adapted*, >> not *adopted*). This is consistent with the following statement in >> draft-valin-codec-guidelines-02: >> >> Furthermore, contributors need to be >> aware that any codec that results from work within the IETF is likely >> to be different from any existing codec that was contributed to the >> Internet Standards Process. >> >> All of the speakers I heard at the BoF in Stockholm made it clear that >> they expect to and are eager to collaborate on a codec that meets the >> requirements, and that they do not expect to simply get their own codecs >> approved as-is. > > This all might be true. However, at the moment we are discussing the charter > and not the drafts nor any oral statements, which all can be updated or > revoked at any time. Thus, it would be beneficial having some high level > goals in the charter that help to decide on the number of codecs. > > These could be for e.g. "Different codecs must have unmergable, orthogonal > requirements" or "One codec and a low number of optional extensions that > address additional requirements". These are good topics to discuss in the BoF. 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/ iEYEARECAAYFAkrzCogACgkQNL8k5A2w/vyAKACg8BsVakPGxqbD0oRhSFK6Xrjs vGcAoPe5KjefxI3H2T/KjvxjEPor4XwD =gVWu -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Nov 5 10:36: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 9280D28C0E1 for ; Thu, 5 Nov 2009 10:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 W0K4NpE9iS7h for ; Thu, 5 Nov 2009 10:36:54 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D5D7F28C24E for ; Thu, 5 Nov 2009 10:36:40 -0800 (PST) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5A1B340D1E for ; Thu, 5 Nov 2009 11:37:03 -0700 (MST) Message-ID: <4AF31B4E.6060605@stpeter.im> Date: Thu, 05 Nov 2009 11:37:02 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.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 Subject: [codec] preparing for the 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, 05 Nov 2009 18:36:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This message is intended to help participants prepare for the Codec BoF at IETF 76. Date: November 12, 2009 Time: 13:00-15:00 local time 04:00-06:00 UTC (Note: this is the evening of November 11 in North America!) Building: ANA Crowne Plaza Hiroshima Hotel 7-20 Nakamachi, Naka-ku Hiroshima 730-0037 JAPAN Tel: +81 82-241-1111 http://www.anacrowneplaza-hiroshima.jp/en/ Room: Orchid East http://tools.ietf.org/agenda/76/venue/?room=orchid-east Description: At IETF 75, the IETF held a BoF about the possibility of forming a working group to develop one or more audio codecs that would be optimized for use in Internet applications and that could be widely implemented and easily distributed among application developers, service operators, and end users. The BoF at IETF 75 was inconclusive regarding the matter of forming a working group. Since then, the two main open issues have been addressed through publication and discussion of Internet-Drafts about the proposed work processes and technical requirements of a Codec WG (see links below). In addition, the IETF and ITU-T have held discussions pursuant to the liaison agreement in place regarding cooperation and coordination of activities related to media codecs. The BoF at IETF 76 will build on this work in an attempt to reach consensus about whether to charter a working group. Agenda: http://www.ietf.org/proceedings/09nov/agenda/codec.txt Audio: http://videolab.uoregon.edu/events/ietf/ietf766.m3u Chat Room: xmpp:codec@jabber.ietf.org?join Chat Logs: http://www.ietf.org/jabber/logs/codec/ Draft Charter: http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt Summary of previous BoF: http://www.ietf.org/mail-archive/web/codec/current/msg00540.html Proposed work process: http://tools.ietf.org/html/draft-valin-codec-guidelines-02 Proposed requirements: http://tools.ietf.org/html/draft-valin-codec-requirements-02 Submitted codecs: http://tools.ietf.org/html/draft-spiritdsp-ipmr-00 http://tools.ietf.org/html/draft-valin-celt-codec-01 http://tools.ietf.org/html/draft-vos-silk-00 Other related drafts: http://tools.ietf.org/html/draft-hoene-avt-acs-requirements-00 Mailing list archives: http://www.ietf.org/mail-archive/web/codec/current/maillist.html Chairs: Eric Burger and Peter Saint-Andre Responsible AD: Cullen Jennings IAB Shepherd: Gregory Lebovitz HTH, 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/ iEYEARECAAYFAkrzG04ACgkQNL8k5A2w/vxx0gCdF1sdc8ws9BBpmzxLu7Ek491M UfoAoITGooePsUMZSTP6GtknKEnsJmGJ =/oDo -----END PGP SIGNATURE----- From koen.vos@skype.net Fri Nov 6 01:40: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 43C7228C15B for ; Fri, 6 Nov 2009 01:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGYg912OlSbZ for ; Fri, 6 Nov 2009 01:40:00 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 2764028C148 for ; Fri, 6 Nov 2009 01:40:00 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 1C6776064C841; Fri, 6 Nov 2009 09:40:23 +0000 (GMT) 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=q7v3INhpJT7e AzWsjgZe4xu0/hk=; b=K6AUXx9tRQdg6CM5PIqmUnjIpgR5lKI8a6ljCejP5rN7 vYDl9Nwoc5g+q6O3qb5gNuEuSCWMKroIeaLFwZbs9f/DqSa2QYB/qRGjr8dz9jUL jN7MrZVUsXtbwqQQQEyS9fmYlYKtq3Rlsy0oh02c33Kbej6Pj9VFi+sO7OW1yuI= 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=WqMC3aNvNhY6/eXkp7Ee hQJCQQRbkdHRgibRBGCj9KkTDAVFbw3ZvxPEVkHutDUsSRcbSdNasX3NNnA5i9wc oHbED/Mg55Yq+tOZHa7XMaVQre4QUbi46LIJeFoCneLJ31eU61SoTypR/CkYLMRL ULs9UpJFER0D/E/VGiKY4Tw= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 1A6556064C820; Fri, 6 Nov 2009 09:40:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9PDRl2QuA2C; Fri, 6 Nov 2009 09:40:22 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 69E026064C83B; Fri, 6 Nov 2009 09:40:22 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Fri, 06 Nov 2009 01:40:22 -0800 Message-ID: <20091106014022.100031ckka9a7wna@mail.skype.net> Date: Fri, 06 Nov 2009 01:40:22 -0800 From: Koen Vos To: Roni Even References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4af2be4d.141bf30a.239d.4d9a@mx.google.com> In-Reply-To: <4af2be4d.141bf30a.239d.4d9a@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) Cc: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 06 Nov 2009 09:40:01 -0000 Quoting Roni Even: > This is also tied to my view that if the group want to succeed it > should define one codec. Roni, could you please elaborate on what you mean by "one codec," and why you think it matters? AMR-WB has several modes, is that ok? H.264 consists a whole toolbox of models and modes (AVC, SVC, MVC), not all of them supported by all implementations of H.264. Is that ok? thanks, koen. From ron.even.tlv@gmail.com Fri Nov 6 05:35: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 87AAA3A635F for ; Fri, 6 Nov 2009 05:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r140vUUoBKWL for ; Fri, 6 Nov 2009 05:35:11 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 879DD3A6825 for ; Fri, 6 Nov 2009 05:35:11 -0800 (PST) Received: by ewy3 with SMTP id 3so1021438ewy.37 for ; Fri, 06 Nov 2009 05:35:28 -0800 (PST) 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=pcu1Vmk+79H45ka2zKND6nlEdgHb05E3oGHjSl9I5Rw=; b=w2EtLFB3tteolwjAnweB9Gvwl+S5J1l3GSBFSOQN1lckdjwMvUIRKYkEuJffayFcKJ 3O0n/0s08T0Fa/DQ7MdbJ3MHp0CTSRhuuM2aHQxb5EA0PJF7oj7ASiYCvrboUiMjKzlS FKreUfa0WEhqAf2o1EEhYLZAcd2FIYvSMtnsA= 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=JDmaU94kHCeMx5TB3UE/McgOq+a7Can2ES5A0b5Jw4RcGXtJKhvqdZFU7ECpjXRwfD ctdLF328A8Na3XuA6SCbTOCAHHNvpVipxrGOx33iG1BN91p3AOhiGkIfvFhIziRd3IE/ JbIHSzTWGJiJeqyjUGR/GoBWTi3qYjQauXqyw= Received: by 10.216.86.206 with SMTP id w56mr1343063wee.1.1257514528175; Fri, 06 Nov 2009 05:35:28 -0800 (PST) Received: from windows8d787f9 (host-112-47.meeting.ietf.org [133.93.112.47]) by mx.google.com with ESMTPS id j8sm129312gvb.19.2009.11.06.05.35.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Nov 2009 05:35:26 -0800 (PST) From: "Roni Even" To: "'Koen Vos'" References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4af2be4d.141bf30a.239d.4d9a@mx.google.com> <20091106014022.100031ckka9a7wna@mail.skype.net> In-Reply-To: <20091106014022.100031ckka9a7wna@mail.skype.net> Date: Fri, 6 Nov 2009 15:34:24 +0200 Message-ID: <4af4261e.0856100a.56d0.3f7e@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: AcpexSqd8TVtWtDlS/C3cZbCkN4W1wAHpzZw Content-Language: en-us Cc: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 06 Nov 2009 13:35:12 -0000 Hi Koen, The AMR-WB was defined as one codec as discussed in earlier thread by Ingemar for a specific application. The operation point is negotiable. This is a reasonable solution if the requirement will be for multiple operation points (in this case BW). What is not reasonable is to have two different codecs with overlapping operation points for the same application. You do not start with multiple application and the requirements for the multiple application and let everyone choose the subset they wants to support. If one of the worries is deployment by people who worry about the cost of deployment than one of the aspect of cost is the need to support multiple codecs. Cost is not only how much royalty you pay but also how you maintain your solution and support your customers. As for the video SVC and MVC are enhancements to AVC. Roni Even > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Friday, November 06, 2009 11:40 AM > To: Roni Even > Cc: 'Peter Saint-Andre'; 'Ingemar Johansson S'; codec@ietf.org > Subject: Re: [codec] Comments on BoF charter problem statement > > Quoting Roni Even: > > This is also tied to my view that if the group want to succeed it > > should define one codec. > > > Roni, could you please elaborate on what you mean by "one codec," and > why you think it matters? > > AMR-WB has several modes, is that ok? > H.264 consists a whole toolbox of models and modes (AVC, SVC, MVC), > not all of them supported by all implementations of H.264. Is that ok? > > thanks, > koen. From koen.vos@skype.net Fri Nov 6 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 9158E3A6A3E for ; Fri, 6 Nov 2009 06:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19ip2r8GU3Vb for ; Fri, 6 Nov 2009 06:17:19 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 461413A6825 for ; Fri, 6 Nov 2009 06:17:19 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 1C1746064C88D; Fri, 6 Nov 2009 14:17:42 +0000 (GMT) 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=OH9lZyHxabSw mmWXOnezvEtmZQk=; b=QYBFForm+EdXnICZ2k+YKLImWh812tNRkGsGLIk/HDxN VUS/ol7HPwOCnEeifxy3ZV+CJFmGagjDW8+OqK/+2QerxcDTWl+XHL3N57eU4MxC N5YcrBdxGgy8fkKlLVXIS7IH83jknx2Np5jBt5rv0Yal6O+wfbP3TPe/IV9YAKU= 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=QOhnL+oUqrdK3UtduuHy EGt1mrwU04t28IUuDQVuXpNhqZfCIH/7S8Fv1CTHBROWpIkxqH37/uiN6FmQtAMG Engx4+mwUtlP9adxoyPBPxId8Q4IbHInlzSZRHcRD+hqkt4MlxWXppTcmBMmF00W SZjUzSY2vr3VsP/AL9YuWlk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 163AD605D7583; Fri, 6 Nov 2009 14:17:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRxJ5XjHhy-A; Fri, 6 Nov 2009 14:17:41 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 5C8F86064C88D; Fri, 6 Nov 2009 14:17:41 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Fri, 06 Nov 2009 06:17:41 -0800 Message-ID: <20091106061741.84362mp7u4q0t6v9@mail.skype.net> Date: Fri, 06 Nov 2009 06:17:41 -0800 From: Koen Vos To: Roni Even References: <130EBB38279E9847BAAAE0B8F9905F8C0228D54C@esealmw109.eemea.ericsson.se> <4AF1EF3D.9010503@stpeter.im> <4af2be4d.141bf30a.239d.4d9a@mx.google.com> <20091106014022.100031ckka9a7wna@mail.skype.net> <4af4261e.0856100a.56d0.3f7e@mx.google.com> In-Reply-To: <4af4261e.0856100a.56d0.3f7e@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) Cc: 'Ingemar Johansson S' , codec@ietf.org Subject: Re: [codec] Comments on BoF charter problem statement X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 06 Nov 2009 14:17:20 -0000 Hi Roni, Maybe we should require that we will have a single codec, possibly with multiple modes - just to avoid confusion from circular definitions. Is your wish simply to guarantee that all compliant implementations will be able to talk to each other? That could for instance be guaranteed by requiring that any implementation needs to support more than half of the modes in the standard. > What is not reasonable is to have two different > codecs with overlapping operation points for the same application. Not sure what you mean here, can you give an example? The same codec under two different names? best, koen. Quoting Roni Even: > Hi Koen, > The AMR-WB was defined as one codec as discussed in earlier thread by > Ingemar for a specific application. The operation point is negotiable. This > is a reasonable solution if the requirement will be for multiple operation > points (in this case BW). What is not reasonable is to have two different > codecs with overlapping operation points for the same application. You do > not start with multiple application and the requirements for the multiple > application and let everyone choose the subset they wants to support. > If one of the worries is deployment by people who worry about the cost of > deployment than one of the aspect of cost is the need to support multiple > codecs. Cost is not only how much royalty you pay but also how you maintain > your solution and support your customers. > As for the video SVC and MVC are enhancements to AVC. > Roni Even > >> -----Original Message----- >> From: Koen Vos [mailto:koen.vos@skype.net] >> Sent: Friday, November 06, 2009 11:40 AM >> To: Roni Even >> Cc: 'Peter Saint-Andre'; 'Ingemar Johansson S'; codec@ietf.org >> Subject: Re: [codec] Comments on BoF charter problem statement >> >> Quoting Roni Even: >> > This is also tied to my view that if the group want to succeed it >> > should define one codec. >> >> >> Roni, could you please elaborate on what you mean by "one codec," and >> why you think it matters? >> >> AMR-WB has several modes, is that ok? >> H.264 consists a whole toolbox of models and modes (AVC, SVC, MVC), >> not all of them supported by all implementations of H.264. Is that ok? >> >> thanks, >> koen. > > From SRS0=LE/iW+=G2=sipforum.org=eburger@srs.bis.na.blackberry.com Fri Nov 6 08:54:54 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091923A68FB for ; Fri, 6 Nov 2009 08:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbgvwkL+wW1D for ; Fri, 6 Nov 2009 08:54:53 -0800 (PST) Received: from smtp17.bis.na.blackberry.com (smtp17.bis.na.blackberry.com [216.9.248.59]) by core3.amsl.com (Postfix) with ESMTP id 151E43A6358 for ; Fri, 6 Nov 2009 08:54:52 -0800 (PST) Received: from bda380.bisx.prod.on.blackberry (bda380.bisx.prod.on.blackberry [172.20.234.80]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id nA6GtMtN027007 for ; Fri, 6 Nov 2009 16:55:22 GMT Received: from bda380.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda380.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id nA6GtDPL008895 for ; Fri, 6 Nov 2009 16:55:13 GMT X-rim-org-msg-ref-id: 1690371232 Message-ID: <1690371232-1257526512-cardhu_decombobulator_blackberry.rim.net-498180772-@bda365.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: codec@ietf.org From: "eburger" Date: Fri, 6 Nov 2009 16:35:52 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Subject: [codec] Scribes & Jabber Scribes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@sipforum.org 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, 06 Nov 2009 16:59:47 -0000 V2UgbmVlZCBudW1lcm91cyB2b2x1bnRlZXJzIGZvciBTY3JpYmVzLCBKYWJiZXIgU2NyaWJlcywg YW5kIFBzeWNoaWMgTWVkaXVtcyAoSmFiYmVyIENoYXQgUm9vbSBSZWxheSBQZW9wbGUpIGZvciB0 aGUgQ29kZWMgQk9GLiANCg0KUGxlYXNlIHJlc3BvbmQgZGlyZWN0bHkgdG8gUGV0ZXIgYW5kIG1l IGlmIHlvdSBhcmUgd2lsbGluZyB0byBkbyBvbmUgb2YgdGhlc2Ugam9icy4gWW91IHdpbGwgYmUg aW1tb3J0YWxpemVkIGluIHRoZSBtaW51dGVzIGFuZCBzbGlkZXMgaWYgeW91IGRvLiANCi0tDQpE ci4gRXJpYyBCdXJnZXIsIENoYWlybWFuIG9mIHRoZSBCb2FyZCwgU0lQIEZvcnVtDQo8aHR0cDov L3d3dy5zaXBmb3J1bS5vcmc+DQpTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZTsgc29ycnkgaWYg dGVyc2UuIEFsbCBtb2JpbGUgdXNlcnMgbmVlZCBsZW1vbmFkZS4gIFNlZSA8aHR0cDovL3d3dy5z dGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZT4gZm9yIG1vcmUgaW5mb3JtYXRpb24u From mknappe@juniper.net Mon Nov 9 11: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 B12A53A69FB for ; Mon, 9 Nov 2009 11:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 A8bcqbc7Y9ax for ; Mon, 9 Nov 2009 11:15:33 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 80FA23A69D5 for ; Mon, 9 Nov 2009 11:15:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSvhqZxPOmxL2+uX9XLx0dei8fnXF1gRO@postini.com; Mon, 09 Nov 2009 11:16:00 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 9 Nov 2009 11:11:43 -0800 From: Michael Knappe To: Michael Knappe , "bens@alum.mit.edu" , Slava Borilin Date: Mon, 9 Nov 2009 11:11:50 -0800 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpT5N/tS2brQjYASqibRoJifZxwKACmJ4tUAABj1kYCvFv3bw== 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Nov 2009 19:15:34 -0000 Having not heard any further comments on this thread, are we in consensus w= ith the text as refined below? This would be an addition to section 5.8 (Le= gacy compatibility) in the next revision of draft-valin-codec-requirements. Cheers, Mike On 10/26/09 1:58 PM, "Michael Knappe" wrote: For ease of reading, incorporating the edits it would read as: The systems providing input to the encoder and receiving output from the de= coder may be far from ideal in actual use. Input and output audio streams = may be corrupted by compounding non-linear artifacts from analog hardware a= nd digital processing. The codecs to be developed should be tested to ensur= e that they degrade gracefully under adverse audio conditions. Types of di= gital corruption that may be tested include tandem encoding with similar an= d different codecs, low-quality resampling, and digital clipping. Types of= analog corruption that may be tested include microphones with substantial = background noise, analog clipping, and loudspeaker distortion. No specific = end-to-end quality requirements are mandated for use with the proposed code= c. It is advisable, however, that several typical in-situ environments/proc= essing chains be specified for the purpose of benchmarking end-to-end quali= ty with the proposed codec. On 10/26/09 1:47 PM, "Michael Knappe" wrote: Benjamin, Well worded paragraph, thanks. I would add just some minor edits and a scop= ing sentence at the end. My proposed changes are in italics. Cheers, Mike Audio Corruption Robustness The systems providing input to the encoder and s//receiving/ output from th= e decoder s/are likely to/may/ be far from ideal in actual use. Input and output audio str= eams may be corrupted by s//compounding non-linear/ artifacts from analog hardwa= re and digital processing. The codecs to be developed should be tested to e= nsure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. s//No specif= ic end-to-end quality requirements are mandated for use with the proposed c= odec. It is advisable, however, that several typical in-situ environments/p= rocessing chains be specified for the purpose of benchmarking end-to-end qu= ality with the proposed codec./ """ " On 10/23/09 6:29 AM, "Benjamin M. Schwartz" wrot= e: Slava Borilin wrote: > Henry, e2e (or p2p) is cool but what about Legal interception for > example in this case, which every cellco has to implemenet? Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode. The encoded packets can just be copied to the additional receiver. To address the "tandeming" issue, I think the following text should be added to the "Basic Requirements" or "Additional Considerations": """ Audio Corruption Robustness The systems providing input to the encoder and output from the decoder are likely to be far from ideal in actual use. Input and output audio streams may be corrupted by artifacts from analog hardware and digital processing. The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. """ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Mon Nov 9 12:41: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 3F66B3A687B for ; Mon, 9 Nov 2009 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 kToA6vz7OlV3 for ; Mon, 9 Nov 2009 12:41:11 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id DEC713A67A6 for ; Mon, 9 Nov 2009 12:41:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSvh+fiDlc/TD+mAUOqT0IEJxLVqtOSNi@postini.com; Mon, 09 Nov 2009 12:41:37 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 9 Nov 2009 12:39:56 -0800 From: Michael Knappe To: "Michael Ramalho (mramalho)" , Roni Even , Peter Saint-Andre , "codec@ietf.org" Date: Mon, 9 Nov 2009 12:40:03 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAIIsicABcPGr7g== 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Nov 2009 20:41:13 -0000 In looking at building the table illustrating codec applications vs. criter= ia, the problem space appears to be parameterized by three major criteria: A) end-to-end latency: objectively, achieving the least amount of latency p= ossible is better for real-time communications. Psychoacoustically, achievi= ng end-to-end delays less than 150 ms has diminishing quality returns for h= uman speech communication, while the specific application of live music int= eraction requires less than 50 ms end-to-end delay (and ideally 25 ms or le= ss). Clearly, the live music interaction requirement requires not only a lo= w delay codec, but also a carefully controlled, minimal jitter and very low= propagation delay network. The 150 ms requirement, on the other hand, has = more leeway in allocating latency budget between codec algorithmic delays a= nd other sources of delay in the network. Bottom line: live music interacti= on appears to be an outlier relative to other codec applications with respe= ct to end-to-end latency. B) number of channels: objectively, recreating as complete a representation= of the original source sound field is better for real-time communications.= For two-party speech communications, source material from a single microph= one can obviously be transmitted with a single audio channel, with the deci= sion to present the signal to one or more audio outputs made at the receivi= ng end (e.g. Single output telephone handset receiver, dual output binaura= l headphones). However, even for two-party speech communications with a sin= gle talker at each end, speakerphone communications can be improved by tran= smitting two channels of audio from two microphones on the speakerphone, th= at when listened to with stereo headphones at the receiving end, the 'barre= l effect' common to mono microphone speakerphones is greatly reduced. This = concept of transmission of soundfield along with speech (or music) becomes = more important as more complex acoustic environments are involved (includin= g the creation of virtual acoustic environments with multiple talker source= s mixed into a common soundfield). Thus, the need for more transmission cha= nnels should increase with the application's desire to produce a more immer= sive environment. Bottom line: although single party source material in two= -party communications could benefit from more than one transmission channel= , applications like advanced conferencing / telepresence, gaming and live = music interaction are likely to benefit the most from multi-channel environ= ments. C) frequency bandwidth: objectively, reproducing the widest possible audio = frequency bandwidth to cover the frequency content of the original source m= aterial is better for real-time communications. Human speech has been trans= mitted with intelligibility limitations for decades over bandwidths as narr= ow as 3 kHz. Speech intelligibility improves significantly as bandwidth is = increased to 6 or 7 kHz, with diminishing intelligibility improvements as b= andwidth is increased past this, even though the subjective measure of 'nat= uralness' may continue to improve up to the limits of human hearing. This c= oncept of 'intelligibility' and 'naturalness' also applies to music - an ex= ample of intelligibility here could be discerning between an oboe and basso= on in a symphony, while naturalness is more a measure of how 'real' that si= ngled-out oboe sounds. It would appear to follow that the more complex a so= und source and soundfield that we wish to transmit, the wider the bandwidth= we should encode. In the high fidelity and professional recording domains,= this quest for 'naturalness' has extended beyond what we typically feel th= e human limitation of 20 kHz auditory perception is, to sample rates up to = 192 kHz and beyond. Bottom line: human speech in simple two-party interact= ions will receive the most benefit in transmitting the first 7 kHz of audio= bandwidth, but more complex source material will continue to benefit from = wider audio bandwidths, possibly extending beyond the traditional 20 kHz 'a= uditory limit'. I have not included in the above criteria the concept of fundamental codec = type - many previous telephony compression algorithms rely on parameterizat= ions of the human mechanics of the generation of speech (e.g. CELP based co= decs) which do not translate well to parameterization of other source mater= ial such as music, whereas auditory receiving end perceptual audio paramete= rizations tend to work well for both music and speech, but historically hav= e had latency limitations. My thought here, for this proposed codec, is tha= t we should not be looking for a codec where a priori knowledge of the type= of audio material is required (although certainly the codec could be desig= ned to optimize its performance dynamically for varying types of source mat= erial). Also not included above are fundamental concepts of distortion and noise - = for me, this is a secondary requirement that once A,B and C are established= , that sufficient signal-to-noise ratios be maintained to not undermine int= elligibility and naturalness goals of the transmission. This may mean a nat= ural progression to higher SNR targets for wider bandwidth, more immersive = environments. Thoughts? Mike On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wrote= : All, I strongly agree with Roni here, re: "I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec." Let's consider two SIMPLE examples. Example 1 - Let's assume I have an application that requires a certain linearity within a certain BW ranges (need > 25 dB of waveform linearity in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application uses adaptive signal processing techniques and linearity is important. Perhaps it is a far-end echo cancellation application, or a microphone beam array processing application that processes multiple streams at the receiver end. I could go on with any number of interesting examples. Note that such an applications would generate specific REQUIREMENTS to meet these use cases. The candidate codec would probably be waveform-based (at least in the bands having the linearity requirements). Example 2 - Many voice codecs use spectral techniques (such as spectral band replication, SBR) above 4k. Such codecs, while potentially capturing the spectral content well enough, will NOT preserve the phase (as the phase information is not in the compressed representation). Such a codec would NOT meet the simple > 20 dB linearity requirement (of the 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to a human - perhaps, as the human auditory system is not as sensitive to phase in this region. Additionally, many of these codecs are speech model based - and typically have < 20 dB of linearity on unvoiced speech even in 0 - 4k region. (You could throw in an entropy coding stage after the model to fix this - at the cost of BW - but I digress). One might ask why codec manufacturers use techniques such as SBR? Answer: because they are generally more efficient (precisely because they don't require as much phase information in the compressed domain) and sound good to humans. I could go on and on ... but I sincerely doubt that ONE MAGICAL codec can satisfy both examples above ... because both APPLICATIONS would result in different REQUIREMENTS. I think the rush to a "single-codec" requirements here is premature ... I agree with Roni ... one size does not fit all. Given the simple examples above - isn't it clear that we need to define applications (one might call them use cases) - and then requirements for them - before we determine how a given candidate satisfies the requirements? At a minimum, I see two legitimate codec classes: CLASS 1) codecs that are bandwidth efficient and sound good to humans (and perhaps satisfy tendeming or tone pass-through requirements), and CLASS 2) codecs whose output may later be processed by sophisticated signal processing functions (high-quality mixing, many classification-based applications such as speaker/sound/intrusion identification) that have SNR/waveform/distortion criteria generally exceeding CLASS 1. Granted, we should make each use case as broad as possible so as not to have too many of them. Once one codec is standardized for a particular application type - a subsequent candidate codec/application would need to prove it is "sufficiently different" from the existing codec(s) to go further. The WG chairs need to exert leadership to ensure the desired result (of the smallest number of codecs spanning the greatest application space). IF a given codec meets the requirements of its use case AND that use case is valid THEN I (for one) don't have an issue with the IETF "rubber stamping" of it. If you have a specific use case - then get together with other similarly minded folks and generate a "use case" draft and then a requirements draft for that use case. Don't try to solve world hunger in one step. Off Soapbox, Michael Ramalho, Ph.D. [Flames expected ... but please try to disprove my debate above when doing so ... I dislike flames that do not disprove a thesis ;-) ] PS - I think CLASS 1 codecs should be addressed first by the WG ... and later consider other classes as people advocate for their use case. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, October 30, 2009 6:34 PM To: 'Peter Saint-Andre'; codec@ietf.org Subject: Re: [codec] questions to be answered Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > 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/ > > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =3D9vPK > -----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 eburger@standardstrack.com Mon Nov 9 16:58: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 F067A3A69DE for ; Mon, 9 Nov 2009 16:58:39 -0800 (PST) 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 fdoISUoCux5q for ; Mon, 9 Nov 2009 16:58:39 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 5255C3A6959 for ; Mon, 9 Nov 2009 16:58:39 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N7f4U-0002Hr-JJ for codec@ietf.org; Mon, 09 Nov 2009 16:58:58 -0800 Message-Id: <730D3821-6FEC-439D-B952-9406105523BA@standardstrack.com> From: Eric Burger 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 v936) Date: Tue, 10 Nov 2009 09:59:02 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [codec] Scribes & Jabber Scribes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 00:58:40 -0000 We still need more Scribes & Jabber Scribes. Please get back to me ASAP if you can volunteer. This will be a packed session, and we will need multiple scribes. Thanks. From koen.vos@skype.net Mon Nov 9 19:29: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 336F23A6824 for ; Mon, 9 Nov 2009 19:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U9MlnLyRyMdL for ; Mon, 9 Nov 2009 19:29:07 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 0042B3A681B for ; Mon, 9 Nov 2009 19:29:06 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8B47D60643C22; Tue, 10 Nov 2009 03:29:33 +0000 (GMT) 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=pLbKYDKqIcum BFiLoAuppVJpb/U=; b=hfumtDE4KFM2TeWqqh7jwHsXev1DlO510kXzQNd91qaY +p6SvkRy3No67kFgEnzWGOqD+dEdk5uKJnrGKQfN1kSKlcG/QctCRQ+iGnz9Z2v/ nE75Iqk+xl4ps3NltaFtwjsGaZbSLdtdZUzYMOjQY4TD4tF+RLONug9Ol/RO2j8= 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=vIMNo0sni3MkzJBeLj0S xwjaYPcuRapNftxuSL6lyCPwTLKZNb8dwZVGcu8sgIvB64DeThZyGCicegJXTu+1 nWZ8n1Y6YN2MbbDB+PXMbS719LA27JpOF/YE5uB49QQ+LW9NP6VDzo3bsluOr9N4 MDwlKwO7KXQc1bVdLJmn85g= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 88B17605D63D1; Tue, 10 Nov 2009 03:29:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjAafGmBjCcq; Tue, 10 Nov 2009 03:29:24 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 19BCB60643C4A; Tue, 10 Nov 2009 03:29:24 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Mon, 09 Nov 2009 19:29:24 -0800 Message-ID: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> Date: Mon, 09 Nov 2009 19:29:24 -0800 From: Koen Vos To: Michael Knappe References: 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) Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 03:29:09 -0000 These are good requirements at the high end, e.g. for virtual presence and interactive music. At the low end, for basic voice, I think also -and sometimes more- important are: - Bitrate - Robustness to packet loss - Complexity - Real-time scalability (the ability to adjust parameters) These aspects determine how well communications work in challenging scenarios like over wireless networks and on embedded devices. koen. Quoting Michael Knappe: > In looking at building the table illustrating codec applications vs. > criteria, the problem space appears to be parameterized by three > major criteria: > > A) end-to-end latency: objectively, achieving the least amount of > latency possible is better for real-time communications. > Psychoacoustically, achieving end-to-end delays less than 150 ms has > diminishing quality returns for human speech communication, while > the specific application of live music interaction requires less > than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, > the live music interaction requirement requires not only a low delay > codec, but also a carefully controlled, minimal jitter and very low > propagation delay network. The 150 ms requirement, on the other > hand, has more leeway in allocating latency budget between codec > algorithmic delays and other sources of delay in the network. Bottom > line: live music interaction appears to be an outlier relative to > other codec applications with respect to end-to-end latency. > > B) number of channels: objectively, recreating as complete a > representation of the original source sound field is better for > real-time communications. For two-party speech communications, > source material from a single microphone can obviously be > transmitted with a single audio channel, with the decision to > present the signal to one or more audio outputs made at the > receiving end (e.g. Single output telephone handset receiver, dual > output binaural headphones). However, even for two-party speech > communications with a single talker at each end, speakerphone > communications can be improved by transmitting two channels of audio > from two microphones on the speakerphone, that when listened to with > stereo headphones at the receiving end, the 'barrel effect' common > to mono microphone speakerphones is greatly reduced. This concept of > transmission of soundfield along with speech (or music) becomes more > important as more complex acoustic environments are involved > (including the creation > of virtual acoustic environments with multiple talker sources mixed > into a common soundfield). Thus, the need for more transmission > channels should increase with the application's desire to produce a > more immersive environment. Bottom line: although single party > source material in two-party communications could benefit from more > than one transmission channel, applications like advanced > conferencing / telepresence, gaming and live music interaction are > likely to benefit the most from multi-channel environments. > > C) frequency bandwidth: objectively, reproducing the widest possible > audio frequency bandwidth to cover the frequency content of the > original source material is better for real-time communications. > Human speech has been transmitted with intelligibility limitations > for decades over bandwidths as narrow as 3 kHz. Speech > intelligibility improves significantly as bandwidth is increased to > 6 or 7 kHz, with diminishing intelligibility improvements as > bandwidth is increased past this, even though the subjective measure > of 'naturalness' may continue to improve up to the limits of human > hearing. This concept of 'intelligibility' and 'naturalness' also > applies to music - an example of intelligibility here could be > discerning between an oboe and bassoon in a symphony, while > naturalness is more a measure of how 'real' that singled-out oboe > sounds. It would appear to follow that the more complex a sound > source and soundfield that we wish to transmit, the wider the > bandwidth we should enco > de. In the high fidelity and professional recording domains, this > quest for 'naturalness' has extended beyond what we typically feel > the human limitation of 20 kHz auditory perception is, to sample > rates up to 192 kHz and beyond. Bottom line: human speech in simple > two-party interactions will receive the most benefit in transmitting > the first 7 kHz of audio bandwidth, but more complex source material > will continue to benefit from wider audio bandwidths, possibly > extending beyond the traditional 20 kHz 'auditory limit'. > > I have not included in the above criteria the concept of fundamental > codec type - many previous telephony compression algorithms rely on > parameterizations of the human mechanics of the generation of speech > (e.g. CELP based codecs) which do not translate well to > parameterization of other source material such as music, whereas > auditory receiving end perceptual audio parameterizations tend to > work well for both music and speech, but historically have had > latency limitations. My thought here, for this proposed codec, is > that we should not be looking for a codec where a priori knowledge > of the type of audio material is required (although certainly the > codec could be designed to optimize its performance dynamically for > varying types of source material). > > Also not included above are fundamental concepts of distortion and > noise - for me, this is a secondary requirement that once A,B and C > are established, that sufficient signal-to-noise ratios be > maintained to not undermine intelligibility and naturalness goals of > the transmission. This may mean a natural progression to higher SNR > targets for wider bandwidth, more immersive environments. > > Thoughts? > > Mike > > On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wrote: > > All, > > I strongly agree with Roni here, re: "I think that the if the charter > describes a list of applications it need to have a separate requirement > for each application on which this proposed group is going to develop a > separate codec." > > Let's consider two SIMPLE examples. > > Example 1 - Let's assume I have an application that requires a certain > linearity within a certain BW ranges (need > 25 dB of waveform linearity > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application > uses adaptive signal processing techniques and linearity is important. > Perhaps it is a far-end echo cancellation application, or a microphone > beam array processing application that processes multiple streams at the > receiver end. I could go on with any number of interesting examples. > Note that such an applications would generate specific REQUIREMENTS to > meet these use cases. The candidate codec would probably be > waveform-based (at least in the bands having the linearity > requirements). > > Example 2 - Many voice codecs use spectral techniques (such as spectral > band replication, SBR) above 4k. Such codecs, while potentially > capturing the spectral content well enough, will NOT preserve the phase > (as the phase information is not in the compressed representation). Such > a codec would NOT meet the simple > 20 dB linearity requirement (of the > 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to > a human - perhaps, as the human auditory system is not as sensitive to > phase in this region. Additionally, many of these codecs are speech > model based - and typically have < 20 dB of linearity on unvoiced speech > even in 0 - 4k region. (You could throw in an entropy coding stage after > the model to fix this - at the cost of BW - but I digress). > > One might ask why codec manufacturers use techniques such as SBR? > Answer: because they are generally more efficient (precisely because > they don't require as much phase information in the compressed domain) > and sound good to humans. > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS. > > I think the rush to a "single-codec" requirements here is premature ... > I agree with Roni ... one size does not fit all. > > Given the simple examples above - isn't it clear that we need to define > applications (one might call them use cases) - and then requirements for > them - before we determine how a given candidate satisfies the > requirements? > > At a minimum, I see two legitimate codec classes: > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and > > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. > > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). > > IF > a given codec meets the requirements of its use case > AND > that use case is valid > THEN > I (for one) don't have an issue with the IETF "rubber stamping" of it. > > If you have a specific use case - then get together with other similarly > minded folks and generate a "use case" draft and then a requirements > draft for that use case. Don't try to solve world hunger in one step. > > Off Soapbox, > > Michael Ramalho, Ph.D. > > [Flames expected ... but please try to disprove my debate above when > doing so ... I dislike flames that do not disprove a thesis ;-) ] > > PS - I think CLASS 1 codecs should be addressed first by the WG ... and > later consider other classes as people advocate for their use case. > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Friday, October 30, 2009 6:34 PM > To: 'Peter Saint-Andre'; codec@ietf.org > Subject: Re: [codec] questions to be answered > > Hi Peter, > I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how to > decide which codecs are in scope for this working group is agreed. My > view > that this issue is not addressed since I assume that all the parties > that > submitted candidate codecs would like their codecs to be approved at the > IETF which will make this group a rubber stamping WG. > I think that the if the charter describes a list of applications it need > to > have a separate requirement for each application on which this proposed > group is going to develop a separate codec. If there is one requirement > document for all apllications there should be one codec to address it. > > Thanks > Roni Even > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Peter Saint-Andre >> Sent: Friday, October 30, 2009 10:12 PM >> To: codec@ietf.org >> Subject: [codec] questions to be answered >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> RFC 5434 has a list of questions that need to be answered before a WG >> is >> formed, and I think we have fairly clear answers to these questions: >> >> 1. Is there a problem that needs solving? >> >> (Yes, see problem statement in charter.) >> >> 2. Is the scope of the problem well defined and understood? >> >> (Yes, see objectives in charter, guidelines I-D, and requirements > I-D.) >> >> 3. Is there agreement on what the WG needs to deliver? >> >> (Yes, see deliverables in charter, guidelines I-D, and requirements I- >> D.) >> >> 4. Are there enough IETF participants to do the work? >> >> (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >> >> 5. Does the WG have a reasonable probability of success? >> >> (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >> emphasis on "reasonable" because we won't know until we try.) >> >> 6. Is the IETF is the right place to do the work? >> >> (Maybe. I think this is the major item to clarify at the BoF.) >> >> 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/ >> >> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >> =9vPK >> -----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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From hsinnrei@adobe.com Mon Nov 9 20:46: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 1C1A33A68B1 for ; Mon, 9 Nov 2009 20:46:02 -0800 (PST) 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=[AWL=-0.000, 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 gIs5Vm1NkiCE for ; Mon, 9 Nov 2009 20:45:59 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 5F5803A690B for ; Mon, 9 Nov 2009 20:45:56 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSvjwHg/8F395+WUCXqgbp3+nLal4Cl5S@postini.com; Mon, 09 Nov 2009 20:46:25 PST 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 nAA4d7Hc028353; Mon, 9 Nov 2009 20:39:07 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nAA4kL07015790; Mon, 9 Nov 2009 20:46:21 -0800 (PST) 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; Mon, 9 Nov 2009 20:46:21 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 9 Nov 2009 20:46:21 -0800 From: Henry Sinnreich To: Koen Vos , Michael Knappe Date: Mon, 9 Nov 2009 20:46:19 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcphtgwKm4QMb9leQ+m4RErOB+O+IQACrJnS Message-ID: In-Reply-To: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C71F1F2B10EC3hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 04:46:02 -0000 --_000_C71F1F2B10EC3hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >- Robustness to packet loss Are you thinking of burst packet loss or random distributed packet loss? And what would be the metrics and values for either? If we have no metrics and no credible values, I suggest to forget this rat = hole. Broadband Internet has IMO and negligible packet loss, except for congestio= n events where the codec cannot do anything anyway. Packet loss was a big deal in old analog modem times and pre-3G/4G wireless= networks :-) My two cents, Henry On 11/10/09 12:29 PM, "Koen Vos" wrote: These are good requirements at the high end, e.g. for virtual presence and interactive music. At the low end, for basic voice, I think also -and sometimes more- important are: - Bitrate - Robustness to packet loss - Complexity - Real-time scalability (the ability to adjust parameters) These aspects determine how well communications work in challenging scenarios like over wireless networks and on embedded devices. koen. Quoting Michael Knappe: > In looking at building the table illustrating codec applications vs. > criteria, the problem space appears to be parameterized by three > major criteria: > > A) end-to-end latency: objectively, achieving the least amount of > latency possible is better for real-time communications. > Psychoacoustically, achieving end-to-end delays less than 150 ms has > diminishing quality returns for human speech communication, while > the specific application of live music interaction requires less > than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, > the live music interaction requirement requires not only a low delay > codec, but also a carefully controlled, minimal jitter and very low > propagation delay network. The 150 ms requirement, on the other > hand, has more leeway in allocating latency budget between codec > algorithmic delays and other sources of delay in the network. Bottom > line: live music interaction appears to be an outlier relative to > other codec applications with respect to end-to-end latency. > > B) number of channels: objectively, recreating as complete a > representation of the original source sound field is better for > real-time communications. For two-party speech communications, > source material from a single microphone can obviously be > transmitted with a single audio channel, with the decision to > present the signal to one or more audio outputs made at the > receiving end (e.g. Single output telephone handset receiver, dual > output binaural headphones). However, even for two-party speech > communications with a single talker at each end, speakerphone > communications can be improved by transmitting two channels of audio > from two microphones on the speakerphone, that when listened to with > stereo headphones at the receiving end, the 'barrel effect' common > to mono microphone speakerphones is greatly reduced. This concept of > transmission of soundfield along with speech (or music) becomes more > important as more complex acoustic environments are involved > (including the creation > of virtual acoustic environments with multiple talker sources mixed > into a common soundfield). Thus, the need for more transmission > channels should increase with the application's desire to produce a > more immersive environment. Bottom line: although single party > source material in two-party communications could benefit from more > than one transmission channel, applications like advanced > conferencing / telepresence, gaming and live music interaction are > likely to benefit the most from multi-channel environments. > > C) frequency bandwidth: objectively, reproducing the widest possible > audio frequency bandwidth to cover the frequency content of the > original source material is better for real-time communications. > Human speech has been transmitted with intelligibility limitations > for decades over bandwidths as narrow as 3 kHz. Speech > intelligibility improves significantly as bandwidth is increased to > 6 or 7 kHz, with diminishing intelligibility improvements as > bandwidth is increased past this, even though the subjective measure > of 'naturalness' may continue to improve up to the limits of human > hearing. This concept of 'intelligibility' and 'naturalness' also > applies to music - an example of intelligibility here could be > discerning between an oboe and bassoon in a symphony, while > naturalness is more a measure of how 'real' that singled-out oboe > sounds. It would appear to follow that the more complex a sound > source and soundfield that we wish to transmit, the wider the > bandwidth we should enco > de. In the high fidelity and professional recording domains, this > quest for 'naturalness' has extended beyond what we typically feel > the human limitation of 20 kHz auditory perception is, to sample > rates up to 192 kHz and beyond. Bottom line: human speech in simple > two-party interactions will receive the most benefit in transmitting > the first 7 kHz of audio bandwidth, but more complex source material > will continue to benefit from wider audio bandwidths, possibly > extending beyond the traditional 20 kHz 'auditory limit'. > > I have not included in the above criteria the concept of fundamental > codec type - many previous telephony compression algorithms rely on > parameterizations of the human mechanics of the generation of speech > (e.g. CELP based codecs) which do not translate well to > parameterization of other source material such as music, whereas > auditory receiving end perceptual audio parameterizations tend to > work well for both music and speech, but historically have had > latency limitations. My thought here, for this proposed codec, is > that we should not be looking for a codec where a priori knowledge > of the type of audio material is required (although certainly the > codec could be designed to optimize its performance dynamically for > varying types of source material). > > Also not included above are fundamental concepts of distortion and > noise - for me, this is a secondary requirement that once A,B and C > are established, that sufficient signal-to-noise ratios be > maintained to not undermine intelligibility and naturalness goals of > the transmission. This may mean a natural progression to higher SNR > targets for wider bandwidth, more immersive environments. > > Thoughts? > > Mike > > On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wro= te: > > All, > > I strongly agree with Roni here, re: "I think that the if the charter > describes a list of applications it need to have a separate requirement > for each application on which this proposed group is going to develop a > separate codec." > > Let's consider two SIMPLE examples. > > Example 1 - Let's assume I have an application that requires a certain > linearity within a certain BW ranges (need > 25 dB of waveform linearity > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application > uses adaptive signal processing techniques and linearity is important. > Perhaps it is a far-end echo cancellation application, or a microphone > beam array processing application that processes multiple streams at the > receiver end. I could go on with any number of interesting examples. > Note that such an applications would generate specific REQUIREMENTS to > meet these use cases. The candidate codec would probably be > waveform-based (at least in the bands having the linearity > requirements). > > Example 2 - Many voice codecs use spectral techniques (such as spectral > band replication, SBR) above 4k. Such codecs, while potentially > capturing the spectral content well enough, will NOT preserve the phase > (as the phase information is not in the compressed representation). Such > a codec would NOT meet the simple > 20 dB linearity requirement (of the > 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to > a human - perhaps, as the human auditory system is not as sensitive to > phase in this region. Additionally, many of these codecs are speech > model based - and typically have < 20 dB of linearity on unvoiced speech > even in 0 - 4k region. (You could throw in an entropy coding stage after > the model to fix this - at the cost of BW - but I digress). > > One might ask why codec manufacturers use techniques such as SBR? > Answer: because they are generally more efficient (precisely because > they don't require as much phase information in the compressed domain) > and sound good to humans. > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS. > > I think the rush to a "single-codec" requirements here is premature ... > I agree with Roni ... one size does not fit all. > > Given the simple examples above - isn't it clear that we need to define > applications (one might call them use cases) - and then requirements for > them - before we determine how a given candidate satisfies the > requirements? > > At a minimum, I see two legitimate codec classes: > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and > > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. > > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). > > IF > a given codec meets the requirements of its use case > AND > that use case is valid > THEN > I (for one) don't have an issue with the IETF "rubber stamping" of it. > > If you have a specific use case - then get together with other similarly > minded folks and generate a "use case" draft and then a requirements > draft for that use case. Don't try to solve world hunger in one step. > > Off Soapbox, > > Michael Ramalho, Ph.D. > > [Flames expected ... but please try to disprove my debate above when > doing so ... I dislike flames that do not disprove a thesis ;-) ] > > PS - I think CLASS 1 codecs should be addressed first by the WG ... and > later consider other classes as people advocate for their use case. > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Friday, October 30, 2009 6:34 PM > To: 'Peter Saint-Andre'; codec@ietf.org > Subject: Re: [codec] questions to be answered > > Hi Peter, > I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how to > decide which codecs are in scope for this working group is agreed. My > view > that this issue is not addressed since I assume that all the parties > that > submitted candidate codecs would like their codecs to be approved at the > IETF which will make this group a rubber stamping WG. > I think that the if the charter describes a list of applications it need > to > have a separate requirement for each application on which this proposed > group is going to develop a separate codec. If there is one requirement > document for all apllications there should be one codec to address it. > > Thanks > Roni Even > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Peter Saint-Andre >> Sent: Friday, October 30, 2009 10:12 PM >> To: codec@ietf.org >> Subject: [codec] questions to be answered >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> RFC 5434 has a list of questions that need to be answered before a WG >> is >> formed, and I think we have fairly clear answers to these questions: >> >> 1. Is there a problem that needs solving? >> >> (Yes, see problem statement in charter.) >> >> 2. Is the scope of the problem well defined and understood? >> >> (Yes, see objectives in charter, guidelines I-D, and requirements > I-D.) >> >> 3. Is there agreement on what the WG needs to deliver? >> >> (Yes, see deliverables in charter, guidelines I-D, and requirements I- >> D.) >> >> 4. Are there enough IETF participants to do the work? >> >> (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >> >> 5. Does the WG have a reasonable probability of success? >> >> (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >> emphasis on "reasonable" because we won't know until we try.) >> >> 6. Is the IETF is the right place to do the work? >> >> (Maybe. I think this is the major item to clarify at the BoF.) >> >> 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/ >> >> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >> =3D9vPK >> -----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 > > _______________________________________________ > 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_C71F1F2B10EC3hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] questions to be answered >- Robustness to packet loss

Are you thinking of burst packet loss or random distributed packet loss? And what would be the metrics and values for either?

If we have no metrics and no credible values, I suggest to forget this rat = hole.
Broadband Internet has IMO and negligible packet loss, except for congestio= n events where the codec cannot do anything anyway.

Packet loss was a big deal in old analog modem times and pre-3G/4G wireless= networks :-)

My two cents,

Henry


On 11/10/09 12:29 PM, "Koen Vos" <koen.vos@skype.net> wrote:

These are good requirements at the high end= , e.g. for virtual presence
and interactive music.

At the low end, for basic voice, I think also -and sometimes more-
important are:
- Bitrate
- Robustness to packet loss
- Complexity
- Real-time scalability (the ability to adjust parameters)
These aspects determine how well communications work in challenging
scenarios like over wireless networks and on embedded devices.

koen.


Quoting Michael Knappe:
> In looking at building the table illustrating codec applications vs. <= BR> > criteria, the problem space appears to be parameterized by three
> major criteria:
>
> A) end-to-end latency: objectively, achieving the least amount of
> latency possible is better for real-time communications.
> Psychoacoustically, achieving end-to-end delays less than 150 ms has <= BR> > diminishing quality returns for human speech communication, while
> the specific application of live music interaction requires less
> than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly,
> the live music interaction requirement requires not only a low delay <= BR> > codec, but also a carefully controlled, minimal jitter and very low > propagation delay network. The 150 ms requirement, on the other
> hand, has more leeway in allocating latency budget between codec
> algorithmic delays and other sources of delay in the network. Bottom <= BR> > line: live music interaction appears to be an outlier relative to
> other codec applications with respect to end-to-end latency.
>
> B) number of channels: objectively, recreating as complete a
> representation of the original source sound field is better for
> real-time communications. For two-party speech communications,
> source material from a single microphone can obviously be
> transmitted with a single audio channel, with the decision to
> present the signal to one or more audio outputs made at the
> receiving end (e.g.  Single output telephone handset receiver, du= al
> output binaural headphones). However, even for two-party speech
> communications with a single talker at each end, speakerphone
> communications can be improved by transmitting two channels of audio <= BR> > from two microphones on the speakerphone, that when listened to with <= BR> > stereo headphones at the receiving end, the 'barrel effect' common > to mono microphone speakerphones is greatly reduced. This concept of <= BR> > transmission of soundfield along with speech (or music) becomes more <= BR> > important as more complex acoustic environments are involved
> (including the creation
>  of virtual acoustic environments with multiple talker sources mi= xed
> into a common soundfield). Thus, the need for more transmission
> channels should increase with the application's desire to produce a > more immersive environment. Bottom line: although single party
> source material in two-party communications could benefit from more > than one transmission channel, applications like advanced
> conferencing / telepresence,  gaming and live music interaction a= re
> likely to benefit the most from multi-channel environments.
>
> C) frequency bandwidth: objectively, reproducing the widest possible <= BR> > audio frequency bandwidth to cover the frequency content of the
> original source material is better for real-time communications.
> Human speech has been transmitted with intelligibility limitations > for decades over bandwidths as narrow as 3 kHz. Speech
> intelligibility improves significantly as bandwidth is increased to > 6 or 7 kHz, with diminishing intelligibility improvements as
> bandwidth is increased past this, even though the subjective measure <= BR> > of 'naturalness' may continue to improve up to the limits of human > hearing. This concept of 'intelligibility' and 'naturalness' also
> applies to music - an example of intelligibility here could be
> discerning between an oboe and bassoon in a symphony, while
> naturalness is more a measure of how 'real' that singled-out oboe
> sounds. It would appear to follow that the more complex a sound
> source and soundfield that we wish to transmit, the wider the
> bandwidth we should enco
>  de. In the high fidelity and professional recording domains, thi= s
> quest for 'naturalness' has extended beyond what we typically feel > the human limitation of 20 kHz auditory perception is, to sample
> rates up to 192 kHz and beyond. Bottom line:  human speech in sim= ple
> two-party interactions will receive the most benefit in transmitting <= BR> > the first 7 kHz of audio bandwidth, but more complex source material <= BR> > will continue to benefit from wider audio bandwidths, possibly
> extending beyond the traditional 20 kHz 'auditory limit'.
>
> I have not included in the above criteria the concept of fundamental <= BR> > codec type - many previous telephony compression algorithms rely on > parameterizations of the human mechanics of the generation of speech <= BR> > (e.g. CELP based codecs) which do not translate well to
> parameterization of other source material such as music, whereas
> auditory receiving end perceptual audio parameterizations tend to
> work well for both music and speech, but historically have had
> latency limitations. My thought here, for this proposed codec, is
> that we should not be looking for a codec where a priori knowledge > of the type of audio material is required (although certainly the
> codec could be designed to optimize its performance dynamically for > varying types of source material).
>
> Also not included above are fundamental concepts of distortion and > noise - for me, this is a secondary requirement that once A,B and C > are established, that sufficient signal-to-noise ratios be
> maintained to not undermine intelligibility and naturalness goals of <= BR> > the transmission. This may mean a natural progression to higher SNR > targets for wider bandwidth, more immersive environments.
>
> Thoughts?
>
> Mike
>
> On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" <mramalho@cisco.com> wrote:
>
> All,
>
> I strongly agree with Roni here, re: "I think that the if the cha= rter
> describes a list of applications it need to have a separate requiremen= t
> for each application on which this proposed group is going to develop = a
> separate codec."
>
> Let's consider two SIMPLE examples.
>
> Example 1 - Let's assume I have an application that requires a certain=
> linearity within a certain BW ranges (need > 25 dB of waveform line= arity
> in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this applic= ation
> uses adaptive signal processing techniques and linearity is important.=
> Perhaps it is a far-end echo cancellation application, or a microphone=
> beam array processing application that processes multiple streams at t= he
> receiver end. I could go on with any number of interesting examples. > Note that such an applications would generate specific REQUIREMENTS to=
> meet these use cases. The candidate codec would probably be
> waveform-based (at least in the bands having the linearity
> requirements).
>
> Example 2 - Many voice codecs use spectral techniques (such as spectra= l
> band replication, SBR) above 4k. Such codecs, while potentially
> capturing the spectral content well enough, will NOT preserve the phas= e
> (as the phase information is not in the compressed representation). Su= ch
> a codec would NOT meet the simple > 20 dB linearity requirement (of= the
> 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD = to
> a human - perhaps, as the human auditory system is not as sensitive to=
> phase in this region. Additionally, many of these codecs are speech > model based - and typically have < 20 dB of linearity on unvoiced s= peech
> even in 0 - 4k region. (You could throw in an entropy coding stage aft= er
> the model to fix this - at the cost of BW - but I digress).
>
> One might ask why codec manufacturers use techniques such as SBR?
> Answer: because they are generally more efficient (precisely because > they don't require as much phase information in the compressed domain)=
> and sound good to humans.
>
> I could go on and on ... but I sincerely doubt that ONE MAGICAL codec<= BR> > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS.
>
> I think the rush to a "single-codec" requirements here is pr= emature ...
> I agree with Roni ... one size does not fit all.
>
> Given the simple examples above - isn't it clear that we need to defin= e
> applications (one might call them use cases) - and then requirements f= or
> them - before we determine how a given candidate satisfies the
> requirements?
>
> At a minimum, I see two legitimate codec classes:
>
> CLASS 1) codecs that are bandwidth efficient and sound good to humans<= BR> > (and perhaps satisfy tendeming or tone pass-through requirements), and=
>
> CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many
> classification-based applications such as speaker/sound/intrusion
> identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1.
>
> Granted, we should make each use case as broad as possible so as not t= o
> have too many of them. Once one codec is standardized for a particular=
> application type - a subsequent candidate codec/application would need=
> to prove it is "sufficiently different" from the existing co= dec(s) to go
> further. The WG chairs need to exert leadership to ensure the desired<= BR> > result (of the smallest number of codecs spanning the greatest
> application space).
>
> IF
> a given codec meets the requirements of its use case
> AND
> that use case is valid
> THEN
> I (for one) don't have an issue with the IETF "rubber stamping&qu= ot; of it.
>
> If you have a specific use case - then get together with other similar= ly
> minded folks and generate a "use case" draft and then a requ= irements
> draft for that use case. Don't try to solve world hunger in one step.<= BR> >
> Off Soapbox,
>
> Michael Ramalho, Ph.D.
>
> [Flames expected ... but please try to disprove my debate above when > doing so ... I dislike flames that do not disprove a thesis ;-) ]
>
> PS - I think CLASS 1 codecs should be addressed first by the WG ... an= d
> later consider other classes as people advocate for their use case. >
> -----Original Message-----
> From: codec-bounces@ietf.org [<= a href=3D"mailto:codec-bounces@ietf.org">mailto:codec-bounces@ietf.org]= On Behalf
> Of Roni Even
> Sent: Friday, October 30, 2009 6:34 PM
> To: 'Peter Saint-Andre'; codec@ietf.org=
> Subject: Re: [codec] questions to be answered
>
> Hi Peter,
> I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how = to
> decide which codecs are in scope for this working group is agreed. My<= BR> > view
> that this issue is not addressed since I assume that all the parties > that
> submitted candidate codecs would like their codecs to be approved at t= he
> IETF which will make this group a rubber stamping WG.
> I think that the if the charter describes a list of applications it ne= ed
> to
> have a separate requirement for each application on which this propose= d
> group is going to develop a separate codec. If there is one requiremen= t
> document for all apllications there should be one codec to address it.=
>
> Thanks
> Roni Even
>
>
>
>> -----Original Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On Behalf
>> Of Peter Saint-Andre
>> Sent: Friday, October 30, 2009 10:12 PM
>> To: codec@ietf.org
>> Subject: [codec] questions to be answered
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> RFC 5434 has a list of questions that need to be answered before a= WG
>> is
>> formed, and I think we have fairly clear answers to these question= s:
>>
>> 1. Is there a problem that needs solving?
>>
>> (Yes, see problem statement in charter.)
>>
>> 2. Is the scope of the problem well defined and understood?
>>
>> (Yes, see objectives in charter, guidelines I-D, and requirements<= BR> > I-D.)
>>
>> 3. Is there agreement on what the WG needs to deliver?
>>
>> (Yes, see deliverables in charter, guidelines I-D, and requirement= s I-
>> D.)
>>
>> 4. Are there enough IETF participants to do the work?
>>
>> (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.)=
>>
>> 5. Does the WG have a reasonable probability of success?
>>
>> (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an=
>> emphasis on "reasonable" because we won't know until we = try.)
>>
>> 6. Is the IETF is the right place to do the work?
>>
>> (Maybe. I think this is the major item to clarify at the BoF.)
>>
>> 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/
>>
>> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP
>> =3D9vPK
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>
> _______________________________________________
> 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_C71F1F2B10EC3hsinnreiadobecom_-- From mknappe@juniper.net Mon Nov 9 20:55: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 4872D3A6820 for ; Mon, 9 Nov 2009 20:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 IQtTREBMN7zr for ; Mon, 9 Nov 2009 20:55:05 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 2FB7B3A680F for ; Mon, 9 Nov 2009 20:55:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSvjyPztG/7640zUz278s3WzKAzREJUtv@postini.com; Mon, 09 Nov 2009 20:55:32 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 9 Nov 2009 20:49:38 -0800 From: Michael Knappe To: Koen Vos Date: Mon, 9 Nov 2009 20:49:45 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcphtghQlU67us1dTHaAexdXubwsGAACzDkR Message-ID: In-Reply-To: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 04:55:07 -0000 Koen, Agreed that bitrate, robustness, computational complexity (implementability= and cost) and RT scalability are absolutely all important aspects, and not= just for the low end. In particular, robustness to packet loss is importan= t for any proposed codec. Bitrate, possibly coupled with scalability, help = determine how far the codec can reach - poorly analogous to whether certain= blood cells can make it all the way to capillaries or not. I'm thinking th= at this last concept become a fourth axis of 'codec reach', in addition to = latency, channels, and bandwidth, thanks for highlighting this. Computational complexity is an interesting thought process in itself - sinc= e we're looking at something that possibly won't be fully deployed for seve= ral years, how much leeway should we allow here for economical deployments?= Should we allow bit 'compatible' versions in addition to bit exact qualifi= cations to allow for flexibility in computational limitations? Mike On 11/9/09 7:29 PM, "Koen Vos" wrote: These are good requirements at the high end, e.g. for virtual presence and interactive music. At the low end, for basic voice, I think also -and sometimes more- important are: - Bitrate - Robustness to packet loss - Complexity - Real-time scalability (the ability to adjust parameters) These aspects determine how well communications work in challenging scenarios like over wireless networks and on embedded devices. koen. Quoting Michael Knappe: > In looking at building the table illustrating codec applications vs. > criteria, the problem space appears to be parameterized by three > major criteria: > > A) end-to-end latency: objectively, achieving the least amount of > latency possible is better for real-time communications. > Psychoacoustically, achieving end-to-end delays less than 150 ms has > diminishing quality returns for human speech communication, while > the specific application of live music interaction requires less > than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, > the live music interaction requirement requires not only a low delay > codec, but also a carefully controlled, minimal jitter and very low > propagation delay network. The 150 ms requirement, on the other > hand, has more leeway in allocating latency budget between codec > algorithmic delays and other sources of delay in the network. Bottom > line: live music interaction appears to be an outlier relative to > other codec applications with respect to end-to-end latency. > > B) number of channels: objectively, recreating as complete a > representation of the original source sound field is better for > real-time communications. For two-party speech communications, > source material from a single microphone can obviously be > transmitted with a single audio channel, with the decision to > present the signal to one or more audio outputs made at the > receiving end (e.g. Single output telephone handset receiver, dual > output binaural headphones). However, even for two-party speech > communications with a single talker at each end, speakerphone > communications can be improved by transmitting two channels of audio > from two microphones on the speakerphone, that when listened to with > stereo headphones at the receiving end, the 'barrel effect' common > to mono microphone speakerphones is greatly reduced. This concept of > transmission of soundfield along with speech (or music) becomes more > important as more complex acoustic environments are involved > (including the creation > of virtual acoustic environments with multiple talker sources mixed > into a common soundfield). Thus, the need for more transmission > channels should increase with the application's desire to produce a > more immersive environment. Bottom line: although single party > source material in two-party communications could benefit from more > than one transmission channel, applications like advanced > conferencing / telepresence, gaming and live music interaction are > likely to benefit the most from multi-channel environments. > > C) frequency bandwidth: objectively, reproducing the widest possible > audio frequency bandwidth to cover the frequency content of the > original source material is better for real-time communications. > Human speech has been transmitted with intelligibility limitations > for decades over bandwidths as narrow as 3 kHz. Speech > intelligibility improves significantly as bandwidth is increased to > 6 or 7 kHz, with diminishing intelligibility improvements as > bandwidth is increased past this, even though the subjective measure > of 'naturalness' may continue to improve up to the limits of human > hearing. This concept of 'intelligibility' and 'naturalness' also > applies to music - an example of intelligibility here could be > discerning between an oboe and bassoon in a symphony, while > naturalness is more a measure of how 'real' that singled-out oboe > sounds. It would appear to follow that the more complex a sound > source and soundfield that we wish to transmit, the wider the > bandwidth we should enco > de. In the high fidelity and professional recording domains, this > quest for 'naturalness' has extended beyond what we typically feel > the human limitation of 20 kHz auditory perception is, to sample > rates up to 192 kHz and beyond. Bottom line: human speech in simple > two-party interactions will receive the most benefit in transmitting > the first 7 kHz of audio bandwidth, but more complex source material > will continue to benefit from wider audio bandwidths, possibly > extending beyond the traditional 20 kHz 'auditory limit'. > > I have not included in the above criteria the concept of fundamental > codec type - many previous telephony compression algorithms rely on > parameterizations of the human mechanics of the generation of speech > (e.g. CELP based codecs) which do not translate well to > parameterization of other source material such as music, whereas > auditory receiving end perceptual audio parameterizations tend to > work well for both music and speech, but historically have had > latency limitations. My thought here, for this proposed codec, is > that we should not be looking for a codec where a priori knowledge > of the type of audio material is required (although certainly the > codec could be designed to optimize its performance dynamically for > varying types of source material). > > Also not included above are fundamental concepts of distortion and > noise - for me, this is a secondary requirement that once A,B and C > are established, that sufficient signal-to-noise ratios be > maintained to not undermine intelligibility and naturalness goals of > the transmission. This may mean a natural progression to higher SNR > targets for wider bandwidth, more immersive environments. > > Thoughts? > > Mike > > On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wro= te: > > All, > > I strongly agree with Roni here, re: "I think that the if the charter > describes a list of applications it need to have a separate requirement > for each application on which this proposed group is going to develop a > separate codec." > > Let's consider two SIMPLE examples. > > Example 1 - Let's assume I have an application that requires a certain > linearity within a certain BW ranges (need > 25 dB of waveform linearity > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application > uses adaptive signal processing techniques and linearity is important. > Perhaps it is a far-end echo cancellation application, or a microphone > beam array processing application that processes multiple streams at the > receiver end. I could go on with any number of interesting examples. > Note that such an applications would generate specific REQUIREMENTS to > meet these use cases. The candidate codec would probably be > waveform-based (at least in the bands having the linearity > requirements). > > Example 2 - Many voice codecs use spectral techniques (such as spectral > band replication, SBR) above 4k. Such codecs, while potentially > capturing the spectral content well enough, will NOT preserve the phase > (as the phase information is not in the compressed representation). Such > a codec would NOT meet the simple > 20 dB linearity requirement (of the > 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to > a human - perhaps, as the human auditory system is not as sensitive to > phase in this region. Additionally, many of these codecs are speech > model based - and typically have < 20 dB of linearity on unvoiced speech > even in 0 - 4k region. (You could throw in an entropy coding stage after > the model to fix this - at the cost of BW - but I digress). > > One might ask why codec manufacturers use techniques such as SBR? > Answer: because they are generally more efficient (precisely because > they don't require as much phase information in the compressed domain) > and sound good to humans. > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS. > > I think the rush to a "single-codec" requirements here is premature ... > I agree with Roni ... one size does not fit all. > > Given the simple examples above - isn't it clear that we need to define > applications (one might call them use cases) - and then requirements for > them - before we determine how a given candidate satisfies the > requirements? > > At a minimum, I see two legitimate codec classes: > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and > > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. > > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). > > IF > a given codec meets the requirements of its use case > AND > that use case is valid > THEN > I (for one) don't have an issue with the IETF "rubber stamping" of it. > > If you have a specific use case - then get together with other similarly > minded folks and generate a "use case" draft and then a requirements > draft for that use case. Don't try to solve world hunger in one step. > > Off Soapbox, > > Michael Ramalho, Ph.D. > > [Flames expected ... but please try to disprove my debate above when > doing so ... I dislike flames that do not disprove a thesis ;-) ] > > PS - I think CLASS 1 codecs should be addressed first by the WG ... and > later consider other classes as people advocate for their use case. > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Friday, October 30, 2009 6:34 PM > To: 'Peter Saint-Andre'; codec@ietf.org > Subject: Re: [codec] questions to be answered > > Hi Peter, > I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how to > decide which codecs are in scope for this working group is agreed. My > view > that this issue is not addressed since I assume that all the parties > that > submitted candidate codecs would like their codecs to be approved at the > IETF which will make this group a rubber stamping WG. > I think that the if the charter describes a list of applications it need > to > have a separate requirement for each application on which this proposed > group is going to develop a separate codec. If there is one requirement > document for all apllications there should be one codec to address it. > > Thanks > Roni Even > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Peter Saint-Andre >> Sent: Friday, October 30, 2009 10:12 PM >> To: codec@ietf.org >> Subject: [codec] questions to be answered >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> RFC 5434 has a list of questions that need to be answered before a WG >> is >> formed, and I think we have fairly clear answers to these questions: >> >> 1. Is there a problem that needs solving? >> >> (Yes, see problem statement in charter.) >> >> 2. Is the scope of the problem well defined and understood? >> >> (Yes, see objectives in charter, guidelines I-D, and requirements > I-D.) >> >> 3. Is there agreement on what the WG needs to deliver? >> >> (Yes, see deliverables in charter, guidelines I-D, and requirements I- >> D.) >> >> 4. Are there enough IETF participants to do the work? >> >> (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >> >> 5. Does the WG have a reasonable probability of success? >> >> (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >> emphasis on "reasonable" because we won't know until we try.) >> >> 6. Is the IETF is the right place to do the work? >> >> (Maybe. I think this is the major item to clarify at the BoF.) >> >> 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/ >> >> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >> =3D9vPK >> -----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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From mknappe@juniper.net Mon Nov 9 21:01: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 31C993A6A3E for ; Mon, 9 Nov 2009 21:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.294 X-Spam-Level: X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 N12A453sPZoa for ; Mon, 9 Nov 2009 21:01:42 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id DED2A3A6A27 for ; Mon, 9 Nov 2009 21:01:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSvjzzqpc6XNQlNxu/Nm2oINPc+TNUPeM@postini.com; Mon, 09 Nov 2009 21:02:09 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 9 Nov 2009 20:53:14 -0800 From: Michael Knappe To: Henry Sinnreich , Koen Vos Date: Mon, 9 Nov 2009 20:53:20 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: AcphtgwKm4QMb9leQ+m4RErOB+O+IQACrJnSAAA+u4k= 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 05:01:44 -0000 Agreed that pure network packet loss (or even packet reordering) is not usu= ally the issue, but sudden jumps in jitter that cause temporary receiving e= nd packet starvation or overflow while the adaptive jitter buffer works its= magic would still be an issue in many deployment scenarios. Mike On 11/9/09 8:46 PM, "Henry Sinnreich" wrote: >- Robustness to packet loss Are you thinking of burst packet loss or random distributed packet loss? And what would be the metrics and values for either? If we have no metrics and no credible values, I suggest to forget this rat = hole. Broadband Internet has IMO and negligible packet loss, except for congestio= n events where the codec cannot do anything anyway. Packet loss was a big deal in old analog modem times and pre-3G/4G wireless= networks :-) My two cents, Henry On 11/10/09 12:29 PM, "Koen Vos" wrote: These are good requirements at the high end, e.g. for virtual presence and interactive music. At the low end, for basic voice, I think also -and sometimes more- important are: - Bitrate - Robustness to packet loss - Complexity - Real-time scalability (the ability to adjust parameters) These aspects determine how well communications work in challenging scenarios like over wireless networks and on embedded devices. koen. Quoting Michael Knappe: > In looking at building the table illustrating codec applications vs. > criteria, the problem space appears to be parameterized by three > major criteria: > > A) end-to-end latency: objectively, achieving the least amount of > latency possible is better for real-time communications. > Psychoacoustically, achieving end-to-end delays less than 150 ms has > diminishing quality returns for human speech communication, while > the specific application of live music interaction requires less > than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, > the live music interaction requirement requires not only a low delay > codec, but also a carefully controlled, minimal jitter and very low > propagation delay network. The 150 ms requirement, on the other > hand, has more leeway in allocating latency budget between codec > algorithmic delays and other sources of delay in the network. Bottom > line: live music interaction appears to be an outlier relative to > other codec applications with respect to end-to-end latency. > > B) number of channels: objectively, recreating as complete a > representation of the original source sound field is better for > real-time communications. For two-party speech communications, > source material from a single microphone can obviously be > transmitted with a single audio channel, with the decision to > present the signal to one or more audio outputs made at the > receiving end (e.g. Single output telephone handset receiver, dual > output binaural headphones). However, even for two-party speech > communications with a single talker at each end, speakerphone > communications can be improved by transmitting two channels of audio > from two microphones on the speakerphone, that when listened to with > stereo headphones at the receiving end, the 'barrel effect' common > to mono microphone speakerphones is greatly reduced. This concept of > transmission of soundfield along with speech (or music) becomes more > important as more complex acoustic environments are involved > (including the creation > of virtual acoustic environments with multiple talker sources mixed > into a common soundfield). Thus, the need for more transmission > channels should increase with the application's desire to produce a > more immersive environment. Bottom line: although single party > source material in two-party communications could benefit from more > than one transmission channel, applications like advanced > conferencing / telepresence, gaming and live music interaction are > likely to benefit the most from multi-channel environments. > > C) frequency bandwidth: objectively, reproducing the widest possible > audio frequency bandwidth to cover the frequency content of the > original source material is better for real-time communications. > Human speech has been transmitted with intelligibility limitations > for decades over bandwidths as narrow as 3 kHz. Speech > intelligibility improves significantly as bandwidth is increased to > 6 or 7 kHz, with diminishing intelligibility improvements as > bandwidth is increased past this, even though the subjective measure > of 'naturalness' may continue to improve up to the limits of human > hearing. This concept of 'intelligibility' and 'naturalness' also > applies to music - an example of intelligibility here could be > discerning between an oboe and bassoon in a symphony, while > naturalness is more a measure of how 'real' that singled-out oboe > sounds. It would appear to follow that the more complex a sound > source and soundfield that we wish to transmit, the wider the > bandwidth we should enco > de. In the high fidelity and professional recording domains, this > quest for 'naturalness' has extended beyond what we typically feel > the human limitation of 20 kHz auditory perception is, to sample > rates up to 192 kHz and beyond. Bottom line: human speech in simple > two-party interactions will receive the most benefit in transmitting > the first 7 kHz of audio bandwidth, but more complex source material > will continue to benefit from wider audio bandwidths, possibly > extending beyond the traditional 20 kHz 'auditory limit'. > > I have not included in the above criteria the concept of fundamental > codec type - many previous telephony compression algorithms rely on > parameterizations of the human mechanics of the generation of speech > (e.g. CELP based codecs) which do not translate well to > parameterization of other source material such as music, whereas > auditory receiving end perceptual audio parameterizations tend to > work well for both music and speech, but historically have had > latency limitations. My thought here, for this proposed codec, is > that we should not be looking for a codec where a priori knowledge > of the type of audio material is required (although certainly the > codec could be designed to optimize its performance dynamically for > varying types of source material). > > Also not included above are fundamental concepts of distortion and > noise - for me, this is a secondary requirement that once A,B and C > are established, that sufficient signal-to-noise ratios be > maintained to not undermine intelligibility and naturalness goals of > the transmission. This may mean a natural progression to higher SNR > targets for wider bandwidth, more immersive environments. > > Thoughts? > > Mike > > On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wro= te: > > All, > > I strongly agree with Roni here, re: "I think that the if the charter > describes a list of applications it need to have a separate requirement > for each application on which this proposed group is going to develop a > separate codec." > > Let's consider two SIMPLE examples. > > Example 1 - Let's assume I have an application that requires a certain > linearity within a certain BW ranges (need > 25 dB of waveform linearity > in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application > uses adaptive signal processing techniques and linearity is important. > Perhaps it is a far-end echo cancellation application, or a microphone > beam array processing application that processes multiple streams at the > receiver end. I could go on with any number of interesting examples. > Note that such an applications would generate specific REQUIREMENTS to > meet these use cases. The candidate codec would probably be > waveform-based (at least in the bands having the linearity > requirements). > > Example 2 - Many voice codecs use spectral techniques (such as spectral > band replication, SBR) above 4k. Such codecs, while potentially > capturing the spectral content well enough, will NOT preserve the phase > (as the phase information is not in the compressed representation). Such > a codec would NOT meet the simple > 20 dB linearity requirement (of the > 4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to > a human - perhaps, as the human auditory system is not as sensitive to > phase in this region. Additionally, many of these codecs are speech > model based - and typically have < 20 dB of linearity on unvoiced speech > even in 0 - 4k region. (You could throw in an entropy coding stage after > the model to fix this - at the cost of BW - but I digress). > > One might ask why codec manufacturers use techniques such as SBR? > Answer: because they are generally more efficient (precisely because > they don't require as much phase information in the compressed domain) > and sound good to humans. > > I could go on and on ... but I sincerely doubt that ONE MAGICAL codec > can satisfy both examples above ... because both APPLICATIONS would > result in different REQUIREMENTS. > > I think the rush to a "single-codec" requirements here is premature ... > I agree with Roni ... one size does not fit all. > > Given the simple examples above - isn't it clear that we need to define > applications (one might call them use cases) - and then requirements for > them - before we determine how a given candidate satisfies the > requirements? > > At a minimum, I see two legitimate codec classes: > > CLASS 1) codecs that are bandwidth efficient and sound good to humans > (and perhaps satisfy tendeming or tone pass-through requirements), and > > CLASS 2) codecs whose output may later be processed by sophisticated > signal processing functions (high-quality mixing, many > classification-based applications such as speaker/sound/intrusion > identification) that have SNR/waveform/distortion criteria generally > exceeding CLASS 1. > > Granted, we should make each use case as broad as possible so as not to > have too many of them. Once one codec is standardized for a particular > application type - a subsequent candidate codec/application would need > to prove it is "sufficiently different" from the existing codec(s) to go > further. The WG chairs need to exert leadership to ensure the desired > result (of the smallest number of codecs spanning the greatest > application space). > > IF > a given codec meets the requirements of its use case > AND > that use case is valid > THEN > I (for one) don't have an issue with the IETF "rubber stamping" of it. > > If you have a specific use case - then get together with other similarly > minded folks and generate a "use case" draft and then a requirements > draft for that use case. Don't try to solve world hunger in one step. > > Off Soapbox, > > Michael Ramalho, Ph.D. > > [Flames expected ... but please try to disprove my debate above when > doing so ... I dislike flames that do not disprove a thesis ;-) ] > > PS - I think CLASS 1 codecs should be addressed first by the WG ... and > later consider other classes as people advocate for their use case. > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Friday, October 30, 2009 6:34 PM > To: 'Peter Saint-Andre'; codec@ietf.org > Subject: Re: [codec] questions to be answered > > Hi Peter, > I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how to > decide which codecs are in scope for this working group is agreed. My > view > that this issue is not addressed since I assume that all the parties > that > submitted candidate codecs would like their codecs to be approved at the > IETF which will make this group a rubber stamping WG. > I think that the if the charter describes a list of applications it need > to > have a separate requirement for each application on which this proposed > group is going to develop a separate codec. If there is one requirement > document for all apllications there should be one codec to address it. > > Thanks > Roni Even > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Peter Saint-Andre >> Sent: Friday, October 30, 2009 10:12 PM >> To: codec@ietf.org >> Subject: [codec] questions to be answered >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> RFC 5434 has a list of questions that need to be answered before a WG >> is >> formed, and I think we have fairly clear answers to these questions: >> >> 1. Is there a problem that needs solving? >> >> (Yes, see problem statement in charter.) >> >> 2. Is the scope of the problem well defined and understood? >> >> (Yes, see objectives in charter, guidelines I-D, and requirements > I-D.) >> >> 3. Is there agreement on what the WG needs to deliver? >> >> (Yes, see deliverables in charter, guidelines I-D, and requirements I- >> D.) >> >> 4. Are there enough IETF participants to do the work? >> >> (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >> >> 5. Does the WG have a reasonable probability of success? >> >> (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >> emphasis on "reasonable" because we won't know until we try.) >> >> 6. Is the IETF is the right place to do the work? >> >> (Maybe. I think this is the major item to clarify at the BoF.) >> >> 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/ >> >> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >> =3D9vPK >> -----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 > > _______________________________________________ > 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 gregory.ietf@gmail.com Mon Nov 9 21:35: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 29BBF3A67F7 for ; Mon, 9 Nov 2009 21:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 ddX0Fe3dmjXK for ; Mon, 9 Nov 2009 21:35:00 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id EF12C3A69CB for ; Mon, 9 Nov 2009 21:34:59 -0800 (PST) Received: by yxe30 with SMTP id 30so4043955yxe.29 for ; Mon, 09 Nov 2009 21:35:24 -0800 (PST) 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=gS2u7mr4K+vtSXanzwAOwvthVP9P8gXs6VHHwwf61zA=; b=Ot8B4OMlsg33UmgtqcMAW0peRIw8qcr/FZ3siUguE6KwBA8T8tlvE1NIvNAqhlsZBF lFixrN2T2kyNI9D+9jfKbUBaVkXBpBTUzJ5xfWYl9+PISCf7oMppmD/5F6/ag94V0lgj zSo2orbxTUxPsGdEVrh8fLUfkZ6xNzkGJcBJA= 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=n8+jndkoDmw1Z+bzXvCJJ78hC3uBP3G3sie+vexV8NpyH4Ec/wgoH30Mt2Q1xcJD3E 7+yOWTIap/0P/ejDG9K/W5HnHWPL4Nds1nT0o6/FzmkVlx8h/bo9sGupmgNRQjXqqLpY yB1Dxu5UGLDPpi2pdfyrwx3p7gc/ZHIVQXDCA= Received: by 10.150.43.17 with SMTP id q17mr15142669ybq.197.1257831323944; Mon, 09 Nov 2009 21:35:23 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 15sm202724gxk.8.2009.11.09.21.35.21 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 21:35:23 -0800 (PST) Message-ID: <4af8fb9b.0f0bca0a.2df9.139c@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Nov 2009 21:35:17 -0800 To: Koen Vos ,Michael Knappe From: "Gregory M. Lebovitz" In-Reply-To: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> References: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 05:35:02 -0000 speaking w/ my individual contributor hat here... At 07:29 PM 11/9/2009, Koen Vos wrote: >These are good requirements at the high end, e.g. for virtual presence >and interactive music. > >At the low end, for basic voice, I think also -and sometimes more- >important are: >- Bitrate >- Robustness to packet loss >- Complexity >- Real-time scalability (the ability to adjust parameters) >These aspects determine how well communications work in challenging >scenarios like over wireless networks and on embedded devices. In the beginning, I'm more interested in seeing us solve basic voice over a concatenation of various types of networks, with excellent quality, and do so in a focused way. I'd be more interested and eager to address the interactive music type applications in a 2nd wave, re-chartering phase. Just mho, Gregory. >koen. > > >Quoting Michael Knappe: >>In looking at building the table illustrating codec applications vs. >>criteria, the problem space appears to be parameterized by three >>major criteria: >> >>A) end-to-end latency: objectively, achieving the least amount of >>latency possible is better for real-time communications. >>Psychoacoustically, achieving end-to-end delays less than 150 ms has >>diminishing quality returns for human speech communication, while >>the specific application of live music interaction requires less >>than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, >>the live music interaction requirement requires not only a low delay >>codec, but also a carefully controlled, minimal jitter and very low >>propagation delay network. The 150 ms requirement, on the other >>hand, has more leeway in allocating latency budget between codec >>algorithmic delays and other sources of delay in the network. Bottom >>line: live music interaction appears to be an outlier relative to >>other codec applications with respect to end-to-end latency. >> >>B) number of channels: objectively, recreating as complete a >>representation of the original source sound field is better for >>real-time communications. For two-party speech communications, >>source material from a single microphone can obviously be >>transmitted with a single audio channel, with the decision to >>present the signal to one or more audio outputs made at the >>receiving end (e.g. Single output telephone handset receiver, dual >>output binaural headphones). However, even for two-party speech >>communications with a single talker at each end, speakerphone >>communications can be improved by transmitting two channels of audio >>from two microphones on the speakerphone, that when listened to with >>stereo headphones at the receiving end, the 'barrel effect' common >>to mono microphone speakerphones is greatly reduced. This concept of >>transmission of soundfield along with speech (or music) becomes more >>important as more complex acoustic environments are involved >>(including the creation >> of virtual acoustic environments with multiple talker sources mixed >>into a common soundfield). Thus, the need for more transmission >>channels should increase with the application's desire to produce a >>more immersive environment. Bottom line: although single party >>source material in two-party communications could benefit from more >>than one transmission channel, applications like advanced >>conferencing / telepresence, gaming and live music interaction are >>likely to benefit the most from multi-channel environments. >> >>C) frequency bandwidth: objectively, reproducing the widest possible >>audio frequency bandwidth to cover the frequency content of the >>original source material is better for real-time communications. >>Human speech has been transmitted with intelligibility limitations >>for decades over bandwidths as narrow as 3 kHz. Speech >>intelligibility improves significantly as bandwidth is increased to >>6 or 7 kHz, with diminishing intelligibility improvements as >>bandwidth is increased past this, even though the subjective measure >>of 'naturalness' may continue to improve up to the limits of human >>hearing. This concept of 'intelligibility' and 'naturalness' also >>applies to music - an example of intelligibility here could be >>discerning between an oboe and bassoon in a symphony, while >>naturalness is more a measure of how 'real' that singled-out oboe >>sounds. It would appear to follow that the more complex a sound >>source and soundfield that we wish to transmit, the wider the >>bandwidth we should enco >> de. In the high fidelity and professional recording domains, this >>quest for 'naturalness' has extended beyond what we typically feel >>the human limitation of 20 kHz auditory perception is, to sample >>rates up to 192 kHz and beyond. Bottom line: human speech in simple >>two-party interactions will receive the most benefit in transmitting >>the first 7 kHz of audio bandwidth, but more complex source material >>will continue to benefit from wider audio bandwidths, possibly >>extending beyond the traditional 20 kHz 'auditory limit'. >> >>I have not included in the above criteria the concept of fundamental >>codec type - many previous telephony compression algorithms rely on >>parameterizations of the human mechanics of the generation of speech >>(e.g. CELP based codecs) which do not translate well to >>parameterization of other source material such as music, whereas >>auditory receiving end perceptual audio parameterizations tend to >>work well for both music and speech, but historically have had >>latency limitations. My thought here, for this proposed codec, is >>that we should not be looking for a codec where a priori knowledge >>of the type of audio material is required (although certainly the >>codec could be designed to optimize its performance dynamically for >>varying types of source material). >> >>Also not included above are fundamental concepts of distortion and >>noise - for me, this is a secondary requirement that once A,B and C >>are established, that sufficient signal-to-noise ratios be >>maintained to not undermine intelligibility and naturalness goals of >>the transmission. This may mean a natural progression to higher SNR >>targets for wider bandwidth, more immersive environments. >> >>Thoughts? >> >>Mike >> >>On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wrote: >> >>All, >> >>I strongly agree with Roni here, re: "I think that the if the charter >>describes a list of applications it need to have a separate requirement >>for each application on which this proposed group is going to develop a >>separate codec." >> >>Let's consider two SIMPLE examples. >> >>Example 1 - Let's assume I have an application that requires a certain >>linearity within a certain BW ranges (need > 25 dB of waveform linearity >>in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application >>uses adaptive signal processing techniques and linearity is important. >>Perhaps it is a far-end echo cancellation application, or a microphone >>beam array processing application that processes multiple streams at the >>receiver end. I could go on with any number of interesting examples. >>Note that such an applications would generate specific REQUIREMENTS to >>meet these use cases. The candidate codec would probably be >>waveform-based (at least in the bands having the linearity >>requirements). >> >>Example 2 - Many voice codecs use spectral techniques (such as spectral >>band replication, SBR) above 4k. Such codecs, while potentially >>capturing the spectral content well enough, will NOT preserve the phase >>(as the phase information is not in the compressed representation). Such >>a codec would NOT meet the simple > 20 dB linearity requirement (of the >>4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to >>a human - perhaps, as the human auditory system is not as sensitive to >>phase in this region. Additionally, many of these codecs are speech >>model based - and typically have < 20 dB of linearity on unvoiced speech >>even in 0 - 4k region. (You could throw in an entropy coding stage after >>the model to fix this - at the cost of BW - but I digress). >> >>One might ask why codec manufacturers use techniques such as SBR? >>Answer: because they are generally more efficient (precisely because >>they don't require as much phase information in the compressed domain) >>and sound good to humans. >> >>I could go on and on ... but I sincerely doubt that ONE MAGICAL codec >>can satisfy both examples above ... because both APPLICATIONS would >>result in different REQUIREMENTS. >> >>I think the rush to a "single-codec" requirements here is premature ... >>I agree with Roni ... one size does not fit all. >> >>Given the simple examples above - isn't it clear that we need to define >>applications (one might call them use cases) - and then requirements for >>them - before we determine how a given candidate satisfies the >>requirements? >> >>At a minimum, I see two legitimate codec classes: >> >>CLASS 1) codecs that are bandwidth efficient and sound good to humans >>(and perhaps satisfy tendeming or tone pass-through requirements), and >> >>CLASS 2) codecs whose output may later be processed by sophisticated >>signal processing functions (high-quality mixing, many >>classification-based applications such as speaker/sound/intrusion >>identification) that have SNR/waveform/distortion criteria generally >>exceeding CLASS 1. >> >>Granted, we should make each use case as broad as possible so as not to >>have too many of them. Once one codec is standardized for a particular >>application type - a subsequent candidate codec/application would need >>to prove it is "sufficiently different" from the existing codec(s) to go >>further. The WG chairs need to exert leadership to ensure the desired >>result (of the smallest number of codecs spanning the greatest >>application space). >> >>IF >>a given codec meets the requirements of its use case >>AND >>that use case is valid >>THEN >>I (for one) don't have an issue with the IETF "rubber stamping" of it. >> >>If you have a specific use case - then get together with other similarly >>minded folks and generate a "use case" draft and then a requirements >>draft for that use case. Don't try to solve world hunger in one step. >> >>Off Soapbox, >> >>Michael Ramalho, Ph.D. >> >>[Flames expected ... but please try to disprove my debate above when >>doing so ... I dislike flames that do not disprove a thesis ;-) ] >> >>PS - I think CLASS 1 codecs should be addressed first by the WG ... and >>later consider other classes as people advocate for their use case. >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of Roni Even >>Sent: Friday, October 30, 2009 6:34 PM >>To: 'Peter Saint-Andre'; codec@ietf.org >>Subject: Re: [codec] questions to be answered >> >>Hi Peter, >>I am not sure that there is a consensus about what the group need to >>deliver. I do not feel that the issue of the number of codecs and how to >>decide which codecs are in scope for this working group is agreed. My >>view >>that this issue is not addressed since I assume that all the parties >>that >>submitted candidate codecs would like their codecs to be approved at the >>IETF which will make this group a rubber stamping WG. >>I think that the if the charter describes a list of applications it need >>to >>have a separate requirement for each application on which this proposed >>group is going to develop a separate codec. If there is one requirement >>document for all apllications there should be one codec to address it. >> >>Thanks >>Roni Even >> >> >> >>>-----Original Message----- >>>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>>Of Peter Saint-Andre >>>Sent: Friday, October 30, 2009 10:12 PM >>>To: codec@ietf.org >>>Subject: [codec] questions to be answered >>> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>RFC 5434 has a list of questions that need to be answered before a WG >>>is >>>formed, and I think we have fairly clear answers to these questions: >>> >>>1. Is there a problem that needs solving? >>> >>>(Yes, see problem statement in charter.) >>> >>>2. Is the scope of the problem well defined and understood? >>> >>>(Yes, see objectives in charter, guidelines I-D, and requirements >>I-D.) >>> >>>3. Is there agreement on what the WG needs to deliver? >>> >>>(Yes, see deliverables in charter, guidelines I-D, and requirements I- >>>D.) >>> >>>4. Are there enough IETF participants to do the work? >>> >>>(Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >>> >>>5. Does the WG have a reasonable probability of success? >>> >>>(Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >>>emphasis on "reasonable" because we won't know until we try.) >>> >>>6. Is the IETF is the right place to do the work? >>> >>>(Maybe. I think this is the major item to clarify at the BoF.) >>> >>>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/ >>> >>>iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >>>lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >>>=9vPK >>>-----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 >> >>_______________________________________________ >>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 stefan.sayer@iptego.com Mon Nov 9 21:37: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 A9D3B28C0F4 for ; Mon, 9 Nov 2009 21:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzBUp6uTRxOU for ; Mon, 9 Nov 2009 21:37:04 -0800 (PST) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 225FE3A69CB for ; Mon, 9 Nov 2009 21:37:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 1ABB711540A1; Tue, 10 Nov 2009 06:37:28 +0100 (CET) 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 R4TKHodH9K62; Tue, 10 Nov 2009 06:37:27 +0100 (CET) Received: from [12.50.73.222] (unknown [12.50.73.222]) by mail.iptego.net (Postfix) with ESMTPSA id 355161154094; Tue, 10 Nov 2009 06:37:27 +0100 (CET) Message-ID: <4AF8FC15.7010102@iptego.com> Date: Tue, 10 Nov 2009 06:37:25 +0100 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Henry Sinnreich 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 05:37:05 -0000 o Henry Sinnreich [11/10/2009 05:46 AM]: >>- Robustness to packet loss > > Are you thinking of burst packet loss or random distributed packet loss? > And what would be the metrics and values for either? > > If we have no metrics and no credible values, I suggest to forget this > rat hole. > Broadband Internet has IMO and negligible packet loss, except for > congestion events where the codec cannot do anything anyway. > > Packet loss was a big deal in old analog modem times and pre-3G/4G > wireless networks :-) and it is still a big issue in multi-hop wireless networks. Stefan > > My two cents, > > Henry From mknappe@juniper.net Mon Nov 9 21:53: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 AA35828C102 for ; Mon, 9 Nov 2009 21:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 6qewzTk+8P7f for ; Mon, 9 Nov 2009 21:53:05 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 8224628C0F0 for ; Mon, 9 Nov 2009 21:53:05 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSvj/2XYiNucJXWDQXJtuErHX85rpdseQ@postini.com; Mon, 09 Nov 2009 21:53:32 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 9 Nov 2009 21:52:20 -0800 From: Michael Knappe To: "Gregory M. Lebovitz" , Koen Vos Date: Mon, 9 Nov 2009 21:52:26 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: Acphx5q4dSdzdzBITPGEDa9JUeT4fAAAmA48 Message-ID: In-Reply-To: <4af8fb9b.0f0bca0a.2df9.139c@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 05:53:07 -0000 Gregory, Being a bit careful on terminology .... 'Basic' can mean a lot of different= things...even the description of the codec BoF in the IETF agenda is "Inte= rnet Wideband Audio Codec" - wideband would not be considered 'basic' to a = lot of voice transmission people. 'Excellent quality' also means a lot of = different things to different people, which is another good reason to try a= nd develop a common parameter and criteria language so we can all be on the= same page when we discuss relative merits. The underlying purpose of this ongoing application parameterization exercis= e is to build an 80/20 grouping of criteria to help narrow down the most ef= fective focus of the proposed codec. For instance, just from the latency re= quirement alone it would appear interactive music is an outlier application= that might cause undue limitations on a proposed codec for other codec app= lications, and I would agree that this might be something either to address= as a second phase or not at all within the context of the proposed WG. Cheers, Mike On 11/9/09 9:35 PM, "Gregory M. Lebovitz" wrote: That speaking w/ my individual contributor hat here... At 07:29 PM 11/9/2009, Koen Vos wrote: >These are good requirements at the high end, e.g. for virtual presence >and interactive music. > >At the low end, for basic voice, I think also -and sometimes more- >important are: >- Bitrate >- Robustness to packet loss >- Complexity >- Real-time scalability (the ability to adjust parameters) >These aspects determine how well communications work in challenging >scenarios like over wireless networks and on embedded devices. In the beginning, I'm more interested in seeing us solve basic voice over a concatenation of various types of networks, with excellent quality, and do so in a focused way. I'd be more interested and eager to address the interactive music type applications in a 2nd wave, re-chartering phase. Just mho, Gregory. >koen. > > >Quoting Michael Knappe: >>In looking at building the table illustrating codec applications vs. >>criteria, the problem space appears to be parameterized by three >>major criteria: >> >>A) end-to-end latency: objectively, achieving the least amount of >>latency possible is better for real-time communications. >>Psychoacoustically, achieving end-to-end delays less than 150 ms has >>diminishing quality returns for human speech communication, while >>the specific application of live music interaction requires less >>than 50 ms end-to-end delay (and ideally 25 ms or less). Clearly, >>the live music interaction requirement requires not only a low delay >>codec, but also a carefully controlled, minimal jitter and very low >>propagation delay network. The 150 ms requirement, on the other >>hand, has more leeway in allocating latency budget between codec >>algorithmic delays and other sources of delay in the network. Bottom >>line: live music interaction appears to be an outlier relative to >>other codec applications with respect to end-to-end latency. >> >>B) number of channels: objectively, recreating as complete a >>representation of the original source sound field is better for >>real-time communications. For two-party speech communications, >>source material from a single microphone can obviously be >>transmitted with a single audio channel, with the decision to >>present the signal to one or more audio outputs made at the >>receiving end (e.g. Single output telephone handset receiver, dual >>output binaural headphones). However, even for two-party speech >>communications with a single talker at each end, speakerphone >>communications can be improved by transmitting two channels of audio >>from two microphones on the speakerphone, that when listened to with >>stereo headphones at the receiving end, the 'barrel effect' common >>to mono microphone speakerphones is greatly reduced. This concept of >>transmission of soundfield along with speech (or music) becomes more >>important as more complex acoustic environments are involved >>(including the creation >> of virtual acoustic environments with multiple talker sources mixed >>into a common soundfield). Thus, the need for more transmission >>channels should increase with the application's desire to produce a >>more immersive environment. Bottom line: although single party >>source material in two-party communications could benefit from more >>than one transmission channel, applications like advanced >>conferencing / telepresence, gaming and live music interaction are >>likely to benefit the most from multi-channel environments. >> >>C) frequency bandwidth: objectively, reproducing the widest possible >>audio frequency bandwidth to cover the frequency content of the >>original source material is better for real-time communications. >>Human speech has been transmitted with intelligibility limitations >>for decades over bandwidths as narrow as 3 kHz. Speech >>intelligibility improves significantly as bandwidth is increased to >>6 or 7 kHz, with diminishing intelligibility improvements as >>bandwidth is increased past this, even though the subjective measure >>of 'naturalness' may continue to improve up to the limits of human >>hearing. This concept of 'intelligibility' and 'naturalness' also >>applies to music - an example of intelligibility here could be >>discerning between an oboe and bassoon in a symphony, while >>naturalness is more a measure of how 'real' that singled-out oboe >>sounds. It would appear to follow that the more complex a sound >>source and soundfield that we wish to transmit, the wider the >>bandwidth we should enco >> de. In the high fidelity and professional recording domains, this >>quest for 'naturalness' has extended beyond what we typically feel >>the human limitation of 20 kHz auditory perception is, to sample >>rates up to 192 kHz and beyond. Bottom line: human speech in simple >>two-party interactions will receive the most benefit in transmitting >>the first 7 kHz of audio bandwidth, but more complex source material >>will continue to benefit from wider audio bandwidths, possibly >>extending beyond the traditional 20 kHz 'auditory limit'. >> >>I have not included in the above criteria the concept of fundamental >>codec type - many previous telephony compression algorithms rely on >>parameterizations of the human mechanics of the generation of speech >>(e.g. CELP based codecs) which do not translate well to >>parameterization of other source material such as music, whereas >>auditory receiving end perceptual audio parameterizations tend to >>work well for both music and speech, but historically have had >>latency limitations. My thought here, for this proposed codec, is >>that we should not be looking for a codec where a priori knowledge >>of the type of audio material is required (although certainly the >>codec could be designed to optimize its performance dynamically for >>varying types of source material). >> >>Also not included above are fundamental concepts of distortion and >>noise - for me, this is a secondary requirement that once A,B and C >>are established, that sufficient signal-to-noise ratios be >>maintained to not undermine intelligibility and naturalness goals of >>the transmission. This may mean a natural progression to higher SNR >>targets for wider bandwidth, more immersive environments. >> >>Thoughts? >> >>Mike >> >>On 11/2/09 5:41 AM, "Michael Ramalho (mramalho)" wro= te: >> >>All, >> >>I strongly agree with Roni here, re: "I think that the if the charter >>describes a list of applications it need to have a separate requirement >>for each application on which this proposed group is going to develop a >>separate codec." >> >>Let's consider two SIMPLE examples. >> >>Example 1 - Let's assume I have an application that requires a certain >>linearity within a certain BW ranges (need > 25 dB of waveform linearity >>in the band 0 - 4k, > 20 db from 4k - 8k, etc). Perhaps this application >>uses adaptive signal processing techniques and linearity is important. >>Perhaps it is a far-end echo cancellation application, or a microphone >>beam array processing application that processes multiple streams at the >>receiver end. I could go on with any number of interesting examples. >>Note that such an applications would generate specific REQUIREMENTS to >>meet these use cases. The candidate codec would probably be >>waveform-based (at least in the bands having the linearity >>requirements). >> >>Example 2 - Many voice codecs use spectral techniques (such as spectral >>band replication, SBR) above 4k. Such codecs, while potentially >>capturing the spectral content well enough, will NOT preserve the phase >>(as the phase information is not in the compressed representation). Such >>a codec would NOT meet the simple > 20 dB linearity requirement (of the >>4k - 8k band) of the previous paragraph. Will such a codec SOUND GOOD to >>a human - perhaps, as the human auditory system is not as sensitive to >>phase in this region. Additionally, many of these codecs are speech >>model based - and typically have < 20 dB of linearity on unvoiced speech >>even in 0 - 4k region. (You could throw in an entropy coding stage after >>the model to fix this - at the cost of BW - but I digress). >> >>One might ask why codec manufacturers use techniques such as SBR? >>Answer: because they are generally more efficient (precisely because >>they don't require as much phase information in the compressed domain) >>and sound good to humans. >> >>I could go on and on ... but I sincerely doubt that ONE MAGICAL codec >>can satisfy both examples above ... because both APPLICATIONS would >>result in different REQUIREMENTS. >> >>I think the rush to a "single-codec" requirements here is premature ... >>I agree with Roni ... one size does not fit all. >> >>Given the simple examples above - isn't it clear that we need to define >>applications (one might call them use cases) - and then requirements for >>them - before we determine how a given candidate satisfies the >>requirements? >> >>At a minimum, I see two legitimate codec classes: >> >>CLASS 1) codecs that are bandwidth efficient and sound good to humans >>(and perhaps satisfy tendeming or tone pass-through requirements), and >> >>CLASS 2) codecs whose output may later be processed by sophisticated >>signal processing functions (high-quality mixing, many >>classification-based applications such as speaker/sound/intrusion >>identification) that have SNR/waveform/distortion criteria generally >>exceeding CLASS 1. >> >>Granted, we should make each use case as broad as possible so as not to >>have too many of them. Once one codec is standardized for a particular >>application type - a subsequent candidate codec/application would need >>to prove it is "sufficiently different" from the existing codec(s) to go >>further. The WG chairs need to exert leadership to ensure the desired >>result (of the smallest number of codecs spanning the greatest >>application space). >> >>IF >>a given codec meets the requirements of its use case >>AND >>that use case is valid >>THEN >>I (for one) don't have an issue with the IETF "rubber stamping" of it. >> >>If you have a specific use case - then get together with other similarly >>minded folks and generate a "use case" draft and then a requirements >>draft for that use case. Don't try to solve world hunger in one step. >> >>Off Soapbox, >> >>Michael Ramalho, Ph.D. >> >>[Flames expected ... but please try to disprove my debate above when >>doing so ... I dislike flames that do not disprove a thesis ;-) ] >> >>PS - I think CLASS 1 codecs should be addressed first by the WG ... and >>later consider other classes as people advocate for their use case. >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of Roni Even >>Sent: Friday, October 30, 2009 6:34 PM >>To: 'Peter Saint-Andre'; codec@ietf.org >>Subject: Re: [codec] questions to be answered >> >>Hi Peter, >>I am not sure that there is a consensus about what the group need to >>deliver. I do not feel that the issue of the number of codecs and how to >>decide which codecs are in scope for this working group is agreed. My >>view >>that this issue is not addressed since I assume that all the parties >>that >>submitted candidate codecs would like their codecs to be approved at the >>IETF which will make this group a rubber stamping WG. >>I think that the if the charter describes a list of applications it need >>to >>have a separate requirement for each application on which this proposed >>group is going to develop a separate codec. If there is one requirement >>document for all apllications there should be one codec to address it. >> >>Thanks >>Roni Even >> >> >> >>>-----Original Message----- >>>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>>Of Peter Saint-Andre >>>Sent: Friday, October 30, 2009 10:12 PM >>>To: codec@ietf.org >>>Subject: [codec] questions to be answered >>> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>RFC 5434 has a list of questions that need to be answered before a WG >>>is >>>formed, and I think we have fairly clear answers to these questions: >>> >>>1. Is there a problem that needs solving? >>> >>>(Yes, see problem statement in charter.) >>> >>>2. Is the scope of the problem well defined and understood? >>> >>>(Yes, see objectives in charter, guidelines I-D, and requirements >>I-D.) >>> >>>3. Is there agreement on what the WG needs to deliver? >>> >>>(Yes, see deliverables in charter, guidelines I-D, and requirements I- >>>D.) >>> >>>4. Are there enough IETF participants to do the work? >>> >>>(Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) >>> >>>5. Does the WG have a reasonable probability of success? >>> >>>(Yes, see codec I-Ds, guidelines I-D, and list discussion, with an >>>emphasis on "reasonable" because we won't know until we try.) >>> >>>6. Is the IETF is the right place to do the work? >>> >>>(Maybe. I think this is the major item to clarify at the BoF.) >>> >>>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/ >>> >>>iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz >>>lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP >>>=3D9vPK >>>-----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 >> >>_______________________________________________ >>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@usherbrooke.ca Mon Nov 9 22:00: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 426D228C0D7 for ; Mon, 9 Nov 2009 22:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwI9bE8soQip for ; Mon, 9 Nov 2009 22:00:07 -0800 (PST) Received: from idefix.homelinux.org (host-144-181.meeting.ietf.org [133.93.144.181]) by core3.amsl.com (Postfix) with ESMTP id 1AD4D28B56A for ; Mon, 9 Nov 2009 22:00:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTPS id 581E050AC49; Tue, 10 Nov 2009 15:00:33 +0900 (JST) Message-ID: <4AF9017E.3020700@usherbrooke.ca> Date: Tue, 10 Nov 2009 15:00:30 +0900 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <20091109192924.33878h8lwzg4bk0k@mail.skype.net> <4af8fb9b.0f0bca0a.2df9.139c@mx.google.com> In-Reply-To: <4af8fb9b.0f0bca0a.2df9.139c@mx.google.com> 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 06:00:08 -0000 Gregory M. Lebovitz a écrit : > speaking w/ my individual contributor hat here... > > At 07:29 PM 11/9/2009, Koen Vos wrote: >> These are good requirements at the high end, e.g. for virtual presence >> and interactive music. >> >> At the low end, for basic voice, I think also -and sometimes more- >> important are: >> - Bitrate >> - Robustness to packet loss >> - Complexity >> - Real-time scalability (the ability to adjust parameters) >> These aspects determine how well communications work in challenging >> scenarios like over wireless networks and on embedded devices. > > In the beginning, I'm more interested in seeing us solve basic voice > over a concatenation of various types of networks, with excellent > quality, and do so in a focused way. > > I'd be more interested and eager to address the interactive music type > applications in a 2nd wave, re-chartering phase. So far, I don't see a reason why all the requirements we currently have cannot be addressed at the same time and -- ideally -- with the same codec. But the best way to answer the question is to get the technical work started and see the outcome. At this point, I have a very hard time predicting what the outcome of the technology merge (of the 4 codecs "submitted" already) would look like in terms of capabilities, so I think it would be a bad idea to make assumptions about that in the initial charter. Otherwise, I totally agree with Koen about the bitrate, robustness, complexity and scalability being very important aspects. Cheers, Jean-Marc From jean-marc.valin@usherbrooke.ca Mon Nov 9 22:07: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 1DDBA28C0F0 for ; Mon, 9 Nov 2009 22:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjeIIJRl0v20 for ; Mon, 9 Nov 2009 22:07:54 -0800 (PST) Received: from idefix.homelinux.org (host-144-181.meeting.ietf.org [133.93.144.181]) by core3.amsl.com (Postfix) with ESMTP id 10E0C28B56A for ; Mon, 9 Nov 2009 22:07:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTPS id D8F5050AC4A; Tue, 10 Nov 2009 15:08:20 +0900 (JST) Message-ID: <4AF90354.4090800@usherbrooke.ca> Date: Tue, 10 Nov 2009 15:08:20 +0900 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael Knappe References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 06:07:56 -0000 > The underlying purpose of this ongoing application parameterization > exercise is to build an 80/20 grouping of criteria to help narrow > down the most effective focus of the proposed codec. For instance, > just from the latency requirement alone it would appear interactive > music is an outlier application that might cause undue limitations on > a proposed codec for other codec applications, and I would agree that > this might be something either to address as a second phase or not at > all within the context of the proposed WG. Again, this is implicitly assuming the outcome of the technical work. I could very well imagine that the "natural split" in terms of applications could be between "medium quality" (narrowband/wideband) speech-only codec using an LP-based source model and very high quality super-wideband transform-based codec. Of course, it's reasonable to ensure that addressing the requirements of one application not cause a degradation of quality for other applications. Jean-Marc From swmike@swm.pp.se Mon Nov 9 23:01: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 798593A693C for ; Mon, 9 Nov 2009 23:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrzXILsabqya for ; Mon, 9 Nov 2009 23:01:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 74FF13A69DC for ; Mon, 9 Nov 2009 23:01:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D535C9E; Tue, 10 Nov 2009 08:01:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D4B789A for ; Tue, 10 Nov 2009 08:01:47 +0100 (CET) Date: Tue, 10 Nov 2009 08:01:47 +0100 (CET) From: Mikael Abrahamsson To: "codec@ietf.org" 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 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 07:01:23 -0000 On Mon, 9 Nov 2009, Henry Sinnreich wrote: >> - Robustness to packet loss > > Are you thinking of burst packet loss or random distributed packet loss? > And what would be the metrics and values for either? > > If we have no metrics and no credible values, I suggest to forget this rat hole. I *strongly* disagree to this line of thinking. This thinking is what is causing a lot of the current system implementations (codec and transport together) to not work properly on "the Internet". See my previous email on this list on this issue. I can come up with metrics that are realistic, that I have seen in real life. I might not have the exact numbers, but I have scenarios where they occur. > Broadband Internet has IMO and negligible packet loss, except for congestion events where the codec cannot do anything anyway. > > Packet loss was a big deal in old analog modem times and pre-3G/4G wireless networks :-) This is still a problem (and no, it wasn't a problem on analog modems with ARQ), depending on where in the world you are. I can come up with multiple scenarios where I want this "Internet codec/transport" to work that current implementations do not work in, where for instance you trade latency for pps for instance. In some cases it's better to send 5 pps with 500 byte packets to get the packets thru, than to send 50pps of smaller packets because they do not go thru. Yes, latency suffers, but it *works*. I'd rather have a 2 second end-to-end latency for my call than no call at all. -- Mikael Abrahamsson email: swmike@swm.pp.se From hsinnrei@adobe.com Mon Nov 9 23:12: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 0F4CB3A6824 for ; Mon, 9 Nov 2009 23:12:22 -0800 (PST) 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 YYQq2EUhDe7h for ; Mon, 9 Nov 2009 23:12:20 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id 6BD543A68CB for ; Mon, 9 Nov 2009 23:12:20 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSvkSbHI/foL/sORI8592n0x2BhJda7ii@postini.com; Mon, 09 Nov 2009 23:12:47 PST 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 nAA75THc013953; Mon, 9 Nov 2009 23:05:29 -0800 (PST) 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 nAA77gaH003476; Mon, 9 Nov 2009 23:12:43 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 9 Nov 2009 23:11:57 -0800 From: Henry Sinnreich To: Mikael Abrahamsson , "codec@ietf.org" Date: Mon, 9 Nov 2009 23:11:52 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: Acph068DJBv8gqrVQ2GDm9F8gv9B3AAAWSwb 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_C71F414810EF3hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 07:12:22 -0000 --_000_C71F414810EF3hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I can come up with metrics that are realistic, >that I have seen in real life. Metrics and values/numbers would be very interesting if you can share them,= to better understand the requirements. Also to make sure in what usage scenarios they may occur. Thanks, Henry On 11/10/09 4:01 PM, "Mikael Abrahamsson" wrote: On Mon, 9 Nov 2009, Henry Sinnreich wrote: >> - Robustness to packet loss > > Are you thinking of burst packet loss or random distributed packet loss? > And what would be the metrics and values for either? > > If we have no metrics and no credible values, I suggest to forget this ra= t hole. I *strongly* disagree to this line of thinking. This thinking is what is causing a lot of the current system implementations (codec and transport together) to not work properly on "the Internet". See my previous email on this list on this issue. I can come up with metrics that are realistic, that I have seen in real life. I might not have the exact numbers, but I have scenarios where they occur. > Broadband Internet has IMO and negligible packet loss, except for congest= ion events where the codec cannot do anything anyway. > > Packet loss was a big deal in old analog modem times and pre-3G/4G wirele= ss networks :-) This is still a problem (and no, it wasn't a problem on analog modems with ARQ), depending on where in the world you are. I can come up with multiple scenarios where I want this "Internet codec/transport" to work that current implementations do not work in, where for instance you trade latency for pps for instance. In some cases it's better to send 5 pps with 500 byte packets to get the packets thru, than to send 50pps of smaller packets because they do not go thru. Yes, latency suffers, but it *works*. I'd rather have a 2 second end-to-end latency for my call than no call at all. -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C71F414810EF3hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] questions to be answered >I can come up with metrics that are realistic,
>that I have seen in real life.

Metrics and values/numbers would be very interesting if you can share them,= to better understand the requirements.
Also to make sure in what usage scenarios they may occur.

Thanks, Henry


On 11/10/09 4:01 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

On Mon, 9 Nov 2009, Henry Sinnreich wrote:<= BR>
>> - Robustness to packet loss
>
> Are you thinking of burst packet loss or random distributed packet los= s?
> And what would be the metrics and values for either?
>
> If we have no metrics and no credible values, I suggest to forget this= rat hole.

I *strongly* disagree to this line of thinking. This thinking is what is causing a lot of the current system implementations (codec and transport together) to not work properly on "the Internet". See my previous= email on
this list on this issue.

I can come up with metrics that are realistic, that I have seen in real
life. I might not have the exact numbers, but I have scenarios where they occur.

> Broadband Internet has IMO and negligible packet loss, except for cong= estion events where the codec cannot do anything anyway.
>
> Packet loss was a big deal in old analog modem times and pre-3G/4G wir= eless networks :-)

This is still a problem (and no, it wasn't a problem on analog modems with<= BR> ARQ), depending on where in the world you are. I can come up with multiple<= BR> scenarios where I want this "Internet codec/transport" to work th= at
current implementations do not work in, where for instance you trade
latency for pps for instance. In some cases it's better to send 5 pps with<= BR> 500 byte packets to get the packets thru, than to send 50pps of smaller
packets because they do not go thru. Yes, latency suffers, but it *works*.<= BR>
I'd rather have a 2 second end-to-end latency for my call than no call at all.

--
Mikael Abrahamsson    email: sw= mike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C71F414810EF3hsinnreiadobecom_-- From swmike@swm.pp.se Tue Nov 10 00:03: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 5001128C126 for ; Tue, 10 Nov 2009 00:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM0DvhwIYzEa for ; Tue, 10 Nov 2009 00:03:16 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2B7AC3A6A03 for ; Tue, 10 Nov 2009 00:03:15 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 965E99C; Tue, 10 Nov 2009 09:03:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 953339A for ; Tue, 10 Nov 2009 09:03:41 +0100 (CET) Date: Tue, 10 Nov 2009 09:03:41 +0100 (CET) From: Mikael Abrahamsson To: "codec@ietf.org" 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 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:03:17 -0000 On Mon, 9 Nov 2009, Henry Sinnreich wrote: > Metrics and values/numbers would be very interesting if you can share > them, to better understand the requirements. Also to make sure in what > usage scenarios they may occur. 2 seconds jitter and 10% continous random packet loss should definitely be handled gracefully (during the tsunami where several fiber optic cables were severed in asia, packet loss from the region to the rest of the world was continous 5-7% due to remaining paths being extremely congested). 2 seconds is for multiple links in a row being full (typically Cisco 12000 routers can buffer 600ms of data when congestion occurs). There are numerous cases (ADSL2+ without interleave, high speed links with CRC errors, ethernet duplex errors) where random packet loss can be seen. Typically this is less than 1%, otherwise people tend to fix the problem because TCP works very badly. We then have the 3G/wifi network issue, where jitter can also be at least 2 seconds, plus packet loss as well (some networks seem to buffer X kilobytes, some Y number of packets, after that they tail drop. I've seen both behaviours). Burst loss, where when you have a network re-route, you might lose typically 0.05 - 2 seconds of data, and you might get re-ordering during the convergence. Since this is a transient event, I don't think much can be done about it but try to play data as they come in and just ignore out of order packets. Perhaps jitter buffer should be increased when out-of-order packets is seen, but when things calm down again it needs to be reduced again. I've also seen networks which re-order packets constantly, I don't know what the load-sharing algorithm used is, but I think the jitter buffer size should be adapted and handle out of order packets so they're presented to the codec correctly. When running voice over GSM GPRS, typically there is very low bandwidth and high delay. Here bw should be kept as low as possible and the IP header is a big overhead and pps should thus be kept at a minimum, for instance 3-5 pps and the very lowest quality setting should be used. So, the SYSTEM (I'm not just talking codec here), as far as I can see it, needs to gracefully handle at least 10% packet loss, out of order packets (analyse the time they might be re-ordered and adapt jitter buffer accordingly), or just plain jitter up to 2s. My reasoning here is mainly focused on voice over Internet, but as far as I can see this applies to all sound, even though if it's not interactive I guess the focus can be switched from low latency (it might be better for a voice call to have lower latency than actually getting perfect sound) to reliable sound delivery with higher latency (by increasing jitter buffer and putting sound information in multiple packets so that single packet loss doesn't mean silence in that interval). Basically I'd like to see that as soon as jitter buffer is increased, the resiliancy to packet loss should be increased as well by telling the other end that it can start to do packet loss concealment information in the packets as well (whatever it's called, I'm not a codec guy). If sender knows what the receiver jitter buffer is, then this can be used to increase resiliency (I guess). Does this help? -- Mikael Abrahamsson email: swmike@swm.pp.se From ingemar.s.johansson@ericsson.com Tue Nov 10 00:06: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 E590D3A694D for ; Tue, 10 Nov 2009 00:06:24 -0800 (PST) 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_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 1dEAws2Vg+S3 for ; Tue, 10 Nov 2009 00:06:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B42293A67A3 for ; Tue, 10 Nov 2009 00:06:23 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-f1-4af91f1949fe Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6A.59.04191.91F19FA4; Tue, 10 Nov 2009 09:06:49 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:06:38 +0100 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, 10 Nov 2009 09:06:30 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standardization in ITU-T, what are the issues ? Thread-Index: Acph3LYKM8OZE+gITmu7Fk/tky94Aw== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 10 Nov 2009 08:06:38.0048 (UTC) FILETIME=[BA578E00:01CA61DC] X-Brightmail-Tracker: AAAAAA== Subject: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:06:25 -0000 Hi I am curious to know to what extent proponents of a Codec WG in IETF has = approached ITU-T with a request to standardize a RF codec.=20 As I understand it there is a possibility of free membership which of = course means limited rights to vote, however if I get this part correct = it is a possibility to get voting rights via a countrys standards body. = There is a chance that I don't get these details right as I have not = myself digged into the membership rules of ITU-T. Anyway, my question. Who has actively approached the ITU-T with this and = what was he response ?. Also are there any meeting documents or other = public info that documents this ? BR /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From hoene@uni-tuebingen.de Tue Nov 10 00:16: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 548563A69AD for ; Tue, 10 Nov 2009 00:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 ZazorFBLfp8N for ; Tue, 10 Nov 2009 00:16:22 -0800 (PST) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 284093A697F for ; Tue, 10 Nov 2009 00:16:21 -0800 (PST) Received: from hoeneLenovoT60 (host-19-93.meeting.ietf.org [133.93.19.93]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id nAA8GZa3010959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Nov 2009 09:16:44 +0100 From: "Christian Hoene" To: "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> Date: Tue, 10 Nov 2009 09:16:35 +0900 Message-ID: <007101ca619b$16f60ed0$44e22c70$@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: Acph3LYKM8OZE+gITmu7Fk/tky94AwAQhb+g Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:16:23 -0000 Hello Ingemar, > I am curious to know to what extent proponents of a Codec WG in IETF has > approached ITU-T with a request to standardize a RF codec. Gregory M. Lebovitz has posted this email two weeks ago: > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Gregory M. Lebovitz > Sent: Sunday, November 01, 2009 12:26 AM > To: Peter Saint-Andre; codec@ietf.org > Subject: Re: [codec] *draft* agenda > > > d. Coordination has occurred with ITU-T SG 16 > > s/has occurred/is occurring > > Justification: We have had a good call between IETF leaders and > ITU-T SG 16 and other ITU-T leaders to ensure good coordination > around this topic. I and Cullen are drafting a formal Liaison to the > ITU-T, which is being reviewed by the IAB and will be sent this > weekend. But this effort will entail continued and on-going > coordination with ITU-T, as they have much to offer in this process. I am not aware of any official liaison statement, yet. With best regards, Christian From gregory.ietf@gmail.com Tue Nov 10 00:30: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 9480128C134 for ; Tue, 10 Nov 2009 00:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 O-MuoKQhQk7P for ; Tue, 10 Nov 2009 00:30:07 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 97AFF28C133 for ; Tue, 10 Nov 2009 00:30:06 -0800 (PST) Received: by gxk28 with SMTP id 28so431678gxk.9 for ; Tue, 10 Nov 2009 00:30:31 -0800 (PST) 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=6rdF7b334xydNuHhuz1bktftS13ujvqMUvJCyKoLl9o=; b=ixm3R4ABDDpS1aanfe0WT+QgaURtjanWCKUKFvFH0JSF+8Whd8gBBvQTdmfiqf1gck 1EJy5Ca4XNNZ3jo8PqDphnKBJytqJArqkNn3dLpzbIsDMiQuYApuLh+JohAphZdysOBx 5eXaJ1W9Lrg1fZRH757XG3CzgwKowK1lpCgW4= 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=nNtml0cftpGteqxF0vv0ySGH7dPK998G2AE0KXIPXC+lW2OzmLpIAjlXwh3Ton3fDJ AktO3OzsOWXofGFafdxxQpjHBKXm6OuoANDx0nuvKZDpFvSuO5xHXDKMfoTKhWTNTxCi 2bXMuX7M0K2zGCoM6vWZQVUTnb1kDMyzX1+7g= Received: by 10.151.29.8 with SMTP id g8mr15305819ybj.250.1257841830998; Tue, 10 Nov 2009 00:30:30 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 13sm248346gxk.1.2009.11.10.00.30.28 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 00:30:30 -0800 (PST) Message-ID: <4af924a6.0d0bca0a.0949.1684@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 00:30:24 -0800 To: Mikael Abrahamsson ,"codec@ietf.org" From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:30:08 -0000 At 12:03 AM 11/10/2009, Mikael Abrahamsson wrote: >On Mon, 9 Nov 2009, Henry Sinnreich wrote: > >>Metrics and values/numbers would be very interesting if you can >>share them, to better understand the requirements. Also to make >>sure in what usage scenarios they may occur. > >2 seconds jitter and 10% continous random packet loss should >definitely be handled gracefully (during the tsunami where several >fiber optic cables were severed in asia, packet loss from the region >to the rest of the world was continous 5-7% due to remaining paths >being extremely congested). 2 seconds is for multiple links in a row >being full (typically Cisco 12000 routers can buffer 600ms of data >when congestion occurs). There are numerous cases (ADSL2+ without >interleave, high speed links with CRC errors, ethernet duplex >errors) where random packet loss can be seen. Typically this is less >than 1%, otherwise people tend to fix the problem because TCP works very badly. > >We then have the 3G/wifi network issue, where jitter can also be at >least 2 seconds, plus packet loss as well (some networks seem to >buffer X kilobytes, some Y number of packets, after that they tail >drop. I've seen both behaviours). > >Burst loss, where when you have a network re-route, you might lose >typically 0.05 - 2 seconds of data, and you might get re-ordering >during the convergence. Since this is a transient event, I don't >think much can be done about it but try to play data as they come in >and just ignore out of order packets. Perhaps jitter buffer should >be increased when out-of-order packets is seen, but when things calm >down again it needs to be reduced again. > >I've also seen networks which re-order packets constantly, I don't >know what the load-sharing algorithm used is, but I think the jitter >buffer size should be adapted and handle out of order packets so >they're presented to the codec correctly. > >When running voice over GSM GPRS, typically there is very low >bandwidth and high delay. Here bw should be kept as low as possible >and the IP header is a big overhead and pps should thus be kept at a >minimum, for instance 3-5 pps and the very lowest quality setting >should be used. > >So, the SYSTEM (I'm not just talking codec here), as far as I can >see it, needs to gracefully handle at least 10% packet loss, out of >order packets (analyse the time they might be re-ordered and adapt >jitter buffer accordingly), or just plain jitter up to 2s. > >My reasoning here is mainly focused on voice over Internet, but as >far as I can see this applies to all sound, even though if it's not >interactive I guess the focus can be switched from low latency (it >might be better for a voice call to have lower latency than actually >getting perfect sound) to reliable sound delivery with higher >latency (by increasing jitter buffer and putting sound information >in multiple packets so that single packet loss doesn't mean silence >in that interval). Basically I'd like to see that as soon as jitter >buffer is increased, the resiliancy to packet loss should be >increased as well by telling the other end that it can start to do >packet loss concealment information in the packets as well (whatever >it's called, I'm not a codec guy). If sender knows what the receiver >jitter buffer is, then this can be used to increase resiliency (I guess). > >Does this help? I'm not a codec designer, or expert in this area at all, but that seems VERY practical and tangible. Those are observable metrics for behavior, and you provided a clear explanation of WHY you offered those metrics, which make decent sense to me. So, yes, it helps. Gregory. >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From ingemar.s.johansson@ericsson.com Tue Nov 10 00:33: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 A262428C0FB for ; Tue, 10 Nov 2009 00:33:51 -0800 (PST) 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_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 G93nf2VI-Mk8 for ; Tue, 10 Nov 2009 00:33:50 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 63ADD28C121 for ; Tue, 10 Nov 2009 00:33:50 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-29-4af92587a8e3 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8B.6A.16818.78529FA4; Tue, 10 Nov 2009 09:34:16 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:33:00 +0100 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, 10 Nov 2009 09:32:38 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0232A089@esealmw109.eemea.ericsson.se> In-Reply-To: <007101ca619b$16f60ed0$44e22c70$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: Acph3LYKM8OZE+gITmu7Fk/tky94AwAQhb+gAA+98QA= References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <007101ca619b$16f60ed0$44e22c70$@de> From: "Ingemar Johansson S" To: "Christian Hoene" , X-OriginalArrivalTime: 10 Nov 2009 08:33:00.0485 (UTC) FILETIME=[698C4750:01CA61E0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:33:51 -0000 Hi Noted, but what I was asking was more like "who has tried to approach ITU-T" earlier. If I recall things correctly there was a big laugh in the audience when it it was stated at the mic that "you can go to the ITU-T" at the last Codec BoF in Stockholm.=20 So from the SPL level of the laugh there must be a few who have tried this. BR Ingemar =20 > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 > Sent: den 10 november 2009 09:17 > To: Ingemar Johansson S; codec@ietf.org > Subject: RE: [codec] Standardization in ITU-T, what are the issues ? >=20 > Hello Ingemar, >=20 > > I am curious to know to what extent proponents of a Codec=20 > WG in IETF=20 > > has approached ITU-T with a request to standardize a RF codec. >=20 > Gregory M. Lebovitz has posted this email two weeks ago: >=20 > > -----Original Message----- > > From: codec-bounces@ietf.org=20 > [mailto:codec-bounces@ietf.org] On Behalf=20 > > Of Gregory M. Lebovitz > > Sent: Sunday, November 01, 2009 12:26 AM > > To: Peter Saint-Andre; codec@ietf.org > > Subject: Re: [codec] *draft* agenda > >=20 > > > d. Coordination has occurred with ITU-T SG 16 > >=20 > > s/has occurred/is occurring > >=20 > > Justification: We have had a good call between IETF=20 > leaders and ITU-T=20 > > SG 16 and other ITU-T leaders to ensure good coordination=20 > around this=20 > > topic. I and Cullen are drafting a formal Liaison to the=20 > ITU-T, which=20 > > is being reviewed by the IAB and will be sent this weekend.=20 > But this=20 > > effort will entail continued and on-going coordination with=20 > ITU-T, as=20 > > they have much to offer in this process. >=20 > I am not aware of any official liaison statement, yet. >=20 > With best regards, >=20 > Christian >=20 >=20 >=20 >=20 From gregory.ietf@gmail.com Tue Nov 10 00:54: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 ECCA928C151 for ; Tue, 10 Nov 2009 00:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 ZDrt4oibe0tj for ; Tue, 10 Nov 2009 00:54:48 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 3EB7A28C153 for ; Tue, 10 Nov 2009 00:54:37 -0800 (PST) Received: by yxe30 with SMTP id 30so4144149yxe.29 for ; Tue, 10 Nov 2009 00:55:00 -0800 (PST) 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=KiAeLn2psQ04szArb7KranvCeMRS3q0YatUYSVFR/oE=; b=Ncpi+qvdvfwX2/5+L0R4xRdymNb/fF/dxCBH8R+J204U4fOC9VWhMlTfPYO6p3b8ch vrpzSLuwL+JXajvw6/uSorWW4H6BNPitEZT+/MoLPxbzqjdBPTqj2mkTMfG8sIbt17iB ENOeJjAEWfoQ8WHzMvZ6iREMD+8ga/KT8VwB4= 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=iKRSMFjyd21bG5zFEmlEDdImOd2/NLRt5R7e7Lhj97LxJ+dGrEqtsabUXLQ5aVkWId 9LW9asrCuLV7Uw8Bdn47/SGMSdFzUhmv4HRVmH9N1Ttjje4NQC4snYFveVUvmNR7cK/h y78qFL3nRSLfAYDE7MEJgJ8Q4TimpL2mudDKo= Received: by 10.150.119.23 with SMTP id r23mr15429147ybc.169.1257843300681; Tue, 10 Nov 2009 00:55:00 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 15sm272634gxk.8.2009.11.10.00.54.58 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 00:54:59 -0800 (PST) Message-ID: <4af92a63.0f0bca0a.2df9.1bae@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 00:54:45 -0800 To: Mikael Abrahamsson ,"codec@ietf.org" From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 08:54:49 -0000 At 11:01 PM 11/9/2009, Mikael Abrahamsson wrote: >On Mon, 9 Nov 2009, Henry Sinnreich wrote: > >>>- Robustness to packet loss >> >>Are you thinking of burst packet loss or random distributed packet loss? >>And what would be the metrics and values for either? >> >>If we have no metrics and no credible values, I suggest to forget >>this rat hole. > >I *strongly* disagree to this line of thinking. This thinking is >what is causing a lot of the current system implementations (codec >and transport together) to not work properly on "the Internet". See >my previous email on this list on this issue. > >I can come up with metrics that are realistic, that I have seen in >real life. I might not have the exact numbers, but I have scenarios >where they occur. > >>Broadband Internet has IMO and negligible packet loss, except for >>congestion events where the codec cannot do anything anyway. Well, I'm sitting here in the CONEX BoF where several cable operators have presented on why they think there is a problem with congestion and the associated service degradation and packet loss. It's anecdotal input, yes, but it's compelling. >>Packet loss was a big deal in old analog modem times and pre-3G/4G >>wireless networks :-) Again, listen to the archived audio stream of CONEX, and the jabber archive too, which held a lot of discussion on the observed loss in networks. Gregory. >This is still a problem (and no, it wasn't a problem on analog >modems with ARQ), depending on where in the world you are. I can >come up with multiple scenarios where I want this "Internet >codec/transport" to work that current implementations do not work >in, where for instance you trade latency for pps for instance. In >some cases it's better to send 5 pps with 500 byte packets to get >the packets thru, than to send 50pps of smaller packets because they >do not go thru. Yes, latency suffers, but it *works*. > >I'd rather have a 2 second end-to-end latency for my call than no call at all. > >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Tue Nov 10 01:07: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 C8B5928C13E for ; Tue, 10 Nov 2009 01:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 87CQiPoTWaX5 for ; Tue, 10 Nov 2009 01:07:40 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 7109528C11A for ; Tue, 10 Nov 2009 01:07:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSvktdKCfzQL8uzX1fEyGn/pto5IZzjs1@postini.com; Tue, 10 Nov 2009 01:08:07 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Nov 2009 01:01:56 -0800 From: Michael Knappe To: Mikael Abrahamsson , "codec@ietf.org" Date: Tue, 10 Nov 2009 01:02:01 -0800 Thread-Topic: [codec] questions to be answered Thread-Index: Acph3FSqLeEZtGwxRG+PePelQEZ/KgACCJMu 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 09:07:41 -0000 Mikael, Thanks for the very useful industry examples and metrics. Handling of these= examples fall either into jitter buffer design (which so far in the BoF em= ail correspondence, other than noting the need for some form of adaptive ji= tter buffer algorithm, is being treated as largely outside the scope of the= proposed WG) or packet loss concealment (which IS often tied to the codec'= s design). As you've noted, other than doing the best it can to maintain a = balance between the impairment due to end-to-end latency and impairment due= to periods of packet loss concealment, there is really no crystal ball tha= t can be employed to recover large numbers of consecutively lost packets du= ring wildly varying jitter conditions. As you mention in your email, it is possible to more tightly couple PLC and= the jitter buffer. For instance, a proposed codec's decode operation could= provide an intelligent feedback loop to the jitter buffer at the receiving= end to let it know how well it's packet loss concealment algorithm is curr= ently operating - for instance telling the jitter buffer to go ahead and ra= pidly increase its size if the PLC algorithm is simply falling apart under = enormous packet loss. There are also examples of time varying / frequency i= nvariant 'stretch' jitter buffers that are an integral component of the cod= ec design, and we should treat them as a whole while evaluating any such pr= oposed codecs. Mike On 11/10/09 12:03 AM, "Mikael Abrahamsson" wrote: On Mon, 9 Nov 2009, Henry Sinnreich wrote: > Metrics and values/numbers would be very interesting if you can share > them, to better understand the requirements. Also to make sure in what > usage scenarios they may occur. 2 seconds jitter and 10% continous random packet loss should definitely be handled gracefully (during the tsunami where several fiber optic cables were severed in asia, packet loss from the region to the rest of the world was continous 5-7% due to remaining paths being extremely congested). 2 seconds is for multiple links in a row being full (typically Cisco 12000 routers can buffer 600ms of data when congestion occurs). There are numerous cases (ADSL2+ without interleave, high speed links with CRC errors, ethernet duplex errors) where random packet loss can be seen. Typically this is less than 1%, otherwise people tend to fix the problem because TCP works very badly. We then have the 3G/wifi network issue, where jitter can also be at least 2 seconds, plus packet loss as well (some networks seem to buffer X kilobytes, some Y number of packets, after that they tail drop. I've seen both behaviours). Burst loss, where when you have a network re-route, you might lose typically 0.05 - 2 seconds of data, and you might get re-ordering during the convergence. Since this is a transient event, I don't think much can be done about it but try to play data as they come in and just ignore out of order packets. Perhaps jitter buffer should be increased when out-of-order packets is seen, but when things calm down again it needs to be reduced again. I've also seen networks which re-order packets constantly, I don't know what the load-sharing algorithm used is, but I think the jitter buffer size should be adapted and handle out of order packets so they're presented to the codec correctly. When running voice over GSM GPRS, typically there is very low bandwidth and high delay. Here bw should be kept as low as possible and the IP header is a big overhead and pps should thus be kept at a minimum, for instance 3-5 pps and the very lowest quality setting should be used. So, the SYSTEM (I'm not just talking codec here), as far as I can see it, needs to gracefully handle at least 10% packet loss, out of order packets (analyse the time they might be re-ordered and adapt jitter buffer accordingly), or just plain jitter up to 2s. My reasoning here is mainly focused on voice over Internet, but as far as I can see this applies to all sound, even though if it's not interactive I guess the focus can be switched from low latency (it might be better for a voice call to have lower latency than actually getting perfect sound) to reliable sound delivery with higher latency (by increasing jitter buffer and putting sound information in multiple packets so that single packet loss doesn't mean silence in that interval). Basically I'd like to see that as soon as jitter buffer is increased, the resiliancy to packet loss should be increased as well by telling the other end that it can start to do packet loss concealment information in the packets as well (whatever it's called, I'm not a codec guy). If sender knows what the receiver jitter buffer is, then this can be used to increase resiliency (I guess). Does this help? -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From simao.campos@itu.int Tue Nov 10 04:31: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 0B8FB28C1AA for ; Tue, 10 Nov 2009 04:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwwi83HxH9ti for ; Tue, 10 Nov 2009 04:31:47 -0800 (PST) Received: from protext02.itu.ch (protext02.itu.ch [156.106.192.19]) by core3.amsl.com (Postfix) with ESMTP id C820728C1A7 for ; Tue, 10 Nov 2009 04:31:45 -0800 (PST) Received: from protext02.itu.ch ([156.106.192.19]) by protext02.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Nov 2009 13:32:11 +0100 Received: From PROTINT0.blue.itu.ch ([156.106.128.46]) by protext02.itu.ch (WebShield SMTP v4.5 MR3) id 1257856326891; Tue, 10 Nov 2009 13:32:06 +0100 Received: from MAILBOX1.blue.itu.ch ([156.106.130.106]) by PROTINT0.blue.itu.ch with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:32:06 +0100 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_01CA6201.D031E938" Date: Tue, 10 Nov 2009 13:32:04 +0100 Message-ID: <334A4109C6BEA14ABB48EBCF274A6C8A055399DF@MAILBOX1.blue.itu.ch> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 2009) Thread-Index: AcmQIkz5T2nGCOt3SSuWmu9aW21jHTR3oR3Q From: To: X-OriginalArrivalTime: 10 Nov 2009 12:32:06.0562 (UTC) FILETIME=[D079E820:01CA6201] Subject: [codec] FW: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 10 Nov 2009 12:31:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6201.D031E938 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, please find attached a liaison statement sent from SG 16. I extracted = the files from the ZIP since we had some difficulties with the server. Best regards, Simao << ls-124.pdf >> << ls-124.doc >> _____________________________________________ From: TSBSG16, ITU [mailto:tsbsg16@itu.int]=20 Sent: 10 November 2009 10:57 To: Cullen Jennings; statements@ietf.org; Robert Sparks; Gregory = Lebovitz; Russ Housley; Patrik F=E4ltstr=F6m Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com; = herve.taddei@huawei.com; hiwasaki.yusuke@lab.ntt.co.jp; = hiwasaki.yusuke@gmail.com Subject: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 = November 2009) Dear all, Kindly find attached the Liaison Statement COM16 - LS 124 on "speech = and audio coding standardization" addressed to IETF RAI, IESG agreed at = the ITU-T SG 16 meeting held in Geneva from 26 October to 6 November = 2009.=20 =20 Best regards, Rosa Angeles-Le=F3n de Vivero on behalf of ITU-T Study Group 16 ITU - Telecommunication Standardization Bureau (TSB) SG 16 e-mail: tsbsg16@itu.int << ls-124.zip >> ------_=_NextPart_001_01CA6201.D031E938 Content-Type: application/octet-stream; name="ls-124.pdf" Content-Transfer-Encoding: base64 Content-Description: ls-124.pdf Content-Disposition: attachment; filename="ls-124.pdf" JVBERi0xLjQNJeLjz9MNCjkgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgMzM2NzcvTyAxMS9FIDI4 NTMxL04gMi9UIDMzNDUxL0ggWyAxNTk2IDI2NF0+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAg DQp4cmVmDQo5IDY1DQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDE4NjAgMDAwMDAgbg0KMDAw MDAwMTkzNyAwMDAwMCBuDQowMDAwMDAyMTE1IDAwMDAwIG4NCjAwMDAwMDI3MTggMDAwMDAgbg0K MDAwMDAwMzIxNiAwMDAwMCBuDQowMDAwMDAzNzQ3IDAwMDAwIG4NCjAwMDAwMDM3ODEgMDAwMDAg bg0KMDAwMDAwMzgyNCAwMDAwMCBuDQowMDAwMDAzODY3IDAwMDAwIG4NCjAwMDAwMDM5MTAgMDAw MDAgbg0KMDAwMDAwMzk1MyAwMDAwMCBuDQowMDAwMDAzOTk2IDAwMDAwIG4NCjAwMDAwMDQwMzkg MDAwMDAgbg0KMDAwMDAwNDA4MiAwMDAwMCBuDQowMDAwMDA0MzI0IDAwMDAwIG4NCjAwMDAwMDQ0 MDAgMDAwMDAgbg0KMDAwMDAwNTA4MyAwMDAwMCBuDQowMDAwMDA1Njg2IDAwMDAwIG4NCjAwMDAw MDYyMjggMDAwMDAgbg0KMDAwMDAwNjkxNiAwMDAwMCBuDQowMDAwMDA3NTI5IDAwMDAwIG4NCjAw MDAwMDgyMDAgMDAwMDAgbg0KMDAwMDAwODg0OSAwMDAwMCBuDQowMDAwMDA5NTA0IDAwMDAwIG4N CjAwMDAwMTIxNzMgMDAwMDAgbg0KMDAwMDAxMjQxOCAwMDAwMCBuDQowMDAwMDE0NjA0IDAwMDAw IG4NCjAwMDAwMTQ4NTMgMDAwMDAgbg0KMDAwMDAxNTE0NCAwMDAwMCBuDQowMDAwMDE1NTA2IDAw MDAwIG4NCjAwMDAwMTU4NzAgMDAwMDAgbg0KMDAwMDAxNjI0MSAwMDAwMCBuDQowMDAwMDE2NjIw IDAwMDAwIG4NCjAwMDAwMTcwMDQgMDAwMDAgbg0KMDAwMDAxNzM3NCAwMDAwMCBuDQowMDAwMDE3 NzE2IDAwMDAwIG4NCjAwMDAwMTgwNjggMDAwMDAgbg0KMDAwMDAxODUzMCAwMDAwMCBuDQowMDAw MDE4OTk2IDAwMDAwIG4NCjAwMDAwMTk0MzYgMDAwMDAgbg0KMDAwMDAxOTcyNCAwMDAwMCBuDQow MDAwMDIwMDY1IDAwMDAwIG4NCjAwMDAwMjA0ODEgMDAwMDAgbg0KMDAwMDAyMDcyNCAwMDAwMCBu DQowMDAwMDIxMTAxIDAwMDAwIG4NCjAwMDAwMjE1NzUgMDAwMDAgbg0KMDAwMDAyMTcwOCAwMDAw MCBuDQowMDAwMDIyMDQ3IDAwMDAwIG4NCjAwMDAwMjIxODAgMDAwMDAgbg0KMDAwMDAyMjUyMyAw MDAwMCBuDQowMDAwMDIyNjU2IDAwMDAwIG4NCjAwMDAwMjMwMTAgMDAwMDAgbg0KMDAwMDAyMzU2 MSAwMDAwMCBuDQowMDAwMDIzODg1IDAwMDAwIG4NCjAwMDAwMjQyNzcgMDAwMDAgbg0KMDAwMDAy NDQ5MyAwMDAwMCBuDQowMDAwMDI0NzY5IDAwMDAwIG4NCjAwMDAwMjUxNjggMDAwMDAgbg0KMDAw MDAyNTQ2MyAwMDAwMCBuDQowMDAwMDI1NzQyIDAwMDAwIG4NCjAwMDAwMjYwODUgMDAwMDAgbg0K MDAwMDAyNjMxNSAwMDAwMCBuDQowMDAwMDI4MjgzIDAwMDAwIG4NCjAwMDAwMDE1OTYgMDAwMDAg bg0KdHJhaWxlcg0KPDwvU2l6ZSA3NC9QcmV2IDMzNDQxL1Jvb3QgMTAgMCBSL0luZm8gOCAwIFIv SURbPDQwNEQyMjkyQzlGQTI1RDI5MTY5QURFRTdCNkU1RDI3PjxEOTk5RTRBNkE3RjVDMTQ4OEE5 Rjc3NEE2RjNBNEYyRT5dPj4NCnN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgICAgICAgICAgICAgIA0K NzMgMCBvYmo8PC9MZW5ndGggMTc4L0ZpbHRlci9GbGF0ZURlY29kZS9JIDIwOS9MIDE5My9TIDY4 Pj5zdHJlYW0NCnjaYmBgYGZgYOtkYAMy9jHwMyAAPwMLAysQc7xhOOHBwHAVJi7YnNsAYTUwcIBk kIAdFDMwKDHwcDJZyjJ+ZGDgZJgARbwMWhqTLOUP9akY1aoV5S7ZcLmt4bqAoIfIwkDRiXGijCbC D9dIM07jf2gs/uCiaOEONkNDNkNTNkMHhUAlsYRt/Iq5AgFfhQOOVDy4hmQpCwNDkSaQZgJiCyDm ALpsF5BmBOL7AAEGADOOKEENCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmo8PC9NZXRhZGF0YSA3 IDAgUi9QYWdlcyA2IDAgUi9UeXBlL0NhdGFsb2cvUGFnZUxhYmVscyA0IDAgUj4+DWVuZG9iag0x MSAwIG9iajw8L0Nyb3BCb3hbMCAwIDU5NSA4NDJdL1BhcmVudCA2IDAgUi9Db250ZW50c1syNSAw IFIgMjYgMCBSIDI3IDAgUiAyOCAwIFIgMjkgMCBSIDMwIDAgUiAzMSAwIFIgMzIgMCBSXS9Sb3Rh dGUgMC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vUmVzb3VyY2VzIDEyIDAgUi9UeXBlL1BhZ2U+Pg1l bmRvYmoNMTIgMCBvYmo8PC9YT2JqZWN0PDwvSW0zOCAzNSAwIFIvSW0zOSAzNCAwIFIvSW00MCAz NyAwIFIvSW00MSAzOCAwIFIvSW00MiAzOSAwIFIvSW00MyA0MCAwIFIvSW00NCA0MSAwIFIvSW00 NSA0MiAwIFIvSW00NiA0MyAwIFIvSW00NyA0NCAwIFIvSW00OCA0NSAwIFIvSW00OSA0NiAwIFIv SW01MCA0NyAwIFIvSW01MSA0OCAwIFIvSW01MiA1MCAwIFIvSW01MyA1MSAwIFIvSW01NCA1MyAw IFIvSW01NSA1NCAwIFIvSW01NiA1NSAwIFIvSW01NyA1NiAwIFIvSW01OCA1NyAwIFIvSW01OSA1 OCAwIFIvSW02MCA1OSAwIFIvSW02MSA2MSAwIFIvSW02MiA2MyAwIFIvSW02MyA2NSAwIFIvSW02 NCA2NiAwIFIvSW02NSA2NyAwIFIvSW02NiA2OSAwIFIvSW0xMDYgNzAgMCBSL0ltMTA3IDcxIDAg Uj4+L0NvbG9yU3BhY2U8PC9DczYgMTUgMCBSL0NzOCAxNiAwIFIvQ3M5IDE3IDAgUi9DczEwIDE4 IDAgUi9DczExIDE5IDAgUi9DczEyIDIwIDAgUi9DczEzIDIxIDAgUi9DczE0IDIyIDAgUj4+L0Zv bnQ8PC9UVDIgMTMgMCBSL1RUNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1h Z2VJXS9FeHRHU3RhdGU8PC9HUzEgMjQgMCBSPj4+Pg1lbmRvYmoNMTMgMCBvYmo8PC9TdWJ0eXBl L1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDcyIDAgUi9MYXN0Q2hhciAxNTAvV2lkdGhzWzI1MCAw IDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMCAwIDUwMCA1MDAgNTAwIDAgNTAwIDAg NTAwIDAgMCA1MDAgMzMzIDAgMCAwIDAgMCAwIDcyMiAwIDcyMiA3MjIgNjY3IDYxMSA3NzggMCAz ODkgMCAwIDY2NyA5NDQgNzIyIDc3OCAwIDc3OCA3MjIgNTU2IDY2NyA3MjIgMCAwIDAgMCA2Njcg MCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMCAwIDI3OCA4 MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDAgMCA1MDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDBdL0Jhc2VGb250 L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNv ZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTQgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnRE ZXNjcmlwdG9yIDIzIDAgUi9MYXN0Q2hhciAxNTAvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDMz MyAzMzMgMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCAyNzggMCAwIDAgMCAwIDkyMSA3MjIgMCA2NjcgNzIyIDYxMSA1NTYgNzIyIDcy MiAzMzMgMzg5IDAgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDcyMiAwIDk0NCAw IDcyMiAwIDAgMjc4IDAgMCA1MDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3 OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIy IDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDUwMF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0Vu Y29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTUgMCBvYmpbL0lDQ0Jh c2VkIDMzIDAgUl0NZW5kb2JqDTE2IDAgb2JqWy9JbmRleGVkIDE1IDAgUiA1NCAzNiAwIFJdDWVu ZG9iag0xNyAwIG9ialsvSW5kZXhlZCAxNSAwIFIgNjcgNDkgMCBSXQ1lbmRvYmoNMTggMCBvYmpb L0luZGV4ZWQgMTUgMCBSIDUyIDUyIDAgUl0NZW5kb2JqDTE5IDAgb2JqWy9JbmRleGVkIDE1IDAg UiA4OSA2MCAwIFJdDWVuZG9iag0yMCAwIG9ialsvSW5kZXhlZCAxNSAwIFIgNzkgNjIgMCBSXQ1l bmRvYmoNMjEgMCBvYmpbL0luZGV4ZWQgMTUgMCBSIDQzIDY0IDAgUl0NZW5kb2JqDTIyIDAgb2Jq Wy9JbmRleGVkIDE1IDAgUiA2NCA2OCAwIFJdDWVuZG9iag0yMyAwIG9iajw8L1N0ZW1WIDgyL0Zv bnROYW1lL1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQw MC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU2OCAtMzA3IDIwMDAgMTAwN10vQXNj ZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0 IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTI0IDAgb2Jq PDwvT1BNIDEvT1AgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4w Mj4+DWVuZG9iag0yNSAwIG9iajw8L0xlbmd0aCA2MTQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJbFNNj5swEL3zK+aIpcbBxhjorV+qttfQ06oHAs7GFWCEzUbpr+/YZjfZbhUpsmc8b96b N+y/Hxg82eRzk+ybhgOD5pTUkOGvhoLTnEOVUcazHJox2X+xEjob0hnYbkp2Gc2yrISmSzJoLslj +sk5RXY5LdLJaTN9JL+aHx5bRGxB80qWWN18TXwtK0KtP1URAA5mVGAWIJLKtB2ITAcwJ1LSKgV3 VqSgeQojhttwdGrR/jJsBc75W3cmFeWp6mPUmXDFem1jZNCxXFszgXUbFkFBZRp7+BZqchAUcEFF ned3xMUr8ToSH7GqDqR4eoWjCgew6/G36sLZQaDBUnhofkYWnZlD5EoYFemin86OEoEU4AFZrUEF vo+gEGFasvOPrUI1IY2SLnoYQvvXvoH1jle0qgDfswLJb9S9mZF6Hpnrqddd61RPsLGe/D8OGnz4 WfcrjrY33ToSxtBWHAmFCJ8FZIF+viDLF2ReRugDaoD2JrbEwV7JTiJtrzbcHcIrC5NxMC/qOcTU tKVcfKNgRcHmtNmJ7MJhbL39SPBkFgygfu1sNAwtrKJdj16UU1PvBfrlmddlNlZ9gOPqsOBNV1/L OJXyfkvfTczZG5FFzYvpV5xa5zc+JpBpO+DeLuEWx4XjY/IGyre9mdvF+QWX3nZk4w0Ipm8eipry DNn862L9OmuxAa3HwfuIJBABu150mB6yWbdB4kZvn8nqzmbRf8Lr+HnxsJc0dv3WJL4vVPjZ4Bip iH+47ag3Od0nRY2A/G26EDh+casu6/p/AEL6VwFdMFqLdymPzcR9JfwVYADJlCoJDQplbmRzdHJl YW0NZW5kb2JqDTI2IDAgb2JqPDwvTGVuZ3RoIDUzNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVh bQ0KSIlsk02P0zAQhu/+FXNMkDrrr/HHsZQeirpdwXrFAXFaUQmkguCy/4Tfy2sn8SYIVXJcZ57x vO9Mrkq8sPPkQ101+5hzIm84e/r9VV3//x7PpLWZIt4WlUnjl0kCR3KJTdKOyk1pKs91eVEDjeW7 Mpq1bbHTztjIEiiKcA4zwkhsG4ddPXtRn4fTpYyR3XAcDdaPl9FzGvblhGceHtq/y/6MEDtQOZ6n 2MP04h6rmdeny+kwZpZhP+4MgktD5jRTVnqa0k0Bmxto/FLeq7tSUDmVqzKOqxlVTtt5E1gS5FjW azmhytnVrY3NjMPDPeH0D50f4YHH5ljtORb1Sxn6RqoZGYOwpQCzLe0CGhCq4Z/e0A+E+cwBvciu 3W81i0V6kozO6bqLrXHaOUvPN3V3uhkd6d1P9aHCAeU2d1vxHHCNZaNnEGLxTvwMet25xFpynkXj Tk/BoIO6DkPlLGQbWTiz4sKUfM21uxxHiyLjwtjOZDa+1/gPgwGzqGJm3MKIZmtQX1wxdVbBWA4w Y/HC+xUSqyR5RaqHDke5YXDF+c5J5zCIelvemmuuOLydubDiUpXlN5xfrK8KUWa3sLcMM+XiVtqa a1+k893G1DnH/lUf0ieSxGlumWspXC8zr7CqJIcNBv+iqw90eWGkT4d4FtdL3DD4yuA+PvWZ6ZOB QTeh29EmUVpwk+UEB5OJ9FeAAQBgBfOWDQplbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqPDwvTGVu Z3RoIDQ3My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMkz9v2zAQxXd9Co7UoPMd/4qj a3lQ0diNwwxJ0ClAhwJG0alfv4+0pMiBg0YCTILmj+/d8Wkznr1Rw+/mvvnT+EAh4YmK8Qpxr7AU GY+oaB15x9Y59XpuNuDswkUyFlxfOUPxChPqgVkzY26FxQjM35ZjioGt+JnzM8fwUZE6EYHrop5u MOG2VgWvtYyBxzhz8VNa10z/OS2TKPRs0KyJS//Xes8Evq3lyEol1nqeLHri5/4H+ejaJFxxlgyj l3N94cOY4J81J+R7tmbRsytOAja51X3DgsOSAYeqocfz3YW3nHhsrZve+tkTAhUlUUJtZvG4ZMQj rPadx4nBsM5jWDISmNzUCzQDtpCj0t+ibVVI8IrC7Jx/O134ffMlN5uccWUq/2zkYhODSCQMIfX1 C1D53LDKr+Xnb6NVm38VzEyYpanAy0xMJMS3xCxNcMcEJ305Quf9t/3ueHf3eBh32zweD/U4Vp3A efQqD9N2KdvrVKTovuiHvD0M29MwPrfFoN62gJyuhzzsd/l4Uu2P/HVdEi/eeOWtFFZbM3vDnZfy MMNXMWk9Dm3nKOgn9X1/apEAPbZIiD5eloe2aCskre08GZ26su61YbksGJhR/wQYANin9OcNCmVu ZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmo8PC9MZW5ndGggNjE5L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiZxTwXKbMBS88xXvKDpBkYQkRG7u1PG4k8bTWD3VORCsOHQMeDBOJ/2Qfm+fgILT tJeOZ2wNZnff7j7Zj8GltQI42MeAxzQ1wPDTn2QiqNGQcEa5YTHYMmCUMZaCzYPIHwXY7wGZV7t9 cXyCutq/hPZbEAnKuUoh4lQlqQT7ocNxDyOrptgVVba/ggHmEVz0sgKUpglorWl8rmg8lHmxr+Tz yR3boq7ChGzIcRNeQXhvOxuyt4EMEhDGfwszOQ7MRU/C2SXXEEZcKaGoIQtXuefsAoSGVd7WD66B CDTc1s8ujPwLZWioIA8ho5LgnwJT6GTnNlAS4wFtYqokyFRRaQCdQ+OCx+C9PQ94tCnihEoBWmqq BqPdfEx3ToeTn/RmOVuuV7ewDiOJ2jbk+D2z80/zW9s7RxMU38a0tRotqzExsq5PTe4wJgz6Xyl1 1Sztl8jCuj1tX2DR1KcD+Ix61OAg6mBeSntcNGkRW7R7d/VaRNA4Vuh4lOjo0AdiXjUkxobY0NCd O+xf4GYNbQ3Lub3G7YLjwbn8CbJqC9lpW9SQ19ui2sGxxUdZsy1+ZN1mKKxq3IphckNjAbiZwqhp 8v9I2xceU4Obmmpq+sLx57zwP7ZZqZSa823mk1ney17XDWS5nx3tYlNRzLgine272fICA1gvenn2 umc+cfEzrrwuSxdKmpKqHRi5NoxEPYl91w+STIMkE7ioHuumzM6mUfwN9G1hs8OhqZ/9xcbspGZk tmucw6ZaGBZr4fepdK7tmARGq4fd8DTx5KQn9M1u/nYzf4LGimPSXc/yYbiOmzC8h18CDACU4CWj DQplbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2JqPDwvTGVuZ3RoIDU0NC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImMkstu20AMRffzFVzKLczO+5FV0CaFEaBdzSYwupjaSq1ElgM/6vbvO0PJ lhtk4Z0okLyXc098YFMpUFuYCrQG4h3T6JR2EI9sXt3Vadk2XX0D39J2sYKJdspUkgsOkx/xgfEy 5hzNceScW4iL/DcPV1823T4t9jcwic/sU4waBMQnZtFpyL2izExPQ0VsVm9/1xDTcjkxaKu6udAQ o4QuEtPTZxaaHdIxN8d6seo27eZXU+9IM344OVk1XaJfwqPiBiQqWlc2zatYt9nkVGjDq486gLAS ZNAcpOXvWhChH7xfTwK6KjVlvu/j+cjdomMKlcjF+URRJqpVuRD3+cK6uV2RbVxs1sXZfWQqWAwW tFboPAjpUfr8UiaE4GFbsyf2OTIhgVQkGGlQ6txu0HGeD1qTPid9Oq2CYbNR6CVoZ9FoUFyUCASa fqmABpgyBk3Wdh7zq66Z0QHtuW7Hmla0Y/9Qk7ccsuxDvnCZ8wYt8hl68HjG5CpCqF2OkUtK9PGw O7zUMGuOaZdeGlpwERK1Cjmy+D3GMxJliyH9h/Sauiu58AK0zOcE0D6LvEvmW5vz6mv6QyukH1dk qJwXol8xGOqJ4v3QVViRiuqpGl4B/9Kr3LbpJ3b7fSYLn1//Z0t5yr7kq8vHULeXtaB8x37R5zuy NdAkXU72LUwnLmRAeYERlSNFNDpCNJTEUCCZ0HOjHEc7cAP/BBgAFkULtA0KZW5kc3RyZWFtDWVu ZG9iag0zMCAwIG9iajw8L0xlbmd0aCA2MDIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ ZJPJbtswEIbveoo5SkBMaKNkH1M0LVL0lAjoociBkUY1W1p0SSqp+/Qdkra8FIZlyhA//ssoh65P Usi6n8lDl/CKrUuo2jVbQ5UXrK2hYBwMJmNScc54A9U6ZxXsEl5vWHO6Vctt2KqWh4+3Y/KhS4oS cvrQD29YC1XNGe2uoNslOcvzvPRSVn5ZQPeepM9uHg7w2eh5D0UDbiumXxYeH7pP8HT/CPcGRdBd NIwoOXQfI6deOKXnfE9HbWg3SgNfpZBWT/DshMNdtmZlipNjkL10X5JVBK0K1nAPi1LqyHjCEY2R 0w9w2sPoaxAhMkRGz65TOUFvpEMjA6+oWN1e6Dr7q3gwKChYT8XBQ2n3Qc8G1FGjdcFcQY3wC0q1 UPzSSztaKbyVO7hJ7V3aLVrPjx5LzsoN9yYLvjCLMzNG/xqdks1RK6XfL3wL5+gcSQL1uJTBQhH5 ObtbqZso9UbcVlgQsBNuNgSeBtgb/YYTDPiGSu9ProLykgbxmMOF+9T5PT1aC75liwp759V6mnV0 FWaQf/0/XuEqUq7dt+e5Ow6M3SP228AQ8yA19HrAnrT2vTZDxlmbxkTCkiwM6IRU1KPNarZJ0c8D J216PGlvqivxTTwIHJ0zyV4oGoXfM+GaVJpQZ+3rtAy+ZRtCBWKTwisqSeH4l8HRRdpTrfGExdjV 7F7EGainyO78/MmJZFPqhnqYDmBlfEwqYQD/oDkZKOvLKSz+q7aXFonoKx3IQEsx6Mk6Q9M5RLnS QS9orufeHz7OSh3O6j3+upbmXEtIC/4JMADs2UFIDQplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2Jq PDwvTGVuZ3RoIDU4MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImElM2SmzAQhO9+ijmK KqMCY/xzzyHOcYuctnJg5cEohSUiyXb89plBYLybreTiwthq+uue4VV47FAFUPaIykNo6wDnZCfX AjEswTrQyY/q2yLPZVaWkEH1ZZFmMsuKFVS3xaswR8Qj4O+klFuh6HpJIgh2+O6SNJeF0Cdt6g4C qtZoVXdRcS2Ld4pZDpVaTFe3hQCHvy7a4RlN8BJesO/odNDmxL6S6uciXZVynQM9JC9ZJ2OFQSzf DBIOtbnScT4TWu3JaI8uaI/gW3vpWCRfyXI1Gpl9REv7CHkEYwO8IVwI16EP+pxs5V7Ugdjf7lDD ydlLD3+BDSKrWW8ITdy0bwdHFo54xc72pDA0IGHk2sjdjrk25UNmP8Oto61DAELS3NdW9NaF2gQW JbNIuFQBW+Q+kvXURi6QD5nhR5tk9BkmM/1w00WK/eeJxGqQQyXTzt7rLtzTxiFGAkqJ1eJYUTq1 h752AWwTyUh3rosFi1m7iFg8P1FrTIcByTc9sXdWofdw02waDtX3tJJwMKNlud48T1RMG5pa0Sh7 0nI0hZNldrOT70Y6zszM4qGtr0hEaMZaqHR6wnuAj/XSuETbTG+O0FgKnvoUhCEeYcyQXFxjI8FW borRkui0nf44cn61N4ZYUvDGmvSxT2Oy8fD/0p2WKmaapDwBhvO5qJbbeq50OU50Iberfw20qs24 IL5HpRsdi2db+/m98XGUttHQcyIVurhZPkn5BcL3X7ChnTMKOclxUZwkZ/BHgAEAnWFP6w0KZW5k c3RyZWFtDWVuZG9iag0zMiAwIG9iajw8L0xlbmd0aCA1ODYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJXFPLcpswFN3zFXcpZoKMeBjostNOm6w6KZ0ski4ULBs1WKKSHMZ/3yvJr2YjBNKc 56V/SLKioE1TQ8Yoq6H/kuTQD35ZkmfyJGCfNrQlPMXzgrwJMGIrjFCDAKfBjQLufzzCrCc5HEFv 45f+V9bDC0l/9w+IlAMDO6ikyGlb1PjqSWieM0/0TEbn5nRNPq1W0h0o7mTkUm4VgFbSH5tVQPva J2W+pmtgdUdbfDBGmwJyWndd16K4ZJt87hOGnzxvARVraVkAW+O9Ni+h3wdFeVBEXlIKaf8nycqc sjKEsK7P+qLALGwbnwd5GoWCjXgXk56l2gEHJRYY9EYMd/DzG1sD3xkhLKbAHQiPjKbL/MZ03l5A WRtDnuQ+bSn6Vtx51NJsspkbd8Ro04Y8grTAp3hHpxgisQ7kftbWytdJoAOfTHZiuvbo2aqrhSqy fdcLGjChqEBckJkPLnaHTLfsnjqAs4bW7dnFZT4IWLlTcisHrtx0hElY63G8b0y9/Oj6vPMyOMxG o/poCxbpxhjk2U1NO/bRTXF1U0SYUxmIQoRyFpYRh9N7wxXNKA2HOdsarRzsNJ/8zEZDHa3K21q6 C3TBTgqHUSI6lmx0imrIkU/uGHaIKPyfYA+TA2zaZylUONpQuFcwcItTEJ2cqP53UsfZj3KNDtAR 1ZetrqqN+Iu4NTlg8TWRJgRWerOeVQUKbJ7dWLnpvItWLoHcgfQyKwL6YOBdiuUusCk+DGJ2PK0Q +xWrHOVuBCPtW7x9/vfgnwADAFtVHk8NCmVuZHN0cmVhbQ1lbmRvYmoNMzMgMCBvYmo8PC9MZW5n dGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0cmVh bQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10 Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsA jdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0A QBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX 1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuU DQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHB wUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2+ +M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1M rsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au 8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqAC JuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyD j8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3Q CqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14H D8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuU iHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCG cI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZ NE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g 5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2Ew GG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXG krBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3 mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovL Fs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvb etpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSd xmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r +sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5q r61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzq EB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHsh N8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy /cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/ TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21M u73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/m MfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdW Lf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPq QXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOp Zkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xx bGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXv urEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt 2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuv nByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+Co UqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUT tYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C 28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC6 0TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynf r+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO60 70DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+ 3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iajw8L1N1YnR5cGUvSW1hZ2Uv TGVuZ3RoIDYwL0ZpbHRlci9DQ0lUVEZheERlY29kZS9JbWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29t cG9uZW50IDEvV2lkdGggMTEzL0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDExMz4+L0hlaWdo dCA0Mi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0Ky4Hhqf317Wr2vatavatWFa1DVq1DDsOG4YOw4Mgy eDhhNwYI1g8GQaQgcGEDDnYkHh9zsoFh44AIAIAKDQplbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2Jq PDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjAyMC9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNv bXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL01hc2sgMzQgMCBSL1dpZHRoIDExMy9IZWlnaHQg NDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ7JfPb1RVFMf9A5SwNJG1MZK4cYEuTEkgkqAxwR8h EkkIyA9ZEDfVjelsaEhdYJDwQxJJoJRJI6RAiSRKEdJqbSsWKUJbwdHSWhloykwTJRqCn+nXHm/e e/PmvembDjVzc/Lyft53z+d+7znnplK1VpHWeyXz3GsHUye/397ev+uLH9/eefap5XvrW77d23GN Sx2fX3t4674Lh7uGPvlqEPv0wpBr3A+0dPdwoB3rHeYpP3rm5QP0jDXsPkc/Jy/+lO65EdiV/ehY 59XjW3beeOyFXx95NtB4dHPh0vG6TdnNjRO70r0/387czptdHc12X791/mqGMeAILuO433S/bmOa EYICPp19I1hEnjWk0ZFGoVpDmjjS3NQ9rLXjMt+qH44YbuoOPHUJUsbApTjLRDiQczjt/7D33MB4 k5EvX3+U2eTIvz78/LKeah7V24G2vv3b0x1LNhbjWQwyn+zY0xVIz4w/Ypy8Ut/2xJKPVmz7TDTg 0HKq/8FMi7L2//jzHsZEIBujylH64S9c8tRF6lI1tkYY34sRLmaG9+O2i281nuF3OIJI+Cl/L3Te 3IM4Bx9fEQumB+y5F9/d0fyNX5Dy942G0xhzyq81p9xnMMvWHPprutWQJo6UFoUnTfB5n2/pwcIL JwojMv4CSa0OmV0a50DaHvIe8z8q9DANkHhYNsBwY2rof219G5qBoebOQxi/oMELcSXqUm3vGKR/ U6kr1wWLm4RUf3TBeiCXZwWqzT3ESYTU9/TqkOyToPGXDYu2kBklSH90Ra5nu4exWBJ1kdLe3Hac sKwo7VKlc2jbcggHWwZbkCIbMvUckPTIlXl0/TWv4YCMFRWxWDxdqkOZrNC5s8Y5S4P7GPHW5tTY Cm9JyIFHdwrwbjbRMq5EFVr9+uSOCryRsRxWNlIaPGtI/Uix8niaUJmRVVtb3eXPCZcYXkMbsERX N+T6i2SXtscMo/+RfRhezM8W456uYhW+6QcC5WUlf5PImRe4ke9ElSPVLz+yMkAbASnWH4hCzM+w mOE4eSrBmMk0sQpCfipf8BrXbk/excrISiFaZedlEcDKCVeHlHDaYtguIzrYiPA5zlKuTAqyhGTJ 3+EjzmoNKsuL6ux5ppzsT1WjHa5+p3NDx00uuSlzY2yyFncHqu2nNBlxrrX05AjRNdbeMxZVIsD7 TV+aOLWn8KQtnRAWmFzkKv4Vkmv0zKW6KNb8Mn6cxR44LUGkqZmgmpu6984Hp4mijBC2LPZiKQna 2onwTkRtxAWLfljFEakyBdHni70hbtqusxI81eCJ3cnlV65LiyfHYiJUumH5Q5UREntT08EhWbB0 uG71/ojRleXPLJTkiVPwlISMaiV4qsETAyy7Km2gWNolBwl8gYVwycwei6d6ptuIcUCbo5BiD6dY 7BKPUa0cTzWtgsn8FFO5YHETTlGdlvQd8gqwaECKnQ1bfasaQ/G8EAf2dEWpB3jBHwSUjxie6VNU Kw3Tg1TZSpVVyRWt0othw0GZlBMlr7hgBVATJNm7TwFLgIVbOFuqKavwrYBp2H1OPGez5Sybqv23 5cQAUkF4EVVnoYA4ABMyncks+ud8pZgTOJVSrNiWrPZT0/UJPCkRFTbnnqc1CzW9VzLwwU35GCUH 6R1gCg4e4ReXqZk9SyBht/R1S+IQ/ibaYmCPPPoSCU7F/Bwko5JNAwDpUCZLFFICip6DLBogctgC ih5gi9GJGKofqx+0QUtFrsr0msqtmwuXFpNrtmHf37/8ZlZFpKIKT6wQBE71w8QUGz0BSZliS/7C VE5wAl7uY5DkDi+QDV0Ze37hToGmzBYOoZI6ClkGgh198tX815eM6v27U9UF+29cPdUvvKQtreVU nFpUBOySOKDSl7oCcXJksrijhSDOnkkxvHqK0QmzwHRoppgUutqwaMt43aZA0Y6+/h5g4SmrOlXx xJBuZ98ItSsuCGzckkl4FWyZHbBgdAUWLQRMQVUmYpK3md7hJkj1LZdr69t6ro8xwsmT57ObG/1g kasnDlQ3FIinNnHUdcT8VVtbpS6FgnDR2oLlZWUuaFjWMx26IsQQLf1jYNcde0FqF0+muL1jkKlX HahxokkAgtGTwgiwE7vS2EMCVmMWUh3RxrI1h/BLecdTNdmlZCmY4QHZEzP9kRPjX5IuqZNVY3si P1JwIVpWvX8LBm0eGVV9Wy2qcsHA/nBtnNoPsErriocW+qxSRZaYFasl44ORVD90y+da+CvXpSmi RsZy7oYI8yAVK87vT+Y58YuW4EDsBaxWXxWpqpkjQqqiC0/xd/n6o4pvpB6LuiR05XRL635z1agE hKTpig6FUSH994lJzJCKauAghdeQmmgxYLrJi/u8JqtuBSukVsfi9Z1cfmDw1pEzlygPiHJiy1EL H7xKSahO4VExkzvomae8Y9mHz5msg8e/AyMAMRcpFmVDZEhl7mInopLIPGBtX1D1wkBI4WlItQfk SHwg4kEGgzmoiYFkN4QnSYNON3nacmKA9+Fm4VEOCqmoimcZg/Ske/UstlZ9ecotpiNpVLGbkGq0 CSIV1URG6PI0pBytSIAt6i2AnQkFVQ+zaskirdAIhVRm4lRlW6hjNzcWYuzdqYchec27pr1qDWmy zYPUygPCglsPVHuY86wZUisPuNSJzmXVHuZ8bRYKakiTbX6k1R7R/7b9I8AA1TMoFQoNCmVuZHN0 cmVhbQ1lbmRvYmoNMzYgMCBvYmo8PC9MZW5ndGggMTgwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiQClAFr/////d4m7GzePvMfa4Ojq2OPm3Obp3ufq4urs5Ovs4+zv5O707PHy6meF4QAz 7ZGn+vr69vf42d/qOFOeXXWvs73YWW6taXy08/T16+/wpbLPxtng0N7kzd3i1uTqwNbfKESWh6PG uszaQ1qhqb3SvNPdttDcsc3bncHZDiuJ6O3v9PX2pLfQpAxL8p+yw8viz9rjyNrhy9zjz+DqLkya mq/L09jpAgwAgaF6wQoNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAxNDAvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE2IDAgUi9XaWR0aCA4Ny9IZWlnaHQgMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIm0zFkW giAAQFFIILAJQiM0B6LQbC5r/0sL7ZxqA72f93cBHAQIEzJElDIWhqPxZNo3413A110IAeZQRvFC LTWjCCHiw5gkMl1leaFKs7abYusqV9dlDMB/2GAHKf6wTaP3h+PbPf2yvEfPnGOptP6y+GKTPLve 7qaN7CP1bOWcaZ8vAQYAvtIR0QoNCmVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmo8PC9TdWJ0eXBl L0ltYWdlL0xlbmd0aCAyMTEvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE1IDAgUi9XaWR0aCA4OS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K SIm6ef+Vhss0IDp15f6dZy9vPH4GREAGEN17/urBCxB69OrNk9cg9Oz1WyB6/f7D+0+fz996LG3e f5fX9iGDMTICirzfeOD///+/YOA/GPxCAkAu0IT2qUcsgufFlq4HWv3t+w+g+JuPn4CGf/n6DSji HLUwMm8t0A1AEYgzgAjiMIgjgejqw6dA9PjN+8yaLUBzgOyzdx+duPUQgoDczceuuyQt49PunLT+ 7Mk7T/dcvrvtwp2NZ28D0ZpTt4Box6XHQL1AZ3z8/AMgwADhZs9OCg0KZW5kc3RyZWFtDWVuZG9i ag0zOSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIxMy9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDkwL0hlaWdodCAxL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIifr161dmzRZp834g+ejVm6sPn954/AyI7jx7CUT3nr968AKE gFJPXoPQi7fvIejNx0/PXr8NzFq5z63gsYDDQwZjZHRDwv3T0Qv/////hQr+w8DmvTcsgucBtR8+ /QjI/fb9x8fPn4FmAtHr9x+A6P2nz0DbY0vXA5XtOX4LKA60HSgCcRjEkUAEdDAQAcWXbL/gHLXw xK2HZ+8+ApJAdOzmAyACcjcfuw70oIbLNKAaoMi2C3eAaOPZ22tO3QKi5SfvAknL2EV1k/cBBBgA YI3RJQoNCmVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAy MjAvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAg Ui9XaWR0aCA5MS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlasv2Cc9RCi+B5Szed v/Ps5dWHT288fgZEQDYQ3Xv+6sELELr/+tObj5+evPsCJOHo169f7YuPhdZteRJS9pDBGA09FnD4 dPTC////f8EAkP342dvY0vVABLRxyfYLEPHPX75+/Pz5/afPQDNfv/8AQS/evgeKABl1k/fp+cwq 79wNdBtQAdAxQIdBHAlEQEEIunDvCdAjQDOBjBO3HgLRsZsPgOjs3Uez1p8GSmXWbNFwmTZp/Vmg 4LYLdzaevb3m1C0gWn7yLpAEikub91+8/hwgwABDI9BkCg0KZW5kc3RyZWFtDWVuZG9iag00MSAw IG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIyOC9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1Bl ckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDkzL0hlaWdodCAxL1R5cGUvWE9i amVjdD4+c3RyZWFtDQpIiXr/6bNF8Lz2qUdckpadunL/6sOnQHTj8TMguvPsJRDde/7qwYtXj9+8 f3793qf5mz4dvQBBQO77x8+BaPfRqwnhM06s2ftELeghgzEauiHhDlT869ev/2CwdMNloHXlnbuB 6Nnrt0CRb99/fP7yFYjef/oMRG8+fnr9/gMQvXj7HoKAyj5+/rzn+K3ArJUQpwLdBhSHOA/IhrgZ iIDc2NL1mTVbrj15deLWQwg6e/fRgWv3IZaef/CqbvI+PZ9ZQBIouPHs7TWnbgHR8uNgdPJuSt8e r4TlQCcBBBgAmuvSuAoNCmVuZHN0cmVhbQ1lbmRvYmoNNDIgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAyMzMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE1IDAgUi9XaWR0aCA5NC9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6//9/ 3eR9saXrZ60/HZi18urDpxB04/EzILrz7CUE3Xv+6tGrN0CRJ2pBd3ltb0i4AxGQDUcQwccCDg8Z jDERUPzT0QtP3n0BWmQRPG/30av/weDXr19fvn4Doo+fPwPR+08g9Objp9fvPwDRi7fvgejZ67dP Xr8B2g4UBzKWbjrvlbAcaAjQ2bvO3AIioKuAsg9evLr25BXQqdMWn3RJWgZkn7v3DOiR8w9erdx7 yTlqIdB3B67dP3bzwYlbD9sXH5M27weasOfy3TWnbgHR8uMgtOjITSACGr50w2WAAAMACevIHgoN CmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyMTkvRmls dGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0 aCA5NS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIl69PSjns+sPZfvti8+llmz5cK9 J1cfPgWiG4+fQdCdZy+B6MGLV0D05N2XtxOXP2QwJgPdkHBPCJ9R3rn79fsP//////b9BxB9+foN iD5/+frx82cgev/p85uPn4AKIOjF2/dA9OT1Gwh69AqEgOL3nr9auul8ZN5ai+B5QBSYtbJu8r55 a89sPnb91JX7u87cAvpo5d5LQMas9adjS9druEwDeu3AtfvHbj4AkkDPAhlA/wLFs6Yf3HbhDhAt P35r0ZGbQLT85F2goHPUQqDVAAEGALGuxBkKDQplbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqPDwv U3VidHlwZS9JbWFnZS9MZW5ndGggMTkxL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9u ZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggOTYvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCkiJ+v//f2bNFiB6/OZ9eeduIOPqw6dwdOPxMyC68+wlED148QqIHr16A2Q/UQt6yGBM Hvo0f9P///+/ff/x+ctXCPr4+TMQvf8ERW8+fnr9/gMQvXj7HoKevH4DRECrIW649/wVyA2v3wCl dp25BUTTFp+MLV3vHLXQK2G5RfA8IJI279fzmQUUASKgp5Zsv3D6zuMj1+4fuHZ/z+W7cNS++JiG yzQgCUQbz95edOQmHLkkLQMaCxBgADbWxdgKDQplbmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqPDwv U3VidHlwZS9JbWFnZS9MZW5ndGggMjAxL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9u ZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggOTcvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCkiJevT0o57PrM3Hrj9+8z6zZkt55+4bj59dffgUgoBsILrz7CUQ3Xv+6sELEHry7sun +ZseMhiTjV7VTf/2/QcEffz8+f0nKHrz8RMQvX7/AYhevH0PQc9ev33y+s2jVyAEcQDQJRAnAd0G ZAMRUArIPX/r8Z7Ld3cfvbrrzC2gXyLz1gK5B67dP3fv2dm7j45cu38AjICCQLTtwh0gAjLqJu+T Nu8HovbFx9acurXoyM25B28CydKlJyyC5z16+hEgwABWa9GFCg0KZW5kc3RyZWFtDWVuZG9iag00 NiAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMxMS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0 c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDk5L0hlaWdodCAyL1R5cGUv WE9iamVjdD4+c3RyZWFtDQpIifr//3955+7Y0vXXnry68+xlZs0WIBfIvnDvydWHTyHoxuNnQASU BaJ7z189ePHq/utPQPZz+zQgeshgTB56ld76/tNnIPr2/QeE8ebjJyB6/f4DBL14+x6Inr1+++T1 m0evQAhoNQRBHANxGARB3AkkIS4Hyk5bfNIladmJWw9P33l87OYDIDpy7f4BMNpz+S4QbbtwB45S +vYAkZ7PrK5tl5YfvzX34E0gmrn/hn3q8qUbLv/////R048WwfM2HbgKNA0YPnWT9wEDDW4droAC oifvvrzfeACI7vLakh1WT0LKgOj59Xu/fv3CE0poAQV0A3JAwd0JcTYQnb37CMhec/ga0Gubj13H E1Abz94GojWnbkEYfqXrgVqA4bPoyE1IWGVNP+gctRDoPIAAAwCDaa3XCg0KZW5kc3RyZWFtDWVu ZG9iag00NyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMxNC9GaWx0ZXIvRmxhdGVEZWNv ZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEwMC9IZWlnaHQg Mi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6////0g2XI/PWnr376MSth9eevGqfeiS2dP2Fe08g 6OrDpxB04/GzO89eQtC9568evHgFJJ+8+wJEr9JbHzIYU4KeqAV9Onrh2/cfr99/gKAXb99D0LPX b5+8fgNEj169AVoKQUCrIS4BugqI4I4EIoizgd45/+DVrjO3LILnrdx76fSdx8duPjhy7f4BMNpz +S4EbbtwZ+PZ22tO3YKjRUduArW4560GMuYevDlz/42Ju64CRTbvvfHm4yevhOWT1p8Fmg8MK6Bd 0xafDMxaiTWskIML4ubHb94D0fPr94CepTC47vLavp24HOiej59/AMMfElDwUCI1oIAIGD5AEaBf 2hcfA3KRwwoSXMCAQg6r5cfB6ORdYOBouExL6dsDDK5pe68DgyumdXtmzRaAAAMAaAyrjQoNCmVu ZHN0cmVhbQ1lbmRvYmoNNDggMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyODgvRmlsdGVy L0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0aCAx MDEvSGVpZ2h0IDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJrJE/S8NAGIf9NOLk4uKuozioi34D F7fWRXR2LEKHgkpdsiilrTioFYVS/5RKIbRJahKb5pqaNFUsfgAfvHJIQRAUnuHuHe79/Z7TzXB2 +aDcfL5reVBzOsWKweRSd+qukDS8Lph+ILGDENxe1H4ZIV4/BinNm5j5O2Il2TPc+H0Y9Acg+jF0 oljtYq8MIMPIbBIVmBZQtf2miNa3ToErHeH6C9rBWd3O157g+KGl3Y44KlvavbO9dzU1n97JP+7f WKnzBgec6GbIfHP3gl0Vqw3S2NxaNpOrqgAqz0/GqOPHbzT9H2OTS8PDAl8AvDzm6pe6cEUXhhRc 3ThhQrvvunA1pgtRCowtJnIoSpcMdMH0QqZYMj8FGACi06gjCg0KZW5kc3RyZWFtDWVuZG9iag00 OSAwIG9iajw8L0xlbmd0aCAyMTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJAMwAM//6 +vpKYKear8vL3OPG2eDI2uHP4Opdda9pfLTW5OrQ3uTV4eXY4+bc5une5+rg6Orf6/LyxdDYGEfh ADPkVHbn197i6uzN3eKHo8ZEYqbE1t/A1t+809220Nyxzdusytqnx9qixNmdwdmRutUuTJpVfrTx 8/jDy+JDWqHs8fLr7/Dv8vPP2uO8x9r29/jx8/Pz9PXo7e/yn7Ltkaf09fapvdI4U57k7vTj7O+l ss85XaIbN4+kt9D////m6+26zNqzxtc/ZacOK4nR1+cCDAAHp5kgCg0KZW5kc3RyZWFtDWVuZG9i ag01MCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDE4OS9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTcgMCBSL1dpZHRoIDEwNC9IZWlnaHQgMy9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KSImEz0kSgjAQBVCUIBIyiLOAIIJBQIkDCirO97+TsVyxoHzL 7v+rqyWp0ZQBUFpqW4MQ6rqOEMaYENoxur0a/cGQUkpEDiHRED04khUFjieyaVm2PXUc1515njef +8HC9wOVheHSwlGcsNU65ZzxDWcUbVkqSMauxt6Q0piQKBM2osESzqKopRyOo++dKc6Louj8mCfN O1/islRBfq246fz6X4ZxWp1o4H58gO87rLpwn6/3R4ABAGB1LUMKDQplbmRzdHJlYW0NZW5kb2Jq DTUxIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjY0L0ZpbHRlci9GbGF0ZURlY29kZS9C aXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggMTA1L0hlaWdodCAyL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIifr//39s6Xogal987MC1+y/evv////+0xScDs1ZG5q0FimMl D59+BFT26NWbqw+fvv/0GaKFoC6CJC4pIAIaDrTl85evd569BKJv338AuXWT90Fk0RTDGaeu3Acq u/bk1ZFr94/dfGARPG/RkZtABtCney7fBaKNZ28Djfr16xeaUWhmAv118/4roFHLT951z1stbd4P VP/o6UevhOVAtGT7BaD5T959ASoAKubT7sSD5q09Awm6C/eeQIIOYh1+XZQgoOPhQXfj8bMvX78B ucCgwK9r894byEHnHLVw0vqzJ249hATdtgt34EGn5zMLv1GQ1AJMYJaxi4AIGKQAAQYA1mxX+goN CmVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBvYmo8PC9MZW5ndGggMTc0L0ZpbHRlci9GbGF0ZURlY29k ZT4+c3RyZWFtDQpIiQCfAGD/09jpUWqpsc3bvNPd5O70////aXy0DiuJnq3M4urs0N7k7/Lz8fPz 2OPm9PX2Q1qhpbDTwNbfxNbfSmCnlqPJyNrhttDc9vf4+vr6vMfaGzePXIW3OFOew8viRGKm6O3v WW6t1eHls73YxtngrMraXXWvf7HOOV2ih5XE4+zv4Ojqzd3id4m7R26rapfBy9zj7PHyLkyah6PG p8ndp8faAgwAW+FxzgoNCmVuZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAyMjUvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE4IDAgUi9XaWR0aCAxMDYvSGVpZ2h0IDUvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJfI9t V8IgAIUDuoitaajh2pssQlGn1er//7bY6jQwTxf4cu/hPOe5IYSyW/DJbwSmdwl40FwLwX2azjAf mwekcrFcPTKm6DoLhieQvCizqq4Z20CHP3qSDppr0Z7UzFCOzTOahalXhin1ss6CoYLNt7vKcW7Y PnY6HBNY+z9p/k2KnJre6YcUObX59iTa89mofex0eH2DEFpz6w/n7+NWlnyoLBdImj9OUi47oxT9 uHAik6JoSddJdenkSUA2XP/cuDmHoeqHgRQ7MU+SitLPyKlCe9oV7kuAAQCpZxuiCg0KZW5kc3Ry ZWFtDWVuZG9iag01NCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMyMi9GaWx0ZXIvRmxh dGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEwNy9I ZWlnaHQgMi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSImMkbFLAmEYh/+D/pGguaaGNmmJaCgIXBpq aIuWsFFcixoahDQ5gqQkqSGLIMnKLg+kyOtMu7Ow8+LSU5Nbrgc+cDyF3/Dy3e97jvf5AkFp61gm mWI5Jb8Zlu153vxqcmQ04pPESZGa9vUtl/Vaw7rJ65yQhv1rNVvEbjliIN2/HuX1yIU/M7yTJTSd dofrpYq5G7+PJh/rP7bruoKpm5byXiPtTpfm+GzUn3l6+UqtUDXZ7vqlEghK4fgtw5misezRgyrl 1KbTgz8QxY6gYtnSWuJubHpvLpTGkrh4cK4QwRQClzfS/jT2EgLzmkGA4IcIpSz4/PEpwowByqHt qyEFVusmFwuqwV+mFvaBc84JcAEkSKbJ12EeWggkfYFs2hfI++JhICqTU4XAzdTTxGJsckmaWTlE /r8AAwDNP3afCg0KZW5kc3RyZWFtDWVuZG9iag01NSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVu Z3RoIDQvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEvSGVpZ2h0 IDEvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCtnf6goNCmVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmo8 PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxODcvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21w b25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0aCAxMDcvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0 Pj5zdHJlYW0NCkiJsgiet+jITSDaePY2ED1+8/7///+ReWv5tDvxoKUbLgOV3Xn28urDp+1TjzhH Lbxw7wkQAbkQBpwLRC/egsws79yN30ygOUAEVPngxSuIxkev3gANmbb4JNB8i+B5QNkj1+5DLP38 5StQJVAQv5mb994AKjv/4NW2C3f2XL7rlbC8ffExIAPo0zWnbi0/eRfo8W/ff/z69YugUYdPPwIa BVRfv/FcaN0WPZ9ZQNMePf0IEGAAyUe37AoNCmVuZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmo8PC9T dWJ0eXBlL0ltYWdlL0xlbmd0aCA0L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAg Ui9XaWR0aCAxL0hlaWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQqzvdgKDQplbmRzdHJlYW0N ZW5kb2JqDTU4IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTkxL0ZpbHRlci9GbGF0ZURl Y29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggMTA3L0hlaWdo dCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIibIInrfoyE0g2nj29ppTtx68ePX////Mmi182p14 0Ly1Z4DK7j1/deTafYvgedMWn7z68CkQnb376MK9J2jo9fsPQMV1k/fhN7N96hEgAqq8//oTxDQI uvbkFZAEWuGStAxoF9Btaw5f+/L1G1Clc9RC/GYu3XAZqOzcvWfbLtzZc/ku0IT2xceADKBPgWj5 8VtAj3/8/OPXr18Ejdpz/BbQKKD6+o3nsqYflDbvD8xaefP+K4AAAwCNVLdDCg0KZW5kc3RyZWFt DWVuZG9iag01OSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDQvQml0c1BlckNvbXBvbmVu dCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCtPY6QoNCmVuZHN0cmVhbQ1lbmRvYmoNNjAgMCBvYmo8PC9MZW5ndGggMjg1L0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIiQAOAfH+OFOeosTZrMra4Ojq////WW6tDiuJpbDT7PHyfpO+ Q1qhxtngzd3i0N7k6O3vd4m7h5XE77HA1uTqz+Dq3ObppbLPw8vis73Yzt7mttDcmq/Lsc3bp8fa ncHZ9vf4+vr6f7HOGzeP2d/q3ufqaXy0nq3MyNrhh6PG1eHly9zj5z9m6meFyt7ruszaLkyapLfQ 9PX2vMfadaXIirbSKESWkq/NxNbf5uvt4QAz5FR2ytTf8fP4wNbfp8ndhLPPOV2iSmCn4+zvu8XV qb3S4uXxR26rXIW3RGKmvNPd4urs5CZSyKy97/LzP2WnssDV4xBAz5mvydzlXXWvTnWvkbrVmb/Y VX60x9zpZI68apfBAgwATiW+XgoNCmVuZHN0cmVhbQ1lbmRvYmoNNjEgMCBvYmo8PC9TdWJ0eXBl L0ltYWdlL0xlbmd0aCAzOTkvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE5IDAgUi9XaWR0aCAxMDcvSGVpZ2h0IDgvVHlwZS9YT2JqZWN0Pj5zdHJlYW0N CkiJbNFrU4JAFIDhXVosdiFMyzRAAQ1ETcvQMFHJexcry0v9/z/SqjMpq+cjh5l3nzkAQo47Qnzk f47RiYCJuBpJksRTJG930Sg6i8XpZ+lcuuBBAoHt7hIlUylwpXCqqqUzO4sE0nTdwCbQNE7Notx2 c40sYOcty1nHaEoIpQrFEm2JYjIm3WQR3n1iUlHKFUWlqdvMzuIOweq9WzbdWo1TGVUO1x2LjuM4 ovPAqApe4zEu0hX9pRlWxf0K4BSFa0FGBfV2B5iGICiQUQXAFwmx1jXriVV5XqEbXz+FNMOqni2X azW7KvB9xKjaA2BGhsNVKqSSR3jsOGRTe95Ted7La4mGCHkLq+SO62KMQWfQ31MNQN+dTFSNUb37 GPsrGG2RAyrP+/gsTdepkGqqfH1rs8octtLsrdqLoIkNY8aqYqQ+wni8ahFySEWnSKakztxqmQp+ 6KGgNmvuqRZ8hnJ+YSysyo+Jz/O4l9+kDqjoNLpL/xQFu0+0ILBVqM3nNBVW6fogiv4EGABC2EQV Cg0KZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iajw8L0xlbmd0aCAyNTUvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJAPAAD/93ibsbN49HbqudwdnW5Or///9Zbq0OK4mlsNPP4Oq8093A1t/G 2eDJ3OVdda8uTJqlss/Q3uTE1t/i6uyHlcT6+vrqfpfhADPkJlLIrL3H3Onk7vRpfLSSr82KttKn x9qZv9iRutWnyd3Z3+p/sc6Es89Oda84U56ercwoRJaHo8bL3OPg6Op+k77Y4+bGgJ3dDT3f6/Li 5fGywNU/ZaeWvdfx8/jo7e/29/g5XaLO3ua20NyWo8ne5+rV4eXqZ4XDy+Ls8fK8x9pDWqHT2OlK YKdql8G40uOxzdupvdJEYqazxtfYGEf74OZ1pcj09fYCDAD2qqhpCg0KZW5kc3RyZWFtDWVuZG9i ag02MyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDI0MC9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMjAgMCBSL1dpZHRoIDEwNi9IZWlnaHQgNC9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckGtXgkAURQfwiDCD1ASVUiYyhtgDMS01TdPM3v3/f9OT Zuh8vHvdu9e5RNN0o4Sy+ZcKLJsyx6m6W9uc8R0QyTzP3937zX6tHuBAMoLg0G0cGUYzbCHSJIj8 ULSPSSWOXVFSNzqfJtvm3CFJ94TxU5ypJpynuaqXZvAk0/q4GAyN5jBsXaIr58nVqCHaeicajwd6 Vuw0uba/4kwTwtms2Ak3LO3lrjkWkpnVEW4tSukMWCrjMjIhxGpxt17fJ5tip8nDj4o9xk/Pwb9O Fq3XctXLqx8rN1dLfKfvKb8zp9gI8ea+fwgwAFDAH5wKDQplbmRzdHJlYW0NZW5kb2JqDTY0IDAg b2JqPDwvTGVuZ3RoIDE0Ny9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkAhAB7//Hz+FFq qXWlyENaoZajyf///1lurQ4riaWw08vc47HN27bQ3LzT3cbZ4F11ry5MmrO92HeJu4eVxM7e5sDW 38isveQmUuEAM+p+l56tzChEljhTnvr6+oq20n+xzlyFt36Tvk51r6Wyz2l8tMja4azK2oejxsfc 6am90vvg5oSzzzldogIMAFoKVmsKDQplbmRzdHJlYW0NZW5kb2JqDTY1IDAgb2JqPDwvU3VidHlw ZS9JbWFnZS9MZW5ndGggMTI0L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgv Q29sb3JTcGFjZSAyMSAwIFIvV2lkdGggMTA1L0hlaWdodCAzL1R5cGUvWE9iamVjdD4+c3RyZWFt DQpIibzOyxKCMBBEUQJpQDIqiRFFIUZ5Kv//f2BBSaxy7VlOL+54jPkBRxh9xNgkYkKCtmK3TyHX TSkcNOljdpqdwSNXIHmuwot7uhZFacob8/4VgrV3/4FqXXLUTTJ5x7S2Lex3iIi6fillT/fFn1J0 xrwGOQowAJ0WDykKDQplbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9M ZW5ndGggMjQ3L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFj ZSAxNSAwIFIvV2lkdGggMTA0L0hlaWdodCAyL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIidq898bm vTdckpZN3HX11L3X////j8xby6fdiQct3XAZqOzErYfLj99acwqENp69jYy2XbgDQXsu373x+BlQ cXnnbvxmtk89AkRAlafvPIZrh5iw+dj1JyFlDxmM0dCr9Fag+kdPP2q4TMNvONkI4qQ3Hz91bbtU v/Fcy+bzpUtPAMUvXn8OtBeILILnAUWuPXkFVJZZswW/afPWngEqO3bzATzc4AgtAIHozrOXQMV1 k/cRGW4n7zxFDjdILABNXpvRhxl0n+ZvggRdYNZK6oaYtHn/tMUngYb/+vVr7sGbwECDhJt96nJg NAFtBAgwAKWkOYMKDQplbmRzdHJlYW0NZW5kb2JqDTY3IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9M ZW5ndGggMTQzL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFj ZSAxNSAwIFIvV2lkdGggMTAyL0hlaWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiYrMWxvT uv3ak1f///8PzFrJp92JB81bewao7MC1+4uO3Fx+/BYcrTmFBUHMLO/cjd/M9qlHgAio8sSthxvP 3oYjiCFAxrYLd441zL3La/uQwRiOgNxP8zcBdX37/gPoKj2fWUCE3yKCKLNmCxBdvvESYizQj/Ub zwFRy+bzKX17IAqA4gABBgBMA59TCg0KZW5kc3RyZWFtDWVuZG9iag02OCAwIG9iajw8L0xlbmd0 aCAyMTAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJAMMAPP+lsNM4U57P4Or///93ibsb N48oRJbA1t+ixNmnx9qnyd2sytrW5OqHlcSWo8nG2eDPma/YGEfhADPqZ4X97/L29/i8x9ppfLQu TJoOK4lDWqHi5fHc5umWvdd/sc6zvdjk7vS40uOdwdmerczLKlftkaf74ObZ3+pZbq1KYKdRaqld da/Dy+Ls8fLf6/KEs88/ZaeHo8bx8/jO3ubT2OnH3Onz9PXx8/Pv8vPe5+r6+vqpvdK+RnDjEEDk VHbyxdBHbqsCDAD6XIhdCg0KZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iajw8L1N1YnR5cGUvSW1h Z2UvTGVuZ3RoIDE5MS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9y U3BhY2UgMjIgMCBSL1dpZHRoIDEwMS9IZWlnaHQgMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlc ztsWgUAYhuHyN5pmkm0qkYqEjE0ie+7/qkyjZdGz5mi+g/eX5BooCNVLEqgYY40jlNOh8Z2QYUCT lkir3Sl0e2CafctGzi80MFwAGI48znbGvh3AHzXEZUajmg6VkfI24RdgMpmKSjuazfgQSw1rvuCW iWKsGP9Zr2mR2Gzrsmsmu9Rn+yxlPmOxy1gQiooo4cMxT0/inVdZnl9UEdeKkVxvotK53x/Rs3LM MAg979OQXwq8BRgAwnkWmQoNCmVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmo8PC9TdWJ0eXBlL0lt YWdlL0xlbmd0aCA0Ny9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1hZ2VNYXNrIHRydWUvQml0c1Bl ckNvbXBvbmVudCAxL1dpZHRoIDkzL0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDkzPj4vSGVp Z2h0IDM5L1R5cGUvWE9iamVjdD4+c3RyZWFtDQrL292779vdu+93tlQDGyMAvshhqXCDthB7BA+n Yg7e7Dp06DrTp0HTp+OACACACg0KZW5kc3RyZWFtDWVuZG9iag03MSAwIG9iajw8L1N1YnR5cGUv SW1hZ2UvTGVuZ3RoIDE4MDMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE1IDAgUi9NYXNrIDcwIDAgUi9XaWR0aCA5My9IZWlnaHQgMzkvVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCkiJ7NfNi1d1FMfx/oCKlkH7CII2LaxFFCQJ1aYHiCJBgh4X0qbahK5E3BQV arRQSk0kxdJIyBRBnfIpp8ynQcdxZpzRURudURND6vXzo19ud2bUdMYZ8PflcLm/7+8+nPP+fs45 3ztzZnOMOP7u6BnY3MrG25EJNDApWJpkyrhwaQwsXBU+bLw9mhAjWHr3tvfNmH/hyhhvpybEwCRY +r/b8M+VMd5OTYiBSRPL0BEUyHS/+H4zlcoIFp2o654nlN/YeDs1IcZlwbw5C5lmVyojWC72Dxy+ 4+FmKlUHJkyFQUYSNctvGWlJTSy1EQ4nP1mKTO/jb1w8NRgbb7/GeQSLYrvv3inI4NPUTEZ6UFKp kU2j/RVZivnpwfPH+0+dOD3Q1XOy88jpYiaZf63Fub/Os9F69U2O1N7u+58frVTqOX6SbdzWeaEy rh8L23+oj41ijDcwLu/uFq6KYGxm/m8qJXCBrF63L0yCZcGK7bPnbnr7w+/Zy9NXsKnvrcwJe+6d ZdWZD+asZUu+3eXGYGHOf9vbW8U7liT+M8oeJoJh1/+5ZKGLw8Ey47P1T09b+uQrXyZSWOYt2sIW r2n96ee2tZt3i3TrH4d2tnU5ZmbVht1LVu10TcjA5XYP8aihWIwzZ8/dEjCX8wiNYMHnmlvfon80 RATCQ89+4YiDMHftO0YwR0/2y5rTg4Mx5zHzMbdXT7pO9Hcc7dvX1YMYPnc/OAcfRmwey7wLk1j/ wK3omCGjtlwmM8LWV+KXskAboXHfpI9FIRbeuoDDJd6qAdV9/ESxzr6G4VCsvbfvQM8xlp/JL4qa vaiFhBgJmTTjFbGxzqykTBHMsP069RAQC8fDBybPs6A8p43oYVgaQ+EUPjUysPhJM5EZPqTiXcLf ffgI+3F7W0lS854z1jUn4Xt+EYyvyNKvxSt2FiCpoo+8sED6hNXgmbMMmRxjZbJYljjZV4UTFEwx UWfIo5E1i1pAIEU0XMCAgg6fL1ZuSwniQFHvGO24gh2Eg3c9VopMkksUHMABDcmienCJ/5Ldz3Qc IUglIi9W+gvzrye4ReDqrQJCD5IuuEQKAuBeUbCnf9EkSxJ5jle3tnd3/3nGE5Rxk1kdjxq7vWge q0eXVFJk2JTp3/AQAQuqd1hBrppJy3AiBIGX2DnMCq5CrHSZdGfzuTKdy42CLRIiDJkFQlgFl/PJ r33tsS37O1yw42An5bjdA6s7pbHAogHJoEKGrXjro+Ub9wiNA5jwQfgWDijbM24kAXOUU9V+WtLT kTBE6i5s05E9UIFiUQLZYEKcSRmGTwJn/t205xAmzvFxAsue7j6I3G4G55JTowsnqq4KJjbtpc+5 kUB4nvCTBaUvxGrFpFpV8jMNKz0rxVNz8eTUUqIis1/aDoPjRciQUJJI1MEVkUQ5y9b9jgxRWbjQ g310ZZNHpdAtvvOZKpZsZmRTymzKpvpQQ5EyW7VavWXuci84IhKF2ntp/z8oQxvteO6mVAx85BcI rk+umRQySiAUkUhnDm870LWzo8/RuT2DzUP5lLhJJukFnCFp71r/1Ls1wayb9LoF5U96cY1J4VB2 XGwkOO7FP9XYZOna2f5JNFmWvGjIaVGLKs1SjoCCJWSIB9tHp36l7GzYc4iKwFGjkmI+tWI3XIfz DZJM9wopzMnSrIthJZxsVqtMQqAKpGaFTMHCVUtAe9FJbTPjxKRiIqGSXDHxAoIGAmqRVAItS+mv fGpFbGaceMgNdyjKZLRHJOCXrbjdnWZd+jVz7qMyZSFMqgopuq3aSGSiFqsfLKy2x3M06QkmwWEJ No0slKp9MP6j9OnKHY6IpVeW5L0BJtkb2LCl0PEKFmuq9tbKb4PM5lbe+veaTGpwqmRgyceU+drX QXa5sKxu2RsxRAMKbMgofY2vgF0HyYlsfm3vkTt+ggB1mTTjMpMlm66Tie9ThrOnBUX24Vky1ru3 ndX6tfJrUlxDmVwYMoaSYbA4WoUkRYpwkgsW2ZGWl7xQJWiYKS8uTuzJlEbZ6Wi0IZ0LBxgjmC0H jig1sDh5ddaaqmYwvzqT1BNMKNDF+SopWLJwKSO+j2pFRtkRSIK9CpManKpmeGgmO2GJ72lp0yQh CnmhcoqXS/7KGim2XMrOUL0lNs7jkw0PMhBhAhcgweLIkk3VT7ORmOTfOJBczhdHFQvxpBEPW34l VzVNrsJkJCzm5W+6Bs/zcaERe3tkk71uti7F7GZdSRj+0hrckh6tX8sdM4LyM0nEfmg9wPIxkpyN DWUSV6NDL8p+cigWltYpK9WTWio1yMyYHyAj7WyHTSVYMmmJs0dSLiw96abyBEg8iWOFiVv8jMac +Ek22dqhYUfnJ8E4j04KluVb21KlLcFIm70mlmGxhMxtjuWa/eh2Hv8KMAB4VHtfCg0KZW5kc3Ry ZWFtDWVuZG9iag03MiAwIG9iajw8L1N0ZW1WIDEzNi9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFMt Qm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNjZW50 IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50IDg5MS9Gb250RmFtaWx5 KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVz Y3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUg ODQyXS9QYXJlbnQgNiAwIFIvQ29udGVudHMgMyAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5 NSA4NDJdL1Jlc291cmNlcyAyIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9iajw8L0NvbG9y U3BhY2U8PC9DczYgMTUgMCBSPj4vRm9udDw8L1RUNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MxIDI0IDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggNjU2 L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWRUXW/bIBR996+4jyANavztx63NpkzdOrX0 aZkm1yYxk4Mj4zTqH9nv3QWiONsSyebC5dxzDhfffHoSsLPRBxndSJmBALmNaojxX0NS1byuoKwF r7I4BbmPbm5tAa31CTHY1kQxj+M4Adn6UYoAp4gwSIABlb8ilvISGAKIFAHuoviSmbrM7+T24QuI An7D/RMIWvCSJBlGK6A/5OeodARcKT/IcRlSHJ7ZeJzcIwawNc0RQOIzJc/sKthsaMqFK4ZhRhh1 lP5Zo6zgCXnAoCYhTRSbzb3PecJZlymSbOUnuE+4o04febgNbEXiueLLMy3zmCfFQlV4m5gf1oHw 3DczzL2CdtwfBjUr6KhjoWhMXtUw+uCwpzVRZga1pRnG4TlSgc9phpMeBnhRcGqsJzXTjKjOE0pi 7uxzvrtjqi713dDVh1OvDBLQuJXA+tujI0IrXiADTMyIhXmEQe96hK4QGn3LCDRb9ANDNfm3V2Dn xnTN1PnE4Afz9XGLyC8c0oXDuQO0hcPxZdC2Vx335oJEvLV8ZhIO09gqa5WFvnnFIs1W7Y6uylle XOZBYLA1IFrQhh2GplWgt9CAGQ1zqpyvzNELwQtlmVM6IbYN4odGhzUb5KM/uu0XNa7c33qWM3VD 7H304i2ciRlntK5Vxip3FSoeV2ey8dIIYROMBh7ff70DtHRvOYS7E3ZgvWKpJ5Z64a6tDZ6ZaYej 1aN5BydshPE4dDApjWANttR4nKBTVk/Kw4qSV+lVV+QLmfLclSM01mobWnO9ktiGKfmIDVcStNa7 gdzy/ArlP154VrO22zdtdh5Gm+5o5+mNB201enkl7XKJyc/rX8gVBX4/rowgfnoloz8CDABjsysF Cg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvTnVtc1swIDUgMCBSXT4+DWVuZG9iag01IDAg b2JqPDwvUy9EPj4NZW5kb2JqDTYgMCBvYmo8PC9Db3VudCAyL1R5cGUvUGFnZXMvS2lkc1sxMSAw IFIgMSAwIFJdPj4NZW5kb2JqDTcgMCBvYmo8PC9TdWJ0eXBlL1hNTC9MZW5ndGggMzU0MC9UeXBl L01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6 cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1w dGs9IjMuMS03MDEiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8i PgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDcuMC41IChXaW5kb3dz KTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5QU2NyaXB0NS5kbGwg VmVyc2lvbiA1LjIuMjwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+ MjAwOS0xMS0xMFQxMDo0Njo1MyswMTowMDwveGFwOk1vZGlmeURhdGU+CiAgICAgICAgIDx4YXA6 Q3JlYXRlRGF0ZT4yMDA5LTExLTEwVDEwOjQ2OjUzKzAxOjAwPC94YXA6Q3JlYXRlRGF0ZT4KICAg ICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIi CiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+ CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgICAg IDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkg eG1sOmxhbmc9IngtZGVmYXVsdCI+TWljcm9zb2Z0IFdvcmQgLSBscy0xMjQuZG9jPC9yZGY6bGk+ CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRj OmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPmFu Z2VsZXM8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0 b3I+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1aWQ6ODNmMDUyMWItZjBlNS00 YzQxLWJjMzAtM2VlNzEzODY1Y2I0PC94YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06 SW5zdGFuY2VJRD51dWlkOmUwYTkwNmNiLTk1OTMtNDRmNi1hZmI2LTg4YWVmN2FkODA2MjwveGFw TU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94 OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqPDwvQ3Jl YXRpb25EYXRlKEQ6MjAwOTExMTAxMDQ2NTMrMDEnMDAnKS9BdXRob3IoYW5nZWxlcykvQ3JlYXRv cihQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMikvUHJvZHVjZXIoQWNyb2JhdCBEaXN0aWxsZXIg Ny4wLjUgXChXaW5kb3dzXCkpL01vZERhdGUoRDoyMDA5MTExMDEwNDY1MyswMScwMCcpL1RpdGxl KE1pY3Jvc29mdCBXb3JkIC0gbHMtMTI0LmRvYyk+Pg1lbmRvYmoNeHJlZg0KMCA5DQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMjg1MzEgMDAwMDAgbg0KMDAwMDAyODY1NiAwMDAwMCBuDQowMDAw MDI4NzY1IDAwMDAwIG4NCjAwMDAwMjk0ODkgMDAwMDAgbg0KMDAwMDAyOTUyMiAwMDAwMCBuDQow MDAwMDI5NTQ1IDAwMDAwIG4NCjAwMDAwMjk2MDIgMDAwMDAgbg0KMDAwMDAzMzIxOCAwMDAwMCBu DQp0cmFpbGVyDQo8PC9TaXplIDk+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= ------_=_NextPart_001_01CA6201.D031E938 Content-Type: application/msword; name="ls-124.doc" Content-Transfer-Encoding: base64 Content-Description: ls-124.doc Content-Disposition: attachment; filename="ls-124.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVAAAAAAAAAAA EAAAVgAAAAEAAAD+////AAAAAFMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJ2AJBAAA+BK/AAAAAAAAMAAAAAAABgAApRQAAA4AYmpiauvI68gAAAAAAAAAAAAAAAAAAAAA AAAJBBYAOzgAAImiAACJogAA1goAAAAAAADOAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwFAAAAAAAA/AUAAPwF AAAAAAAA/AUAAAAAAAD8BQAAAAAAAPwFAAAAAAAA/AUAABQAAAAAAAAAAAAAABAGAAAAAAAAPBkA AAAAAAA8GQAAAAAAADwZAAA4AAAAdBkAACQAAACYGQAAZAAAABAGAAAAAAAAGyMAAPIAAAAIGgAA OgAAAEIaAAAWAAAAWBoAAAAAAABYGgAAAAAAAFgaAAAAAAAANxsAAKgAAADfGwAAVAAAADMcAAAs AAAAmiIAAAIAAACcIgAAAAAAAJwiAAAAAAAAnCIAAAAAAACcIgAAAAAAAJwiAAAAAAAAnCIAACQA AAANJAAAaAIAAHUmAAD4AAAAwCIAABUAAAAAAAAAAAAAAAAAAAAAAAAA/AUAAAAAAAC4HgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAzGwAABAAAADcbAAAAAAAAuB4AAAAAAAC4HgAAAAAAAMAiAAAAAAAA AAAAAAAAAAD8BQAAAAAAAPwFAAAAAAAAWBoAAAAAAAAAAAAAAAAAAFgaAADbAAAA1SIAABYAAABy IAAAAAAAAHIgAAAAAAAAciAAAAAAAAC4HgAAWAAAAPwFAAAAAAAAWBoAAAAAAAD8BQAAAAAAAFga AAAAAAAAmiIAAAAAAAAAAAAAAAAAAHIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAuB4AAAAAAACaIgAAAAAAAAAAAAAAAAAAciAAAAAAAAAAAAAA AAAAAHIgAAAAAAAA/AUAAAAAAAD8BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAciAAAAAAAABYGgAAAAAAAPwZAAAMAAAAkBAA6d5h ygEAAAAAAAAAADwZAAAAAAAAEB8AAFgAAAByIAAAAAAAAAAAAAAAAAAA1iAAAMQBAADrIgAAMAAA ABsjAAAAAAAAciAAAAAAAABtJwAAAAAAAGgfAACyAAAAbScAAAAAAAByIAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAG0nAAAAAAAAAAAAAAAAAAD8BQAAAAAAAHIgAABkAAAAXxwAAJIAAADxHAAAaAAAAHIg AAAAAAAAWR0AAFQAAACtHQAACwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXxwA AAAAAABfHAAAAAAAAF8cAAAAAAAAwCIAAAAAAADAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGiAAAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8cAAAA AAAAXxwAAAAAAABfHAAAAAAAABsjAAAAAAAAuB4AAAAAAAC4HgAAAAAAALgeAAAAAAAAuB4AAAAA AAAAAAAAAAAAABAGAAAAAAAAEAYAAGQAAAB0BgAA5AkAAFgQAADkCAAAEAYAAAAAAAAQBgAAAAAA AHQGAAAAAAAAWBAAAAAAAAAQBgAAAAAAABAGAAAAAAAAEAYAAAAAAAD8BQAAAAAAAPwFAAAAAAAA /AUAAAAAAAD8BQAAAAAAAPwFAAAAAAAA/AUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHSU5U RVJOQVRJT05BTCBURUxFQ09NTVVOSUNBVElPTiBVTklPTgdDT00gMTYgliBMUyAxMjQgliBFBwcH VEVMRUNPTU1VTklDQVRJT04LU1RBTkRBUkRJWkFUSU9OIFNFQ1RPUg1TVFVEWSBQRVJJT0QgMjAw OS0yMDEyBwcHBwdFbmdsaXNoIG9ubHkNT3JpZ2luYWw6IEVuZ2xpc2gHB1F1ZXN0aW9uKHMpOgcx MC8xNgdHZW5ldmEsIDI2IE9jdG9iZXIgLSA2IE5vdmVtYmVyIDIwMDkHB0xJQUlTT04gU1RBVEVN RU5UBwdTb3VyY2U6B0lUVS1UIFN0dWR5IEdyb3VwIDE2BwdUaXRsZToHUmVwbHkgTFMgdG8gSUVU RiBvbiBzcGVlY2ggYW5kIGF1ZGlvIGNvZGluZyBzdGFuZGFyZGl6YXRpb24HB0xJQUlTT04gU1RB VEVNRU5UBwdGb3IgYWN0aW9uIHRvOgdJRVRGIFJBSSwgSUVTRwcHRm9yIGNvbW1lbnQgdG86By0H B0ZvciBpbmZvcm1hdGlvbiB0bzoHLQcHQXBwcm92YWw6B0FncmVlZCBhdCBJVFUtVCBTRyAxNiBt ZWV0aW5nIChHZW5ldmEsIDI2IE9jdG9iZXIgliA2IE5vdmVtYmVyIDIwMDkpBwdEZWFkbGluZToH TWFyY2ggMjAxMAcHQ29udGFjdDoHSGVydmUgVGFkZGVpC0h1YXdlaSBUZWNobm9sb2dpZXMLQ2hp bmEHVGVsOgkrNDkgMTYyIDI5NDAgMjYwC0VtYWlsOgkTIEhZUEVSTElOSyAibWFpbHRvOmhlcnZl LnRhZGRlaUBodWF3ZWkuY29tIiABFGhlcnZlLnRhZGRlaUBodWF3ZWkuY29tFQcHQ29udGFjdDoH WXVzdWtlIEhpd2FzYWtpC05UVAtKYXBhbgdUZWw6CSs4MSA0MjIgNTkgNDgxNQtGYXg6CSs4MSA0 MjIgNjAgNzgxMQtFbWFpbDoJEyBIWVBFUkxJTksgIm1haWx0bzpoaXdhc2FraS55dXN1a2VAbGFi Lm50dC5jby5qcCIgARRoaXdhc2FraS55dXN1a2VAbGFiLm50dC5jby5qcBUHBwcHU3R1ZHkgR3Jv dXAgMTYgdGhhbmtzIElFVEYgUkFJIEFyZWEgZm9yIHRoZWlyIExpYWlzb24gU3RhdGVtZW50Lg1S ZWZlcnJpbmcgdG8gdGhlIHRocmVlIG1haW4gY3JpdGVyaWEgcmVmZXJyZWQgdG8gaW4geW91ciBs aWFpc29uIHN0YXRlbWVudCwgU3R1ZHkgR3JvdXAgMTYgd2lzaGVzIHRvIGJyaW5nIHRoZSBmb2xs b3dpbmcgdG8gdGhlIGF0dGVudGlvbiBvZiBJRVRGIFJBSS4NU3R1ZHkgR3JvdXAgMTYgaGFzIGEg bWF0dXJlIGFuZCBwcm92ZW4gZGV2ZWxvcG1lbnQgcHJvY2VzcyBmb3Igc2VsZWN0aW5nIGFuZCBz dGFuZGFyZGl6aW5nIHNwZWVjaCBhbmQgYXVkaW8gY29kZWNzIGFjY29yZGluZyB0byBhIGRldGFp bGVkIHNldCBvZiB0ZWNobmljYWwgcmVxdWlyZW1lbnRzLiBXZSBiZWxpZXZlIHRoYXQgdGhpcyBk ZXZlbG9wbWVudCBwcm9jZXNzLCByZWZpbmVkIG92ZXIgbWFueSBzaW1pbGFyIGV4ZXJjaXNlcywg aGFzIGRlbW9uc3RyYXRlZCB0aGF0IGl0IGNhbiBzdWNjZXNzZnVsbHkgc2VsZWN0IGNvZGVjcyB0 aGF0IG1lZXQsIG9yIGluZGVlZCBleGNlZWQsIHRoZSBvcmlnaW5hbCB0ZWNobmljYWwgcmVxdWly ZW1lbnRzLiBSZXBsaWNhdGluZyBvciByZWludmVudGluZyB0aGlzIGV4cGVydGlzZSBzaG91bGQg bm90IGJlIHVuZGVyZXN0aW1hdGVkIGJ5IGEgZ3JvdXAgd2lzaGluZyB0byBkZXZlbG9wIGEgY29k ZWMuIA1JdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJl dmVudCBhIHJveWFsdHktZnJlZSBjb2RlYyBiZWluZyBzZWxlY3RlZCBhcyBwYXJ0IG9mIHRoZSBj b2RlYyBkZXZlbG9wbWVudCBwcm9jZXNzIHdpdGhpbiBJVFUtVC4gSW4gZmFjdCwgc2V2ZXJhbCBy b3lhbHR5LWZyZWUgY29kZWNzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIGZvcm0gcGFydCBvZiB0 aGUgY29kZWMgcG9ydGZvbGlvIG9mIHRoZSBJVFUtVC4gSG93ZXZlciwgYSBub24tdGVjaG5pY2Fs IHJlcXVpcmVtZW50LCBzdWNoIGFzIHJveWFsdHktZnJlZSwgY2Fubm90IGJlIHNwZWNpZmllZCBh cyBwYXJ0IG9mIHRoZSBUZXJtcyBvZiBSZWZlcmVuY2UgZm9yIGEgY29kZXIuIFdlIG1ha2UgcmVm ZXJlbmNlIHRvIHRoZSBJUFIgcG9saWN5IG9mIHRoZSBJVFUtVCAoEyBIWVBFUkxJTksgImh0dHA6 Ly9pdHUuaW50L0lUVS1UL2lwci8iIAEUaHR0cDovL2l0dS5pbnQvSVRVLVQvaXByLxUpLg1XaGVu IGRldmVsb3BpbmcgYSBuZXcgY29kZWMsIFNHMTYgYWdyZWVzIHRoYXQgZWxpbWluYXRpbmcgM3Jk LXBhcnR5IElQUiBpcyBhbG1vc3QgaW1wb3NzaWJsZS4gSG93ZXZlciB0aGUgaW1wYWN0IG9mIHRo aXMgM3JkLXBhcnR5IElQUiBpcyBzaWduaWZpY2FudGx5IGxlc3Mgb2YgYSBwcm9ibGVtIHdpdGgg Y29kZWMgZGV2ZWxvcG1lbnRzIHdoZXJlIHRoZXJlIGlzIG5vIHVwLWZyb250IGdvYWwgdG8gYWNo aWV2ZSBhIHJveWFsdHktZnJlZSByZXN1bHQgYXQgdGhlIGVuZC4gSW4gY2FzZXMgd2hlcmUgcm95 YWx0eS1mcmVlIGlzIGFuIHVwLWZyb250IHJlcXVpcmVtZW50IHRoZW4gdGhlcmUgaXMsIGluIG91 ciB2aWV3LCBhbiB1bmFjY2VwdGFibHkgaGlnaCByaXNrIHRoYXQgdGhlIGNvbXBsZXRlIGRldmVs b3BtZW50IGVmZm9ydCB3aWxsIGJlIHdhc3RlZCB3aGVuIHRoaXMgSVBSIGNvbWVzIHRvIGxpZ2h0 IGFmdGVyIHRoZSBzdGFuZGFyZCBpcyBwdWJsaXNoZWQuIFRoZSBJVFUtVCBwcm9jZXNzZXMgaGF2 ZSBzYWZlZ3VhcmRzIGluLXBsYWNlIGlmIGEgbm9uLW1lbWJlciBoYXMgSVBSIGNsYWltcyB3aGlj aCB0aGV5IHdpbGwgbm90IGxpY2Vuc2Ugb24gUkFORCB0ZXJtcy4gDUluIGNvbmNsdXNpb24sIHdl IHdvdWxkIHJlaXRlcmF0ZSBvdXIgZGVzaXJlIHRvIGFzc2lzdCB0aGUgSUVURiBpbiBzYXRpc2Z5 aW5nIHRoZSBpbmR1c3RyeS4NX19fX19fX19fX19fXw0NAw0NBA0NAw0NBA0NLSATIFBBR0UgIFwq IE1FUkdFRk9STUFUIBQyFSAtDUNPTSAxNiCWIExTIDEyNCCWIEUNDUlUVS1UXENPTS1UXENPTTE2 XExTXDEyNEUuRE9DDQ1BdHRlbnRpb246IFNvbWUgb3IgYWxsIG9mIHRoZSBtYXRlcmlhbCBhdHRh Y2hlZCB0byB0aGlzIGxpYWlzb24gc3RhdGVtZW50IG1heSBiZSBzdWJqZWN0IHRvIElUVSBjb3B5 cmlnaHQuIEluIHN1Y2ggYSBjYXNlIHRoaXMgd2lsbCBiZSBpbmRpY2F0ZWQgaW4gdGhlIGluZGl2 aWR1YWwgZG9jdW1lbnQuIA1TdWNoIGEgY29weXJpZ2h0IGRvZXMgbm90IHByZXZlbnQgdGhlIHVz ZSBvZiB0aGUgbWF0ZXJpYWwgZm9yIGl0cyBpbnRlbmRlZCBwdXJwb3NlLCBidXQgaXQgcHJldmVu dHMgdGhlIHJlcHJvZHVjdGlvbiBvZiBhbGwgb3IgcGFydCBvZiBpdCBpbiBhIHB1YmxpY2F0aW9u IHdpdGhvdXQgdGhlIGF1dGhvcml6YXRpb24gb2YgSVRVLgcHDQ0NDQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAAACCAAA KAgAADsIAAA8CAAAPggAAGcIAAB0CAAAfQgAAH4IAAB/CAAAgQgAAIIIAACgCAAAoQgAAKIIAACv CAAAsQgAALQIAADbCAAA9ggAAAoJAAAMCQAAEgkAAFAJAABjCQAAcgkAAHYJAAB6CQAAgQkAAJIJ AACUCQAAqQkAAKsJAAC2CQAA8erh2tDqxOG+tKrqxKGV6qrqkeqqkeqq6oV3bGRsd2x3bHcAAAAA AAAAAAAAAAAAAAAAAAAAAAAOFmh8UCsAbUgJBHNICQQAFBVok0HxABZofFArAG1ICQRzSAkEABoV aKoudgAWaHxQKwA1CIFcCIFtSAkEc0gJBAAXFWiqLnYAFmh8UCsANQiBbUgJBHNICQQGFmh8UCsA ABYVaHxQKwAWaHxQKwA1CIFDShwAXAiBABAWaHxQKwA1CIFDShwAXAiBABIVaHxQKwAWaHxQKwA1 CIFcCIEAExVofFArABZofFArADoIgUNKFAAKFmh8UCsAQ0oUAAAWFWh8UCsAFmh8UCsANQiBQ0oa AFwIgQATFWh8UCsAFmh8UCsANQiBQ0ocAA0WaHxQKwA1CIFDShwAEBVofFArABZofFArAENKFAAA DBVofFArABZofFArAAAcA2oAAAAAFWh8UCsAFmh8UCsANQiBQ0okAFUIASMABgAAAggAACgIAAA8 CAAAPQgAAD4IAABnCAAAfggAAH8IAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAACJAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAGtkIBgAABYkARckAUlmAQAAAAKW OQADNAEI1kYAA8f/UAV5GYomYAaJBQAAAAAAAAAAAAAAAAAAAAAABikUAAAAAAAAAAAAAAAAAAAA AAAGEQ0AAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA /wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEM AAADJAIWJAFJZgEAAABhJAJnZHxQKwAJAAAWJAFJZgEAAABnZHxQKwAACAAGAADWEgAApBQAAP7+ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECfwgAAIAIAACBCAAAgggA AI8IAAChCAAAnAAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAhwAAAAAAAAAA AAAAAIcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQCFiQBSWYBAAAAYSQCZ2R8UCsACQAAFiQB SWYBAAAAZ2R8UCsAAGIAAGtkqRgAABYkARckAUlmAQAAAAKWOQADNAEHlGMBCNZGAAPH/1AFGBWK JiAGiQUAAAAAAAAAAAAAAAAAAAAAYAbIDwAAAAAAAAAAAAAAAAAAAAAABnIRAAAAAAAAAAAAAAAA AAAAABT2A8MmF/YDAAAY9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8A AAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAWhCAAAoggAAK8IAAC1CAAA 2ggAAJwAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAIWJAFJZgEAAABhJAJnZHxQKwAJAAAWJAFJ ZgEAAABnZHxQKwAAYgAAa2Q7GQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUDAMI1kYAA8f/UAUYFYom IAaJBQAAAAAAAAAADAEAAAAAAAAgBsgPAAAAAAAAAAAMAQAAAAAAAIAGchEAAAAAAAAAAAwBAAAA AAAAFPYDwyYX9gMAABj2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAA AP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEABNoIAADbCAAA7QgAAO4IAAD2 CAAACwkAAJwAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAAAUwAAAAAAAAAAAAAAAEoAAAAAAAAAAAAA AABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZHxQKwAAPAAAa2RpGgAAFiQBFyQBSWYBAAAA ApY5AAM0AQeUZQEI1hoAAcf/iiYABsMmAAAAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY9gMAABrW BAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQoDOQBh9gMAAGY0AQwAAAMkARYkAUlmAQAA AGEkAWdkfFArAABiAABrZOEZAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWRgADx/8YBjgTiiYA BlEGAAAAAAAAAAAAAAAAAAAAAAAGIA0AAAAAAAAAAAAAAAAAAAAAAAZSEwAAAAAAAAAAAAAAAAAA AAAU9gPDJhf2AwAAGPYDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA /wAAAP8d1gwAAAD/AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AQAFCwkAAAwJAAATCQAATwkAAFAJ AABiCQAArwAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAA AEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADAAAAyQBFiQBSWYBAAAAYSQBZ2T6c1wAAE8AAGtkNxsAABYkARckAUlmAQAA AAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAMAQAAAAAAAAAGciAAAAAAAAAAAAwB AAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYI AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AQsAABSkeAAWJAFJZgEAAABnZHxQKwAATwAAa2TFGgAA FiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/GAaKJgAGUQYAAAAAAAAAAAAAAAAAAAAAAAZy IAAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYI AAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAViCQAAYwkAAHIJAACBCQAAggkA AJIJAACUCQAAvwAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAWgAAAAAAAAAA AAAAALYAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJGAAWJAFJZgEAAABnZPpzXAAAUgAAa2QnHAAA FiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/TwiKJgAGiAgAAAAAAAAAAAAAAAAAAAAAAAY7 HgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYI AAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6c1wACRYAFiQBSWYBAAAAZ2T6 c1wACQAAFiQBSWYBAAAAZ2T6c1wAAD8AAGtktxsAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYa AAHH/4omAAbDJgwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzW BAAAAP8d1gQAAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAAABpQJAACVCQAAqQkAAKsJAACsCQAA tgkAAPsJAACsAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAABHAAAAAAAAAAAA AAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUgAAa2QXHQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/TwiKJgAGiAgA AAAAAAAAAAAAAAAAAAAAAAY7HgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/ AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6 c1wACRcAFiQBSWYBAAAAZ2T6c1wACQAAFiQBSWYBAAAAZ2T6c1wAAFIAAGtknxwAABYkARckAUlm AQAAAAKWOQADNAEHlGUBCNYwAALH/08IiiYABogIAAAAAAAAAAAAAAAAAAAAAAAGOx4AAAAAAAAA AAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/ HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNcAAAGtgkAANUJAAD6CQAA+wkAAAYKAAAR CgAAGwoAACcKAAAoCgAAOwoAADwKAABCCgAARwoAAFcKAABYCgAAXgoAAF8KAABgCgAAjAoAAI0K AACOCgAApQoAAKYKAACnCgAAsQoAAMAKAADBCgAAxAoAAMUKAADPCgAA0AoAAN8KAADgCgAA5AoA AOUKAAD0CgAA9QoAAPsKAAD8CgAA/QoAAC8LAAAwCwAAMQsAAE4LAABPCwAAUAsAAFELAABTCwAA KwwAAPbu4NLH0sC8wLzAuMC8wLitwKKtma3A0sC8wLzAuMC8wLjAvMC4rcCOrZmtwNKBvAAAAAAA AAAAAAAAAAAAGBVoqi52ABZofFArAENKEgBtSAkEc0gJBAAVAgiBA2rwHwAABggBFmh8UCsAVQgB EBVouw5GABZofFArADBKFAAAFQIIgQNqjR4AAAYIARZofFArAFUIARUDagAAAAAVaLsORgAWaHxQ KwBVCAEGFmjDR8MAAAYWaHxQKwAADBVouw5GABZofFArAAAUFWiTQfEAFmh8UCsAbUgJBHNICQQA GhVoqi52ABZofFArADUIgVwIgW1ICQRzSAkEABoVaMohRAAWaHxQKwA1CIFcCIFtSAkEc0gJBAAP FWjKIUQAFmh8UCsANQiBEhVoyiFEABZofFArADUIgVwIgTD7CQAA/AkAAAYKAAARCgAAEgoAABsK AABCCgAApwoAAKwAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAACjAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFIAAGtkBx4AABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/08IiiYABogIAAAA AAAAAAAMAQAAAAAAAAAGOx4AAAAAAAAAAAwBAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNc AAkTABYkAUlmAQAAAGdk+nNcAAkAABYkAUlmAQAAAGdk+nNcAABSAABrZI8dAAAWJAEXJAFJZgEA AAACljkAAzQBB5RlAQjWMAACx/9PCIomAAaICAAAAAAAAAAAAAAAAAAAAAAABjseAAAAAAAAAAAA AAAAAAAAABT2A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAAAB6cKAACoCgAAsQoAAMsKAABQCwAAmQAA AAAAAAAAAAAAAJAAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk+nNcAABl AABrZFQfAAAWJAEXJAFJZgEAAAACljkAAzQBB5TMAAjWRgADx/8YBkIXiiYABlEGDAEAAAAAAAAA AAAAAAAAAAAGKhEMAQAAAAAAAAAAAAAAAAAAAAZIDwwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAA GPYDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/ AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNcAAAEUAsAAFELAABSCwAAUwsAAJQLAAArDAAA DQ4AAJkAAAAAAAAAAAAAAACOAAAAAAAAAAAAAAAATgAAAAAAAAAAAAAAAEMAAAAAAAAAAAAAAAA6 AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAAAAEAABnZHxQKwAACAAADcYFAAGnJQJnZHxQKwAACgAA DcYFAAGnJQITpPAAZ2TDR8MAAD8AAGtkXyEAABYkARckAUlmAQAAAAKWOQADNAEHlMwACNYaAAHH /4omAAbDJgwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAA AP8d1gQAAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAALAAATpAAAFiQBSWYBAAAAZ2T6c1wAAGUA AGtkwyAAABYkARckAUlmAQAAAAKWOQADNAEHlMwACNZGAAPH/xgGQheKJgAGUQYMAQAAAAAAAAAA AAAAAAAAAAYqEQwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY 9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8A AAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6c1wAAAYrDAAADQ4AAL4PAAC/DwAAyw8AAOQPAADm DwAA5w8AAOgPAAABEAAAAhAAAAUQAABiEAAAfhAAAIEQAAD0EAAA1RIAANYSAADXEgAA2RIAANoS AADcEgAA3RIAAN8SAADgEgAA4hIAAOQSAADlEgAA+xIAAPwSAAD9EgAA/hIAABUTAAAWEwAANBMA ADUTAAA/EwAAohQAAKQUAAD49Oz05fTa7NHs9Mb4xvj0wrq2ura6trq2qZipmImYqbZ4tmxjtgAA AAAQFWh8UCsAFmh8UCsAQ0oSAAAWFWh8UCsAFmh8UCsANQiBQ0oSAFwIgQAgFWh8UCsAFmh8UCsA Q0oQAE9KAABRSgAAbUgMBHNIDAQAHRZow0fDAENKEgBPSgAAUUoAAG1IAARuSAAEdQgBIQNqAAAA ABVofFArABZofFArAENKEgBPSgAAUUoAAFUIARgVaHxQKwAWaHxQKwBDShIAT0oAAFFKAAAABhZo +nNcAAAPA2oAAAAAFmj6c1wAVQgBBhZocVAKAAAUFWi7DkYAFmh8UCsAbUgJBHNICQQAEBVoBFvk ABZofFArADBKFAAAFQIIgQNqzyEAAAYIARZofFArAFUIAQwVaLsORgAWaHxQKwAADwNqAAAAABZo fFArAFUIAQYWaHxQKwAADhZofFArAG1ICQRzSAkEJg0OAAAFEAAAaxIAAMcSAADVEgAA1hIAANgS AADZEgAA2xIAANwSAADeEgAA3xIAAOESAADiEgAAARMAABUTAAAWEwAANBMAADUTAADjEwAAoBQA APYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAA AAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADf AAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA5wAAAAAA AAAAAAAAAMUAAAAAAAAAAAAAAADFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpAAAFiQBSWYBAAAAZ2R8UCsAAAQQAGdkfFAr AAAJDwADJAEUpPAAYSQBZ2R8UCsAAAcPAAMkAWEkAWdkfFArAAABAAAABwAAAyQBYSQBZ2R8UCsA AAQAAGdkfFArAAAIAAANxgUAAaclAmdkfFArAAAUoBQAAKEUAACiFAAAoxQAAKQUAAClFAAAwQAA AAAAAAAAAAAAALoAAAAAAAAAAAAAAAC1AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABBAAZ2R8 UCsAAAYAABOkAABnZHxQKwA+AABrZIwiAAAWJAEXJAFJZgEAAAAAVAEAApZsAAM0AQjWGgABx/+K JgAGwyYEAQAABAEAAAQBAAAEAQAAFPYDwyYa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/MtYG AAEKAzkANNYGAAEKA2wAYfYDAABmNAGKVAEAAAWkFAAApRQAAPwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGFmhxUAoAATkACjABJlAJADGQaAE6cHxQKwAfsH0uILDIQSGw bgQisG4EI5CJBSSQiQUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBgAAEQAZAAAAAAAAAAIAAAAAAAAAAAAAAAAAEUG CAfxAuECAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwTAAAALIECvAIAAAAAQQA AAAKAABDAAvwKAAAAARBAQAAAAXBEAAAAAYBAgAAAP8BAAAIAGkAdAB1AC0AbwBsAGQAAAAAABDw BAAAAAAAAIBiAAfwgBcAAAYGAUBiTRU7jpmGIdjQWNlMW/8AXBcAAAEAAABEAAAAAAA1DgBuHvBU FwAAAUBiTRU7jpmGIdjQWNlMW/+JUE5HDQoaCgAAAA1JSERSAAAAawAAAHgIAwAAAMIj/AsAAAMA UExURaLE2YeVxOzx8oq20sTW37zT3dzm6dXh5ZiEp2SOvKzK2pG61Rs3j/r6+qWyz+pnhfLF0ChE lpajyeRUdnWlyLHN23eJu/Hz+DhTnml8tPT19sbZ4K1ojsPL4oejxs3d4mqXwe+xwNDe5J3B2Upg p7jS4+jt71lureTr7ODo6u2Rp4Szz+Tu9N7n6uvv8LO92OLq7FV+tOQmUvKfstjj5tPY6csqV8ja 4fP09cDW37rM2t0NPefX3rbQ3O/y8+br7aS30Ja91/b3+Oc/ZqQMS+MQQPvg5l11r5qvyy5MmlyF t0NaoTldorPG18rU3+p+l051r9bk6r5GcGMcaOLl8Zm/2ERipt/r8n6Tvs+Zr8isvazD1rzH2kdu q8aAncvc4+Pm7T9lp1Fqqc/g6tgYR5Kvzc7e5r03ZbvF1e/j59nf6rLA1cnc5cre66m90p6tzMfc 6c/a4/Hz86fH2v3w89HX56Ww0/3v8qfJ3ePs72BXmOEAM3+xzg4rif///wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM25c8QAAACAdFJOU/////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A OAVLZwAAAAFiS0dEf0i/ceUAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAABNNSURBVGhDvZrtQ9rY EsYDCFQgahDDiciLQImIICouUgsivTWGRCpdtdytrCu+tFddbXHXyhrCv37nJAESxLb3g3ewQgPy yzMzZ86ckxAd1bYmtBfP+ERo302ubD0jRf3qLqvz+h353LAeq/NuVn5mWJ+19ebb/40lv5t8Zi/2 dXUm3q48rzAdSx5/+7y5qGN1vj08rxf1rM67h5XnzEUDa2v5Wb1oYMnzD2/+er78MLA6W6cP88/n RSMLIvbwfEV4gPVt+TteJElvyvzHHlgq5ZVL/7OzB1jyysPD+DAvbmz4b0wMy3Isyzbwb5q+81/8 b7gBVgeEPQwUYZK8WKxFBZY2uYuHn/2Vr5XDz5djbppuCNGa/2/ypyvbIKsz+/CwrC8fqQs3y7Om y9WNmLnZNJvNsVgshX9a8UyFbgsCY7qY/jl9j1jf3jzoysfeIsu76Mp0qQDfD7YxB5ZOx8GSNls8 zrGHgUaUOyz8DO0RSwZhWuKX9kxRqs2uNpsqSKUBToEl062Y2SaYCvZX4GHTxo9d+YjVIUHYW5z4 q6YowyB3qbS21lxrNpvw1GwWCqkUprViMf9YwBSouV61bEn7dkNw7/1I22NWZ2IdQvYt5UZM5VIY u6jcmGo0BwapV3OP+b9mzNPNpj0QRXAqDEtRDfoyvJApNpB7+vt1YAhLHgcvTtbZSuyzi2KFKMvU gFEsKkzIvQZbKxYFdiwD8pLxMCDRgcmXDG4LDf93HTmE1dl6C7CZj7TgargvK3+QMjxKJBi8aMYr n9200G7Tl/a5VMtmS28L9hGTgEzBqo9Gte85chiriYU9/GOihTmyNA0hAoNQNQv4ZXO6VCoIpkM6 KnA32dScLdOotWzBbXRwXQ1/FITK09KGsMia61/AWt6qu0uplFnhrCmGU6NgTk1fCxupZuzQ1EBc 0WYuokomDKKo2tHJUY1ffLJ4PWbFuDb1Hgv7FK02VRRgpsG0RDSTNN2E1Dc3459pJAS+sjVbOFxt XYtMLngyhkzeJxLyEetCaDMjc5D3Dw/vSbOCmlZICg0rM8ucu4lHdTo9F7PfRAUBhVvBy+0A10Zs o4HajdjwfBxkVXjqGurPLOT9w/pKCVBYU0k1DUbStWYspgzpdKw0d4Pa0Yag5CtPBc4C26wwvIwM sCpUYzU1F2+ZlfRYnyiZdagujHSz00q5ipnTOwGucYDaLs5qD56fWAUanqycMNSNRtbfPB1vxePp dPo1zvuH5dekqgpnPEkqsLXC2ioKm1MF89wlLSDWdP01LNANFDgJZ893qMBVznpVHqrMwLrga7F4 Elhzc+Z5zHp4kyr1URqsWSixtJw6pA8EZiycTKVtczRXdfONS3v2JICsOWsuxwqxxwmiZ8UEJh23 KaxWSk2Ph3EcJ1VVV1izQFaQiUVMMW2GymHLZDJ+tJMcYaiaLzgi1M6t1nyeYx9PNDoW2UAZm01l zW14JxQvPrwraTVDVlil6TWStNdcbfdFszkH9d4GLLuNpW326jYSPlYDQi4HLIdgejSo+yyZdh3G AZaEcM3NtRbU9ID5RVEkg6kw+YJG3CLLrKUwClgAs40hXzhYzTFU4JVwDaypfIRaHMz8PuuwTafh rzRWLDVdxNUDbEXHIhWSnyQziEmleqzMV2GsGswenQR4Ttj2AWsqH+BXB0LWY11QVAWfYdeHqcJX Fx5kkPmzWJEiSy6YEFcpkVCnKgKbTCm6wIf2FsPZg9ls1r5z0D67wizHSwYNZH6XRTIuJm3vs2Ix 80bjvRqy0wnMwbhF1PDLJeg6UqlCkkOH5jnoBDArWRSywPL5gjsuqujL56cc9w6xZhTWZRUFNGbr sj6YF6CJIQNLk6oX3yow+Q8OFUlyrQnlN5WKFVI1nrab4wrLHhaKYYW1LTDUmU9hnbn+NsA0VgGZ Dip2jdV6vTIx8fo///n8z2/QwanKQNQdojdkaAhwqccNyEbzsIFMmZgNs2wcUwUfBnOIPqnxtdyU 4/b2fjRqqPkqS65x2w34C+xDWzKdWV4/XQZbP1WdiJUtcOizTE7D9K+xNuZgeI1FUe1VJh2v2twH 1XP7ybXQyPmyAVfNCiyCQHd6YSprj7cGmDBmASweX1CLht5O/6FTslZ8FRdC7YXim0qOsahRu9mp vOKvX21zFJPz5ay+ABXKA+o+ZCgfCktmmBbNgC5FGIxlm+Y7PW0F+0+bLbELAYWbxLnYKzcnRBFy 8dCXFo9GclawABWYIsAO3DphCmuP32kxNHa7logL0NY/snelkjIva9FSukSchsm07av18yuGtebO gyNQNaBsWGuugIOIEB6ka0AwS4bSaWPoKjhRg32wqdXQaOMFmM8wCmRBtNSRDG63Z+xhOwQse+Tz aax8fpS33EYi+8d3/eqBWXvo8qha4+AP+sKUyXLQJl/DTK2herKUjA8H7R/RTo8FQ3lqF+0TkUhI 6JdFYMl3bDBbNXHhsAJTym9yQauGRtzyBHQ7Sr4r0VJcqLFOXqHrI1UWlA2Hw0GgOhHZd6LFXsSA ZY6ehbN2d0NjYVg83no9JD2gXs2bvQva/G9ABY/sjUAQs3CVB9btvZMaJTb3y4yetYpGYBDuIKsC U9Ie5pUhea9onHxtVpYPBlXhYPCoyjDBETVc4EIYXfc1Soo4JdQrwaCrRtt9vmxQ2Aa3KxFTi31L K1CDQVteWVhQFyp9D4aDR1l7jVV0YVnAgoS/30WbTiffcyLRIaPbENPsCRQZnReT8Q8Tp0PSQ5Wm qeoGC6Oy4cABDC5NFmZFIk5+CVhct9wTHb+Qs0Gn4v16WGo2vbD68cYzMS+e+SdWhtv8BFlKJZNm rT/1Fppes/kke42U0ZW3LbRarQ+KjYxVCdGV0iJGdIqcbwHPun3bsDeNB4b8b9pmKxkOV32v0A7U J2veazjuOG53qz0hc4FcTHbjtb368Mtpe0F/oPtG/5l1y2uYVcP7AvjBVuTqiA8RmDVVInvHGxfy fd3VncaIvWhxZEFm2z27kdPhgv5A/63eqwawMtMy6h1YxCzhLItbjRLJ94775YAocl0frjamrAsy M8jSHRjKamaABcswze7kTG4k6s7ihC+R/eOHcsNVRlrpIPwHVmtML+PuJ3SxcjNjN+qyj/gO3NDV 5B0lsq/XL3MuSfSrwggT47O2jLriwYLMDVHTPySoLL0uO9alsfS6aJdUv9FYdMiXbxl1xY/M8g3L Mhw8GKbv/DZilCMccyMX7IO6crloADc190ZdjXa5TGusRiAHLEO8MAuWxvgH/pn6ckxKR6ocV1gG XVZg5aBk3Orj5Zfpulg2aazomXVqQJctOOe/S8E6D5qpkkzrWWuFC/dNjDQX0uGwMV4nGstx6zXE i/DwS6yaHAQq5oFl0GU7OkK0LYiLYzgm1/SsuP3rDaz57TaonWsGXSdWK+jCldCYh4QkHjeUKnVB IGLqkS67SQjDl+FSHDPqitvt6bAbaCM2+5phfJ3kgWWFtpAwxouQlvio0ggsYpYjbtSVHEFuexCz wuGUUdcH3ABV7e4DxHw0xus8bz0IWGHeIryG8UVIIVdD2WhcBZYDWLq6cSeba4IvCAao4ICu2eoJ PgNbGFo1v0HXeT6PtvG8FTHqikiSS1A3NQkUcdwmjbqyKGDPHik0YBni9Wb8T4AFg+fV8KukIV7n U1N8ceoWWNNGXR4LxWss6sxxO6CLEUZgPsoeHR0FjzaM8XrzMFk5CcI78AGvMV65InJAajyOV0JE GstVmyIGdEVRLugDGOCyrQFdsIT+fILPJOvzGnRdB2j+7CzgqbF7uuOHMuFJ1LusdhmzDPGCRbcV pmoFlx7UBZsDv/2JVyS+gkEXLVKUANsqYn3POL4kYKkNKUEd30YGdF3mBAGUYZjvsS5YSPz7zyuF pa8bV1PcbsRZ3CegRunrIehaiqpdACG4nIO6qr4RUIZhPt8QXdBxjPuufCPGeH3JR0chWETEOVA3 pESvbjDtEFE15qHd6oMNimvorjDLmIdauzP5+QvM5lHd/JUlUOAWms99YBl0SVLdpPbZBO2qR6rG eEFp811x/Fh4xDdi1EXCNRDVln/7op9haXnhTG3gnffyhat3DhekU0rsduv8HeKlAV1Q2qwjVzQV gJ45btSV+b0LW//9g24KcO3Jl8ebkf1N571XDvRQVKxkgdzozl8X4nH9g1EXlBuwKzdFj/iSxjy0 +37vLSrGZX+/LHMl2XwCDXZSlg/7R1n5gyRJQndeXo2GqJfGeJ1PKTDfNTrYWTDqOsl9+a0LO93S JXdbOFRbtT1T34Ntt/xSkjy8tl1EeBsewW3UdTSVh9Va3urLc/yiUdc5bGx1F+wP72S3vlMQaPeN iaV0hxBJWiRLudHto+TarmdsoB5CrcG4fC5XCxh1wb6W9cu1toRZ3vpBa7cof5GkhKilBtwPsHjg /NOoK3vrwDRFXcao6wifgnVHW1aMy3t6GYPtkEk2Q2Z4+n0vrCo9A3noA5ZKm5qyGXVdYdZU3jGj puOKvNd4quFyuWUSJpTEMdVdMsOaiC1XZd1f3Mg5AqYGjAOrGnVlMR/OI6+m4zpsDtzoGi0dl1mV SwSgRttMd0MFWHfoBPbzXJRmd8AiMO1eZZl678CZ+rRTcNz/W10xjX+TS4cMr8s94LngQo4s2zYh 3yW+vailBr5/Y4F/aVyI5CIqDMTdVgfegm0mxz2cB3F/84sCO53fgo9c3MEFxihYg6Pdfmj55A8O TAIP9ncdgFXiAt4F8/mqF+94XeyZzS8jGIbtlvgC6zFYX8FP0r/aJHPKKeBFI3F/rVwxgLI/OT8x sGqyvYRIKShUp3ubDnjPoYKkhHOU8mw6N51iiNjfj4BpNFUflkiM8mItMgWlXDH4xMeZ7rBef/tm fP5PvLqrfsk59hMKSEpIx7wHaUUD11745xXKiYSlzktOZ0IMRTY3N/dVXg+oaHREaJ5fOru9h3Ku maZM1ffLC6gR8OiaJcQjqXzQ32pT9oiu+YSUSIh8ArP2nU4dzcC7j3gOqIOQhbgn4Fy2X3zqFmL1 ef2TqQeSLNKuqy4l+DHjvk2nhEYBJomiJYEwC8M290FdRJXXM4jSWRnxx6HEvntmyNJ9/X1A9V5C WqL4kCVR1m3bqPcRyXe84l5elMSQ02IBmsrDzhywyH1E4tCvv/TKvVHb6UwAohWqU/wofGEC6mk3 47v3LJEQMYB5EEKYBTQdr89U2E73zLCNsR7ydIYTqeMQ1mYpi/pNem1fdJGCs8BubIeckCeqKfIM tul+8f4pRX1967/WLGoq8od9Vb17sWS2blHdSIGXe7RB3OZMd1PW6LmB/52+wF8GEzI3ZL8XFixU CJ8KjHNqFE4K47ryFI8qD0C/eGozRyfrPQ4ZLoW88Uppd89cDuD0gMmmXKZ2sT8xTidQc6vFeWYY U4/lrb9/AZFSfeQ2XuXoXXcoNbAXLfW6M0SJCgx/XAWqTOUZjvSqxRA/rr83aUUDXNQYuHrTv56y R5Vhwt49hnQU+VHF4X1TOZqZ1Kr72E5nXvQ+ZCnz3X0oXZ3XXsp+CBlkKZazhIe8kaYHS8Ok/fIe alTPLCHKkINKL9pPStnNe6CGeQBi8fAg7WmaNFCe1j/NvDCcXMLDBx5djNVf1yvRIIpX81Hapeqe AUcapRkS8sXgiVH9qaSnxnC90sscW8QlLS9CIrX0PUcGDAk5Y4iuhJghl+oNLNhmFpdETU0iMUqh MtTrp8zyj74mflKrrpq+Yq/HGFI3uoe8LE/1ZiBcrGEGeCJsliVqVF/rT7s5CAOL/onryx25wLSX nP1s8uxSYhmX0UFLJJZcoUTCpMvIddWPCQ81VJUhD1VtJRoqYt8dFs8STMaewdAnErsUzHlgpvd9 T/4CAxkyufbEnQ7GeCmwOxe0BH0d4EkEc4RuLCudBNXN0oSpnySnM9Iu737qDo7HrA5cqT42pLtF Ch1T/G5IgjKlnAMefngYdnNBp+1f/zwawsNzvnv0ghlIiYTFUz7m0e4o4CB6owNlJSEFtMuo0C++ e/JG0CG6sB/HQJoxIyyAE3lK3PV46lTZiSVq5VwpzFLtk3Y5+mF54gnacBbMZzS/OzC2EpAyoSWx 7WqjpdFRDx4aUPyhT/OEynVRpFy/vtFm0smJoXdMPsXqkH4WT2TGbE9YQsd8ubwrQmPCg4miCL8R L9Z3RZ67ImfHVdryUEc+yerIXriku+TBaro5kPAc4yqJ1XhATWh0aakcCoHC0K7ILpbkDklOvFtW xgC0+fqSobx+moUb4kNOEKH3wurgF2RjP4raPIpDNSqKjL9XKbZmJ5WyvDw7SPsuC2h/wybo7ijE xgOjrA6jTDfwICckz2idj5r29KOX/LaliHv7ZpY0zCs/YIE4smKKHoh8G6IH3Y2uJ5BC5WPxIGq6 GHILCojDTeTkrP5+8h+zAGdeLdKsyIvHu+XyaAjiVF7aPYaMYN03F0/dVLa1Na/cFzdruDb6KIbD DsDNKYdwxyjNNKLRA5ZmTHeHF96S/L175Uhyax5GQX8A/JSunzqboR/agrx8Oz6hevKZWZ3OX3/N ji+Pz/4FWfLsLCwIMmUesuT/wgJ1W7Ozf/0XvHEVdKRHia0AAAAASUVORK5CYIKHABYkARckAUlm AQAAAAGWAAAhdgADaAE11gUAAQOJBTXWBQECAykUNdYFAgMDEQ0jdgABiQUjdgECKRQjdgIDEQ06 VgsAApY5AAM0ART2A8MmGPYDAAAr1gIAAzXWBQABA4kFNdYFAQIDKRQ11gUCAwMRDTTWBgABBQAA ADTWBgABCgM5AGY0AZAAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA4kFNdYFAQIDyA811gUC AwNyESN2AAGJBSN2AQLIDyN2AgNyETpWCwACljkAAzQBB5RjART2A8MmGPYDAAAr1gIAASvWAgED NdYFAAEDiQU11gUBAgPIDzXWBQIDA3IRNNYGAAEFAAAANNYGAAEKAzkAZjQBpAAWJAEXJAFJZgEA AAABlgAAIXYAA2gBNdYFAAEDiQU11gUBAgPIDzXWBQIDA3IRI3YAAYkFI3YBAsgPI3YCA3IROlYL AAKWOQADNAEHlAwDFPYDwyYY9gMAACvWAgABK9YCAQEs1gMCAwE11gUAAQOJBTXWBQECA8gPNdYF AgMDchEv1gsAAwQAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AYYAFiQBFyQBSWYBAAAAAZYA ACF2AANoATXWBQABA1EGNdYFAQIDIA011gUCAwNSEyN2AAFRBiN2AQIgDSN2AgNSEzpWCwACljkA AzQBB5RlART2A8MmGPYDAAA11gUAAQNRBjXWBQECAyANNdYFAgMDUhM01gYAAQUAAAA01gYAAQoD OQBmNAFaABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPDJiN2AAHDJjpWCwACljkAAzQBB5Rl ART2A8MmGPYDAAA11gUAAQPDJjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDUQY11gUBAgNyIDTWBgABBQAAADTWBgABCgM5AGY0AX4AFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDUQY11gUBAgNyIC/WCwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBbgAW JAEXJAFJZgEAAAABlgAAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDwyYv1gsAAQEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNcAHYAFiQB FyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0 AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNc AHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsA ApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0 AXl0+nNcAHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgEC Ox46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgAB CgM5AGY0AXl0+nNcAHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgAB iAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAA ADTWBgABCgM5AGY0AXl0+nNcAIQAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQID Ox4jdgABiAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7Hi/W CwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBeXT6c1wAxwAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6 zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupC1YAAABtAGEAaQBsAHQAbwA6AGgAZQBy AHYAZQAuAHQAYQBkAGQAZQBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQAAAHlYgfQ7HX9IryyCXcSF J2MAAAAApasAAJoAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA1EGNdYFAQIDKhE11gUCAwNI DyN2AAFRBiN2AQIqESN2AgNIDzpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA11gUAAQNRBjXWBQEC AyoRNdYFAgMDSA8v1gsAAwEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNcANMAAABE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtiAAAAbQBhAGkA bAB0AG8AOgBoAGkAdwBhAHMAYQBrAGkALgB5AHUAcwB1AGsAZQBAAGwAYQBiAC4AbgB0AHQALgBj AG8ALgBqAHAAAAB5WIH0Ox1/SK8sgl3EhSdjAAAAAKWrAACaABYkARckAUlmAQAAAAGWAAAhdgAD aAE11gUAAQNRBjXWBQECAyoRNdYFAgMDSA8jdgABUQYjdgECKhEjdgIDSA86VgsAApY5AAM0AQeU zAAU9gPDJhj2AwAANdYFAAEDUQY11gUBAgMqETXWBQIDA0gPL9YLAAMBAAAA/wwBAAA01gYAAQUA AAA01gYAAQoDOQBmNAF5dPpzXABuABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPDJiN2AAHD JjpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA11gUAAQPDJi/WCwABAQAAAP8MAQAANNYGAAEFAAAA NNYGAAEKAzkAZjQBeXT6c1wAvQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnq efm6zhGMggCqAEupC0wAAABoAHQAdABwADoALwAvAGkAdAB1AC4AaQBuAHQALwBJAFQAVQAtAFQA LwBpAHAAcgAvAAAAeViB9Dsdf0ivLIJdxIUnYwAAAAClqwAAaAAWJAEXJAFJZgEAAAABljMAIXYA AWgBNdYFAAEDwyYjdgABwyY6VgsAApZsAAM0ART2A8MmF/YAAAA11gUAAQPDJi/WCwABDwAAAP8E AQAAMtYGAAEKAzkANNYGAAEFAAAAZjQBilQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAhgIZABIAAQCcAA8ABAAAAAMAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAYPH/AgBmAAwAAAB8UCsAAAAGAE4AbwBy AG0AYQBsAAAAJwAAAA3GDgAEGgOnBDQGwQfAwMDAE6R4ADUkADckADgkADlEAgBIJAAAGABDShgA UEoAAF9IAQRtSAkIc0gJCHRICQQAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEAAAAAAAAA ABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAVgBpQPP/ swBWAAwFAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAIAA6VgsAF/YDAAA01gYA AQUDAAA01gYAAQoDbABh9gMAAAIACwAAACgAa0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkA cwB0AAAAAgAMAAAAAAA0AB9AAQDyADQADAAAAAAAAAAAAAYASABlAGEAZABlAHIAAAANAA8ADcYI AAJfEr4kAQIAAAA0ACBAAQACATQADAAAAAAAAAAAAAYARgBvAG8AdABlAHIAAAANABAADcYIAAJf Er4kAQIAAAAwAP5vAQASATAADAAVAHxQKwAAAAcATABTAFQAaQB0AGwAZQAAAAIAEQAGADUIgVwI gTIA/m8BACIBMgAMAAAAfFArAAAACABMAFMAUwBvAHUAcgBjAGUAAAACABIABgA1CIFcCIE2AP5v AQAyATYADAAAAHxQKwAAAAoATABTAEQAZQBhAGQAbABpAG4AZQAAAAIAEwAGADUIgVwIgTYAVWCi AEEBNgAMBAAAfFArAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioCcGgAAP8ASgD+b6IA UQFKAAwAEQB8UCsAAAAMAEwAUwBUAGkAdABsAGUAIABDAGgAYQByAAAAGgA1CAFDShgAXAgBX0gB BG1ICQhzSAkIdEgJBDgA/m8BAGIBOAAMAAAAfFArAAAACwBMAFMARgBvAHIAQQBjAHQAaQBvAG4A AAACABYABgA1CIFcCIEuAP5vYQFyAS4ADAAAAHxQKwAAAAkATABTAEYAbwByAEkAbgBmAG8AAAAC ABcAAAA0AP5vYQGCATQADAAAAHxQKwAAAAwATABTAEYAbwByAEMAbwBtAG0AZQBuAHQAAAACABgA AAAAAAAApQwAAAYAADgAAAAA/////wAAAACnAgAAqAIAAKYMAADq0AAwADAAAAAAAAACAAAAAwAA AAEAAAA0pIoHCkAAAAAwAAAAAAAAAAAAAAAABjCvDgAAAAAwBwoAAAAAMAAAAAAAAAAAAAAAAAMw AAAAAAAAAAcAAAAAAgAAACgAAAA8AAAAPQAAAD4AAABnAAAAfgAAAH8AAACAAAAAgQAAAIIAAACP AAAAoQAAAKIAAACvAAAAtQAAANoAAADbAAAA7QAAAO4AAAD2AAAACwEAAAwBAAATAQAATwEAAFAB AABiAQAAYwEAAHIBAACBAQAAggEAAJIBAACUAQAAlQEAAKkBAACrAQAArAEAALYBAAD7AQAA/AEA AAYCAAARAgAAEgIAABsCAABCAgAApwIAAKgCAACxAgAAywIAAFADAABRAwAAUgMAAFMDAACUAwAA KwQAAA0GAAAFCAAAawoAAMcKAADVCgAA1goAANgKAADZCgAA2woAANwKAADeCgAA3woAAOEKAADi CgAAAQsAABULAAAWCwAANAsAADULAADjCwAAoAwAAKEMAACiDAAApgwAAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpYAAAADAAAAAAAAAAgAAA AIABAAAAAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACAAKlAAAAAMAAAAAAAAACAAAAA gAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAmUAAAAAwAAAAAAAAAIAAAACA AQAABAAAAACgAKlgAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACpYAAAADAAAAAAAAAAgAAAAIAB AAAAAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACAAalAAAAAMAAAAAAAAACAAAAAgAEA AAAAAAAAoAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAA AAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgAAAAIABAAAA AAAAAKABmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAA AACgAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACZQAAAADAAAAAAAAAAgAAAAIABAACEAAAA AKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAA oAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAA qQAAABYwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABgwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAA ABcwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABMw AAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAKgAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAAqAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAKgAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAACoAAAAACABmQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAAKgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAB5yAAwADAAAAAAAAABAAAA AAAAAAAAAAAAAKAHiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACkB3nIADAAMAAAAAAAAAEAAAAA AAAAAAAAAAAAoAeIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAKQHecgAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAACgB4iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAApAd5yAAwADAAAAAAAAABAAAAAAAA AAAAAAAAAKAHiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACkB5hAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAiNEAMAowAAAAAAAAAQAAAAgAAAAL AAAA8FlOB5hAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACI0QAwCTAAAAAAAAACAAAAAgAAAAoA AACclE4HqUAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKlAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACZQAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAIiRADAAMAAAAAAAAAEAAAAAAAAAAAAAADgJpAcAAAAAAgAAACgAAAA8AAAAPQAAAD4AAABn AAAAfgAAAH8AAACAAAAAgQAAAIIAAACPAAAAoQAAAKIAAACvAAAAtQAAANoAAADbAAAA7QAAAO4A AAD2AAAACwEAAAwBAAATAQAATwEAAFABAABiAQAAYwEAAHIBAACBAQAAggEAAJIBAACUAQAAlQEA AKkBAACrAQAArAEAALYBAAD7AQAA/AEAAAYCAAARAgAAEgIAABsCAABCAgAApwIAAKgCAACxAgAA ywIAAFADAABRAwAAUgMAAFMDAACUAwAAKwQAAA0GAAAFCAAAawoAAMcKAADVCgAA1goAAAELAAAV CwAAFgsAADQLAAA1CwAA4wsAAKAMAAChDAAAogwAAKYMAACpQAAAADAAAAAAAAAAgAAAAIABAAAA AAAAAKABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAA AAAAoAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqWAAAAAwAAAAAAAAAIAAAACAAQAAAAAA AACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAA AKABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAJlAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA oACpYAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAqWAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACg AKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgAGpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAB mUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACr QAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAZlA AAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKABmUAA AAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACrQAAA ADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAA MAAAAAAAAACAAAAAgAEAAAAAAAAAoACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKABmUAAAAAw AAAAAAAAAIAAAACAAQAABAAAAACgAKtAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAeZQAAAADAA AAAAAAAAgAAAAIABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAACuMAAA AAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAA AAAAAICUpQEAAQAA0AAAAAAgAalAAACwMAAAAAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAA AAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAACvMAAAAAAA AACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAA AICUpQEAAQAA0AAAAAAgAalAAAAAMAAAAAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAA gJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAAAuMAAAAAAAAACA lKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICU pQEAAQAA0AAAAAAgAalAAAAAMAAAAAAAAACAlKUBAAEAANAAAAAAIAGrQAAAADAAAAAAAAAAgJSl AQABAADQAAAAACAHmUAAAAAwAAAAAAAAAICUpQEAAQAA1AAAAAAgAalAAAAAMAAAAAAAAACAlKUB AAEAANAAAAAAIAGpQAAAADAAAAAAAAAAgJSlAQABAADQAAAAACABq0AAAAAwAAAAAAAAAICUpQEA AQAA0AAAAAAgB5lAAAAAMAAAAAAAAACAlKUBAAEAANQAAAAAIAGpQAAAADAAAAAAAAAAgJSlAQAB AADQAAAAACABmUAAAAAwAAAAAAAAAICUpQEAAQAA1AAAAAAgAZhAAAAAMAAAAAAAAACAlKUBAAAA AAAAAAAAAAGYQAAAADAAAAAAAAAAgJSlAQAAAAAAAAAAAAABmEAAAAAwAAAAAAAAAICUpQEAAAAA AAAAAAAAAZhAAAAAMAAAAAAAAACAlKUBAAAAAAAAAAAAAAGYQAAAADAAAAAAAAAAgJSlAQAAAAAA AAAAAAABmEAAAAAwAAAAAAAAAICUpQEAAAAAAAAAAAAAAZhAAAAAMAAAAAAAAACAlKUBAAAAAAAA AAAAAAEIAAAAADAAAAAAAAAAAAAAAAAAAAAIAAAAAAABitEAMAAwAAAAAAAAAgAAAAUAAAAAAAAA AAAAB4jRADAAMAAAAAAAAAIAAAAFAAAAAAAAAAAAAAGI0QAwAzAAAAAAAAABAAAABwAAAAQAAADA VU4HqUAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAYjRADAAMAAAAAAAAAIAAAAFAAAAAQAAAECM TgepQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAIABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACg AJlAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA CgAAAAAwAAAAAAAAAAAAAAAAJTDNAQAAAQAABwAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwAAAAM AAAAQAAAAEAAAABfAAAAXwAAAM0BAADQAQAAAAYAALYJAAArDAAApBQAAKUUAAALAAAAFAAAABgA AAAbAAAAAAYAAH8IAAChCAAA2ggAAAsJAABiCQAAlAkAAPsJAACnCgAAUAsAAA0OAACgFAAApRQA AAwAAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAVAAAAFgAAABcAAAAZAAAAGgAAAAAGAACkFAAA DQAAAF8CAACNAgAApQIAAPwCAAAwAwAATgMAAL4HAADnBwAAAQgAAKUMAAATWBT/FZQTWBT/FZQT WBT/FZQOAAAAJQAAACcAAADQAQAAEyEU/5WADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAAAgAAAAEA AAABAAAAAwAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAIE AAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAA AA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAA PwMBAAEAAAAR8AQAAAABAAAApQwAAP//CgAAAAgAZAB0AGEAYgBsAGUAYQB1AAoASQBuAHMAZQBy AHQATABvAGcAbwAEAGQAbgB1AG0ABQBkAGQAYQB0AGUABwBkAG8AcgBsAGEAbgBnAAgAZABtAGUA ZQB0AGkAbgBnAAkAZABiAGwAdQBlAHAAaQBuAGsABgBkAHQAaQB0AGwAZQAHAGQAcwBvAHUAcgBj AGUABwBkAHQAaQB0AGwAZQAxAAAAAAAAAAAAAAAAAD0AAACAAAAAogAAAKIAAADbAAAA7gAAAAwB AACmDAAACAAAAAAAAAABAAKDAgACgwMAAoMEAAKDBQABggYAAIEHAAGCCQABggAAAAA9AAAAgAAA AKIAAADbAAAA2wAAAO4AAAAMAQAAUAEAAFABAACmDAAA//8KAAAABgCCmUMFEAABAHSGGQAGAIOZ QwURAAEA7K0hDgYAhJlDBRAAAQCs0CkOBgCFmUMFEAABAFzAKQ4GAIaZQwURAAEAnCedCgYAh5lD BRAAAQDEkBkABgCImUMFEQABAIQ2Lg4GAImZQwUQAAEANDcuDgYAiplDBREAAQDU9ikOBgCLmUMF EAABAFQ0GAAiAAAAtQAAALUAAADVAQAA1QEAADwCAAA8AgAAxQIAAMUCAABeCgAApgwAAAAAAAAB AAEAAAACAAIAAAACAAMAAAACAAQAAAACAAUAAAACAAYAAAACAAcAAAACAAgAAAACAAkAAAABACcA AAC7AAAAuwAAANsBAADbAQAAQQIAAEECAADKAgAAygIAAGIKAACmDAAAAAAAAAEAAAACAAAAAwAA AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAMAAAA4AAAACQAAACqAdXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBIBDaXR5AIA5AAAACgAAACqAdXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAQgAAAAQAAAAqgHVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncw6AY291bnRyeS1yZWdpb24AgAwAAAHcsQEQ AAAAAAoAAAAAAAkAAAAAAAoAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAQAAAAAAAoAAAAAAAQAAAAA AAoAAAAAAAAAAADWCgAA1goAANgKAADYCgAA2QoAANkKAADbCgAA3AoAAN4KAADfCgAA4QoAAOIK AACjDAAApgwAAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgAAAAAA1goAANYKAADYCgAA2AoA ANkKAADZCgAA2woAANwKAADeCgAA3woAAOEKAADiCgAAowwAAKYMAAAHAAQABwAEAAIABAAHAAQA BwAEAAcABAAHAAIAAAAAAAIAAAA+AAAAggAAABMBAABQAQAAtgEAAPwBAABTAwAAzwMAANAEAADH CgAA1QoAANYKAADWCgAA2AoAANgKAADZCgAA2QoAANsKAADcCgAA3goAAN8KAADhCgAA4goAAOQK AAD+CgAAFAsAAKMMAACmDAAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAEAAcABAACAAQABwAE AAcABAAHAAQABQAHAAUABwACAAAAAADWCgAA1goAANgKAADYCgAA2QoAANkKAADbCgAA3AoAAN4K AADfCgAA4QoAAOIKAACjDAAApgwAAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgATAAAABAAA AAgAAADlAAAAAAAAABIAAADvCwMAcVAKACNxIAB8UCsAiipWAD1lVwD6c1wAskFfAAwvagDQZGoA Elp3AM4zfgB0ZJ8ARXGjALYMpwDDR8MArn/WAPgj4ABzEPkAAAAAAAIAAAAoAAAAPAAAAD0AAAA+ AAAAfgAAAH8AAACAAAAAgQAAAIIAAAChAAAAogAAAK8AAAC1AAAA2gAAANsAAADtAAAA7gAAAPYA AAALAQAADAEAABMBAABPAQAAUAEAAGIBAABjAQAAcgEAAIEBAACCAQAAkgEAAJQBAACVAQAAqQEA AKsBAACsAQAAtgEAAPsBAAD8AQAABgIAABECAAASAgAAGwIAAEICAACnAgAAqAIAALECAADLAgAA UAMAAFEDAABSAwAAUwMAANYKAAA1CwAAoAwAAKEMAACmDAAAAAAAAAIBAAACAQAAAgEAAJ4BAAQC AQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAJ4BAAQCAQAAngEABAIB AAACAQAAngEABAIBAAACAQAAngEABAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEA AAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAngEABAIBAAACAQAA AgEAAJ4BAAQCAQAAlgEABAAAAAAIAAAAAgEAAJYBAAT/QAGAAQC4BgAAuAYAACycWgkBAAEAuAYA AAAAAAC4BgAAGAaKJgIQAAAAAAAAAKUMAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD/ /wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAA AgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAA ADsGkAGGBwIBBgADAQEBAQEDAAAAAAAOCBAAAAAAAAAAAQAEAAAAAABTAGkAbQBTAHUAbgAAAItb U08AACIABAAxCIwYAPDQAgAAaAEAAAAAU1LbRlZS20aZGjtmAgADAAAAsAEAACYJAAABAC8AAAAE AAMQSQAAALABAAAmCQAAAQAvAAAASQAAAAAAAAChJADwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABuBIkFeAC0AIGCEjQAABAAGQBkAAAAGQAAAKcKAACnCgAAAAAAAOluBukAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAEECAAAAAAgyg3EA 8BAACNwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFgAAAAACfD/DwEAAT8AAOQEAAD///9/ ////f////3////9/////f////3////9/fFArAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA AAAAOwBSAGUAcABsAHkAIABMAFMAIAB0AG8AIABJAEUAVABGACAAbwBuACAAcwBwAGUAZQBjAGgA IABhAG4AZAAgAGEAdQBkAGkAbwAgAGMAbwBkAGkAbgBnACAAcwB0AGEAbgBkAGEAcgBkAGkAegBh AHQAaQBvAG4AAAACADEAMAAAABIAUgBhAHAAcABvAHIAdABlAHUAcgBzACAAUQAxADAALwAxADYA GABBAHIAdAB1AHIAbwAgAE0AYQByAHQAaQBuACAAZABlACAATgBpAGMAbwBsAGEAcwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAFACAAASAAAAAQAAAJgAAAACAAAA oAAAAAMAAADkAAAABAAAAPAAAAAFAAAADAEAAAYAAAAYAQAABwAAAJwBAAAIAAAAsAEAAAkAAADU AQAAEgAAAOABAAAKAAAAAAIAAAsAAAAMAgAADAAAABgCAAANAAAAJAIAAA4AAAAwAgAADwAAADgC AAAQAAAAQAIAABMAAABIAgAAAgAAAOQEAAAeAAAAPAAAAFJlcGx5IExTIHRvIElFVEYgb24gc3Bl ZWNoIGFuZCBhdWRpbyBjb2Rpbmcgc3RhbmRhcmRpemF0aW9uAB4AAAAEAAAAAAAAAB4AAAAUAAAA UmFwcG9ydGV1cnMgUTEwLzE2AAAeAAAABAAAADEwAAAeAAAAfAAAAENPTSAxNiCWIExTIDEyNCCW IEUgIEZvcjogR2VuZXZhLCAyNiBPY3RvYmVyIC0gNiBOb3ZlbWJlciAyMDA5DURvY3VtZW50IGRh dGU6IA1TYXZlZCBieSBSQS0xMDY5NjkgYXQgMDk6MTk6NTYgb24gMTAuMTEuMjAwOQAeAAAADAAA AE5vcm1hbC5kb3QAAB4AAAAcAAAAQXJ0dXJvIE1hcnRpbiBkZSBOaWNvbGFzAAAAAB4AAAAEAAAA MgAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAADSSWsAAAAAQAAAAAB+B03d Jb8BQAAAAABylHTeYcoBQAAAAABE3t/eYcoBAwAAAAEAAAADAAAAsAEAAAMAAAAmCQAAAwAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAA AAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmujAEAAEgBAAAOAAAA AQAAAHgAAAAOAAAAgAAAAA8AAACQAAAABAAAAMQAAAAFAAAAzAAAAAYAAADUAAAAEQAAANwAAAAX AAAA5AAAAAsAAADsAAAAEAAAAPQAAAATAAAA/AAAABYAAAAEAQAADQAAAAwBAAAMAAAAJwEAAAIA AADkBAAAHgAAAAgAAABJVFUtVAAAAB4AAAAsAAAASW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNh dGlvbiBVbmlvbiAoSVRVKQADAAAA4DcAAAMAAABJAAAAAwAAAC8AAAADAAAApwoAAAMAAAAPJwsA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAA8AAABJVFUgTm9ybWFsLmRv dAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAADoAgAACQAAAAAAAABQAAAAAQAAAM8A AAACAAAA1wAAAAMAAAA/AgAABAAAAFsCAAAFAAAAZwIAAAYAAACPAgAABwAAAJsCAAAIAAAAywIA AAcAAAACAAAADAAAAF9QSURfSExJTktTAAMAAAAHAAAARG9jbnVtAAQAAAAIAAAARG9jZGF0ZQAF AAAACgAAAERvY29ybGFuZwAGAAAADAAAAERvY2JsdWVwaW5rAAcAAAAIAAAARG9jZGVzdAAIAAAA CgAAAERvY2F1dGhvcgACAAAA5AQAAEEAAABgAQAAEgAAAAMAAAAUAFkAAwAAAAYAAAADAAAAAAAA AAMAAAAFAAAAHwAAABoAAABoAHQAdABwADoALwAvAGkAdAB1AC4AaQBuAHQALwBJAFQAVQAtAFQA LwBpAHAAcgAvAAAAHwAAAAEAAAAAAGAQAwAAAHsABwADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAf AAAAJQAAAG0AYQBpAGwAdABvADoAaABpAHcAYQBzAGEAawBpAC4AeQB1AHMAdQBrAGUAQABsAGEA YgAuAG4AdAB0AC4AYwBvAC4AagBwAAAAAAAfAAAAAQAAAAAAYBADAAAANgBNAAMAAAAAAAAAAwAA AAAAAAADAAAABQAAAB8AAAAfAAAAbQBhAGkAbAB0AG8AOgBoAGUAcgB2AGUALgB0AGEAZABkAGUA aQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AAAAAAB8AAAABAAAAAABgEB4AAAAUAAAAQ09NIDE2IJYg TFMgMTI0IJYgRQAeAAAABAAAAAAAAAAeAAAAIAAAAEVuZ2xpc2ggb25seSBPcmlnaW5hbDogRW5n bGlzaAAAHgAAAAQAAAAxMAAAHgAAACgAAABHZW5ldmEsIDI2IE9jdG9iZXIgLSA2IE5vdmVtYmVy IDIwMDkAAAAAHgAAABQAAABSYXBwb3J0ZXVycyBRMTAvMTYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAAHwAAACAAAAAhAAAAIgAAACMAAAAk AAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAP7///8wAAAAMQAAADIA AAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAA TwAAAFAAAABRAAAAUgAAAP7////9////VQAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAACAPAfp3mHKAVcAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAAAPYiAAAAAAAA MQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAvAAAAbScAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA7OAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLAAAAABAAAAAAAAAB AEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRv Y3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01CA6201.D031E938-- From ingemar.s.johansson@ericsson.com Tue Nov 10 04: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 B1D0B3A6AAC for ; Tue, 10 Nov 2009 04:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 zmsqfYHSjBPD for ; Tue, 10 Nov 2009 04:46:36 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 258F63A68D3 for ; Tue, 10 Nov 2009 04:46:35 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-52-4af960c4894e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 38.45.16818.4C069FA4; Tue, 10 Nov 2009 13:47:00 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:47:00 +0100 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, 10 Nov 2009 13:46:59 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: Acph+k5z9VDxFRx3Sj23paQmG1RdpwABri2z References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> From: "Ingemar Johansson S" To: "Alan Duric" , X-OriginalArrivalTime: 10 Nov 2009 12:47:00.0048 (UTC) FILETIME=[E5090D00:01CA6203] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 12:46:37 -0000 Hi =20 What was the answer?, is there any documentation of this effort in the = ITU-T archives. I guess there should be. I am just trying to understand = the reality behind the general conception that it is difficult to = approach ITU-T and to be honest I cannot imagine what the outcome is or = was as I haven't tried it myself. 2000/2001 is quite a few moons ago an = then the word royalty free was real difficult to find on the map, is = there a chance that the attitude may have changed since, especially as a = result of the discussions in IETF ?. =20 What I can see (URL's provided by colleagues active in ITU-T, I am not = an ITU-T geek myself) the cost of participating as an associate in ITU-T = is CHF10600 (~USD10000) per year.=20 http://www.itu.int/members/associates/fees.html = =20 The limitations with being an associate is found at=20 http://www.itu.int/members/associates/rights.html = =20 I am interested to know what the specific problems was or are, is it the = cost or the lack of voting rights or a combination ?. If I understand it = right one cannot vote directly as an associate but there are = possibilities to go via the national body. =20 BR /Ingemar =20 =20 ________________________________ Fr=E5n: Alan Duric [mailto:alan@telio.no] Skickat: ti 2009-11-10 12:38 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? Dear Ingemar, I have personally approached ITU on behalf of Global IP Solutions (at=20 that time Global IP Sound), back in 2001/2002, with respect to=20 standardization of iLBC.You can imagine the outcome. I would not recommend to any of the authors of the current set of=20 codecs to consider that process. This question has been brought up at the last meeting in Stockholm and=20 I suppose the conclusion was obvious. Best regards, alan Alan Duric CTO and Cofounder Telio Holding ASA | Oslo exchange: TELIO On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > Hi > > I am curious to know to what extent proponents of a Codec WG in IETF=20 > has approached ITU-T with a request to standardize a RF codec. > > As I understand it there is a possibility of free membership which=20 > of course means limited rights to vote, however if I get this part=20 > correct it is a possibility to get voting rights via a countrys=20 > standards body. There is a chance that I don't get these details=20 > right as I have not myself digged into the membership rules of ITU-T. > > Anyway, my question. Who has actively approached the ITU-T with this=20 > and what was he response ?. Also are there any meeting documents or=20 > other public info that documents this ? > > BR > /Ingemar > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From alan@telio.no Tue Nov 10 03:37: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 AACDB3A6990 for ; Tue, 10 Nov 2009 03:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVg75T9gltoy for ; Tue, 10 Nov 2009 03:37:52 -0800 (PST) Received: from mailx.metromail.hr (mailx.metromail.hr [213.147.96.46]) by core3.amsl.com (Postfix) with ESMTP id 6724E3A685C for ; Tue, 10 Nov 2009 03:37:52 -0800 (PST) Received: from mailx.metromail.hr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 68304308CCB; Tue, 10 Nov 2009 12:38:18 +0100 (CET) Received: from [192.168.15.107] (unknown [213.147.102.229]) by ha1rez.metronet.hr (Postfix) with ESMTP id 1A799308CC6; Tue, 10 Nov 2009 12:38:18 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Alan Duric In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> Date: Tue, 10 Nov 2009 12:38:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> To: Ingemar Johansson S , codec@ietf.org X-Mailer: Apple Mail (2.1076) X-PMX-Version: 5.5.8.383112, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.10.112422 X-Mailman-Approved-At: Tue, 10 Nov 2009 05:01:54 -0800 Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 11:44:45 -0000 Dear Ingemar, I have personally approached ITU on behalf of Global IP Solutions (at =20= that time Global IP Sound), back in 2001/2002, with respect to =20 standardization of iLBC.You can imagine the outcome. I would not recommend to any of the authors of the current set of =20 codecs to consider that process. This question has been brought up at the last meeting in Stockholm and =20= I suppose the conclusion was obvious. Best regards, alan Alan Duric CTO and Cofounder Telio Holding ASA | Oslo exchange: TELIO On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > Hi > > I am curious to know to what extent proponents of a Codec WG in IETF =20= > has approached ITU-T with a request to standardize a RF codec. > > As I understand it there is a possibility of free membership which =20 > of course means limited rights to vote, however if I get this part =20 > correct it is a possibility to get voting rights via a countrys =20 > standards body. There is a chance that I don't get these details =20 > right as I have not myself digged into the membership rules of ITU-T. > > Anyway, my question. Who has actively approached the ITU-T with this =20= > and what was he response ?. Also are there any meeting documents or =20= > other public info that documents this ? > > BR > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Nov 10 05:26: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 1FC9B3A67E1 for ; Tue, 10 Nov 2009 05:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nThBa53kquMO for ; Tue, 10 Nov 2009 05:26:24 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id BDA3B3A672F for ; Tue, 10 Nov 2009 05:26:23 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 922B960647B93; Tue, 10 Nov 2009 13:26:50 +0000 (GMT) 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=2V6ghoMie2qo 1JmWUuwpZuqZuVM=; b=uW86EOkmV2fgZMQyv8RhJQ3MaBdOYKzQ7DPs6xlP10Uj MSpxxvemhlzr/6XWpoiKLPm5QEFVaE2vAuVC7DDbjfI1+Qp+DKQLRyob3WnlzhJ+ 3qgE2tcbiKrLHK1jPy6oKbLrih51zJl+k8E4Yr7jQnFDJbN8UG1ETroEPuv8FvQ= 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=amwGrKUZGKHEDBflRg/i BJ8jhTuVk+l7XPbbZuaGRVCdGX0RfeyGgUcPq0KjrFLAhES4rPe2g/KGvCkVHRv/ i4/jestKaNSgxfexpyD97cldoxCt6ytBh4fpSlfxI31nVOQgECWkQzfKRkv/3ILt Cn2jCg3T13vXJgmXOSRIZ9E= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9049460646131; Tue, 10 Nov 2009 13:26:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYqENEnziwGr; Tue, 10 Nov 2009 13:26:41 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 3679C606453F5; Tue, 10 Nov 2009 13:26:41 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Tue, 10 Nov 2009 05:26:41 -0800 Message-ID: <20091110052641.34281f6075r5cowh@mail.skype.net> Date: Tue, 10 Nov 2009 05:26:41 -0800 From: Koen Vos To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> 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) Cc: Alan Duric , codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 13:26:25 -0000 The ITU liaison stated that their policy requires royalty free (RF) or =20 reasonable and non-discriminatory terms (RAND) for their standards. In =20 practice that means that anyone can add IP to the standard as long as =20 it brings a small improvement. Unfortunately, that means their policy is incompatible with that of =20 the IETF. They were fully aware of that when writing the liaison, yet =20 didn't indicate a willingness to abandon their position. ITU liaison: https://datatracker.ietf.org/documents/LIAISON/file662.doc koen. Quoting Ingemar Johansson S: > Hi > > What was the answer?, is there any documentation of this effort in =20 > the ITU-T archives. I guess there should be. I am just trying to =20 > understand the reality behind the general conception that it is =20 > difficult to approach ITU-T and to be honest I cannot imagine what =20 > the outcome is or was as I haven't tried it myself. 2000/2001 is =20 > quite a few moons ago an then the word royalty free was real =20 > difficult to find on the map, is there a chance that the attitude =20 > may have changed since, especially as a result of the discussions in =20 > IETF ?. > > What I can see (URL's provided by colleagues active in ITU-T, I am =20 > not an ITU-T geek myself) the cost of participating as an associate =20 > in ITU-T is CHF10600 (~USD10000) per year. > http://www.itu.int/members/associates/fees.html =20 > > The limitations with being an associate is found at > http://www.itu.int/members/associates/rights.html =20 > > I am interested to know what the specific problems was or are, is it =20 > the cost or the lack of voting rights or a combination ?. If I =20 > understand it right one cannot vote directly as an associate but =20 > there are possibilities to go via the national body. > > BR > /Ingemar > > > > ________________________________ > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > Skickat: ti 2009-11-10 12:38 > Till: Ingemar Johansson S; codec@ietf.org > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > Dear Ingemar, > > I have personally approached ITU on behalf of Global IP Solutions (at > that time Global IP Sound), back in 2001/2002, with respect to > standardization of iLBC.You can imagine the outcome. > I would not recommend to any of the authors of the current set of > codecs to consider that process. > This question has been brought up at the last meeting in Stockholm and > I suppose the conclusion was obvious. > > Best regards, > alan > > Alan Duric > CTO and Cofounder > Telio Holding ASA | Oslo exchange: TELIO > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > >> Hi >> >> I am curious to know to what extent proponents of a Codec WG in IETF >> has approached ITU-T with a request to standardize a RF codec. >> >> As I understand it there is a possibility of free membership which >> of course means limited rights to vote, however if I get this part >> correct it is a possibility to get voting rights via a countrys >> standards body. There is a chance that I don't get these details >> right as I have not myself digged into the membership rules of ITU-T. >> >> Anyway, my question. Who has actively approached the ITU-T with this >> and what was he response ?. Also are there any meeting documents or >> other public info that documents this ? >> >> BR >> /Ingemar >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> INGEMAR JOHANSSON M.Sc. >> Senior Research Engineer >> >> Ericsson AB >> Multimedia Technologies >> Labratoriegr=E4nd 11 >> 971 28, Lule=E5, Sweden >> Phone +46-1071 43042 >> SMS/MMS +46-73 078 3289 >> ingemar.s.johansson@ericsson.com >> www.ericsson.com >> Visit http://labs.ericsson.com ! >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> 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 simao.campos@itu.int Tue Nov 10 05:51: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 269203A689F for ; Tue, 10 Nov 2009 05:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYxpG9uaMDnj for ; Tue, 10 Nov 2009 05:51:49 -0800 (PST) Received: from protext02.itu.ch (protext02.itu.ch [156.106.192.19]) by core3.amsl.com (Postfix) with ESMTP id E23483A67E1 for ; Tue, 10 Nov 2009 05:51:48 -0800 (PST) Received: from protext02.itu.ch ([156.106.192.19]) by protext02.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Nov 2009 14:52:14 +0100 Received: From PROTINT1.blue.itu.ch ([156.106.128.47]) by protext02.itu.ch (WebShield SMTP v4.5 MR3) id 1257861132843; Tue, 10 Nov 2009 14:52:12 +0100 Received: from MAILBOX1.blue.itu.ch ([156.106.130.106]) by PROTINT1.blue.itu.ch with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 14:52:12 +0100 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, 10 Nov 2009 14:52:09 +0100 Message-ID: <334A4109C6BEA14ABB48EBCF274A6C8A05539A42@MAILBOX1.blue.itu.ch> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: Acph+k5z9VDxFRx3Sj23paQmG1RdpwABri2zAAIhhnA= References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 10 Nov 2009 13:52:12.0648 (UTC) FILETIME=[01206E80:01CA620D] Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 13:51:51 -0000 Hi Alan and Ingemar Maybe Alan can refresh my memory but at the time I was the chairman of = WP3/16 (working for COMSAT Labs) and do not recall an official proposal = from GIPS to ITU (Note: currently I work for the ITU secretariat). Maybe = there were informal consultations, but alas as Ingemar mentions this was = eons ago and the landscape has changed tremendously. Concerning the issue of vote, I have never seen in 20 years of ITU = experience an instance of vote at a technical group meeting (such as = study groups and their sub-groups). ITU study groups move forward by = consensus, here usually meaning "lack of sustained opposition". Vote and = representation by "national bodies" is part of the ISO and IEC process. = Effectively, every one participating at a meeting has the opportunity to = fully express themselves, and points of view are fairly taken into = account. That's my experience, at least. I hope Yusuke's presentation tomorrow may clear up some of the = misunderstandings. Best regards, Simao -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Ingemar Johansson S Sent: 10 November 2009 13:47 To: Alan Duric; codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? Hi =20 What was the answer?, is there any documentation of this effort in the = ITU-T archives. I guess there should be. I am just trying to understand = the reality behind the general conception that it is difficult to = approach ITU-T and to be honest I cannot imagine what the outcome is or = was as I haven't tried it myself. 2000/2001 is quite a few moons ago an = then the word royalty free was real difficult to find on the map, is = there a chance that the attitude may have changed since, especially as a = result of the discussions in IETF ?. =20 What I can see (URL's provided by colleagues active in ITU-T, I am not = an ITU-T geek myself) the cost of participating as an associate in ITU-T = is CHF10600 (~USD10000) per year.=20 http://www.itu.int/members/associates/fees.html = =20 The limitations with being an associate is found at=20 http://www.itu.int/members/associates/rights.html = =20 I am interested to know what the specific problems was or are, is it the = cost or the lack of voting rights or a combination ?. If I understand it = right one cannot vote directly as an associate but there are = possibilities to go via the national body. =20 BR /Ingemar =20 =20 ________________________________ Fr=E5n: Alan Duric [mailto:alan@telio.no] Skickat: ti 2009-11-10 12:38 Till: Ingemar Johansson S; codec@ietf.org =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? Dear Ingemar, I have personally approached ITU on behalf of Global IP Solutions (at=20 that time Global IP Sound), back in 2001/2002, with respect to=20 standardization of iLBC.You can imagine the outcome. I would not recommend to any of the authors of the current set of=20 codecs to consider that process. This question has been brought up at the last meeting in Stockholm and=20 I suppose the conclusion was obvious. Best regards, alan Alan Duric CTO and Cofounder Telio Holding ASA | Oslo exchange: TELIO On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > Hi > > I am curious to know to what extent proponents of a Codec WG in IETF=20 > has approached ITU-T with a request to standardize a RF codec. > > As I understand it there is a possibility of free membership which=20 > of course means limited rights to vote, however if I get this part=20 > correct it is a possibility to get voting rights via a countrys=20 > standards body. There is a chance that I don't get these details=20 > right as I have not myself digged into the membership rules of ITU-T. > > Anyway, my question. Who has actively approached the ITU-T with this=20 > and what was he response ?. Also are there any meeting documents or=20 > other public info that documents this ? > > BR > /Ingemar > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > 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 Tue Nov 10 06:26: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 294733A6AC8 for ; Tue, 10 Nov 2009 06:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swvBnUpDqAY1 for ; Tue, 10 Nov 2009 06:26:19 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id B97893A67F0 for ; Tue, 10 Nov 2009 06:26:18 -0800 (PST) Received: by bwz23 with SMTP id 23so64375bwz.29 for ; Tue, 10 Nov 2009 06:26:43 -0800 (PST) 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=1occs8RbVmPj6OTxXET9fvvms/WUlrCZS8YkFgqCqFg=; b=dLcCUzrirxbt0TPmDIdMu9QRJnM3CbgPRK8jqdcw5FplAngRcYsVPCMulUJJZNN8fH 4kFzgNCviW7Bafx+z+k4sXK/u99OBql1rBkDmTMIJpU2IA3rkZcM0V2UP0sMdBWah9aj nhFs/iFLkHn7esgmjIJBvlsnk4yLRWwBV9068= 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=nnhJvL5QamaVADvuLR9OJX4BBzKPmwp8xX0wQ5X9g/cHsFQK49ftDRqNT2bMoPfUkp ujAp5ymsSszRyAFzpJmsQBYx+rIwBhzLxbu4MZ4hgiYqZdd4TrN6wmWePL1ta8iqQpcu jGHjOXuijTTYHDefo9n7HumOvBX4SA8XA6BtI= Received: by 10.204.175.83 with SMTP id w19mr164848bkz.24.1257863202639; Tue, 10 Nov 2009 06:26:42 -0800 (PST) Received: from windows8d787f9 (host-112-47.meeting.ietf.org [133.93.112.47]) by mx.google.com with ESMTPS id 14sm230815bwz.5.2009.11.10.06.26.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 06:26:41 -0800 (PST) From: "Roni Even" To: "'Alan Duric'" , "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> In-Reply-To: Date: Tue, 10 Nov 2009 23:25:34 +0900 Message-ID: <4af97821.0e1abc0a.46a3.1a4b@mx.google.com> 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: AcpiBgzykUose1a8RfmhMvUnqU+NMAACvZZw Content-Language: en-us Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 14:26:20 -0000 Alan, I think that there is a difference between standardizing a codec and standardizing iLBC, meaning coming to a group and saying I want to standardize my codec (rubber stamp). I do not believe that any standard = body including the IETF will welcome a request to make your specific codec a standard. I believe that the even the approach of the IETF if it decide = to standardize a codec is not to rubber stamp a codec. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Alan Duric > Sent: Tuesday, November 10, 2009 8:38 PM > To: Ingemar Johansson S; codec@ietf.org > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >=20 > Dear Ingemar, >=20 > I have personally approached ITU on behalf of Global IP Solutions (at > that time Global IP Sound), back in 2001/2002, with respect to > standardization of iLBC.You can imagine the outcome. > I would not recommend to any of the authors of the current set of > codecs to consider that process. > This question has been brought up at the last meeting in Stockholm and > I suppose the conclusion was obvious. >=20 > Best regards, > alan >=20 > Alan Duric > CTO and Cofounder > Telio Holding ASA | Oslo exchange: TELIO >=20 >=20 >=20 > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: >=20 > > Hi > > > > I am curious to know to what extent proponents of a Codec WG in IETF > > has approached ITU-T with a request to standardize a RF codec. > > > > As I understand it there is a possibility of free membership which > > of course means limited rights to vote, however if I get this part > > correct it is a possibility to get voting rights via a countrys > > standards body. There is a chance that I don't get these details > > right as I have not myself digged into the membership rules of = ITU-T. > > > > Anyway, my question. Who has actively approached the ITU-T with this > > and what was he response ?. Also are there any meeting documents or > > other public info that documents this ? > > > > BR > > /Ingemar > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > INGEMAR JOHANSSON M.Sc. > > Senior Research Engineer > > > > Ericsson AB > > Multimedia Technologies > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > 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 From mramalho@cisco.com Tue Nov 10 06:29: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 418793A6AC9 for ; Tue, 10 Nov 2009 06:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 pfwsE2WkZRV8 for ; Tue, 10 Nov 2009 06:29:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A232B3A6AC8 for ; Tue, 10 Nov 2009 06:29:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHsH+UpAZnwN/2dsb2JhbADGMJgUgi6CEASBaA X-IronPort-AV: E=Sophos;i="4.44,716,1249257600"; d="scan'208";a="67235838" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2009 14:29:50 +0000 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 nAAEToQM024814; Tue, 10 Nov 2009 14:29:50 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, 10 Nov 2009 09:29:50 -0500 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, 10 Nov 2009 09:29:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] questions to be answered Thread-Index: Acph3GDMaayJ0hg5RiuK9LG4azMdOwAMAcag References: From: "Michael Ramalho (mramalho)" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 10 Nov 2009 14:29:50.0188 (UTC) FILETIME=[42B9B2C0:01CA6212] Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 14:29:25 -0000 Comments in-line with "MAR:". Michael Ramalho -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Tuesday, November 10, 2009 3:04 AM To: codec@ietf.org Subject: Re: [codec] questions to be answered On Mon, 9 Nov 2009, Henry Sinnreich wrote: > Metrics and values/numbers would be very interesting if you can share=20 > them, to better understand the requirements. Also to make sure in what > usage scenarios they may occur. 2 seconds jitter and 10% continous random packet loss should definitely be=20 handled gracefully (during the tsunami where several fiber optic cables=20 were severed in asia, packet loss from the region to the rest of the world=20 was continous 5-7% due to remaining paths being extremely congested). 2=20 seconds is for multiple links in a row being full (typically Cisco 12000 routers can buffer 600ms of data when congestion occurs). There are=20 numerous cases (ADSL2+ without interleave, high speed links with CRC=20 errors, ethernet duplex errors) where random packet loss can be seen.=20 Typically this is less than 1%, otherwise people tend to fix the problem because TCP works very badly. MAR: Let's consider ... 10% RANDOM packet loss ... and ptime =3D 20ms. MAR: Probability of more than 2 consecutive losses (40ms conceal) is lower bounded at 1% (once every 2 seconds at 50 pps). MAR: Probability of more than 3 consecutive losses is bounded at .1% (once every 20 seconds). MAR: Probability of more than 4 consecutive losses is bounded at 0.01% (once every 200 seconds). MAR: Isolated packet losses are typically concealed well (even more so if they occur less often). MAR: A doublet loss (2 consecutive losses) are also typically concealed well for long lasting vowels (and silence). So these too are TYPICALLY concealed well - the exception being short lasting phonemes (such as a "t"). But in the example above, this loss event only happens once every 2 seconds - what is the probability of the 40ms loss coming during the short-lived phoneme? Still a very low occurrence. Maybe once every 5 minutes. MAR: Extend analysis for > 3+ consecutive RANDOM losses. MAR: Consecutive losses exceeding 200ms (10 consecutive losses) are almost guaranteed to lose significant phonetic content. Most people hear 200ms drops consistently. But the time between such events - assuming RANDOM LOSSES - is indeed very long (do the math ;-) )! MAR: Is there any wonder that even 10% RANDOM packet loss is still highly intelligible? No. But the key is the RANDOM (assuming i.i.d.) loss assumption. MAR: I assure you that i.i.d. random loss isn't the challenging case (assuming a good PLC). We then have the 3G/wifi network issue, where jitter can also be at least=20 2 seconds, plus packet loss as well (some networks seem to buffer X=20 kilobytes, some Y number of packets, after that they tail drop. I've seen=20 both behaviours). Burst loss, where when you have a network re-route, you might lose=20 typically 0.05 - 2 seconds of data, and you might get re-ordering during the convergence. Since this is a transient event, I don't think much can be done about it but try to play data as they come in and just ignore out=20 of order packets. Perhaps jitter buffer should be increased when=20 out-of-order packets is seen, but when things calm down again it needs to=20 be reduced again. MAR: OK .. now you jump from RANDOM loss to DROP OUTs. These occur during such things as route changes. Yes, you will typically hear these if they take more than about 100ms ~ 200ms to converge. If they occur once .. and then not again for > 4 minutes or so .. the listener forgets about them (just like bad cell phone reception). MAR: But you jumped from RANDOM LOSS to DROP OUTs - there is a vast middle ground where the characteristic of the losses ISN'T RANDOM. I (and others) usually use the term "burst loss" to cover these cases that are in between RANDOM losses and DROP OUTs. I've also seen networks which re-order packets constantly, I don't know=20 what the load-sharing algorithm used is, but I think the jitter buffer=20 size should be adapted and handle out of order packets so they're=20 presented to the codec correctly. When running voice over GSM GPRS, typically there is very low bandwidth=20 and high delay. Here bw should be kept as low as possible and the IP=20 header is a big overhead and pps should thus be kept at a minimum, for=20 instance 3-5 pps and the very lowest quality setting should be used. So, the SYSTEM (I'm not just talking codec here), as far as I can see it,=20 needs to gracefully handle at least 10% packet loss, out of order packets=20 (analyse the time they might be re-ordered and adapt jitter buffer=20 accordingly), or just plain jitter up to 2s. MAR: This cannot be your conclusion EXCEPT if the 10% loss is nearer to a i.i.d. random distribution than to any particularly (auditorially nasty) burst characteristic. MAR: As an aside, another person responding to this thread (not you) talked about wireless (e.g., 802.11) characteristics. Well they can have auditorially nasty burst loss characteristics when the endpoint is nearly out-of-range. Layer 2 tries to get the VoIP packet across, but "gives up" after a while ... it does this consistently because it is nearly out-of-range ... and it gets some across. MAR: The bottom line for anyone still reading is IF the loss event WIPES OUT a particular phoneme completely (the "t" example above) NO AMOUNT OF REAL-TIME CODEC MAGIC PIXIE DUST can resurrect the phoneme. The only way around this is to add redundant information in other packets and to trade off delay. [I say real-time .. because you can run ASR and guess what phoneme(s) was/were missing ... and then insert it .. but that isn't a real time activity. I digress once again .. sorry about that.] My reasoning here is mainly focused on voice over Internet, but as far as=20 I can see this applies to all sound, even though if it's not interactive I=20 guess the focus can be switched from low latency (it might be better for a=20 voice call to have lower latency than actually getting perfect sound) to reliable sound delivery with higher latency (by increasing jitter buffer and putting sound information in multiple packets so that single packet=20 loss doesn't mean silence in that interval). MAR: If you don't include redundant information so that you can recover "missing content", I don't agree with your conclusion. MAR: All of this points to Henry's request. Please bound the problem. I (for one) are really tired of people talking about the codec handling X% RANDOM packet loss. VoIP streams will typically (assuming good PLC) be highly intelligible until the probability of > 1 consecutive loss becomes significant (up to about 20% ... again ... do the math at your ptime to find out). Basically I'd like to see=20 that as soon as jitter buffer is increased, the resiliancy to packet loss=20 should be increased as well by telling the other end that it can start to=20 do packet loss concealment information in the packets as well (whatever=20 it's called, I'm not a codec guy). If sender knows what the receiver=20 jitter buffer is, then this can be used to increase resiliency (I guess). Does this help? MAR: Anyone still listening can flame ... but please disprove the analysis before you do so. Thanks in advance. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Tue Nov 10 06:31: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 BB0843A6AC9 for ; Tue, 10 Nov 2009 06:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PEHVKbn7SHJY for ; Tue, 10 Nov 2009 06:31:35 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 168473A6AE0 for ; Tue, 10 Nov 2009 06:31:34 -0800 (PST) Received: by fxm7 with SMTP id 7so69657fxm.29 for ; Tue, 10 Nov 2009 06:31:59 -0800 (PST) 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=M5BhWSX8f/eQGemAq7aHLIOfnRV7TzEpuGGLzwSdhKM=; b=JaF3nO4+zW7PjzdWxlWO57U6K01Pi4pBwPzcuI0gU7ptWyLduGHKZcmATqeabd4vVw DuYg8ELdI+kjFW0IaavAAfL98f+wuGFZmBKN3hk2L7cskUFZejwIQOJz50UtyZhn/11E ArYwVEZ28hOCBfbvgXlExjoLbeAADEPAWT4p8= 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=gVBsmW2IJbCJJf9MFKnPtIDMeyKP2TRi5qhYv5m38wdL7JPuxuHKVaArc9wQEfXmyA R6jg/zY0KiTXRGVz+0+q8D+P/M12WzkuYUZYCfMC59XliRnyp/2gtPIeVDZna9pdYZXq vEhbZ0F1RHKPKvTJ6i78e/eRN14WDLtbvE9lk= Received: by 10.204.152.27 with SMTP id e27mr111920bkw.192.1257863519124; Tue, 10 Nov 2009 06:31:59 -0800 (PST) Received: from windows8d787f9 (host-112-47.meeting.ietf.org [133.93.112.47]) by mx.google.com with ESMTPS id 13sm232361bwz.10.2009.11.10.06.31.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 06:31:58 -0800 (PST) From: "Roni Even" To: "'Koen Vos'" , "'Ingemar Johansson S'" References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> <20091110052641.34281f6075r5cowh@mail.skype.net> In-Reply-To: <20091110052641.34281f6075r5cowh@mail.skype.net> Date: Tue, 10 Nov 2009 23:30:51 +0900 Message-ID: <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> 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: AcpiCXm6NaA44/ZES02a8HjaaapWMgACFGfQ Content-Language: en-us Cc: 'Alan Duric' , codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 14:31:36 -0000 Hi, Inline Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Tuesday, November 10, 2009 10:27 PM > To: Ingemar Johansson S > Cc: Alan Duric; codec@ietf.org > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >=20 > The ITU liaison stated that their policy requires royalty free (RF) or > reasonable and non-discriminatory terms (RAND) for their standards. In > practice that means that anyone can add IP to the standard as long as > it brings a small improvement. Roni: this is not the ITU process, if a candidate was selected based on selection, than another party do not add to it. If collaboration take = place than the parties in the collaboration need to agree what will be in a = codec. >=20 > Unfortunately, that means their policy is incompatible with that of > the IETF. They were fully aware of that when writing the liaison, yet > didn't indicate a willingness to abandon their position. >=20 > ITU liaison: > https://datatracker.ietf.org/documents/LIAISON/file662.doc >=20 > koen. >=20 >=20 > Quoting Ingemar Johansson S: > > Hi > > > > What was the answer?, is there any documentation of this effort in > > the ITU-T archives. I guess there should be. I am just trying to > > understand the reality behind the general conception that it is > > difficult to approach ITU-T and to be honest I cannot imagine what > > the outcome is or was as I haven't tried it myself. 2000/2001 is > > quite a few moons ago an then the word royalty free was real > > difficult to find on the map, is there a chance that the attitude > > may have changed since, especially as a result of the discussions in > > IETF ?. > > > > What I can see (URL's provided by colleagues active in ITU-T, I am > > not an ITU-T geek myself) the cost of participating as an associate > > in ITU-T is CHF10600 (~USD10000) per year. > > http://www.itu.int/members/associates/fees.html > > > > The limitations with being an associate is found at > > http://www.itu.int/members/associates/rights.html > > > > I am interested to know what the specific problems was or are, is it > > the cost or the lack of voting rights or a combination ?. If I > > understand it right one cannot vote directly as an associate but > > there are possibilities to go via the national body. > > > > BR > > /Ingemar > > > > > > > > ________________________________ > > > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > > Skickat: ti 2009-11-10 12:38 > > Till: Ingemar Johansson S; codec@ietf.org > > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > > > > > Dear Ingemar, > > > > I have personally approached ITU on behalf of Global IP Solutions = (at > > that time Global IP Sound), back in 2001/2002, with respect to > > standardization of iLBC.You can imagine the outcome. > > I would not recommend to any of the authors of the current set of > > codecs to consider that process. > > This question has been brought up at the last meeting in Stockholm > and > > I suppose the conclusion was obvious. > > > > Best regards, > > alan > > > > Alan Duric > > CTO and Cofounder > > Telio Holding ASA | Oslo exchange: TELIO > > > > > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > > > >> Hi > >> > >> I am curious to know to what extent proponents of a Codec WG in = IETF > >> has approached ITU-T with a request to standardize a RF codec. > >> > >> As I understand it there is a possibility of free membership which > >> of course means limited rights to vote, however if I get this part > >> correct it is a possibility to get voting rights via a countrys > >> standards body. There is a chance that I don't get these details > >> right as I have not myself digged into the membership rules of ITU- > T. > >> > >> Anyway, my question. Who has actively approached the ITU-T with = this > >> and what was he response ?. Also are there any meeting documents or > >> other public info that documents this ? > >> > >> BR > >> /Ingemar > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >> INGEMAR JOHANSSON M.Sc. > >> Senior Research Engineer > >> > >> Ericsson AB > >> Multimedia Technologies > >> Labratoriegr=E4nd 11 > >> 971 28, Lule=E5, Sweden > >> Phone +46-1071 43042 > >> SMS/MMS +46-73 078 3289 > >> ingemar.s.johansson@ericsson.com > >> www.ericsson.com > >> Visit http://labs.ericsson.com ! > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >> _______________________________________________ > >> 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 From gmaxwell@juniper.net Tue Nov 10 06:48: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 D77B128C1E3 for ; Tue, 10 Nov 2009 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5MByzH6EMYUQ for ; Tue, 10 Nov 2009 06:48:59 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id E4FB528C1C2 for ; Tue, 10 Nov 2009 06:48:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSvl9dU9Q5MixyYmcfjPCFH5hkHw6ntSK@postini.com; Tue, 10 Nov 2009 06:49:26 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 10 Nov 2009 06:45:43 -0800 From: Gregory Maxwell To: "codec@ietf.org" Date: Tue, 10 Nov 2009 06:45:42 -0800 Thread-Topic: Transparency or intelligibility? Thread-Index: AQHKYhR6PzU0AKhjpU26DD37PS5ZAA== Message-ID: 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: [codec] Transparency or intelligibility? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 14:48:59 -0000 One source of disagreement over requirements which I've seen crop up with r= espect to audio codecs arises out of what appears to be a lack of agreement on the end goal= : Is the expectation=20 that the result will be transparent, or that it will be merely intelligible= and/or 'good sounding'? By transparent I mean something roughly like "an experienced listener is un= able to distinguish in a blind listening test even with material selected to be especially challengi= ng for the codec". While it's is not possible to deliver transparency without intelligibility,= it is possible to deliver excellent intelligibility without a hope of transparency. So optimizing for one vs = the other can lead to different engineering trade-offs. For example, a 7kHz low-pass will produce speech with perfect intelligibil= ity but at the same time would have absolutely no hope of being transparent. If you had a goal of e= ven near transparency you would probably not even consider a codec with a low-pass lower than abo= ut 18kHz or so. (For general audio=97 for pure speech and adult listeners you could possibl= y go a bit lower but 7kHz is far too low) It was my thought that for the transmission of sound typical Internet bandw= idths are high enough that we really have little excuse but to provide transparency under good operati= ng conditions. Of course, during levels of high loss or congestion transparency will not b= e possible and in that case a codec should maintain intelligibility under adverse conditions and that s= hould be an absolute requirement too, but in the normal case transparency should be expected. Is this thinking consistent with the thoughts of other working group partic= ipants? From gregory.ietf@gmail.com Tue Nov 10 07:08: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 406E728C137 for ; Tue, 10 Nov 2009 07:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, 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 nPWlwogK1m8v for ; Tue, 10 Nov 2009 07:08:29 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id B324628C134 for ; Tue, 10 Nov 2009 07:08:28 -0800 (PST) Received: by fxm7 with SMTP id 7so110041fxm.29 for ; Tue, 10 Nov 2009 07:08:51 -0800 (PST) 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 :content-transfer-encoding; bh=5UMBy4aTO5sXiIvB7aDAu757RVYPKe6LNth9Rp6u0+I=; b=iQOHvt2rjJ2p3w37WiRBvTvcX3WydCQ7D43/savvnvep9+PV271UH2SVPIYvwg6ocX xSJOUAyFqIIeDwdvQgKQNHnREj4ASBQlbSWDjoVvqBa6qDjzAkhh2yr6XeNQVdlIX4iA SZFmBMK2WI83XZ5iFDbOyN/8tIn6+Fuxw3Xxs= 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:content-transfer-encoding; b=oZFFzfI1y0pDHDLkCfH2DBhqa+utGl51x3xko8uGaiC743QSGb7R3J3lM7OL32hviG x8/yqzlrJxooF0PpyqZtDT34Cw3YLFbn5D9GWeMtBUUMH7zEAREWfRSaRLuIbHWgGaPV w4QUaW2gEEn4btj/9LUW3+qrjgIN6lpXbW84I= Received: by 10.204.152.27 with SMTP id e27mr156621bkw.192.1257865730902; Tue, 10 Nov 2009 07:08:50 -0800 (PST) Received: from Gregory-T60.gmail.com (host-112-179.meeting.ietf.org [133.93.112.179]) by mx.google.com with ESMTPS id 15sm241335bwz.12.2009.11.10.07.08.48 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 07:08:49 -0800 (PST) Message-ID: <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Nov 2009 07:08:42 -0800 To: "Roni Even" From: "Gregory M. Lebovitz" In-Reply-To: <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> <20091110052641.34281f6075r5cowh@mail.skype.net> <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 15:08:30 -0000 At 06:30 AM 11/10/2009, Roni Even wrote: >Hi, >Inline >Roni Even > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Koen Vos > > Sent: Tuesday, November 10, 2009 10:27 PM > > To: Ingemar Johansson S > > Cc: Alan Duric; codec@ietf.org > > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > The ITU liaison stated that their policy requires royalty free (RF) or > > reasonable and non-discriminatory terms (RAND) for their standards. In > > practice that means that anyone can add IP to the standard as long as > > it brings a small improvement. > > >Roni: this is not the ITU process, if a candidate was selected based on >selection, than another party do not add to it. If collaboration take place >than the parties in the collaboration need to agree what will be in a= codec. Is this a key area of difference of process between the IETF and ITU-T: - In the IETF there is most commonly all=20 parties working together to produce something,=20 openly adding their respective insights, and I.P.=20 (with associated IPR statements), into one thing. - In SG16 multiple parties of one, or a small=20 number of people, each submit a candidate codec,=20 those codecs are compared and evaluated=20 technically, and then advanced with the=20 characterizations to the voting members who then=20 consider many factors, including I.P.R. and chose one winner? This "pick the single best" vs "add the best=20 components into one" is a big difference in the=20 way the two SDO's go about this process, where=20 ITU-T matches the former terse summary, and IETF matches the latter. Comments on that observation? Gregory. > > > > Unfortunately, that means their policy is incompatible with that of > > the IETF. They were fully aware of that when writing the liaison, yet > > didn't indicate a willingness to abandon their position. > > > > ITU liaison: > > https://datatracker.ietf.org/documents/LIAISON/file662.doc > > > > koen. > > > > > > Quoting Ingemar Johansson S: > > > Hi > > > > > > What was the answer?, is there any documentation of this effort in > > > the ITU-T archives. I guess there should be. I am just trying to > > > understand the reality behind the general conception that it is > > > difficult to approach ITU-T and to be honest I cannot imagine what > > > the outcome is or was as I haven't tried it myself. 2000/2001 is > > > quite a few moons ago an then the word royalty free was real > > > difficult to find on the map, is there a chance that the attitude > > > may have changed since, especially as a result of the discussions in > > > IETF ?. > > > > > > What I can see (URL's provided by colleagues active in ITU-T, I am > > > not an ITU-T geek myself) the cost of participating as an associate > > > in ITU-T is CHF10600 (~USD10000) per year. > > > http://www.itu.int/members/associates/fees.html > > > > > > The limitations with being an associate is found at > > > http://www.itu.int/members/associates/rights.html > > > > > > I am interested to know what the specific problems was or are, is it > > > the cost or the lack of voting rights or a combination ?. If I > > > understand it right one cannot vote directly as an associate but > > > there are possibilities to go via the national body. > > > > > > BR > > > /Ingemar > > > > > > > > > > > > ________________________________ > > > > > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > > > Skickat: ti 2009-11-10 12:38 > > > Till: Ingemar Johansson S; codec@ietf.org > > > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > > > > > > > > > Dear Ingemar, > > > > > > I have personally approached ITU on behalf of Global IP Solutions (at > > > that time Global IP Sound), back in 2001/2002, with respect to > > > standardization of iLBC.You can imagine the outcome. > > > I would not recommend to any of the authors of the current set of > > > codecs to consider that process. > > > This question has been brought up at the last meeting in Stockholm > > and > > > I suppose the conclusion was obvious. > > > > > > Best regards, > > > alan > > > > > > Alan Duric > > > CTO and Cofounder > > > Telio Holding ASA | Oslo exchange: TELIO > > > > > > > > > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > > > > > >> Hi > > >> > > >> I am curious to know to what extent proponents of a Codec WG in IETF > > >> has approached ITU-T with a request to standardize a RF codec. > > >> > > >> As I understand it there is a possibility of free membership which > > >> of course means limited rights to vote, however if I get this part > > >> correct it is a possibility to get voting rights via a countrys > > >> standards body. There is a chance that I don't get these details > > >> right as I have not myself digged into the membership rules of ITU- > > T. > > >> > > >> Anyway, my question. Who has actively approached the ITU-T with this > > >> and what was he response ?. Also are there any meeting documents or > > >> other public info that documents this ? > > >> > > >> BR > > >> /Ingemar > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> INGEMAR JOHANSSON M.Sc. > > >> Senior Research Engineer > > >> > > >> Ericsson AB > > >> Multimedia Technologies > > >> Labratoriegr=E4nd 11 > > >> 971 28, Lule=E5, Sweden > > >> Phone +46-1071 43042 > > >> SMS/MMS +46-73 078 3289 > > >> ingemar.s.johansson@ericsson.com > > >> www.ericsson.com > > >> Visit http://labs.ericsson.com ! > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> _______________________________________________ > > >> 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 gmaxwell@juniper.net Tue Nov 10 07:12: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 9CF2628C1AF for ; Tue, 10 Nov 2009 07:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 lCY2M+b6wmLb for ; Tue, 10 Nov 2009 07:12:20 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 4C88328C196 for ; Tue, 10 Nov 2009 07:12:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSvmC7YVmOOOQY7pGKFXV5Nzhft7asuu3@postini.com; Tue, 10 Nov 2009 07:12:48 PST 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; Tue, 10 Nov 2009 07:07:17 -0800 From: Gregory Maxwell To: Henry Sinnreich , Peter Saint-Andre , "codec@ietf.org" Date: Tue, 10 Nov 2009 07:07:16 -0800 Thread-Topic: [codec] proposed charter Thread-Index: AcpIRdIwtMUlpM9DS5exTbP1Jeg8VQAHUyrbBmxv1eM= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] proposed 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: Tue, 10 Nov 2009 15:12:21 -0000 Behalf Of Henry Sinnreich [hsinnrei@adobe.com] wrote: > Also the reference to packet loss in the Internet opens a can of worms, s= ince broadband > networks don=92t really suffer from sizable random packet loss, but may s= uffer from packet > burst loss (such as producing voice clipping) due to congestion or route = flapping for which > no codec can expected to be tolerant or immune. The public internet very much suffers from random packet loss. Best practices queue management has people using random-early-discard, and = as far as I can tell no one of significance is placing VoIP traffic transiting from other p= eople's networks into a special high priority queue, so even when there is no significant congestio= n. This isn't a high level of loss, but it is a constant reality so we ought to expect it to be = well handled, and handling it well is very much a property of the codec. Congestion and broken links are also a reality, especially when you conside= r internetworks.=20 Anecdotally=97 Wednesday, Thursday, and Friday of last week I was seeing a = random loss of 4-6% between my home and my office (which are less than two miles apart, bu= t three providers apart). Today, and most of the rest of the time it is fine. Although not an issue for me, many end users have significant bandwidth bo= ttlenecks at the first hop out of their local network. If you have a 128Kbit/sec upstream c= ap then any kind of file upload is going to cause loss=97 absent some QoS configuration which s= till does not generally exist even though it has been justified for years. =20 Burst losses, as you say, are much harder to do anything useful with... and= are often more an exercise in jitter buffer performance than codec performance.=20 =20 I have a pair of small computers with GPS disciplined oscillators and some = software I wrote that sends out nanosecond timestamped and sequenced numbered packets. If people= can suggest types of network paths they'd like to see data more solid than anecdotes, I= 'd be glad to send it out and collect traces. From herve.taddei@huawei.com Tue Nov 10 08: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 D62793A6A05 for ; Tue, 10 Nov 2009 08:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhiU3AGRcKqN for ; Tue, 10 Nov 2009 08:10:57 -0800 (PST) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id 25C343A6AD8 for ; Tue, 10 Nov 2009 08:10:57 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSW00ECRIAZU1@lhrga03-in.huawei.com> for codec@ietf.org; Tue, 10 Nov 2009 16:11:23 +0000 (GMT) Received: from PCHERVE ([217.167.116.133]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSW006DNIAY3Z@lhrga03-in.huawei.com> for codec@ietf.org; Tue, 10 Nov 2009 16:11:23 +0000 (GMT) Date: Tue, 10 Nov 2009 17:11:20 +0100 From: Herve Taddei In-reply-to: <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> To: "'Gregory M. Lebovitz'" , 'Roni Even' Message-id: <003c01ca6220$711382a0$8574a7d9@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: AcpiF85lBexBZrgDTDOOFk0vb7ahyQAA876g References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> <20091110052641.34281f6075r5cowh@mail.skype.net> <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 16:11:00 -0000 As a clarification to the ITU-T process, we have different ways of = working depending on how the group wants to see the work progressing. For = example, ITU-T G.718 was developed having a baseline selection phase, then many companies agreed to work on that baseline and to improve it. I think = about 14 companies indicated their wish to contribute and the codec was = finally standardized. So you cannot really say that the ways of working are so different, what you call "add the best components into one" has been = done in ITU-T.=20 I have never seen any voting in ITU-T, but perhaps I am not old enough. = When there is consensus on the floor, the work progresses to the next phase, there is no vote. There is no humming either, but all companies can = express their opinion. Best regards, Herv=E9 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Gregory M. Lebovitz > Sent: Tuesday, November 10, 2009 4:09 PM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >=20 > At 06:30 AM 11/10/2009, Roni Even wrote: > >Hi, > >Inline > >Roni Even > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf > > > Of Koen Vos > > > Sent: Tuesday, November 10, 2009 10:27 PM > > > To: Ingemar Johansson S > > > Cc: Alan Duric; codec@ietf.org > > > Subject: Re: [codec] Standardization in ITU-T, what are the issues = ? > > > > > > The ITU liaison stated that their policy requires royalty free = (RF) or > > > reasonable and non-discriminatory terms (RAND) for their = standards. In > > > practice that means that anyone can add IP to the standard as long = as > > > it brings a small improvement. > > > > > >Roni: this is not the ITU process, if a candidate was selected based = on > >selection, than another party do not add to it. If collaboration take place > >than the parties in the collaboration need to agree what will be in a codec. >=20 > Is this a key area of difference of process between the IETF and = ITU-T: > - In the IETF there is most commonly all > parties working together to produce something, > openly adding their respective insights, and I.P. > (with associated IPR statements), into one thing. > - In SG16 multiple parties of one, or a small > number of people, each submit a candidate codec, > those codecs are compared and evaluated > technically, and then advanced with the > characterizations to the voting members who then > consider many factors, including I.P.R. and chose one winner? >=20 > This "pick the single best" vs "add the best > components into one" is a big difference in the > way the two SDO's go about this process, where > ITU-T matches the former terse summary, and IETF matches the latter. >=20 > Comments on that observation? >=20 > Gregory. >=20 >=20 > > > > > > Unfortunately, that means their policy is incompatible with that = of > > > the IETF. They were fully aware of that when writing the liaison, = yet > > > didn't indicate a willingness to abandon their position. > > > > > > ITU liaison: > > > https://datatracker.ietf.org/documents/LIAISON/file662.doc > > > > > > koen. > > > > > > > > > Quoting Ingemar Johansson S: > > > > Hi > > > > > > > > What was the answer?, is there any documentation of this effort = in > > > > the ITU-T archives. I guess there should be. I am just trying to > > > > understand the reality behind the general conception that it is > > > > difficult to approach ITU-T and to be honest I cannot imagine = what > > > > the outcome is or was as I haven't tried it myself. 2000/2001 is > > > > quite a few moons ago an then the word royalty free was real > > > > difficult to find on the map, is there a chance that the = attitude > > > > may have changed since, especially as a result of the = discussions in > > > > IETF ?. > > > > > > > > What I can see (URL's provided by colleagues active in ITU-T, I = am > > > > not an ITU-T geek myself) the cost of participating as an = associate > > > > in ITU-T is CHF10600 (~USD10000) per year. > > > > http://www.itu.int/members/associates/fees.html > > > > > > > > The limitations with being an associate is found at > > > > http://www.itu.int/members/associates/rights.html > > > > > > > > I am interested to know what the specific problems was or are, = is it > > > > the cost or the lack of voting rights or a combination ?. If I > > > > understand it right one cannot vote directly as an associate but > > > > there are possibilities to go via the national body. > > > > > > > > BR > > > > /Ingemar > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > > > > Skickat: ti 2009-11-10 12:38 > > > > Till: Ingemar Johansson S; codec@ietf.org > > > > =C4mne: Re: [codec] Standardization in ITU-T, what are the = issues ? > > > > > > > > > > > > > > > > Dear Ingemar, > > > > > > > > I have personally approached ITU on behalf of Global IP = Solutions (at > > > > that time Global IP Sound), back in 2001/2002, with respect to > > > > standardization of iLBC.You can imagine the outcome. > > > > I would not recommend to any of the authors of the current set = of > > > > codecs to consider that process. > > > > This question has been brought up at the last meeting in = Stockholm > > > and > > > > I suppose the conclusion was obvious. > > > > > > > > Best regards, > > > > alan > > > > > > > > Alan Duric > > > > CTO and Cofounder > > > > Telio Holding ASA | Oslo exchange: TELIO > > > > > > > > > > > > > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > > > > > > > >> Hi > > > >> > > > >> I am curious to know to what extent proponents of a Codec WG in IETF > > > >> has approached ITU-T with a request to standardize a RF codec. > > > >> > > > >> As I understand it there is a possibility of free membership = which > > > >> of course means limited rights to vote, however if I get this = part > > > >> correct it is a possibility to get voting rights via a countrys > > > >> standards body. There is a chance that I don't get these = details > > > >> right as I have not myself digged into the membership rules of = ITU- > > > T. > > > >> > > > >> Anyway, my question. Who has actively approached the ITU-T with this > > > >> and what was he response ?. Also are there any meeting = documents or > > > >> other public info that documents this ? > > > >> > > > >> BR > > > >> /Ingemar > > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >> INGEMAR JOHANSSON M.Sc. > > > >> Senior Research Engineer > > > >> > > > >> Ericsson AB > > > >> Multimedia Technologies > > > >> Labratoriegr=E4nd 11 > > > >> 971 28, Lule=E5, Sweden > > > >> Phone +46-1071 43042 > > > >> SMS/MMS +46-73 078 3289 > > > >> ingemar.s.johansson@ericsson.com > > > >> www.ericsson.com > > > >> Visit http://labs.ericsson.com ! > > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >> _______________________________________________ > > > >> 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 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From swmike@swm.pp.se Tue Nov 10 08:15: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 ECC2B3A688B for ; Tue, 10 Nov 2009 08:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1lVm5c04A7a6 for ; Tue, 10 Nov 2009 08:15:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id E24DF3A6821 for ; Tue, 10 Nov 2009 08:15:55 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9F1069C; Tue, 10 Nov 2009 17:16:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9E38D9A; Tue, 10 Nov 2009 17:16:21 +0100 (CET) Date: Tue, 10 Nov 2009 17:16:21 +0100 (CET) From: Mikael Abrahamsson To: "Michael Ramalho (mramalho)" 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] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 16:15:58 -0000 On Tue, 10 Nov 2009, Michael Ramalho (mramalho) wrote: > Comments in-line with "MAR:". Please consider using the generally accepted "Internet style" way of citation outlined in: . > MAR: Isolated packet losses are typically concealed well (even more so > if they occur less often). Unless they cause crackling sound when this happens, so I guess it depends on the codec. I've had VOIP phone calls where it was very annoying. > MAR: But you jumped from RANDOM LOSS to DROP OUTs - there is a vast > middle ground where the characteristic of the losses ISN'T RANDOM. I > (and others) usually use the term "burst loss" to cover these cases that > are in between RANDOM losses and DROP OUTs. "jumped" sounds here like you're accusing me of being unstructured, or what are you trying to say? > REAL-TIME CODEC MAGIC PIXIE DUST can resurrect the phoneme. The only way > around this is to add redundant information in other packets and to > trade off delay. I thought I made this point numerous time in my email. What is the term to use so people like you understand that I want information regarding the audio spread out over several packets (interleaving?) so if some packet(s) are lost, at least some of the sound can be presented albeit at much lower quality? Every time jitter buffer is increased, I see no downside in using this technique to make the transfer of sound more robust? > and putting sound information in multiple packets so that single packet > loss doesn't mean silence in that interval). > > MAR: If you don't include redundant information so that you can recover > "missing content", I don't agree with your conclusion. As stated before, my meaning was exactly to include redundant/partial information in multiple packets. > MAR: Anyone still listening can flame ... but please disprove the > analysis before you do so. Thanks in advance. What is your suggestion as to what should be done? Do nothing at all? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Nov 10 08:20: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 3DB203A6B11 for ; Tue, 10 Nov 2009 08:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 mz7WkVBt9wy0 for ; Tue, 10 Nov 2009 08:20:10 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 68CF73A672E for ; Tue, 10 Nov 2009 08:20:10 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AD9659C; Tue, 10 Nov 2009 17:20:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AC4159A for ; Tue, 10 Nov 2009 17:20:36 +0100 (CET) Date: Tue, 10 Nov 2009 17:20:36 +0100 (CET) From: Mikael Abrahamsson To: "codec@ietf.org" 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; format=flowed; charset=US-ASCII Subject: Re: [codec] Transparency or intelligibility? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 16:20:11 -0000 On Tue, 10 Nov 2009, Gregory Maxwell wrote: > Is this thinking consistent with the thoughts of other working group > participants? I agree wholly that whatever we come up with should have excellent (transparent) sound quality when conditions are good, and should be able to be intelligible when conditions are really bad. I would like to have the application tell the system whether delay is important or not, if delay is not important then delay can be traded for higher sound quality, if delay is important then quality can be traded for intelligibility. -- Mikael Abrahamsson email: swmike@swm.pp.se From stephen.botzko@gmail.com Tue Nov 10 08:32: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 626B128C17B for ; Tue, 10 Nov 2009 08:32:16 -0800 (PST) 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 maDJSMkzFyjp for ; Tue, 10 Nov 2009 08:32:13 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 3DEBB28C15C for ; Tue, 10 Nov 2009 08:32:13 -0800 (PST) Received: by bwz23 with SMTP id 23so200426bwz.29 for ; Tue, 10 Nov 2009 08:32:35 -0800 (PST) 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=UAlCy10/lqTY9oQj6PKamKh4c6uR7Mkk+ZwtQhuSGY8=; b=pPVbwtzIO78Ej17df2V1mYggLw5gh8kiueiOSyOXGKkD6i9o7DaFf3tgGGtjzYjAwz w0SG3Gdnqn85zqVw/QZ7RVdQZZjHTFBjC4FqPWocNt+F3rBRTLeZ6S4b36edLzNVnLq9 gWghZcWBdXHy4hb5EGiqWHY/gn6dyFh2m2yMA= 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=Tq9sxGe5CHS5XNfF+SyTNxP5w89SZsQqyflk0wARPuCOPudzGCfAVACZ261eNLLtIn CU+AotNgyl/AFsx8ABzf3TLc59XqKTLynwsMVph3PwlW9MoeH1RyX0t0ZrDFoOnSaSEb ku4JZOcwKD5vgVFI+3hl2yHzwTOObgsCamqD0= MIME-Version: 1.0 Received: by 10.103.127.35 with SMTP id e35mr106533mun.106.1257870755628; Tue, 10 Nov 2009 08:32:35 -0800 (PST) In-Reply-To: <6e9223710911100831y21265bebr51c6d3fe954b5cdb@mail.gmail.com> References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> <20091110052641.34281f6075r5cowh@mail.skype.net> <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> <6e9223710911100831y21265bebr51c6d3fe954b5cdb@mail.gmail.com> Date: Tue, 10 Nov 2009 11:32:35 -0500 Message-ID: <6e9223710911100832g63c8c6e8l1ff800f8388e61ee@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e65c884c900833047806dbe5 Subject: [codec] Fwd: Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 16:32:16 -0000 --0016e65c884c900833047806dbe5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the ITU-T, the audio and video standardization (both SG16/WP3 activities= ) are done quite differently - the video standardization process is well described by your characterization of the IETF process. The ITU-T audio questions spend a lot of time researching and agreeing on specific requirements and objectives before they accept any codec candidates. Most of the meeting time is focused on this phase. In the meetings I have witnessed, the requirements/criteria for selection are clear enough that the selection process itself is not controversial - consensus is achieved without the need for voting. Regards Stephen Botzko On Tue, Nov 10, 2009 at 10:08 AM, Gregory M. Lebovitz < gregory.ietf@gmail.com> wrote: > At 06:30 AM 11/10/2009, Roni Even wrote: > >> Hi, >> Inline >> Roni Even >> >> > -----Original Message----- >> > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> > Of Koen Vos >> > Sent: Tuesday, November 10, 2009 10:27 PM >> > To: Ingemar Johansson S >> > Cc: Alan Duric; codec@ietf.org >> > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >> > >> > The ITU liaison stated that their policy requires royalty free (RF) or >> > reasonable and non-discriminatory terms (RAND) for their standards. In >> > practice that means that anyone can add IP to the standard as long as >> > it brings a small improvement. >> >> >> Roni: this is not the ITU process, if a candidate was selected based on >> selection, than another party do not add to it. If collaboration take >> place >> than the parties in the collaboration need to agree what will be in a >> codec. >> > > Is this a key area of difference of process between the IETF and ITU-T: > - In the IETF there is most commonly all parties working together to > produce something, openly adding their respective insights, and I.P. (wit= h > associated IPR statements), into one thing. > - In SG16 multiple parties of one, or a small number of people, each > submit a candidate codec, those codecs are compared and evaluated > technically, and then advanced with the characterizations to the voting > members who then consider many factors, including I.P.R. and chose one > winner? > > This "pick the single best" vs "add the best components into one" is a bi= g > difference in the way the two SDO's go about this process, where ITU-T > matches the former terse summary, and IETF matches the latter. > > Comments on that observation? > > Gregory. > > > > > >> > Unfortunately, that means their policy is incompatible with that of >> > the IETF. They were fully aware of that when writing the liaison, yet >> > didn't indicate a willingness to abandon their position. >> > >> > ITU liaison: >> > https://datatracker.ietf.org/documents/LIAISON/file662.doc >> > >> > koen. >> > >> > >> > Quoting Ingemar Johansson S: >> > > Hi >> > > >> > > What was the answer?, is there any documentation of this effort in >> > > the ITU-T archives. I guess there should be. I am just trying to >> > > understand the reality behind the general conception that it is >> > > difficult to approach ITU-T and to be honest I cannot imagine what >> > > the outcome is or was as I haven't tried it myself. 2000/2001 is >> > > quite a few moons ago an then the word royalty free was real >> > > difficult to find on the map, is there a chance that the attitude >> > > may have changed since, especially as a result of the discussions in >> > > IETF ?. >> > > >> > > What I can see (URL's provided by colleagues active in ITU-T, I am >> > > not an ITU-T geek myself) the cost of participating as an associate >> > > in ITU-T is CHF10600 (~USD10000) per year. >> > > http://www.itu.int/members/associates/fees.html >> > > >> > > The limitations with being an associate is found at >> > > http://www.itu.int/members/associates/rights.html >> > > >> > > I am interested to know what the specific problems was or are, is it >> > > the cost or the lack of voting rights or a combination ?. If I >> > > understand it right one cannot vote directly as an associate but >> > > there are possibilities to go via the national body. >> > > >> > > BR >> > > /Ingemar >> > > >> > > >> > > >> > > ________________________________ >> > > >> > > Fr=E5n: Alan Duric [mailto:alan@telio.no] >> > > Skickat: ti 2009-11-10 12:38 >> > > Till: Ingemar Johansson S; codec@ietf.org >> > > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? >> > > >> > > >> > > >> > > Dear Ingemar, >> > > >> > > I have personally approached ITU on behalf of Global IP Solutions (a= t >> > > that time Global IP Sound), back in 2001/2002, with respect to >> > > standardization of iLBC.You can imagine the outcome. >> > > I would not recommend to any of the authors of the current set of >> > > codecs to consider that process. >> > > This question has been brought up at the last meeting in Stockholm >> > and >> > > I suppose the conclusion was obvious. >> > > >> > > Best regards, >> > > alan >> > > >> > > Alan Duric >> > > CTO and Cofounder >> > > Telio Holding ASA | Oslo exchange: TELIO >> > > >> > > >> > > >> > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: >> > > >> > >> Hi >> > >> >> > >> I am curious to know to what extent proponents of a Codec WG in IET= F >> > >> has approached ITU-T with a request to standardize a RF codec. >> > >> >> > >> As I understand it there is a possibility of free membership which >> > >> of course means limited rights to vote, however if I get this part >> > >> correct it is a possibility to get voting rights via a countrys >> > >> standards body. There is a chance that I don't get these details >> > >> right as I have not myself digged into the membership rules of ITU- >> > T. >> > >> >> > >> Anyway, my question. Who has actively approached the ITU-T with thi= s >> > >> and what was he response ?. Also are there any meeting documents or >> > >> other public info that documents this ? >> > >> >> > >> BR >> > >> /Ingemar >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> INGEMAR JOHANSSON M.Sc. >> > >> Senior Research Engineer >> > >> >> > >> Ericsson AB >> > >> Multimedia Technologies >> > >> Labratoriegr=E4nd 11 >> > >> 971 28, Lule=E5, Sweden >> > >> Phone +46-1071 43042 >> > >> SMS/MMS +46-73 078 3289 >> > >> ingemar.s.johansson@ericsson.com >> > >> www.ericsson.com >> > >> Visit http://labs.ericsson.com ! >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> _______________________________________________ >> > >> 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 > --0016e65c884c900833047806dbe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the ITU-T, the audio and video standardiz= ation (both SG16/WP3 activities) are done quite differently - the video sta= ndardization process is well described by your characterization of the IETF= process.

The ITU-T audio questions spend a lot of time researching and agreeing = on specific requirements and objectives before they accept any codec candid= ates.=A0 Most of the meeting time is focused on this phase.=A0 In the meeti= ngs I have witnessed,=A0 the requirements/criteria for selection are clear = enough that the selection process itself is not controversial - consensus i= s achieved without the need for voting.=A0

Regards
Stephen Botzko


On Tue, Nov 10, 2009 = at 10:08 AM, Gregory M. Lebovitz <gregory.ietf@gmail.com> wrote:
At 06:30 AM = 11/10/2009, Roni Even wrote:
Hi,
Inline
Roni Even

> -----Original Message-----
> From: code= c-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
> Of Koen Vos
> Sent: Tuesday, November 10, 2009 10:27 PM
> To: Ingemar Johansson S
> Cc: Alan Duric; co= dec@ietf.org
> Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >
> The ITU liaison stated that their policy requires royalty free (RF) or=
> reasonable and non-discriminatory terms (RAND) for their standards. In=
> practice that means that anyone can add IP to the standard as long as<= br> > it brings a small improvement.


Roni: this is not the ITU process, if a candidate was selected based on
selection, than another party do not add to it. If collaboration take place=
than the parties in the collaboration need to agree what will be in a codec= .

Is this a key area of difference of process between the IETF and ITU-T:
=A0- In the IETF there is most commonly all parties working together to pr= oduce something, openly adding their respective insights, and I.P. (with as= sociated IPR statements), into one thing.
=A0- In SG16 multiple parties of one, or a small number of people, each su= bmit a candidate codec, those codecs are compared and evaluated technically= , and then advanced with the characterizations to the voting members who th= en consider many factors, including I.P.R. and chose one winner?

This "pick the single best" vs "add the best components into= one" is a big difference in the way the two SDO's go about this p= rocess, where ITU-T matches the former terse summary, and IETF matches the = latter.

Comments on that observation?

Gregory.



>
> Unfortunately, that means their policy is incompatible with that of > the IETF. They were fully aware of that when writing the liaison, yet<= br> > didn't indicate a willingness to abandon their position.
>
> ITU liaison:
> https://datatracker.ietf.org/documents/LIAISON/file662.d= oc
>
> koen.
>
>
> Quoting Ingemar Johansson S:
> > Hi
> >
> > What was the answer?, is there any documentation of this effort i= n
> > the ITU-T archives. I guess there should be. I am just trying to<= br> > > understand the reality behind the general conception that it is > > difficult to approach ITU-T and to be honest I cannot imagine wha= t
> > the outcome is or was as I haven't tried it myself. 2000/2001= is
> > quite a few moons ago an then the word royalty free was real
> > difficult to find on the map, is there a chance that the attitude=
> > may have changed since, especially as a result of the discussions= in
> > IETF ?.
> >
> > What I can see (URL's provided by colleagues active in ITU-T,= I am
> > not an ITU-T geek myself) the cost of participating as an associa= te
> > in ITU-T is CHF10600 (~USD10000) per year.
> > http://www.itu.int/members/associates/fees.html
> > <http://www.itu.int/members/associates/fees.html> > > The limitations with being an associate is found at
> > http://www.itu.int/members/associates/rights.html
> > <http://www.itu.int/members/associates/rights.html>= ;
> > I am interested to know what the specific problems was or are, is= it
> > the cost or the lack of voting rights or a combination ?. If I > > understand it right one cannot vote directly as an associate but<= br> > > there are possibilities to go via the national body.
> >
> > BR
> > /Ingemar
> >
> >
> >
> > ________________________________
> >
> > Fr=E5n: Alan Duric [mailto:alan@telio.no]
> > Skickat: ti 2009-11-10 12:38
> > Till: Ingemar Johansson S; codec@ietf.org
> > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues= ?
> >
> >
> >
> > Dear Ingemar,
> >
> > I have personally approached ITU on behalf of Global IP Solutions= (at
> > that time Global IP Sound), back in 2001/2002, with respect to > > standardization of iLBC.You can imagine the outcome.
> > I would not recommend to any of the authors of the current set of=
> > codecs to consider that process.
> > This question has been brought up at the last meeting in Stockhol= m
> and
> > I suppose the conclusion was obvious.
> >
> > Best regards,
> > alan
> >
> > Alan Duric
> > CTO and Cofounder
> > Telio Holding ASA | Oslo exchange: TELIO
> >
> >
> >
> > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote:
> >
> >> Hi
> >>
> >> I am curious to know to what extent proponents of a Codec WG = in IETF
> >> has approached ITU-T with a request to standardize a RF codec= .
> >>
> >> As I understand it there is a possibility of free membership = which
> >> of course means limited rights to vote, however if I get this= part
> >> correct it is a possibility to get voting rights via a countr= ys
> >> standards body. There is a chance that I don't get these = details
> >> right as I have not myself digged into the membership rules o= f ITU-
> T.
> >>
> >> Anyway, my question. Who has actively approached the ITU-T wi= th this
> >> and what was he response ?. Also are there any meeting docume= nts or
> >> other public info that documents this ?
> >>
> >> BR
> >> /Ingemar
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> INGEMAR JOHANSSON =A0M.Sc.
> >> Senior Research Engineer
> >>
> >> Ericsson AB
> >> Multimedia Technologies
> >> Labratoriegr=E4nd 11
> >> 971 28, Lule=E5, Sweden
> >> Phone +46-1071 43042
> >> SMS/MMS +46-73 078 3289
> >> ingemar.s.johansson@ericsson.com
> >> www.eri= csson.com
> >> Visit = http://labs.ericsson.com <http://labs.ericsson.com/> =A0!
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> _______________________________________________
> >> 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
> >
>
> _______________________________________________
> 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


--0016e65c884c900833047806dbe5-- From koen.vos@skype.net Tue Nov 10 08:37: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 5DB2C3A6B07 for ; Tue, 10 Nov 2009 08:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nsjEUZMq31IV for ; Tue, 10 Nov 2009 08:37:46 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 56EBA3A68D4 for ; Tue, 10 Nov 2009 08:37:46 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 6E10B60647BFB; Tue, 10 Nov 2009 16:38:13 +0000 (GMT) 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=1kOwsKfc1y1N NbuqS7OfrtK9HbM=; b=pj/ssTtyxeY+s31y3idp3jyFtKPXxxHoJpQdkuz1+p0X O8VTOPzE8dvCiK6IDwjEaxqDvEWvBwudoWCZU8TMAwCFDR5C8+71O1SIbNcSxlVr vgFOgpHjcsW1XLjn3cF/maWmG1IGEU9MYCcyGG9D0Bl+iyyH3wiwdN/m3TnCnGI= 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=BpNBKpbQCgH+Rf9VdmyP DNjUvqM7sm4bAdORzdbg/qB/4xUssZyVU8+fotOritPhNg9Zty+8XZXjdK3G41PK 5kF8gdgecJUkyPKWX1l9Ldp3gf6hX1NwhPsLKaTjL0f/rb8FJ5bQR/72joxIS3er hK8aMUN/kc3CYNObMoz0ebo= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 6C6DE60647BD4; Tue, 10 Nov 2009 16:38:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcrFVPOhVIyn; Tue, 10 Nov 2009 16:38:12 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id C3D3E60647BE3; Tue, 10 Nov 2009 16:38:12 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Tue, 10 Nov 2009 08:38:12 -0800 Message-ID: <20091110083812.47885wbfbxwaq584@mail.skype.net> Date: Tue, 10 Nov 2009 08:38:12 -0800 From: Koen Vos To: Mikael Abrahamsson References: 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) Cc: "codec@ietf.org" Subject: Re: [codec] Transparency or intelligibility? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 16:37:47 -0000 Quoting Mikael Abrahamsson: > I would like to have the application tell the system whether delay > is important or not, if delay is not important then delay can be > traded for higher sound quality, if delay is important then quality > can be traded for intelligibility. We're addressing a codec for real-time communications, so delay is important by definition. For applications where delay is not important, good solutions already exist - Ogg-Vorbis for example. There may be subtle trade-offs between delay and quality, e.g with network jitter, where additional jitter buffer delay can reduce the effective packet loss rate. That seems like a design choice for the jitter buffer however. koen. From mramalho@cisco.com Tue Nov 10 09:08: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 17F3F28C1F8 for ; Tue, 10 Nov 2009 09:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 F2l-LVu1O9k2 for ; Tue, 10 Nov 2009 09:08:24 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 45BC928C1F4 for ; Tue, 10 Nov 2009 09:08:24 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPss+UqrR7Ht/2dsb2JhbADGSZgohD4E X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208";a="268955113" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2009 17:08:51 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAH8obW010497; Tue, 10 Nov 2009 17:08:51 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); Tue, 10 Nov 2009 12:08:51 -0500 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, 10 Nov 2009 12:08:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] questions to be answered Thread-Index: AcpiISpJQz30b+GlSqu1tY+qpLKnvgABboVQ References: From: "Michael Ramalho (mramalho)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 10 Nov 2009 17:08:51.0185 (UTC) FILETIME=[799A4E10:01CA6228] Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 17:08:25 -0000 >> MAR: Isolated packet losses are typically concealed well (even more so=20 >> if they occur less often). >Unless they cause crackling sound when this happens, so I guess it depends=20 >on the codec. I've had VOIP phone calls where it was very annoying. Your issue could be the codec (for the case that it does it's own PLC) or the PLC. For reasonable ptimes (30ms or less), longer lived phonemes and isolated losses - shame on your system for generating annoying sounds. Sounds like you have a simple "repeat last frame" PLC. So circa 1970. ... >> MAR: Anyone still listening can flame ... but please disprove the=20 >> analysis before you do so. Thanks in advance. > >What is your suggestion as to what should be done? Do nothing at all? Quite the contrary, Mikael. I was simply trying to highlight two (highly interrelated) points: 1 - That the burst lost characteristic is an important criteria - designing for i.i.d. random losses where the losses are < 10% is relatively easy if your goal is intelligibility (not transparency). Again, shame on ANY 1990 ~ 2009 vintage codec for not concealing most ISOLATED losses without auditory detriment. 2 - That Henry's suggestion (to bound the problem, define metrics) is a good one. Subsequent emails have continued w.r.t. the intelligibility/transparency issue. Thanks for your commentary. I didn't mean to frustrate, but rather to enlighten. Michael Ramalho From stewe@stewe.org Tue Nov 10 12:06: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 8C5B43A6928 for ; Tue, 10 Nov 2009 12:06:59 -0800 (PST) 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, 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 tX+hC01w208q for ; Tue, 10 Nov 2009 12:06:58 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id E08DD3A6879 for ; Tue, 10 Nov 2009 12:06:55 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 484506-1743317 for multiple; Tue, 10 Nov 2009 21:07:22 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 05:07:09 +0900 From: Stephan Wenger To: Koen Vos , Ingemar Johansson S Message-ID: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: AcpiQWH/DRQ7wMSB1E+mlAHu3a5qug== In-Reply-To: <20091110052641.34281f6075r5cowh@mail.skype.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: Alan Duric , codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 20:06:59 -0000 Hi, On 11/10/09 10:26 PM, "Koen Vos" wrote: > The ITU liaison stated that their policy requires royalty free (RF) or > reasonable and non-discriminatory terms (RAND) for their standards. This is correct. > In =20 > practice that means that anyone can add IP to the standard as long as > it brings a small improvement. This is not necessarily correct; it depends on the culture of the technical group in question. Even in SG16, there are Questions where I personally ha= d a very hard time to bring in proposals that were encumbered, and had to sho= w much more than "small improvement" to get my stuff in---and favorable licensing terms on top of that. In contrast to what Alan Duric implied in a different email, the ITU has, i= n the past, be quite willing to "experiment" with attempts to define royalty free codecs. H.264 and its failed RF baseline project is one prominent example.=20 >=20 > Unfortunately, that means their policy is incompatible with that of > the IETF.=20 This sentence, when read in isolation, is undoubtly correct. However, when read in context, it creates a wrong impression. By their respective policy and guideline documents: 1. In the ITU, one has (as a minimum) to agree to RAND terms when working o= n a standard. In the IETF, there is no such requirement; it is perfectly OK by policy (and has happened again just a few days ago) to submit a disclosure without any licensing commitment, even after having influenced the setting of a standard. 2. Both ITU-T and the IETF have an expressed preference for unencumbered technologies in their respective policies and guideline documents. When reviewing only the policies and guideline documents, the ITU actually offers a slightly "better deal" towards users, compared to the IETF, when looking at licensing obligations only. It can do this because it has a membership concept (with all its advantages and disadvantages), whereas the IETF has not. This is IMO fairly well understood in the patents&standards community. I believe that what you are really betting on is to introduce a culture different from the one of the ITU and ETSI speech coding groups, by attempting to choose the IETF as a venue. Probably because you think your chance of success is higher. If successful, we are probably loosing a rather large part of the experts community which prefers to work in the mor= e established culture, for reasons that may include IPR greed but perhaps als= o the perceived knowledge that working in your culture would be a waste of their time. Please allow me to remind you that your attempt of forming an IETF codec WG with the culture you appear to imply has, and probably will continue, to meet opposition, as it would likely meet opposition in the ITU. You alread= y had to rephrase all of your requirements and draft charter documents to remove any reference to a hard requirement of RF licensing, in order to mak= e it compatible with the IETF policies. Do you think that people like me asked to do so without a reason? It may be that an RF requirement still exists in your head, but not in mine, and I'm perfectly entitled to play ball, just as you are. Regards, Stephan > They were fully aware of that when writing the liaison, yet > didn't indicate a willingness to abandon their position. >=20 > ITU liaison: > https://datatracker.ietf.org/documents/LIAISON/file662.doc >=20 > koen. >=20 >=20 > Quoting Ingemar Johansson S: >> Hi >>=20 >> What was the answer?, is there any documentation of this effort in >> the ITU-T archives. I guess there should be. I am just trying to >> understand the reality behind the general conception that it is >> difficult to approach ITU-T and to be honest I cannot imagine what >> the outcome is or was as I haven't tried it myself. 2000/2001 is >> quite a few moons ago an then the word royalty free was real >> difficult to find on the map, is there a chance that the attitude >> may have changed since, especially as a result of the discussions in >> IETF ?. >>=20 >> What I can see (URL's provided by colleagues active in ITU-T, I am >> not an ITU-T geek myself) the cost of participating as an associate >> in ITU-T is CHF10600 (~USD10000) per year. >> http://www.itu.int/members/associates/fees.html >> >> The limitations with being an associate is found at >> http://www.itu.int/members/associates/rights.html >> >> I am interested to know what the specific problems was or are, is it >> the cost or the lack of voting rights or a combination ?. If I >> understand it right one cannot vote directly as an associate but >> there are possibilities to go via the national body. >>=20 >> BR >> /Ingemar >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> Fr=E5n: Alan Duric [mailto:alan@telio.no] >> Skickat: ti 2009-11-10 12:38 >> Till: Ingemar Johansson S; codec@ietf.org >> =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? >>=20 >>=20 >>=20 >> Dear Ingemar, >>=20 >> I have personally approached ITU on behalf of Global IP Solutions (at >> that time Global IP Sound), back in 2001/2002, with respect to >> standardization of iLBC.You can imagine the outcome. >> I would not recommend to any of the authors of the current set of >> codecs to consider that process. >> This question has been brought up at the last meeting in Stockholm and >> I suppose the conclusion was obvious. >>=20 >> Best regards, >> alan >>=20 >> Alan Duric >> CTO and Cofounder >> Telio Holding ASA | Oslo exchange: TELIO >>=20 >>=20 >>=20 >> On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: >>=20 >>> Hi >>>=20 >>> I am curious to know to what extent proponents of a Codec WG in IETF >>> has approached ITU-T with a request to standardize a RF codec. >>>=20 >>> As I understand it there is a possibility of free membership which >>> of course means limited rights to vote, however if I get this part >>> correct it is a possibility to get voting rights via a countrys >>> standards body. There is a chance that I don't get these details >>> right as I have not myself digged into the membership rules of ITU-T. >>>=20 >>> Anyway, my question. Who has actively approached the ITU-T with this >>> and what was he response ?. Also are there any meeting documents or >>> other public info that documents this ? >>>=20 >>> BR >>> /Ingemar >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> INGEMAR JOHANSSON M.Sc. >>> Senior Research Engineer >>>=20 >>> Ericsson AB >>> Multimedia Technologies >>> Labratoriegr=E4nd 11 >>> 971 28, Lule=E5, Sweden >>> Phone +46-1071 43042 >>> SMS/MMS +46-73 078 3289 >>> ingemar.s.johansson@ericsson.com >>> www.ericsson.com >>> Visit http://labs.ericsson.com ! >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From bmschwar@fas.harvard.edu Tue Nov 10 12: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 4D0C53A68B4 for ; Tue, 10 Nov 2009 12:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 gyJL1J-Nj9Iy for ; Tue, 10 Nov 2009 12:42:02 -0800 (PST) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by core3.amsl.com (Postfix) with ESMTP id 72DD93A68AF for ; Tue, 10 Nov 2009 12:42:02 -0800 (PST) Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id 38AB74D5C75; Tue, 10 Nov 2009 15:42:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mail; bh=Sks0YHjVU4cKolLa/pjJUBpiv8ogNDLC237QrM6AGzw=; b=YiFP bwOmhNx8EFZ9hbmn0WvpRX+ONIsTSt2DPwpnzg8RPv96PcgQO+d5jgPaSHYabdKD wTPJ/+oPhvS5GZPGEbrzeEHygVouu/L4A/Qek95XTT1/IjNox/pDukhoCUj1cvEQ BhheHVVzH8As82f57VJcMJs3gz5lwtybh/hXbSY= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=mail; b=X9//vmaejhfPLcihy1lfga4Qo7svtp91h+ZGcmEruK9bJi favkot2N3z75C6S6fuI6XL1zjjuIk7KyoMaeLrEcEYAkWK5+HRQ1mGWbstxNNtik gNq3N9UyNDE1q01BOcv/TzYICAlcKU2OJZhVBfBnTlvdkSyjECWQ0QNHvYzAI= Received: from [172.23.141.114] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 336144D5BB7; Tue, 10 Nov 2009 15:42:27 -0500 (EST) Message-ID: <4AF9D032.3090507@fas.harvard.edu> Date: Tue, 10 Nov 2009 15:42:26 -0500 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu 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, 10 Nov 2009 20:42:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Wenger wrote: > Do you think that people like me > asked to do so without a reason? It may be that an RF requirement still > exists in your head, but not in mine, and I'm perfectly entitled to play > ball, just as you are. Thank you for your honesty regarding your intention to disregard whether our codec can be legally implemented in free software. Knowing this, I can make sure to oppose your technical suggestions until they have been vetted extensively for licensing issues. Culture is determined by the participants. I believe in the importance of free technology standards, and I intend to "play ball" as well. I am not alone. - --Ben Schwartz -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkr50DIACgkQUJT6e6HFtqS37wCgnWv8ts4/3NK8L+CdTB+e+Orm zVIAnR3kMCT7OQDQrcF6EQj+B5msaKNI =mvR7 -----END PGP SIGNATURE----- From fluffy@cisco.com Tue Nov 10 14:13: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 DCE513A696C for ; Tue, 10 Nov 2009 14:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 LuJmXKyy2CSw for ; Tue, 10 Nov 2009 14:13:41 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1C2763A6993 for ; Tue, 10 Nov 2009 14:13:40 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: ls-124.pdf, ls-124.doc : 33677, 45568 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADt0+UqrR7H+/2dsb2JhbADGPpg/hD4EgWh4 X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="pdf'?doc'32?scan'32,208,32";a="48874502" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 22:14:07 +0000 Received: from sjc-vpn4-883.cisco.com (sjc-vpn4-883.cisco.com [10.21.83.114]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAAME4MN024418 for ; Tue, 10 Nov 2009 22:14:04 GMT From: Cullen Jennings Content-Type: multipart/mixed; boundary=Apple-Mail-1-411169416 Date: Wed, 11 Nov 2009 07:14:03 +0900 References: <334A4109C6BEA14ABB48EBCF274A6C8A055399DF@MAILBOX1.blue.itu.ch> To: codec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 10 Nov 2009 22:13:42 -0000 --Apple-Mail-1-411169416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Begin forwarded message: > From: > Date: November 10, 2009 9:32:04 PM GMT+09:00 > To: > Cc: > Subject: FW: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 =20 > October - 6 November 2009) > > Dear all, > > please find attached a liaison statement sent from SG 16. I =20 > extracted the files from the ZIP since we had some difficulties with =20= > the server. > > Best regards, > Simao > > << ls-124.pdf >> > << ls-124.doc >> > > _____________________________________________ > From: TSBSG16, ITU [mailto:tsbsg16@itu.int] > Sent: 10 November 2009 10:57 > To: Cullen Jennings; statements@ietf.org; Robert Sparks; Gregory =20 > Lebovitz; Russ Housley; Patrik F=E4ltstr=F6m > Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com; = herve.taddei@huawei.com=20 > ; hiwasaki.yusuke@lab.ntt.co.jp; hiwasaki.yusuke@gmail.com > Subject: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - =20= > 6 November 2009) > > > > Dear all, > > Kindly find attached the Liaison Statement COM16 - LS 124 on =20 > "speech and audio coding standardization" addressed to IETF RAI, =20 > IESG agreed at the ITU-T SG 16 meeting held in Geneva from 26 =20 > October to 6 November 2009. > > Best regards, > > Rosa Angeles-Le=F3n de Vivero > on behalf of ITU-T Study Group 16 > ITU - Telecommunication Standardization Bureau (TSB) > SG 16 e-mail: tsbsg16@itu.int > > > << ls-124.zip >> --Apple-Mail-1-411169416 Content-Disposition: inline; filename=ls-124.pdf Content-Type: application/pdf; name="ls-124.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjkgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgMzM2NzcvTyAxMS9FIDI4 NTMxL04gMi9UIDMzNDUxL0ggWyAxNTk2IDI2NF0+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAg DQp4cmVmDQo5IDY1DQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDE4NjAgMDAwMDAgbg0KMDAw MDAwMTkzNyAwMDAwMCBuDQowMDAwMDAyMTE1IDAwMDAwIG4NCjAwMDAwMDI3MTggMDAwMDAgbg0K MDAwMDAwMzIxNiAwMDAwMCBuDQowMDAwMDAzNzQ3IDAwMDAwIG4NCjAwMDAwMDM3ODEgMDAwMDAg bg0KMDAwMDAwMzgyNCAwMDAwMCBuDQowMDAwMDAzODY3IDAwMDAwIG4NCjAwMDAwMDM5MTAgMDAw MDAgbg0KMDAwMDAwMzk1MyAwMDAwMCBuDQowMDAwMDAzOTk2IDAwMDAwIG4NCjAwMDAwMDQwMzkg MDAwMDAgbg0KMDAwMDAwNDA4MiAwMDAwMCBuDQowMDAwMDA0MzI0IDAwMDAwIG4NCjAwMDAwMDQ0 MDAgMDAwMDAgbg0KMDAwMDAwNTA4MyAwMDAwMCBuDQowMDAwMDA1Njg2IDAwMDAwIG4NCjAwMDAw MDYyMjggMDAwMDAgbg0KMDAwMDAwNjkxNiAwMDAwMCBuDQowMDAwMDA3NTI5IDAwMDAwIG4NCjAw MDAwMDgyMDAgMDAwMDAgbg0KMDAwMDAwODg0OSAwMDAwMCBuDQowMDAwMDA5NTA0IDAwMDAwIG4N CjAwMDAwMTIxNzMgMDAwMDAgbg0KMDAwMDAxMjQxOCAwMDAwMCBuDQowMDAwMDE0NjA0IDAwMDAw IG4NCjAwMDAwMTQ4NTMgMDAwMDAgbg0KMDAwMDAxNTE0NCAwMDAwMCBuDQowMDAwMDE1NTA2IDAw MDAwIG4NCjAwMDAwMTU4NzAgMDAwMDAgbg0KMDAwMDAxNjI0MSAwMDAwMCBuDQowMDAwMDE2NjIw IDAwMDAwIG4NCjAwMDAwMTcwMDQgMDAwMDAgbg0KMDAwMDAxNzM3NCAwMDAwMCBuDQowMDAwMDE3 NzE2IDAwMDAwIG4NCjAwMDAwMTgwNjggMDAwMDAgbg0KMDAwMDAxODUzMCAwMDAwMCBuDQowMDAw MDE4OTk2IDAwMDAwIG4NCjAwMDAwMTk0MzYgMDAwMDAgbg0KMDAwMDAxOTcyNCAwMDAwMCBuDQow MDAwMDIwMDY1IDAwMDAwIG4NCjAwMDAwMjA0ODEgMDAwMDAgbg0KMDAwMDAyMDcyNCAwMDAwMCBu DQowMDAwMDIxMTAxIDAwMDAwIG4NCjAwMDAwMjE1NzUgMDAwMDAgbg0KMDAwMDAyMTcwOCAwMDAw MCBuDQowMDAwMDIyMDQ3IDAwMDAwIG4NCjAwMDAwMjIxODAgMDAwMDAgbg0KMDAwMDAyMjUyMyAw MDAwMCBuDQowMDAwMDIyNjU2IDAwMDAwIG4NCjAwMDAwMjMwMTAgMDAwMDAgbg0KMDAwMDAyMzU2 MSAwMDAwMCBuDQowMDAwMDIzODg1IDAwMDAwIG4NCjAwMDAwMjQyNzcgMDAwMDAgbg0KMDAwMDAy NDQ5MyAwMDAwMCBuDQowMDAwMDI0NzY5IDAwMDAwIG4NCjAwMDAwMjUxNjggMDAwMDAgbg0KMDAw MDAyNTQ2MyAwMDAwMCBuDQowMDAwMDI1NzQyIDAwMDAwIG4NCjAwMDAwMjYwODUgMDAwMDAgbg0K MDAwMDAyNjMxNSAwMDAwMCBuDQowMDAwMDI4MjgzIDAwMDAwIG4NCjAwMDAwMDE1OTYgMDAwMDAg bg0KdHJhaWxlcg0KPDwvU2l6ZSA3NC9QcmV2IDMzNDQxL1Jvb3QgMTAgMCBSL0luZm8gOCAwIFIv SURbPDQwNEQyMjkyQzlGQTI1RDI5MTY5QURFRTdCNkU1RDI3PjxEOTk5RTRBNkE3RjVDMTQ4OEE5 Rjc3NEE2RjNBNEYyRT5dPj4NCnN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgICAgICAgICAgICAgIA0K NzMgMCBvYmo8PC9MZW5ndGggMTc4L0ZpbHRlci9GbGF0ZURlY29kZS9JIDIwOS9MIDE5My9TIDY4 Pj5zdHJlYW0NCnjaYmBgYGZgYOtkYAMy9jHwMyAAPwMLAysQc7xhOOHBwHAVJi7YnNsAYTUwcIBk kIAdFDMwKDHwcDJZyjJ+ZGDgZJgARbwMWhqTLOUP9akY1aoV5S7ZcLmt4bqAoIfIwkDRiXGijCbC D9dIM07jf2gs/uCiaOEONkNDNkNTNkMHhUAlsYRt/Iq5AgFfhQOOVDy4hmQpCwNDkSaQZgJiCyDm ALpsF5BmBOL7AAEGADOOKEENCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmo8PC9NZXRhZGF0YSA3 IDAgUi9QYWdlcyA2IDAgUi9UeXBlL0NhdGFsb2cvUGFnZUxhYmVscyA0IDAgUj4+DWVuZG9iag0x MSAwIG9iajw8L0Nyb3BCb3hbMCAwIDU5NSA4NDJdL1BhcmVudCA2IDAgUi9Db250ZW50c1syNSAw IFIgMjYgMCBSIDI3IDAgUiAyOCAwIFIgMjkgMCBSIDMwIDAgUiAzMSAwIFIgMzIgMCBSXS9Sb3Rh dGUgMC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vUmVzb3VyY2VzIDEyIDAgUi9UeXBlL1BhZ2U+Pg1l bmRvYmoNMTIgMCBvYmo8PC9YT2JqZWN0PDwvSW0zOCAzNSAwIFIvSW0zOSAzNCAwIFIvSW00MCAz NyAwIFIvSW00MSAzOCAwIFIvSW00MiAzOSAwIFIvSW00MyA0MCAwIFIvSW00NCA0MSAwIFIvSW00 NSA0MiAwIFIvSW00NiA0MyAwIFIvSW00NyA0NCAwIFIvSW00OCA0NSAwIFIvSW00OSA0NiAwIFIv SW01MCA0NyAwIFIvSW01MSA0OCAwIFIvSW01MiA1MCAwIFIvSW01MyA1MSAwIFIvSW01NCA1MyAw IFIvSW01NSA1NCAwIFIvSW01NiA1NSAwIFIvSW01NyA1NiAwIFIvSW01OCA1NyAwIFIvSW01OSA1 OCAwIFIvSW02MCA1OSAwIFIvSW02MSA2MSAwIFIvSW02MiA2MyAwIFIvSW02MyA2NSAwIFIvSW02 NCA2NiAwIFIvSW02NSA2NyAwIFIvSW02NiA2OSAwIFIvSW0xMDYgNzAgMCBSL0ltMTA3IDcxIDAg Uj4+L0NvbG9yU3BhY2U8PC9DczYgMTUgMCBSL0NzOCAxNiAwIFIvQ3M5IDE3IDAgUi9DczEwIDE4 IDAgUi9DczExIDE5IDAgUi9DczEyIDIwIDAgUi9DczEzIDIxIDAgUi9DczE0IDIyIDAgUj4+L0Zv bnQ8PC9UVDIgMTMgMCBSL1RUNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1h Z2VJXS9FeHRHU3RhdGU8PC9HUzEgMjQgMCBSPj4+Pg1lbmRvYmoNMTMgMCBvYmo8PC9TdWJ0eXBl L1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDcyIDAgUi9MYXN0Q2hhciAxNTAvV2lkdGhzWzI1MCAw IDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMCAwIDUwMCA1MDAgNTAwIDAgNTAwIDAg NTAwIDAgMCA1MDAgMzMzIDAgMCAwIDAgMCAwIDcyMiAwIDcyMiA3MjIgNjY3IDYxMSA3NzggMCAz ODkgMCAwIDY2NyA5NDQgNzIyIDc3OCAwIDc3OCA3MjIgNTU2IDY2NyA3MjIgMCAwIDAgMCA2Njcg MCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMCAwIDI3OCA4 MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDAgMCA1MDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDBdL0Jhc2VGb250 L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNv ZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTQgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnRE ZXNjcmlwdG9yIDIzIDAgUi9MYXN0Q2hhciAxNTAvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDMz MyAzMzMgMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCAyNzggMCAwIDAgMCAwIDkyMSA3MjIgMCA2NjcgNzIyIDYxMSA1NTYgNzIyIDcy MiAzMzMgMzg5IDAgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDcyMiAwIDk0NCAw IDcyMiAwIDAgMjc4IDAgMCA1MDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3 OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIy IDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDUwMF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0Vu Y29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTUgMCBvYmpbL0lDQ0Jh c2VkIDMzIDAgUl0NZW5kb2JqDTE2IDAgb2JqWy9JbmRleGVkIDE1IDAgUiA1NCAzNiAwIFJdDWVu ZG9iag0xNyAwIG9ialsvSW5kZXhlZCAxNSAwIFIgNjcgNDkgMCBSXQ1lbmRvYmoNMTggMCBvYmpb L0luZGV4ZWQgMTUgMCBSIDUyIDUyIDAgUl0NZW5kb2JqDTE5IDAgb2JqWy9JbmRleGVkIDE1IDAg UiA4OSA2MCAwIFJdDWVuZG9iag0yMCAwIG9ialsvSW5kZXhlZCAxNSAwIFIgNzkgNjIgMCBSXQ1l bmRvYmoNMjEgMCBvYmpbL0luZGV4ZWQgMTUgMCBSIDQzIDY0IDAgUl0NZW5kb2JqDTIyIDAgb2Jq Wy9JbmRleGVkIDE1IDAgUiA2NCA2OCAwIFJdDWVuZG9iag0yMyAwIG9iajw8L1N0ZW1WIDgyL0Zv bnROYW1lL1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQw MC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU2OCAtMzA3IDIwMDAgMTAwN10vQXNj ZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0 IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTI0IDAgb2Jq PDwvT1BNIDEvT1AgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4w Mj4+DWVuZG9iag0yNSAwIG9iajw8L0xlbmd0aCA2MTQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJbFNNj5swEL3zK+aIpcbBxhjorV+qttfQ06oHAs7GFWCEzUbpr+/YZjfZbhUpsmc8b96b N+y/Hxg82eRzk+ybhgOD5pTUkOGvhoLTnEOVUcazHJox2X+xEjob0hnYbkp2Gc2yrISmSzJoLslj +sk5RXY5LdLJaTN9JL+aHx5bRGxB80qWWN18TXwtK0KtP1URAA5mVGAWIJLKtB2ITAcwJ1LSKgV3 VqSgeQojhttwdGrR/jJsBc75W3cmFeWp6mPUmXDFem1jZNCxXFszgXUbFkFBZRp7+BZqchAUcEFF ned3xMUr8ToSH7GqDqR4eoWjCgew6/G36sLZQaDBUnhofkYWnZlD5EoYFemin86OEoEU4AFZrUEF vo+gEGFasvOPrUI1IY2SLnoYQvvXvoH1jle0qgDfswLJb9S9mZF6Hpnrqddd61RPsLGe/D8OGnz4 WfcrjrY33ToSxtBWHAmFCJ8FZIF+viDLF2ReRugDaoD2JrbEwV7JTiJtrzbcHcIrC5NxMC/qOcTU tKVcfKNgRcHmtNmJ7MJhbL39SPBkFgygfu1sNAwtrKJdj16UU1PvBfrlmddlNlZ9gOPqsOBNV1/L OJXyfkvfTczZG5FFzYvpV5xa5zc+JpBpO+DeLuEWx4XjY/IGyre9mdvF+QWX3nZk4w0Ipm8eipry DNn862L9OmuxAa3HwfuIJBABu150mB6yWbdB4kZvn8nqzmbRf8Lr+HnxsJc0dv3WJL4vVPjZ4Bip iH+47ag3Od0nRY2A/G26EDh+casu6/p/AEL6VwFdMFqLdymPzcR9JfwVYADJlCoJDQplbmRzdHJl YW0NZW5kb2JqDTI2IDAgb2JqPDwvTGVuZ3RoIDUzNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVh bQ0KSIlsk02P0zAQhu/+FXNMkDrrr/HHsZQeirpdwXrFAXFaUQmkguCy/4Tfy2sn8SYIVXJcZ57x vO9Mrkq8sPPkQ101+5hzIm84e/r9VV3//x7PpLWZIt4WlUnjl0kCR3KJTdKOyk1pKs91eVEDjeW7 Mpq1bbHTztjIEiiKcA4zwkhsG4ddPXtRn4fTpYyR3XAcDdaPl9FzGvblhGceHtq/y/6MEDtQOZ6n 2MP04h6rmdeny+kwZpZhP+4MgktD5jRTVnqa0k0Bmxto/FLeq7tSUDmVqzKOqxlVTtt5E1gS5FjW azmhytnVrY3NjMPDPeH0D50f4YHH5ljtORb1Sxn6RqoZGYOwpQCzLe0CGhCq4Z/e0A+E+cwBvciu 3W81i0V6kozO6bqLrXHaOUvPN3V3uhkd6d1P9aHCAeU2d1vxHHCNZaNnEGLxTvwMet25xFpynkXj Tk/BoIO6DkPlLGQbWTiz4sKUfM21uxxHiyLjwtjOZDa+1/gPgwGzqGJm3MKIZmtQX1wxdVbBWA4w Y/HC+xUSqyR5RaqHDke5YXDF+c5J5zCIelvemmuuOLydubDiUpXlN5xfrK8KUWa3sLcMM+XiVtqa a1+k893G1DnH/lUf0ieSxGlumWspXC8zr7CqJIcNBv+iqw90eWGkT4d4FtdL3DD4yuA+PvWZ6ZOB QTeh29EmUVpwk+UEB5OJ9FeAAQBgBfOWDQplbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqPDwvTGVu Z3RoIDQ3My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMkz9v2zAQxXd9Co7UoPMd/4qj a3lQ0diNwwxJ0ClAhwJG0alfv4+0pMiBg0YCTILmj+/d8Wkznr1Rw+/mvvnT+EAh4YmK8Qpxr7AU GY+oaB15x9Y59XpuNuDswkUyFlxfOUPxChPqgVkzY26FxQjM35ZjioGt+JnzM8fwUZE6EYHrop5u MOG2VgWvtYyBxzhz8VNa10z/OS2TKPRs0KyJS//Xes8Evq3lyEol1nqeLHri5/4H+ejaJFxxlgyj l3N94cOY4J81J+R7tmbRsytOAja51X3DgsOSAYeqocfz3YW3nHhsrZve+tkTAhUlUUJtZvG4ZMQj rPadx4nBsM5jWDISmNzUCzQDtpCj0t+ibVVI8IrC7Jx/O134ffMlN5uccWUq/2zkYhODSCQMIfX1 C1D53LDKr+Xnb6NVm38VzEyYpanAy0xMJMS3xCxNcMcEJ305Quf9t/3ueHf3eBh32zweD/U4Vp3A efQqD9N2KdvrVKTovuiHvD0M29MwPrfFoN62gJyuhzzsd/l4Uu2P/HVdEi/eeOWtFFZbM3vDnZfy MMNXMWk9Dm3nKOgn9X1/apEAPbZIiD5eloe2aCskre08GZ26su61YbksGJhR/wQYANin9OcNCmVu ZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmo8PC9MZW5ndGggNjE5L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiZxTwXKbMBS88xXvKDpBkYQkRG7u1PG4k8bTWD3VORCsOHQMeDBOJ/2Qfm+fgILT tJeOZ2wNZnff7j7Zj8GltQI42MeAxzQ1wPDTn2QiqNGQcEa5YTHYMmCUMZaCzYPIHwXY7wGZV7t9 cXyCutq/hPZbEAnKuUoh4lQlqQT7ocNxDyOrptgVVba/ggHmEVz0sgKUpglorWl8rmg8lHmxr+Tz yR3boq7ChGzIcRNeQXhvOxuyt4EMEhDGfwszOQ7MRU/C2SXXEEZcKaGoIQtXuefsAoSGVd7WD66B CDTc1s8ujPwLZWioIA8ho5LgnwJT6GTnNlAS4wFtYqokyFRRaQCdQ+OCx+C9PQ94tCnihEoBWmqq BqPdfEx3ToeTn/RmOVuuV7ewDiOJ2jbk+D2z80/zW9s7RxMU38a0tRotqzExsq5PTe4wJgz6Xyl1 1Sztl8jCuj1tX2DR1KcD+Ix61OAg6mBeSntcNGkRW7R7d/VaRNA4Vuh4lOjo0AdiXjUkxobY0NCd O+xf4GYNbQ3Lub3G7YLjwbn8CbJqC9lpW9SQ19ui2sGxxUdZsy1+ZN1mKKxq3IphckNjAbiZwqhp 8v9I2xceU4Obmmpq+sLx57zwP7ZZqZSa823mk1ney17XDWS5nx3tYlNRzLgine272fICA1gvenn2 umc+cfEzrrwuSxdKmpKqHRi5NoxEPYl91w+STIMkE7ioHuumzM6mUfwN9G1hs8OhqZ/9xcbspGZk tmucw6ZaGBZr4fepdK7tmARGq4fd8DTx5KQn9M1u/nYzf4LGimPSXc/yYbiOmzC8h18CDACU4CWj DQplbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2JqPDwvTGVuZ3RoIDU0NC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImMkstu20AMRffzFVzKLczO+5FV0CaFEaBdzSYwupjaSq1ElgM/6vbvO0PJ lhtk4Z0okLyXc098YFMpUFuYCrQG4h3T6JR2EI9sXt3Vadk2XX0D39J2sYKJdspUkgsOkx/xgfEy 5hzNceScW4iL/DcPV1823T4t9jcwic/sU4waBMQnZtFpyL2izExPQ0VsVm9/1xDTcjkxaKu6udAQ o4QuEtPTZxaaHdIxN8d6seo27eZXU+9IM344OVk1XaJfwqPiBiQqWlc2zatYt9nkVGjDq486gLAS ZNAcpOXvWhChH7xfTwK6KjVlvu/j+cjdomMKlcjF+URRJqpVuRD3+cK6uV2RbVxs1sXZfWQqWAwW tFboPAjpUfr8UiaE4GFbsyf2OTIhgVQkGGlQ6txu0HGeD1qTPid9Oq2CYbNR6CVoZ9FoUFyUCASa fqmABpgyBk3Wdh7zq66Z0QHtuW7Hmla0Y/9Qk7ccsuxDvnCZ8wYt8hl68HjG5CpCqF2OkUtK9PGw O7zUMGuOaZdeGlpwERK1Cjmy+D3GMxJliyH9h/Sauiu58AK0zOcE0D6LvEvmW5vz6mv6QyukH1dk qJwXol8xGOqJ4v3QVViRiuqpGl4B/9Kr3LbpJ3b7fSYLn1//Z0t5yr7kq8vHULeXtaB8x37R5zuy NdAkXU72LUwnLmRAeYERlSNFNDpCNJTEUCCZ0HOjHEc7cAP/BBgAFkULtA0KZW5kc3RyZWFtDWVu ZG9iag0zMCAwIG9iajw8L0xlbmd0aCA2MDIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ ZJPJbtswEIbveoo5SkBMaKNkH1M0LVL0lAjoociBkUY1W1p0SSqp+/Qdkra8FIZlyhA//ssoh65P Usi6n8lDl/CKrUuo2jVbQ5UXrK2hYBwMJmNScc54A9U6ZxXsEl5vWHO6Vctt2KqWh4+3Y/KhS4oS cvrQD29YC1XNGe2uoNslOcvzvPRSVn5ZQPeepM9uHg7w2eh5D0UDbiumXxYeH7pP8HT/CPcGRdBd NIwoOXQfI6deOKXnfE9HbWg3SgNfpZBWT/DshMNdtmZlipNjkL10X5JVBK0K1nAPi1LqyHjCEY2R 0w9w2sPoaxAhMkRGz65TOUFvpEMjA6+oWN1e6Dr7q3gwKChYT8XBQ2n3Qc8G1FGjdcFcQY3wC0q1 UPzSSztaKbyVO7hJ7V3aLVrPjx5LzsoN9yYLvjCLMzNG/xqdks1RK6XfL3wL5+gcSQL1uJTBQhH5 ObtbqZso9UbcVlgQsBNuNgSeBtgb/YYTDPiGSu9ProLykgbxmMOF+9T5PT1aC75liwp759V6mnV0 FWaQf/0/XuEqUq7dt+e5Ow6M3SP228AQ8yA19HrAnrT2vTZDxlmbxkTCkiwM6IRU1KPNarZJ0c8D J216PGlvqivxTTwIHJ0zyV4oGoXfM+GaVJpQZ+3rtAy+ZRtCBWKTwisqSeH4l8HRRdpTrfGExdjV 7F7EGainyO78/MmJZFPqhnqYDmBlfEwqYQD/oDkZKOvLKSz+q7aXFonoKx3IQEsx6Mk6Q9M5RLnS QS9orufeHz7OSh3O6j3+upbmXEtIC/4JMADs2UFIDQplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2Jq PDwvTGVuZ3RoIDU4MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImElM2SmzAQhO9+ijmK KqMCY/xzzyHOcYuctnJg5cEohSUiyXb89plBYLybreTiwthq+uue4VV47FAFUPaIykNo6wDnZCfX AjEswTrQyY/q2yLPZVaWkEH1ZZFmMsuKFVS3xaswR8Qj4O+klFuh6HpJIgh2+O6SNJeF0Cdt6g4C qtZoVXdRcS2Ld4pZDpVaTFe3hQCHvy7a4RlN8BJesO/odNDmxL6S6uciXZVynQM9JC9ZJ2OFQSzf DBIOtbnScT4TWu3JaI8uaI/gW3vpWCRfyXI1Gpl9REv7CHkEYwO8IVwI16EP+pxs5V7Ugdjf7lDD ydlLD3+BDSKrWW8ITdy0bwdHFo54xc72pDA0IGHk2sjdjrk25UNmP8Oto61DAELS3NdW9NaF2gQW JbNIuFQBW+Q+kvXURi6QD5nhR5tk9BkmM/1w00WK/eeJxGqQQyXTzt7rLtzTxiFGAkqJ1eJYUTq1 h752AWwTyUh3rosFi1m7iFg8P1FrTIcByTc9sXdWofdw02waDtX3tJJwMKNlud48T1RMG5pa0Sh7 0nI0hZNldrOT70Y6zszM4qGtr0hEaMZaqHR6wnuAj/XSuETbTG+O0FgKnvoUhCEeYcyQXFxjI8FW borRkui0nf44cn61N4ZYUvDGmvSxT2Oy8fD/0p2WKmaapDwBhvO5qJbbeq50OU50Iberfw20qs24 IL5HpRsdi2db+/m98XGUttHQcyIVurhZPkn5BcL3X7ChnTMKOclxUZwkZ/BHgAEAnWFP6w0KZW5k c3RyZWFtDWVuZG9iag0zMiAwIG9iajw8L0xlbmd0aCA1ODYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJXFPLcpswFN3zFXcpZoKMeBjostNOm6w6KZ0ski4ULBs1WKKSHMZ/3yvJr2YjBNKc 56V/SLKioE1TQ8Yoq6H/kuTQD35ZkmfyJGCfNrQlPMXzgrwJMGIrjFCDAKfBjQLufzzCrCc5HEFv 45f+V9bDC0l/9w+IlAMDO6ikyGlb1PjqSWieM0/0TEbn5nRNPq1W0h0o7mTkUm4VgFbSH5tVQPva J2W+pmtgdUdbfDBGmwJyWndd16K4ZJt87hOGnzxvARVraVkAW+O9Ni+h3wdFeVBEXlIKaf8nycqc sjKEsK7P+qLALGwbnwd5GoWCjXgXk56l2gEHJRYY9EYMd/DzG1sD3xkhLKbAHQiPjKbL/MZ03l5A WRtDnuQ+bSn6Vtx51NJsspkbd8Ro04Y8grTAp3hHpxgisQ7kftbWytdJoAOfTHZiuvbo2aqrhSqy fdcLGjChqEBckJkPLnaHTLfsnjqAs4bW7dnFZT4IWLlTcisHrtx0hElY63G8b0y9/Oj6vPMyOMxG o/poCxbpxhjk2U1NO/bRTXF1U0SYUxmIQoRyFpYRh9N7wxXNKA2HOdsarRzsNJ/8zEZDHa3K21q6 C3TBTgqHUSI6lmx0imrIkU/uGHaIKPyfYA+TA2zaZylUONpQuFcwcItTEJ2cqP53UsfZj3KNDtAR 1ZetrqqN+Iu4NTlg8TWRJgRWerOeVQUKbJ7dWLnpvItWLoHcgfQyKwL6YOBdiuUusCk+DGJ2PK0Q +xWrHOVuBCPtW7x9/vfgnwADAFtVHk8NCmVuZHN0cmVhbQ1lbmRvYmoNMzMgMCBvYmo8PC9MZW5n dGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0cmVh bQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10 Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsA jdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0A QBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX 1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuU DQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHB wUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2+ +M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1M rsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au 8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqAC JuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyD j8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3Q CqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14H D8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuU iHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCG cI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZ NE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g 5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2Ew GG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXG krBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3 mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovL Fs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvb etpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSd xmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r +sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5q r61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzq EB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHsh N8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy /cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/ TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21M u73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/m MfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdW Lf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPq QXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOp Zkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xx bGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXv urEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt 2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuv nByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+Co UqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUT tYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C 28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC6 0TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynf r+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO60 70DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+ 3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iajw8L1N1YnR5cGUvSW1hZ2Uv TGVuZ3RoIDYwL0ZpbHRlci9DQ0lUVEZheERlY29kZS9JbWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29t cG9uZW50IDEvV2lkdGggMTEzL0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDExMz4+L0hlaWdo dCA0Mi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0Ky4Hhqf317Wr2vatavatWFa1DVq1DDsOG4YOw4Mgy eDhhNwYI1g8GQaQgcGEDDnYkHh9zsoFh44AIAIAKDQplbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2Jq PDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjAyMC9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNv bXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL01hc2sgMzQgMCBSL1dpZHRoIDExMy9IZWlnaHQg NDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ7JfPb1RVFMf9A5SwNJG1MZK4cYEuTEkgkqAxwR8h EkkIyA9ZEDfVjelsaEhdYJDwQxJJoJRJI6RAiSRKEdJqbSsWKUJbwdHSWhloykwTJRqCn+nXHm/e e/PmvembDjVzc/Lyft53z+d+7znnplK1VpHWeyXz3GsHUye/397ev+uLH9/eefap5XvrW77d23GN Sx2fX3t4674Lh7uGPvlqEPv0wpBr3A+0dPdwoB3rHeYpP3rm5QP0jDXsPkc/Jy/+lO65EdiV/ehY 59XjW3beeOyFXx95NtB4dHPh0vG6TdnNjRO70r0/387czptdHc12X791/mqGMeAILuO433S/bmOa EYICPp19I1hEnjWk0ZFGoVpDmjjS3NQ9rLXjMt+qH44YbuoOPHUJUsbApTjLRDiQczjt/7D33MB4 k5EvX3+U2eTIvz78/LKeah7V24G2vv3b0x1LNhbjWQwyn+zY0xVIz4w/Ypy8Ut/2xJKPVmz7TDTg 0HKq/8FMi7L2//jzHsZEIBujylH64S9c8tRF6lI1tkYY34sRLmaG9+O2i281nuF3OIJI+Cl/L3Te 3IM4Bx9fEQumB+y5F9/d0fyNX5Dy942G0xhzyq81p9xnMMvWHPprutWQJo6UFoUnTfB5n2/pwcIL JwojMv4CSa0OmV0a50DaHvIe8z8q9DANkHhYNsBwY2rof219G5qBoebOQxi/oMELcSXqUm3vGKR/ U6kr1wWLm4RUf3TBeiCXZwWqzT3ESYTU9/TqkOyToPGXDYu2kBklSH90Ra5nu4exWBJ1kdLe3Hac sKwo7VKlc2jbcggHWwZbkCIbMvUckPTIlXl0/TWv4YCMFRWxWDxdqkOZrNC5s8Y5S4P7GPHW5tTY Cm9JyIFHdwrwbjbRMq5EFVr9+uSOCryRsRxWNlIaPGtI/Uix8niaUJmRVVtb3eXPCZcYXkMbsERX N+T6i2SXtscMo/+RfRhezM8W456uYhW+6QcC5WUlf5PImRe4ke9ElSPVLz+yMkAbASnWH4hCzM+w mOE4eSrBmMk0sQpCfipf8BrXbk/excrISiFaZedlEcDKCVeHlHDaYtguIzrYiPA5zlKuTAqyhGTJ 3+EjzmoNKsuL6ux5ppzsT1WjHa5+p3NDx00uuSlzY2yyFncHqu2nNBlxrrX05AjRNdbeMxZVIsD7 TV+aOLWn8KQtnRAWmFzkKv4Vkmv0zKW6KNb8Mn6cxR44LUGkqZmgmpu6984Hp4mijBC2LPZiKQna 2onwTkRtxAWLfljFEakyBdHni70hbtqusxI81eCJ3cnlV65LiyfHYiJUumH5Q5UREntT08EhWbB0 uG71/ojRleXPLJTkiVPwlISMaiV4qsETAyy7Km2gWNolBwl8gYVwycwei6d6ptuIcUCbo5BiD6dY 7BKPUa0cTzWtgsn8FFO5YHETTlGdlvQd8gqwaECKnQ1bfasaQ/G8EAf2dEWpB3jBHwSUjxie6VNU Kw3Tg1TZSpVVyRWt0othw0GZlBMlr7hgBVATJNm7TwFLgIVbOFuqKavwrYBp2H1OPGez5Sybqv23 5cQAUkF4EVVnoYA4ABMyncks+ud8pZgTOJVSrNiWrPZT0/UJPCkRFTbnnqc1CzW9VzLwwU35GCUH 6R1gCg4e4ReXqZk9SyBht/R1S+IQ/ibaYmCPPPoSCU7F/Bwko5JNAwDpUCZLFFICip6DLBogctgC ih5gi9GJGKofqx+0QUtFrsr0msqtmwuXFpNrtmHf37/8ZlZFpKIKT6wQBE71w8QUGz0BSZliS/7C VE5wAl7uY5DkDi+QDV0Ze37hToGmzBYOoZI6ClkGgh198tX815eM6v27U9UF+29cPdUvvKQtreVU nFpUBOySOKDSl7oCcXJksrijhSDOnkkxvHqK0QmzwHRoppgUutqwaMt43aZA0Y6+/h5g4SmrOlXx xJBuZ98ItSsuCGzckkl4FWyZHbBgdAUWLQRMQVUmYpK3md7hJkj1LZdr69t6ro8xwsmT57ObG/1g kasnDlQ3FIinNnHUdcT8VVtbpS6FgnDR2oLlZWUuaFjWMx26IsQQLf1jYNcde0FqF0+muL1jkKlX HahxokkAgtGTwgiwE7vS2EMCVmMWUh3RxrI1h/BLecdTNdmlZCmY4QHZEzP9kRPjX5IuqZNVY3si P1JwIVpWvX8LBm0eGVV9Wy2qcsHA/nBtnNoPsErriocW+qxSRZaYFasl44ORVD90y+da+CvXpSmi RsZy7oYI8yAVK87vT+Y58YuW4EDsBaxWXxWpqpkjQqqiC0/xd/n6o4pvpB6LuiR05XRL635z1agE hKTpig6FUSH994lJzJCKauAghdeQmmgxYLrJi/u8JqtuBSukVsfi9Z1cfmDw1pEzlygPiHJiy1EL H7xKSahO4VExkzvomae8Y9mHz5msg8e/AyMAMRcpFmVDZEhl7mInopLIPGBtX1D1wkBI4WlItQfk SHwg4kEGgzmoiYFkN4QnSYNON3nacmKA9+Fm4VEOCqmoimcZg/Ske/UstlZ9ecotpiNpVLGbkGq0 CSIV1URG6PI0pBytSIAt6i2AnQkFVQ+zaskirdAIhVRm4lRlW6hjNzcWYuzdqYchec27pr1qDWmy zYPUygPCglsPVHuY86wZUisPuNSJzmXVHuZ8bRYKakiTbX6k1R7R/7b9I8AA1TMoFQoNCmVuZHN0 cmVhbQ1lbmRvYmoNMzYgMCBvYmo8PC9MZW5ndGggMTgwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiQClAFr/////d4m7GzePvMfa4Ojq2OPm3Obp3ufq4urs5Ovs4+zv5O707PHy6meF4QAz 7ZGn+vr69vf42d/qOFOeXXWvs73YWW6taXy08/T16+/wpbLPxtng0N7kzd3i1uTqwNbfKESWh6PG uszaQ1qhqb3SvNPdttDcsc3bncHZDiuJ6O3v9PX2pLfQpAxL8p+yw8viz9rjyNrhy9zjz+DqLkya mq/L09jpAgwAgaF6wQoNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAxNDAvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE2IDAgUi9XaWR0aCA4Ny9IZWlnaHQgMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIm0zFkW giAAQFFIILAJQiM0B6LQbC5r/0sL7ZxqA72f93cBHAQIEzJElDIWhqPxZNo3413A110IAeZQRvFC LTWjCCHiw5gkMl1leaFKs7abYusqV9dlDMB/2GAHKf6wTaP3h+PbPf2yvEfPnGOptP6y+GKTPLve 7qaN7CP1bOWcaZ8vAQYAvtIR0QoNCmVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmo8PC9TdWJ0eXBl L0ltYWdlL0xlbmd0aCAyMTEvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE1IDAgUi9XaWR0aCA4OS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K SIm6ef+Vhss0IDp15f6dZy9vPH4GREAGEN17/urBCxB69OrNk9cg9Oz1WyB6/f7D+0+fz996LG3e f5fX9iGDMTICirzfeOD///+/YOA/GPxCAkAu0IT2qUcsgufFlq4HWv3t+w+g+JuPn4CGf/n6DSji HLUwMm8t0A1AEYgzgAjiMIgjgejqw6dA9PjN+8yaLUBzgOyzdx+duPUQgoDczceuuyQt49PunLT+ 7Mk7T/dcvrvtwp2NZ28D0ZpTt4Box6XHQL1AZ3z8/AMgwADhZs9OCg0KZW5kc3RyZWFtDWVuZG9i ag0zOSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIxMy9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDkwL0hlaWdodCAxL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIifr161dmzRZp834g+ejVm6sPn954/AyI7jx7CUT3nr968AKE gFJPXoPQi7fvIejNx0/PXr8NzFq5z63gsYDDQwZjZHRDwv3T0Qv/////hQr+w8DmvTcsgucBtR8+ /QjI/fb9x8fPn4FmAtHr9x+A6P2nz0DbY0vXA5XtOX4LKA60HSgCcRjEkUAEdDAQAcWXbL/gHLXw xK2HZ+8+ApJAdOzmAyACcjcfuw70oIbLNKAaoMi2C3eAaOPZ22tO3QKi5SfvAknL2EV1k/cBBBgA YI3RJQoNCmVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAy MjAvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAg Ui9XaWR0aCA5MS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlasv2Cc9RCi+B5Szed v/Ps5dWHT288fgZEQDYQ3Xv+6sELELr/+tObj5+evPsCJOHo169f7YuPhdZteRJS9pDBGA09FnD4 dPTC////f8EAkP342dvY0vVABLRxyfYLEPHPX75+/Pz5/afPQDNfv/8AQS/evgeKABl1k/fp+cwq 79wNdBtQAdAxQIdBHAlEQEEIunDvCdAjQDOBjBO3HgLRsZsPgOjs3Uez1p8GSmXWbNFwmTZp/Vmg 4LYLdzaevb3m1C0gWn7yLpAEikub91+8/hwgwABDI9BkCg0KZW5kc3RyZWFtDWVuZG9iag00MSAw IG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIyOC9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1Bl ckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDkzL0hlaWdodCAxL1R5cGUvWE9i amVjdD4+c3RyZWFtDQpIiXr/6bNF8Lz2qUdckpadunL/6sOnQHTj8TMguvPsJRDde/7qwYtXj9+8 f3793qf5mz4dvQBBQO77x8+BaPfRqwnhM06s2ftELeghgzEauiHhDlT869ev/2CwdMNloHXlnbuB 6Nnrt0CRb99/fP7yFYjef/oMRG8+fnr9/gMQvXj7HoKAyj5+/rzn+K3ArJUQpwLdBhSHOA/IhrgZ iIDc2NL1mTVbrj15deLWQwg6e/fRgWv3IZaef/CqbvI+PZ9ZQBIouPHs7TWnbgHR8uNgdPJuSt8e r4TlQCcBBBgAmuvSuAoNCmVuZHN0cmVhbQ1lbmRvYmoNNDIgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAyMzMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE1IDAgUi9XaWR0aCA5NC9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6//9/ 3eR9saXrZ60/HZi18urDpxB04/EzILrz7CUE3Xv+6tGrN0CRJ2pBd3ltb0i4AxGQDUcQwccCDg8Z jDERUPzT0QtP3n0BWmQRPG/30av/weDXr19fvn4Doo+fPwPR+08g9Objp9fvPwDRi7fvgejZ67dP Xr8B2g4UBzKWbjrvlbAcaAjQ2bvO3AIioKuAsg9evLr25BXQqdMWn3RJWgZkn7v3DOiR8w9erdx7 yTlqIdB3B67dP3bzwYlbD9sXH5M27weasOfy3TWnbgHR8uMgtOjITSACGr50w2WAAAMACevIHgoN CmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyMTkvRmls dGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0 aCA5NS9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIl69PSjns+sPZfvti8+llmz5cK9 J1cfPgWiG4+fQdCdZy+B6MGLV0D05N2XtxOXP2QwJgPdkHBPCJ9R3rn79fsP//////b9BxB9+foN iD5/+frx82cgev/p85uPn4AKIOjF2/dA9OT1Gwh69AqEgOL3nr9auul8ZN5ai+B5QBSYtbJu8r55 a89sPnb91JX7u87cAvpo5d5LQMas9adjS9druEwDeu3AtfvHbj4AkkDPAhlA/wLFs6Yf3HbhDhAt P35r0ZGbQLT85F2goHPUQqDVAAEGALGuxBkKDQplbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqPDwv U3VidHlwZS9JbWFnZS9MZW5ndGggMTkxL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9u ZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggOTYvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCkiJ+v//f2bNFiB6/OZ9eeduIOPqw6dwdOPxMyC68+wlED148QqIHr16A2Q/UQt6yGBM Hvo0f9P///+/ff/x+ctXCPr4+TMQvf8ERW8+fnr9/gMQvXj7HoKevH4DRECrIW649/wVyA2v3wCl dp25BUTTFp+MLV3vHLXQK2G5RfA8IJI279fzmQUUASKgp5Zsv3D6zuMj1+4fuHZ/z+W7cNS++JiG yzQgCUQbz95edOQmHLkkLQMaCxBgADbWxdgKDQplbmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqPDwv U3VidHlwZS9JbWFnZS9MZW5ndGggMjAxL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9u ZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggOTcvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCkiJevT0o57PrM3Hrj9+8z6zZkt55+4bj59dffgUgoBsILrz7CUQ3Xv+6sELEHry7sun +ZseMhiTjV7VTf/2/QcEffz8+f0nKHrz8RMQvX7/AYhevH0PQc9ev33y+s2jVyAEcQDQJRAnAd0G ZAMRUArIPX/r8Z7Ld3cfvbrrzC2gXyLz1gK5B67dP3fv2dm7j45cu38AjICCQLTtwh0gAjLqJu+T Nu8HovbFx9acurXoyM25B28CydKlJyyC5z16+hEgwABWa9GFCg0KZW5kc3RyZWFtDWVuZG9iag00 NiAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMxMS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0 c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDk5L0hlaWdodCAyL1R5cGUv WE9iamVjdD4+c3RyZWFtDQpIifr//3955+7Y0vXXnry68+xlZs0WIBfIvnDvydWHTyHoxuNnQASU BaJ7z189ePHq/utPQPZz+zQgeshgTB56ld76/tNnIPr2/QeE8ebjJyB6/f4DBL14+x6Inr1+++T1 m0evQAhoNQRBHANxGARB3AkkIS4Hyk5bfNIladmJWw9P33l87OYDIDpy7f4BMNpz+S4QbbtwB45S +vYAkZ7PrK5tl5YfvzX34E0gmrn/hn3q8qUbLv/////R048WwfM2HbgKNA0YPnWT9wEDDW4droAC oifvvrzfeACI7vLakh1WT0LKgOj59Xu/fv3CE0poAQV0A3JAwd0JcTYQnb37CMhec/ga0Gubj13H E1Abz94GojWnbkEYfqXrgVqA4bPoyE1IWGVNP+gctRDoPIAAAwCDaa3XCg0KZW5kc3RyZWFtDWVu ZG9iag00NyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMxNC9GaWx0ZXIvRmxhdGVEZWNv ZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEwMC9IZWlnaHQg Mi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIn6////0g2XI/PWnr376MSth9eevGqfeiS2dP2Fe08g 6OrDpxB04/GzO89eQtC9568evHgFJJ+8+wJEr9JbHzIYU4KeqAV9Onrh2/cfr99/gKAXb99D0LPX b5+8fgNEj169AVoKQUCrIS4BugqI4I4EIoizgd45/+DVrjO3LILnrdx76fSdx8duPjhy7f4BMNpz +S4EbbtwZ+PZ22tO3YKjRUduArW4560GMuYevDlz/42Ju64CRTbvvfHm4yevhOWT1p8Fmg8MK6Bd 0xafDMxaiTWskIML4ubHb94D0fPr94CepTC47vLavp24HOiej59/AMMfElDwUCI1oIAIGD5AEaBf 2hcfA3KRwwoSXMCAQg6r5cfB6ORdYOBouExL6dsDDK5pe68DgyumdXtmzRaAAAMAaAyrjQoNCmVu ZHN0cmVhbQ1lbmRvYmoNNDggMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyODgvRmlsdGVy L0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0aCAx MDEvSGVpZ2h0IDIvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJrJE/S8NAGIf9NOLk4uKuozioi34D F7fWRXR2LEKHgkpdsiilrTioFYVS/5RKIbRJahKb5pqaNFUsfgAfvHJIQRAUnuHuHe79/Z7TzXB2 +aDcfL5reVBzOsWKweRSd+qukDS8Lph+ILGDENxe1H4ZIV4/BinNm5j5O2Il2TPc+H0Y9Acg+jF0 oljtYq8MIMPIbBIVmBZQtf2miNa3ToErHeH6C9rBWd3O157g+KGl3Y44KlvavbO9dzU1n97JP+7f WKnzBgec6GbIfHP3gl0Vqw3S2NxaNpOrqgAqz0/GqOPHbzT9H2OTS8PDAl8AvDzm6pe6cEUXhhRc 3ThhQrvvunA1pgtRCowtJnIoSpcMdMH0QqZYMj8FGACi06gjCg0KZW5kc3RyZWFtDWVuZG9iag00 OSAwIG9iajw8L0xlbmd0aCAyMTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJAMwAM//6 +vpKYKear8vL3OPG2eDI2uHP4Opdda9pfLTW5OrQ3uTV4eXY4+bc5une5+rg6Orf6/LyxdDYGEfh ADPkVHbn197i6uzN3eKHo8ZEYqbE1t/A1t+809220Nyxzdusytqnx9qixNmdwdmRutUuTJpVfrTx 8/jDy+JDWqHs8fLr7/Dv8vPP2uO8x9r29/jx8/Pz9PXo7e/yn7Ltkaf09fapvdI4U57k7vTj7O+l ss85XaIbN4+kt9D////m6+26zNqzxtc/ZacOK4nR1+cCDAAHp5kgCg0KZW5kc3RyZWFtDWVuZG9i ag01MCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDE4OS9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTcgMCBSL1dpZHRoIDEwNC9IZWlnaHQgMy9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KSImEz0kSgjAQBVCUIBIyiLOAIIJBQIkDCirO97+TsVyxoHzL 7v+rqyWp0ZQBUFpqW4MQ6rqOEMaYENoxur0a/cGQUkpEDiHRED04khUFjieyaVm2PXUc1515njef +8HC9wOVheHSwlGcsNU65ZzxDWcUbVkqSMauxt6Q0piQKBM2osESzqKopRyOo++dKc6Louj8mCfN O1/islRBfq246fz6X4ZxWp1o4H58gO87rLpwn6/3R4ABAGB1LUMKDQplbmRzdHJlYW0NZW5kb2Jq DTUxIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMjY0L0ZpbHRlci9GbGF0ZURlY29kZS9C aXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggMTA1L0hlaWdodCAyL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIifr//39s6Xogal987MC1+y/evv////+0xScDs1ZG5q0FimMl D59+BFT26NWbqw+fvv/0GaKFoC6CJC4pIAIaDrTl85evd569BKJv338AuXWT90Fk0RTDGaeu3Acq u/bk1ZFr94/dfGARPG/RkZtABtCney7fBaKNZ28Djfr16xeaUWhmAv118/4roFHLT951z1stbd4P VP/o6UevhOVAtGT7BaD5T959ASoAKubT7sSD5q09Awm6C/eeQIIOYh1+XZQgoOPhQXfj8bMvX78B ucCgwK9r894byEHnHLVw0vqzJ249hATdtgt34EGn5zMLv1GQ1AJMYJaxi4AIGKQAAQYA1mxX+goN CmVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBvYmo8PC9MZW5ndGggMTc0L0ZpbHRlci9GbGF0ZURlY29k ZT4+c3RyZWFtDQpIiQCfAGD/09jpUWqpsc3bvNPd5O70////aXy0DiuJnq3M4urs0N7k7/Lz8fPz 2OPm9PX2Q1qhpbDTwNbfxNbfSmCnlqPJyNrhttDc9vf4+vr6vMfaGzePXIW3OFOew8viRGKm6O3v WW6t1eHls73YxtngrMraXXWvf7HOOV2ih5XE4+zv4Ojqzd3id4m7R26rapfBy9zj7PHyLkyah6PG p8ndp8faAgwAW+FxzgoNCmVuZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAyMjUvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNw YWNlIDE4IDAgUi9XaWR0aCAxMDYvSGVpZ2h0IDUvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJfI9t V8IgAIUDuoitaajh2pssQlGn1er//7bY6jQwTxf4cu/hPOe5IYSyW/DJbwSmdwl40FwLwX2azjAf mwekcrFcPTKm6DoLhieQvCizqq4Z20CHP3qSDppr0Z7UzFCOzTOahalXhin1ss6CoYLNt7vKcW7Y PnY6HBNY+z9p/k2KnJre6YcUObX59iTa89mofex0eH2DEFpz6w/n7+NWlnyoLBdImj9OUi47oxT9 uHAik6JoSddJdenkSUA2XP/cuDmHoeqHgRQ7MU+SitLPyKlCe9oV7kuAAQCpZxuiCg0KZW5kc3Ry ZWFtDWVuZG9iag01NCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDMyMi9GaWx0ZXIvRmxh dGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEwNy9I ZWlnaHQgMi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSImMkbFLAmEYh/+D/pGguaaGNmmJaCgIXBpq aIuWsFFcixoahDQ5gqQkqSGLIMnKLg+kyOtMu7Ow8+LSU5Nbrgc+cDyF3/Dy3e97jvf5AkFp61gm mWI5Jb8Zlu153vxqcmQ04pPESZGa9vUtl/Vaw7rJ65yQhv1rNVvEbjliIN2/HuX1yIU/M7yTJTSd dofrpYq5G7+PJh/rP7bruoKpm5byXiPtTpfm+GzUn3l6+UqtUDXZ7vqlEghK4fgtw5misezRgyrl 1KbTgz8QxY6gYtnSWuJubHpvLpTGkrh4cK4QwRQClzfS/jT2EgLzmkGA4IcIpSz4/PEpwowByqHt qyEFVusmFwuqwV+mFvaBc84JcAEkSKbJ12EeWggkfYFs2hfI++JhICqTU4XAzdTTxGJsckmaWTlE /r8AAwDNP3afCg0KZW5kc3RyZWFtDWVuZG9iag01NSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVu Z3RoIDQvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEvSGVpZ2h0 IDEvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCtnf6goNCmVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmo8 PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxODcvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21w b25lbnQgOC9Db2xvclNwYWNlIDE1IDAgUi9XaWR0aCAxMDcvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0 Pj5zdHJlYW0NCkiJsgiet+jITSDaePY2ED1+8/7///+ReWv5tDvxoKUbLgOV3Xn28urDp+1TjzhH Lbxw7wkQAbkQBpwLRC/egsws79yN30ygOUAEVPngxSuIxkev3gANmbb4JNB8i+B5QNkj1+5DLP38 5StQJVAQv5mb994AKjv/4NW2C3f2XL7rlbC8ffExIAPo0zWnbi0/eRfo8W/ff/z69YugUYdPPwIa BVRfv/FcaN0WPZ9ZQNMePf0IEGAAyUe37AoNCmVuZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmo8PC9T dWJ0eXBlL0ltYWdlL0xlbmd0aCA0L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE1IDAg Ui9XaWR0aCAxL0hlaWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQqzvdgKDQplbmRzdHJlYW0N ZW5kb2JqDTU4IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTkxL0ZpbHRlci9GbGF0ZURl Y29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxNSAwIFIvV2lkdGggMTA3L0hlaWdo dCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIibIInrfoyE0g2nj29ppTtx68ePX////Mmi182p14 0Ly1Z4DK7j1/deTafYvgedMWn7z68CkQnb376MK9J2jo9fsPQMV1k/fhN7N96hEgAqq8//oTxDQI uvbkFZAEWuGStAxoF9Btaw5f+/L1G1Clc9RC/GYu3XAZqOzcvWfbLtzZc/ku0IT2xceADKBPgWj5 8VtAj3/8/OPXr18Ejdpz/BbQKKD6+o3nsqYflDbvD8xaefP+K4AAAwCNVLdDCg0KZW5kc3RyZWFt DWVuZG9iag01OSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDQvQml0c1BlckNvbXBvbmVu dCA4L0NvbG9yU3BhY2UgMTUgMCBSL1dpZHRoIDEvSGVpZ2h0IDEvVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCtPY6QoNCmVuZHN0cmVhbQ1lbmRvYmoNNjAgMCBvYmo8PC9MZW5ndGggMjg1L0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIiQAOAfH+OFOeosTZrMra4Ojq////WW6tDiuJpbDT7PHyfpO+ Q1qhxtngzd3i0N7k6O3vd4m7h5XE77HA1uTqz+Dq3ObppbLPw8vis73Yzt7mttDcmq/Lsc3bp8fa ncHZ9vf4+vr6f7HOGzeP2d/q3ufqaXy0nq3MyNrhh6PG1eHly9zj5z9m6meFyt7ruszaLkyapLfQ 9PX2vMfadaXIirbSKESWkq/NxNbf5uvt4QAz5FR2ytTf8fP4wNbfp8ndhLPPOV2iSmCn4+zvu8XV qb3S4uXxR26rXIW3RGKmvNPd4urs5CZSyKy97/LzP2WnssDV4xBAz5mvydzlXXWvTnWvkbrVmb/Y VX60x9zpZI68apfBAgwATiW+XgoNCmVuZHN0cmVhbQ1lbmRvYmoNNjEgMCBvYmo8PC9TdWJ0eXBl L0ltYWdlL0xlbmd0aCAzOTkvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE5IDAgUi9XaWR0aCAxMDcvSGVpZ2h0IDgvVHlwZS9YT2JqZWN0Pj5zdHJlYW0N CkiJbNFrU4JAFIDhXVosdiFMyzRAAQ1ETcvQMFHJexcry0v9/z/SqjMpq+cjh5l3nzkAQo47Qnzk f47RiYCJuBpJksRTJG930Sg6i8XpZ+lcuuBBAoHt7hIlUylwpXCqqqUzO4sE0nTdwCbQNE7Notx2 c40sYOcty1nHaEoIpQrFEm2JYjIm3WQR3n1iUlHKFUWlqdvMzuIOweq9WzbdWo1TGVUO1x2LjuM4 ovPAqApe4zEu0hX9pRlWxf0K4BSFa0FGBfV2B5iGICiQUQXAFwmx1jXriVV5XqEbXz+FNMOqni2X azW7KvB9xKjaA2BGhsNVKqSSR3jsOGRTe95Ted7La4mGCHkLq+SO62KMQWfQ31MNQN+dTFSNUb37 GPsrGG2RAyrP+/gsTdepkGqqfH1rs8octtLsrdqLoIkNY8aqYqQ+wni8ahFySEWnSKakztxqmQp+ 6KGgNmvuqRZ8hnJ+YSysyo+Jz/O4l9+kDqjoNLpL/xQFu0+0ILBVqM3nNBVW6fogiv4EGABC2EQV Cg0KZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iajw8L0xlbmd0aCAyNTUvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJAPAAD/93ibsbN49HbqudwdnW5Or///9Zbq0OK4mlsNPP4Oq8093A1t/G 2eDJ3OVdda8uTJqlss/Q3uTE1t/i6uyHlcT6+vrqfpfhADPkJlLIrL3H3Onk7vRpfLSSr82KttKn x9qZv9iRutWnyd3Z3+p/sc6Es89Oda84U56ercwoRJaHo8bL3OPg6Op+k77Y4+bGgJ3dDT3f6/Li 5fGywNU/ZaeWvdfx8/jo7e/29/g5XaLO3ua20NyWo8ne5+rV4eXqZ4XDy+Ls8fK8x9pDWqHT2OlK YKdql8G40uOxzdupvdJEYqazxtfYGEf74OZ1pcj09fYCDAD2qqhpCg0KZW5kc3RyZWFtDWVuZG9i ag02MyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDI0MC9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMjAgMCBSL1dpZHRoIDEwNi9IZWlnaHQgNC9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckGtXgkAURQfwiDCD1ASVUiYyhtgDMS01TdPM3v3/f9OT Zuh8vHvdu9e5RNN0o4Sy+ZcKLJsyx6m6W9uc8R0QyTzP3937zX6tHuBAMoLg0G0cGUYzbCHSJIj8 ULSPSSWOXVFSNzqfJtvm3CFJ94TxU5ypJpynuaqXZvAk0/q4GAyN5jBsXaIr58nVqCHaeicajwd6 Vuw0uba/4kwTwtms2Ak3LO3lrjkWkpnVEW4tSukMWCrjMjIhxGpxt17fJ5tip8nDj4o9xk/Pwb9O Fq3XctXLqx8rN1dLfKfvKb8zp9gI8ea+fwgwAFDAH5wKDQplbmRzdHJlYW0NZW5kb2JqDTY0IDAg b2JqPDwvTGVuZ3RoIDE0Ny9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkAhAB7//Hz+FFq qXWlyENaoZajyf///1lurQ4riaWw08vc47HN27bQ3LzT3cbZ4F11ry5MmrO92HeJu4eVxM7e5sDW 38isveQmUuEAM+p+l56tzChEljhTnvr6+oq20n+xzlyFt36Tvk51r6Wyz2l8tMja4azK2oejxsfc 6am90vvg5oSzzzldogIMAFoKVmsKDQplbmRzdHJlYW0NZW5kb2JqDTY1IDAgb2JqPDwvU3VidHlw ZS9JbWFnZS9MZW5ndGggMTI0L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgv Q29sb3JTcGFjZSAyMSAwIFIvV2lkdGggMTA1L0hlaWdodCAzL1R5cGUvWE9iamVjdD4+c3RyZWFt DQpIibzOyxKCMBBEUQJpQDIqiRFFIUZ5Kv//f2BBSaxy7VlOL+54jPkBRxh9xNgkYkKCtmK3TyHX TSkcNOljdpqdwSNXIHmuwot7uhZFacob8/4VgrV3/4FqXXLUTTJ5x7S2Lex3iIi6fillT/fFn1J0 xrwGOQowAJ0WDykKDQplbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9M ZW5ndGggMjQ3L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFj ZSAxNSAwIFIvV2lkdGggMTA0L0hlaWdodCAyL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIidq898bm vTdckpZN3HX11L3X////j8xby6fdiQct3XAZqOzErYfLj99acwqENp69jYy2XbgDQXsu373x+BlQ cXnnbvxmtk89AkRAlafvPIZrh5iw+dj1JyFlDxmM0dCr9Fag+kdPP2q4TMNvONkI4qQ3Hz91bbtU v/Fcy+bzpUtPAMUvXn8OtBeILILnAUWuPXkFVJZZswW/afPWngEqO3bzATzc4AgtAIHozrOXQMV1 k/cRGW4n7zxFDjdILABNXpvRhxl0n+ZvggRdYNZK6oaYtHn/tMUngYb/+vVr7sGbwECDhJt96nJg NAFtBAgwAKWkOYMKDQplbmRzdHJlYW0NZW5kb2JqDTY3IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9M ZW5ndGggMTQzL0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFj ZSAxNSAwIFIvV2lkdGggMTAyL0hlaWdodCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiYrMWxvT uv3ak1f///8PzFrJp92JB81bewao7MC1+4uO3Fx+/BYcrTmFBUHMLO/cjd/M9qlHgAio8sSthxvP 3oYjiCFAxrYLd441zL3La/uQwRiOgNxP8zcBdX37/gPoKj2fWUCE3yKCKLNmCxBdvvESYizQj/Ub zwFRy+bzKX17IAqA4gABBgBMA59TCg0KZW5kc3RyZWFtDWVuZG9iag02OCAwIG9iajw8L0xlbmd0 aCAyMTAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJAMMAPP+lsNM4U57P4Or///93ibsb N48oRJbA1t+ixNmnx9qnyd2sytrW5OqHlcSWo8nG2eDPma/YGEfhADPqZ4X97/L29/i8x9ppfLQu TJoOK4lDWqHi5fHc5umWvdd/sc6zvdjk7vS40uOdwdmerczLKlftkaf74ObZ3+pZbq1KYKdRaqld da/Dy+Ls8fLf6/KEs88/ZaeHo8bx8/jO3ubT2OnH3Onz9PXx8/Pv8vPe5+r6+vqpvdK+RnDjEEDk VHbyxdBHbqsCDAD6XIhdCg0KZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iajw8L1N1YnR5cGUvSW1h Z2UvTGVuZ3RoIDE5MS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9y U3BhY2UgMjIgMCBSL1dpZHRoIDEwMS9IZWlnaHQgMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlc ztsWgUAYhuHyN5pmkm0qkYqEjE0ie+7/qkyjZdGz5mi+g/eX5BooCNVLEqgYY40jlNOh8Z2QYUCT lkir3Sl0e2CafctGzi80MFwAGI48znbGvh3AHzXEZUajmg6VkfI24RdgMpmKSjuazfgQSw1rvuCW iWKsGP9Zr2mR2Gzrsmsmu9Rn+yxlPmOxy1gQiooo4cMxT0/inVdZnl9UEdeKkVxvotK53x/Rs3LM MAg979OQXwq8BRgAwnkWmQoNCmVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmo8PC9TdWJ0eXBlL0lt YWdlL0xlbmd0aCA0Ny9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1hZ2VNYXNrIHRydWUvQml0c1Bl ckNvbXBvbmVudCAxL1dpZHRoIDkzL0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDkzPj4vSGVp Z2h0IDM5L1R5cGUvWE9iamVjdD4+c3RyZWFtDQrL292779vdu+93tlQDGyMAvshhqXCDthB7BA+n Yg7e7Dp06DrTp0HTp+OACACACg0KZW5kc3RyZWFtDWVuZG9iag03MSAwIG9iajw8L1N1YnR5cGUv SW1hZ2UvTGVuZ3RoIDE4MDMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDE1IDAgUi9NYXNrIDcwIDAgUi9XaWR0aCA5My9IZWlnaHQgMzkvVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCkiJ7NfNi1d1FMfx/oCKlkH7CII2LaxFFCQJ1aYHiCJBgh4X0qbahK5E3BQV arRQSk0kxdJIyBRBnfIpp8ynQcdxZpzRURudURND6vXzo19ud2bUdMYZ8PflcLm/7+8+nPP+fs45 3ztzZnOMOP7u6BnY3MrG25EJNDApWJpkyrhwaQwsXBU+bLw9mhAjWHr3tvfNmH/hyhhvpybEwCRY +r/b8M+VMd5OTYiBSRPL0BEUyHS/+H4zlcoIFp2o654nlN/YeDs1IcZlwbw5C5lmVyojWC72Dxy+ 4+FmKlUHJkyFQUYSNctvGWlJTSy1EQ4nP1mKTO/jb1w8NRgbb7/GeQSLYrvv3inI4NPUTEZ6UFKp kU2j/RVZivnpwfPH+0+dOD3Q1XOy88jpYiaZf63Fub/Os9F69U2O1N7u+58frVTqOX6SbdzWeaEy rh8L23+oj41ijDcwLu/uFq6KYGxm/m8qJXCBrF63L0yCZcGK7bPnbnr7w+/Zy9NXsKnvrcwJe+6d ZdWZD+asZUu+3eXGYGHOf9vbW8U7liT+M8oeJoJh1/+5ZKGLw8Ey47P1T09b+uQrXyZSWOYt2sIW r2n96ee2tZt3i3TrH4d2tnU5ZmbVht1LVu10TcjA5XYP8aihWIwzZ8/dEjCX8wiNYMHnmlvfon80 RATCQ89+4YiDMHftO0YwR0/2y5rTg4Mx5zHzMbdXT7pO9Hcc7dvX1YMYPnc/OAcfRmwey7wLk1j/ wK3omCGjtlwmM8LWV+KXskAboXHfpI9FIRbeuoDDJd6qAdV9/ESxzr6G4VCsvbfvQM8xlp/JL4qa vaiFhBgJmTTjFbGxzqykTBHMsP069RAQC8fDBybPs6A8p43oYVgaQ+EUPjUysPhJM5EZPqTiXcLf ffgI+3F7W0lS854z1jUn4Xt+EYyvyNKvxSt2FiCpoo+8sED6hNXgmbMMmRxjZbJYljjZV4UTFEwx UWfIo5E1i1pAIEU0XMCAgg6fL1ZuSwniQFHvGO24gh2Eg3c9VopMkksUHMABDcmienCJ/5Ldz3Qc IUglIi9W+gvzrye4ReDqrQJCD5IuuEQKAuBeUbCnf9EkSxJ5jle3tnd3/3nGE5Rxk1kdjxq7vWge q0eXVFJk2JTp3/AQAQuqd1hBrppJy3AiBIGX2DnMCq5CrHSZdGfzuTKdy42CLRIiDJkFQlgFl/PJ r33tsS37O1yw42An5bjdA6s7pbHAogHJoEKGrXjro+Ub9wiNA5jwQfgWDijbM24kAXOUU9V+WtLT kTBE6i5s05E9UIFiUQLZYEKcSRmGTwJn/t205xAmzvFxAsue7j6I3G4G55JTowsnqq4KJjbtpc+5 kUB4nvCTBaUvxGrFpFpV8jMNKz0rxVNz8eTUUqIis1/aDoPjRciQUJJI1MEVkUQ5y9b9jgxRWbjQ g310ZZNHpdAtvvOZKpZsZmRTymzKpvpQQ5EyW7VavWXuci84IhKF2ntp/z8oQxvteO6mVAx85BcI rk+umRQySiAUkUhnDm870LWzo8/RuT2DzUP5lLhJJukFnCFp71r/1Ls1wayb9LoF5U96cY1J4VB2 XGwkOO7FP9XYZOna2f5JNFmWvGjIaVGLKs1SjoCCJWSIB9tHp36l7GzYc4iKwFGjkmI+tWI3XIfz DZJM9wopzMnSrIthJZxsVqtMQqAKpGaFTMHCVUtAe9FJbTPjxKRiIqGSXDHxAoIGAmqRVAItS+mv fGpFbGaceMgNdyjKZLRHJOCXrbjdnWZd+jVz7qMyZSFMqgopuq3aSGSiFqsfLKy2x3M06QkmwWEJ No0slKp9MP6j9OnKHY6IpVeW5L0BJtkb2LCl0PEKFmuq9tbKb4PM5lbe+veaTGpwqmRgyceU+drX QXa5sKxu2RsxRAMKbMgofY2vgF0HyYlsfm3vkTt+ggB1mTTjMpMlm66Tie9ThrOnBUX24Vky1ru3 ndX6tfJrUlxDmVwYMoaSYbA4WoUkRYpwkgsW2ZGWl7xQJWiYKS8uTuzJlEbZ6Wi0IZ0LBxgjmC0H jig1sDh5ddaaqmYwvzqT1BNMKNDF+SopWLJwKSO+j2pFRtkRSIK9CpManKpmeGgmO2GJ72lp0yQh CnmhcoqXS/7KGim2XMrOUL0lNs7jkw0PMhBhAhcgweLIkk3VT7ORmOTfOJBczhdHFQvxpBEPW34l VzVNrsJkJCzm5W+6Bs/zcaERe3tkk71uti7F7GZdSRj+0hrckh6tX8sdM4LyM0nEfmg9wPIxkpyN DWUSV6NDL8p+cigWltYpK9WTWio1yMyYHyAj7WyHTSVYMmmJs0dSLiw96abyBEg8iWOFiVv8jMac +Ek22dqhYUfnJ8E4j04KluVb21KlLcFIm70mlmGxhMxtjuWa/eh2Hv8KMAB4VHtfCg0KZW5kc3Ry ZWFtDWVuZG9iag03MiAwIG9iajw8L1N0ZW1WIDEzNi9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFMt Qm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNjZW50 IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50IDg5MS9Gb250RmFtaWx5 KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVz Y3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUg ODQyXS9QYXJlbnQgNiAwIFIvQ29udGVudHMgMyAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5 NSA4NDJdL1Jlc291cmNlcyAyIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9iajw8L0NvbG9y U3BhY2U8PC9DczYgMTUgMCBSPj4vRm9udDw8L1RUNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MxIDI0IDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggNjU2 L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWRUXW/bIBR996+4jyANavztx63NpkzdOrX0 aZkm1yYxk4Mj4zTqH9nv3QWiONsSyebC5dxzDhfffHoSsLPRBxndSJmBALmNaojxX0NS1byuoKwF r7I4BbmPbm5tAa31CTHY1kQxj+M4Adn6UYoAp4gwSIABlb8ilvISGAKIFAHuoviSmbrM7+T24QuI An7D/RMIWvCSJBlGK6A/5OeodARcKT/IcRlSHJ7ZeJzcIwawNc0RQOIzJc/sKthsaMqFK4ZhRhh1 lP5Zo6zgCXnAoCYhTRSbzb3PecJZlymSbOUnuE+4o04febgNbEXiueLLMy3zmCfFQlV4m5gf1oHw 3DczzL2CdtwfBjUr6KhjoWhMXtUw+uCwpzVRZga1pRnG4TlSgc9phpMeBnhRcGqsJzXTjKjOE0pi 7uxzvrtjqi713dDVh1OvDBLQuJXA+tujI0IrXiADTMyIhXmEQe96hK4QGn3LCDRb9ANDNfm3V2Dn xnTN1PnE4Afz9XGLyC8c0oXDuQO0hcPxZdC2Vx335oJEvLV8ZhIO09gqa5WFvnnFIs1W7Y6uylle XOZBYLA1IFrQhh2GplWgt9CAGQ1zqpyvzNELwQtlmVM6IbYN4odGhzUb5KM/uu0XNa7c33qWM3VD 7H304i2ciRlntK5Vxip3FSoeV2ey8dIIYROMBh7ff70DtHRvOYS7E3ZgvWKpJ5Z64a6tDZ6ZaYej 1aN5BydshPE4dDApjWANttR4nKBTVk/Kw4qSV+lVV+QLmfLclSM01mobWnO9ktiGKfmIDVcStNa7 gdzy/ArlP154VrO22zdtdh5Gm+5o5+mNB201enkl7XKJyc/rX8gVBX4/rowgfnoloz8CDABjsysF Cg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvTnVtc1swIDUgMCBSXT4+DWVuZG9iag01IDAg b2JqPDwvUy9EPj4NZW5kb2JqDTYgMCBvYmo8PC9Db3VudCAyL1R5cGUvUGFnZXMvS2lkc1sxMSAw IFIgMSAwIFJdPj4NZW5kb2JqDTcgMCBvYmo8PC9TdWJ0eXBlL1hNTC9MZW5ndGggMzU0MC9UeXBl L01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6 cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1w dGs9IjMuMS03MDEiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8i PgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDcuMC41IChXaW5kb3dz KTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5QU2NyaXB0NS5kbGwg VmVyc2lvbiA1LjIuMjwveGFwOkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+ MjAwOS0xMS0xMFQxMDo0Njo1MyswMTowMDwveGFwOk1vZGlmeURhdGU+CiAgICAgICAgIDx4YXA6 Q3JlYXRlRGF0ZT4yMDA5LTExLTEwVDEwOjQ2OjUzKzAxOjAwPC94YXA6Q3JlYXRlRGF0ZT4KICAg ICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIi CiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+ CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgICAg IDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkg eG1sOmxhbmc9IngtZGVmYXVsdCI+TWljcm9zb2Z0IFdvcmQgLSBscy0xMjQuZG9jPC9yZGY6bGk+ CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRj OmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPmFu Z2VsZXM8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0 b3I+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1aWQ6ODNmMDUyMWItZjBlNS00 YzQxLWJjMzAtM2VlNzEzODY1Y2I0PC94YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06 SW5zdGFuY2VJRD51dWlkOmUwYTkwNmNiLTk1OTMtNDRmNi1hZmI2LTg4YWVmN2FkODA2MjwveGFw TU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94 OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqPDwvQ3Jl YXRpb25EYXRlKEQ6MjAwOTExMTAxMDQ2NTMrMDEnMDAnKS9BdXRob3IoYW5nZWxlcykvQ3JlYXRv cihQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMikvUHJvZHVjZXIoQWNyb2JhdCBEaXN0aWxsZXIg Ny4wLjUgXChXaW5kb3dzXCkpL01vZERhdGUoRDoyMDA5MTExMDEwNDY1MyswMScwMCcpL1RpdGxl KE1pY3Jvc29mdCBXb3JkIC0gbHMtMTI0LmRvYyk+Pg1lbmRvYmoNeHJlZg0KMCA5DQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMjg1MzEgMDAwMDAgbg0KMDAwMDAyODY1NiAwMDAwMCBuDQowMDAw MDI4NzY1IDAwMDAwIG4NCjAwMDAwMjk0ODkgMDAwMDAgbg0KMDAwMDAyOTUyMiAwMDAwMCBuDQow MDAwMDI5NTQ1IDAwMDAwIG4NCjAwMDAwMjk2MDIgMDAwMDAgbg0KMDAwMDAzMzIxOCAwMDAwMCBu DQp0cmFpbGVyDQo8PC9TaXplIDk+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= --Apple-Mail-1-411169416 Content-Disposition: attachment; filename=ls-124.doc Content-Type: application/msword; name="ls-124.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVAAAAAAAAAAA EAAAVgAAAAEAAAD+////AAAAAFMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJ2AJBAAA+BK/AAAAAAAAMAAAAAAABgAApRQAAA4AYmpiauvI68gAAAAAAAAAAAAAAAAAAAAA AAAJBBYAOzgAAImiAACJogAA1goAAAAAAADOAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwFAAAAAAAA/AUAAPwF AAAAAAAA/AUAAAAAAAD8BQAAAAAAAPwFAAAAAAAA/AUAABQAAAAAAAAAAAAAABAGAAAAAAAAPBkA AAAAAAA8GQAAAAAAADwZAAA4AAAAdBkAACQAAACYGQAAZAAAABAGAAAAAAAAGyMAAPIAAAAIGgAA OgAAAEIaAAAWAAAAWBoAAAAAAABYGgAAAAAAAFgaAAAAAAAANxsAAKgAAADfGwAAVAAAADMcAAAs AAAAmiIAAAIAAACcIgAAAAAAAJwiAAAAAAAAnCIAAAAAAACcIgAAAAAAAJwiAAAAAAAAnCIAACQA AAANJAAAaAIAAHUmAAD4AAAAwCIAABUAAAAAAAAAAAAAAAAAAAAAAAAA/AUAAAAAAAC4HgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAzGwAABAAAADcbAAAAAAAAuB4AAAAAAAC4HgAAAAAAAMAiAAAAAAAA AAAAAAAAAAD8BQAAAAAAAPwFAAAAAAAAWBoAAAAAAAAAAAAAAAAAAFgaAADbAAAA1SIAABYAAABy IAAAAAAAAHIgAAAAAAAAciAAAAAAAAC4HgAAWAAAAPwFAAAAAAAAWBoAAAAAAAD8BQAAAAAAAFga AAAAAAAAmiIAAAAAAAAAAAAAAAAAAHIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAuB4AAAAAAACaIgAAAAAAAAAAAAAAAAAAciAAAAAAAAAAAAAA AAAAAHIgAAAAAAAA/AUAAAAAAAD8BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAciAAAAAAAABYGgAAAAAAAPwZAAAMAAAAkBAA6d5h ygEAAAAAAAAAADwZAAAAAAAAEB8AAFgAAAByIAAAAAAAAAAAAAAAAAAA1iAAAMQBAADrIgAAMAAA ABsjAAAAAAAAciAAAAAAAABtJwAAAAAAAGgfAACyAAAAbScAAAAAAAByIAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAG0nAAAAAAAAAAAAAAAAAAD8BQAAAAAAAHIgAABkAAAAXxwAAJIAAADxHAAAaAAAAHIg AAAAAAAAWR0AAFQAAACtHQAACwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXxwA AAAAAABfHAAAAAAAAF8cAAAAAAAAwCIAAAAAAADAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGiAAAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8cAAAA AAAAXxwAAAAAAABfHAAAAAAAABsjAAAAAAAAuB4AAAAAAAC4HgAAAAAAALgeAAAAAAAAuB4AAAAA AAAAAAAAAAAAABAGAAAAAAAAEAYAAGQAAAB0BgAA5AkAAFgQAADkCAAAEAYAAAAAAAAQBgAAAAAA AHQGAAAAAAAAWBAAAAAAAAAQBgAAAAAAABAGAAAAAAAAEAYAAAAAAAD8BQAAAAAAAPwFAAAAAAAA /AUAAAAAAAD8BQAAAAAAAPwFAAAAAAAA/AUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHSU5U RVJOQVRJT05BTCBURUxFQ09NTVVOSUNBVElPTiBVTklPTgdDT00gMTYgliBMUyAxMjQgliBFBwcH VEVMRUNPTU1VTklDQVRJT04LU1RBTkRBUkRJWkFUSU9OIFNFQ1RPUg1TVFVEWSBQRVJJT0QgMjAw OS0yMDEyBwcHBwdFbmdsaXNoIG9ubHkNT3JpZ2luYWw6IEVuZ2xpc2gHB1F1ZXN0aW9uKHMpOgcx MC8xNgdHZW5ldmEsIDI2IE9jdG9iZXIgLSA2IE5vdmVtYmVyIDIwMDkHB0xJQUlTT04gU1RBVEVN RU5UBwdTb3VyY2U6B0lUVS1UIFN0dWR5IEdyb3VwIDE2BwdUaXRsZToHUmVwbHkgTFMgdG8gSUVU RiBvbiBzcGVlY2ggYW5kIGF1ZGlvIGNvZGluZyBzdGFuZGFyZGl6YXRpb24HB0xJQUlTT04gU1RB VEVNRU5UBwdGb3IgYWN0aW9uIHRvOgdJRVRGIFJBSSwgSUVTRwcHRm9yIGNvbW1lbnQgdG86By0H B0ZvciBpbmZvcm1hdGlvbiB0bzoHLQcHQXBwcm92YWw6B0FncmVlZCBhdCBJVFUtVCBTRyAxNiBt ZWV0aW5nIChHZW5ldmEsIDI2IE9jdG9iZXIgliA2IE5vdmVtYmVyIDIwMDkpBwdEZWFkbGluZToH TWFyY2ggMjAxMAcHQ29udGFjdDoHSGVydmUgVGFkZGVpC0h1YXdlaSBUZWNobm9sb2dpZXMLQ2hp bmEHVGVsOgkrNDkgMTYyIDI5NDAgMjYwC0VtYWlsOgkTIEhZUEVSTElOSyAibWFpbHRvOmhlcnZl LnRhZGRlaUBodWF3ZWkuY29tIiABFGhlcnZlLnRhZGRlaUBodWF3ZWkuY29tFQcHQ29udGFjdDoH WXVzdWtlIEhpd2FzYWtpC05UVAtKYXBhbgdUZWw6CSs4MSA0MjIgNTkgNDgxNQtGYXg6CSs4MSA0 MjIgNjAgNzgxMQtFbWFpbDoJEyBIWVBFUkxJTksgIm1haWx0bzpoaXdhc2FraS55dXN1a2VAbGFi Lm50dC5jby5qcCIgARRoaXdhc2FraS55dXN1a2VAbGFiLm50dC5jby5qcBUHBwcHU3R1ZHkgR3Jv dXAgMTYgdGhhbmtzIElFVEYgUkFJIEFyZWEgZm9yIHRoZWlyIExpYWlzb24gU3RhdGVtZW50Lg1S ZWZlcnJpbmcgdG8gdGhlIHRocmVlIG1haW4gY3JpdGVyaWEgcmVmZXJyZWQgdG8gaW4geW91ciBs aWFpc29uIHN0YXRlbWVudCwgU3R1ZHkgR3JvdXAgMTYgd2lzaGVzIHRvIGJyaW5nIHRoZSBmb2xs b3dpbmcgdG8gdGhlIGF0dGVudGlvbiBvZiBJRVRGIFJBSS4NU3R1ZHkgR3JvdXAgMTYgaGFzIGEg bWF0dXJlIGFuZCBwcm92ZW4gZGV2ZWxvcG1lbnQgcHJvY2VzcyBmb3Igc2VsZWN0aW5nIGFuZCBz dGFuZGFyZGl6aW5nIHNwZWVjaCBhbmQgYXVkaW8gY29kZWNzIGFjY29yZGluZyB0byBhIGRldGFp bGVkIHNldCBvZiB0ZWNobmljYWwgcmVxdWlyZW1lbnRzLiBXZSBiZWxpZXZlIHRoYXQgdGhpcyBk ZXZlbG9wbWVudCBwcm9jZXNzLCByZWZpbmVkIG92ZXIgbWFueSBzaW1pbGFyIGV4ZXJjaXNlcywg aGFzIGRlbW9uc3RyYXRlZCB0aGF0IGl0IGNhbiBzdWNjZXNzZnVsbHkgc2VsZWN0IGNvZGVjcyB0 aGF0IG1lZXQsIG9yIGluZGVlZCBleGNlZWQsIHRoZSBvcmlnaW5hbCB0ZWNobmljYWwgcmVxdWly ZW1lbnRzLiBSZXBsaWNhdGluZyBvciByZWludmVudGluZyB0aGlzIGV4cGVydGlzZSBzaG91bGQg bm90IGJlIHVuZGVyZXN0aW1hdGVkIGJ5IGEgZ3JvdXAgd2lzaGluZyB0byBkZXZlbG9wIGEgY29k ZWMuIA1JdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJl dmVudCBhIHJveWFsdHktZnJlZSBjb2RlYyBiZWluZyBzZWxlY3RlZCBhcyBwYXJ0IG9mIHRoZSBj b2RlYyBkZXZlbG9wbWVudCBwcm9jZXNzIHdpdGhpbiBJVFUtVC4gSW4gZmFjdCwgc2V2ZXJhbCBy b3lhbHR5LWZyZWUgY29kZWNzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIGZvcm0gcGFydCBvZiB0 aGUgY29kZWMgcG9ydGZvbGlvIG9mIHRoZSBJVFUtVC4gSG93ZXZlciwgYSBub24tdGVjaG5pY2Fs IHJlcXVpcmVtZW50LCBzdWNoIGFzIHJveWFsdHktZnJlZSwgY2Fubm90IGJlIHNwZWNpZmllZCBh cyBwYXJ0IG9mIHRoZSBUZXJtcyBvZiBSZWZlcmVuY2UgZm9yIGEgY29kZXIuIFdlIG1ha2UgcmVm ZXJlbmNlIHRvIHRoZSBJUFIgcG9saWN5IG9mIHRoZSBJVFUtVCAoEyBIWVBFUkxJTksgImh0dHA6 Ly9pdHUuaW50L0lUVS1UL2lwci8iIAEUaHR0cDovL2l0dS5pbnQvSVRVLVQvaXByLxUpLg1XaGVu IGRldmVsb3BpbmcgYSBuZXcgY29kZWMsIFNHMTYgYWdyZWVzIHRoYXQgZWxpbWluYXRpbmcgM3Jk LXBhcnR5IElQUiBpcyBhbG1vc3QgaW1wb3NzaWJsZS4gSG93ZXZlciB0aGUgaW1wYWN0IG9mIHRo aXMgM3JkLXBhcnR5IElQUiBpcyBzaWduaWZpY2FudGx5IGxlc3Mgb2YgYSBwcm9ibGVtIHdpdGgg Y29kZWMgZGV2ZWxvcG1lbnRzIHdoZXJlIHRoZXJlIGlzIG5vIHVwLWZyb250IGdvYWwgdG8gYWNo aWV2ZSBhIHJveWFsdHktZnJlZSByZXN1bHQgYXQgdGhlIGVuZC4gSW4gY2FzZXMgd2hlcmUgcm95 YWx0eS1mcmVlIGlzIGFuIHVwLWZyb250IHJlcXVpcmVtZW50IHRoZW4gdGhlcmUgaXMsIGluIG91 ciB2aWV3LCBhbiB1bmFjY2VwdGFibHkgaGlnaCByaXNrIHRoYXQgdGhlIGNvbXBsZXRlIGRldmVs b3BtZW50IGVmZm9ydCB3aWxsIGJlIHdhc3RlZCB3aGVuIHRoaXMgSVBSIGNvbWVzIHRvIGxpZ2h0 IGFmdGVyIHRoZSBzdGFuZGFyZCBpcyBwdWJsaXNoZWQuIFRoZSBJVFUtVCBwcm9jZXNzZXMgaGF2 ZSBzYWZlZ3VhcmRzIGluLXBsYWNlIGlmIGEgbm9uLW1lbWJlciBoYXMgSVBSIGNsYWltcyB3aGlj aCB0aGV5IHdpbGwgbm90IGxpY2Vuc2Ugb24gUkFORCB0ZXJtcy4gDUluIGNvbmNsdXNpb24sIHdl IHdvdWxkIHJlaXRlcmF0ZSBvdXIgZGVzaXJlIHRvIGFzc2lzdCB0aGUgSUVURiBpbiBzYXRpc2Z5 aW5nIHRoZSBpbmR1c3RyeS4NX19fX19fX19fX19fXw0NAw0NBA0NAw0NBA0NLSATIFBBR0UgIFwq IE1FUkdFRk9STUFUIBQyFSAtDUNPTSAxNiCWIExTIDEyNCCWIEUNDUlUVS1UXENPTS1UXENPTTE2 XExTXDEyNEUuRE9DDQ1BdHRlbnRpb246IFNvbWUgb3IgYWxsIG9mIHRoZSBtYXRlcmlhbCBhdHRh Y2hlZCB0byB0aGlzIGxpYWlzb24gc3RhdGVtZW50IG1heSBiZSBzdWJqZWN0IHRvIElUVSBjb3B5 cmlnaHQuIEluIHN1Y2ggYSBjYXNlIHRoaXMgd2lsbCBiZSBpbmRpY2F0ZWQgaW4gdGhlIGluZGl2 aWR1YWwgZG9jdW1lbnQuIA1TdWNoIGEgY29weXJpZ2h0IGRvZXMgbm90IHByZXZlbnQgdGhlIHVz ZSBvZiB0aGUgbWF0ZXJpYWwgZm9yIGl0cyBpbnRlbmRlZCBwdXJwb3NlLCBidXQgaXQgcHJldmVu dHMgdGhlIHJlcHJvZHVjdGlvbiBvZiBhbGwgb3IgcGFydCBvZiBpdCBpbiBhIHB1YmxpY2F0aW9u IHdpdGhvdXQgdGhlIGF1dGhvcml6YXRpb24gb2YgSVRVLgcHDQ0NDQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAAACCAAA KAgAADsIAAA8CAAAPggAAGcIAAB0CAAAfQgAAH4IAAB/CAAAgQgAAIIIAACgCAAAoQgAAKIIAACv CAAAsQgAALQIAADbCAAA9ggAAAoJAAAMCQAAEgkAAFAJAABjCQAAcgkAAHYJAAB6CQAAgQkAAJIJ AACUCQAAqQkAAKsJAAC2CQAA8erh2tDqxOG+tKrqxKGV6qrqkeqqkeqq6oV3bGRsd2x3bHcAAAAA AAAAAAAAAAAAAAAAAAAAAAAOFmh8UCsAbUgJBHNICQQAFBVok0HxABZofFArAG1ICQRzSAkEABoV aKoudgAWaHxQKwA1CIFcCIFtSAkEc0gJBAAXFWiqLnYAFmh8UCsANQiBbUgJBHNICQQGFmh8UCsA ABYVaHxQKwAWaHxQKwA1CIFDShwAXAiBABAWaHxQKwA1CIFDShwAXAiBABIVaHxQKwAWaHxQKwA1 CIFcCIEAExVofFArABZofFArADoIgUNKFAAKFmh8UCsAQ0oUAAAWFWh8UCsAFmh8UCsANQiBQ0oa AFwIgQATFWh8UCsAFmh8UCsANQiBQ0ocAA0WaHxQKwA1CIFDShwAEBVofFArABZofFArAENKFAAA DBVofFArABZofFArAAAcA2oAAAAAFWh8UCsAFmh8UCsANQiBQ0okAFUIASMABgAAAggAACgIAAA8 CAAAPQgAAD4IAABnCAAAfggAAH8IAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAACJAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAGtkIBgAABYkARckAUlmAQAAAAKW OQADNAEI1kYAA8f/UAV5GYomYAaJBQAAAAAAAAAAAAAAAAAAAAAABikUAAAAAAAAAAAAAAAAAAAA AAAGEQ0AAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA /wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEM AAADJAIWJAFJZgEAAABhJAJnZHxQKwAJAAAWJAFJZgEAAABnZHxQKwAACAAGAADWEgAApBQAAP7+ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECfwgAAIAIAACBCAAAgggA AI8IAAChCAAAnAAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAhwAAAAAAAAAA AAAAAIcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQCFiQBSWYBAAAAYSQCZ2R8UCsACQAAFiQB SWYBAAAAZ2R8UCsAAGIAAGtkqRgAABYkARckAUlmAQAAAAKWOQADNAEHlGMBCNZGAAPH/1AFGBWK JiAGiQUAAAAAAAAAAAAAAAAAAAAAYAbIDwAAAAAAAAAAAAAAAAAAAAAABnIRAAAAAAAAAAAAAAAA AAAAABT2A8MmF/YDAAAY9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8A AAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAWhCAAAoggAAK8IAAC1CAAA 2ggAAJwAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAIWJAFJZgEAAABhJAJnZHxQKwAJAAAWJAFJ ZgEAAABnZHxQKwAAYgAAa2Q7GQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUDAMI1kYAA8f/UAUYFYom IAaJBQAAAAAAAAAADAEAAAAAAAAgBsgPAAAAAAAAAAAMAQAAAAAAAIAGchEAAAAAAAAAAAwBAAAA AAAAFPYDwyYX9gMAABj2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAA AP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEABNoIAADbCAAA7QgAAO4IAAD2 CAAACwkAAJwAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAAAUwAAAAAAAAAAAAAAAEoAAAAAAAAAAAAA AABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZHxQKwAAPAAAa2RpGgAAFiQBFyQBSWYBAAAA ApY5AAM0AQeUZQEI1hoAAcf/iiYABsMmAAAAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY9gMAABrW BAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQoDOQBh9gMAAGY0AQwAAAMkARYkAUlmAQAA AGEkAWdkfFArAABiAABrZOEZAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWRgADx/8YBjgTiiYA BlEGAAAAAAAAAAAAAAAAAAAAAAAGIA0AAAAAAAAAAAAAAAAAAAAAAAZSEwAAAAAAAAAAAAAAAAAA AAAU9gPDJhf2AwAAGPYDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA /wAAAP8d1gwAAAD/AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AQAFCwkAAAwJAAATCQAATwkAAFAJ AABiCQAArwAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAA AEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADAAAAyQBFiQBSWYBAAAAYSQBZ2T6c1wAAE8AAGtkNxsAABYkARckAUlmAQAA AAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAMAQAAAAAAAAAGciAAAAAAAAAAAAwB AAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYI AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AQsAABSkeAAWJAFJZgEAAABnZHxQKwAATwAAa2TFGgAA FiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/GAaKJgAGUQYAAAAAAAAAAAAAAAAAAAAAAAZy IAAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYI AAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAViCQAAYwkAAHIJAACBCQAAggkA AJIJAACUCQAAvwAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAWgAAAAAAAAAA AAAAALYAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJGAAWJAFJZgEAAABnZPpzXAAAUgAAa2QnHAAA FiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/TwiKJgAGiAgAAAAAAAAAAAAAAAAAAAAAAAY7 HgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYI AAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6c1wACRYAFiQBSWYBAAAAZ2T6 c1wACQAAFiQBSWYBAAAAZ2T6c1wAAD8AAGtktxsAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYa AAHH/4omAAbDJgwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzW BAAAAP8d1gQAAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAAABpQJAACVCQAAqQkAAKsJAACsCQAA tgkAAPsJAACsAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAABHAAAAAAAAAAAA AAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUgAAa2QXHQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/TwiKJgAGiAgA AAAAAAAAAAAAAAAAAAAAAAY7HgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/ AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6 c1wACRcAFiQBSWYBAAAAZ2T6c1wACQAAFiQBSWYBAAAAZ2T6c1wAAFIAAGtknxwAABYkARckAUlm AQAAAAKWOQADNAEHlGUBCNYwAALH/08IiiYABogIAAAAAAAAAAAAAAAAAAAAAAAGOx4AAAAAAAAA AAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/ HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNcAAAGtgkAANUJAAD6CQAA+wkAAAYKAAAR CgAAGwoAACcKAAAoCgAAOwoAADwKAABCCgAARwoAAFcKAABYCgAAXgoAAF8KAABgCgAAjAoAAI0K AACOCgAApQoAAKYKAACnCgAAsQoAAMAKAADBCgAAxAoAAMUKAADPCgAA0AoAAN8KAADgCgAA5AoA AOUKAAD0CgAA9QoAAPsKAAD8CgAA/QoAAC8LAAAwCwAAMQsAAE4LAABPCwAAUAsAAFELAABTCwAA KwwAAPbu4NLH0sC8wLzAuMC8wLitwKKtma3A0sC8wLzAuMC8wLjAvMC4rcCOrZmtwNKBvAAAAAAA AAAAAAAAAAAAGBVoqi52ABZofFArAENKEgBtSAkEc0gJBAAVAgiBA2rwHwAABggBFmh8UCsAVQgB EBVouw5GABZofFArADBKFAAAFQIIgQNqjR4AAAYIARZofFArAFUIARUDagAAAAAVaLsORgAWaHxQ KwBVCAEGFmjDR8MAAAYWaHxQKwAADBVouw5GABZofFArAAAUFWiTQfEAFmh8UCsAbUgJBHNICQQA GhVoqi52ABZofFArADUIgVwIgW1ICQRzSAkEABoVaMohRAAWaHxQKwA1CIFcCIFtSAkEc0gJBAAP FWjKIUQAFmh8UCsANQiBEhVoyiFEABZofFArADUIgVwIgTD7CQAA/AkAAAYKAAARCgAAEgoAABsK AABCCgAApwoAAKwAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAACjAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFIAAGtkBx4AABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/08IiiYABogIAAAA AAAAAAAMAQAAAAAAAAAGOx4AAAAAAAAAAAwBAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNc AAkTABYkAUlmAQAAAGdk+nNcAAkAABYkAUlmAQAAAGdk+nNcAABSAABrZI8dAAAWJAEXJAFJZgEA AAACljkAAzQBB5RlAQjWMAACx/9PCIomAAaICAAAAAAAAAAAAAAAAAAAAAAABjseAAAAAAAAAAAA AAAAAAAAABT2A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAAAB6cKAACoCgAAsQoAAMsKAABQCwAAmQAA AAAAAAAAAAAAAJAAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk+nNcAABl AABrZFQfAAAWJAEXJAFJZgEAAAACljkAAzQBB5TMAAjWRgADx/8YBkIXiiYABlEGDAEAAAAAAAAA AAAAAAAAAAAGKhEMAQAAAAAAAAAAAAAAAAAAAAZIDwwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAA GPYDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/ AAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AXl0+nNcAAAEUAsAAFELAABSCwAAUwsAAJQLAAArDAAA DQ4AAJkAAAAAAAAAAAAAAACOAAAAAAAAAAAAAAAATgAAAAAAAAAAAAAAAEMAAAAAAAAAAAAAAAA6 AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAAAAEAABnZHxQKwAACAAADcYFAAGnJQJnZHxQKwAACgAA DcYFAAGnJQITpPAAZ2TDR8MAAD8AAGtkXyEAABYkARckAUlmAQAAAAKWOQADNAEHlMwACNYaAAHH /4omAAbDJgwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAA AP8d1gQAAAD/NNYGAAEKAzkAYfYDAABmNAF5dPpzXAALAAATpAAAFiQBSWYBAAAAZ2T6c1wAAGUA AGtkwyAAABYkARckAUlmAQAAAAKWOQADNAEHlMwACNZGAAPH/xgGQheKJgAGUQYMAQAAAAAAAAAA AAAAAAAAAAYqEQwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY 9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8A AAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBeXT6c1wAAAYrDAAADQ4AAL4PAAC/DwAAyw8AAOQPAADm DwAA5w8AAOgPAAABEAAAAhAAAAUQAABiEAAAfhAAAIEQAAD0EAAA1RIAANYSAADXEgAA2RIAANoS AADcEgAA3RIAAN8SAADgEgAA4hIAAOQSAADlEgAA+xIAAPwSAAD9EgAA/hIAABUTAAAWEwAANBMA ADUTAAA/EwAAohQAAKQUAAD49Oz05fTa7NHs9Mb4xvj0wrq2ura6trq2qZipmImYqbZ4tmxjtgAA AAAQFWh8UCsAFmh8UCsAQ0oSAAAWFWh8UCsAFmh8UCsANQiBQ0oSAFwIgQAgFWh8UCsAFmh8UCsA Q0oQAE9KAABRSgAAbUgMBHNIDAQAHRZow0fDAENKEgBPSgAAUUoAAG1IAARuSAAEdQgBIQNqAAAA ABVofFArABZofFArAENKEgBPSgAAUUoAAFUIARgVaHxQKwAWaHxQKwBDShIAT0oAAFFKAAAABhZo +nNcAAAPA2oAAAAAFmj6c1wAVQgBBhZocVAKAAAUFWi7DkYAFmh8UCsAbUgJBHNICQQAEBVoBFvk ABZofFArADBKFAAAFQIIgQNqzyEAAAYIARZofFArAFUIAQwVaLsORgAWaHxQKwAADwNqAAAAABZo fFArAFUIAQYWaHxQKwAADhZofFArAG1ICQRzSAkEJg0OAAAFEAAAaxIAAMcSAADVEgAA1hIAANgS AADZEgAA2xIAANwSAADeEgAA3xIAAOESAADiEgAAARMAABUTAAAWEwAANBMAADUTAADjEwAAoBQA APYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAA AAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADf AAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA5wAAAAAA AAAAAAAAAMUAAAAAAAAAAAAAAADFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpAAAFiQBSWYBAAAAZ2R8UCsAAAQQAGdkfFAr AAAJDwADJAEUpPAAYSQBZ2R8UCsAAAcPAAMkAWEkAWdkfFArAAABAAAABwAAAyQBYSQBZ2R8UCsA AAQAAGdkfFArAAAIAAANxgUAAaclAmdkfFArAAAUoBQAAKEUAACiFAAAoxQAAKQUAAClFAAAwQAA AAAAAAAAAAAAALoAAAAAAAAAAAAAAAC1AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABBAAZ2R8 UCsAAAYAABOkAABnZHxQKwA+AABrZIwiAAAWJAEXJAFJZgEAAAAAVAEAApZsAAM0AQjWGgABx/+K JgAGwyYEAQAABAEAAAQBAAAEAQAAFPYDwyYa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/MtYG AAEKAzkANNYGAAEKA2wAYfYDAABmNAGKVAEAAAWkFAAApRQAAPwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGFmhxUAoAATkACjABJlAJADGQaAE6cHxQKwAfsH0uILDIQSGw bgQisG4EI5CJBSSQiQUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBgAAEQAZAAAAAAAAAAIAAAAAAAAAAAAAAAAAEUG CAfxAuECAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwTAAAALIECvAIAAAAAQQA AAAKAABDAAvwKAAAAARBAQAAAAXBEAAAAAYBAgAAAP8BAAAIAGkAdAB1AC0AbwBsAGQAAAAAABDw BAAAAAAAAIBiAAfwgBcAAAYGAUBiTRU7jpmGIdjQWNlMW/8AXBcAAAEAAABEAAAAAAA1DgBuHvBU FwAAAUBiTRU7jpmGIdjQWNlMW/+JUE5HDQoaCgAAAA1JSERSAAAAawAAAHgIAwAAAMIj/AsAAAMA UExURaLE2YeVxOzx8oq20sTW37zT3dzm6dXh5ZiEp2SOvKzK2pG61Rs3j/r6+qWyz+pnhfLF0ChE lpajyeRUdnWlyLHN23eJu/Hz+DhTnml8tPT19sbZ4K1ojsPL4oejxs3d4mqXwe+xwNDe5J3B2Upg p7jS4+jt71lureTr7ODo6u2Rp4Szz+Tu9N7n6uvv8LO92OLq7FV+tOQmUvKfstjj5tPY6csqV8ja 4fP09cDW37rM2t0NPefX3rbQ3O/y8+br7aS30Ja91/b3+Oc/ZqQMS+MQQPvg5l11r5qvyy5MmlyF t0NaoTldorPG18rU3+p+l051r9bk6r5GcGMcaOLl8Zm/2ERipt/r8n6Tvs+Zr8isvazD1rzH2kdu q8aAncvc4+Pm7T9lp1Fqqc/g6tgYR5Kvzc7e5r03ZbvF1e/j59nf6rLA1cnc5cre66m90p6tzMfc 6c/a4/Hz86fH2v3w89HX56Ww0/3v8qfJ3ePs72BXmOEAM3+xzg4rif///wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM25c8QAAACAdFJOU/////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A OAVLZwAAAAFiS0dEf0i/ceUAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAABNNSURBVGhDvZrtQ9rY EsYDCFQgahDDiciLQImIICouUgsivTWGRCpdtdytrCu+tFddbXHXyhrCv37nJAESxLb3g3ewQgPy yzMzZ86ckxAd1bYmtBfP+ERo302ubD0jRf3qLqvz+h353LAeq/NuVn5mWJ+19ebb/40lv5t8Zi/2 dXUm3q48rzAdSx5/+7y5qGN1vj08rxf1rM67h5XnzEUDa2v5Wb1oYMnzD2/+er78MLA6W6cP88/n RSMLIvbwfEV4gPVt+TteJElvyvzHHlgq5ZVL/7OzB1jyysPD+DAvbmz4b0wMy3Isyzbwb5q+81/8 b7gBVgeEPQwUYZK8WKxFBZY2uYuHn/2Vr5XDz5djbppuCNGa/2/ypyvbIKsz+/CwrC8fqQs3y7Om y9WNmLnZNJvNsVgshX9a8UyFbgsCY7qY/jl9j1jf3jzoysfeIsu76Mp0qQDfD7YxB5ZOx8GSNls8 zrGHgUaUOyz8DO0RSwZhWuKX9kxRqs2uNpsqSKUBToEl062Y2SaYCvZX4GHTxo9d+YjVIUHYW5z4 q6YowyB3qbS21lxrNpvw1GwWCqkUprViMf9YwBSouV61bEn7dkNw7/1I22NWZ2IdQvYt5UZM5VIY u6jcmGo0BwapV3OP+b9mzNPNpj0QRXAqDEtRDfoyvJApNpB7+vt1YAhLHgcvTtbZSuyzi2KFKMvU gFEsKkzIvQZbKxYFdiwD8pLxMCDRgcmXDG4LDf93HTmE1dl6C7CZj7TgargvK3+QMjxKJBi8aMYr n9200G7Tl/a5VMtmS28L9hGTgEzBqo9Gte85chiriYU9/GOihTmyNA0hAoNQNQv4ZXO6VCoIpkM6 KnA32dScLdOotWzBbXRwXQ1/FITK09KGsMia61/AWt6qu0uplFnhrCmGU6NgTk1fCxupZuzQ1EBc 0WYuokomDKKo2tHJUY1ffLJ4PWbFuDb1Hgv7FK02VRRgpsG0RDSTNN2E1Dc3459pJAS+sjVbOFxt XYtMLngyhkzeJxLyEetCaDMjc5D3Dw/vSbOCmlZICg0rM8ucu4lHdTo9F7PfRAUBhVvBy+0A10Zs o4HajdjwfBxkVXjqGurPLOT9w/pKCVBYU0k1DUbStWYspgzpdKw0d4Pa0Yag5CtPBc4C26wwvIwM sCpUYzU1F2+ZlfRYnyiZdagujHSz00q5ipnTOwGucYDaLs5qD56fWAUanqycMNSNRtbfPB1vxePp dPo1zvuH5dekqgpnPEkqsLXC2ioKm1MF89wlLSDWdP01LNANFDgJZ893qMBVznpVHqrMwLrga7F4 Elhzc+Z5zHp4kyr1URqsWSixtJw6pA8EZiycTKVtczRXdfONS3v2JICsOWsuxwqxxwmiZ8UEJh23 KaxWSk2Ph3EcJ1VVV1izQFaQiUVMMW2GymHLZDJ+tJMcYaiaLzgi1M6t1nyeYx9PNDoW2UAZm01l zW14JxQvPrwraTVDVlil6TWStNdcbfdFszkH9d4GLLuNpW326jYSPlYDQi4HLIdgejSo+yyZdh3G AZaEcM3NtRbU9ID5RVEkg6kw+YJG3CLLrKUwClgAs40hXzhYzTFU4JVwDaypfIRaHMz8PuuwTafh rzRWLDVdxNUDbEXHIhWSnyQziEmleqzMV2GsGswenQR4Ttj2AWsqH+BXB0LWY11QVAWfYdeHqcJX Fx5kkPmzWJEiSy6YEFcpkVCnKgKbTCm6wIf2FsPZg9ls1r5z0D67wizHSwYNZH6XRTIuJm3vs2Ix 80bjvRqy0wnMwbhF1PDLJeg6UqlCkkOH5jnoBDArWRSywPL5gjsuqujL56cc9w6xZhTWZRUFNGbr sj6YF6CJIQNLk6oX3yow+Q8OFUlyrQnlN5WKFVI1nrab4wrLHhaKYYW1LTDUmU9hnbn+NsA0VgGZ Dip2jdV6vTIx8fo///n8z2/QwanKQNQdojdkaAhwqccNyEbzsIFMmZgNs2wcUwUfBnOIPqnxtdyU 4/b2fjRqqPkqS65x2w34C+xDWzKdWV4/XQZbP1WdiJUtcOizTE7D9K+xNuZgeI1FUe1VJh2v2twH 1XP7ybXQyPmyAVfNCiyCQHd6YSprj7cGmDBmASweX1CLht5O/6FTslZ8FRdC7YXim0qOsahRu9mp vOKvX21zFJPz5ay+ABXKA+o+ZCgfCktmmBbNgC5FGIxlm+Y7PW0F+0+bLbELAYWbxLnYKzcnRBFy 8dCXFo9GclawABWYIsAO3DphCmuP32kxNHa7logL0NY/snelkjIva9FSukSchsm07av18yuGtebO gyNQNaBsWGuugIOIEB6ka0AwS4bSaWPoKjhRg32wqdXQaOMFmM8wCmRBtNSRDG63Z+xhOwQse+Tz aax8fpS33EYi+8d3/eqBWXvo8qha4+AP+sKUyXLQJl/DTK2herKUjA8H7R/RTo8FQ3lqF+0TkUhI 6JdFYMl3bDBbNXHhsAJTym9yQauGRtzyBHQ7Sr4r0VJcqLFOXqHrI1UWlA2Hw0GgOhHZd6LFXsSA ZY6ehbN2d0NjYVg83no9JD2gXs2bvQva/G9ABY/sjUAQs3CVB9btvZMaJTb3y4yetYpGYBDuIKsC U9Ie5pUhea9onHxtVpYPBlXhYPCoyjDBETVc4EIYXfc1Soo4JdQrwaCrRtt9vmxQ2Aa3KxFTi31L K1CDQVteWVhQFyp9D4aDR1l7jVV0YVnAgoS/30WbTiffcyLRIaPbENPsCRQZnReT8Q8Tp0PSQ5Wm qeoGC6Oy4cABDC5NFmZFIk5+CVhct9wTHb+Qs0Gn4v16WGo2vbD68cYzMS+e+SdWhtv8BFlKJZNm rT/1Fppes/kke42U0ZW3LbRarQ+KjYxVCdGV0iJGdIqcbwHPun3bsDeNB4b8b9pmKxkOV32v0A7U J2veazjuOG53qz0hc4FcTHbjtb368Mtpe0F/oPtG/5l1y2uYVcP7AvjBVuTqiA8RmDVVInvHGxfy fd3VncaIvWhxZEFm2z27kdPhgv5A/63eqwawMtMy6h1YxCzhLItbjRLJ94775YAocl0frjamrAsy M8jSHRjKamaABcswze7kTG4k6s7ihC+R/eOHcsNVRlrpIPwHVmtML+PuJ3SxcjNjN+qyj/gO3NDV 5B0lsq/XL3MuSfSrwggT47O2jLriwYLMDVHTPySoLL0uO9alsfS6aJdUv9FYdMiXbxl1xY/M8g3L Mhw8GKbv/DZilCMccyMX7IO6crloADc190ZdjXa5TGusRiAHLEO8MAuWxvgH/pn6ckxKR6ocV1gG XVZg5aBk3Orj5Zfpulg2aazomXVqQJctOOe/S8E6D5qpkkzrWWuFC/dNjDQX0uGwMV4nGstx6zXE i/DwS6yaHAQq5oFl0GU7OkK0LYiLYzgm1/SsuP3rDaz57TaonWsGXSdWK+jCldCYh4QkHjeUKnVB IGLqkS67SQjDl+FSHDPqitvt6bAbaCM2+5phfJ3kgWWFtpAwxouQlvio0ggsYpYjbtSVHEFuexCz wuGUUdcH3ABV7e4DxHw0xus8bz0IWGHeIryG8UVIIVdD2WhcBZYDWLq6cSeba4IvCAao4ICu2eoJ PgNbGFo1v0HXeT6PtvG8FTHqikiSS1A3NQkUcdwmjbqyKGDPHik0YBni9Wb8T4AFg+fV8KukIV7n U1N8ceoWWNNGXR4LxWss6sxxO6CLEUZgPsoeHR0FjzaM8XrzMFk5CcI78AGvMV65InJAajyOV0JE GstVmyIGdEVRLugDGOCyrQFdsIT+fILPJOvzGnRdB2j+7CzgqbF7uuOHMuFJ1LusdhmzDPGCRbcV pmoFlx7UBZsDv/2JVyS+gkEXLVKUANsqYn3POL4kYKkNKUEd30YGdF3mBAGUYZjvsS5YSPz7zyuF pa8bV1PcbsRZ3CegRunrIehaiqpdACG4nIO6qr4RUIZhPt8QXdBxjPuufCPGeH3JR0chWETEOVA3 pESvbjDtEFE15qHd6oMNimvorjDLmIdauzP5+QvM5lHd/JUlUOAWms99YBl0SVLdpPbZBO2qR6rG eEFp811x/Fh4xDdi1EXCNRDVln/7op9haXnhTG3gnffyhat3DhekU0rsduv8HeKlAV1Q2qwjVzQV gJ45btSV+b0LW//9g24KcO3Jl8ebkf1N571XDvRQVKxkgdzozl8X4nH9g1EXlBuwKzdFj/iSxjy0 +37vLSrGZX+/LHMl2XwCDXZSlg/7R1n5gyRJQndeXo2GqJfGeJ1PKTDfNTrYWTDqOsl9+a0LO93S JXdbOFRbtT1T34Ntt/xSkjy8tl1EeBsewW3UdTSVh9Va3urLc/yiUdc5bGx1F+wP72S3vlMQaPeN iaV0hxBJWiRLudHto+TarmdsoB5CrcG4fC5XCxh1wb6W9cu1toRZ3vpBa7cof5GkhKilBtwPsHjg /NOoK3vrwDRFXcao6wifgnVHW1aMy3t6GYPtkEk2Q2Z4+n0vrCo9A3noA5ZKm5qyGXVdYdZU3jGj puOKvNd4quFyuWUSJpTEMdVdMsOaiC1XZd1f3Mg5AqYGjAOrGnVlMR/OI6+m4zpsDtzoGi0dl1mV SwSgRttMd0MFWHfoBPbzXJRmd8AiMO1eZZl678CZ+rRTcNz/W10xjX+TS4cMr8s94LngQo4s2zYh 3yW+vailBr5/Y4F/aVyI5CIqDMTdVgfegm0mxz2cB3F/84sCO53fgo9c3MEFxihYg6Pdfmj55A8O TAIP9ncdgFXiAt4F8/mqF+94XeyZzS8jGIbtlvgC6zFYX8FP0r/aJHPKKeBFI3F/rVwxgLI/OT8x sGqyvYRIKShUp3ubDnjPoYKkhHOU8mw6N51iiNjfj4BpNFUflkiM8mItMgWlXDH4xMeZ7rBef/tm fP5PvLqrfsk59hMKSEpIx7wHaUUD11745xXKiYSlzktOZ0IMRTY3N/dVXg+oaHREaJ5fOru9h3Ku maZM1ffLC6gR8OiaJcQjqXzQ32pT9oiu+YSUSIh8ArP2nU4dzcC7j3gOqIOQhbgn4Fy2X3zqFmL1 ef2TqQeSLNKuqy4l+DHjvk2nhEYBJomiJYEwC8M290FdRJXXM4jSWRnxx6HEvntmyNJ9/X1A9V5C WqL4kCVR1m3bqPcRyXe84l5elMSQ02IBmsrDzhywyH1E4tCvv/TKvVHb6UwAohWqU/wofGEC6mk3 47v3LJEQMYB5EEKYBTQdr89U2E73zLCNsR7ydIYTqeMQ1mYpi/pNem1fdJGCs8BubIeckCeqKfIM tul+8f4pRX1967/WLGoq8od9Vb17sWS2blHdSIGXe7RB3OZMd1PW6LmB/52+wF8GEzI3ZL8XFixU CJ8KjHNqFE4K47ryFI8qD0C/eGozRyfrPQ4ZLoW88Uppd89cDuD0gMmmXKZ2sT8xTidQc6vFeWYY U4/lrb9/AZFSfeQ2XuXoXXcoNbAXLfW6M0SJCgx/XAWqTOUZjvSqxRA/rr83aUUDXNQYuHrTv56y R5Vhwt49hnQU+VHF4X1TOZqZ1Kr72E5nXvQ+ZCnz3X0oXZ3XXsp+CBlkKZazhIe8kaYHS8Ok/fIe alTPLCHKkINKL9pPStnNe6CGeQBi8fAg7WmaNFCe1j/NvDCcXMLDBx5djNVf1yvRIIpX81Hapeqe AUcapRkS8sXgiVH9qaSnxnC90sscW8QlLS9CIrX0PUcGDAk5Y4iuhJghl+oNLNhmFpdETU0iMUqh MtTrp8zyj74mflKrrpq+Yq/HGFI3uoe8LE/1ZiBcrGEGeCJsliVqVF/rT7s5CAOL/onryx25wLSX nP1s8uxSYhmX0UFLJJZcoUTCpMvIddWPCQ81VJUhD1VtJRoqYt8dFs8STMaewdAnErsUzHlgpvd9 T/4CAxkyufbEnQ7GeCmwOxe0BH0d4EkEc4RuLCudBNXN0oSpnySnM9Iu737qDo7HrA5cqT42pLtF Ch1T/G5IgjKlnAMefngYdnNBp+1f/zwawsNzvnv0ghlIiYTFUz7m0e4o4CB6owNlJSEFtMuo0C++ e/JG0CG6sB/HQJoxIyyAE3lK3PV46lTZiSVq5VwpzFLtk3Y5+mF54gnacBbMZzS/OzC2EpAyoSWx 7WqjpdFRDx4aUPyhT/OEynVRpFy/vtFm0smJoXdMPsXqkH4WT2TGbE9YQsd8ubwrQmPCg4miCL8R L9Z3RZ67ImfHVdryUEc+yerIXriku+TBaro5kPAc4yqJ1XhATWh0aakcCoHC0K7ILpbkDklOvFtW xgC0+fqSobx+moUb4kNOEKH3wurgF2RjP4raPIpDNSqKjL9XKbZmJ5WyvDw7SPsuC2h/wybo7ijE xgOjrA6jTDfwICckz2idj5r29KOX/LaliHv7ZpY0zCs/YIE4smKKHoh8G6IH3Y2uJ5BC5WPxIGq6 GHILCojDTeTkrP5+8h+zAGdeLdKsyIvHu+XyaAjiVF7aPYaMYN03F0/dVLa1Na/cFzdruDb6KIbD DsDNKYdwxyjNNKLRA5ZmTHeHF96S/L175Uhyax5GQX8A/JSunzqboR/agrx8Oz6hevKZWZ3OX3/N ji+Pz/4FWfLsLCwIMmUesuT/wgJ1W7Ozf/0XvHEVdKRHia0AAAAASUVORK5CYIKHABYkARckAUlm AQAAAAGWAAAhdgADaAE11gUAAQOJBTXWBQECAykUNdYFAgMDEQ0jdgABiQUjdgECKRQjdgIDEQ06 VgsAApY5AAM0ART2A8MmGPYDAAAr1gIAAzXWBQABA4kFNdYFAQIDKRQ11gUCAwMRDTTWBgABBQAA ADTWBgABCgM5AGY0AZAAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA4kFNdYFAQIDyA811gUC AwNyESN2AAGJBSN2AQLIDyN2AgNyETpWCwACljkAAzQBB5RjART2A8MmGPYDAAAr1gIAASvWAgED NdYFAAEDiQU11gUBAgPIDzXWBQIDA3IRNNYGAAEFAAAANNYGAAEKAzkAZjQBpAAWJAEXJAFJZgEA AAABlgAAIXYAA2gBNdYFAAEDiQU11gUBAgPIDzXWBQIDA3IRI3YAAYkFI3YBAsgPI3YCA3IROlYL AAKWOQADNAEHlAwDFPYDwyYY9gMAACvWAgABK9YCAQEs1gMCAwE11gUAAQOJBTXWBQECA8gPNdYF AgMDchEv1gsAAwQAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AYYAFiQBFyQBSWYBAAAAAZYA ACF2AANoATXWBQABA1EGNdYFAQIDIA011gUCAwNSEyN2AAFRBiN2AQIgDSN2AgNSEzpWCwACljkA AzQBB5RlART2A8MmGPYDAAA11gUAAQNRBjXWBQECAyANNdYFAgMDUhM01gYAAQUAAAA01gYAAQoD OQBmNAFaABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPDJiN2AAHDJjpWCwACljkAAzQBB5Rl ART2A8MmGPYDAAA11gUAAQPDJjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDUQY11gUBAgNyIDTWBgABBQAAADTWBgABCgM5AGY0AX4AFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDUQY11gUBAgNyIC/WCwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBbgAW JAEXJAFJZgEAAAABlgAAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsAApY5AAM0AQeUZQEU9gPDJhj2 AwAANdYFAAEDwyYv1gsAAQEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNcAHYAFiQB FyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsAApY5AAM0 AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNc AHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgECOx46VgsA ApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgABCgM5AGY0 AXl0+nNcAHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgABiAgjdgEC Ox46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAAADTWBgAB CgM5AGY0AXl0+nNcAHYAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQIDOx4jdgAB iAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7HjTWBgABBQAA ADTWBgABCgM5AGY0AXl0+nNcAIQAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA4gINdYFAQID Ox4jdgABiAgjdgECOx46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDiAg11gUBAgM7Hi/W CwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBeXT6c1wAxwAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6 zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupC1YAAABtAGEAaQBsAHQAbwA6AGgAZQBy AHYAZQAuAHQAYQBkAGQAZQBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQAAAHlYgfQ7HX9IryyCXcSF J2MAAAAApasAAJoAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA1EGNdYFAQIDKhE11gUCAwNI DyN2AAFRBiN2AQIqESN2AgNIDzpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA11gUAAQNRBjXWBQEC AyoRNdYFAgMDSA8v1gsAAwEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXl0+nNcANMAAABE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtiAAAAbQBhAGkA bAB0AG8AOgBoAGkAdwBhAHMAYQBrAGkALgB5AHUAcwB1AGsAZQBAAGwAYQBiAC4AbgB0AHQALgBj AG8ALgBqAHAAAAB5WIH0Ox1/SK8sgl3EhSdjAAAAAKWrAACaABYkARckAUlmAQAAAAGWAAAhdgAD aAE11gUAAQNRBjXWBQECAyoRNdYFAgMDSA8jdgABUQYjdgECKhEjdgIDSA86VgsAApY5AAM0AQeU zAAU9gPDJhj2AwAANdYFAAEDUQY11gUBAgMqETXWBQIDA0gPL9YLAAMBAAAA/wwBAAA01gYAAQUA AAA01gYAAQoDOQBmNAF5dPpzXABuABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPDJiN2AAHD JjpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA11gUAAQPDJi/WCwABAQAAAP8MAQAANNYGAAEFAAAA NNYGAAEKAzkAZjQBeXT6c1wAvQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnq efm6zhGMggCqAEupC0wAAABoAHQAdABwADoALwAvAGkAdAB1AC4AaQBuAHQALwBJAFQAVQAtAFQA LwBpAHAAcgAvAAAAeViB9Dsdf0ivLIJdxIUnYwAAAAClqwAAaAAWJAEXJAFJZgEAAAABljMAIXYA AWgBNdYFAAEDwyYjdgABwyY6VgsAApZsAAM0ART2A8MmF/YAAAA11gUAAQPDJi/WCwABDwAAAP8E AQAAMtYGAAEKAzkANNYGAAEFAAAAZjQBilQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAhgIZABIAAQCcAA8ABAAAAAMAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgAAYPH/AgBmAAwAAAB8UCsAAAAGAE4AbwBy AG0AYQBsAAAAJwAAAA3GDgAEGgOnBDQGwQfAwMDAE6R4ADUkADckADgkADlEAgBIJAAAGABDShgA UEoAAF9IAQRtSAkIc0gJCHRICQQAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEAAAAAAAAA ABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAVgBpQPP/ swBWAAwFAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAIAA6VgsAF/YDAAA01gYA AQUDAAA01gYAAQoDbABh9gMAAAIACwAAACgAa0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkA cwB0AAAAAgAMAAAAAAA0AB9AAQDyADQADAAAAAAAAAAAAAYASABlAGEAZABlAHIAAAANAA8ADcYI AAJfEr4kAQIAAAA0ACBAAQACATQADAAAAAAAAAAAAAYARgBvAG8AdABlAHIAAAANABAADcYIAAJf Er4kAQIAAAAwAP5vAQASATAADAAVAHxQKwAAAAcATABTAFQAaQB0AGwAZQAAAAIAEQAGADUIgVwI gTIA/m8BACIBMgAMAAAAfFArAAAACABMAFMAUwBvAHUAcgBjAGUAAAACABIABgA1CIFcCIE2AP5v AQAyATYADAAAAHxQKwAAAAoATABTAEQAZQBhAGQAbABpAG4AZQAAAAIAEwAGADUIgVwIgTYAVWCi AEEBNgAMBAAAfFArAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioCcGgAAP8ASgD+b6IA UQFKAAwAEQB8UCsAAAAMAEwAUwBUAGkAdABsAGUAIABDAGgAYQByAAAAGgA1CAFDShgAXAgBX0gB BG1ICQhzSAkIdEgJBDgA/m8BAGIBOAAMAAAAfFArAAAACwBMAFMARgBvAHIAQQBjAHQAaQBvAG4A AAACABYABgA1CIFcCIEuAP5vYQFyAS4ADAAAAHxQKwAAAAkATABTAEYAbwByAEkAbgBmAG8AAAAC ABcAAAA0AP5vYQGCATQADAAAAHxQKwAAAAwATABTAEYAbwByAEMAbwBtAG0AZQBuAHQAAAACABgA AAAAAAAApQwAAAYAADgAAAAA/////wAAAACnAgAAqAIAAKYMAADq0AAwADAAAAAAAAACAAAAAwAA AAEAAAA0pIoHCkAAAAAwAAAAAAAAAAAAAAAABjCvDgAAAAAwBwoAAAAAMAAAAAAAAAAAAAAAAAMw AAAAAAAAAAcAAAAAAgAAACgAAAA8AAAAPQAAAD4AAABnAAAAfgAAAH8AAACAAAAAgQAAAIIAAACP AAAAoQAAAKIAAACvAAAAtQAAANoAAADbAAAA7QAAAO4AAAD2AAAACwEAAAwBAAATAQAATwEAAFAB AABiAQAAYwEAAHIBAACBAQAAggEAAJIBAACUAQAAlQEAAKkBAACrAQAArAEAALYBAAD7AQAA/AEA AAYCAAARAgAAEgIAABsCAABCAgAApwIAAKgCAACxAgAAywIAAFADAABRAwAAUgMAAFMDAACUAwAA KwQAAA0GAAAFCAAAawoAAMcKAADVCgAA1goAANgKAADZCgAA2woAANwKAADeCgAA3woAAOEKAADi CgAAAQsAABULAAAWCwAANAsAADULAADjCwAAoAwAAKEMAACiDAAApgwAAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpYAAAADAAAAAAAAAAgAAA AIABAAAAAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACAAKlAAAAAMAAAAAAAAACAAAAA gAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAmUAAAAAwAAAAAAAAAIAAAACA AQAABAAAAACgAKlgAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACpYAAAADAAAAAAAAAAgAAAAIAB AAAAAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACAAalAAAAAMAAAAAAAAACAAAAAgAEA AAAAAAAAoAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqUAAAAAwAAAAAAAAAIAAAACAAQAA AAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgAAAAIABAAAA AAAAAKABmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAA AACgAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACZQAAAADAAAAAAAAAAgAAAAIABAACEAAAA AKAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAA oAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAA qQAAABYwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABgwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAA ABcwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABMw AAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAKgAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAAqAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAKgAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAACoAAAAACABmQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAAKgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAB5yAAwADAAAAAAAAABAAAA AAAAAAAAAAAAAKAHiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACkB3nIADAAMAAAAAAAAAEAAAAA AAAAAAAAAAAAoAeIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAKQHecgAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAACgB4iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAApAd5yAAwADAAAAAAAAABAAAAAAAA AAAAAAAAAKAHiJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACkB5hAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAiNEAMAowAAAAAAAAAQAAAAgAAAAL AAAA8FlOB5hAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACI0QAwCTAAAAAAAAACAAAAAgAAAAoA AACclE4HqUAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKlAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACZQAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAIiRADAAMAAAAAAAAAEAAAAAAAAAAAAAADgJpAcAAAAAAgAAACgAAAA8AAAAPQAAAD4AAABn AAAAfgAAAH8AAACAAAAAgQAAAIIAAACPAAAAoQAAAKIAAACvAAAAtQAAANoAAADbAAAA7QAAAO4A AAD2AAAACwEAAAwBAAATAQAATwEAAFABAABiAQAAYwEAAHIBAACBAQAAggEAAJIBAACUAQAAlQEA AKkBAACrAQAArAEAALYBAAD7AQAA/AEAAAYCAAARAgAAEgIAABsCAABCAgAApwIAAKgCAACxAgAA ywIAAFADAABRAwAAUgMAAFMDAACUAwAAKwQAAA0GAAAFCAAAawoAAMcKAADVCgAA1goAAAELAAAV CwAAFgsAADQLAAA1CwAA4wsAAKAMAAChDAAAogwAAKYMAACpQAAAADAAAAAAAAAAgAAAAIABAAAA AAAAAKABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAA AAAAoAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAAKAAqWAAAAAwAAAAAAAAAIAAAACAAQAAAAAA AACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAA AKABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAJlAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA oACpYAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAAqWAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACg AKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgAGpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAB mUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACr QAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAZlA AAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKABmUAA AAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAoACrQAAA ADAAAAAAAAAAgAAAAIABAAAAAAAAAKAHmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAACgAKlAAAAA MAAAAAAAAACAAAAAgAEAAAAAAAAAoACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAKABmUAAAAAw AAAAAAAAAIAAAACAAQAABAAAAACgAKtAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAeZQAAAADAA AAAAAAAAgAAAAIABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAACuMAAA AAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAA AAAAAICUpQEAAQAA0AAAAAAgAalAAACwMAAAAAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAA AAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAACvMAAAAAAA AACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAA AICUpQEAAQAA0AAAAAAgAalAAAAAMAAAAAAAAACAlKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAA gJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICUpQEAAQAA0AAAAAAgAalAAAAuMAAAAAAAAACA lKUBAAEAANAAAAAAIAGZQAAAADAAAAAAAAAAgJSlAQABAADUAAAAACABqUAAAAAwAAAAAAAAAICU pQEAAQAA0AAAAAAgAalAAAAAMAAAAAAAAACAlKUBAAEAANAAAAAAIAGrQAAAADAAAAAAAAAAgJSl AQABAADQAAAAACAHmUAAAAAwAAAAAAAAAICUpQEAAQAA1AAAAAAgAalAAAAAMAAAAAAAAACAlKUB AAEAANAAAAAAIAGpQAAAADAAAAAAAAAAgJSlAQABAADQAAAAACABq0AAAAAwAAAAAAAAAICUpQEA AQAA0AAAAAAgB5lAAAAAMAAAAAAAAACAlKUBAAEAANQAAAAAIAGpQAAAADAAAAAAAAAAgJSlAQAB AADQAAAAACABmUAAAAAwAAAAAAAAAICUpQEAAQAA1AAAAAAgAZhAAAAAMAAAAAAAAACAlKUBAAAA AAAAAAAAAAGYQAAAADAAAAAAAAAAgJSlAQAAAAAAAAAAAAABmEAAAAAwAAAAAAAAAICUpQEAAAAA AAAAAAAAAZhAAAAAMAAAAAAAAACAlKUBAAAAAAAAAAAAAAGYQAAAADAAAAAAAAAAgJSlAQAAAAAA AAAAAAABmEAAAAAwAAAAAAAAAICUpQEAAAAAAAAAAAAAAZhAAAAAMAAAAAAAAACAlKUBAAAAAAAA AAAAAAEIAAAAADAAAAAAAAAAAAAAAAAAAAAIAAAAAAABitEAMAAwAAAAAAAAAgAAAAUAAAAAAAAA AAAAB4jRADAAMAAAAAAAAAIAAAAFAAAAAAAAAAAAAAGI0QAwAzAAAAAAAAABAAAABwAAAAQAAADA VU4HqUAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAYjRADAAMAAAAAAAAAIAAAAFAAAAAQAAAECM TgepQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAIABqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACg AJlAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAoACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA CgAAAAAwAAAAAAAAAAAAAAAAJTDNAQAAAQAABwAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwAAAAM AAAAQAAAAEAAAABfAAAAXwAAAM0BAADQAQAAAAYAALYJAAArDAAApBQAAKUUAAALAAAAFAAAABgA AAAbAAAAAAYAAH8IAAChCAAA2ggAAAsJAABiCQAAlAkAAPsJAACnCgAAUAsAAA0OAACgFAAApRQA AAwAAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAVAAAAFgAAABcAAAAZAAAAGgAAAAAGAACkFAAA DQAAAF8CAACNAgAApQIAAPwCAAAwAwAATgMAAL4HAADnBwAAAQgAAKUMAAATWBT/FZQTWBT/FZQT WBT/FZQOAAAAJQAAACcAAADQAQAAEyEU/5WADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAAAgAAAAEA AAABAAAAAwAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAIE AAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAA AA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAA PwMBAAEAAAAR8AQAAAABAAAApQwAAP//CgAAAAgAZAB0AGEAYgBsAGUAYQB1AAoASQBuAHMAZQBy AHQATABvAGcAbwAEAGQAbgB1AG0ABQBkAGQAYQB0AGUABwBkAG8AcgBsAGEAbgBnAAgAZABtAGUA ZQB0AGkAbgBnAAkAZABiAGwAdQBlAHAAaQBuAGsABgBkAHQAaQB0AGwAZQAHAGQAcwBvAHUAcgBj AGUABwBkAHQAaQB0AGwAZQAxAAAAAAAAAAAAAAAAAD0AAACAAAAAogAAAKIAAADbAAAA7gAAAAwB AACmDAAACAAAAAAAAAABAAKDAgACgwMAAoMEAAKDBQABggYAAIEHAAGCCQABggAAAAA9AAAAgAAA AKIAAADbAAAA2wAAAO4AAAAMAQAAUAEAAFABAACmDAAA//8KAAAABgCCmUMFEAABAHSGGQAGAIOZ QwURAAEA7K0hDgYAhJlDBRAAAQCs0CkOBgCFmUMFEAABAFzAKQ4GAIaZQwURAAEAnCedCgYAh5lD BRAAAQDEkBkABgCImUMFEQABAIQ2Lg4GAImZQwUQAAEANDcuDgYAiplDBREAAQDU9ikOBgCLmUMF EAABAFQ0GAAiAAAAtQAAALUAAADVAQAA1QEAADwCAAA8AgAAxQIAAMUCAABeCgAApgwAAAAAAAAB AAEAAAACAAIAAAACAAMAAAACAAQAAAACAAUAAAACAAYAAAACAAcAAAACAAgAAAACAAkAAAABACcA AAC7AAAAuwAAANsBAADbAQAAQQIAAEECAADKAgAAygIAAGIKAACmDAAAAAAAAAEAAAACAAAAAwAA AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAMAAAA4AAAACQAAACqAdXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBIBDaXR5AIA5AAAACgAAACqAdXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAQgAAAAQAAAAqgHVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncw6AY291bnRyeS1yZWdpb24AgAwAAAHcsQEQ AAAAAAoAAAAAAAkAAAAAAAoAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAQAAAAAAAoAAAAAAAQAAAAA AAoAAAAAAAAAAADWCgAA1goAANgKAADYCgAA2QoAANkKAADbCgAA3AoAAN4KAADfCgAA4QoAAOIK AACjDAAApgwAAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgAAAAAA1goAANYKAADYCgAA2AoA ANkKAADZCgAA2woAANwKAADeCgAA3woAAOEKAADiCgAAowwAAKYMAAAHAAQABwAEAAIABAAHAAQA BwAEAAcABAAHAAIAAAAAAAIAAAA+AAAAggAAABMBAABQAQAAtgEAAPwBAABTAwAAzwMAANAEAADH CgAA1QoAANYKAADWCgAA2AoAANgKAADZCgAA2QoAANsKAADcCgAA3goAAN8KAADhCgAA4goAAOQK AAD+CgAAFAsAAKMMAACmDAAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAEAAcABAACAAQABwAE AAcABAAHAAQABQAHAAUABwACAAAAAADWCgAA1goAANgKAADYCgAA2QoAANkKAADbCgAA3AoAAN4K AADfCgAA4QoAAOIKAACjDAAApgwAAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgATAAAABAAA AAgAAADlAAAAAAAAABIAAADvCwMAcVAKACNxIAB8UCsAiipWAD1lVwD6c1wAskFfAAwvagDQZGoA Elp3AM4zfgB0ZJ8ARXGjALYMpwDDR8MArn/WAPgj4ABzEPkAAAAAAAIAAAAoAAAAPAAAAD0AAAA+ AAAAfgAAAH8AAACAAAAAgQAAAIIAAAChAAAAogAAAK8AAAC1AAAA2gAAANsAAADtAAAA7gAAAPYA AAALAQAADAEAABMBAABPAQAAUAEAAGIBAABjAQAAcgEAAIEBAACCAQAAkgEAAJQBAACVAQAAqQEA AKsBAACsAQAAtgEAAPsBAAD8AQAABgIAABECAAASAgAAGwIAAEICAACnAgAAqAIAALECAADLAgAA UAMAAFEDAABSAwAAUwMAANYKAAA1CwAAoAwAAKEMAACmDAAAAAAAAAIBAAACAQAAAgEAAJ4BAAQC AQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAJ4BAAQCAQAAngEABAIB AAACAQAAngEABAIBAAACAQAAngEABAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEA AAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAngEABAIBAAACAQAA AgEAAJ4BAAQCAQAAlgEABAAAAAAIAAAAAgEAAJYBAAT/QAGAAQC4BgAAuAYAACycWgkBAAEAuAYA AAAAAAC4BgAAGAaKJgIQAAAAAAAAAKUMAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD/ /wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAA AgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAA ADsGkAGGBwIBBgADAQEBAQEDAAAAAAAOCBAAAAAAAAAAAQAEAAAAAABTAGkAbQBTAHUAbgAAAItb U08AACIABAAxCIwYAPDQAgAAaAEAAAAAU1LbRlZS20aZGjtmAgADAAAAsAEAACYJAAABAC8AAAAE AAMQSQAAALABAAAmCQAAAQAvAAAASQAAAAAAAAChJADwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABuBIkFeAC0AIGCEjQAABAAGQBkAAAAGQAAAKcKAACnCgAAAAAAAOluBukAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAEECAAAAAAgyg3EA 8BAACNwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFgAAAAACfD/DwEAAT8AAOQEAAD///9/ ////f////3////9/////f////3////9/fFArAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA AAAAOwBSAGUAcABsAHkAIABMAFMAIAB0AG8AIABJAEUAVABGACAAbwBuACAAcwBwAGUAZQBjAGgA IABhAG4AZAAgAGEAdQBkAGkAbwAgAGMAbwBkAGkAbgBnACAAcwB0AGEAbgBkAGEAcgBkAGkAegBh AHQAaQBvAG4AAAACADEAMAAAABIAUgBhAHAAcABvAHIAdABlAHUAcgBzACAAUQAxADAALwAxADYA GABBAHIAdAB1AHIAbwAgAE0AYQByAHQAaQBuACAAZABlACAATgBpAGMAbwBsAGEAcwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAFACAAASAAAAAQAAAJgAAAACAAAA oAAAAAMAAADkAAAABAAAAPAAAAAFAAAADAEAAAYAAAAYAQAABwAAAJwBAAAIAAAAsAEAAAkAAADU AQAAEgAAAOABAAAKAAAAAAIAAAsAAAAMAgAADAAAABgCAAANAAAAJAIAAA4AAAAwAgAADwAAADgC AAAQAAAAQAIAABMAAABIAgAAAgAAAOQEAAAeAAAAPAAAAFJlcGx5IExTIHRvIElFVEYgb24gc3Bl ZWNoIGFuZCBhdWRpbyBjb2Rpbmcgc3RhbmRhcmRpemF0aW9uAB4AAAAEAAAAAAAAAB4AAAAUAAAA UmFwcG9ydGV1cnMgUTEwLzE2AAAeAAAABAAAADEwAAAeAAAAfAAAAENPTSAxNiCWIExTIDEyNCCW IEUgIEZvcjogR2VuZXZhLCAyNiBPY3RvYmVyIC0gNiBOb3ZlbWJlciAyMDA5DURvY3VtZW50IGRh dGU6IA1TYXZlZCBieSBSQS0xMDY5NjkgYXQgMDk6MTk6NTYgb24gMTAuMTEuMjAwOQAeAAAADAAA AE5vcm1hbC5kb3QAAB4AAAAcAAAAQXJ0dXJvIE1hcnRpbiBkZSBOaWNvbGFzAAAAAB4AAAAEAAAA MgAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAADSSWsAAAAAQAAAAAB+B03d Jb8BQAAAAABylHTeYcoBQAAAAABE3t/eYcoBAwAAAAEAAAADAAAAsAEAAAMAAAAmCQAAAwAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAA AAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmujAEAAEgBAAAOAAAA AQAAAHgAAAAOAAAAgAAAAA8AAACQAAAABAAAAMQAAAAFAAAAzAAAAAYAAADUAAAAEQAAANwAAAAX AAAA5AAAAAsAAADsAAAAEAAAAPQAAAATAAAA/AAAABYAAAAEAQAADQAAAAwBAAAMAAAAJwEAAAIA AADkBAAAHgAAAAgAAABJVFUtVAAAAB4AAAAsAAAASW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNh dGlvbiBVbmlvbiAoSVRVKQADAAAA4DcAAAMAAABJAAAAAwAAAC8AAAADAAAApwoAAAMAAAAPJwsA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAA8AAABJVFUgTm9ybWFsLmRv dAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAADoAgAACQAAAAAAAABQAAAAAQAAAM8A AAACAAAA1wAAAAMAAAA/AgAABAAAAFsCAAAFAAAAZwIAAAYAAACPAgAABwAAAJsCAAAIAAAAywIA AAcAAAACAAAADAAAAF9QSURfSExJTktTAAMAAAAHAAAARG9jbnVtAAQAAAAIAAAARG9jZGF0ZQAF AAAACgAAAERvY29ybGFuZwAGAAAADAAAAERvY2JsdWVwaW5rAAcAAAAIAAAARG9jZGVzdAAIAAAA CgAAAERvY2F1dGhvcgACAAAA5AQAAEEAAABgAQAAEgAAAAMAAAAUAFkAAwAAAAYAAAADAAAAAAAA AAMAAAAFAAAAHwAAABoAAABoAHQAdABwADoALwAvAGkAdAB1AC4AaQBuAHQALwBJAFQAVQAtAFQA LwBpAHAAcgAvAAAAHwAAAAEAAAAAAGAQAwAAAHsABwADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAf AAAAJQAAAG0AYQBpAGwAdABvADoAaABpAHcAYQBzAGEAawBpAC4AeQB1AHMAdQBrAGUAQABsAGEA YgAuAG4AdAB0AC4AYwBvAC4AagBwAAAAAAAfAAAAAQAAAAAAYBADAAAANgBNAAMAAAAAAAAAAwAA AAAAAAADAAAABQAAAB8AAAAfAAAAbQBhAGkAbAB0AG8AOgBoAGUAcgB2AGUALgB0AGEAZABkAGUA aQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AAAAAAB8AAAABAAAAAABgEB4AAAAUAAAAQ09NIDE2IJYg TFMgMTI0IJYgRQAeAAAABAAAAAAAAAAeAAAAIAAAAEVuZ2xpc2ggb25seSBPcmlnaW5hbDogRW5n bGlzaAAAHgAAAAQAAAAxMAAAHgAAACgAAABHZW5ldmEsIDI2IE9jdG9iZXIgLSA2IE5vdmVtYmVy IDIwMDkAAAAAHgAAABQAAABSYXBwb3J0ZXVycyBRMTAvMTYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAAHwAAACAAAAAhAAAAIgAAACMAAAAk AAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAP7///8wAAAAMQAAADIA AAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAA TwAAAFAAAABRAAAAUgAAAP7////9////VQAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAACAPAfp3mHKAVcAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAAAPYiAAAAAAAA MQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAvAAAAbScAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA7OAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLAAAAABAAAAAAAAAB AEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRv Y3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --Apple-Mail-1-411169416 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed --Apple-Mail-1-411169416-- From stewe@stewe.org Tue Nov 10 15:23: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 7E5AB28C212 for ; Tue, 10 Nov 2009 15:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 S51HmxsAVQBb for ; Tue, 10 Nov 2009 15:23:37 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 63A4528C24E for ; Tue, 10 Nov 2009 15:23:37 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 484684-1743317 for multiple; Wed, 11 Nov 2009 00:24:04 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 08:23:51 +0900 From: Stephan Wenger To: Message-ID: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: AcpiXNyJJj7hBNtkrUC6eBerlER7Vg== In-Reply-To: <4AF9D032.3090507@fas.harvard.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 23:23:38 -0000 Hi Ben, You are most welcome. However, it's not really necessary to study my technical contributions, if any, in any more detail than those of anyone else here. After all, we are all bound to the disclosure obligations of RFC 3979. Further, I think I have an IETF-history of being rather open with respect to IPR claims in the past--perhaps because I have a rough idea of what can happen to the enforceability of one's patents if one doesn't play by the rules. (You may wish to check AVT's mailing list archives and/or the IPR database in case you have doubts). You and I appear to simlpy set different business priorities. Yours appear to lie in what you call "free" software; mine are in keeping one of the generally well working licensing environments intact. Both, I think, are legitimate. Further, I want to avoid anything that, in my opinion, may do damage to an organization called IETF, to which I have contributed occasionally over the last 10+ years, and whose great *protocol* work has made the Internet possible. I think, that's a legitimate goal as well. (In the interest of full disclosure: I do not own patents in the field of speech compression, nor, to the best of my knowledge, do any of my current clients. Some of my previous employers do own extensive patent portfolios in the field in question.) Stephan On 11/11/09 5:42 AM, "Benjamin M. Schwartz" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephan Wenger wrote: >> Do you think that people like me >> asked to do so without a reason? It may be that an RF requirement still >> exists in your head, but not in mine, and I'm perfectly entitled to play >> ball, just as you are. > > Thank you for your honesty regarding your intention to disregard whether > our codec can be legally implemented in free software. Knowing this, I > can make sure to oppose your technical suggestions until they have been > vetted extensively for licensing issues. > > Culture is determined by the participants. I believe in the importance of > free technology standards, and I intend to "play ball" as well. I am not > alone. > > - --Ben Schwartz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (GNU/Linux) > > iEYEARECAAYFAkr50DIACgkQUJT6e6HFtqS37wCgnWv8ts4/3NK8L+CdTB+e+Orm > zVIAnR3kMCT7OQDQrcF6EQj+B5msaKNI > =mvR7 > -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Tue Nov 10 15:32: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 82A9D28C0D0 for ; Tue, 10 Nov 2009 15:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9YtDtebmxw0 for ; Tue, 10 Nov 2009 15:32:34 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 8F7613A6A65 for ; Tue, 10 Nov 2009 15:32:33 -0800 (PST) Received: by ewy3 with SMTP id 3so625996ewy.37 for ; Tue, 10 Nov 2009 15:33:00 -0800 (PST) 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=4AFn0+7+EvjE4lWHYpODdDx56D3+Zl5mohmn7erFK3E=; b=RRj0w10rq4KEddQfH1MhonJqU4oSLDC/prmqAlYuJXni80D27fmkOO3EiN7jKxKw9/ s1q7KP4nNscugS3H/5E3a/ffdTRBYzxGUMJWPc73uPoxpnWpukxVg+D8v+aZvrDYck01 4gaejFSKGsgT04c7WGO4PCB/zJ2PKBjWLjcZM= 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=Do0PIZNQhQGVBfOgMNVNoH4H8cdbEuE5bIp7gJyacmN/cdUlFFbaDw/aA7c/m4cxiF jH8VpDofgZ0DHYRwyFJk4bJ9YSWbQxVs5ctuFhNJPzsz80pkFV+F9BrozS46UTarDGTc 9wgRYtYjs2Ep6i+KuU4OAcMjENgarqvyWlfCM= Received: by 10.216.88.138 with SMTP id a10mr250447wef.163.1257895980251; Tue, 10 Nov 2009 15:33:00 -0800 (PST) Received: from windows8d787f9 (host-112-47.meeting.ietf.org [133.93.112.47]) by mx.google.com with ESMTPS id q9sm3651923gve.0.2009.11.10.15.32.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 15:32:58 -0800 (PST) From: "Roni Even" To: "'Gregory M. Lebovitz'" References: <130EBB38279E9847BAAAE0B8F9905F8C0232A009@esealmw109.eemea.ericsson.se> <130EBB38279E9847BAAAE0B8F9905F8C6E40E5@esealmw109.eemea.ericsson.se> <20091110052641.34281f6075r5cowh@mail.skype.net> <4af9795e.0d1abc0a.4cff.1ce3@mx.google.com> <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> In-Reply-To: <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> Date: Wed, 11 Nov 2009 08:31:50 +0900 Message-ID: <4af9f82a.09a8100a.7324.ffffff19@mx.google.com> 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: AcpiF7e/af8XMvkmTMG/ye+cmMpZUwAROISA Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 23:32:35 -0000 Hi, At the IETF there can be one or multiple individual IDs for a solution = and if there is more than one they try to converge to one individual ID that will serve as a base for one WG draft.=20 To this working group draft everyone can contribute and their input will = be evaluated in order to consider its benefits. This process can be the same for codec, the major issue is that to = evaluate the value of a proposed enhancement to a codec the WG will need to understand the benefits. For audio codecs that will mean that each such proposal may need to supply quality test results in order to enable a meaningful comparison between the current proposal and the suggested enhancement. This is not an easy and fast process. Regards Roni Even > -----Original Message----- > From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] > Sent: Wednesday, November 11, 2009 12:09 AM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >=20 > At 06:30 AM 11/10/2009, Roni Even wrote: > >Hi, > >Inline > >Roni Even > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf > > > Of Koen Vos > > > Sent: Tuesday, November 10, 2009 10:27 PM > > > To: Ingemar Johansson S > > > Cc: Alan Duric; codec@ietf.org > > > Subject: Re: [codec] Standardization in ITU-T, what are the issues > ? > > > > > > The ITU liaison stated that their policy requires royalty free = (RF) > or > > > reasonable and non-discriminatory terms (RAND) for their = standards. > In > > > practice that means that anyone can add IP to the standard as long > as > > > it brings a small improvement. > > > > > >Roni: this is not the ITU process, if a candidate was selected based > on > >selection, than another party do not add to it. If collaboration take > place > >than the parties in the collaboration need to agree what will be in a > codec. >=20 > Is this a key area of difference of process between the IETF and = ITU-T: > - In the IETF there is most commonly all > parties working together to produce something, > openly adding their respective insights, and I.P. > (with associated IPR statements), into one thing. > - In SG16 multiple parties of one, or a small > number of people, each submit a candidate codec, > those codecs are compared and evaluated > technically, and then advanced with the > characterizations to the voting members who then > consider many factors, including I.P.R. and chose one winner? >=20 > This "pick the single best" vs "add the best > components into one" is a big difference in the > way the two SDO's go about this process, where > ITU-T matches the former terse summary, and IETF matches the latter. >=20 > Comments on that observation? >=20 > Gregory. >=20 >=20 > > > > > > Unfortunately, that means their policy is incompatible with that = of > > > the IETF. They were fully aware of that when writing the liaison, > yet > > > didn't indicate a willingness to abandon their position. > > > > > > ITU liaison: > > > https://datatracker.ietf.org/documents/LIAISON/file662.doc > > > > > > koen. > > > > > > > > > Quoting Ingemar Johansson S: > > > > Hi > > > > > > > > What was the answer?, is there any documentation of this effort > in > > > > the ITU-T archives. I guess there should be. I am just trying to > > > > understand the reality behind the general conception that it is > > > > difficult to approach ITU-T and to be honest I cannot imagine > what > > > > the outcome is or was as I haven't tried it myself. 2000/2001 is > > > > quite a few moons ago an then the word royalty free was real > > > > difficult to find on the map, is there a chance that the = attitude > > > > may have changed since, especially as a result of the = discussions > in > > > > IETF ?. > > > > > > > > What I can see (URL's provided by colleagues active in ITU-T, I > am > > > > not an ITU-T geek myself) the cost of participating as an > associate > > > > in ITU-T is CHF10600 (~USD10000) per year. > > > > http://www.itu.int/members/associates/fees.html > > > > > > > > The limitations with being an associate is found at > > > > http://www.itu.int/members/associates/rights.html > > > > > > > > I am interested to know what the specific problems was or are, = is > it > > > > the cost or the lack of voting rights or a combination ?. If I > > > > understand it right one cannot vote directly as an associate but > > > > there are possibilities to go via the national body. > > > > > > > > BR > > > > /Ingemar > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > > > > Skickat: ti 2009-11-10 12:38 > > > > Till: Ingemar Johansson S; codec@ietf.org > > > > =C4mne: Re: [codec] Standardization in ITU-T, what are the = issues ? > > > > > > > > > > > > > > > > Dear Ingemar, > > > > > > > > I have personally approached ITU on behalf of Global IP = Solutions > (at > > > > that time Global IP Sound), back in 2001/2002, with respect to > > > > standardization of iLBC.You can imagine the outcome. > > > > I would not recommend to any of the authors of the current set = of > > > > codecs to consider that process. > > > > This question has been brought up at the last meeting in > Stockholm > > > and > > > > I suppose the conclusion was obvious. > > > > > > > > Best regards, > > > > alan > > > > > > > > Alan Duric > > > > CTO and Cofounder > > > > Telio Holding ASA | Oslo exchange: TELIO > > > > > > > > > > > > > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > > > > > > > >> Hi > > > >> > > > >> I am curious to know to what extent proponents of a Codec WG in > IETF > > > >> has approached ITU-T with a request to standardize a RF codec. > > > >> > > > >> As I understand it there is a possibility of free membership > which > > > >> of course means limited rights to vote, however if I get this > part > > > >> correct it is a possibility to get voting rights via a countrys > > > >> standards body. There is a chance that I don't get these = details > > > >> right as I have not myself digged into the membership rules of > ITU- > > > T. > > > >> > > > >> Anyway, my question. Who has actively approached the ITU-T with > this > > > >> and what was he response ?. Also are there any meeting = documents > or > > > >> other public info that documents this ? > > > >> > > > >> BR > > > >> /Ingemar > > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >> INGEMAR JOHANSSON M.Sc. > > > >> Senior Research Engineer > > > >> > > > >> Ericsson AB > > > >> Multimedia Technologies > > > >> Labratoriegr=E4nd 11 > > > >> 971 28, Lule=E5, Sweden > > > >> Phone +46-1071 43042 > > > >> SMS/MMS +46-73 078 3289 > > > >> ingemar.s.johansson@ericsson.com > > > >> www.ericsson.com > > > >> Visit http://labs.ericsson.com ! > > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >> _______________________________________________ > > > >> 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 mknappe@juniper.net Tue Nov 10 15:44: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 04D803A69D9 for ; Tue, 10 Nov 2009 15:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 qHig2QY7+TEv for ; Tue, 10 Nov 2009 15:44:46 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A0E0C3A6B30 for ; Tue, 10 Nov 2009 15:44:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSvn6/coIcjlFErWNK+02hNHsR4iVxtny@postini.com; Tue, 10 Nov 2009 15:45:03 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 10 Nov 2009 15:45:01 -0800 From: Michael Knappe To: "Gregory M. Lebovitz" , Roni Even Date: Tue, 10 Nov 2009 15:45:08 -0800 Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: AcpiF7t8WUgFNAILRFSZgNRKCjZ6WQASBo2J Message-ID: In-Reply-To: <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 23:44:48 -0000 >From a low level codec development point of view, because of the highly int= erconnected and symbiotic model-based nature of most codec's internal compo= nents, it may be difficult to "add the best pieces into one" from multiple = submissions apart from specifying separable profiles. I do think it is wort= h exploring the concepts of things like bit-compatible interoperability (wh= ere encoders and decoders do not produce identical results given the same t= est vectors) to allow flexibility in quality and computational complexity t= radeoffs -> G.729 and G.729A is a good example of this.) Mike On 11/10/09 7:08 AM, "Gregory M. Lebovitz" wrote: At 06:30 AM 11/10/2009, Roni Even wrote: >Hi, >Inline >Roni Even > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Koen Vos > > Sent: Tuesday, November 10, 2009 10:27 PM > > To: Ingemar Johansson S > > Cc: Alan Duric; codec@ietf.org > > Subject: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > The ITU liaison stated that their policy requires royalty free (RF) or > > reasonable and non-discriminatory terms (RAND) for their standards. In > > practice that means that anyone can add IP to the standard as long as > > it brings a small improvement. > > >Roni: this is not the ITU process, if a candidate was selected based on >selection, than another party do not add to it. If collaboration take plac= e >than the parties in the collaboration need to agree what will be in a code= c. Is this a key area of difference of process between the IETF and ITU-T: - In the IETF there is most commonly all parties working together to produce something, openly adding their respective insights, and I.P. (with associated IPR statements), into one thing. - In SG16 multiple parties of one, or a small number of people, each submit a candidate codec, those codecs are compared and evaluated technically, and then advanced with the characterizations to the voting members who then consider many factors, including I.P.R. and chose one winner? This "pick the single best" vs "add the best components into one" is a big difference in the way the two SDO's go about this process, where ITU-T matches the former terse summary, and IETF matches the latter. Comments on that observation? Gregory. > > > > Unfortunately, that means their policy is incompatible with that of > > the IETF. They were fully aware of that when writing the liaison, yet > > didn't indicate a willingness to abandon their position. > > > > ITU liaison: > > https://datatracker.ietf.org/documents/LIAISON/file662.doc > > > > koen. > > > > > > Quoting Ingemar Johansson S: > > > Hi > > > > > > What was the answer?, is there any documentation of this effort in > > > the ITU-T archives. I guess there should be. I am just trying to > > > understand the reality behind the general conception that it is > > > difficult to approach ITU-T and to be honest I cannot imagine what > > > the outcome is or was as I haven't tried it myself. 2000/2001 is > > > quite a few moons ago an then the word royalty free was real > > > difficult to find on the map, is there a chance that the attitude > > > may have changed since, especially as a result of the discussions in > > > IETF ?. > > > > > > What I can see (URL's provided by colleagues active in ITU-T, I am > > > not an ITU-T geek myself) the cost of participating as an associate > > > in ITU-T is CHF10600 (~USD10000) per year. > > > http://www.itu.int/members/associates/fees.html > > > > > > The limitations with being an associate is found at > > > http://www.itu.int/members/associates/rights.html > > > > > > I am interested to know what the specific problems was or are, is it > > > the cost or the lack of voting rights or a combination ?. If I > > > understand it right one cannot vote directly as an associate but > > > there are possibilities to go via the national body. > > > > > > BR > > > /Ingemar > > > > > > > > > > > > ________________________________ > > > > > > Fr=E5n: Alan Duric [mailto:alan@telio.no] > > > Skickat: ti 2009-11-10 12:38 > > > Till: Ingemar Johansson S; codec@ietf.org > > > =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? > > > > > > > > > > > > Dear Ingemar, > > > > > > I have personally approached ITU on behalf of Global IP Solutions (at > > > that time Global IP Sound), back in 2001/2002, with respect to > > > standardization of iLBC.You can imagine the outcome. > > > I would not recommend to any of the authors of the current set of > > > codecs to consider that process. > > > This question has been brought up at the last meeting in Stockholm > > and > > > I suppose the conclusion was obvious. > > > > > > Best regards, > > > alan > > > > > > Alan Duric > > > CTO and Cofounder > > > Telio Holding ASA | Oslo exchange: TELIO > > > > > > > > > > > > On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: > > > > > >> Hi > > >> > > >> I am curious to know to what extent proponents of a Codec WG in IETF > > >> has approached ITU-T with a request to standardize a RF codec. > > >> > > >> As I understand it there is a possibility of free membership which > > >> of course means limited rights to vote, however if I get this part > > >> correct it is a possibility to get voting rights via a countrys > > >> standards body. There is a chance that I don't get these details > > >> right as I have not myself digged into the membership rules of ITU- > > T. > > >> > > >> Anyway, my question. Who has actively approached the ITU-T with this > > >> and what was he response ?. Also are there any meeting documents or > > >> other public info that documents this ? > > >> > > >> BR > > >> /Ingemar > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> INGEMAR JOHANSSON M.Sc. > > >> Senior Research Engineer > > >> > > >> Ericsson AB > > >> Multimedia Technologies > > >> Labratoriegr=E4nd 11 > > >> 971 28, Lule=E5, Sweden > > >> Phone +46-1071 43042 > > >> SMS/MMS +46-73 078 3289 > > >> ingemar.s.johansson@ericsson.com > > >> www.ericsson.com > > >> Visit http://labs.ericsson.com ! > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> _______________________________________________ > > >> 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 Tue Nov 10 15:51: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 7705628C140 for ; Tue, 10 Nov 2009 15:51:31 -0800 (PST) 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.773, BAYES_00=-2.599, 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 gkZuTm6YRbZ6 for ; Tue, 10 Nov 2009 15:51:30 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id A63FF28C0D0 for ; Tue, 10 Nov 2009 15:51:29 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 484722-1743317 for multiple; Wed, 11 Nov 2009 00:51:56 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 08:51:45 +0900 From: Stephan Wenger To: "Gregory M. Lebovitz" , Roni Even Message-ID: Thread-Topic: [codec] Standardization in ITU-T, what are the issues ? Thread-Index: AcpiYMJR/IeggTM5sku0kTaReHZwCA== In-Reply-To: <4af98201.0f1abc0a.7c72.1b6e@mx.google.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Standardization in ITU-T, what are the issues ? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Nov 2009 23:51:31 -0000 Hi Greg, With respect to your observation: First, I believe you are over-generalizing what happens in SG16. SG16 is roughly as diverse as the RAI area in the IETF. There are groups that put = a huge emphasis on collaborative work, and others which typically operate in = a less collaborative fashion that some people call shoot-out mode. Speech standardization often, though not always, has followed this latter approach= . Video standardization and most protocol related work (as well as modem work back since) followed the collaborative approach. Second, let's assume, for the sake of assumption, that people contributing to the ITU speech standardization are neither stupid nor inherently evil, and that their employers, in their vast majority--non practicing entities such as universities and IP companies excluded--have an interest in getting products out. Still with decades of experience in speech standardization, they have chosen the shoot-out mode, never mind the inherent delays and pain. People of the same employers work perfectly well together in a collaborative mode in creating video codecs and protocols. Could it just possibly be that using the shoot-out mode for speech is not bound to the organization, however encrusted in its procedures it may be, but bound to the technology? Maybe, in speech codec design, the sum of parts is not necessarily better than the parts taken in isolation? Having followed this mailing list, I have seen entirely too much position maneuvers of the key proponents to come to a radically different conclusion= . Regards, Stephan On 11/11/09 12:08 AM, "Gregory M. Lebovitz" wrote: > At 06:30 AM 11/10/2009, Roni Even wrote: >> Hi, >> Inline >> Roni Even >>=20 >>> -----Original Message----- >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>> Of Koen Vos >>> Sent: Tuesday, November 10, 2009 10:27 PM >>> To: Ingemar Johansson S >>> Cc: Alan Duric; codec@ietf.org >>> Subject: Re: [codec] Standardization in ITU-T, what are the issues ? >>>=20 >>> The ITU liaison stated that their policy requires royalty free (RF) or >>> reasonable and non-discriminatory terms (RAND) for their standards. In >>> practice that means that anyone can add IP to the standard as long as >>> it brings a small improvement. >>=20 >>=20 >> Roni: this is not the ITU process, if a candidate was selected based on >> selection, than another party do not add to it. If collaboration take pl= ace >> than the parties in the collaboration need to agree what will be in a co= dec. >=20 > Is this a key area of difference of process between the IETF and ITU-T: > - In the IETF there is most commonly all > parties working together to produce something, > openly adding their respective insights, and I.P. > (with associated IPR statements), into one thing. > - In SG16 multiple parties of one, or a small > number of people, each submit a candidate codec, > those codecs are compared and evaluated > technically, and then advanced with the > characterizations to the voting members who then > consider many factors, including I.P.R. and chose one winner? >=20 > This "pick the single best" vs "add the best > components into one" is a big difference in the > way the two SDO's go about this process, where > ITU-T matches the former terse summary, and IETF matches the latter. >=20 > Comments on that observation? >=20 > Gregory. >=20 >=20 >>>=20 >>> Unfortunately, that means their policy is incompatible with that of >>> the IETF. They were fully aware of that when writing the liaison, yet >>> didn't indicate a willingness to abandon their position. >>>=20 >>> ITU liaison: >>> https://datatracker.ietf.org/documents/LIAISON/file662.doc >>>=20 >>> koen. >>>=20 >>>=20 >>> Quoting Ingemar Johansson S: >>>> Hi >>>>=20 >>>> What was the answer?, is there any documentation of this effort in >>>> the ITU-T archives. I guess there should be. I am just trying to >>>> understand the reality behind the general conception that it is >>>> difficult to approach ITU-T and to be honest I cannot imagine what >>>> the outcome is or was as I haven't tried it myself. 2000/2001 is >>>> quite a few moons ago an then the word royalty free was real >>>> difficult to find on the map, is there a chance that the attitude >>>> may have changed since, especially as a result of the discussions in >>>> IETF ?. >>>>=20 >>>> What I can see (URL's provided by colleagues active in ITU-T, I am >>>> not an ITU-T geek myself) the cost of participating as an associate >>>> in ITU-T is CHF10600 (~USD10000) per year. >>>> http://www.itu.int/members/associates/fees.html >>>> >>>> The limitations with being an associate is found at >>>> http://www.itu.int/members/associates/rights.html >>>> >>>> I am interested to know what the specific problems was or are, is it >>>> the cost or the lack of voting rights or a combination ?. If I >>>> understand it right one cannot vote directly as an associate but >>>> there are possibilities to go via the national body. >>>>=20 >>>> BR >>>> /Ingemar >>>>=20 >>>>=20 >>>>=20 >>>> ________________________________ >>>>=20 >>>> Fr=E5n: Alan Duric [mailto:alan@telio.no] >>>> Skickat: ti 2009-11-10 12:38 >>>> Till: Ingemar Johansson S; codec@ietf.org >>>> =C4mne: Re: [codec] Standardization in ITU-T, what are the issues ? >>>>=20 >>>>=20 >>>>=20 >>>> Dear Ingemar, >>>>=20 >>>> I have personally approached ITU on behalf of Global IP Solutions (at >>>> that time Global IP Sound), back in 2001/2002, with respect to >>>> standardization of iLBC.You can imagine the outcome. >>>> I would not recommend to any of the authors of the current set of >>>> codecs to consider that process. >>>> This question has been brought up at the last meeting in Stockholm >>> and >>>> I suppose the conclusion was obvious. >>>>=20 >>>> Best regards, >>>> alan >>>>=20 >>>> Alan Duric >>>> CTO and Cofounder >>>> Telio Holding ASA | Oslo exchange: TELIO >>>>=20 >>>>=20 >>>>=20 >>>> On Nov 10, 2009, at 9:06 AM, Ingemar Johansson S wrote: >>>>=20 >>>>> Hi >>>>>=20 >>>>> I am curious to know to what extent proponents of a Codec WG in IETF >>>>> has approached ITU-T with a request to standardize a RF codec. >>>>>=20 >>>>> As I understand it there is a possibility of free membership which >>>>> of course means limited rights to vote, however if I get this part >>>>> correct it is a possibility to get voting rights via a countrys >>>>> standards body. There is a chance that I don't get these details >>>>> right as I have not myself digged into the membership rules of ITU- >>> T. >>>>>=20 >>>>> Anyway, my question. Who has actively approached the ITU-T with this >>>>> and what was he response ?. Also are there any meeting documents or >>>>> other public info that documents this ? >>>>>=20 >>>>> BR >>>>> /Ingemar >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> INGEMAR JOHANSSON M.Sc. >>>>> Senior Research Engineer >>>>>=20 >>>>> Ericsson AB >>>>> Multimedia Technologies >>>>> Labratoriegr=E4nd 11 >>>>> 971 28, Lule=E5, Sweden >>>>> Phone +46-1071 43042 >>>>> SMS/MMS +46-73 078 3289 >>>>> ingemar.s.johansson@ericsson.com >>>>> www.ericsson.com >>>>> Visit http://labs.ericsson.com ! >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Tue Nov 10 16:57: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 1619F28C20C for ; Tue, 10 Nov 2009 16:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, DATE_IN_PAST_06_12=1.069, 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 YxM4u1MuKXVy for ; Tue, 10 Nov 2009 16:57:19 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 08E3728C1F3 for ; Tue, 10 Nov 2009 16:57:18 -0800 (PST) Received: from hoeneLenovoT60 (host-19-93.meeting.ietf.org [133.93.19.93]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id nAB0vTfH011048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Nov 2009 01:57:38 +0100 From: "Christian Hoene" To: References: <334A4109C6BEA14ABB48EBCF274A6C8A055399DF@MAILBOX1.blue.itu.ch> In-Reply-To: Date: Wed, 11 Nov 2009 01:57:27 +0900 Message-ID: <000001ca6226$e9565930$bc030b90$@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: AcpiUzEoHqKWV3KvRv2k7T2SuBXB1wAMBzgA 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.1.61; VDF: 7.1.6.216; host: mx05); id=20852-yWmEJG Subject: Re: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 11 Nov 2009 00:57:20 -0000 Good morning, > > please find attached a liaison statement sent from SG 16. Reading the liaison statement, I was thinking about how a potential cooperation with Study Group 16 might look like. I do not have a firm opinion yet, however, at least three possibilities. Compete with SG16 as in the case of H.323 vs SIP, let the ITU-T do the work, or work together in some way. Considering this high risk endeavor and the lack of experiences at the IETF in regard of codec standardization, the last might be preferable. But then again, what are the risks of cooperation? Will it slow down an IETF standardization process? Will the particular requirements of the Internet be ignored? Are there increased chances that the standardization is going to be hindered or sabotaged? Will the travelling budget be exceeded? And, how the cooperation - if any - shall look like? Any opinions on that? With best regards, Christian From kpfleming@digium.com Tue Nov 10 17:03: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 14FCB3A67B1 for ; Tue, 10 Nov 2009 17:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.337 X-Spam-Level: X-Spam-Status: No, score=-105.337 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 V7LwcDxN7-Qo for ; Tue, 10 Nov 2009 17:03:18 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 12FD33A689C for ; Tue, 10 Nov 2009 17:03:18 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N81cf-0005Ok-3F for codec@ietf.org; Tue, 10 Nov 2009 19:03:45 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 12CB0DFC828 for ; Tue, 10 Nov 2009 19:03:45 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgTSuOhty0Oh for ; Tue, 10 Nov 2009 19:03:44 -0600 (CST) Received: from [133.93.24.160] (host-24-160.meeting.ietf.org [133.93.24.160]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 2D44DDFC827 for ; Tue, 10 Nov 2009 19:03:43 -0600 (CST) Message-ID: <4AFA0D6D.1020203@digium.com> Date: Wed, 11 Nov 2009 10:03:41 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: codec@ietf.org References: <334A4109C6BEA14ABB48EBCF274A6C8A055399DF@MAILBOX1.blue.itu.ch> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 11 Nov 2009 01:03:19 -0000 Cullen Jennings wrote: >> From: TSBSG16, ITU [mailto:tsbsg16@itu.int] >> Sent: 10 November 2009 10:57 >> To: Cullen Jennings; statements@ietf.org; Robert Sparks; Gregory >> Lebovitz; Russ Housley; Patrik F=E4ltstr=F6m >> Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com; >> herve.taddei@huawei.com; hiwasaki.yusuke@lab.ntt.co.jp; >> hiwasaki.yusuke@gmail.com >> Subject: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6= >> November 2009) >> >> >> >> Dear all, >> >> Kindly find attached the Liaison Statement COM16 - LS 124 on "speech >> and audio coding standardization" addressed to IETF RAI, IESG agreed >> at the ITU-T SG 16 meeting held in Geneva from 26 October to 6 >> November 2009. At the risk of inflaming the licensing discussion even further, in the ITU-T process, is it only required that the IPR disclosure claim to offer the IPR under RAND, but that there is no actual confirmation that the discloser's terms would in fact be widely agreed upon to be RAND? For example, to my knowledge, Polycom has recently begun offering royalty-free (under a patent non-assert) licensing for their IPR including in G.719. However, the other primary IPR holder in G,719 is Ericsson, and the process of determining licensing terms for their IP begins with signing a non-disclosure agreement with them. Given that, it's completely impossible to know whether a licensing offer from them is discriminatory or not, because the recipient cannot discuss the proposed terms with other existing or potential licensees. If this arrangement qualifies under the ITU-T's definition of RAND, then it seems that doesn't result in licensability under terms that most people would term 'reasonable', let alone compatible with open source licensing. --=20 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 rob.glidden@sbcglobal.net Tue Nov 10 17:22: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 25B443A6859 for ; Tue, 10 Nov 2009 17:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 0SvJZiqi2K7P for ; Tue, 10 Nov 2009 17:22:07 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 7430D3A682A for ; Tue, 10 Nov 2009 17:22:07 -0800 (PST) Received: (qmail 81797 invoked from network); 11 Nov 2009 01:22:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=U0YclwHCE/UAld+4OfK6kGFFBsqIXVaS/CzTaoBL5SyIk9MWwhfF93hCMsaoBOlreVoQWYB+jMdzIOS0moAuFmqPvZTt9bZDj7cGemg82LBK+QhlNIcSc7/LeDLhNDsdktLxdUtHCNkQhrIFIMDGlB54IV/pPNOnUf5UsJF3+A0= ; Received: from adsl-68-124-184-158.dsl.pltn13.pacbell.net (rob.glidden@68.124.184.158 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2009 17:22:28 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: 94OEX8gVM1mdGEolKsR6QcrBCIDUoYq6LBfl0cFTkujGcYu_VZlftV4RCbPiorRFtvYJpH.azevw3bNgqPduptThbmkYnq1LTdVW8esSuD8Vl_tlNENYAFs6Wjm9lopfW6pA86iDN3dgaLZ78qi3eEoKM7quSd8UyP_reTEWU9EwcEk55AWzpei.g_gXTuH3s.oHnd6DYeKtKDCW2HW6uxTPOPesOMEyB5cULxHjSuYLygl6Ro4ZpgJk5Z_CBn5wUcC9QM60TO2zvj8O_2YjSh0qrClA1EuicWex X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFA11CC.5000908@sbcglobal.net> Date: Tue, 10 Nov 2009 17:22:20 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 01:22:08 -0000 Here is my view, perhaps you share it, perhaps you don't. What the world needs now is royalty-free, standardized codecs. This is critical to the future of the Web, and the progress the Internet has brought to the world, and will bring to the world. Video, audio, transport, the whole thing. Evaluated, vetted for patents. Under an appropriate, responsible and complete royalty free process. No less. IETF, ITU, and ISO/MPEG should all get going on this important activity -- after all why shouldn't all of these organizations include this as core to their mission. I have, and no doubt you have too, seen countless explanations why this should not, could not, will not, rather not, might not, or can not happen. Some well meaning and sincere, some from vested interests. There are too many "powerful" interests against it. "Important" commercial interests are ambivalent. It is too hard "legally" or "politically" or "technically". It is just too confusing to think through. There is no longer a critical mass that cares enough about keeping the future of the Open Internet open and royalty free. The well meaning are ignorant, or naive. Etc. Don't settle. Take the issue of royalty free, standardized codecs all the way to the top of these organizations. Do what it takes. If it requires new organizations, start them. It it requires revised processes, revise them. This is the spirit that built the Web and the Internet, this is the spirit that is its lifeblood, and this is the spirit that needs to be at the heart of its future. Don't settle. Don't let those who have tried hard already, or have only half-heartedly tried, justify the status quo or their half-heartedness. Encourage them to focus on how to take the next steps. Don't let convenient "interpretations" of standards processes be an excuse for never starting, never finishing, or never setting up processes that will work. Need more legal background? Find it. More technical information? Get it. Don't settle. The world has plenty of patent-encumbered media standards, plenty of proprietary solutions, and plenty of standards in other domains that have figured out how to deliver royalty free. But the world does not have enough royalty-free codec standards, so this is the task that needs to be addressed. Rob From stewe@stewe.org Tue Nov 10 17:59: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 86E623A6BD8 for ; Tue, 10 Nov 2009 17:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 S7mEhZpyRz74 for ; Tue, 10 Nov 2009 17:59:04 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 402A43A6BD3 for ; Tue, 10 Nov 2009 17:59:02 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 484816-1743317 for multiple; Wed, 11 Nov 2009 02:59:29 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 10:59:12 +0900 From: Stephan Wenger To: "Kevin P. Fleming" Message-ID: Thread-Topic: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 2009) Thread-Index: AcpicpBJwNQnP7l+J0eh8Dd9IuRlpw== In-Reply-To: <4AFA0D6D.1020203@digium.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 11 Nov 2009 01:59:05 -0000 Hi Kevin, While, in some jurisdictions, there are tests on what qualifies as RAND and what does not, it is true that RAND commitments alone typically do not provide a potential user with guidance about the commercial terms of a license. However, it gives the potential user an assurance that a license is actually available. Some say that it makes the hurdle much higher in obtaining injunctions for unlicensed use of a patent. Both are Good Things= , from a righttaker's viewpoint. Remember, without a RAND commitment, a patent allows the rightholder to forbid anyone in the jurisdiction, for whatever reason, to use the claimed subject matter. The definition of "Reasonable" in RAND, and "Fair and Reasonable" in FRAND, are both heavily discussed and litigated. I doubt that you will full agreement on these definition if you ask more than one person. However, I have, so far, never heard that the NDA part of the story has been questione= d in the licensing community. It is common that those discussions are held under NDA. There are valid commercial and legal reasons why this is the case. RAND does NOT mean that all possible users will get the same terms after th= e bilateral discussions that are common in licensing. That is one reasons wh= y licensing discussions are typically under NDA. All that said, there is a movement ongoing in the patents&standards community to allow a rightholder, using the SDOs communication process, to provide potential users voluntarily with information of licensing terms--typically something like the maximum royalty that is being charged, and expressed as a percentage of the unit price. IEEE was the first major organization to add this to their policy. Google "patent standard ex ante" if you are interested. In a few cases, ex ante mechanisms have actually started to see use; in others, I would argue they have seen abuse. Neither the ITU nor the IETF embrace ex ante disclosures of licensing terms in thei= r policies, although, at least in the IETF, it's possible to make those. If = a rightholder were truly interested in publishing its terms, there would also be other non-SDO means to do so. For a number of (mostly antitrust-related) reasons, IMO and AFAIK, ex ante disclosures will remain voluntary in most legislations and in the foreseeable future. Stephan On 11/11/09 10:03 AM, "Kevin P. Fleming" wrote: > Cullen Jennings wrote: >=20 >>> From: TSBSG16, ITU [mailto:tsbsg16@itu.int] >>> Sent: 10 November 2009 10:57 >>> To: Cullen Jennings; statements@ietf.org; Robert Sparks; Gregory >>> Lebovitz; Russ Housley; Patrik F=E4ltstr=F6m >>> Cc: Campos, Simao; claude.lamblin@orange-ftgroup.com; >>> herve.taddei@huawei.com; hiwasaki.yusuke@lab.ntt.co.jp; >>> hiwasaki.yusuke@gmail.com >>> Subject: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 >>> November 2009) >>>=20 >>>=20 >>>=20 >>> Dear all, >>>=20 >>> Kindly find attached the Liaison Statement COM16 - LS 124 on "speech >>> and audio coding standardization" addressed to IETF RAI, IESG agreed >>> at the ITU-T SG 16 meeting held in Geneva from 26 October to 6 >>> November 2009. >=20 > At the risk of inflaming the licensing discussion even further, in the > ITU-T process, is it only required that the IPR disclosure claim to > offer the IPR under RAND, but that there is no actual confirmation that > the discloser's terms would in fact be widely agreed upon to be RAND? >=20 > For example, to my knowledge, Polycom has recently begun offering > royalty-free (under a patent non-assert) licensing for their IPR > including in G.719. However, the other primary IPR holder in G,719 is > Ericsson, and the process of determining licensing terms for their IP > begins with signing a non-disclosure agreement with them. Given that, > it's completely impossible to know whether a licensing offer from them > is discriminatory or not, because the recipient cannot discuss the > proposed terms with other existing or potential licensees. >=20 > If this arrangement qualifies under the ITU-T's definition of RAND, then > it seems that doesn't result in licensability under terms that most > people would term 'reasonable', let alone compatible with open source > licensing. From kpfleming@digium.com Tue Nov 10 18:06: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 6CA0F3A6BE4 for ; Tue, 10 Nov 2009 18:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.335 X-Spam-Level: X-Spam-Status: No, score=-105.335 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 fWHJlMKVDRUe for ; Tue, 10 Nov 2009 18:06:34 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 5E37F3A6BBC for ; Tue, 10 Nov 2009 18:06:34 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N82bt-0005uV-Jy for codec@ietf.org; Tue, 10 Nov 2009 20:07:01 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 856C0DFC827 for ; Tue, 10 Nov 2009 20:07:01 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta4tf5+Yc7Sq for ; Tue, 10 Nov 2009 20:07:00 -0600 (CST) Received: from [133.93.24.160] (host-24-160.meeting.ietf.org [133.93.24.160]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 7EE1FDFC828 for ; Tue, 10 Nov 2009 20:07:00 -0600 (CST) Message-ID: <4AFA1C41.1000201@digium.com> Date: Wed, 11 Nov 2009 11:06:57 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: codec@ietf.org References: 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] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 11 Nov 2009 02:06:35 -0000 Stephan Wenger wrote: > RAND does NOT mean that all possible users will get the same terms after the > bilateral discussions that are common in licensing. That is one reasons why > licensing discussions are typically under NDA. I wouldn't expect so, and I certainly understand why negotiations are frequently under NDA. However, it essentially removes all the 'teeth' from the 'ND' part of 'RAND'. If I approach a patent holder and they offer me licensing at 10 times the rate they have ever charged any previous party (because I am a competitor, or I am a small company, or they don't like the color of my company's logo), I would think that most people would consider that discriminatory. Since there is no recourse, their 'offer' to license under RAND could be considered to be in bad faith, and they can continue to make such offers in further standards-making processes without any concerns raised by the receivers of those offers. -- 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 rob.glidden@sbcglobal.net Tue Nov 10 19:07: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 BF00F28C26B for ; Tue, 10 Nov 2009 19:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 F4xCW77NLZ3M for ; Tue, 10 Nov 2009 19:07:00 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 00E323A67D2 for ; Tue, 10 Nov 2009 19:06:59 -0800 (PST) Received: (qmail 90221 invoked from network); 11 Nov 2009 03:07:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eYmu4x+z6c4vtoYJ5icp/rlFQg8H308tXzNSTbyBm/mh1G81ipikKo5Gd/SoTYDcjcG43ka1U0mgGlrlLLiAq5yEpPBblZ6l2YfBSqWcMnNjHd3ByPXBupzipzcI8TgI331IYRz/8R/v4KF5om23glKfMAYfOkr53ymyfyhvKmo= ; Received: from adsl-68-124-184-158.dsl.pltn13.pacbell.net (rob.glidden@68.124.184.158 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 Nov 2009 19:07:25 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: QZ2tZTkVM1lIX4.ysAGkt5Iuq.xhLy2_WrsHUdIAe6G4OkOJw8NdR4kBq202T6e8KlJtiWbSyPT9f2GRA5C.qBZCjZRsISqsxs2FcZnAHkx_CYBLThjpZLU2D.LMvZNw7tLyi3bE7x.njIFn1rEXIe7uJXfH2k5I1YoJ_nRRi1mXckkFi7aKfGF0jaYNhlLe9cezrc2sAvYQiivSk_f7UGxncUGWl.BByJSsgxRIFU4QoQqrYotRF2CN3z_ptFs2s7bV0Py6RGaP3FChKQogTJLElMbM4MxezGr6r0xtMS0F3vyTkNtGR2drSz.oAImF7oOBEItuolddi1rCGlb. X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFA2A6C.1050704@sbcglobal.net> Date: Tue, 10 Nov 2009 19:07:24 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Burger , codec@ietf.org References: <4AFA11CC.5000908@sbcglobal.net> <00A9C380-8834-4BF6-AE22-B176BA6830AB@standardstrack.com> In-Reply-To: <00A9C380-8834-4BF6-AE22-B176BA6830AB@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 03:07:00 -0000 Eric: Perhaps you would be willing to elaborate? Rob Eric Burger wrote: > If I'm not mistaken, do you not have legal training? What you ask for > is just not possible with our legal system in the U.S. or the WIPO, > either. > > I take that back, and this is why I rewrote the draft charter to place > a preference on technologies that are at least 20 years old. That > guarantees that any extant IPR has expired, even if we are not aware > of it. > > Rather than asking for perfection, I think the industry will be OK > with good enough. Unless your goal is to kill this work. In that case, > rallying people for royalty free only will ensure the engineer's > companies will prevent them from doing any work. > > > > On Nov 11, 2009, at 10:22 AM, Rob Glidden wrote: > >> Here is my view, perhaps you share it, perhaps you don't. >> >> What the world needs now is royalty-free, standardized codecs. This >> is critical to the future of the Web, and the progress the Internet >> has brought to the world, and will bring to the world. >> >> Video, audio, transport, the whole thing. Evaluated, vetted for >> patents. Under an appropriate, responsible and complete royalty free >> process. No less. >> >> IETF, ITU, and ISO/MPEG should all get going on this important >> activity -- after all why shouldn't all of these organizations >> include this as core to their mission. >> >> I have, and no doubt you have too, seen countless explanations why >> this should not, could not, will not, rather not, might not, or can >> not happen. Some well meaning and sincere, some from vested >> interests. There are too many "powerful" interests against it. >> "Important" commercial interests are ambivalent. It is too hard >> "legally" or "politically" or "technically". It is just too >> confusing to think through. There is no longer a critical mass that >> cares enough about keeping the future of the Open Internet open and >> royalty free. The well meaning are ignorant, or naive. Etc. >> >> Don't settle. Take the issue of royalty free, standardized codecs >> all the way to the top of these organizations. Do what it takes. If >> it requires new organizations, start them. It it requires revised >> processes, revise them. This is the spirit that built the Web and the >> Internet, this is the spirit that is its lifeblood, and this is the >> spirit that needs to be at the heart of its future. >> >> Don't settle. Don't let those who have tried hard already, or have >> only half-heartedly tried, justify the status quo or their >> half-heartedness. Encourage them to focus on how to take the next >> steps. Don't let convenient "interpretations" of standards processes >> be an excuse for never starting, never finishing, or never setting up >> processes that will work. Need more legal background? Find it. More >> technical information? Get it. >> >> Don't settle. The world has plenty of patent-encumbered media >> standards, plenty of proprietary solutions, and plenty of standards >> in other domains that have figured out how to deliver royalty free. >> But the world does not have enough royalty-free codec standards, so >> this is the task that needs to be addressed. >> >> Rob >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > From rchen@broadcom.com Tue Nov 10 19:09: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 87B7C28C27F for ; Tue, 10 Nov 2009 19:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFNnp0E-YN-R for ; Tue, 10 Nov 2009 19:09:09 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id BD2AC28C249 for ; Tue, 10 Nov 2009 19:09:09 -0800 (PST) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 10 Nov 2009 19:09:32 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 10 Nov 2009 19:10:54 -0800 From: "Raymond (Juin-Hwey) Chen" To: "codec@ietf.org" Date: Tue, 10 Nov 2009 19:09:30 -0800 Thread-Topic: Broadcom submits BroadVoice codecs and offers its patent rights and C source codes of BV16/BV32 royalty free Thread-Index: AcoBGqVmgpoTb8KVToaAgsBd8r5MggPc527QFHrWg3A= Message-ID: References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> In-Reply-To: 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: 66E4F56638O4574368-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [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, 11 Nov 2009 03:09:11 -0000 All, As a follow-up of my previous email below, I would like to bring to everyon= e's attention that Broadcom today issued a news release that formally annou= nced that Broadcom is offering open source BroadVoice C code royalty-free a= nd without licensing fees. See, for example, http://finance.yahoo.com/news/Broadcom-Offers-RoyaltyFree-prnews-2935046185= .html?x=3D0&.v=3D1 .=20 The open source BroadVoice C code is licensed under the GNU Lesser General = Public License (LGPL), version 2.1, as published by the Free Software Found= ation. As of now, the open source floating-point and fixed-point C code for both B= roadVoice16 and BroadVoice32 can be freely downloaded from=20 http://www.broadcom.com/broadvoice . This fulfills our previous promise in the email below to make BroadVoice16/= BroadVoice32 C code "open source" (since "open source" is a desirable featu= re of candidate codecs for the Internet Wideband Audio Codec). Thanks. Raymond=20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= aymond (Juin-Hwey) Chen Sent: Wednesday, July 29, 2009 2:12 PM To: codec@ietf.org Subject: [codec] Broadcom submits BroadVoice codecs and offers its patent r= ights and C source codes of BV16/BV32 royalty free 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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Nov 10 19:26: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 5362C28C266 for ; Tue, 10 Nov 2009 19:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RVnLjvfBA-NP for ; Tue, 10 Nov 2009 19:26:32 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 0A9AE3A6878 for ; Tue, 10 Nov 2009 19:26:32 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 81DEA60647AA1; Wed, 11 Nov 2009 03:26:59 +0000 (GMT) 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=Qc8FqJmZOMia Z4zHpctCIa+9yXQ=; b=OOj7DOJXzn1rMCMMd9sLP0a9zyEq/xEJU9miZARSw3rI 8wRTbhn77TxLICfH+c2od0TgKVXVCBflWprO03Ts1Kbd9K8gtfWfeZEl3q/YAaeq +9LGaRWOhCVaykseLPqbYsJq+tNrRPTkcfU87zBSwz35srss7xrDw0Ds2eVQTx0= 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=a1x1A9/9Y5f4Z3paZ2FE Rr28Xd7jkowa780MnvOXoAwzl4q1bwDHMVsRBwICq9csSZh664l2/bkb1D8BRj2w ObrIh9odolK3xmxgD2uTK4OBDic5Ag6hIBgXh+g32CbPwilmp4Ej5wLbX7lnAb5L KdmmT2h+soOZwbLhke6fBWs= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 803C760647A95; Wed, 11 Nov 2009 03:26:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlkzdSkN1Cid; Wed, 11 Nov 2009 03:26:50 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 1641A60647A50; Wed, 11 Nov 2009 03:26:50 +0000 (GMT) Received: from softbank218116249033.bbtec.net (softbank218116249033.bbtec.net [218.116.249.33]) by mail.skype.net (Horde Framework) with HTTP; Tue, 10 Nov 2009 19:26:50 -0800 Message-ID: <20091110192650.14630hs8dj0amxve@mail.skype.net> Date: Tue, 10 Nov 2009 19:26:50 -0800 From: Koen Vos To: Rob Glidden References: <4AFA11CC.5000908@sbcglobal.net> In-Reply-To: <4AFA11CC.5000908@sbcglobal.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) Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 03:26:33 -0000 1. Technological progress saturates. 2. Patents expire. Therefore, the performance advantage of royalty-bearing standards diminishes with time, and high-quality, royalty-free standards are unavoidable. I'm convinced that today we have reached this point of commoditization for audio and speech coding technology. koen. Quoting Rob Glidden: > Here is my view, perhaps you share it, perhaps you don't. > > What the world needs now is royalty-free, standardized codecs. This > is critical to the future of the Web, and the progress the Internet > has brought to the world, and will bring to the world. > > Video, audio, transport, the whole thing. Evaluated, vetted for > patents. Under an appropriate, responsible and complete royalty free > process. No less. > > IETF, ITU, and ISO/MPEG should all get going on this important > activity -- after all why shouldn't all of these organizations > include this as core to their mission. > > I have, and no doubt you have too, seen countless explanations why > this should not, could not, will not, rather not, might not, or can > not happen. Some well meaning and sincere, some from vested > interests. There are too many "powerful" interests against it. > "Important" commercial interests are ambivalent. It is too hard > "legally" or "politically" or "technically". It is just too > confusing to think through. There is no longer a critical mass that > cares enough about keeping the future of the Open Internet open and > royalty free. The well meaning are ignorant, or naive. Etc. > > Don't settle. Take the issue of royalty free, standardized codecs > all the way to the top of these organizations. Do what it takes. If > it requires new organizations, start them. It it requires revised > processes, revise them. This is the spirit that built the Web and > the Internet, this is the spirit that is its lifeblood, and this is > the spirit that needs to be at the heart of its future. > > Don't settle. Don't let those who have tried hard already, or have > only half-heartedly tried, justify the status quo or their > half-heartedness. Encourage them to focus on how to take the next > steps. Don't let convenient "interpretations" of standards > processes be an excuse for never starting, never finishing, or never > setting up processes that will work. Need more legal background? > Find it. More technical information? Get it. > > Don't settle. The world has plenty of patent-encumbered media > standards, plenty of proprietary solutions, and plenty of standards > in other domains that have figured out how to deliver royalty free. > But the world does not have enough royalty-free codec standards, so > this is the task that needs to be addressed. > > Rob > > > > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From bmschwar@fas.harvard.edu Tue Nov 10 19:40: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 B61623A6C09 for ; Tue, 10 Nov 2009 19:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm8+KAHwtsY0 for ; Tue, 10 Nov 2009 19:40:47 -0800 (PST) Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by core3.amsl.com (Postfix) with ESMTP id 975B53A6C08 for ; Tue, 10 Nov 2009 19:40:47 -0800 (PST) Received: from us24.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us24.unix.fas.harvard.edu (Postfix) with ESMTP id C714446DEC0; Tue, 10 Nov 2009 22:41:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mail; bh=GVZDzOXVFKrUWbBKqXXPqgct/Osni4zDwa2c/0M6pzw=; b=fO6M EFV+fgf4d4IW1dtWR7gP77LHsx8rcj7xIACbJp2Kg89E0B3V6/zspj4pgQ7h2kor vf4UFgUAnAUx3gfmFPm2/y78/WK6qcN8MKBrZjlLTTJaLXto1NYK4FZB2dsmjQkV qEEQnbedvFtH/O+Amqnv2zm2/H1yGeZKx3SEhpY= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=mail; b=QaBioMSwEYCy8AS3hsPeskPrDkxlU5wdQqxP6WSq9/s1kQ g+VyyH4SRDXw4GaeluSBPJyVHaFP7ZEHbvI+r1qGDts/O55JlJgb7/cDCVLWyDqt HrW5M5uNiRhaKxQRxhSve5PdSLCYce2qC2xSQt3djL4+9WJ/NJIsxd36j8K3k= Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us24.unix.fas.harvard.edu (Postfix) with ESMTPSA id B70F446DE19; Tue, 10 Nov 2009 22:41:14 -0500 (EST) Message-ID: <4AFA3254.9040802@fas.harvard.edu> Date: Tue, 10 Nov 2009 22:41:08 -0500 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: "Raymond (Juin-Hwey) Chen" References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [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 Reply-To: bens@alum.mit.edu 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, 11 Nov 2009 03:40:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Raymond (Juin-Hwey) Chen wrote: > Broadcom today issued a news release that formally announced that Broadcom is offering open source BroadVoice C code royalty-free and without licensing fees. Thank you, and congratulations! This will make the rest of our codec development process even more exciting. Today, Broadcom is leading by example. - --Ben Schwartz -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkr6MlQACgkQUJT6e6HFtqTojACeLQ/ZhTC2CKIU4taG2ujI3ZOp 0aoAn1yjPiYcyj7lTHkUlbL++0EvX/Vq =y85O -----END PGP SIGNATURE----- From stewe@stewe.org Tue Nov 10 20:15: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 BFEF83A6BFF for ; Tue, 10 Nov 2009 20:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 MRlZCZfSFapM for ; Tue, 10 Nov 2009 20:15:12 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 6D4C43A67AF for ; Tue, 10 Nov 2009 20:15:12 -0800 (PST) Received: from [133.93.24.137] (unverified [133.93.24.137]) by stewe.org (SurgeMail 3.9e) with ESMTP id 484943-1743317 for multiple; Wed, 11 Nov 2009 05:15:39 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 13:15:30 +0900 From: Stephan Wenger To: Koen Vos , Rob Glidden Message-ID: Thread-Topic: [codec] Royalty Free codec standards -- don't settle for less Thread-Index: AcpihZrBEiMHoNgRi0Ktmt/iuLgE8A== In-Reply-To: <20091110192650.14630hs8dj0amxve@mail.skype.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 133.93.24.137 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 04:15:13 -0000 The existence of at least a dozend of projects in the speech coding field today suggests to me that we have not yet reached the point of technology progress saturation in this field. Other that this minor point, I agree. Stephan On 11/11/09 12:26 PM, "Koen Vos" wrote: > 1. Technological progress saturates. > 2. Patents expire. > Therefore, the performance advantage of royalty-bearing standards > diminishes with time, and high-quality, royalty-free standards are > unavoidable. I'm convinced that today we have reached this point of > commoditization for audio and speech coding technology. > > koen. > > > Quoting Rob Glidden: >> Here is my view, perhaps you share it, perhaps you don't. >> >> What the world needs now is royalty-free, standardized codecs. This >> is critical to the future of the Web, and the progress the Internet >> has brought to the world, and will bring to the world. >> >> Video, audio, transport, the whole thing. Evaluated, vetted for >> patents. Under an appropriate, responsible and complete royalty free >> process. No less. >> >> IETF, ITU, and ISO/MPEG should all get going on this important >> activity -- after all why shouldn't all of these organizations >> include this as core to their mission. >> >> I have, and no doubt you have too, seen countless explanations why >> this should not, could not, will not, rather not, might not, or can >> not happen. Some well meaning and sincere, some from vested >> interests. There are too many "powerful" interests against it. >> "Important" commercial interests are ambivalent. It is too hard >> "legally" or "politically" or "technically". It is just too >> confusing to think through. There is no longer a critical mass that >> cares enough about keeping the future of the Open Internet open and >> royalty free. The well meaning are ignorant, or naive. Etc. >> >> Don't settle. Take the issue of royalty free, standardized codecs >> all the way to the top of these organizations. Do what it takes. If >> it requires new organizations, start them. It it requires revised >> processes, revise them. This is the spirit that built the Web and >> the Internet, this is the spirit that is its lifeblood, and this is >> the spirit that needs to be at the heart of its future. >> >> Don't settle. Don't let those who have tried hard already, or have >> only half-heartedly tried, justify the status quo or their >> half-heartedness. Encourage them to focus on how to take the next >> steps. Don't let convenient "interpretations" of standards >> processes be an excuse for never starting, never finishing, or never >> setting up processes that will work. Need more legal background? >> Find it. More technical information? Get it. >> >> Don't settle. The world has plenty of patent-encumbered media >> standards, plenty of proprietary solutions, and plenty of standards >> in other domains that have figured out how to deliver royalty free. >> But the world does not have enough royalty-free codec standards, so >> this is the task that needs to be addressed. >> >> Rob >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 eburger@standardstrack.com Tue Nov 10 21:17: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 D24AE28C26C for ; Tue, 10 Nov 2009 21:17:01 -0800 (PST) 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 nwz4IbB62KWn for ; Tue, 10 Nov 2009 21:17:00 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id CECF33A6910 for ; Tue, 10 Nov 2009 21:17:00 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N85a3-0005u4-2S; Tue, 10 Nov 2009 21:17:19 -0800 Message-Id: <4E3DDDA0-C7D0-4D30-BA4C-961E449902AD@standardstrack.com> From: Eric Burger To: Rob Glidden In-Reply-To: <4AFA2A6C.1050704@sbcglobal.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 14:17:22 +0900 References: <4AFA11CC.5000908@sbcglobal.net> <00A9C380-8834-4BF6-AE22-B176BA6830AB@standardstrack.com> <4AFA2A6C.1050704@sbcglobal.net> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 05:17:01 -0000 If the goal is to ensure we do not produce anything for ten years, sure, let us form task groups with tens of members to research all of the patent literature, technical literature, and press materials; catalog the information; and come to written, published, and peer- reviewed expert opinion, we MIGHT have a near guarantee of a Royalty Free codec. That will cost the industry at least USD 75M (average 50 people, average cost of US$ 150,000/year, 10 years). Since most of the participants have day jobs or are consultants paid by corporations, well run companies would say $10M in royalties is a bargain. With these numbers, the intellectual property system works, and the world is better off paying inventors royalties. If the goal is to have a reasonable chance of producing a royalty free codec in the next three years, then I would offer the proposed charter has a high chance of success. Use codecs that are known to have no asserted IPR, use codecs that are older than 20 years old, and use codecs that have been out for a few years that no one has asserted rights against, and we have a reasonable expectation the result will be royalty free. On Nov 11, 2009, at 12:07 PM, Rob Glidden wrote: > Eric: > > Perhaps you would be willing to elaborate? > > Rob > > Eric Burger wrote: >> If I'm not mistaken, do you not have legal training? What you ask >> for is just not possible with our legal system in the U.S. or the >> WIPO, either. >> >> I take that back, and this is why I rewrote the draft charter to >> place a preference on technologies that are at least 20 years old. >> That guarantees that any extant IPR has expired, even if we are not >> aware of it. >> >> Rather than asking for perfection, I think the industry will be OK >> with good enough. Unless your goal is to kill this work. In that >> case, rallying people for royalty free only will ensure the >> engineer's companies will prevent them from doing any work. >> >> >> >> On Nov 11, 2009, at 10:22 AM, Rob Glidden wrote: >> >>> Here is my view, perhaps you share it, perhaps you don't. >>> >>> What the world needs now is royalty-free, standardized codecs. >>> This is critical to the future of the Web, and the progress the >>> Internet has brought to the world, and will bring to the world. >>> >>> Video, audio, transport, the whole thing. Evaluated, vetted for >>> patents. Under an appropriate, responsible and complete royalty >>> free process. No less. >>> >>> IETF, ITU, and ISO/MPEG should all get going on this important >>> activity -- after all why shouldn't all of these organizations >>> include this as core to their mission. >>> >>> I have, and no doubt you have too, seen countless explanations why >>> this should not, could not, will not, rather not, might not, or >>> can not happen. Some well meaning and sincere, some from vested >>> interests. There are too many "powerful" interests against it. >>> "Important" commercial interests are ambivalent. It is too hard >>> "legally" or "politically" or "technically". It is just too >>> confusing to think through. There is no longer a critical mass >>> that cares enough about keeping the future of the Open Internet >>> open and royalty free. The well meaning are ignorant, or naive. >>> Etc. >>> >>> Don't settle. Take the issue of royalty free, standardized codecs >>> all the way to the top of these organizations. Do what it takes. >>> If it requires new organizations, start them. It it requires >>> revised processes, revise them. This is the spirit that built the >>> Web and the Internet, this is the spirit that is its lifeblood, >>> and this is the spirit that needs to be at the heart of its future. >>> >>> Don't settle. Don't let those who have tried hard already, or >>> have only half-heartedly tried, justify the status quo or their >>> half-heartedness. Encourage them to focus on how to take the next >>> steps. Don't let convenient "interpretations" of standards >>> processes be an excuse for never starting, never finishing, or >>> never setting up processes that will work. Need more legal >>> background? Find it. More technical information? Get it. >>> >>> Don't settle. The world has plenty of patent-encumbered media >>> standards, plenty of proprietary solutions, and plenty of >>> standards in other domains that have figured out how to deliver >>> royalty free. But the world does not have enough royalty-free >>> codec standards, so this is the task that needs to be addressed. >>> >>> Rob >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >> >> > From kpfleming@digium.com Tue Nov 10 21:30: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 1143928C29A for ; Tue, 10 Nov 2009 21:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.316 X-Spam-Level: X-Spam-Status: No, score=-105.316 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 8wTm1ca9EBw1 for ; Tue, 10 Nov 2009 21:30:34 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 1D32628C27C for ; Tue, 10 Nov 2009 21:30:34 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N85nJ-0007Pb-Il for codec@ietf.org; Tue, 10 Nov 2009 23:31:01 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 8E3FBDFC828 for ; Tue, 10 Nov 2009 23:31:01 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYINvI5gFMA2 for ; Tue, 10 Nov 2009 23:31:01 -0600 (CST) Received: from [133.93.24.160] (host-24-160.meeting.ietf.org [133.93.24.160]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id D45B7DFC827 for ; Tue, 10 Nov 2009 23:31:00 -0600 (CST) Message-ID: <4AFA4C12.8050502@digium.com> Date: Wed, 11 Nov 2009 14:30:58 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: "codec@ietf.org" References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <4AFA3254.9040802@fas.harvard.edu> In-Reply-To: <4AFA3254.9040802@fas.harvard.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [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, 11 Nov 2009 05:30:35 -0000 Benjamin M. Schwartz wrote: > Raymond (Juin-Hwey) Chen wrote: >> Broadcom today issued a news release that formally announced that Broadcom is offering open source BroadVoice C code royalty-free and without licensing fees. > > Thank you, and congratulations! This will make the rest of our codec > development process even more exciting. Today, Broadcom is leading by > example. Well, not to diminish Broadcom's very welcome efforts, they are actually second to the party, since CELT was already open source quite some time ago :-) -- 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 eburger@standardstrack.com Tue Nov 10 22:29: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 8B24F3A698E for ; Tue, 10 Nov 2009 22:29:45 -0800 (PST) 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 JaI-BLAGypdI for ; Tue, 10 Nov 2009 22:29:44 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 989553A6A49 for ; Tue, 10 Nov 2009 22:29:41 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N86i7-0006wi-7x; Tue, 10 Nov 2009 22:29:43 -0800 Message-Id: <7E5EF65E-0760-4D43-9F8F-72B874468300@standardstrack.com> From: Eric Burger 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 v936) Date: Wed, 11 Nov 2009 15:29:48 +0900 References: X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 06:29:45 -0000 In practical terms, I agree that there will be better and better codecs in the future. However, I would offer the older codecs are good enough for our purposes and will be safe. On Nov 11, 2009, at 1:15 PM, Stephan Wenger wrote: > The existence of at least a dozend of projects in the speech coding > field > today suggests to me that we have not yet reached the point of > technology > progress saturation in this field. Other that this minor point, I > agree. > > Stephan > > > > On 11/11/09 12:26 PM, "Koen Vos" wrote: > >> 1. Technological progress saturates. >> 2. Patents expire. >> Therefore, the performance advantage of royalty-bearing standards >> diminishes with time, and high-quality, royalty-free standards are >> unavoidable. I'm convinced that today we have reached this point of >> commoditization for audio and speech coding technology. >> >> koen. >> >> >> Quoting Rob Glidden: >>> Here is my view, perhaps you share it, perhaps you don't. >>> >>> What the world needs now is royalty-free, standardized codecs. This >>> is critical to the future of the Web, and the progress the Internet >>> has brought to the world, and will bring to the world. >>> >>> Video, audio, transport, the whole thing. Evaluated, vetted for >>> patents. Under an appropriate, responsible and complete royalty free >>> process. No less. >>> >>> IETF, ITU, and ISO/MPEG should all get going on this important >>> activity -- after all why shouldn't all of these organizations >>> include this as core to their mission. >>> >>> I have, and no doubt you have too, seen countless explanations why >>> this should not, could not, will not, rather not, might not, or can >>> not happen. Some well meaning and sincere, some from vested >>> interests. There are too many "powerful" interests against it. >>> "Important" commercial interests are ambivalent. It is too hard >>> "legally" or "politically" or "technically". It is just too >>> confusing to think through. There is no longer a critical mass that >>> cares enough about keeping the future of the Open Internet open and >>> royalty free. The well meaning are ignorant, or naive. Etc. >>> >>> Don't settle. Take the issue of royalty free, standardized codecs >>> all the way to the top of these organizations. Do what it takes. If >>> it requires new organizations, start them. It it requires revised >>> processes, revise them. This is the spirit that built the Web and >>> the Internet, this is the spirit that is its lifeblood, and this is >>> the spirit that needs to be at the heart of its future. >>> >>> Don't settle. Don't let those who have tried hard already, or have >>> only half-heartedly tried, justify the status quo or their >>> half-heartedness. Encourage them to focus on how to take the next >>> steps. Don't let convenient "interpretations" of standards >>> processes be an excuse for never starting, never finishing, or never >>> setting up processes that will work. Need more legal background? >>> Find it. More technical information? Get it. >>> >>> Don't settle. The world has plenty of patent-encumbered media >>> standards, plenty of proprietary solutions, and plenty of standards >>> in other domains that have figured out how to deliver royalty free. >>> But the world does not have enough royalty-free codec standards, so >>> this is the task that needs to be addressed. >>> >>> Rob >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 eburger@standardstrack.com Tue Nov 10 22:30: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 B6DC228C29B for ; Tue, 10 Nov 2009 22:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 VgEXQL6yLh71 for ; Tue, 10 Nov 2009 22:30:48 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id A48B128C290 for ; Tue, 10 Nov 2009 22:30:48 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N86jS-00078G-IS; Tue, 10 Nov 2009 22:31:06 -0800 Message-Id: From: Eric Burger To: Kevin P. Fleming In-Reply-To: <4AFA1C41.1000201@digium.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 15:31:12 +0900 References: <4AFA1C41.1000201@digium.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] Fwd: COM 16-LS 124 - Outgoing LS from SG16 meeting (26 October - 6 November 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, 11 Nov 2009 06:30:50 -0000 Welcome to the world of standards. This issue almost tore the W3C apart. At the end of the day, after a year of fierce, destructive fighting, we ended up pretty much where we started from. This stuff has to do with law and business, neither of which seem to be governed by the laws of physics. That is, logic does not apply. On Nov 11, 2009, at 11:06 AM, Kevin P. Fleming wrote: > Stephan Wenger wrote: > >> RAND does NOT mean that all possible users will get the same terms >> after the >> bilateral discussions that are common in licensing. That is one >> reasons why >> licensing discussions are typically under NDA. > > I wouldn't expect so, and I certainly understand why negotiations are > frequently under NDA. However, it essentially removes all the 'teeth' > from the 'ND' part of 'RAND'. If I approach a patent holder and they > offer me licensing at 10 times the rate they have ever charged any > previous party (because I am a competitor, or I am a small company, or > they don't like the color of my company's logo), I would think that > most > people would consider that discriminatory. Since there is no recourse, > their 'offer' to license under RAND could be considered to be in bad > faith, and they can continue to make such offers in further > standards-making processes without any concerns raised by the > receivers > of those offers. > > -- > 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 eburger@standardstrack.com Tue Nov 10 22:33: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 22B9C28C29B for ; Tue, 10 Nov 2009 22:33:24 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcfsYLpP+v6q for ; Tue, 10 Nov 2009 22:33:22 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 943133A6916 for ; Tue, 10 Nov 2009 22:33:22 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N86lw-0007R5-3O; Tue, 10 Nov 2009 22:33:40 -0800 Message-Id: From: Eric Burger To: Raymond (Juin-Hwey) Chen 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 v936) Date: Wed, 11 Nov 2009 15:33:46 +0900 References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: "codec@ietf.org" Subject: Re: [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, 11 Nov 2009 06:33:24 -0000 When you submit your Internet Draft, when the time comes, please do =20 not forget to submit the IPR declaration, indicating Royalty Free, too. This is a note for everyone that wishes to submit their IPR. BTW, you can tell your lawyers not to fret - most declarations are of =20= the form, "If accepted and incorporated into a standards track RFC." =20 That means that you can retain your rights up to the point of =20 publication. At that point we welcome your gift of IPR and change =20 control. On Nov 11, 2009, at 12:09 PM, Raymond (Juin-Hwey) Chen wrote: > All, > > As a follow-up of my previous email below, I would like to bring to =20= > everyone's attention that Broadcom today issued a news release that =20= > formally announced that Broadcom is offering open source BroadVoice =20= > C code royalty-free and without licensing fees. See, for example, > = http://finance.yahoo.com/news/Broadcom-Offers-RoyaltyFree-prnews-293504618= 5.html?x=3D0&.v=3D1=20 > . > The open source BroadVoice C code is licensed under the GNU Lesser =20 > General Public License (LGPL), version 2.1, as published by the Free =20= > Software Foundation. > > As of now, the open source floating-point and fixed-point C code for =20= > both BroadVoice16 and BroadVoice32 can be freely downloaded from > http://www.broadcom.com/broadvoice . > > This fulfills our previous promise in the email below to make =20 > BroadVoice16/BroadVoice32 C code "open source" (since "open source" =20= > is a desirable feature of candidate codecs for the Internet Wideband =20= > Audio Codec). > > Thanks. > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Raymond (Juin-Hwey) Chen > Sent: Wednesday, July 29, 2009 2:12 PM > To: codec@ietf.org > Subject: [codec] Broadcom submits BroadVoice codecs and offers its =20 > patent rights and C source codes of BV16/BV32 royalty free > > All, > > If the IETF codec WG is formed, Broadcom Corporation would like to =20 > submit its family of BroadVoice=AE16 (BV16) and BroadVoice32 (BV32) =20= > standard codecs to the IETF codec WG for consideration as a =20 > candidate codec or a candidate building block for the proposed =20 > Internet Wideband Audio Codec (IWAC) standard. Currently Broadcom =20 > is already offering its patent rights, floating-point C source =20 > codes, and fixed-point C source codes of BV16/BV32 on a royalty-free =20= > 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 =20 > organizations for VoIP applications in cable telephony. BV16 is a =20 > 16 kb/s codec for 8 kHz narrowband signals; it is a standard codec =20 > in the following standards: PacketCableT 1.5, PacketCable 2.0, ANSI/=20= > SCTE 24-21 2006, and ITU-T Recommendation J.161. Similarly, BV32 =20 > is a 32 kb/s codec for 16 kHz wideband signals, and it is a standard =20= > codec in PacketCable 2.0, ANSI/SCTE 24-23 2007, and ITU-T =20 > Recommendation J.361. The RTP payload formats for BV16 and BV32 are =20= > specified in RFC4298. BV16 and BV32 belong to the same family of =20 > codecs. They have very similar codec structures and share most of =20 > the algorithm modules, so if the two are implemented together, =20 > substantial code sharing and memory reduction can be achieved. > > Broadcom developed BV16 and BV32 from the ground up with a goal of =20 > avoiding known third-party intellectual property rights (IPR). =20 > Although it was correctly pointed out earlier in the IETF codec WG =20 > email discussion that no one can be absolutely sure that a given =20 > codec is completely free of third-party IPR, we took two steps to =20 > help increase our confidence. First, to help avoid the codec IPR =20 > minefield, we purposely avoided the popular and heavily-patented =20 > CELP coding paradigm, and instead took an "ancient art" (circa. =20 > 1954) technique of noise feedback coding (NFC) that nobody seemed to =20= > be interested in (i.e., it was the subject of very few recent =20 > publications) and improved it to get BV16/BV32. Any patent on the =20 > fundamental NFC presumably expired long ago. Second, several =20 > extensive patent searches were performed during the development of =20 > BV16/BV32 to help avoid third-party IPR. To the best of our =20 > knowledge, BV16 and BV32 do not infringe on any valid unexpired =20 > third-party patent claim. > > BV16 and BV32 were also designed from the ground up to be optimized =20= > for voice transmission over IP networks, with high speech quality, =20 > low latency, low complexity, and high robustness to packet loss as =20 > primary design goals. Thus, BV16 and BV32 are ideally suited for =20 > low-latency, high-quality voice transmission over the Internet. The =20= > following summarizes the attributes of BV16 and BV32: > > . Low Delay (Latency): algorithmic buffering delay of merely 5 ms =20= > (compared with 15 to 40 ms of competing codecs) > . Low Complexity: much lower MIPS requirements than most competing = =20 > codecs (typically =BD to 1/3 of comparable ITU-T G.72x codecs), also =20= > lower memory requirement than most other competing codecs > . High Quality: equivalent or better speech quality than competing = =20 > codecs in extensive formal subjective MOS listening tests conducted =20= > by AT&T Labs, COMSAT Labs, and Dynastat, Inc. > . Availability: Broadcom is offering its patent rights, floating-=20= > point and fixed-point C source codes of BV16/BV32 on a royalty-free =20= > basis; BV16/BV32 to become open source soon. > > For comprehensive comparisons between BV16/BV32 and other codecs, =20 > please see the codec comparison tables in Annexes C and D (pages 73 =20= > - 81) of the PacketCable 2.0 Codec and Media Specification, =20 > available at: > > = http://www.packetcable.com/downloads/specs/PKT-SP-CODEC-MEDIA-I02-061013.p= df > > Broadcom believes that as compared to the other nearly two dozen =20 > dominant codecs listed there, BV16 and BV32 offer the most =20 > compelling combinations of low delay, low complexity, high quality, =20= > moderate bit-rate, and royalty-free patent rights and C source =20 > codes. The algorithm descriptions of BV16 and BV32 can be found in =20= > 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 =20= > WG reflector that voice transmission over the Internet is the =20 > primary application of the proposed IWAC, although transmitting =20 > general audio (music, etc.) at high fidelity is also desirable/=20 > necessary. It is also clear from the emails that royalty-free, low =20 > latency, and high quality are all highly desirable. Given what was =20= > described above about BV16/BV32, it would seem that BV16/BV32 is an =20= > ideal candidate and is sufficient to cover the narrowband (8 kHz) =20 > and wideband (16 kHz) voice transmission aspects of the applications =20= > of IWAC. To get higher sampling rates and higher audio bandwidths, =20= > it is possible to use BV16 and BV32 as the base layers and add =20 > additional bits on top of the BV16/BV32 bit-streams to encode an =20 > appropriately formulated difference signal to get a scalable, =20 > embedded codec that goes from 8 kHz sampling at 16 kb/s all the way =20= > to 48 kHz sampling at a much higher bit-rate. One advantage of =20 > doing so is that the resulting IWAC will be interoperable with the =20 > BV16/BV32 in the PacketCable, ANSI/SCTE, and ITU-T J.161/J.361 =20 > standards. This is similar to the relationship between ITU-T G.729.1 =20= > and G.729. > > Juin-Hwey (Raymond) Chen > Broadcom Corporation > > > > _______________________________________________ > 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 Wed Nov 11 07:26: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 CE9EB3A672F for ; Wed, 11 Nov 2009 07:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 RPyGYyu9G2Yd for ; Wed, 11 Nov 2009 07:26:00 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1C7FF3A68E2 for ; Wed, 11 Nov 2009 07:25:59 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-f5-4afad7a2b195 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 88.FD.04191.2A7DAFA4; Wed, 11 Nov 2009 16:26:26 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 16:26:26 +0100 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, 11 Nov 2009 16:26:24 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: G.719 royalty-free license Thread-Index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQ== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 11 Nov 2009 15:26:26.0696 (UTC) FILETIME=[559D7080:01CA62E3] X-Brightmail-Tracker: AAAAAA== Subject: [codec] G.719 royalty-free 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: Wed, 11 Nov 2009 15:26:07 -0000 Hi I have the following announcement regarding G.719 Ericsson offers a royalty-free license under Ericsson's G.719 standard = essential patents for end user products.=20 The license agreement can be obtained by contacting = patent.licensing@ericsson.com =20 Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From jean-marc.valin@octasic.com Wed Nov 11 07:53: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 749593A67F4 for ; Wed, 11 Nov 2009 07:53:53 -0800 (PST) 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 fGx0od8CvvOU for ; Wed, 11 Nov 2009 07:53:52 -0800 (PST) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 6D6D83A67A1 for ; Wed, 11 Nov 2009 07:53:50 -0800 (PST) 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_01CA62E7.39A0D318" Date: Wed, 11 Nov 2009 10:53:22 -0500 Message-ID: <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: G.719 royalty-free license Thread-Index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAA8Pu7 References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> From: "Jean-Marc Valin" To: "Ingemar Johansson S" , Subject: Re: [codec] G.719 royalty-free 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: Wed, 11 Nov 2009 15:53:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62E7.39A0D318 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think this is great news! I guess this shows that collaboration would = be possible. I would personally like to invite Ericsson to contribute = the G.719 technology as input to the proposed working group. This could = certainly help towards meeting some of the requirements we currently = have and create an overall better codec. Cheers, Jean-Marc -----Original Message----- From: codec-bounces@ietf.org on behalf of Ingemar Johansson S Sent: Wed 11/11/2009 10:26 AM To: codec@ietf.org Subject: [codec] G.719 royalty-free license =20 Hi I have the following announcement regarding G.719 Ericsson offers a royalty-free license under Ericsson's G.719 standard = essential patents for end user products.=20 The license agreement can be obtained by contacting = patent.licensing@ericsson.com =20 Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA62E7.39A0D318 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [codec] G.719 royalty-free license

Hi,

I think this is great news! I guess this shows that collaboration would = be possible. I would personally like to invite Ericsson to contribute = the G.719 technology as input to the proposed working group. This could = certainly help towards meeting some of the requirements we currently = have and create an overall better codec.

Cheers,

        Jean-Marc


-----Original Message-----
From: codec-bounces@ietf.org on behalf of Ingemar Johansson S
Sent: Wed 11/11/2009 10:26 AM
To: codec@ietf.org
Subject: [codec] G.719 royalty-free license

Hi

I have the following announcement regarding G.719

Ericsson offers a royalty-free license under Ericsson's G.719 standard = essential patents for end user products.
The license agreement can be obtained by contacting = patent.licensing@ericsson.com


Regards
Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Visit http://labs.ericsson.com = !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------_=_NextPart_001_01CA62E7.39A0D318-- From anisse.taleb@gmail.com Wed Nov 11 07:38: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 162E03A6A17 for ; Wed, 11 Nov 2009 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+4e5JqgVDO9 for ; Wed, 11 Nov 2009 07:38:05 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 13F673A69B0 for ; Wed, 11 Nov 2009 07:38:04 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so278258eyd.51 for ; Wed, 11 Nov 2009 07:38:30 -0800 (PST) Received: by 10.213.2.67 with SMTP id 3mr5035689ebi.77.1257953909915; Wed, 11 Nov 2009 07:38:29 -0800 (PST) Received: from Moou ([217.167.116.122]) by mx.google.com with ESMTPS id 23sm658677eya.4.2009.11.11.07.38.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 07:38:29 -0800 (PST) From: "Anisse Taleb" To: "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> Date: Wed, 11 Nov 2009 16:38:26 +0100 Message-ID: <4afada75.1701d00a.2238.14e3@mx.google.com> 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: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAAU4AQ Content-language: sv Subject: Re: [codec] G.719 royalty-free 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: Wed, 11 Nov 2009 16:09:35 -0000 Hi Ingo, This is indeed quite interesting news given that this is a brand new = codec and the first ITU-T fullband conversational codec. I assume this means that the codec is entirely royalty free since = Polycom offers also a royalty free license? Any comments on this? Thanks for the information. /Abisse=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Ingemar Johansson S > Sent: den 11 november 2009 16:26 > To: codec@ietf.org > Subject: [codec] G.719 royalty-free license >=20 > Hi >=20 > I have the following announcement regarding G.719 >=20 > Ericsson offers a royalty-free license under Ericsson's G.719 standard > essential patents for end user products. > The license agreement can be obtained by contacting > patent.licensing@ericsson.com >=20 >=20 > Regards > Ingemar > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer >=20 > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From bmschwar@fas.harvard.edu Wed Nov 11 08:29: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 887E63A6A78 for ; Wed, 11 Nov 2009 08:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 TIFvHf76VEAa for ; Wed, 11 Nov 2009 08:29:55 -0800 (PST) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by core3.amsl.com (Postfix) with ESMTP id 852563A6A72 for ; Wed, 11 Nov 2009 08:29:55 -0800 (PST) Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id 25D574D5C2D; Wed, 11 Nov 2009 11:30:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=QJgmxAJ+FEVCacY JpTssYHqqMMTSXMEuS+1tVBXA4RM=; b=CLOBC15/4v1ctdbOgosVdnUS5kdMm2B gtdmGJ34v+vEHZBGTciaCj8bIKhsEGpc6Hrry07Hbilxv5AeuTj6uMQ6evXoiO02 5u6It+pV0qzNB9OV2xhQDBveS7DPtERUrclnudqtuNKjr7/cZWHlorcYKKEGpw5K DcqCZ/9SVXX0= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=m+b99qL9W +npgkAGS8Tobc0oPZQ9ihu0sJTDFpvJ1+qm9DnMCI6m7RteRgv0mLOgaRAYcU558 XLpNSOlh0I/3pzf1PeR+c5lS04KQrfelM0InCpGd6EwRfTDr+RPeBOMyRoYFNZFo YVDuBHtLFhJnEBPVjDu/RN24PERHZZUSEM= Received: from [172.23.141.114] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 203F34D5B96; Wed, 11 Nov 2009 11:30:23 -0500 (EST) Message-ID: <4AFAE69E.500@fas.harvard.edu> Date: Wed, 11 Nov 2009 11:30:22 -0500 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: Anisse Taleb References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> In-Reply-To: <4afada75.1701d00a.2238.14e3@mx.google.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C1BC88EDC0F5098E67FB902" Cc: codec@ietf.org Subject: Re: [codec] G.719 royalty-free license X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu 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, 11 Nov 2009 16:29:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C1BC88EDC0F5098E67FB902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anisse Taleb wrote: > I assume this means that the codec is entirely royalty free since Polyc= om > offers also a royalty free license? Any comments on this? Polycom's license is "royalty free" but contains various use restrictions= and advertising clauses. It is far from "no strings attached". We don't= know what Ericsson's license says, although we now know how to find out what it is. Even Ericsson's license were a universal binding patent non-assertion statement, the codec would still not be compatible with common open-source licenses due to Polycom's patent licensing restriction= s. --Ben --------------enig2C1BC88EDC0F5098E67FB902 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkr65p4ACgkQUJT6e6HFtqTu6gCfba2z42an2Rhwfrc9fW/57/ZE +4MAoIuuz82yxQoUwR/C74gGm8rScMjJ =aBHI -----END PGP SIGNATURE----- --------------enig2C1BC88EDC0F5098E67FB902-- From rob.glidden@sbcglobal.net Wed Nov 11 09:10: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 DF59C3A6886 for ; Wed, 11 Nov 2009 09:10:47 -0800 (PST) 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.603, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 4e6smE889yT1 for ; Wed, 11 Nov 2009 09:10:46 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 7D8013A686E for ; Wed, 11 Nov 2009 09:10:44 -0800 (PST) Received: (qmail 19333 invoked from network); 11 Nov 2009 17:11:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lI/zZSdkxOs+/XEv6Eg2UrEeguWPPRuGT0aO3IuajspOsQ8VvvMSLF/fPLUbI0IwsgABr/xp23cDfZlfczpdzWwJPGB/pTxkZC4P1VK0notpoo6NsBChF9Qk96OLCel6mUBMsJdYUyfgTDkI/yVmD2d5UH6pRETfTqZ385xZdMA= ; Received: from adsl-68-124-184-158.dsl.pltn13.pacbell.net (rob.glidden@68.124.184.158 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 11 Nov 2009 09:11:04 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: Rnwgdr8VM1nxt_DlqFW8Uxw0zY0lP3mSPSu5GfvP80iDK1Fp2_N0gR1aiaz8UUvgH6yPMJ.Vy0AL7wPDSoZpi3yhPE5l3Znl0UVQ66bmbxRzjMkRNjRNOHQGruzTQJCj71NoFTKS.QbQXwlx_eXNk.To.NWm8qaEjLQ7qyNuPNbMab6fa3wyMlirhRQPHOWH1QWxn2HByVYnJN1L9mnTrPie7Gw5iRBzBBEeMH8.VVMGNeRIc7jRYUTPAG0XiJLg0SSgsvdwo4aA3TXZR4QEs7Ddjw3.wl3J_0zyT7jAgHTug8rxPZpY.AYFZDmCUMCu_11oqY4D0To5Q95mHpJ2OSYqDm9RKuFswwuvgk1BrG8qYmAXLNZDplbI.uZfV4mxbhFv.fBMPh_Iy1YrEQWC_csk5Jp01pDB_g49rKTKlSsTXZxvv_Zw_5YwHvOv8y6uD4mJMuHvycRH_UvBDd2Kbiid3PGHzt.AX06lDp.jm3avQOKktu3atzNzfhHGzI.vdSTfyOvzzEnueEIR7Qq7U8IjugCtDNkVJ3NvzwS3Q2rT9EjPgsf795Am2m_gxOjsg.ylMPnWE2nMNDapGI.DkaqvF9jgLORcmEHNCQV.mQb576MEXiet1TPxEYbUPBCjZwsr_hb861f.TLQmSa.srxKianZoR00gNJql7.FBT0T4u909_soFy.yQs0DynWopM6_6VrKrCG3LmmNucwrBCpfB5GTolYe1djILddvG.2k4YKuE6aRUcAu1o1TUzd7IIJn3bIchZ00cn8rKsq_bzytmKiK7AFNwkznkyPymiyEDqu_oVlZ.chhFBoXhhir6qBxiCPp_M2cxDiX3.FQPNvLCehBH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFAF020.1030207@sbcglobal.net> Date: Wed, 11 Nov 2009 09:10:56 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Burger References: <7E5EF65E-0760-4D43-9F8F-72B874468300@standardstrack.com> In-Reply-To: <7E5EF65E-0760-4D43-9F8F-72B874468300@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 17:10:48 -0000 No argument on the recipe -- build a royalty free house on a royalty free foundation with royalty free bricks and royalty free inspection, etc. But it wasn't the brick house that saved the three little pigs in the end. It is about going the distance in the face of the inevitable shilling, calls to drive into a ditch, meeting-stacking et al. And it is not about convincing the convinced -- it about proving marketplace confidence. It is done all the time, codecs aren't the unique special case some need them to be. Of course vet contributions for blocking patents and other loopholes. Some noteworthy stuff below. Rob 2001 http://www.itscj.ipsj.or.jp/sc29/29w12911jvt.pdf N4400, December 2001 Terms of Reference for a Joint Project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 for the Development of new Video Coding Recommendation and International Standard ... "10.0 Patent and Copyright Issues The project and joint group will progress the project work in compliance with the Intellectual Property Rights (“IPR”) policies and IPR reporting requirements and procedures of both organisations (http://www.itu.int/ITU-Databases/TSBPatent/ and http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm). * JVT will define a “baseline” profile. That profile should be royalty-free for all implementations.* The performance of this profile will particularly be the subject of performance verification tests. JVT’s rules for the implementation of the IPR policy are contained in Annex 3." 2002 http://lists.mpegif.org/pipermail/discuss/2002-May/000347.html [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG-4 Licensing ... Fernando Pereira fp lx.it.pt Mon May 13 18:40:38 EDT 2002 * Previous message: [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG-4 Licensing ... * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 Licensing ... * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi ! Yuval Fisher wrote: > > > As for me, I'm looking at MPEG-4 Part 10 and hoping that it is > > patent-free ;-) > > I wouldn't hold your breath. Many companies are nervous about submarine > patents. There's a strong anti-free-license movement in MPEG. Let me disagree with this statement ! As the current chairman of MPEG Requirements, I would claim that MPEG is doing everything to support the royalty free approach for the baseline profile of MPEG-4 part 10 (AVC) ... and there is a very large support within MPEG members. Of course there is also people with a (legitimate) different opinion but I would personally claim this is a minority. Let me also explain that the approach is not simply everything royalty free but a combination of a royalty free baseline profile with other more complex profiles not necessarily royalty free (but RAND). This combination may provide a good compromise between the two possible extreme alternatives. Finally let me inform that 2 profiles were defined for AVC/H.264 last week in Fairfax: BASELINE (to be royalty free) and MAIN (not necessarily royalty free). Regards Fernando Pereira -- Fernando Manuel Bernardo Pereira, Ph.D., Professor Instituto Superior Técnico - Instituto de Telecomunicações Av. Rovisco Pais, 1049-001 Lisboa, PORTUGAL Phone: + 351 21 8418460 Fax: + 351 21 8418472 E-mail: Fernando.Pereira lx.it.pt WWW: http://www.img.lx.it.pt/~fp/ [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 Licensing ... Rob Koenen rkoenen intertrust.com Fri May 3 20:59:52 EDT 2002 * Previous message: [M4IF Discuss] To those concerned about MPEG-4 Licensing ... * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 Licensing ... * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > As for me, I'm looking at MPEG-4 Part 10 and hoping > that it is > > patent-free ;-) > > > I wouldn't hold your breath. Many companies are nervous about > submarine > patents. There's a strong anti-free-license movement in MPEG. Sweeping statements like these are very unhelpful. It may indeed be unlikley that full JVT codec is going to be RF (Royalty-Free). There is, however, a strong desire among many parties to try and establish a RF baseline. There is an ongoing effort to see how such an RF baseline could be established. It is area in which people like to maneuver carefully, for obvious reasons. Rob 2003 http://lists.mpegif.org/pipermail/discuss/2003-November/000541.html Rob Koenen to Iain Richardson /Thu Nov 20 07:47:47 EST 2003 / (1) Does this mean that the goal of a royalty-free Baseline Profile is not going to happen ? ... I'll answer for what I know and understand today. 1) Via Licensing's website states that their proposed terms cover "use of Baseline, Main, and Extended Profiles". MPEG LA's announcement states "These terms cover the entire AVC Standard regardless of which Profile(s) are used". I think that gives you the answer. 2004 H.264/MPEG-4 Part 10 is also subject to a number of essential. patents. However, in order to make the new standard as accessible as possible, the JVT has attempted to make the Baseline Profile (see Chapter 6) 'royalty free'. During the standardisation process, holders of key patents were encouraged to notify JVT of their patent claims and to state whether they would permit a royalty free license to the patent(s). These patent statements have been taken into account during the development of the Profiles with the aim of keeping the Baseline free of royalty payments. As this process is voluntary and relies on the correct identification of all relevant patents prior to standardisation, it is not yet clear whether the goal of a royalty-free Profile will be realised but initial indications are positive [1]. 1 In March 2003, 31 companies involved in the H.264 development process and/or holding essential patents confirmed their support for a royalty-free Baseline Profile. Iain E.G. Richardson, H.264 and MPEG-4 Video Compression: Video Coding for Next-Generation Multimedia at 274 (John Wiley & Sons, 2004). 2007: (look also at what happened to the attorneys) "Thus, while the language of the JVT IPR policies may not expressly require disclosure by all participants in all circumstances (e.g., if relevant IPR is not disclosed despite the use of best efforts), it at least incorporates a best efforts standard (even apart from the submission of technical proposals). ... In sum, we conclude that Qualcomm, as a participant in the JVT prior to the release of the H.264 standard, did have IPR disclosure obligations, as discussed above, under the written policies of both the JVT and its parent organizations" http://www.cafc.uscourts.gov/opinions/07-1545.pdf Trial court decision: http://www.klgates.com/files/upload/eDAT_Qualcomm_8_6_07_Order_on_Remedy.pdf 2007 SC29 revised patent policy http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm "Although royalty-bearing patented technologies may be included in SC 29 standards, SC 29 suggests to its WGs to promote, whenever possible, the inclusion of technologies that either do not require a patent license, or that only require a RAND license without a royalty or license fee." 2007 ISO/ITU common patent policy 2009: MPEG HVC Eric Burger wrote: > In practical terms, I agree that there will be better and better > codecs in the future. However, I would offer the older codecs are good > enough for our purposes and will be safe. > > On Nov 11, 2009, at 1:15 PM, Stephan Wenger wrote: > >> The existence of at least a dozend of projects in the speech coding >> field >> today suggests to me that we have not yet reached the point of >> technology >> progress saturation in this field. Other that this minor point, I agree. >> >> Stephan >> >> >> >> On 11/11/09 12:26 PM, "Koen Vos" wrote: >> >>> 1. Technological progress saturates. >>> 2. Patents expire. >>> Therefore, the performance advantage of royalty-bearing standards >>> diminishes with time, and high-quality, royalty-free standards are >>> unavoidable. I'm convinced that today we have reached this point of >>> commoditization for audio and speech coding technology. >>> >>> koen. >>> >>> >>> Quoting Rob Glidden: >>>> Here is my view, perhaps you share it, perhaps you don't. >>>> >>>> What the world needs now is royalty-free, standardized codecs. This >>>> is critical to the future of the Web, and the progress the Internet >>>> has brought to the world, and will bring to the world. >>>> >>>> Video, audio, transport, the whole thing. Evaluated, vetted for >>>> patents. Under an appropriate, responsible and complete royalty free >>>> process. No less. >>>> >>>> IETF, ITU, and ISO/MPEG should all get going on this important >>>> activity -- after all why shouldn't all of these organizations >>>> include this as core to their mission. >>>> >>>> I have, and no doubt you have too, seen countless explanations why >>>> this should not, could not, will not, rather not, might not, or can >>>> not happen. Some well meaning and sincere, some from vested >>>> interests. There are too many "powerful" interests against it. >>>> "Important" commercial interests are ambivalent. It is too hard >>>> "legally" or "politically" or "technically". It is just too >>>> confusing to think through. There is no longer a critical mass that >>>> cares enough about keeping the future of the Open Internet open and >>>> royalty free. The well meaning are ignorant, or naive. Etc. >>>> >>>> Don't settle. Take the issue of royalty free, standardized codecs >>>> all the way to the top of these organizations. Do what it takes. If >>>> it requires new organizations, start them. It it requires revised >>>> processes, revise them. This is the spirit that built the Web and >>>> the Internet, this is the spirit that is its lifeblood, and this is >>>> the spirit that needs to be at the heart of its future. >>>> >>>> Don't settle. Don't let those who have tried hard already, or have >>>> only half-heartedly tried, justify the status quo or their >>>> half-heartedness. Encourage them to focus on how to take the next >>>> steps. Don't let convenient "interpretations" of standards >>>> processes be an excuse for never starting, never finishing, or never >>>> setting up processes that will work. Need more legal background? >>>> Find it. More technical information? Get it. >>>> >>>> Don't settle. The world has plenty of patent-encumbered media >>>> standards, plenty of proprietary solutions, and plenty of standards >>>> in other domains that have figured out how to deliver royalty free. >>>> But the world does not have enough royalty-free codec standards, so >>>> this is the task that needs to be addressed. >>>> >>>> Rob >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 xiphmont@gmail.com Wed Nov 11 09:58: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 A7F873A6B1F for ; Wed, 11 Nov 2009 09:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRccnaYP8t4A for ; Wed, 11 Nov 2009 09:58:49 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9E6003A6917 for ; Wed, 11 Nov 2009 09:58:49 -0800 (PST) Received: by bwz23 with SMTP id 23so1302093bwz.29 for ; Wed, 11 Nov 2009 09:59:14 -0800 (PST) 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=AbcHXQ3LVASARp7fBvvMEKyHt8LlvUbrnb6O5GI/gms=; b=aH54onXOr3xjdGDYS5dWKPFmqc2qXxHyvn4OllDW5lQ6ZQacBHjK1IrG9MusEW2xsl UqRqHl9QHAbSKz9Nka98bTJYP2F/mk26hBxX47gg67c6+gDcANLcgwJzRqY/AcTvMqWl cZJq6KyX1tkIIwPwJsKmL8DRfGCwte1iJZpK0= 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=a9NvoAz7EplXMDL5W+p9V6VdR3BgFahhrPHTw74kadvFB2sy16A2FCSR684w2K6tAk zdipGXSlXqI4WL5UMeup4j6DvOnuQ/uEiJOQK1jRbnVcvP1/B0rlOZK56VSm8nWvlAa/ B+XHKpVQ8kisnGPTQ6tIIklZqj4O554VLPY1Q= MIME-Version: 1.0 Received: by 10.204.152.27 with SMTP id e27mr1806946bkw.192.1257962353786; Wed, 11 Nov 2009 09:59:13 -0800 (PST) In-Reply-To: <4AFAE69E.500@fas.harvard.edu> References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> <4AFAE69E.500@fas.harvard.edu> Date: Wed, 11 Nov 2009 12:59:13 -0500 Message-ID: <806dafc20911110959m9ea5a30i829bb3339b9f2d28@mail.gmail.com> From: Monty Montgomery To: bens@alum.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Cc: codec@ietf.org Subject: Re: [codec] G.719 royalty-free 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: Wed, 11 Nov 2009 17:58:50 -0000 Nonetheless excellent news that brings us another solid step forward in untangling the IP web around internet codecs. I'm glad to see it! Monty From stephen.botzko@gmail.com Wed Nov 11 10:00: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 07ACD3A6AB9 for ; Wed, 11 Nov 2009 10:00:07 -0800 (PST) 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 1eZ4R630mV2f for ; Wed, 11 Nov 2009 10:00:06 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id B73323A6B18 for ; Wed, 11 Nov 2009 10:00:05 -0800 (PST) Received: by fxm7 with SMTP id 7so1302174fxm.29 for ; Wed, 11 Nov 2009 10:00:30 -0800 (PST) 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=+5WEhNY/DTyEQVk7+Y2ezpgK5tFPYZvouOcov7gx+s8=; b=sEn632I+r0EIlCtjxp6VPwfiDYLlOKASEmPF2wO0JiQC5zLh+Ia4e8fdOcipOU5xL1 0QToc44rfkXKkPMY9sBMgPNSa+XNN7SWD9IGqGTOvfAGfvl77l+L/jE5k1xhHYE4FGfR YdN83rhH0LUyUBS18rd+mbwqz2rHkCCAcahMU= 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=rgkFU5VTgMe5MCcEmvqrOlT34J0R8nGWL2FofWN9zBD+UiyfnBmLqOEurR+BjzaxV4 +ekDF60WyLVmu1G/6ErI7teqNoZMoyTqLKKgbMmxr29lvmeL24LVs8FSJdXlEX1zusjr 3TW3knDi42F+o2AjKQIBUIJSFmnnGQ7SWC9oI= MIME-Version: 1.0 Received: by 10.102.165.11 with SMTP id n11mr763944mue.5.1257962430641; Wed, 11 Nov 2009 10:00:30 -0800 (PST) In-Reply-To: <6e9223710911110952k4b389ac3j69a4c5e9c369c33c@mail.gmail.com> References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> <4AFAE69E.500@fas.harvard.edu> <6e9223710911110952k4b389ac3j69a4c5e9c369c33c@mail.gmail.com> Date: Wed, 11 Nov 2009 13:00:30 -0500 Message-ID: <6e9223710911111000x416c7bb7k6fa8d8b36aeb99e0@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016364c778fd1b50704781c3388 Subject: [codec] Fwd: G.719 royalty-free 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: Wed, 11 Nov 2009 18:00:07 -0000 --0016364c778fd1b50704781c3388 Content-Type: text/plain; charset=ISO-8859-1 The license agreement from Polycom can be found here: http://www.polycom.com/company/about_us/technology/siren_g7221/license_schedule.html with a faq sheet here: http://www.polycom.com/company/about_us/technology/siren_g7221/faq.html Note that Polycom licenses G.722.1 and G.719 with the same agreement. Stephen Botzko Polycom. On Wed, Nov 11, 2009 at 11:30 AM, Benjamin M. Schwartz < bmschwar@fas.harvard.edu> wrote: > Anisse Taleb wrote: > > I assume this means that the codec is entirely royalty free since Polycom > > offers also a royalty free license? Any comments on this? > > Polycom's license is "royalty free" but contains various use restrictions > and advertising clauses. It is far from "no strings attached". We don't > know what Ericsson's license says, although we now know how to find out > what it is. Even Ericsson's license were a universal binding patent > non-assertion statement, the codec would still not be compatible with > common open-source licenses due to Polycom's patent licensing restrictions. > > --Ben > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0016364c778fd1b50704781c3388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The license agreement from Polycom can be found here:
http://www.polycom.com/com= pany/about_us/technology/siren_g7221/license_schedule.html

with a faq sheet here:
http://www.polycom= .com/company/about_us/technology/siren_g7221/faq.html

Note that = Polycom licenses G.722.1 and G.719 with the same agreement.

Stephen Botzko
Polycom.



On Wed, Nov 11, 2009 at 11:30 AM, Be= njamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:<= br>
=
Anisse Taleb wrote:
> I assume this means that the codec is entirely royalty free since Poly= com
> offers also a royalty free license? Any comments on this?

Polycom's license is "royalty free" but contains variou= s use restrictions
and advertising clauses. =A0It is far from "no strings attached".= =A0We don't
know what Ericsson's license says, although we now know how to find out=
what it is. =A0Even Ericsson's license were a universal binding patent<= br> non-assertion statement, the codec would still not be compatible with
common open-source licenses due to Polycom's patent licensing restricti= ons.

--Ben


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



--0016364c778fd1b50704781c3388-- From jari.hagqvist@nokia.com Wed Nov 11 10:38: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 C60DC28C149 for ; Wed, 11 Nov 2009 10:38:03 -0800 (PST) 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 HhQzsP1-Fkwo for ; Wed, 11 Nov 2009 10:38:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AD2A83A6A94 for ; Wed, 11 Nov 2009 10:38:02 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nABIcL8K030539; Wed, 11 Nov 2009 12:38:29 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 20:38:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 20:38:19 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 11 Nov 2009 19:38:18 +0100 From: To: , Date: Wed, 11 Nov 2009 19:38:17 +0100 Thread-Topic: [codec] Fwd: G.719 royalty-free license Thread-Index: Acpi+OvLG1gppy1RRQW6W4h+hmnfUAAAxqOQ Message-ID: <0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7F@NOK-EUMSG-01.mgdnok.nokia.com> References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> <4AFAE69E.500@fas.harvard.edu> <6e9223710911110952k4b389ac3j69a4c5e9c369c33c@mail.gmail.com> <6e9223710911111000x416c7bb7k6fa8d8b36aeb99e0@mail.gmail.com> In-Reply-To: <6e9223710911111000x416c7bb7k6fa8d8b36aeb99e0@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7FNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2009 18:38:19.0223 (UTC) FILETIME=[239DA670:01CA62FE] X-Nokia-AV: Clean Subject: Re: [codec] Fwd: G.719 royalty-free 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: Wed, 11 Nov 2009 18:38:03 -0000 --_000_0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7FNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The Polycomm license agreement states that "In the event that Licensee make= s a Qualifying Patent Assertion against Polycom or any of its subsidiaries,= Polycom may immediately terminate all patent rights conveyed herein." I'm= not a lawer, but I interprete this such that the Licensee also gives his w= hole patent portfolio royalty-free to Polycomm if he wants to get the Polyc= omm codec royalty-free. Am I right? Best regards, Jari Hagqvist ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of e= xt stephen botzko Sent: 11. marraskuuta 2009 20:01 To: codec@ietf.org Subject: [codec] Fwd: G.719 royalty-free license The license agreement from Polycom can be found here: http://www.polycom.com/company/about_us/technology/siren_g7221/license_sche= dule.html with a faq sheet here: http://www.polycom.com/company/about_us/technology/siren_g7221/faq.html Note that Polycom licenses G.722.1 and G.719 with the same agreement. Stephen Botzko Polycom. On Wed, Nov 11, 2009 at 11:30 AM, Benjamin M. Schwartz > wrote: Anisse Taleb wrote: > I assume this means that the codec is entirely royalty free since Polycom > offers also a royalty free license? Any comments on this? Polycom's license is "royalty free" but contains various use restrictions and advertising clauses. It is far from "no strings attached". We don't know what Ericsson's license says, although we now know how to find out what it is. Even Ericsson's license were a universal binding patent non-assertion statement, the codec would still not be compatible with common open-source licenses due to Polycom's patent licensing restrictions. --Ben _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7FNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
The = Polycomm=20 license agreement states that "In the event that Licensee makes a Quali= fying=20 Patent Assertion against Polycom or any of its subsidiaries, Polycom may=20 immediately terminate all patent rights conveyed herein."  I'm not a=20 lawer, but I interprete this such that the Licensee als= o=20 gives his whole patent portfolio royalty-free to Polycomm = if he=20 wants to get the Polycomm codec royalty-free. Am I=20 right?
 
Best= =20 regards,
Jari= =20 Hagqvist
 
From:=20 codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = ext=20 stephen botzko
Sent: 11. marraskuuta 2009 20:01
To:=20 codec@ietf.org
Subject: [codec] Fwd: G.719 royalty-free=20 license

The license agreement from Polycom can be found here:
http://www.polycom.com/company/about_us/technology/siren_g7= 221/license_schedule.html

with=20 a faq sheet here:
http://www.polycom.com/company/about_us/technology/siren_g7= 221/faq.html

Note=20 that Polycom licenses G.722.1 and G.719 with the same agreement.

Stephen Botzko
Polycom.



On Wed, Nov 11, 2009 at 11:30 AM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:
Anisse Taleb wrote:
> I assume this means that the codec is=20 entirely royalty free since Polycom
> offers also a royalty free=20 license? Any comments on this?

Polycom's license is "royalty= =20 free" but contains various use restrictions
and advertising clauses.=20  It is far from "no strings attached".  We don't
know what=20 Ericsson's license says, although we now know how to find out
what it = is.=20  Even Ericsson's license were a universal binding patent
non-asse= rtion=20 statement, the codec would still not be compatible with
common open-so= urce=20 licenses due to Polycom's patent licensing=20 restrictions.

--Ben


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



--_000_0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7FNOKEUMSG01mgd_-- From eburger@standardstrack.com Wed Nov 11 12:43: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 BAC663A67A8 for ; Wed, 11 Nov 2009 12:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 6nj54GP1suE6 for ; Wed, 11 Nov 2009 12:43:40 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 0E7823A69A2 for ; Wed, 11 Nov 2009 12:43:40 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8K2s-0004Sg-MX; Wed, 11 Nov 2009 12:44:03 -0800 Message-Id: <261D7F95-BB66-459B-B1BB-D1C511FB300D@standardstrack.com> From: Eric Burger To: Rob Glidden In-Reply-To: <4AFAF020.1030207@sbcglobal.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 05:44:03 +0900 References: <7E5EF65E-0760-4D43-9F8F-72B874468300@standardstrack.com> <4AFAF020.1030207@sbcglobal.net> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 20:43:41 -0000 Am I missing something here? I cannot tell if what you are saying is =20= the JVC EG was able to produce a RF baseline (the last paragraph) or =20 they were not able to produce a RF baseline (the second to last =20 paragraph)? One thing that is clearly different is IPR declaration in the IETF is =20= not optional: it is mandatory and the policy is clear. Moreover, =20 there is established case law that if a participant neglects to =20 declare their IPR, and the IPR gets incorporated into a standard, the =20= participant loses their IP rights. On Nov 12, 2009, at 2:10 AM, Rob Glidden wrote: > No argument on the recipe -- build a royalty free house on a royalty =20= > free foundation with royalty free bricks and royalty free =20 > inspection, etc. > > But it wasn't the brick house that saved the three little pigs in =20 > the end. > > It is about going the distance in the face of the inevitable =20 > shilling, calls to drive into a ditch, meeting-stacking et al. > > And it is not about convincing the convinced -- it about proving =20 > marketplace confidence. It is done all the time, codecs aren't the =20 > unique special case some need them to be. > > Of course vet contributions for blocking patents and other loopholes. > > Some noteworthy stuff below. > > Rob > > > 2001 > > http://www.itscj.ipsj.or.jp/sc29/29w12911jvt.pdf > N4400, December 2001 > > Terms of Reference for a Joint Project between ITU-T Q.6/SG16 and =20 > ISO/IEC JTC 1/SC 29/WG11 > for the Development of new Video Coding Recommendation and =20 > International Standard > ... > "10.0 Patent and Copyright Issues > The project and joint group will progress the project work in =20 > compliance with the Intellectual Property > Rights (=93IPR=94) policies and IPR reporting requirements and =20 > procedures of both organisations > (http://www.itu.int/ITU-Databases/TSBPatent/ and = http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm)=20 > . > * > JVT will define a =93baseline=94 profile. That profile should be = royalty-=20 > free for all implementations.* The > performance of this profile will particularly be the subject of =20 > performance verification tests. > JVT=92s rules for the implementation of the IPR policy are contained =20= > in Annex 3." > > > 2002 > > http://lists.mpegif.org/pipermail/discuss/2002-May/000347.html > > [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG-4 =20 > Licensing ... > Fernando Pereira fp lx.it.pt > Mon May 13 18:40:38 EDT 2002 > > * Previous message: [M4IF Discuss] RE: [M4IF News] To those =20 > concerned about MPEG-4 Licensing ... > * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned =20 > about MPEG- 4 Licensing ... > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > Hi ! Yuval Fisher wrote: > > > > > As for me, I'm looking at MPEG-4 Part 10 and hoping that it is > > > patent-free ;-) > > > I wouldn't hold your breath. Many companies are nervous about =20 > submarine > > patents. There's a strong anti-free-license movement in MPEG. > > Let me disagree with this statement ! As the current chairman of =20 > MPEG Requirements, I would claim that MPEG is doing everything to =20 > support the royalty free approach for the baseline profile of MPEG-4 =20= > part 10 (AVC) ... and there is a very large support within MPEG =20 > members. Of course there is also people with a (legitimate) =20 > different opinion but I would personally claim this is a minority. > > Let me also explain that the approach is not simply everything =20 > royalty free but a combination of a royalty free baseline profile =20 > with other more complex profiles not necessarily royalty free (but =20 > RAND). This combination may provide a good compromise between the =20 > two possible extreme alternatives. Finally let me inform that 2 =20 > profiles were defined for AVC/H.264 last week in Fairfax: BASELINE =20 > (to be royalty free) and MAIN (not necessarily royalty free). > > Regards Fernando Pereira -- Fernando Manuel Bernardo Pereira, Ph.D., =20= > Professor > Instituto Superior T=E9cnico - Instituto de Telecomunica=E7=F5es > Av. Rovisco Pais, 1049-001 Lisboa, PORTUGAL > Phone: + 351 21 8418460 Fax: + 351 21 8418472 > E-mail: Fernando.Pereira lx.it.pt WWW: http://www.img.lx.it.pt/~fp/ > > > > [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 =20 > Licensing ... > Rob Koenen rkoenen intertrust.com > Fri May 3 20:59:52 EDT 2002 > > * Previous message: [M4IF Discuss] To those concerned about MPEG-4 =20 > Licensing ... > * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned =20 > about MPEG- 4 Licensing ... > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > > As for me, I'm looking at MPEG-4 Part 10 and hoping > > that it is > > > patent-free ;-) > > > > > > I wouldn't hold your breath. Many companies are nervous about > > submarine > > patents. There's a strong anti-free-license movement in MPEG. > > Sweeping statements like these are very unhelpful. > > It may indeed be unlikley that full JVT codec is going to be RF > (Royalty-Free). > There is, however, a strong desire among many parties to try and > establish a RF baseline. There is an ongoing effort to see how such > an RF baseline could be established. It is area in which people like > to maneuver carefully, for obvious reasons. > > Rob > > > > 2003 > > http://lists.mpegif.org/pipermail/discuss/2003-November/000541.html > Rob Koenen to Iain Richardson > /Thu Nov 20 07:47:47 EST 2003 > / > > (1) Does this mean that the goal of a royalty-free Baseline Profile =20= > is not > going to happen ? > > ... > > I'll answer for what I know and understand today. > 1) Via Licensing's website states that their proposed terms cover =20 > "use of > Baseline, Main, and Extended Profiles". MPEG LA's announcement =20 > states "These > terms cover the entire AVC Standard regardless of which Profile(s) are > used". I think that gives you the answer. > > > > > 2004 > > H.264/MPEG-4 Part 10 is also subject to a number of essential. =20 > patents. > However, in order to make the new standard as accessible as possible, > the JVT has attempted to make the Baseline Profile (see Chapter 6) > 'royalty free'. During the standardisation process, holders of key > patents were encouraged to notify JVT of their patent claims and to > state whether they would permit a royalty free license to the > patent(s). These patent statements have been taken into account during > the development of the Profiles with the aim of keeping the Baseline > free of royalty payments. As this process is voluntary and relies on =20= > the > correct identification of all relevant patents prior to =20 > standardisation, > it is not yet clear whether the goal of a royalty-free Profile will be > realised but initial indications are positive [1]. > > 1 In March 2003, 31 companies involved in the H.264 development =20 > process > and/or holding essential patents confirmed their support for a > royalty-free Baseline Profile. > > Iain E.G. Richardson, H.264 and MPEG-4 Video Compression: Video Coding > for Next-Generation Multimedia at 274 (John Wiley & Sons, 2004). > > 2007: > > (look also at what happened to the attorneys) > > "Thus, while the language of the JVT IPR policies may not expressly =20= > require disclosure by all participants in all circumstances (e.g., =20 > if relevant IPR is not disclosed despite the use of best efforts), =20 > it at least incorporates a best efforts standard (even apart from =20 > the submission of technical proposals). > ... > In sum, we conclude that Qualcomm, as a participant in the JVT prior =20= > to the release of the H.264 standard, did have IPR disclosure =20 > obligations, as discussed above, under the written policies of both =20= > the JVT and its parent organizations" > > http://www.cafc.uscourts.gov/opinions/07-1545.pdf > > Trial court decision: > > = http://www.klgates.com/files/upload/eDAT_Qualcomm_8_6_07_Order_on_Remedy.p= df > > > 2007 SC29 revised patent policy > > http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm > > "Although royalty-bearing patented technologies may be included in =20 > SC 29 standards, SC 29 suggests to its WGs to promote, whenever =20 > possible, the inclusion of technologies that either do not require a =20= > patent license, or that only require a RAND license without a =20 > royalty or license fee." > > 2007 ISO/ITU common patent policy > > 2009: > > MPEG HVC > > > > > > Eric Burger wrote: >> In practical terms, I agree that there will be better and better =20 >> codecs in the future. However, I would offer the older codecs are =20 >> good enough for our purposes and will be safe. >> >> On Nov 11, 2009, at 1:15 PM, Stephan Wenger wrote: >> >>> The existence of at least a dozend of projects in the speech =20 >>> coding field >>> today suggests to me that we have not yet reached the point of =20 >>> technology >>> progress saturation in this field. Other that this minor point, I =20= >>> agree. >>> >>> Stephan >>> >>> >>> >>> On 11/11/09 12:26 PM, "Koen Vos" wrote: >>> >>>> 1. Technological progress saturates. >>>> 2. Patents expire. >>>> Therefore, the performance advantage of royalty-bearing standards >>>> diminishes with time, and high-quality, royalty-free standards are >>>> unavoidable. I'm convinced that today we have reached this point of >>>> commoditization for audio and speech coding technology. >>>> >>>> koen. >>>> >>>> >>>> Quoting Rob Glidden: >>>>> Here is my view, perhaps you share it, perhaps you don't. >>>>> >>>>> What the world needs now is royalty-free, standardized codecs. =20 >>>>> This >>>>> is critical to the future of the Web, and the progress the =20 >>>>> Internet >>>>> has brought to the world, and will bring to the world. >>>>> >>>>> Video, audio, transport, the whole thing. Evaluated, vetted for >>>>> patents. Under an appropriate, responsible and complete royalty =20= >>>>> free >>>>> process. No less. >>>>> >>>>> IETF, ITU, and ISO/MPEG should all get going on this important >>>>> activity -- after all why shouldn't all of these organizations >>>>> include this as core to their mission. >>>>> >>>>> I have, and no doubt you have too, seen countless explanations why >>>>> this should not, could not, will not, rather not, might not, or =20= >>>>> can >>>>> not happen. Some well meaning and sincere, some from vested >>>>> interests. There are too many "powerful" interests against it. >>>>> "Important" commercial interests are ambivalent. It is too hard >>>>> "legally" or "politically" or "technically". It is just too >>>>> confusing to think through. There is no longer a critical mass =20 >>>>> that >>>>> cares enough about keeping the future of the Open Internet open =20= >>>>> and >>>>> royalty free. The well meaning are ignorant, or naive. Etc. >>>>> >>>>> Don't settle. Take the issue of royalty free, standardized codecs >>>>> all the way to the top of these organizations. Do what it takes. =20= >>>>> If >>>>> it requires new organizations, start them. It it requires revised >>>>> processes, revise them. This is the spirit that built the Web and >>>>> the Internet, this is the spirit that is its lifeblood, and this =20= >>>>> is >>>>> the spirit that needs to be at the heart of its future. >>>>> >>>>> Don't settle. Don't let those who have tried hard already, or have >>>>> only half-heartedly tried, justify the status quo or their >>>>> half-heartedness. Encourage them to focus on how to take the next >>>>> steps. Don't let convenient "interpretations" of standards >>>>> processes be an excuse for never starting, never finishing, or =20 >>>>> never >>>>> setting up processes that will work. Need more legal background? >>>>> Find it. More technical information? Get it. >>>>> >>>>> Don't settle. The world has plenty of patent-encumbered media >>>>> standards, plenty of proprietary solutions, and plenty of =20 >>>>> standards >>>>> in other domains that have figured out how to deliver royalty =20 >>>>> free. >>>>> But the world does not have enough royalty-free codec standards, =20= >>>>> so >>>>> this is the task that needs to be addressed. >>>>> >>>>> Rob >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 eburger@standardstrack.com Wed Nov 11 13:04: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 253033A68EE for ; Wed, 11 Nov 2009 13:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 DwOLSRTCuWRZ for ; Wed, 11 Nov 2009 13:04:35 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 0C7013A68A5 for ; Wed, 11 Nov 2009 13:04:35 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8KN4-0000M3-5r; Wed, 11 Nov 2009 13:04:54 -0800 Message-Id: <43D841DF-5ED1-4383-9EEF-816F64BA5D04@standardstrack.com> From: Eric Burger To: In-Reply-To: <0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7F@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 06:04:55 +0900 References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> <4AFAE69E.500@fas.harvard.edu> <6e9223710911110952k4b389ac3j69a4c5e9c369c33c@mail.gmail.com> <6e9223710911111000x416c7bb7k6fa8d8b36aeb99e0@mail.gmail.com> <0E94BEEABCAE4C4EAC18B13A7A5C24564F430FFF7F@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] Fwd: G.719 royalty-free 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: Wed, 11 Nov 2009 21:04:36 -0000 That is correct. There is another issue, which is inventors do not necessarily need to give up their entire rights in a technology in order to create a royalty free standard. No large portfolio company will agree to "my one patent in a corner of a standard equals your portfolio of 55,000 patents." Assertions like this are a sure way to keep large technology firms from participating (unless that is your goal). Reasonable royalty free agreements have the following points; o Royalty Free FOR USE TO IMPLEMENT AND MARKET ARTIFACTS THAT IMPLEMENT THE PUBLISHED STANDARD - This just states the IPR comes with no strings attached for the purposes of using the RFC, when published - This also allows the inventor to keep their rights for other purposes. This is an incentive for people to release their IPR without writing a blank check. This disproportionally protects small inventors, by the way. o License revoked if you assert IPR against me because of my IMPLEMENTATION OF THE PUBLISHED STANDARD - This provides incentives to prevent a party that did not participate in the standards process from asserting their IPR against the standard - This is acceptable to large companies, as they do NOT hand over their entire portfolio just because they participated in a small CODEC work group If you want to go further, you can do the industry as a whole a favor and extend the IPR regime to protect third-parties: o License revoked if you assert IPR against ANYONE because of THEIR implementation of the published standard - This gives people a reason to prosecute IPR in something they hope to be royalty free. - It provides a layer of protection to the industry by dissuading non-participants from asserting their (unknown to the work group) IPR against the ultimate standard. For an example of such a declaration, see: https://datatracker.ietf.org/ipr/580/ On Nov 12, 2009, at 3:38 AM, wrote: > Hi, > The Polycomm license agreement states that "In the event that > Licensee makes a Qualifying Patent Assertion against Polycom or any > of its subsidiaries, Polycom may immediately terminate all patent > rights conveyed herein." I'm not a lawer, but I interprete this > such that the Licensee also gives his whole patent portfolio royalty- > free to Polycomm if he wants to get the Polycomm codec royalty-free. > Am I right? > > Best regards, > Jari Hagqvist > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf Of ext stephen botzko > Sent: 11. marraskuuta 2009 20:01 > To: codec@ietf.org > Subject: [codec] Fwd: G.719 royalty-free license > > The license agreement from Polycom can be found here: > http://www.polycom.com/company/about_us/technology/siren_g7221/license_schedule.html > > with a faq sheet here: > http://www.polycom.com/company/about_us/technology/siren_g7221/ > faq.html > > Note that Polycom licenses G.722.1 and G.719 with the same agreement. > > Stephen Botzko > Polycom. > > > > On Wed, Nov 11, 2009 at 11:30 AM, Benjamin M. Schwartz > wrote: > Anisse Taleb wrote: > > I assume this means that the codec is entirely royalty free since > Polycom > > offers also a royalty free license? Any comments on this? > > Polycom's license is "royalty free" but contains various use > restrictions > and advertising clauses. It is far from "no strings attached". We > don't > know what Ericsson's license says, although we now know how to find > out > what it is. Even Ericsson's license were a universal binding patent > non-assertion statement, the codec would still not be compatible with > common open-source licenses due to Polycom's patent licensing > restrictions. > > --Ben > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Wed Nov 11 14:40: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 3E0D03A6946 for ; Wed, 11 Nov 2009 14:40:03 -0800 (PST) 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.050, 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 nBIOFlrTkgHs for ; Wed, 11 Nov 2009 14:40:01 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 7C1DC3A693B for ; Wed, 11 Nov 2009 14:40:00 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 486058-1743317 for multiple; Wed, 11 Nov 2009 23:40:28 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 12 Nov 2009 07:40:18 +0900 From: Stephan Wenger To: Eric Burger , Rob Glidden Message-ID: Thread-Topic: [codec] Royalty Free codec standards -- don't settle for less Thread-Index: AcpjH/F7exIftJGq6ESgr7xtHqdaPw== In-Reply-To: <261D7F95-BB66-459B-B1BB-D1C511FB300D@standardstrack.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Nov 2009 22:40:03 -0000 Hi Eric, On 11/12/09 5:44 AM, "Eric Burger" wrote: > Am I missing something here? I cannot tell if what you are saying is > the JVC EG was able to produce a RF baseline (the last paragraph) or > they were not able to produce a RF baseline (the second to last > paragraph)? FWIW, I was one of the "architects" of JVT's royalty-free baseline approach= , and I believe I have some limited insight in the realities today. My position in our discussion is in part a reaction to these realities. The short answer to this question is (as usual): it depends whom you ask. However, clearly, most lawyers would probably advise a business to practice H.264 baseline only after having obtained a license from the pool and possibly other known rightholders. At present, one can pick a (royalty-bearing, though cheap, comparatively speaking) license from the MPEG-LA patent pool which contains patent claims allegedly relevant to practice baseline and/or many other profiles. MPEG-L= A does not distinguish between profiles on the out-licensing side; which is a wise business decision on their side, I believe. Further, there are rightholders outside the pool (according to ITU/ISO/IEC declarations on fil= e in the respective organizations), who may or may not charge for a license o= f their patents related to baseline (or other profiles). No one really knows for sure. =20 OTOH, some say that the assurances every contribution had to be accompanied with (RF licensing in case the contribution were accepted, under a reciprocity condition) continues to provide an essentially RF licensing environment for baseline. Note that the requirement for these assurances were implemented in JVT only; they are not a rack ITU or ISO/IEC policy. I'm personally aware of only a single ruling related to alleged infringemen= t of H.264 baseline (although H.264 patents have been litigated more than once), and this ruling was quite positive for the alleged infringer; however, the legal grounds for the ruling had AFAIK little or nothing to do with the assurances mentioned above, but only with other process violations and (more importantly) legal grounds to subtle to discuss here. It should further be noticed, that many folks in the community consider the ruling "bad law". Finally, the JVT Royalty-free baseline project did explicitly NOT target anything but royalty-free *licensing*. As it has been pointed out already, by the strictest interpretation of the GPL and other similarly restrictive "free" or open source licenses, the mere fact that one has to obtain a license already renders a technology "incompatible" with the license. That's why I have pointed out time and time again that you guys need to shoot for non-assert covenants from known rightholders rather than RF licensing provisions. That said, there are tons of open source projects (under GPL and other licenses) that implement H.264 and similarly known-as-encumbered standards. > One thing that is clearly different is IPR declaration in the IETF is > not optional: it is mandatory and the policy is clear. In the ITU as well. Arguably: clearer than in the IETF. > Moreover, =20 > there is established case law that if a participant neglects to > declare their IPR, and the IPR gets incorporated into a standard, the > participant loses their IP rights. I would think your statement may be a tad too strong. But I agree, it has been getting more and more difficult to enforce patent rights when clear process violations are shown, independent from the organization involved. One significant aspect of the case mentioned above is that even violations of the common conduct in the committee in question (something I have called "culture" in a previous posts) may endanger the enforceability of patents, even if one cannot, by the strictest interpretation of policy documents, find support of a process violation under the written policy documents. Not simple, this stuff. Stephan > On Nov 12, 2009, at 2:10 AM, Rob Glidden wrote: >=20 >> No argument on the recipe -- build a royalty free house on a royalty >> free foundation with royalty free bricks and royalty free >> inspection, etc. >>=20 >> But it wasn't the brick house that saved the three little pigs in >> the end. >>=20 >> It is about going the distance in the face of the inevitable >> shilling, calls to drive into a ditch, meeting-stacking et al. >>=20 >> And it is not about convincing the convinced -- it about proving >> marketplace confidence. It is done all the time, codecs aren't the >> unique special case some need them to be. >>=20 >> Of course vet contributions for blocking patents and other loopholes. >>=20 >> Some noteworthy stuff below. >>=20 >> Rob >>=20 >>=20 >> 2001 >>=20 >> http://www.itscj.ipsj.or.jp/sc29/29w12911jvt.pdf >> N4400, December 2001 >>=20 >> Terms of Reference for a Joint Project between ITU-T Q.6/SG16 and >> ISO/IEC JTC 1/SC 29/WG11 >> for the Development of new Video Coding Recommendation and >> International Standard >> ... >> "10.0 Patent and Copyright Issues >> The project and joint group will progress the project work in >> compliance with the Intellectual Property >> Rights (=B3IPR=B2) policies and IPR reporting requirements and >> procedures of both organisations >> (http://www.itu.int/ITU-Databases/TSBPatent/ and >> http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm) >> . >> * >> JVT will define a =B3baseline=B2 profile. That profile should be royalty- >> free for all implementations.* The >> performance of this profile will particularly be the subject of >> performance verification tests. >> JVT=B9s rules for the implementation of the IPR policy are contained >> in Annex 3." >>=20 >>=20 >> 2002 >>=20 >> http://lists.mpegif.org/pipermail/discuss/2002-May/000347.html >>=20 >> [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG-4 >> Licensing ... >> Fernando Pereira fp lx.it.pt >> Mon May 13 18:40:38 EDT 2002 >>=20 >> * Previous message: [M4IF Discuss] RE: [M4IF News] To those >> concerned about MPEG-4 Licensing ... >> * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned >> about MPEG- 4 Licensing ... >> * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] >>=20 >> Hi ! Yuval Fisher wrote: >>>=20 >>>> As for me, I'm looking at MPEG-4 Part 10 and hoping that it is >>>> patent-free ;-) >>>> I wouldn't hold your breath. Many companies are nervous about >> submarine >>> patents. There's a strong anti-free-license movement in MPEG. >>=20 >> Let me disagree with this statement ! As the current chairman of >> MPEG Requirements, I would claim that MPEG is doing everything to >> support the royalty free approach for the baseline profile of MPEG-4 >> part 10 (AVC) ... and there is a very large support within MPEG >> members. Of course there is also people with a (legitimate) >> different opinion but I would personally claim this is a minority. >>=20 >> Let me also explain that the approach is not simply everything >> royalty free but a combination of a royalty free baseline profile >> with other more complex profiles not necessarily royalty free (but >> RAND). This combination may provide a good compromise between the >> two possible extreme alternatives. Finally let me inform that 2 >> profiles were defined for AVC/H.264 last week in Fairfax: BASELINE >> (to be royalty free) and MAIN (not necessarily royalty free). >>=20 >> Regards Fernando Pereira -- Fernando Manuel Bernardo Pereira, Ph.D., >> Professor >> Instituto Superior T=E9cnico - Instituto de Telecomunica=E7=F5es >> Av. Rovisco Pais, 1049-001 Lisboa, PORTUGAL >> Phone: + 351 21 8418460 Fax: + 351 21 8418472 >> E-mail: Fernando.Pereira lx.it.pt WWW: http://www.img.lx.it.pt/~fp/ >>=20 >>=20 >>=20 >> [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 >> Licensing ... >> Rob Koenen rkoenen intertrust.com >> Fri May 3 20:59:52 EDT 2002 >>=20 >> * Previous message: [M4IF Discuss] To those concerned about MPEG-4 >> Licensing ... >> * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned >> about MPEG- 4 Licensing ... >> * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] >>=20 >>>> As for me, I'm looking at MPEG-4 Part 10 and hoping >>> that it is >>>> patent-free ;-) >>>=20 >>>=20 >>> I wouldn't hold your breath. Many companies are nervous about >>> submarine >>> patents. There's a strong anti-free-license movement in MPEG. >>=20 >> Sweeping statements like these are very unhelpful. >>=20 >> It may indeed be unlikley that full JVT codec is going to be RF >> (Royalty-Free). >> There is, however, a strong desire among many parties to try and >> establish a RF baseline. There is an ongoing effort to see how such >> an RF baseline could be established. It is area in which people like >> to maneuver carefully, for obvious reasons. >>=20 >> Rob >>=20 >>=20 >>=20 >> 2003 >>=20 >> http://lists.mpegif.org/pipermail/discuss/2003-November/000541.html >> Rob Koenen to Iain Richardson >> /Thu Nov 20 07:47:47 EST 2003 >> / >>=20 >> (1) Does this mean that the goal of a royalty-free Baseline Profile >> is not >> going to happen ? >>=20 >> ... >>=20 >> I'll answer for what I know and understand today. >> 1) Via Licensing's website states that their proposed terms cover >> "use of >> Baseline, Main, and Extended Profiles". MPEG LA's announcement >> states "These >> terms cover the entire AVC Standard regardless of which Profile(s) are >> used". I think that gives you the answer. >>=20 >>=20 >>=20 >>=20 >> 2004 >>=20 >> H.264/MPEG-4 Part 10 is also subject to a number of essential. >> patents. >> However, in order to make the new standard as accessible as possible, >> the JVT has attempted to make the Baseline Profile (see Chapter 6) >> 'royalty free'. During the standardisation process, holders of key >> patents were encouraged to notify JVT of their patent claims and to >> state whether they would permit a royalty free license to the >> patent(s). These patent statements have been taken into account during >> the development of the Profiles with the aim of keeping the Baseline >> free of royalty payments. As this process is voluntary and relies on >> the >> correct identification of all relevant patents prior to >> standardisation, >> it is not yet clear whether the goal of a royalty-free Profile will be >> realised but initial indications are positive [1]. >>=20 >> 1 In March 2003, 31 companies involved in the H.264 development >> process >> and/or holding essential patents confirmed their support for a >> royalty-free Baseline Profile. >>=20 >> Iain E.G. Richardson, H.264 and MPEG-4 Video Compression: Video Coding >> for Next-Generation Multimedia at 274 (John Wiley & Sons, 2004). >>=20 >> 2007: >>=20 >> (look also at what happened to the attorneys) >>=20 >> "Thus, while the language of the JVT IPR policies may not expressly >> require disclosure by all participants in all circumstances (e.g., >> if relevant IPR is not disclosed despite the use of best efforts), >> it at least incorporates a best efforts standard (even apart from >> the submission of technical proposals). >> ... >> In sum, we conclude that Qualcomm, as a participant in the JVT prior >> to the release of the H.264 standard, did have IPR disclosure >> obligations, as discussed above, under the written policies of both >> the JVT and its parent organizations" >>=20 >> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>=20 >> Trial court decision: >>=20 >> http://www.klgates.com/files/upload/eDAT_Qualcomm_8_6_07_Order_on_Remedy= .pdf >>=20 >>=20 >> 2007 SC29 revised patent policy >>=20 >> http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm >>=20 >> "Although royalty-bearing patented technologies may be included in >> SC 29 standards, SC 29 suggests to its WGs to promote, whenever >> possible, the inclusion of technologies that either do not require a >> patent license, or that only require a RAND license without a >> royalty or license fee." >>=20 >> 2007 ISO/ITU common patent policy >>=20 >> 2009: >>=20 >> MPEG HVC >>=20 >>=20 >>=20 >>=20 >>=20 >> Eric Burger wrote: >>> In practical terms, I agree that there will be better and better >>> codecs in the future. However, I would offer the older codecs are >>> good enough for our purposes and will be safe. >>>=20 >>> On Nov 11, 2009, at 1:15 PM, Stephan Wenger wrote: >>>=20 >>>> The existence of at least a dozend of projects in the speech >>>> coding field >>>> today suggests to me that we have not yet reached the point of >>>> technology >>>> progress saturation in this field. Other that this minor point, I >>>> agree. >>>>=20 >>>> Stephan >>>>=20 >>>>=20 >>>>=20 >>>> On 11/11/09 12:26 PM, "Koen Vos" wrote: >>>>=20 >>>>> 1. Technological progress saturates. >>>>> 2. Patents expire. >>>>> Therefore, the performance advantage of royalty-bearing standards >>>>> diminishes with time, and high-quality, royalty-free standards are >>>>> unavoidable. I'm convinced that today we have reached this point of >>>>> commoditization for audio and speech coding technology. >>>>>=20 >>>>> koen. >>>>>=20 >>>>>=20 >>>>> Quoting Rob Glidden: >>>>>> Here is my view, perhaps you share it, perhaps you don't. >>>>>>=20 >>>>>> What the world needs now is royalty-free, standardized codecs. >>>>>> This >>>>>> is critical to the future of the Web, and the progress the >>>>>> Internet >>>>>> has brought to the world, and will bring to the world. >>>>>>=20 >>>>>> Video, audio, transport, the whole thing. Evaluated, vetted for >>>>>> patents. Under an appropriate, responsible and complete royalty >>>>>> free >>>>>> process. No less. >>>>>>=20 >>>>>> IETF, ITU, and ISO/MPEG should all get going on this important >>>>>> activity -- after all why shouldn't all of these organizations >>>>>> include this as core to their mission. >>>>>>=20 >>>>>> I have, and no doubt you have too, seen countless explanations why >>>>>> this should not, could not, will not, rather not, might not, or >>>>>> can >>>>>> not happen. Some well meaning and sincere, some from vested >>>>>> interests. There are too many "powerful" interests against it. >>>>>> "Important" commercial interests are ambivalent. It is too hard >>>>>> "legally" or "politically" or "technically". It is just too >>>>>> confusing to think through. There is no longer a critical mass >>>>>> that >>>>>> cares enough about keeping the future of the Open Internet open >>>>>> and >>>>>> royalty free. The well meaning are ignorant, or naive. Etc. >>>>>>=20 >>>>>> Don't settle. Take the issue of royalty free, standardized codecs >>>>>> all the way to the top of these organizations. Do what it takes. >>>>>> If >>>>>> it requires new organizations, start them. It it requires revised >>>>>> processes, revise them. This is the spirit that built the Web and >>>>>> the Internet, this is the spirit that is its lifeblood, and this >>>>>> is >>>>>> the spirit that needs to be at the heart of its future. >>>>>>=20 >>>>>> Don't settle. Don't let those who have tried hard already, or have >>>>>> only half-heartedly tried, justify the status quo or their >>>>>> half-heartedness. Encourage them to focus on how to take the next >>>>>> steps. Don't let convenient "interpretations" of standards >>>>>> processes be an excuse for never starting, never finishing, or >>>>>> never >>>>>> setting up processes that will work. Need more legal background? >>>>>> Find it. More technical information? Get it. >>>>>>=20 >>>>>> Don't settle. The world has plenty of patent-encumbered media >>>>>> standards, plenty of proprietary solutions, and plenty of >>>>>> standards >>>>>> in other domains that have figured out how to deliver royalty >>>>>> free. >>>>>> But the world does not have enough royalty-free codec standards, >>>>>> so >>>>>> this is the task that needs to be addressed. >>>>>>=20 >>>>>> Rob >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 >>=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Wed Nov 11 14:58: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 DF35D3A68AE for ; Wed, 11 Nov 2009 14:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 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 eHbuLOOBjT5B for ; Wed, 11 Nov 2009 14:58:55 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id B416A3A68A4 for ; Wed, 11 Nov 2009 14:58:36 -0800 (PST) Received: from [133.93.114.74] (unverified [133.93.114.74]) by stewe.org (SurgeMail 3.9e) with ESMTP id 486077-1743317 for multiple; Wed, 11 Nov 2009 23:59:04 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 12 Nov 2009 07:58:52 +0900 From: Stephan Wenger To: Eric Burger , <"jari.hagqvist@nokia.comjari.hagqvist"@nokia.com> Message-ID: Thread-Topic: [codec] Fwd: G.719 royalty-free license Thread-Index: AcpjIol6UE+FvrmMXU2ZiWWjig/ajg== In-Reply-To: <43D841DF-5ED1-4383-9EEF-816F64BA5D04@standardstrack.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 133.93.114.74 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Fwd: G.719 royalty-free 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: Wed, 11 Nov 2009 22:58:57 -0000 Hi Eric, I wholeheartedly agree with your email below, but also note that very few rightholder companies in the IETF follow your approach. Overly broad reciprocity conditions are the norm for declarations offering no royalties, and not an exception. Just look at (most of) the recent Cisco-style disclosures. There are established areas of technologies in the IETF where an unspoken consensus seems to prevail to keep the environment free of the licensing game. For those areas, the Cisco-style reciprocity conditions are IMHO just fine. Stephan On 11/12/09 6:04 AM, "Eric Burger" wrote: > That is correct. There is another issue, which is inventors do not > necessarily need to give up their entire rights in a technology in > order to create a royalty free standard. > > No large portfolio company will agree to "my one patent in a corner of > a standard equals your portfolio of 55,000 patents." Assertions like > this are a sure way to keep large technology firms from participating > (unless that is your goal). > > > Reasonable royalty free agreements have the following points; > > o Royalty Free FOR USE TO IMPLEMENT AND MARKET ARTIFACTS THAT > IMPLEMENT THE PUBLISHED STANDARD > > - This just states the IPR comes with no strings attached for the > purposes of using the RFC, when published > > - This also allows the inventor to keep their rights for other > purposes. This is an incentive for people to release their IPR without > writing a blank check. This disproportionally protects small > inventors, by the way. > > > o License revoked if you assert IPR against me because of my > IMPLEMENTATION OF THE PUBLISHED STANDARD > > - This provides incentives to prevent a party that did not > participate in the standards process from asserting their IPR against > the standard > > - This is acceptable to large companies, as they do NOT hand over > their entire portfolio just because they participated in a small CODEC > work group > > > If you want to go further, you can do the industry as a whole a favor > and extend the IPR regime to protect third-parties: > > o License revoked if you assert IPR against ANYONE because of THEIR > implementation of the published standard > > - This gives people a reason to prosecute IPR in something they > hope to be royalty free. > > - It provides a layer of protection to the industry by dissuading > non-participants from asserting their (unknown to the work group) IPR > against the ultimate standard. > > > For an example of such a declaration, see: > https://datatracker.ietf.org/ipr/580/ > > On Nov 12, 2009, at 3:38 AM, > > wrote: > >> Hi, >> The Polycomm license agreement states that "In the event that >> Licensee makes a Qualifying Patent Assertion against Polycom or any >> of its subsidiaries, Polycom may immediately terminate all patent >> rights conveyed herein." I'm not a lawer, but I interprete this >> such that the Licensee also gives his whole patent portfolio royalty- >> free to Polycomm if he wants to get the Polycomm codec royalty-free. >> Am I right? >> >> Best regards, >> Jari Hagqvist >> >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of ext stephen botzko >> Sent: 11. marraskuuta 2009 20:01 >> To: codec@ietf.org >> Subject: [codec] Fwd: G.719 royalty-free license >> >> The license agreement from Polycom can be found here: >> http://www.polycom.com/company/about_us/technology/siren_g7221/license_schedu >> le.html >> >> with a faq sheet here: >> http://www.polycom.com/company/about_us/technology/siren_g7221/ >> faq.html >> >> Note that Polycom licenses G.722.1 and G.719 with the same agreement. >> >> Stephen Botzko >> Polycom. >> >> >> >> On Wed, Nov 11, 2009 at 11:30 AM, Benjamin M. Schwartz >> >> wrote: >> Anisse Taleb wrote: >>> I assume this means that the codec is entirely royalty free since >> Polycom >>> offers also a royalty free license? Any comments on this? >> >> Polycom's license is "royalty free" but contains various use >> restrictions >> and advertising clauses. It is far from "no strings attached". We >> don't >> know what Ericsson's license says, although we now know how to find >> out >> what it is. Even Ericsson's license were a universal binding patent >> non-assertion statement, the codec would still not be compatible with >> common open-source licenses due to Polycom's patent licensing >> restrictions. >> >> --Ben >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ingemar.s.johansson@ericsson.com Wed Nov 11 17:20: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 2EA1128C178 for ; Wed, 11 Nov 2009 17:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 V5WPLtUHfrkD for ; Wed, 11 Nov 2009 17:20:56 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E25EA28C17B for ; Wed, 11 Nov 2009 17:20:55 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-93-4afb6313cb04 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 5B.92.31706.3136BFA4; Thu, 12 Nov 2009 02:21:23 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:20:17 +0100 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, 12 Nov 2009 02:20:16 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C02361194@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: G.719 royalty-free license Thread-Index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAUl49A From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 12 Nov 2009 01:20:17.0970 (UTC) FILETIME=[4B826120:01CA6336] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 01:20:57 -0000 Hi As a piece of additional info. Those of you interested in the actual = c-code and the specification can find it at=20 http://www.itu.int/rec/T-REC-G.719-200806-I BR /Ingemar =20 > -----Original Message----- > From: Ingemar Johansson S=20 > Sent: den 12 november 2009 00:26 > To: codec@ietf.org > Subject: G.719 royalty-free license >=20 > Hi >=20 > I have the following announcement regarding G.719 >=20 > Ericsson offers a royalty-free license under Ericsson's G.719=20 > standard essential patents for end user products.=20 > The license agreement can be obtained by contacting=20 > patent.licensing@ericsson.com >=20 > =20 > Regards > Ingemar > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc.=20 > Senior Research Engineer=20 >=20 > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >=20 From ingemar.s.johansson@ericsson.com Wed Nov 11 17:27: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 7096C28C172 for ; Wed, 11 Nov 2009 17:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=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 LgwrgrARCivp for ; Wed, 11 Nov 2009 17:27:11 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A404828C165 for ; Wed, 11 Nov 2009 17:27:10 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-53-4afb6489038c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8C.0E.04191.9846BFA4; Thu, 12 Nov 2009 02:27:37 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:26:14 +0100 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_01CA6337.2024A2C4" Date: Thu, 12 Nov 2009 02:26:13 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C02361197@esealmw109.eemea.ericsson.se> In-Reply-To: <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] G.719 royalty-free license Thread-Index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAA8Pu7ABPQDbA= References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> From: "Ingemar Johansson S" To: "Jean-Marc Valin" , X-OriginalArrivalTime: 12 Nov 2009 01:26:14.0923 (UTC) FILETIME=[204515B0:01CA6337] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 01:27:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6337.2024A2C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 And thanks for the response and the offer. I am still of the very strong opinion that codec work should be done in = another venue (ITU-T, 3GPP, ...), this is mainly for practical reasons. = There are also legal matters around which makes other venues more = suitable but I don't believe that I am skilled enough to discuss the = latter. =20 Regards Ingemar ________________________________ From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: den 12 november 2009 00:53 To: Ingemar Johansson S; codec@ietf.org Subject: RE: [codec] G.719 royalty-free license =09 =09 Hi, =09 I think this is great news! I guess this shows that collaboration would = be possible. I would personally like to invite Ericsson to contribute = the G.719 technology as input to the proposed working group. This could = certainly help towards meeting some of the requirements we currently = have and create an overall better codec. =09 Cheers, =09 Jean-Marc =09 =09 -----Original Message----- From: codec-bounces@ietf.org on behalf of Ingemar Johansson S Sent: Wed 11/11/2009 10:26 AM To: codec@ietf.org Subject: [codec] G.719 royalty-free license =09 Hi =09 I have the following announcement regarding G.719 =09 Ericsson offers a royalty-free license under Ericsson's G.719 standard = essential patents for end user products. The license agreement can be obtained by contacting = patent.licensing@ericsson.com =09 =09 Regards Ingemar = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc. Senior Research Engineer =09 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com Visit http://labs.ericsson.com ! = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =09 =09 ------_=_NextPart_001_01CA6337.2024A2C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [codec] G.719 royalty-free license
Hi
 
And thanks for the response and the=20 offer.
I am still of the very strong opinion that = codec work=20 should be done in another venue (ITU-T, 3GPP, ...), this is mainly = for=20 practical reasons. There are also legal matters around which = makes=20 other venues more suitable but I don't believe that I am skilled = enough to=20 discuss the latter.
 
Regards
Ingemar

From: Jean-Marc Valin=20 [mailto:jean-marc.valin@octasic.com]
Sent: den 12 november = 2009=20 00:53
To: Ingemar Johansson S; = codec@ietf.org
Subject: RE:=20 [codec] G.719 royalty-free license

Hi,

I think this is great news! I guess this = shows that=20 collaboration would be possible. I would personally like to invite = Ericsson to=20 contribute the G.719 technology as input to the proposed working = group. This=20 could certainly help towards meeting some of the requirements we = currently=20 have and create an overall better=20 = codec.

Cheers,

       =20 Jean-Marc


-----Original Message-----
From:=20 codec-bounces@ietf.org on behalf of Ingemar Johansson S
Sent: Wed=20 11/11/2009 10:26 AM
To: codec@ietf.org
Subject: [codec] G.719=20 royalty-free license

Hi

I have the following = announcement=20 regarding G.719

Ericsson offers a royalty-free license under = Ericsson's=20 G.719 standard essential patents for end user products.
The license = agreement can be obtained by contacting=20 = patent.licensing@ericsson.com


Regards
Ingemar
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
INGEMAR=20 JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson=20 AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, = Lule=E5,=20 Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078=20 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Visit = http://labs.ericsson.com=20 = !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________= ________
codec=20 mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

= ------_=_NextPart_001_01CA6337.2024A2C4-- From stpeter@stpeter.im Wed Nov 11 17:33: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 215043A67B1 for ; Wed, 11 Nov 2009 17:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 ij8K9jnL9OGn for ; Wed, 11 Nov 2009 17:33:58 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 237803A63C9 for ; Wed, 11 Nov 2009 17:33:58 -0800 (PST) Received: from host-18-99.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A220940D09; Wed, 11 Nov 2009 18:34:25 -0700 (MST) Message-ID: <4AFB661F.1000806@stpeter.im> Date: Thu, 12 Nov 2009 10:34:23 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C02361197@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C02361197@esealmw109.eemea.ericsson.se> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070608090003020905070706" Cc: codec@ietf.org Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 01:33:59 -0000 This is a cryptographically signed message in MIME format. --------------ms070608090003020905070706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/12/09 10:26 AM, Ingemar Johansson S wrote: > And thanks for the response and the offer. > I am still of the very strong opinion that codec work should be done in > another venue (ITU-T, 3GPP, ...), this is mainly for practical > reasons. Would it be possible for you to describe some of those practical reasons? I think that would be very helpful for our discussions at the BoF today. The more practical and factual we can be, the better. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070608090003020905070706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMjAxMzQyM1owIwYJKoZIhvcNAQkEMRYEFN82/7o3+cZB89brnWTZ qYXHgzrIMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIieS9UrCWlhYMs1Nl5HXBx7gV+k7tpmt0dkSg1n0 rVOBhnm4u2pIR0DLvwHw2HucHWgd8KniH8TkvjjZllyBBQvlQ9zqxUI/lFNTYPigPJTmAP25 CGW3zoO02vJ5QiFrZbs+8g6dnDYIILCg62Bh9PdNbbdzSMmUw1IoAbTSmzyQWgmHglqsB0YQ gdEKzK/R/B/ri6/g3TO80Jkurm0No1jtR/WxFYtKCKEpibO0kxw1Ik1UexVPE7MJ9Cs2dVRp orFUyRr6ad2Yjcdawh729lysXdcE5pCOqrhTFf+QJKnUd3uBMT6cUEQXkLeJghlwDWqQJpDb UWQ6pfESHp8HDAAAAAAAAA== --------------ms070608090003020905070706-- From ron.even.tlv@gmail.com Wed Nov 11 17:42:27 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDB13A69D9 for ; Wed, 11 Nov 2009 17:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xVwJLLaE6LIM for ; Wed, 11 Nov 2009 17:42:26 -0800 (PST) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id 4E6533A6839 for ; Wed, 11 Nov 2009 17:42:26 -0800 (PST) Received: by ywh27 with SMTP id 27so1574207ywh.31 for ; Wed, 11 Nov 2009 17:42:51 -0800 (PST) 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=1qGuPJ3iTZgPK1Zg7bMLKNauNbEdD9syL3WDKn5tIjM=; b=V23yptO9yxJirKrdsMYw5q/kD9MM7V3X4w0neLmR5QtQ3WhAznVcZx1bQEOmC9ANeb 2aS7zT1U0DIRE6Qh/izrCbDxLNx2irzGhCabWdGjU6karFrEwV0ZTzwpIWzXIWgv5qJ2 HyEcf+C/s/OLWsxB2BPVYMqV+huZOw79klUr0= 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=lbWp6V3xgJIfnIRjmeXj64LHVKgcx+/Pm/2tvs/l0nRMzDWhOe7H7AgBwDnzh1qr8k FSWYeY17qEp7331PMTS2JY5sjkgvMP/noxSKO++kGTeAklaCl2zbjGwWzwtAkegRyWhU +WD+86l64+hAGaVoV9H0PHULa0EkrA4DWhfkM= Received: by 10.150.28.4 with SMTP id b4mr4117686ybb.124.1257990171178; Wed, 11 Nov 2009 17:42:51 -0800 (PST) Received: from windows8d787f9 (host-18-119.meeting.ietf.org [133.93.18.119]) by mx.google.com with ESMTPS id 15sm1071460gxk.4.2009.11.11.17.42.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 17:42:50 -0800 (PST) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Ingemar Johansson S'" , References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> In-Reply-To: <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> Date: Thu, 12 Nov 2009 10:41:42 +0900 Message-ID: <4afb681a.0f0bca0a.2c10.61f9@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CA6384.BB4514A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAA8Pu7ABRhszA= Content-Language: en-us Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 01:42:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01CA6384.BB4514A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think that this should be part of survey of existing solutions. Based = on the current requirements this codec qualifies since it is royalty free = and there is no need to bring it as a proposal since it is already been = approved by a standard body. The rest of the requirements are a set that allows any high quality = codec to qualify since there is no selection based on requirements and the = proposal is to allow the proposed group to select multiple codec. =20 Roni Even =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Jean-Marc Valin Sent: Thursday, November 12, 2009 12:53 AM To: Ingemar Johansson S; codec@ietf.org Subject: Re: [codec] G.719 royalty-free license =20 Hi, I think this is great news! I guess this shows that collaboration would = be possible. I would personally like to invite Ericsson to contribute the = G.719 technology as input to the proposed working group. This could certainly = help towards meeting some of the requirements we currently have and create an overall better codec. Cheers, Jean-Marc -----Original Message----- From: codec-bounces@ietf.org on behalf of Ingemar Johansson S Sent: Wed 11/11/2009 10:26 AM To: codec@ietf.org Subject: [codec] G.719 royalty-free license Hi I have the following announcement regarding G.719 Ericsson offers a royalty-free license under Ericsson's G.719 standard essential patents for end user products. The license agreement can be obtained by contacting patent.licensing@ericsson.com Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc. Senior Research Engineer Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_0029_01CA6384.BB4514A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [codec] G.719 royalty-free license

Hi,

I think that this should be part of survey of existing solutions. Based on the current requirements this codec qualifies since = it is royalty free and there is no need to bring it as a proposal since it is = already been approved by a standard body.

The rest of the requirements are a set that allows any = high quality codec to qualify since there is no selection based on = requirements and the proposal is to allow the proposed group to select multiple = codec.

 

Roni Even

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Jean-Marc Valin
Sent: Thursday, November 12, 2009 12:53 AM
To: Ingemar Johansson S; codec@ietf.org
Subject: Re: [codec] G.719 royalty-free = license

 

Hi,

I think this is great news! I guess this shows that collaboration would = be possible. I would personally like to invite Ericsson to contribute the = G.719 technology as input to the proposed working group. This could certainly = help towards meeting some of the requirements we currently have and create an overall better codec.

Cheers,

        Jean-Marc


-----Original Message-----
From: codec-bounces@ietf.org on behalf of Ingemar Johansson S
Sent: Wed 11/11/2009 10:26 AM
To: codec@ietf.org
Subject: [codec] G.719 royalty-free license

Hi

I have the following announcement regarding G.719

Ericsson offers a royalty-free license under Ericsson's G.719 standard essential patents for end user products.
The license agreement can be obtained by contacting patent.licensing@ericsson.com


Regards
Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Visit http://labs.ericsson.com = !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------=_NextPart_000_0029_01CA6384.BB4514A0-- From ingemar.s.johansson@ericsson.com Wed Nov 11 17:56: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 079CB3A67AD for ; Wed, 11 Nov 2009 17:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Qvz6jbPzUTvF for ; Wed, 11 Nov 2009 17:55:59 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CB4CF3A67A6 for ; Wed, 11 Nov 2009 17:55:58 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-37-4afb6b4ad00c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 3F.D6.24094.A4B6BFA4; Thu, 12 Nov 2009 02:56:26 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:56:25 +0100 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, 12 Nov 2009 02:56:21 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0236119E@esealmw109.eemea.ericsson.se> In-Reply-To: <4AFB661F.1000806@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] G.719 royalty-free license Thread-Index: AcpjOEa3ljTQEhSdQtmQ/aZgrl4WnAAAOjeg References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <390831ED3DF58E41A3D2FB82591E2C3604932A89@MAILEXCH.octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C02361197@esealmw109.eemea.ericsson.se> <4AFB661F.1000806@stpeter.im> From: "Ingemar Johansson S" To: "Peter Saint-Andre" X-OriginalArrivalTime: 12 Nov 2009 01:56:25.0929 (UTC) FILETIME=[57B6AB90:01CA633B] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 01:56:00 -0000 OK The main practical reason from my perspactive (my humble and personal opinion) is that we have at our company a limited number of people who do codec research. It is not a secret that all major companies today need to prioritize the work and participating in the (codec)work in one particular venue is not automatically guaranteed just because this work exists. The amount of work must in some sense give a reasonable benefit. I don't today see that codec work in IETF would provide with a benefit over the activities already conducted in other standards venues, to put it short I don't see the added value to justify the participation in a possible codec WG. =20 =20 Regards Ingemar > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 > Sent: den 12 november 2009 10:34 > To: Ingemar Johansson S > Cc: Jean-Marc Valin; codec@ietf.org > Subject: Re: [codec] G.719 royalty-free license >=20 > On 11/12/09 10:26 AM, Ingemar Johansson S wrote: >=20 > > And thanks for the response and the offer. > > I am still of the very strong opinion that codec work=20 > should be done=20 > > in another venue (ITU-T, 3GPP, ...), this is mainly for practical=20 > > reasons. >=20 > Would it be possible for you to describe some of those=20 > practical reasons? I think that would be very helpful for our=20 > discussions at the BoF today. The more practical and factual=20 > we can be, the better. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 From ingemar.s.johansson@ericsson.com Wed Nov 11 18: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 694E73A6960 for ; Wed, 11 Nov 2009 18:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 8h4jRcoOYjNU for ; Wed, 11 Nov 2009 18:08:05 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 06B0F3A694E for ; Wed, 11 Nov 2009 18:08:04 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-6e-4afb6e20566b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4C.0F.04191.02E6BFA4; Thu, 12 Nov 2009 03:08:32 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 03:08:32 +0100 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, 12 Nov 2009 03:08:26 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C023611A4@esealmw109.eemea.ericsson.se> In-Reply-To: <4afada75.1701d00a.2238.14e3@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] G.719 royalty-free license Thread-Index: Acpi41SNGyusSTVjSW+y6zgfX3M8OQAAU4AQABYAfHA= References: <130EBB38279E9847BAAAE0B8F9905F8C02361035@esealmw109.eemea.ericsson.se> <4afada75.1701d00a.2238.14e3@mx.google.com> From: "Ingemar Johansson S" To: "Anisse Taleb" , X-OriginalArrivalTime: 12 Nov 2009 02:08:32.0170 (UTC) FILETIME=[089640A0:01CA633D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] G.719 royalty-free 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, 12 Nov 2009 02:08:06 -0000 Hi This will give the rights to use G.719 RF under the terms listed in the = license agreement. Regards Ingemar=20 > -----Original Message----- > From: Anisse Taleb [mailto:anisse.taleb@huawei.com]=20 > Sent: den 12 november 2009 00:38 > To: Ingemar Johansson S; codec@ietf.org > Subject: RE: [codec] G.719 royalty-free license >=20 > Hi Ingo, > This is indeed quite interesting news given that this is a=20 > brand new codec and the first ITU-T fullband conversational codec. >=20 > I assume this means that the codec is entirely royalty free=20 > since Polycom offers also a royalty free license? Any=20 > comments on this? >=20 > Thanks for the information. >=20 > /Abisse=20 > > -----Original Message----- > > From: codec-bounces@ietf.org=20 > [mailto:codec-bounces@ietf.org] On Behalf=20 > > Of Ingemar Johansson S > > Sent: den 11 november 2009 16:26 > > To: codec@ietf.org > > Subject: [codec] G.719 royalty-free license > >=20 > > Hi > >=20 > > I have the following announcement regarding G.719 > >=20 > > Ericsson offers a royalty-free license under Ericsson's=20 > G.719 standard=20 > > essential patents for end user products. > > The license agreement can be obtained by contacting=20 > > patent.licensing@ericsson.com > >=20 > >=20 > > Regards > > Ingemar > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > INGEMAR JOHANSSON M.Sc. > > Senior Research Engineer > >=20 > > Ericsson AB > > Multimedia Technologies > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 From stpeter@stpeter.im Wed Nov 11 18:29: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 6BC8128C143 for ; Wed, 11 Nov 2009 18:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 AhS6wTNhFIba for ; Wed, 11 Nov 2009 18:29:11 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AF60528C12B for ; Wed, 11 Nov 2009 18:29:11 -0800 (PST) Received: from host-18-99.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70D2B40D09 for ; Wed, 11 Nov 2009 19:29:39 -0700 (MST) Message-ID: <4AFB7311.60002@stpeter.im> Date: Thu, 12 Nov 2009 11:29:37 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804080806030101070303" Subject: [codec] slides uploaded X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Nov 2009 02:29:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070804080806030101070303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Eric and I have just uploaded all the slides for today's BoF. You can find them here: https://datatracker.ietf.org/meeting/76/materials.html#wg-codec /psa --------------ms070804080806030101070303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMjAyMjkzN1owIwYJKoZIhvcNAQkEMRYEFLUtq/PVDke8bGtblkTS oHc3HwCoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABKECadhzSB1GdsZ0U3W2lIVe+zLl214VXbqhnYxV HGkcn7oPoSQzxtthljZ1CA0GDRlzL8kZxjvDLGCq9XGGpey0o6DvGmLaq5C6IXny6yoZACTT xL4oQCZorK9Cow4uhG8H3p9J0Rq+0Sldwl130L+6odNKX53EzDdIAAfh8rPllLov+pZxBPcu WXPWe9hQ9aAyMHPEga4MHbXBTKoL7BICrBREwT8IWU/REq4FueIcOw95tPxkNbOs112gRPKT JpGFHwfrxkWOM8iC+aAUDyFqCJwzG9WTombQvROvzIBg719SJI37A47XUDyvmBh7/ibYpDWG 5uQZeD+BeaBa3gAAAAAAAA== --------------ms070804080806030101070303-- From rob.glidden@sbcglobal.net Wed Nov 11 19:41: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 3CF7528C1BD for ; Wed, 11 Nov 2009 19:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBIYvspfImcD for ; Wed, 11 Nov 2009 19:41:11 -0800 (PST) Received: from atlmtaow01.cingularme.com (atlmtaow01.cingularme.com [66.102.165.6]) by core3.amsl.com (Postfix) with ESMTP id 3590E28C1BB for ; Wed, 11 Nov 2009 19:41:11 -0800 (PST) Received: from COM ([166.194.216.6]) by atlmtaow01.cingularme.com (InterMail vM.6.01.04.00 201-2131-118-20041027) with SMTP id <20091112034116.FKNW10708.atlmtaow01.cingularme.com@COM>; Wed, 11 Nov 2009 22:41:16 -0500 To: Eric Burger From: Date: Wed, 11 Nov 2009 22:40:00 -0500 Mime-Version: 1.0 X-Mailer: VersaMail(R) v. 4.0.1, Copyright (c) 2001-2006 Palm, Inc. X-Sender: rob.glidden@sbcglobal.net X-Priority: 3 Importance: Normal Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20091112034116.FKNW10708.atlmtaow01.cingularme.com@COM> X-Cloudmark-Analysis: v=1.0 c=1 a=j2oILlcjhfgA:10 a=o/VU/QRqK47s3C0XiqZXiA==:17 a=5RPZlWmqAAAA:8 a=bfLuiRfvAAAA:8 a=pcLIrrrKAAAA:8 a=48vgC7mUAAAA:8 a=rDYISnSzAAAA:8 a=hZG83p_yAAAA:8 a=pBniHKKpAAAA:8 a=40RsGamiAAAA:8 a=ZXsqBN31AAAA:8 a=PYw09vz0AAAA:8 a=vR12nkMaAAAA:8 a=jweqIkZIO2k9nEI43fcA:9 a=ZYGYnScUTawr0oqWURgA:7 a=_I7i-1hEHjQ_o2RNdq9Kso9zBKIA:4 a=s0g5mSLcFk4A:10 a=nFzGktgn3_0A:10 a=7tvQCrKcJV0A:10 a=lYaaKfVt5qcA:10 a=ftFGBYpk1mUA:10 a=lZB815dzVvQA:10 a=qi9FgK3vWkoA:10 a=owt5Fu6Rxwnlqems:21 a=AnnsiiBtaKNKZOXZ:21 Cc: codec@ietf.org Subject: Re: [codec] Royalty Free codec standards -- don't settle for less X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Nov 2009 03:41:13 -0000 Eric: Sorry, I am unclear what you are asking. Those are public materials from others, not me. http://www.cafc.uscourts.gov/opinions/07-1545.pdf is straight from the court (check the ruling it is interesting). Others are ipr statements or public emails from leaders and participants at the time. The gist is that on paper several groups have preferences and goals to standardize rf codecs, with charters very similar to here. In the case of jvt, on paper for nearly a decade now. As you can see from the emails even with leaders defending at opportune times the rf prospects. They haven't delivered yet. They haven't gone back and removed patents from baselines. They haven't done a lot of things, nor have the cultures around filled in the gaps. I think the right conclusion is not that it can't be done, it is just that it has not been done yet right. Rob -----Original Message----- From: Eric Burger Subj: Re: [codec] Royalty Free codec standards -- don't settle for less Date: Wed Nov 11, 2009 3:44 pm Size: 12K To: Rob Glidden cc: codec@ietf.org Am I missing something here? I cannot tell if what you are saying is the JVC EG was able to produce a RF baseline (the last paragraph) or they were not able to produce a RF baseline (the second to last paragraph)? One thing that is clearly different is IPR declaration in the IETF is not optional: it is mandatory and the policy is clear. Moreover, there is established case law that if a participant neglects to declare their IPR, and the IPR gets incorporated into a standard, the participant loses their IP rights. On Nov 12, 2009, at 2:10 AM, Rob Glidden wrote: > No argument on the recipe -- build a royalty free house on a royalty > free foundation with royalty free bricks and royalty free > inspection, etc. > > But it wasn't the brick house that saved the three little pigs in > the end. > > It is about going the distance in the face of the inevitable > shilling, calls to drive into a ditch, meeting-stacking et al. > > And it is not about convincing the convinced -- it about proving > marketplace confidence. It is done all the time, codecs aren't the > unique special case some need them to be. > > Of course vet contributions for blocking patents and other loopholes. > > Some noteworthy stuff below. > > Rob > > > 2001 > > http://www.itscj.ipsj.or.jp/sc29/29w12911jvt.pdf > N4400, December 2001 > > Terms of Reference for a Joint Project between ITU-T Q.6/SG16 and > ISO/IEC JTC 1/SC 29/WG11 > for the Development of new Video Coding Recommendation and > International Standard > ... > "10.0 Patent and Copyright Issues > The project and joint group will progress the project work in > compliance with the Intellectual Property > Rights (“IPR”) policies and IPR reporting requirements and > procedures of both organisations > (http://www.itu.int/ITU-Databases/TSBPatent/ and http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm) > . > * > JVT will define a “baseline” profile. That profile should be royalty- > free for all implementations.* The > performance of this profile will particularly be the subject of > performance verification tests. > JVT’s rules for the implementation of the IPR policy are contained > in Annex 3." > > > 2002 > > http://lists.mpegif.org/pipermail/discuss/2002-May/000347.html > > [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG-4 > Licensing ... > Fernando Pereira fp lx.it.pt > Mon May 13 18:40:38 EDT 2002 > > * Previous message: [M4IF Discuss] RE: [M4IF News] To those > concerned about MPEG-4 Licensing ... > * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned > about MPEG- 4 Licensing ... > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > Hi ! Yuval Fisher wrote: > > > > > As for me, I'm looking at MPEG-4 Part 10 and hoping that it is > > > patent-free ;-) > > > I wouldn't hold your breath. Many companies are nervous about > submarine > > patents. There's a strong anti-free-license movement in MPEG. > > Let me disagree with this statement ! As the current chairman of > MPEG Requirements, I would claim that MPEG is doing everything to > support the royalty free approach for the baseline profile of MPEG-4 > part 10 (AVC) ... and there is a very large support within MPEG > members. Of course there is also people with a (legitimate) > different opinion but I would personally claim this is a minority. > > Let me also explain that the approach is not simply everything > royalty free but a combination of a royalty free baseline profile > with other more complex profiles not necessarily royalty free (but > RAND). This combination may provide a good compromise between the > two possible extreme alternatives. Finally let me inform that 2 > profiles were defined for AVC/H.264 last week in Fairfax: BASELINE > (to be royalty free) and MAIN (not necessarily royalty free). > > Regards Fernando Pereira -- Fernando Manuel Bernardo Pereira, Ph.D., > Professor > Instituto Superior Técnico - Instituto de Telecomunicações > Av. Rovisco Pais, 1049-001 Lisboa, PORTUGAL > Phone: + 351 21 8418460 Fax: + 351 21 8418472 > E-mail: Fernando.Pereira lx.it.pt WWW: http://www.img.lx.it.pt/~fp/ > > > > [M4IF Discuss] RE: [M4IF News] To those concerned about MPEG- 4 > Licensing ... > Rob Koenen rkoenen intertrust.com > Fri May 3 20:59:52 EDT 2002 > > * Previous message: [M4IF Discuss] To those concerned about MPEG-4 > Licensing ... > * Next message: [M4IF Discuss] RE: [M4IF News] To those concerned > about MPEG- 4 Licensing ... > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > > As for me, I'm looking at MPEG-4 Part 10 and hoping > > that it is > > > patent-free ;-) > > > > > > I wouldn't hold your breath. Many companies are nervous about > > submarine > > patents. There's a strong anti-free-license movement in MPEG. > > Sweeping statements like these are very unhelpful. > > It may indeed be unlikley that full JVT codec is going to be RF > (Royalty-Free). > There is, however, a strong desire among many parties to try and > establish a RF baseline. There is an ongoing effort to see how such > an RF baseline could be established. It is area in which people like > to maneuver carefully, for obvious reasons. > > Rob > > > > 2003 > > http://lists.mpegif.org/pipermail/discuss/2003-November/000541.html > Rob Koenen to Iain Richardson > /Thu Nov 20 07:47:47 EST 2003 > / > > (1) Does this mean that the goal of a royalty-free Baseline Profile > is not > going to happen ? > > ... > > I'll answer for what I know and understand today. > 1) Via Licensing's website states that their proposed terms cover > "use of > Baseline, Main, and Extended Profiles". MPEG LA's announcement > states "These > terms cover the entire AVC Standard regardless of which Profile(s) are > used". I think that gives you the answer. > > > > > 2004 > > H.264/MPEG-4 Part 10 is also subject to a number of essential. > patents. > However, in order to make the new standard as accessible as possible, > the JVT has attempted to make the Baseline Profile (see Chapter 6) > 'royalty free'. During the standardisation process, holders of key > patents were encouraged to notify JVT of their patent claims and to > state whether they would permit a royalty free license to the > patent(s). These patent statements have been taken into account during > the development of the Profiles with the aim of keeping the Baseline > free of royalty payments. As this process is voluntary and relies on > the > correct identification of all relevant patents prior to > standardisation, > it is not yet clear whether the goal of a royalty-free Profile will be > realised but initial indications are positive [1]. > > 1 In March 2003, 31 companies involved in the H.264 development > process > and/or holding essential patents confirmed their support for a > royalty-free Baseline Profile. > > Iain E.G. Richardson, H.264 and MPEG-4 Video Compression: Video Coding > for Next-Generation Multimedia at 274 (John Wiley & Sons, 2004). > > 2007: > > (look also at what happened to the attorneys) > > "Thus, while the language of the JVT IPR policies may not expressly > require disclosure by all participants in all circumstances (e.g., > if relevant IPR is not disclosed despite the use of best efforts), > it at least incorporates a best efforts standard (even apart from > the submission of technical proposals). > ... > In sum, we conclude that Qualcomm, as a participant in the JVT prior > to the release of the H.264 standard, did have IPR disclosure > obligations, as discussed above, under the written policies of both > the JVT and its parent organizations" > > http://www.cafc.uscourts.gov/opinions/07-1545.pdf > > Trial court decision: > > http://www.klgates.com/files/upload/eDAT_Qualcomm_8_6_07_Order_on_Remedy.pdf > > > 2007 SC29 revised patent policy > > http://www.itscj.ipsj.or.jp/sc29/29w7ipr.htm > > "Although royalty-bearing patented technologies may be included in > SC 29 standards, SC 29 suggests to its WGs to promote, whenever > possible, the inclusion of technologies that either do not require a > patent license, or that only require a RAND license without a > royalty or license fee." > > 2007 ISO/ITU common patent policy > > 2009: > > MPEG HVC > > > > > > Eric Burger wrote: >> In practical terms, I agree that there will be better and better >> codecs in the future. However, I would offer the older codecs are >> good enough for our purposes and will be safe. >> >> On Nov 11, 2009, at 1:15 PM, Stephan Wenger wrote: >> >>> The existence of at least a dozend of projects in the speech >>> coding field >>> today suggests to me that we have not yet reached the point of >>> technology >>> progress saturation in this field. Other that this minor point, I >>> agree. >>> >>> Stephan >>> >>> >>> >>> On 11/11/09 12:26 PM, "Koen Vos" wrote: >>> >>>> 1. Technological progress saturates. >>>> 2. Patents expire. >>>> Therefore, the performance advantage of royalty-bearing standards >>>> diminishes with time, and high-quality, royalty-free standards are >>>> unavoidable. I'm convinced that today we have reached this point of >>>> commoditization for audio and speech coding technology. >>>> >>>> koen. >>>> >>>> >>>> Quoting Rob Glidden: >>>>> Here is my view, perhaps you share it, perhaps you don't. >>>>> >>>>> What the world needs now is royalty-free, standardized codecs. >>>>> This >>>>> is critical to the future of the Web, and the progress the >>>>> Internet >>>>> has brought to the world, and will bring to the world. >>>>> >>>>> Video, audio, transport, the whole thing. Evaluated, vetted for >>>>> patents. Under an appropriate, responsible and complete royalty >>>>> free >>>>> process. No less. >>>>> >>>>> IETF, ITU, and ISO/MPEG should all get going on this important >>>>> activity -- after all why shouldn't all of these organizations >>>>> include this as core to their mission. >>>>> >>>>> I have, and no doubt you have too, seen countless explanations why >>>>> this should not, could not, will not, rather not, might not, or >>>>> can >>>>> not happen. Some well meaning and sincere, some from vested >>>>> interests. There are too many "powerful" interests against it. >>>>> "Important" commercial interests are ambivalent. It is too hard >>>>> "legally" or "politically" or "technically". It is just too >>>>> confusing to think through. There is no longer a critical mass >>>>> that >>>>> cares enough about keeping the future of the Open Internet open >>>>> and >>>>> royalty free. The well meaning are ignorant, or naive. Etc. >>>>> >>>>> Don't settle. Take the issue of royalty free, standardized codecs >>>>> all the way to the top of these organizations. Do what it takes. >>>>> If >>>>> it requires new organizations, start them. It it requires revised >>>>> processes, revise them. This is the spirit that built the Web and >>>>> the Internet, this is the spirit that is its lifeblood, and this >>>>> is >>>>> the spirit that needs to be at the heart of its future. >>>>> >>>>> Don't settle. Don't let those who have tried hard already, or have >>>>> only half-heartedly tried, justify the status quo or their >>>>> half-heartedness. Encourage them to focus on how to take the next >>>>> steps. Don't let convenient "interpretations" of standards >>>>> processes be an excuse for never starting, never finishing, or >>>>> never >>>>> setting up processes that will work. Need more legal background? >>>>> Find it. More technical information? Get it. >>>>> >>>>> Don't settle. The world has plenty of patent-encumbered media >>>>> standards, plenty of proprietary solutions, and plenty of >>>>> standards >>>>> in other domains that have figured out how to deliver royalty >>>>> free. >>>>> But the world does not have enough royalty-free codec standards, >>>>> so >>>>> this is the task that needs to be addressed. >>>>> >>>>> Rob >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 gregory.ietf@gmail.com Wed Nov 11 23:46: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 10E783A6919 for ; Wed, 11 Nov 2009 23:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 3-B5mOJpTJ04 for ; Wed, 11 Nov 2009 23:46:16 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 08E383A68FA for ; Wed, 11 Nov 2009 23:46:15 -0800 (PST) Received: by ywh13 with SMTP id 13so2248413ywh.29 for ; Wed, 11 Nov 2009 23:46:42 -0800 (PST) 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=U402+1tO8WU/N347uzWhy/grys5TOpRq0bOti6w5ikM=; b=deR4Y33pEsshEH38R2Y3RDRIOB+NruJucCCgHs5P96RsyB9ga9snvLwKsK/YutB0JX A9WFT6poz2oChg2qjTa+c8Oaujhu4vjLhU610WtIDD7JNONjrb1Fqysq0I/AX/1rwokg 5wwtT6ux1QNSG0N08er0EJO834/qGa+l3eW/E= 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=NT7iV22QUQbkozsOHQ58F9SwWT5iM8d7367wP/OV33t3Q7a7ADKs6J015ZUUpuch/I xoYywcu2QHy0MhFmfFnm/ijq6d1uTzTsrXNey6q2PVawHqt6MRubkNMwG4VxeSRNcnZS 9ffwbpnEZCngMLzNhESbW3JCdhHMVJ+mVMbGY= Received: by 10.150.210.5 with SMTP id i5mr4650936ybg.174.1258012002163; Wed, 11 Nov 2009 23:46:42 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-200.meeting.ietf.org [133.93.32.200]) by mx.google.com with ESMTPS id 13sm1241896gxk.9.2009.11.11.23.46.39 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 23:46:41 -0800 (PST) Message-ID: <4afbbd61.0d0bca0a.0da7.72d0@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Nov 2009 23:46:36 -0800 To: Simon Perreault From: "Gregory M. Lebovitz" In-Reply-To: <4AFBA784.5000303@viagenie.ca> References: <4AFBA784.5000303@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: codec@ietf.org Subject: Re: [codec] Questions asked in 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, 12 Nov 2009 07:46:17 -0000 It should also be noted that there was a question something to the effect of: This work should be done in cooperation between IETF & ITU-T: ~40+ I'm not exactly sure about the number (40) that I quoted, but it can be confirmed in the forthcoming minutes. also, see corrections below inline... At 10:13 PM 11/11/2009, Simon Perreault wrote: >Hello, > >Just a quick observation on the questions asked today. > >Willing to do the work and do it in IETF: ~20 Want to work on this problem as stated, and want to do it in the IETF >Willing to do the work, not in the IETF: ~0 >Not willing to do the work, nowhere: ~50 Don't want to work on this problem, not here, not anywhere HTH, Gregory. >The 50:20 ratio may seem high. But it was not asked how many people >*not* willing to do the work think this work should happen at the IETF. >I think this figure would have been high. > >For example, I know nothing about codecs, and have no time to work on >this, but would love to see this work done in the IETF. I'm sure I'm not >alone. > >Simon >-- >DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >vCard 4.0 --> http://www.vcarddav.org From eburger@standardstrack.com Thu Nov 12 00:06: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 B15D23A6A4F for ; Thu, 12 Nov 2009 00:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 UdAfo+CSLCMQ for ; Thu, 12 Nov 2009 00:06:02 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id B7C653A69DD for ; Thu, 12 Nov 2009 00:06:02 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8UhI-0001qT-7d for codec@ietf.org; Thu, 12 Nov 2009 00:06:28 -0800 Message-Id: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> From: Eric Burger 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 v936) Date: Thu, 12 Nov 2009 17:06:22 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [codec] DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Nov 2009 08:06:03 -0000 Thank you to everyone who participated in the room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need the work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16. Please review the minutes and send corrections. The minutes are posted to: http://www.ietf.org/proceedings/09nov/minutes/codec.txt From stpeter@stpeter.im Thu Nov 12 13:39: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 854113A67DA for ; Thu, 12 Nov 2009 13:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 avKeyUuPmhCA for ; Thu, 12 Nov 2009 13:39:20 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 836743A657C for ; Thu, 12 Nov 2009 13:39:20 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D53F40D09; Thu, 12 Nov 2009 14:39:48 -0700 (MST) Message-ID: <4AFC80A2.8000009@stpeter.im> Date: Fri, 13 Nov 2009 06:39:46 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eric Burger References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> In-Reply-To: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010107080804040700070202" Cc: codec@ietf.org Subject: Re: [codec] DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Nov 2009 21:39:21 -0000 This is a cryptographically signed message in MIME format. --------------ms010107080804040700070202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/12/09 5:06 PM, Eric Burger wrote: > The minutes are posted to: > http://www.ietf.org/proceedings/09nov/minutes/codec.txt At least in my browser there were some improperly-encoded characters (cf. the technical plenary!) and I found some errors typographical errors and incorrectly spelled names. I have fixed those editorial issues and uploaded corrected notes. Many thanks to the note takers, and to everyone who contributed to a productive BoF. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010107080804040700070202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMjIxMzk0NlowIwYJKoZIhvcNAQkEMRYEFI2DcaL7ODFu54iVimxF NaTIiQ2HMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOpcX2vi6lxsU4//KChOiuZiNAW8v7VmjO7TLZQpQ qSHG5IW7btOp6L8bpkfm7d4iWcPQ6ndLf+0PjYO/6xmbJasunHTs5BZX4EGrL5onCt9Jpak7 BdjtJQJsyxq3nRZVj0kjlsyE8ZccruAe0HyoOwWhLev9ytUUu5qGByyQC73VPr9Vbl1Ljmys dTsxpOcq9qmxzFMGgSNd3HBQ4UiPci+Dy6bF4iugX8PDGHmWmAmZcR+Rm+GBilTE/Gw6Q+ip bjAhJ8DLB/CQelQySdF9CqYo4okfklt5jra1medubFJp27S5+B7oxOnf4zgRKCCWY+m4U7oZ bYZvlKePKmWh1QAAAAAAAA== --------------ms010107080804040700070202-- From stpeter@stpeter.im Thu Nov 12 13:40: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 E6C093A68ED for ; Thu, 12 Nov 2009 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 OdQCl-22-UAH for ; Thu, 12 Nov 2009 13:40:03 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2EE583A657C for ; Thu, 12 Nov 2009 13:40:03 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9307C40D09; Thu, 12 Nov 2009 14:40:31 -0700 (MST) Message-ID: <4AFC80CD.3000806@stpeter.im> Date: Fri, 13 Nov 2009 06:40:29 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eric Burger References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFC80A2.8000009@stpeter.im> In-Reply-To: <4AFC80A2.8000009@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000403060803000904090301" Cc: codec@ietf.org Subject: Re: [codec] DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Nov 2009 21:40:04 -0000 This is a cryptographically signed message in MIME format. --------------ms000403060803000904090301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/13/09 6:39 AM, Peter Saint-Andre wrote: > some errors typographical errors Like that. :) --------------ms000403060803000904090301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMjIxNDAyOVowIwYJKoZIhvcNAQkEMRYEFMgLkWxyIlXzbCijctM/ DWQNGSbMMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAH4bSsU5+1h5R7NsymT2eygYzJ+7Hr1D5HvpyUDpP oyT+mLOPg/bFQtzxavYrwYxq5z1YXYK0imcwEya11eXdFIFFzscnP4QOZCzqlXRNpeccvGqU e0IClYIMfQ9/OVUSWFbb0/1G1dPpCcMoZn9cifLJb3C/BHqjnduOcjs8TpI8KGQ/k1+2nPMn capv+jjsS6Aq7Uk2oJ0tfwfvdsuaH5TzpLboelTgTE9fAaX6B2N8+SRz7HvdTPkabkO7SVAa jJBu/SoOe91Btw2g6a5HXnj0rprQXyoFgtSdevaxDZB/c2AP6A06NPzDt824EuDKgoY+GKCB ryNY9kZYpdEdmQAAAAAAAA== --------------ms000403060803000904090301-- From brian@freeswitch.org Fri Nov 13 14:17: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 4B65D3A6858 for ; Fri, 13 Nov 2009 14:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 YI1iz26n6cy0 for ; Fri, 13 Nov 2009 14:17:12 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 7ACBB3A62C1 for ; Fri, 13 Nov 2009 14:17:12 -0800 (PST) Received: by yxe30 with SMTP id 30so4005186yxe.29 for ; Fri, 13 Nov 2009 14:17:39 -0800 (PST) Received: by 10.150.61.10 with SMTP id j10mr8892599yba.282.1258150658880; Fri, 13 Nov 2009 14:17:38 -0800 (PST) Received: from ?192.168.1.19? (adsl-99-75-35-206.dsl.tul2ok.sbcglobal.net [99.75.35.206]) by mx.google.com with ESMTPS id 22sm119917ywh.30.2009.11.13.14.17.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 14:17:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-11-670581772 From: Brian West In-Reply-To: Date: Fri, 13 Nov 2009 16:17:35 -0600 Message-Id: <02B01440-5BA1-4874-B670-BD7CDFDB6BC4@freeswitch.org> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> To: Raymond (Juin-Hwey) Chen X-Mailer: Apple Mail (2.1075.2) Cc: "codec@ietf.org" Subject: Re: [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: Fri, 13 Nov 2009 22:17:14 -0000 --Apple-Mail-11-670581772 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Raymond, I would like to thank Broadcom for their commitment to Open Source/ Royalty Free codecs. Following up on this trend we have now commited mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree. We have working autotooled/libtoolized floating point implementations which are downloaded and built static for these modules in FreeSWITCH. If Broadcom would setup an SVN I would be happy to provide build systems for mac/linux for both floating and fixed point codecs. On a sidenote.. x-lite's bv32 is busted and not workable so anyone doing any implementations please be warned it will NOT WORK. Hopefully someone from counterpath is paying attention. Thanks, Brian West FreeSWITCH.org PS: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=15464 On Nov 10, 2009, at 9:09 PM, Raymond (Juin-Hwey) Chen wrote: > All, > > As a follow-up of my previous email below, I would like to bring to > everyone's attention that Broadcom today issued a news release that > formally announced that Broadcom is offering open source BroadVoice > C code royalty-free and without licensing fees. See, for example, > http://finance.yahoo.com/news/Broadcom-Offers-RoyaltyFree-prnews-2935046185.html?x=0&.v=1 > . > The open source BroadVoice C code is licensed under the GNU Lesser > General Public License (LGPL), version 2.1, as published by the Free > Software Foundation. > > As of now, the open source floating-point and fixed-point C code for > both BroadVoice16 and BroadVoice32 can be freely downloaded from > http://www.broadcom.com/broadvoice . > > This fulfills our previous promise in the email below to make > BroadVoice16/BroadVoice32 C code "open source" (since "open source" > is a desirable feature of candidate codecs for the Internet Wideband > Audio Codec). > > Thanks. > > Raymond --Apple-Mail-11-670581772 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = I would like to thank Broadcom for their commitment to Open = Source/Royalty Free codecs.  Following up on this trend we have now = commited mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree.  We have = working autotooled/libtoolized floating point implementations which are = downloaded and built static for these modules in FreeSWITCH.  If = Broadcom would setup an SVN I would be happy to provide build systems = for mac/linux for both floating and fixed point = codecs.

On a sidenote.. x-lite's bv32 is busted = and not workable so anyone doing any implementations please be warned it = will NOT WORK.  Hopefully someone from counterpath is paying = attention.

Thanks,
Brian = West


On Nov 10, 2009, at 9:09 PM, Raymond = (Juin-Hwey) Chen wrote:

All,

As a follow-up of my = previous email below, I would like to bring to everyone's attention that = Broadcom today issued a news release that formally announced that = Broadcom is offering open source BroadVoice C code royalty-free and = without licensing fees. See, for example,
http://finance.yahoo.com/news/Broadcom-Of= fers-RoyaltyFree-prnews-2935046185.html?x=3D0&.v=3D1 . 
The open source = BroadVoice C code is licensed under the GNU Lesser General Public = License (LGPL), version 2.1, as published by the Free Software = Foundation.

As of now, the open source floating-point and = fixed-point C code for both BroadVoice16 and BroadVoice32 can be freely = downloaded from 
http://www.broadcom.com/broadv= oice .

This = fulfills our previous promise in the email below to make = BroadVoice16/BroadVoice32 C code "open source" (since "open source" is a = desirable feature of candidate codecs for the Internet Wideband Audio = Codec).

Thanks.

Raymond 

= --Apple-Mail-11-670581772-- From tzafrir.cohen@xorcom.com Sat Nov 14 01:07: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 6E1563A67A6 for ; Sat, 14 Nov 2009 01:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pldbrln2HoqT for ; Sat, 14 Nov 2009 01:07:45 -0800 (PST) Received: from local.xorcom.com (local.xorcom.com [62.90.10.53]) by core3.amsl.com (Postfix) with ESMTP id 0EB213A6405 for ; Sat, 14 Nov 2009 01:07:44 -0800 (PST) Received: by local.xorcom.com (Postfix, from userid 1000) id 5CA2BC9810E; Sat, 14 Nov 2009 11:08:13 +0200 (IST) Date: Sat, 14 Nov 2009 11:08:13 +0200 From: Tzafrir Cohen To: codec@ietf.org Message-ID: <20091114090813.GS3204@xorcom.com> Mail-Followup-To: codec@ietf.org References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <02B01440-5BA1-4874-B670-BD7CDFDB6BC4@freeswitch.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02B01440-5BA1-4874-B670-BD7CDFDB6BC4@freeswitch.org> X-Forced-Service: Sadly Using Gmail [tm] Organization: Xorcom* User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [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: Sat, 14 Nov 2009 09:07:46 -0000 On Fri, Nov 13, 2009 at 04:17:35PM -0600, Brian West wrote: > Raymond, > I would like to thank Broadcom for their commitment to Open Source/ > Royalty Free codecs. Following up on this trend we have now commited > mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree. We have working > autotooled/libtoolized floating point implementations which are > downloaded and built static for these modules in FreeSWITCH. If > Broadcom would setup an SVN I would be happy to provide build systems > for mac/linux for both floating and fixed point codecs. > > On a sidenote.. x-lite's bv32 is busted and not workable so anyone doing > any implementations please be warned it will NOT WORK. Hopefully someone > from counterpath is paying attention. > > Thanks, > Brian West > FreeSWITCH.org > PS: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=15464 That changeset is only the FreeSWITCH modules. You also ommited from there the test data and test driver (bv16/bv.c) . After adding it, I see that the test fails: + cmp -s tv.bv16 ./tv.bv16.ref + checksum=1 + cmp -s tv.bv16.raw ./tv.bv16.ref.raw + cmp -s tv.bv16.bfe10.raw ./tv.bv16.bfe10.ref.raw + checksum=2 This means that the first encoding test fails, and likewise is the last encoding test. However encoding and decoding give the same reference data (the second test that passed). -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen@xorcom.com +972-50-7952406 mailto:tzafrir.cohen@xorcom.com http://www.xorcom.com iax:guest@local.xorcom.com/tzafrir From brian@freeswitch.org Sat Nov 14 03:10: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 3E0D03A688A for ; Sat, 14 Nov 2009 03:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, J_CHICKENPOX_21=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 yHiX17Q1Uuv9 for ; Sat, 14 Nov 2009 03:10:20 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 225823A67DD for ; Sat, 14 Nov 2009 03:10:19 -0800 (PST) Received: by ywh13 with SMTP id 13so4590384ywh.29 for ; Sat, 14 Nov 2009 03:10:46 -0800 (PST) Received: by 10.91.148.16 with SMTP id a16mr3841952ago.119.1258197046713; Sat, 14 Nov 2009 03:10:46 -0800 (PST) Received: from ?192.168.1.19? (adsl-99-75-35-207.dsl.tul2ok.sbcglobal.net [99.75.35.207]) by mx.google.com with ESMTPS id 21sm1216525yxe.55.2009.11.14.03.10.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 03:10:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Brian West In-Reply-To: <20091114090813.GS3204@xorcom.com> Date: Sat, 14 Nov 2009 05:10:43 -0600 Content-Transfer-Encoding: 7bit Message-Id: <1BEFC5A9-4DD7-4D71-AC9C-3FCCD2017D1D@freeswitch.org> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <02B01440-5BA1-4874-B670-BD7CDFDB6BC4@freeswitch.org> <20091114090813.GS3204@xorcom.com> To: Tzafrir Cohen X-Mailer: Apple Mail (2.1075.2) Cc: codec@ietf.org Subject: Re: [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: Sat, 14 Nov 2009 11:10:21 -0000 I didn't include bv.c as its not needed to build a library nor did I include any test programs. Mike Jerris is going to rework my build system and include fixed/float in addition to a few more things and we will push that back to broadcom once its complete. I have compiled the two libs on linux and my mac without any errors. In addition their seems to be some implementation confusion I'm working out with Broadcom right now. From what I can tell everyone has done G.192 bitpacking on the wire but thats not to RFC and the API for g.192 is for offline simulation purposes so seems everyone currently running BV16/BV32 might to be doing it wrong.... Feels a little like G726 RFC3551 vs AAL2 coding snafu. For offline testing you must define G192BITSTREAM=1 which is only referenced in bv.c and used for offline testing. I suspect your tests would pass if you compiled the test program with that flag. Broadcom says this "The G.192 bit-stream format is only for offline simulation purposes. For something real you want the bit-stream packed according to RFC4298." /b On Nov 14, 2009, at 3:08 AM, Tzafrir Cohen wrote: > On Fri, Nov 13, 2009 at 04:17:35PM -0600, Brian West wrote: >> Raymond, >> I would like to thank Broadcom for their commitment to Open Source/ >> Royalty Free codecs. Following up on this trend we have now commited >> mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree. We have working >> autotooled/libtoolized floating point implementations which are >> downloaded and built static for these modules in FreeSWITCH. If >> Broadcom would setup an SVN I would be happy to provide build systems >> for mac/linux for both floating and fixed point codecs. >> >> On a sidenote.. x-lite's bv32 is busted and not workable so anyone >> doing >> any implementations please be warned it will NOT WORK. Hopefully >> someone >> from counterpath is paying attention. >> >> Thanks, >> Brian West >> FreeSWITCH.org >> PS: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=15464 > > That changeset is only the FreeSWITCH modules. > You also ommited from there the test data and test driver (bv16/ > bv.c) . > > After adding it, I see that the test fails: > > + cmp -s tv.bv16 ./tv.bv16.ref > + checksum=1 > + cmp -s tv.bv16.raw ./tv.bv16.ref.raw > + cmp -s tv.bv16.bfe10.raw ./tv.bv16.bfe10.ref.raw > + checksum=2 > > This means that the first encoding test fails, and likewise is the > last > encoding test. However encoding and decoding give the same reference > data (the second test that passed). > > -- > Tzafrir Cohen > icq#16849755 jabber:tzafrir.cohen@xorcom.com > +972-50-7952406 mailto:tzafrir.cohen@xorcom.com > http://www.xorcom.com iax:guest@local.xorcom.com/tzafrir > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From brian@freeswitch.org Sat Nov 14 03:22: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 3E3363A6885 for ; Sat, 14 Nov 2009 03:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.753, 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 91m9PW3-h-T0 for ; Sat, 14 Nov 2009 03:21:59 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 09BF73A67F7 for ; Sat, 14 Nov 2009 03:21:58 -0800 (PST) Received: by gxk28 with SMTP id 28so1998399gxk.9 for ; Sat, 14 Nov 2009 03:22:26 -0800 (PST) Received: by 10.90.23.21 with SMTP id 21mr8567950agw.59.1258197746202; Sat, 14 Nov 2009 03:22:26 -0800 (PST) Received: from ?192.168.1.19? (adsl-99-75-35-207.dsl.tul2ok.sbcglobal.net [99.75.35.207]) by mx.google.com with ESMTPS id 15sm1753678yxh.4.2009.11.14.03.22.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 03:22:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-20-717668891 From: Brian West In-Reply-To: <20091114090813.GS3204@xorcom.com> Date: Sat, 14 Nov 2009 05:22:23 -0600 Message-Id: <1E899837-ABB1-4DED-B6A7-5D235E9C82FC@freeswitch.org> References: <90E2CC8B-2C60-4067-8AC0-62CBCD39249E@counterpath.com> <02B01440-5BA1-4874-B670-BD7CDFDB6BC4@freeswitch.org> <20091114090813.GS3204@xorcom.com> To: Tzafrir Cohen X-Mailer: Apple Mail (2.1075.2) Cc: codec@ietf.org Subject: Re: [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: Sat, 14 Nov 2009 11:22:00 -0000 --Apple-Mail-20-717668891 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Just a small update it seems its a 32bit vs 64bit issue... unsigned long bitword32; <-- LONG IS EVIL. /b On Nov 14, 2009, at 3:08 AM, Tzafrir Cohen wrote: > On Fri, Nov 13, 2009 at 04:17:35PM -0600, Brian West wrote: >> Raymond, >> I would like to thank Broadcom for their commitment to Open Source/ >> Royalty Free codecs. Following up on this trend we have now commited >> mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree. We have working >> autotooled/libtoolized floating point implementations which are >> downloaded and built static for these modules in FreeSWITCH. If >> Broadcom would setup an SVN I would be happy to provide build systems >> for mac/linux for both floating and fixed point codecs. >> >> On a sidenote.. x-lite's bv32 is busted and not workable so anyone >> doing >> any implementations please be warned it will NOT WORK. Hopefully >> someone >> from counterpath is paying attention. >> >> Thanks, >> Brian West >> FreeSWITCH.org >> PS: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=15464 > > That changeset is only the FreeSWITCH modules. > You also ommited from there the test data and test driver (bv16/ > bv.c) . > > After adding it, I see that the test fails: > > + cmp -s tv.bv16 ./tv.bv16.ref > + checksum=1 > + cmp -s tv.bv16.raw ./tv.bv16.ref.raw > + cmp -s tv.bv16.bfe10.raw ./tv.bv16.bfe10.ref.raw > + checksum=2 > > This means that the first encoding test fails, and likewise is the > last > encoding test. However encoding and decoding give the same reference > data (the second test that passed). --Apple-Mail-20-717668891 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = a small update it seems its a 32bit vs 64bit issue... unsigned long = bitword32; <-- LONG IS = EVIL.

/b

On Nov 14, 2009, at = 3:08 AM, Tzafrir Cohen wrote:

On Fri, Nov 13, 2009 at = 04:17:35PM -0600, Brian West wrote:
Raymond,
I would = like to thank Broadcom for their commitment to Open Source/ 
Royalty Free codecs.  Following up on this trend we = have now commited  
mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree.  We = have working  
autotooled/libtoolized floating point implementations = which are  
downloaded = and built static for these modules in FreeSWITCH.  If =  
Broadcom would setup an = SVN I would be happy to provide build systems =  
for mac/linux for both = floating and fixed point codecs.

On a sidenote.. = x-lite's bv32 is busted and not workable so anyone doing 
any implementations please be warned it will NOT WORK. =  Hopefully someone 
from counterpath is paying = attention.

Thanks,
Brian = West
FreeSWITCH.org
PS: ht= tp://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=3D15464

That changeset is only the FreeSWITCH modules. 
You also ommited from = there the test data and test driver (bv16/bv.c) .

After adding = it, I see that the test fails:

+ cmp -s tv.bv16 = ./tv.bv16.ref
+ checksum=3D1
+ cmp -s tv.bv16.raw = ./tv.bv16.ref.raw
+ cmp -s tv.bv16.bfe10.raw = ./tv.bv16.bfe10.ref.raw
+ checksum=3D2

This means that the = first encoding test fails, and likewise is the last
encoding test. = However encoding and decoding give the same reference
data (the = second test that = passed).

= --Apple-Mail-20-717668891-- From rob.glidden@sbcglobal.net Sat Nov 14 03:41: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 3633C3A68C4 for ; Sat, 14 Nov 2009 03:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 3PbVpsUTuLcv for ; Sat, 14 Nov 2009 03:41:49 -0800 (PST) Received: from smtp117.sbc.mail.re3.yahoo.com (smtp117.sbc.mail.re3.yahoo.com [66.196.96.90]) by core3.amsl.com (Postfix) with SMTP id 274FD3A6805 for ; Sat, 14 Nov 2009 03:41:49 -0800 (PST) Received: (qmail 72446 invoked from network); 14 Nov 2009 11:42:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Glaw0CWeig2VSYue5r1Jw/dsIvczbGD7ltvIz6T6KPx8h+swE+9U0jyfFb6oKQ4x85JchrGf2ZVyGMmf3B+akuQ7X4mYqnO57BYlg5G6L55FCr0tt6lXXcrgxmFRE/71S99T2Rw18tilyHnj92hgDvwKn9FhyuU9QbOyUDVwI08= ; Received: from (rob.glidden@201.65.177.98 with plain) by smtp117.sbc.mail.re3.yahoo.com with SMTP; 14 Nov 2009 03:42:17 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: gTuPYeIVM1khXt6BPT1Vq784nY7.brz7aaRvMTabuOpXPDXWe2LVDk74su11hxjkfTEPVP_78MMxjLzp9Yz0z58WSsSl2rnIV_vjUIDbzofAI7u2tKMBPLegRzHvuRE6EPIfmCry9SNH_R9g8ZQSkypQ4opqvVyLUSlPqM7vN3ZUI20bM5ifFjOokoe5evypS1ovk5THuZe7aog5m_K_R1NsYlTXyFYaCL6Cg4U3kOiWccktYfi92RCE2rqkAvhu7Fwx0iWPUiTOqUUx0PPGGyt1iZXy68f3fFKpE.kEpNss0UXVobpeTzYAdf2XpcSJK39zKiTvrwlO1PHJZgyjGKVdsg7lLB4idsNE7HAsBO6Thbun3KkRbe6kTHMG7hpQe2DxhqjtjuPG1nGuOAqCSjcQE6pKxeU2.00SDVxxSWrdNNOJMAkkKD1yiLwR748oMZ1DsSznoXLhMmvowGKr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFE9795.7030706@sbcglobal.net> Date: Sat, 14 Nov 2009 03:42:14 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Burger References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> In-Reply-To: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 14 Nov 2009 11:41:50 -0000 BTW I hear that in MPEG the Chinese National Body initiated a (re)consideration of royalty free standardization and MPEG has issued a call for comments to other national bodies. Someone may want to contact their national MPEG Head of Delegation or numerous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/. At the same time, MPEG is also considering launching new royalty bearing activities HVC (High Performance Video Coding) and MMT (Multimedia Transport). http://www.chiariglione.org/mpeg/working_documents.htm You may recall that h.264 was launched in 2001 as a joint project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the "JVT [Joint Video Team] will define a “baseline” profile. That profile should be royalty-free for all implementations." To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking. Rob Eric Burger wrote: > Thank you to everyone who participated in the room and remotely. We > succeeded in getting a lot of work done, and we have a sense of > whether or not we have a well-formed problem to solve, if there are > people who need the work product, if people are willing to work on it, > and if the IETF is an acceptable venue to do the work. In addition, we > learned a lot about the possibilities for cooperating with ITU-T SG 16. > > Please review the minutes and send corrections. > > The minutes are posted to: > http://www.ietf.org/proceedings/09nov/minutes/codec.txt > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From rob.glidden@sbcglobal.net Sun Nov 15 06:17: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 A4EF33A6975 for ; Sun, 15 Nov 2009 06:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 azGq5n01tKSJ for ; Sun, 15 Nov 2009 06:17:27 -0800 (PST) Received: from smtp116.sbc.mail.re3.yahoo.com (smtp116.sbc.mail.re3.yahoo.com [66.196.96.89]) by core3.amsl.com (Postfix) with SMTP id 3D8FD3A6936 for ; Sun, 15 Nov 2009 06:17:27 -0800 (PST) Received: (qmail 84920 invoked from network); 15 Nov 2009 14:17:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=3iDd7GAi7Di1Md/Z3LZDRxCc58WblkcqX0vsrYSOZRtDYp8uBs2fj0D0x7/tg7jsEDzhpUNtFDFroO+tneknUWVI/cJ8wXstQfbzLVQyHWHlK6/NSr6joXiu7ig+NX5rmvpjTGoACdfU/RwYU/s3kIYNwSyTXQM4QYACj5/by68= ; Received: from (rob.glidden@201.65.177.98 with plain) by smtp116.sbc.mail.re3.yahoo.com with SMTP; 15 Nov 2009 06:17:57 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: gFFtUAgVM1mI7aHAb7zSSyfSTS7lZNb70lb7GnWFRY7oCQi46T_eMtuWkXFjy2XlIustuau43IA0NFoQA5Z8xqduYXwzsRD7yAKNB8wi9qXGO7LtJmN0JxXSZpXBd4WOZL.MFnM6mrqEsJGL8t.g4l5zP3lM6YT36YPmpWyAlhyeE3RG2Ice7tyZuzxJ993rf2HOQcRm7mrcMtodwW.hGM9WDFDxlgaBhGUkNePWxKyLrn9cTPcAYhBBfuECPvC_pa8wYlFEb7Hl4rA0z2oMYT1PR7TtXPc5tlVDxvH9lUtM9ATBM6Qm0uC6db9bzGy5wCvKG.JdDux2YmEHIaqDTJCvw91Z7VqlPifsGQnp8KS2cqDdgTyBne4xhk96xQc_RXYVoHXaROMDL4b7i253vfxEYx5s91q.gQmc_NZa9jPS2a_RZ4cFXLGlo8EF99DzkuSW1Bpx_okeEn2I3j2S X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B000D91.1010705@sbcglobal.net> Date: Sun, 15 Nov 2009 06:17:53 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Burger References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> In-Reply-To: <4AFE9795.7030706@sbcglobal.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Nov 2009 14:17:28 -0000 BTW, see November 10, 2009 "Preliminary call for proposals signals work start for H.264/MPEG-4 AVC successor" (ie HVC): http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx Any "h.264 successor" type work (audio/video/transport) should complete, not drop, the 2001 royalty free undertaking. IETF and ITU-T should lead/support to royalty-free, not give up or hide in a niche, nor let vested interests run process into slow failure. See: http://www.cafc.uscourts.gov/opinions/07-1545.pdf The process was enforceable, and enforced. Patents could have been found earlier, and removed. Rob Rob Glidden wrote: > BTW I hear that in MPEG the Chinese National Body initiated a > (re)consideration of royalty free standardization and MPEG has issued > a call for comments to other national bodies. > > Someone may want to contact their national MPEG Head of Delegation or > numerous liaisons including IETF, listed at > http://www.itscj.ipsj.or.jp/sc29/. > > At the same time, MPEG is also considering launching new royalty > bearing activities HVC (High Performance Video Coding) and MMT > (Multimedia Transport). > http://www.chiariglione.org/mpeg/working_documents.htm > > You may recall that h.264 was launched in 2001 as a joint project > between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the > undertaking that the "JVT [Joint Video Team] will define a “baseline” > profile. That profile should be royalty-free for all implementations." > To date neither ITU-T nor MPEG have ever delivered on this royalty > free undertaking. > > Rob > > Eric Burger wrote: >> Thank you to everyone who participated in the room and remotely. We >> succeeded in getting a lot of work done, and we have a sense of >> whether or not we have a well-formed problem to solve, if there are >> people who need the work product, if people are willing to work on >> it, and if the IETF is an acceptable venue to do the work. In >> addition, we learned a lot about the possibilities for cooperating >> with ITU-T SG 16. >> >> Please review the minutes and send corrections. >> >> The minutes are posted to: >> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >> _______________________________________________ >> 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 Nov 15 13:55: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 28DAF3A6A0F for ; Sun, 15 Nov 2009 13:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 9+SCZHkfPSv8 for ; Sun, 15 Nov 2009 13:55:03 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 37C683A677D for ; Sun, 15 Nov 2009 13:55:00 -0800 (PST) Received: by fxm7 with SMTP id 7so5162637fxm.29 for ; Sun, 15 Nov 2009 13:54:59 -0800 (PST) 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=0N98IBMJU4FZzWQVdde+SmCWB430AyvT1FK+sCDV21k=; b=SskKolYDr7TRi1dmn9M8vkiKgx6gaJjnaRlIiRbAFb7Ytpri/DI1FWXtnaw8DnOSYJ tqondVOXHAEEj6vuNj4k32m+AQU5wO/3iVzMWLFm1VZQgU1lMi7oU0nW54jvnJBCpQSP dG2P5J8/lPgMCOW41EnEpWWlTSSnf9N0qbOcI= 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=K0RMxqVvklLJNCAbuw5M938LlSskn46NC3/68g/7pCGWJyZNHiITfOOhpJgUZuEwr/ Hj95StZpUKdtKy5w/xlI0VHQki4VsTdPA8H6FVXc7NLlcgiaBhSsN4I9HeUZ1rK5FOjD +T9IQlVUfFN45NnO93UljkFkMSDTdsWPwgFB4= MIME-Version: 1.0 Received: by 10.103.7.31 with SMTP id k31mr3229382mui.48.1258322099166; Sun, 15 Nov 2009 13:54:59 -0800 (PST) In-Reply-To: <4B00099D.7040201@sbcglobal.net> References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> Date: Sun, 15 Nov 2009 16:54:59 -0500 Message-ID: <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> From: stephen botzko To: Rob Glidden , codec@ietf.org Content-Type: multipart/alternative; boundary=001636417485bbdeb304786ff1fe Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Nov 2009 21:55:05 -0000 --001636417485bbdeb304786ff1fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Stephan Wenger indicated, it is not clear if the JVT actually failed or not. What is clear is that they did everything they reasonably could have done. There were several folks participating who took the royalty-free baseline profile objective very seriously. Again, all submitted IPR for the baseline tools indicated royalty free terms. So the JVT had every reason to think they had succeeded. By the time this IPR turned up, H.264 had been standardized for over 2 years. H.264 implementations were already out there - so any attempts to do work-arounds would have broken existing implementations (including implementations in silicon). Certainly any existing IETF group would have presumed exactly the same thin= g the JVT did. The lesson here is that even if the SDO is conscientious, an unencumbered codec can not be guaranteed. I don't see any other way to read this. Stephen Botzko Polycom On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden wro= te: > stephen botzko wrote: > > >>> > To date neither ITU-T nor MPEG have ever delivered on this royalty free > undertaking. > >>> > That should be viewed as very *bad* news here, since all the IPR > declarations in JVT for the baseline tools indicated royalty free terms. = In > other words, the SDOs did everything possible to deliver, and when H.264 > baseline was standardized they thought they had succeeded. > > I'd suggest that it is hard to see things this way after reading > > http://www.cafc.uscourts.gov/opinions/07-1545.pdf > > The process was enforceable, and enforced. > The patents could have been found earlier, and removed. > > So any "h.264 successor" type work (audio/video/transport) should complet= e, > not drop, the royalty free undertaking. IETF and ITU-T should lead there= , > not give up or hide in a niche. > > See November 10, 2009 "Preliminary call for proposals signals work start > for H.264/MPEG-4 AVC successor" > > > http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+W= ork+Start+For+H264MPEG4+AVC+Successor.aspx > > Rob > > > Stephen Botzko > Polycom. > > > > On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden w= rote: > >> BTW I hear that in MPEG the Chinese National Body initiated a >> (re)consideration of royalty free standardization and MPEG has issued a = call >> for comments to other national bodies. >> >> Someone may want to contact their national MPEG Head of Delegation or >> numerous liaisons including IETF, listed at >> http://www.itscj.ipsj.or.jp/sc29/. >> >> At the same time, MPEG is also considering launching new royalty bearing >> activities HVC (High Performance Video Coding) and MMT (Multimedia >> Transport). http://www.chiariglione.org/mpeg/working_documents.htm >> >> You may recall that h.264 was launched in 2001 as a joint project betwee= n >> ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that th= e >> "JVT [Joint Video Team] will define a =93baseline=94 profile. That profi= le >> should be royalty-free for all implementations." To date neither ITU-T n= or >> MPEG have ever delivered on this royalty free undertaking. >> >> Rob >> >> Eric Burger wrote: >> >>> Thank you to everyone who participated in the room and remotely. We >>> succeeded in getting a lot of work done, and we have a sense of whether= or >>> not we have a well-formed problem to solve, if there are people who nee= d the >>> work product, if people are willing to work on it, and if the IETF is a= n >>> acceptable venue to do the work. In addition, we learned a lot about th= e >>> possibilities for cooperating with ITU-T SG 16. >>> >>> Please review the minutes and send corrections. >>> >>> The minutes are posted to: >>> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >>> _______________________________________________ >>> 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 >> > > > --001636417485bbdeb304786ff1fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Stephan Wenger indicated, it is not clear if the JVT actually failed or = not.=A0 What is clear is that they did everything they reasonably could hav= e done.=A0 There were several folks participating who took the royalty-free= baseline profile objective very seriously.

Again, all submitted IPR for the baseline tools indicated royalty free = terms.=A0 So the JVT had every reason to think they had succeeded.=A0=A0=A0= By the time this IPR turned up, H.264 had been standardized for over 2 yea= rs.=A0 H.264 implementations were already out there - so any attempts to do= work-arounds would have broken existing implementations (including impleme= ntations in silicon).=A0

Certainly any existing IETF group would have presumed exactly the same = thing the JVT did.=A0 The lesson here is that even if the SDO is conscienti= ous, an unencumbered codec can not be guaranteed. I don't see any other= way to read this.

Stephen Botzko
Polycom


On Sun,= Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrot= e:
=20
stephen botzko wrote:
>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
>>>
That should be viewed as very bad news here, since all the IPR declarations in JVT for the baseline tools indicated royalty free terms. In other words, the SDOs did everything possible to deliver, and when H.264 baseline was standardized they thought they had succeeded.
I'd suggest that it is hard to see things this way after reading

http://www.cafc.uscourts.gov/opinions/07-1545.pdf

The process was enforceable, and enforced.
The patents could have been found earlier, and removed.

So any "h.264 successor" type work (audio/video/transport) should complete, not drop, the royalty free undertaking.=A0 IETF and ITU-T should lead there, not give up or hide in a niche.

See November 10, 2009 "Preliminary call for proposals signals work start for H.264/MPEG-4 AVC successor"

http= ://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+St= art+For+H264MPEG4+AVC+Successor.aspx

Rob


Stephen Botzko
Polycom.=A0

=A0

On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
BTW I hear that in MPEG the Chinese National Body initiated a (re)consideration of royalty free standardization and MPEG has issued a call for comments to other national bodies.

Someone may want to contact their national MPEG Head of Delegation or numerous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.

At the same time, MPEG is also considering launching new royalty bearing activities HVC (High Performance Video Coding) and MMT (Multimedia Transport). http://www.chiariglione.org/mpeg/working_= documents.htm

You may recall that h.264 was launched in 2001 as a joint project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the "JVT [Joint Video Team] will define a =93baseline= =94 profile. That profile should be royalty-free for all implementations." To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.

Rob

Eric Burger wrote:
Thank you to everyone who participated in the room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need the work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16.

Please review the minutes and send corrections.

The minutes are posted to:
http://www.ietf.org/proceedings/09nov/minutes/codec.txt
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec


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



--001636417485bbdeb304786ff1fe-- From rob.glidden@sbcglobal.net Sun Nov 15 15: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 4C97F3A688E for ; Sun, 15 Nov 2009 15:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.459 X-Spam-Level: * X-Spam-Status: No, score=1.459 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shdLcahZ6XgO for ; Sun, 15 Nov 2009 15:17:57 -0800 (PST) Received: from smtp117.sbc.mail.re3.yahoo.com (smtp117.sbc.mail.re3.yahoo.com [66.196.96.90]) by core3.amsl.com (Postfix) with SMTP id B2FEF3A685E for ; Sun, 15 Nov 2009 15:17:56 -0800 (PST) Received: (qmail 8815 invoked from network); 15 Nov 2009 23:17:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Nfl8F9NVUUFbEwkLCL/rKj0hWOgRYSs/MvQ7Y/VhNX+D0wn38/eCY91K5fyG47m0i+xUhmy0A/jhfj1c+LPWyAfoNm3ysEAldiwSegNwJZE1an/F2tNQgLWnP7h04k45XKBuq3Q6j3A0FQY0fYuNUm3CDYE4vWLfINLu3CUb7gE= ; Received: from (rob.glidden@201.65.177.98 with plain) by smtp117.sbc.mail.re3.yahoo.com with SMTP; 15 Nov 2009 15:17:53 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: gIp2k0kVM1l_SBRhllsuwan9Fu0DKehzH.6lrkzeXlThiPoFO2bxmMjRWzY1C9XGnohNidAovrSuQNqRGJVVOC0WBIf8t4G29d3c9pgxkVfJRbfuBrC3sTkBS_kXePrGXVotYo_Pkjk5fC9f5nWFRdlAuzmtjmEhfRKtAec4LDPQ4Ah_T.kvs.gWeBLggIgkQmIUeYAH2DnHzzRm0OITUXlfYFrIFvCYvDxynAl7s6aHfV2S.NurPceZ.bPtmvWUrFUvpDB1D3hujbPotNiSL30BlPm4eanEWA0_eq5bIPDgJnpFlax7PXcM9Q6H8jHpmDW7zRbqmE783hEAmO5jR2vuuauj0rrZ8JMTPVF3wgqUXKd18_RXJgvdphTGJzYmArJLAOXeZYrZMzPS13cNF0fDC5lHc3WEC7XMeoARtkL_eBaMDCGojs2h43EA2W3QP0jGy7OMTQp_5CvuxCEA_RY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B008C19.6010905@sbcglobal.net> Date: Sun, 15 Nov 2009 15:17:45 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: codec@ietf.org References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> In-Reply-To: <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Nov 2009 23:17:58 -0000 There is another way to read this.

This case has been called "the most infamous discovery fiasco in recent times":

- The lawyers were sanctioned
- The patents were held both unenforceable and inapplicable
- Fines were levied
- The law firm crumbled and was sold

But read the case:  these were not patents that turned up two years later.  The two were issued and therefore public in 1995 and 1996 (5 years before the JVT), and had been presented to the MPEG committee before.

Going forward, a more proactive ex ante assessment of known patents, at least of the participants in the activity, rather than just relying on statements, would be good practice to check for blocking patents.

But yes, you are right the court did not blame the JVT process and certainly not those who took the royalty-free objective seriously.  Clearly not everyone shared that goal, and got caught in subverting it.

But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than just keep presuming that such things never occur and accept being blind sided, and has tightened its IPR policy (which provides for third-parties coming forward with blocking info).

And yes, any one can sue about anything, and they can lie about their participation in a standards group.  They can fail to disclose.  They can assert patents that end up being ruled as inapplicable.  Maybe they will get away with it, or maybe as in this case they won't.

But that isn't a good reason to fail to develop the standards the Web needs for its open, royalty-free future.  Rather, the opposite. If it takes this kind of extreme behavior and it still doesn't work, then time to keep moving forward with royalty-free standardization.

Rob

http://www.law.com/jsp/article.jsp?id=1202435137932

"Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

"Lawyers in the Qualcomm discovery scandal claim that the company misled and stonewalled them, ultimately leading to the failure to turn over a mountain of relevant evidence and harsh sanctions from the court."

The allegations were made in briefs filed Monday by lawyers from the now-defunct Day Casebeer Batchelder & Madrid, who for the first time are telling their side of what has become the most infamous discovery fiasco in recent times.

Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major in January 2008 for intentionally withholding "tens of thousands of e-mails" in an infringement case against Broadcom Corp. involving video compression technology patents. The company's lawyers -- six from Day Casebeer and one from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in committing this incredible discovery violation," either knowingly or recklessly, Major wrote at the time."


stephen botzko wrote:
As Stephan Wenger indicated, it is not clear if the JVT actually failed or not.  What is clear is that they did everything they reasonably could have done.  There were several folks participating who took the royalty-free baseline profile objective very seriously.

Again, all submitted IPR for the baseline tools indicated royalty free terms.  So the JVT had every reason to think they had succeeded.    By the time this IPR turned up, H.264 had been standardized for over 2 years.  H.264 implementations were already out there - so any attempts to do work-arounds would have broken existing implementations (including implementations in silicon). 

Certainly any existing IETF group would have presumed exactly the same thing the JVT did.  The lesson here is that even if the SDO is conscientious, an unencumbered codec can not be guaranteed. I don't see any other way to read this.

Stephen Botzko
Polycom


On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
stephen botzko wrote:
>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
>>>
That should be viewed as very bad news here, since all the IPR declarations in JVT for the baseline tools indicated royalty free terms. In other words, the SDOs did everything possible to deliver, and when H.264 baseline was standardized they thought they had succeeded.
I'd suggest that it is hard to see things this way after reading

http://www.cafc.uscourts.gov/opinions/07-1545.pdf

The process was enforceable, and enforced.
The patents could have been found earlier, and removed.

So any "h.264 successor" type work (audio/video/transport) should complete, not drop, the royalty free undertaking.  IETF and ITU-T should lead there, not give up or hide in a niche.

See November 10, 2009 "Preliminary call for proposals signals work start for H.264/MPEG-4 AVC successor"

http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

Rob


Stephen Botzko
Polycom. 

 

On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
BTW I hear that in MPEG the Chinese National Body initiated a (re)consideration of royalty free standardization and MPEG has issued a call for comments to other national bodies.

Someone may want to contact their national MPEG Head of Delegation or numerous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.

At the same time, MPEG is also considering launching new royalty bearing activities HVC (High Performance Video Coding) and MMT (Multimedia Transport). http://www.chiariglione.org/mpeg/working_documents.htm

You may recall that h.264 was launched in 2001 as a joint project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the "JVT [Joint Video Team] will define a “baseline” profile. That profile should be royalty-free for all implementations." To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.

Rob

Eric Burger wrote:
Thank you to everyone who participated in the room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need the work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16.

Please review the minutes and send corrections.

The minutes are posted to:
http://www.ietf.org/proceedings/09nov/minutes/codec.txt
_______________________________________________
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 Sun Nov 15 16:35: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 025F43A67D8 for ; Sun, 15 Nov 2009 16:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 eR+Qc8FZx6PX for ; Sun, 15 Nov 2009 16:35:47 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id EF5083A676A for ; Sun, 15 Nov 2009 16:35:43 -0800 (PST) Received: from [192.168.1.111] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 491569-1743317 for multiple; Mon, 16 Nov 2009 01:35:38 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 15 Nov 2009 16:35:19 -0800 From: Stephan Wenger To: Rob Glidden , Message-ID: Thread-Topic: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted Thread-Index: AcpmVKxz+60Jifn09Eu/YY/9CBL9YA== In-Reply-To: <4B008C19.6010905@sbcglobal.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341147737_3673071" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Nov 2009 00:35:59 -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_3341147737_3673071 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Rob, I will not comment more on the BC/QC San Diego case, except to say that misconduct before the standardization committee (violation of both written and de-facto practiced rules of the committee) was only one and, as some people have argued, small factor in the ruling. I wish one could come to the conclusion that any misconduct before a standardization committee would automatically render related patents unenforceable (the inapplicable part i= s a very different story), but I fear that this is too much to hope for. My current view of the likeliness of success of Codec in relation to JVT=B9s success or failure (depending whom you ask): 1. JVT took on the creation a royalty-free baseline (that is, a part of a standard only, and rightholders may still require a signed license that may be encumbered to the point where it becomes unusable for some open source communities=8Bclearly a factor for some software companies), in a heavily patented field. The vast majority of the participating companies=8Benough to create a consensus-based decision in the committee, and many of them known or likely future rightholders=8Bwas in support of that goal. 2. Codec attempts to take on of creating a standard (not only a baseline of a standard=8Brightholders cannot be appeased by arguing they can make money from non-baseline applications) under what the BOF chairs called =B3acceptabl= e terms=B2--which translate to an open-source friendly non-assert requirement. The field of technology is at least as heavily patented as video. A significant percentage of companies known to hold a sizeable portfolio of audio/speech codec patents have spoken quite clearly against the goal. It=B9= s not up to me to declare an IETF consensus on whether acceptable terms are achievable, but if someone were a declaring such a consensus, I would object=8Band I=B9m sure I would not be alone. In fact, =B3acceptable terms=B2, by policy cannot and will not be a hard requirement for the work of a hypothetical codec WG. Based on these perceptions and facts it seems obvious that it=B9s going to be much harder to achieve=8Bthat is also: easier to prevent for those not amicable=8Bthe goals of a hypothetical codec WG when compared to the goals of JVT. =20 Regards, Stephan On 11/15/09 3:17 PM, "Rob Glidden" wrote: > There is another way to read this. >=20 > This case has been called "the most infamous discovery fiasco in recent > times": >=20 > - The lawyers were sanctioned > - The patents were held both unenforceable and inapplicable > - Fines were levied > - The law firm crumbled and was sold >=20 > But read the case:=A0 these were not patents that turned up two years later= .=A0 > The two were issued and therefore public in 1995 and 1996 (5 years before= the > JVT), and had been presented to the MPEG committee before. >=20 > Going forward, a more proactive ex ante assessment of known patents, at l= east > of the participants in the activity, rather than just relying on statemen= ts, > would be good practice to check for blocking patents. >=20 > But yes, you are right the court did not blame the JVT process and certai= nly > not those who took the royalty-free objective seriously.=A0 Clearly not eve= ryone > shared that goal, and got caught in subverting it. >=20 > But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than jus= t > keep presuming that such things never occur and accept being blind sided,= and > has tightened its IPR policy (which provides for third-parties coming for= ward > with blocking info). >=20 > And yes, any one can sue about anything, and they can lie about their > participation in a standards group.=A0 They can fail to disclose.=A0 They can > assert patents that end up being ruled as inapplicable.=A0 Maybe they will = get > away with it, or maybe as in this case they won't. >=20 > But that isn't a good reason to fail to develop the standards the Web nee= ds > for its open, royalty-free future.=A0 Rather, the opposite. If it takes thi= s > kind of extreme behavior and it still doesn't work, then time to keep mov= ing > forward with royalty-free standardization. >=20 > Rob >=20 > http://www.law.com/jsp/article.jsp?id=3D1202435137932 >=20 > "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >=20 > "Lawyers in the Qualcomm discovery scandal claim that the company misled = and > stonewalled them, ultimately leading to the failure to turn over a mounta= in of > relevant evidence and harsh sanctions from the court." >=20 > The allegations were made in briefs filed Monday by lawyers from the > now-defunct Day Casebeer Batchelder & Madrid > , who for the first= time > are telling their side of what has become the most infamous discovery fia= sco > in recent times=20 > = . >=20 > Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major = in > January 2008 for intentionally withholding "tens of thousands of e-mails"= in > an infringement case against Broadcom Corp. involving video compression > technology patents. The company's lawyers -- six from Day Casebeer and on= e > from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in > committing this incredible discovery violation," either knowingly or > recklessly, Major wrote at the time." >=20 > stephen botzko wrote: >> As Stephan Wenger indicated, it is not clear if the JVT actually failed = or >> not.=A0 What is clear is that they did everything they reasonably could ha= ve >> done.=A0 There were several folks participating who took the royalty-free >> baseline profile objective very seriously. >> =20 >> Again, all submitted IPR for the baseline tools indicated royalty free >> terms.=A0 So the JVT had every reason to think they had succeeded.=A0=A0=A0 By t= he >> time this IPR turned up, H.264 had been standardized for over 2 years.=A0 = H.264 >> implementations were already out there - so any attempts to do work-arou= nds >> would have broken existing implementations (including implementations in >> silicon).=A0=20 >> =20 >> Certainly any existing IETF group would have presumed exactly the same t= hing >> the JVT did.=A0 The lesson here is that even if the SDO is conscientious, = an >> unencumbered codec can not be guaranteed. I don't see any other way to r= ead >> this. >> =20 >> Stephen Botzko >> Polycom >> =20 >> =20 >> =20 >> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >> wrote: >> =20 >>> =20 >>> =20 >>> stephen botzko wrote: >>>>>>> >>> >>>> To date neither ITU-T nor MPEG have ever delivered on this royalty fre= e >>>> undertaking. >>>>>>> >>> >>>> That should be viewed as very bad news here, since all the IPR declara= tions >>>> in JVT for the baseline tools indicated royalty free terms. In other w= ords, >>>> the SDOs did everything possible to deliver, and when H.264 baseline w= as >>>> standardized they thought they had succeeded. >>>> =20 >>> =20 >>> I'd suggest that it is hard to see things this way after reading >>> =20 >>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>> =20 >>> The process was enforceable, and enforced. >>> The patents could have been found earlier, and removed. >>> =20 >>> So any "h.264 successor" type work (audio/video/transport) should compl= ete, >>> not drop, the royalty free undertaking.=A0 IETF and ITU-T should lead the= re, >>> not give up or hide in a niche. >>> =20 >>> See November 10, 2009 "Preliminary call for proposals signals work star= t for >>> H.264/MPEG-4 AVC successor" >>> =20 >>> =20 >>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals= +Work >>> +Start+For+H264MPEG4+AVC+Successor.aspx >>> =20 >>> Rob=20 >>>=20 >>> =20 >>> =20 >>>> Stephen Botzko >>>> Polycom.=A0=20 >>>> =20 >>>> =A0 >>>> =20 >>>> =20 >>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >>>> wrote: >>>> =20 >>>>> BTW I hear that in MPEG the Chinese National Body initiated a >>>>> (re)consideration of royalty free standardization and MPEG has issued= a >>>>> call for comments to other national bodies. >>>>> =20 >>>>> Someone may want to contact their national MPEG Head of Delegation or >>>>> numerous liaisons including IETF, listed at >>>>> http://www.itscj.ipsj.or.jp/sc29/. >>>>> =20 >>>>> At the same time, MPEG is also considering launching new royalty bear= ing >>>>> activities HVC (High Performance Video Coding) and MMT (Multimedia >>>>> Transport). http://www.chiariglione.org/mpeg/working_documents.htm >>>>> =20 >>>>> You may recall that h.264 was launched in 2001 as a joint project bet= ween >>>>> ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that= the >>>>> "JVT [Joint Video Team] will define a =B3baseline=B2 profile. That profil= e >>>>> should be royalty-free for all implementations." To date neither ITU-= T nor >>>>> MPEG have ever delivered on this royalty free undertaking. >>>>> =20 >>>>> Rob >>>>> =20 >>>>> Eric Burger wrote: >>>>> =20 >>>>>> Thank you to everyone who participated in the room and remotely. We >>>>>> succeeded in getting a lot of work done, and we have a sense of whet= her >>>>>> or not we have a well-formed problem to solve, if there are people w= ho >>>>>> need the work product, if people are willing to work on it, and if t= he >>>>>> IETF is an acceptable venue to do the work. In addition, we learned = a lot >>>>>> about the possibilities for cooperating with ITU-T SG 16. >>>>>> =20 >>>>>> Please review the minutes and send corrections. >>>>>> =20 >>>>>> The minutes are posted to: >>>>>> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >>>>>> _______________________________________________ >>>>>> 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 >>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >> =20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3341147737_3673071 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes &nb= sp;Posted Hi Rob,

I will not comment more on the BC/QC San Diego case, except to say that mis= conduct before the standardization committee (violation of both written and = de-facto practiced rules of the committee) was only one and, as some people = have argued, small factor in the ruling.  I wish one could come to the = conclusion that any misconduct before a standardization committee would auto= matically render related patents unenforceable (the inapplicable part is a v= ery different story), but I fear that this is too much to hope for.

My current view of the likeliness of success of Codec in relation to JVT= 217;s success or failure (depending whom you ask):
  1. JVT took on the creation a royalty-free ba= seline (that is, a part of a standard only, and rightholders may still r= equire a signed license that may be encumbered to the point where it becomes= unusable for some open source communities—clearly a factor for some s= oftware companies), in a heavily patented field.  The vast major= ity of the participating companies—enough to create a consensus-based = decision in the committee, and many of them known or likely future righthold= ers—was in support of that goal.=20
  2. Codec attempts to take on of creating a standard = (not only a baseline of a standard—rightholders cannot be appeased by = arguing they can make money from non-baseline applications) under what the B= OF chairs called “acceptable terms”--which translate to an op= en-source friendly non-assert requirement.  The field of technology= is at least as heavily patented as video.  A significant per= centage of companies known to hold a sizeable portfolio of audio/speech = codec patents have spoken quite clearly against the goal.  It= 217;s not up to me to declare an IETF consensus on whether acceptable terms = are achievable, but if someone were a declaring such a consensus, I would ob= ject—and I’m sure I would not be alone.  In fact, “ac= ceptable terms”, by policy cannot and will not be a hard requirement f= or the work of a hypothetical codec WG.
Based on these perceptions and facts it seems obvious t= hat it’s going to be much harder to achieve—that is also: easier= to prevent for those not amicable—the goals of a hypothetical codec W= G when compared to the goals of JVT.  
Regards,
Stephan


On 11/15/09 3:17 PM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>There is another way to read this.

This case has been called "the most infamous discovery fiasco in recen= t times":

- The lawyers were sanctioned
- The patents were held both unenforceable and inapplicable
- Fines were levied
- The law firm crumbled and was sold

But read the case:=A0 these were not patents that turned up two years later.=A0= The two were issued and therefore public in 1995 and 1996 (5 years before t= he JVT), and had been presented to the MPEG committee before.

Going forward, a more proactive ex ante assessment of known patents, at lea= st of the participants in the activity, rather than just relying on statemen= ts, would be good practice to check for blocking patents.

But yes, you are right the court did not blame the JVT process and certainl= y not those who took the royalty-free objective seriously.=A0 Clearly not ever= yone shared that goal, and got caught in subverting it.

But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than just = keep presuming that such things never occur and accept being blind sided, an= d has tightened its IPR policy (which provides for third-parties coming forw= ard with blocking info).

And yes, any one can sue about anything, and they can lie about their parti= cipation in a standards group.=A0 They can fail to disclose.=A0 They can assert = patents that end up being ruled as inapplicable.=A0 Maybe they will get away w= ith it, or maybe as in this case they won't.

But that isn't a good reason to fail to develop the standards the Web needs= for its open, royalty-free future.=A0 Rather, the opposite. If it takes this = kind of extreme behavior and it still doesn't work, then time to keep moving= forward with royalty-free standardization.

Rob

http://www.la= w.com/jsp/article.jsp?id=3D1202435137932

"Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 200= 9

"Lawyers in the Qualcomm discovery scandal claim that the company misl= ed and stonewalled them, ultimately leading to the failure to turn over a mo= untain of relevant evidence and harsh sanctions from the court."

The allegations were made in briefs filed Monday by lawyers from the now-de= funct Day Casebeer Batchelder & Madrid <http://www.law.com/jsp/article.jsp?id=3D12024= 31679659> , who for the first time are telling their side of what has= become the most infamous discovery fiasco in recent times <http://= www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D900005504954> . <= BR>
Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major in= January 2008 for intentionally withholding "tens of thousands of e-mai= ls" in an infringement case against Broadcom Corp. involving video comp= ression technology patents. The company's lawyers -- six from Day Casebeer a= nd one from Heller Ehrman -- were also sanctioned for assisting "Qualco= mm in committing this incredible discovery violation," either knowingly= or recklessly, Major wrote at the time."

stephen botzko wrote:
<= SPAN STYLE=3D'font-size:11pt'>As Stephan Wenger indicated, it is not clear if = the JVT actually failed or not.=A0 What is clear is that they did everything t= hey reasonably could have done.=A0 There were several folks participating who = took the royalty-free baseline profile objective very seriously.
 
Again, all submitted IPR for the baseline tools indicated royalty free term= s.=A0 So the JVT had every reason to think they had succeeded.=A0=A0=A0 By the time = this IPR turned up, H.264 had been standardized for over 2 years.=A0 H.264 imp= lementations were already out there - so any attempts to do work-arounds wou= ld have broken existing implementations (including implementations in silico= n).=A0
 
Certainly any existing IETF group would have presumed exactly the same thin= g the JVT did.=A0 The lesson here is that even if the SDO is conscientious, an= unencumbered codec can not be guaranteed. I don't see any other way to read= this.
 
Stephen Botzko
Polycom
 
 
 
On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 
<= SPAN STYLE=3D'font-size:11pt'>
 
stephen botzko wrote:
<= SPAN STYLE=3D'font-size:11pt'>>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free und= ertaking.
>>>
That should be viewed as very bad news here, since all the IPR decla= rations in JVT for the baseline tools indicated royalty free terms. In other= words, the SDOs did everything possible to deliver, and when H.264 baseline= was standardized they thought they had succeeded.
 
=
I'd suggest that it is hard to see things this way after reading
 
 http://ww= w.cafc.uscourts.gov/opinions/07-1545.pdf
 
The process was enforceable, and enforced.
The patents could have been found earlier, and removed.
 
So any "h.264 successor" type work (audio/video/transport) should= complete, not drop, the royalty free undertaking.=A0 IETF and ITU-T should le= ad there, not give up or hide in a niche.
 
See November 10, 2009 "Preliminary call for proposals signals work sta= rt for H.264/MPEG-4 AVC successor"
 
 http://www.itu.int/= ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG= 4+AVC+Successor.aspx
 
Rob

 
 
<= SPAN STYLE=3D'font-size:11pt'>Stephen Botzko
Polycom.=A0
 
=A0
 
 
On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 
<= SPAN STYLE=3D'font-size:11pt'>BTW I hear that in MPEG the Chinese National Bod= y initiated a (re)consideration of royalty free standardization and MPEG has= issued a call for comments to other national bodies.
 
Someone may want to contact their national MPEG Head of Delegation or numer= ous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.
 
At the same time, MPEG is also considering launching new royalty bearing ac= tivities HVC (High Performance Video Coding) and MMT (Multimedia Transport).= http://www= .chiariglione.org/mpeg/working_documents.htm
 
You may recall that h.264 was launched in 2001 as a joint project between I= TU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the &qu= ot;JVT [Joint Video Team] will define a “baseline” profile. That= profile should be royalty-free for all implementations." To date neith= er ITU-T nor MPEG have ever delivered on this royalty free undertaking.
 
Rob
 
Eric Burger wrote:
 
<= SPAN STYLE=3D'font-size:11pt'>Thank you to everyone who participated in the ro= om and remotely. We succeeded in getting a lot of work done, and we have a s= ense of whether or not we have a well-formed problem to solve, if there are = people who need the work product, if people are willing to work on it, and i= f the IETF is an acceptable venue to do the work. In addition, we learned a = lot about the possibilities for cooperating with ITU-T SG 16.
 
Please review the minutes and send corrections.
 
The minutes are posted to:
 htt= p://www.ietf.org/proceedings/09nov/minutes/codec.txt
_______________________________________________
codec mailing list
 codec@ietf.org
 https://www.iet= f.org/mailman/listinfo/codec
 
 
=
_______________________________________________
codec mailing list
 codec@ietf.org
 https://www.iet= f.org/mailman/listinfo/codec
 
=
 
 
=
 
 
 
=
 
=

___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3341147737_3673071-- From koen.vos@skype.net Sun Nov 15 18:03: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 0FB5B3A68F6 for ; Sun, 15 Nov 2009 18:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_50=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 cWwYcUQrxT0e for ; Sun, 15 Nov 2009 18:03:44 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id A0CD13A6877 for ; Sun, 15 Nov 2009 18:03:43 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C5C786065B9C6; Mon, 16 Nov 2009 02:03:39 +0000 (GMT) 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=oMlyPYaUBZbJ KJWcvhdtxkNhpMA=; b=qXk5vzx9esa7iIlyFQo+eOc9tiJQuhGS4l8xc6eRJxqI 7fTD6ZMozvOeeuYxfhp1Ggq5feDH36fEeA9JF8U3oD2SE8aJBVWX+5HHmMiBcb/A MjmrgFc9DBZlj9/HjmCZ0B8vea1i8vFbMbmVWOIwgW7ODea3VYUNnplDjj3HEnY= 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=Y+i5xD+IMm7bhpJavZtt u+K56KOqW8lEuIXGrK1L/xnTSM+gXj4Fi3sqPGqWKYIEBpX2aQ0OMIEM6m65smvF JjWTfiOynIG6i5hw54xx6/Zzk4q6HuQ2fKuKxIrptktU02mJE78GsSIvYSgdWSGl vDF9ge/W5P5hH+HbAcVemFI= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C3B486064F3EE; Mon, 16 Nov 2009 02:03:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06-tvyTqmUJC; Mon, 16 Nov 2009 02:03:30 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 430026065BA01; Mon, 16 Nov 2009 02:03:30 +0000 (GMT) Received: from 218.45.224.130 ([218.45.224.130]) by mail.skype.net (Horde Framework) with HTTP; Sun, 15 Nov 2009 18:03:30 -0800 Message-ID: <20091115180330.36951poxzqokdrzm@mail.skype.net> Date: Sun, 15 Nov 2009 18:03:30 -0800 From: Koen Vos To: Stephan Wenger References: 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: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Nov 2009 02:03:46 -0000 > The field of technology is at least as heavily patented as video. I disagree on this point - a larger fraction of patents in speech and =20 audio coding have expired. The field has made relatively little =20 progress in the past 20 years, compared to video. koen. Quoting Stephan Wenger : > Hi Rob, > > I will not comment more on the BC/QC San Diego case, except to say that > misconduct before the standardization committee (violation of both written > and de-facto practiced rules of the committee) was only one and, as some > people have argued, small factor in the ruling. I wish one could come to > the conclusion that any misconduct before a standardization committee woul= d > automatically render related patents unenforceable (the inapplicable part = is > a very different story), but I fear that this is too much to hope for. > > My current view of the likeliness of success of Codec in relation to JVT= =B9s > success or failure (depending whom you ask): > 1. JVT took on the creation a royalty-free baseline (that is, a part of a > standard only, and rightholders may still require a signed license that ma= y > be encumbered to the point where it becomes unusable for some open source > communities=8Bclearly a factor for some software companies), in a heavily > patented field. The vast majority of the participating companies=8Benough= to > create a consensus-based decision in the committee, and many of them known > or likely future rightholders=8Bwas in support of that goal. > 2. Codec attempts to take on of creating a standard (not only a baseline o= f > a standard=8Brightholders cannot be appeased by arguing they can make mone= y > from non-baseline applications) under what the BOF chairs called =B3accept= able > terms=B2--which translate to an open-source friendly non-assert requiremen= t. > The field of technology is at least as heavily patented as video. A > significant percentage of companies known to hold a sizeable portfolio of > audio/speech codec patents have spoken quite clearly against the goal. It= =B9s > not up to me to declare an IETF consensus on whether acceptable terms are > achievable, but if someone were a declaring such a consensus, I would > object=8Band I=B9m sure I would not be alone. In fact, =B3acceptable term= s=B2, by > policy cannot and will not be a hard requirement for the work of a > hypothetical codec WG. > Based on these perceptions and facts it seems obvious that it=B9s going to= be > much harder to achieve=8Bthat is also: easier to prevent for those not > amicable=8Bthe goals of a hypothetical codec WG when compared to the goals= of > JVT. > Regards, > Stephan > > > On 11/15/09 3:17 PM, "Rob Glidden" wrote: > >> There is another way to read this. >> >> This case has been called "the most infamous discovery fiasco in recent >> times": >> >> - The lawyers were sanctioned >> - The patents were held both unenforceable and inapplicable >> - Fines were levied >> - The law firm crumbled and was sold >> >> But read the case:=A0 these were not patents that turned up two years lat= er.=A0 >> The two were issued and therefore public in 1995 and 1996 (5 years =20 >> before the >> JVT), and had been presented to the MPEG committee before. >> >> Going forward, a more proactive ex ante assessment of known =20 >> patents, at least >> of the participants in the activity, rather than just relying on statemen= ts, >> would be good practice to check for blocking patents. >> >> But yes, you are right the court did not blame the JVT process and certai= nly >> not those who took the royalty-free objective seriously.=A0 Clearly =20 >> not everyone >> shared that goal, and got caught in subverting it. >> >> But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than jus= t >> keep presuming that such things never occur and accept being blind =20 >> sided, and >> has tightened its IPR policy (which provides for third-parties =20 >> coming forward >> with blocking info). >> >> And yes, any one can sue about anything, and they can lie about their >> participation in a standards group.=A0 They can fail to disclose.=A0 They= can >> assert patents that end up being ruled as inapplicable.=A0 Maybe they wil= l get >> away with it, or maybe as in this case they won't. >> >> But that isn't a good reason to fail to develop the standards the Web nee= ds >> for its open, royalty-free future.=A0 Rather, the opposite. If it takes t= his >> kind of extreme behavior and it still doesn't work, then time to keep mov= ing >> forward with royalty-free standardization. >> >> Rob >> >> http://www.law.com/jsp/article.jsp?id=3D1202435137932 >> >> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >> >> "Lawyers in the Qualcomm discovery scandal claim that the company misled = and >> stonewalled them, ultimately leading to the failure to turn over a =20 >> mountain of >> relevant evidence and harsh sanctions from the court." >> >> The allegations were made in briefs filed Monday by lawyers from the >> now-defunct Day Casebeer Batchelder & Madrid >> , who for the =20 >> first time >> are telling their side of what has become the most infamous discovery fia= sco >> in recent times >> . >> >> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major = in >> January 2008 for intentionally withholding "tens of thousands of e-mails"= in >> an infringement case against Broadcom Corp. involving video compression >> technology patents. The company's lawyers -- six from Day Casebeer and on= e >> from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in >> committing this incredible discovery violation," either knowingly or >> recklessly, Major wrote at the time." >> >> stephen botzko wrote: >>> As Stephan Wenger indicated, it is not clear if the JVT actually failed = or >>> not.=A0 What is clear is that they did everything they reasonably could = have >>> done.=A0 There were several folks participating who took the royalty-fre= e >>> baseline profile objective very seriously. >>> >>> Again, all submitted IPR for the baseline tools indicated royalty free >>> terms.=A0 So the JVT had every reason to think they had succeeded.=A0=A0= =A0 By the >>> time this IPR turned up, H.264 had been standardized for over 2 =20 >>> years.=A0 H.264 >>> implementations were already out there - so any attempts to do work-arou= nds >>> would have broken existing implementations (including implementations in >>> silicon).=A0 >>> >>> Certainly any existing IETF group would have presumed exactly the =20 >>> same thing >>> the JVT did.=A0 The lesson here is that even if the SDO is conscientious= , an >>> unencumbered codec can not be guaranteed. I don't see any other way to r= ead >>> this. >>> >>> Stephen Botzko >>> Polycom >>> >>> >>> >>> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >>> wrote: >>> >>>> >>>> >>>> stephen botzko wrote: >>>>>>>> >>> >>>>> To date neither ITU-T nor MPEG have ever delivered on this royalty fre= e >>>>> undertaking. >>>>>>>> >>> >>>>> That should be viewed as very bad news here, since all the IPR =20 >>>>> declarations >>>>> in JVT for the baseline tools indicated royalty free terms. In =20 >>>>> other words, >>>>> the SDOs did everything possible to deliver, and when H.264 baseline w= as >>>>> standardized they thought they had succeeded. >>>>> >>>> >>>> I'd suggest that it is hard to see things this way after reading >>>> >>>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>>> >>>> The process was enforceable, and enforced. >>>> The patents could have been found earlier, and removed. >>>> >>>> So any "h.264 successor" type work (audio/video/transport) should =20 >>>> complete, >>>> not drop, the royalty free undertaking.=A0 IETF and ITU-T should lead t= here, >>>> not give up or hide in a niche. >>>> >>>> See November 10, 2009 "Preliminary call for proposals signals =20 >>>> work start for >>>> H.264/MPEG-4 AVC successor" >>>> >>>> >>>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals= +Work >>>> +Start+For+H264MPEG4+AVC+Successor.aspx >>>> >>>> Rob >>>> >>>> >>>> >>>>> Stephen Botzko >>>>> Polycom.=A0 >>>>> >>>>> =A0 >>>>> >>>>> >>>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >>>>> wrote: >>>>> >>>>>> BTW I hear that in MPEG the Chinese National Body initiated a >>>>>> (re)consideration of royalty free standardization and MPEG has issued= a >>>>>> call for comments to other national bodies. >>>>>> >>>>>> Someone may want to contact their national MPEG Head of Delegation or >>>>>> numerous liaisons including IETF, listed at >>>>>> http://www.itscj.ipsj.or.jp/sc29/. >>>>>> >>>>>> At the same time, MPEG is also considering launching new royalty bear= ing >>>>>> activities HVC (High Performance Video Coding) and MMT (Multimedia >>>>>> Transport). http://www.chiariglione.org/mpeg/working_documents.htm >>>>>> >>>>>> You may recall that h.264 was launched in 2001 as a joint =20 >>>>>> project between >>>>>> ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the =20 >>>>>> undertaking that the >>>>>> "JVT [Joint Video Team] will define a =B3baseline=B2 profile. That pr= ofile >>>>>> should be royalty-free for all implementations." To date =20 >>>>>> neither ITU-T nor >>>>>> MPEG have ever delivered on this royalty free undertaking. >>>>>> >>>>>> Rob >>>>>> >>>>>> Eric Burger wrote: >>>>>> >>>>>>> Thank you to everyone who participated in the room and remotely. We >>>>>>> succeeded in getting a lot of work done, and we have a sense of whet= her >>>>>>> or not we have a well-formed problem to solve, if there are people w= ho >>>>>>> need the work product, if people are willing to work on it, and if t= he >>>>>>> IETF is an acceptable venue to do the work. In addition, we =20 >>>>>>> learned a lot >>>>>>> about the possibilities for cooperating with ITU-T SG 16. >>>>>>> >>>>>>> Please review the minutes and send corrections. >>>>>>> >>>>>>> The minutes are posted to: >>>>>>> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >>>>>>> _______________________________________________ >>>>>>> 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 Sun Nov 15 18:59: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 2C6E63A6A5A for ; Sun, 15 Nov 2009 18:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=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 w9eRSbnglEld for ; Sun, 15 Nov 2009 18:59:55 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id D140A3A67D1 for ; Sun, 15 Nov 2009 18:59:52 -0800 (PST) Received: from [192.168.1.111] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 491684-1743317 for multiple; Mon, 16 Nov 2009 03:59:48 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 15 Nov 2009 18:59:32 -0800 From: Stephan Wenger To: Koen Vos Message-ID: Thread-Topic: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted Thread-Index: AcpmaNIKNgxisJUjB0GkORbDbmm3ag== In-Reply-To: <20091115180330.36951poxzqokdrzm@mail.skype.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Nov 2009 02:59:57 -0000 On 11/15/09 6:03 PM, "Koen Vos" wrote: >> The field of technology is at least as heavily patented as video. >=20 > I disagree on this point - a larger fraction of patents in speech and > audio coding have expired. The field has made relatively little > progress in the past 20 years, compared to video. >=20 > koen. >=20 Hi Koen, I'm not necessarily disagreeing with either of your statements. However, the number of expired patents, in isolation, does not necessarily tell you anything of the density of a patent minefield. Nor, in isolation, does a perception of "little progress". When viewing both your points in combination, and if the patent offices would not award patents for trivial non-inventions, I could agree to your arguments. However, from previous jobs, I have some knowledge of the relative portfoli= o size of two big companies active in both fields, and based on this sample o= f two, I stand to my perception re density of the patent minefield (even if I never explicitly stated that they are the same). Note also that I did not comment on significance of the steps forward of each of those patents. Tha= t said, in patent work, one better starts with the assumption of validity, an= d in risk analysis, one better starts with sheer numbers... It's actually possible to measure the density of a patent landscape, at least on a quantitative scale. I have not done so and leave this work for = a really slow day. Regards, Stephan >=20 > Quoting Stephan Wenger : >=20 >> Hi Rob, >>=20 >> I will not comment more on the BC/QC San Diego case, except to say that >> misconduct before the standardization committee (violation of both writt= en >> and de-facto practiced rules of the committee) was only one and, as some >> people have argued, small factor in the ruling. I wish one could come t= o >> the conclusion that any misconduct before a standardization committee wo= uld >> automatically render related patents unenforceable (the inapplicable par= t is >> a very different story), but I fear that this is too much to hope for. >>=20 >> My current view of the likeliness of success of Codec in relation to JVT= =B9s >> success or failure (depending whom you ask): >> 1. JVT took on the creation a royalty-free baseline (that is, a part of = a >> standard only, and rightholders may still require a signed license that = may >> be encumbered to the point where it becomes unusable for some open sourc= e >> communities=8Bclearly a factor for some software companies), in a heavily >> patented field. The vast majority of the participating companies=8Benough= to >> create a consensus-based decision in the committee, and many of them kno= wn >> or likely future rightholders=8Bwas in support of that goal. >> 2. Codec attempts to take on of creating a standard (not only a baseline= of >> a standard=8Brightholders cannot be appeased by arguing they can make mone= y >> from non-baseline applications) under what the BOF chairs called =B3accept= able >> terms=B2--which translate to an open-source friendly non-assert requiremen= t. >> The field of technology is at least as heavily patented as video. A >> significant percentage of companies known to hold a sizeable portfolio o= f >> audio/speech codec patents have spoken quite clearly against the goal. = It=B9s >> not up to me to declare an IETF consensus on whether acceptable terms ar= e >> achievable, but if someone were a declaring such a consensus, I would >> object=8Band I=B9m sure I would not be alone. In fact, =B3acceptable terms=B2, = by >> policy cannot and will not be a hard requirement for the work of a >> hypothetical codec WG. >> Based on these perceptions and facts it seems obvious that it=B9s going to= be >> much harder to achieve=8Bthat is also: easier to prevent for those not >> amicable=8Bthe goals of a hypothetical codec WG when compared to the goals= of >> JVT. >> Regards, >> Stephan >>=20 >>=20 >> On 11/15/09 3:17 PM, "Rob Glidden" wrote: >>=20 >>> There is another way to read this. >>>=20 >>> This case has been called "the most infamous discovery fiasco in recent >>> times": >>>=20 >>> - The lawyers were sanctioned >>> - The patents were held both unenforceable and inapplicable >>> - Fines were levied >>> - The law firm crumbled and was sold >>>=20 >>> But read the case:=A0 these were not patents that turned up two years lat= er.=A0 >>> The two were issued and therefore public in 1995 and 1996 (5 years >>> before the >>> JVT), and had been presented to the MPEG committee before. >>>=20 >>> Going forward, a more proactive ex ante assessment of known >>> patents, at least >>> of the participants in the activity, rather than just relying on statem= ents, >>> would be good practice to check for blocking patents. >>>=20 >>> But yes, you are right the court did not blame the JVT process and cert= ainly >>> not those who took the royalty-free objective seriously.=A0 Clearly >>> not everyone >>> shared that goal, and got caught in subverting it. >>>=20 >>> But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than j= ust >>> keep presuming that such things never occur and accept being blind >>> sided, and >>> has tightened its IPR policy (which provides for third-parties >>> coming forward >>> with blocking info). >>>=20 >>> And yes, any one can sue about anything, and they can lie about their >>> participation in a standards group.=A0 They can fail to disclose.=A0 They c= an >>> assert patents that end up being ruled as inapplicable.=A0 Maybe they wil= l get >>> away with it, or maybe as in this case they won't. >>>=20 >>> But that isn't a good reason to fail to develop the standards the Web n= eeds >>> for its open, royalty-free future.=A0 Rather, the opposite. If it takes t= his >>> kind of extreme behavior and it still doesn't work, then time to keep m= oving >>> forward with royalty-free standardization. >>>=20 >>> Rob >>>=20 >>> http://www.law.com/jsp/article.jsp?id=3D1202435137932 >>>=20 >>> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >>>=20 >>> "Lawyers in the Qualcomm discovery scandal claim that the company misle= d and >>> stonewalled them, ultimately leading to the failure to turn over a >>> mountain of >>> relevant evidence and harsh sanctions from the court." >>>=20 >>> The allegations were made in briefs filed Monday by lawyers from the >>> now-defunct Day Casebeer Batchelder & Madrid >>> , who for the >>> first time >>> are telling their side of what has become the most infamous discovery f= iasco >>> in recent times >>> . >>>=20 >>> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Majo= r in >>> January 2008 for intentionally withholding "tens of thousands of e-mail= s" in >>> an infringement case against Broadcom Corp. involving video compression >>> technology patents. The company's lawyers -- six from Day Casebeer and = one >>> from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in >>> committing this incredible discovery violation," either knowingly or >>> recklessly, Major wrote at the time." >>>=20 >>> stephen botzko wrote: >>>> As Stephan Wenger indicated, it is not clear if the JVT actually faile= d or >>>> not.=A0 What is clear is that they did everything they reasonably could = have >>>> done.=A0 There were several folks participating who took the royalty-fre= e >>>> baseline profile objective very seriously. >>>>=20 >>>> Again, all submitted IPR for the baseline tools indicated royalty free >>>> terms.=A0 So the JVT had every reason to think they had succeeded.=A0=A0=A0 By= the >>>> time this IPR turned up, H.264 had been standardized for over 2 >>>> years.=A0 H.264 >>>> implementations were already out there - so any attempts to do work-ar= ounds >>>> would have broken existing implementations (including implementations = in >>>> silicon).=A0 >>>>=20 >>>> Certainly any existing IETF group would have presumed exactly the >>>> same thing >>>> the JVT did.=A0 The lesson here is that even if the SDO is conscientious= , an >>>> unencumbered codec can not be guaranteed. I don't see any other way to= read >>>> this. >>>>=20 >>>> Stephen Botzko >>>> Polycom >>>>=20 >>>>=20 >>>>=20 >>>> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >>>> wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> stephen botzko wrote: >>>>>>>>>>>>=20 >>>>>> To date neither ITU-T nor MPEG have ever delivered on this royalty f= ree >>>>>> undertaking. >>>>>>>>>>>>=20 >>>>>> That should be viewed as very bad news here, since all the IPR >>>>>> declarations >>>>>> in JVT for the baseline tools indicated royalty free terms. In >>>>>> other words, >>>>>> the SDOs did everything possible to deliver, and when H.264 baseline= was >>>>>> standardized they thought they had succeeded. >>>>>>=20 >>>>>=20 >>>>> I'd suggest that it is hard to see things this way after reading >>>>>=20 >>>>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>>>>=20 >>>>> The process was enforceable, and enforced. >>>>> The patents could have been found earlier, and removed. >>>>>=20 >>>>> So any "h.264 successor" type work (audio/video/transport) should >>>>> complete, >>>>> not drop, the royalty free undertaking.=A0 IETF and ITU-T should lead t= here, >>>>> not give up or hide in a niche. >>>>>=20 >>>>> See November 10, 2009 "Preliminary call for proposals signals >>>>> work start for >>>>> H.264/MPEG-4 AVC successor" >>>>>=20 >>>>>=20 >>>>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signa= ls+Wo >>>>> rk >>>>> +Start+For+H264MPEG4+AVC+Successor.aspx >>>>>=20 >>>>> Rob >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Stephen Botzko >>>>>> Polycom.=A0 >>>>>>=20 >>>>>> =A0 >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >>>>>> wrote: >>>>>>=20 >>>>>>> BTW I hear that in MPEG the Chinese National Body initiated a >>>>>>> (re)consideration of royalty free standardization and MPEG has issu= ed a >>>>>>> call for comments to other national bodies. >>>>>>>=20 >>>>>>> Someone may want to contact their national MPEG Head of Delegation = or >>>>>>> numerous liaisons including IETF, listed at >>>>>>> http://www.itscj.ipsj.or.jp/sc29/. >>>>>>>=20 >>>>>>> At the same time, MPEG is also considering launching new royalty be= aring >>>>>>> activities HVC (High Performance Video Coding) and MMT (Multimedia >>>>>>> Transport). http://www.chiariglione.org/mpeg/working_documents.htm >>>>>>>=20 >>>>>>> You may recall that h.264 was launched in 2001 as a joint >>>>>>> project between >>>>>>> ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the >>>>>>> undertaking that the >>>>>>> "JVT [Joint Video Team] will define a =B3baseline=B2 profile. That prof= ile >>>>>>> should be royalty-free for all implementations." To date >>>>>>> neither ITU-T nor >>>>>>> MPEG have ever delivered on this royalty free undertaking. >>>>>>>=20 >>>>>>> Rob >>>>>>>=20 >>>>>>> Eric Burger wrote: >>>>>>>=20 >>>>>>>> Thank you to everyone who participated in the room and remotely. W= e >>>>>>>> succeeded in getting a lot of work done, and we have a sense of wh= ether >>>>>>>> or not we have a well-formed problem to solve, if there are people= who >>>>>>>> need the work product, if people are willing to work on it, and if= the >>>>>>>> IETF is an acceptable venue to do the work. In addition, we >>>>>>>> learned a lot >>>>>>>> about the possibilities for cooperating with ITU-T SG 16. >>>>>>>>=20 >>>>>>>> Please review the minutes and send corrections. >>>>>>>>=20 >>>>>>>> The minutes are posted to: >>>>>>>> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 >=20 From rob.glidden@sbcglobal.net Tue Nov 17 03:28: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 D99BD3A68E3 for ; Tue, 17 Nov 2009 03:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.794 X-Spam-Level: * X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, UNPARSEABLE_RELAY=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 TOoRuKEu+0Ue for ; Tue, 17 Nov 2009 03:28:09 -0800 (PST) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id C5B863A67EB for ; Tue, 17 Nov 2009 03:28:09 -0800 (PST) Received: (qmail 17309 invoked from network); 17 Nov 2009 11:28:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=3/kGMFZCyLkHQ+a8POEpsUzFybiloVymMl0tJmOMx0AvMKVsz1xaIJKdtV4M/Q/DNGm98300WLpA0WWAmU9ah8uU8WEHpgl3+MmuyvAWIcu7Taa9rJsJDt7gdaMnPyM109epsitPuu/DqBYgab787WmCbHrD2d3GnWZRmbxVLR8= ; Received: from customer-static-2-62-37.iplannetworks.net (rob.glidden@190.2.62.37 with plain) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 17 Nov 2009 03:28:07 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: rnU0D1YVM1mJHk6ho32Pr0.VLoEi9YSPOcAPz9nFeQIVqCqE1LutHqTKDpO0y1Wksqdg7y.kSGmUO9XpjTK8vaMCm.aKX8Vks3o_3bc2ZJ9VZM40wWNLjPSH2rKP9EsH5gikPRSI31J5rJUN0PdCQq_YCNNI7o.tCPB6yrUZm63hmy62NSGXaZjJb5MdRb6xHahONEOJGN6T1sh.jzvSfPOCmkPb9YgNJQpXaOKERaI_Sto02.go_yZDk4cUBQwZovGC2q9qbuJhw6ic4Xp5gA3qTS2xpllORs.yCOTn_oPakJkXRfKJL3pCuQqW1Jws4UI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0288C5.6000300@sbcglobal.net> Date: Tue, 17 Nov 2009 03:28:05 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 11:28:16 -0000 Stephan:

It doesn't appear there was ever much more than a paper consensus that was undermined by 2003 (see previous email) when patent pools started announcing coverage of the h.264 baseline (years before the Qualcomm litigation).

As the impressive curriculum states on 2001-2003 time frame:

"Fought the political battles to make those contributions pass, despite substantial resistance from some of the largest companies in the field."

http://www.stewe.org/cv-business-wenger.pdf

So I'd suggest a different interpretation, one that does not assume there was a sincere or sustained political consensus. Accepting this, a more realistic forward look is possible.

Rob


Stephan Wenger wrote:
Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes  Posted Hi Rob,

I will not comment more on the BC/QC San Diego case, except to say that misconduct before the standardization committee (violation of both written and de-facto practiced rules of the committee) was only one and, as some people have argued, small factor in the ruling.  I wish one could come to the conclusion that any misconduct before a standardization committee would automatically render related patents unenforceable (the inapplicable part is a very different story), but I fear that this is too much to hope for.

My current view of the likeliness of success of Codec in relation to JVT’s success or failure (depending whom you ask):
  1. JVT took on the creation a royalty-free baseline (that is, a part of a standard only, and rightholders may still require a signed license that may be encumbered to the point where it becomes unusable for some open source communities—clearly a factor for some software companies), in a heavily patented field.  The vast majority of the participating companies—enough to create a consensus-based decision in the committee, and many of them known or likely future rightholders—was in support of that goal.
  2. Codec attempts to take on of creating a standard (not only a baseline of a standard—rightholders cannot be appeased by arguing they can make money from non-baseline applications) under what the BOF chairs called “acceptable terms”--which translate to an open-source friendly non-assert requirement.  The field of technology is at least as heavily patented as video.  A significant percentage of companies known to hold a sizeable portfolio of audio/speech codec patents have spoken quite clearly against the goal.  It’s not up to me to declare an IETF consensus on whether acceptable terms are achievable, but if someone were a declaring such a consensus, I would object—and I’m sure I would not be alone.  In fact, “acceptable terms”, by policy cannot and will not be a hard requirement for the work of a hypothetical codec WG.
Based on these perceptions and facts it seems obvious that it’s going to be much harder to achieve—that is also: easier to prevent for those not amicable—the goals of a hypothetical codec WG when compared to the goals of JVT.  
Regards,
Stephan


On 11/15/09 3:17 PM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:
There is another way to read this.

This case has been called "the most infamous discovery fiasco in recent times":

- The lawyers were sanctioned
- The patents were held both unenforceable and inapplicable
- Fines were levied
- The law firm crumbled and was sold

But read the case:  these were not patents that turned up two years later.  The two were issued and therefore public in 1995 and 1996 (5 years before the JVT), and had been presented to the MPEG committee before.

Going forward, a more proactive ex ante assessment of known patents, at least of the participants in the activity, rather than just relying on statements, would be good practice to check for blocking patents.

But yes, you are right the court did not blame the JVT process and certainly not those who took the royalty-free objective seriously.  Clearly not everyone shared that goal, and got caught in subverting it.

But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than just keep presuming that such things never occur and accept being blind sided, and has tightened its IPR policy (which provides for third-parties coming forward with blocking info).

And yes, any one can sue about anything, and they can lie about their participation in a standards group.  They can fail to disclose.  They can assert patents that end up being ruled as inapplicable.  Maybe they will get away with it, or maybe as in this case they won't.

But that isn't a good reason to fail to develop the standards the Web needs for its open, royalty-free future.  Rather, the opposite. If it takes this kind of extreme behavior and it still doesn't work, then time to keep moving forward with royalty-free standardization.

Rob

http://www.law.com/jsp/article.jsp?id=1202435137932

"Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

"Lawyers in the Qualcomm discovery scandal claim that the company misled and stonewalled them, ultimately leading to the failure to turn over a mountain of relevant evidence and harsh sanctions from the court."

The allegations were made in briefs filed Monday by lawyers from the now-defunct Day Casebeer Batchelder & Madrid <http://www.law.com/jsp/article.jsp?id=1202431679659> , who for the first time are telling their side of what has become the most infamous discovery fiasco in recent times <http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=900005504954> .

Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major in January 2008 for intentionally withholding "tens of thousands of e-mails" in an infringement case against Broadcom Corp. involving video compression technology patents. The company's lawyers -- six from Day Casebeer and one from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in committing this incredible discovery violation," either knowingly or recklessly, Major wrote at the time."

stephen botzko wrote:
As Stephan Wenger indicated, it is not clear if the JVT actually failed or not.  What is clear is that they did everything they reasonably could have done.  There were several folks participating who took the royalty-free baseline profile objective very seriously.
 
Again, all submitted IPR for the baseline tools indicated royalty free terms.  So the JVT had every reason to think they had succeeded.    By the time this IPR turned up, H.264 had been standardized for over 2 years.  H.264 implementations were already out there - so any attempts to do work-arounds would have broken existing implementations (including implementations in silicon). 
 
Certainly any existing IETF group would have presumed exactly the same thing the JVT did.  The lesson here is that even if the SDO is conscientious, an unencumbered codec can not be guaranteed. I don't see any other way to read this.
 
Stephen Botzko
Polycom
 
 
 
On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 

 
stephen botzko wrote:
>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
>>>
That should be viewed as very bad news here, since all the IPR declarations in JVT for the baseline tools indicated royalty free terms. In other words, the SDOs did everything possible to deliver, and when H.264 baseline was standardized they thought they had succeeded.
 

I'd suggest that it is hard to see things this way after reading
 
 http://www.cafc.uscourts.gov/opinions/07-1545.pdf
 
The process was enforceable, and enforced.
The patents could have been found earlier, and removed.
 
So any "h.264 successor" type work (audio/video/transport) should complete, not drop, the royalty free undertaking.  IETF and ITU-T should lead there, not give up or hide in a niche.
 
See November 10, 2009 "Preliminary call for proposals signals work start for H.264/MPEG-4 AVC successor"
 
 http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx
 
Rob

 
 
Stephen Botzko
Polycom. 
 
 
 
 
On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 
BTW I hear that in MPEG the Chinese National Body initiated a (re)consideration of royalty free standardization and MPEG has issued a call for comments to other national bodies.
 
Someone may want to contact their national MPEG Head of Delegation or numerous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.
 
At the same time, MPEG is also considering launching new royalty bearing activities HVC (High Performance Video Coding) and MMT (Multimedia Transport). http://www.chiariglione.org/mpeg/working_documents.htm
 
You may recall that h.264 was launched in 2001 as a joint project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the "JVT [Joint Video Team] will define a “baseline” profile. That profile should be royalty-free for all implementations." To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
 
Rob
 
Eric Burger wrote:
 
Thank you to everyone who participated in the room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need the work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16.
 
Please review the minutes and send corrections.
 
The minutes are posted to:
 http://www.ietf.org/proceedings/09nov/minutes/codec.txt
_______________________________________________
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 stephen.botzko@gmail.com Tue Nov 17 03:39:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512D028C0EC for ; Tue, 17 Nov 2009 03:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 0khPtxmBZS3b for ; Tue, 17 Nov 2009 03:39:15 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 143413A67DF for ; Tue, 17 Nov 2009 03:39:14 -0800 (PST) Received: by bwz23 with SMTP id 23so6858153bwz.29 for ; Tue, 17 Nov 2009 03:39:10 -0800 (PST) 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=Y529FzIDRULS4pLkkbeQjrashpKr80yUeETjgpCaKj0=; b=WoINTGKAXB4UplbpXar6gdX1k5ncjGolE7WvWeNOf9ASTyp+RyXDayg+9LDhuXDKze pgCJEu2C8hdMwwTBeYibLfyuVbCWlU6sMG4xggsgBIKI4NjQbZND7WkLvxzkiViv36SB yde1LPUvz/DgCRphaaq6wqYHa3SNBPDKBVAUY= 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=AWz3tiE5BmQG9oqomDzEamoEKqmaCB1UaTnPKyMc7amoyR65TkNk8tRUXln2NEtIxf HQwGS2CWz+gr1tfCVKJ0YInLGrRbp8Yk5VPiQEavVV3e+d1z/UEBOd4OpNgJgtUZ/Zz8 pYm5PDTWC/PAr5+w4nuImigkNqJflBKOTc2I0= MIME-Version: 1.0 Received: by 10.102.80.14 with SMTP id d14mr4273736mub.73.1258457949179; Tue, 17 Nov 2009 03:39:09 -0800 (PST) In-Reply-To: <4B0288C5.6000300@sbcglobal.net> References: <4B0288C5.6000300@sbcglobal.net> Date: Tue, 17 Nov 2009 06:39:09 -0500 Message-ID: <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> From: stephen botzko To: Rob Glidden Content-Type: multipart/alternative; boundary=0016e65a044e0691cc04788f93c7 Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 11:39:18 -0000 --0016e65a044e0691cc04788f93c7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Perhaps you should add the word "sincere" to the proposed codec charter. That would certainly fix it. Stephen Botzko Polycom On Tue, Nov 17, 2009 at 6:28 AM, Rob Glidden wro= te: > Stephan: > > It doesn't appear there was ever much more than a paper consensus that wa= s > undermined by 2003 (see previous email) when patent pools started announc= ing > coverage of the h.264 baseline (years before the Qualcomm litigation). > > As the impressive curriculum states on 2001-2003 time frame: > > "Fought the political battles to make those contributions pass, despite > substantial resistance from some of the largest companies in the field." > > http://www.stewe.org/cv-business-wenger.pdf > > So I'd suggest a different interpretation, one that does not assume there > was a sincere or sustained political consensus. Accepting this, a more > realistic forward look is possible. > > Rob > > > > Stephan Wenger wrote: > > Hi Rob, > > I will not comment more on the BC/QC San Diego case, except to say that > misconduct before the standardization committee (violation of both writte= n > and de-facto practiced rules of the committee) was only one and, as some > people have argued, small factor in the ruling. I wish one could come to > the conclusion that any misconduct before a standardization committee wou= ld > automatically render related patents unenforceable (the inapplicable part= is > a very different story), but I fear that this is too much to hope for. > > My current view of the likeliness of success of Codec in relation to JVT= =92s > success or failure (depending whom you ask): > > 1. JVT took on the creation a *royalty-free* *baseline *(that is, a > part of a standard only, and rightholders may still require a signed l= icense > that may be encumbered to the point where it becomes unusable for some= open > source communities=97clearly a factor for some software companies), in= a > *heavily patented field.* The vast majority of the participating > companies=97enough to create a consensus-based decision in the committ= ee, and > many of them known or likely future rightholders=97was *in support* of > that goal. > 2. Codec attempts to take on of creating a *standard *(not only a > baseline of a standard=97rightholders cannot be appeased by arguing th= ey can > make money from non-baseline applications) under what the BOF chairs c= alled > =93acceptable terms=94--which translate to an *open-source friendly > non-assert requirement*. The field of technology is at least as *heav= ily > patented* as video. A *significant percentage* of companies known to > hold a sizeable portfolio of audio/speech codec patents have spoken qu= ite > *clearly against the goal*. It=92s not up to me to declare an IETF > consensus on whether acceptable terms are achievable, but if someone w= ere a > declaring such a consensus, I would object=97and I=92m sure I would no= t be > alone. In fact, =93acceptable terms=94, by policy cannot and will not= be a hard > requirement for the work of a hypothetical codec WG. > > Based on these perceptions and facts it seems obvious that it=92s going t= o be > much harder to achieve=97that is also: easier to prevent for those not > amicable=97the goals of a hypothetical codec WG when compared to the goal= s of > JVT. > Regards, > Stephan > > > On 11/15/09 3:17 PM, "Rob Glidden" wrote: > > There is another way to read this. > > This case has been called "the most infamous discovery fiasco in recent > times": > > - The lawyers were sanctioned > - The patents were held both unenforceable and inapplicable > - Fines were levied > - The law firm crumbled and was sold > > But read the case: these were not patents that turned up two years later= . > The two were issued and therefore public in 1995 and 1996 (5 years before > the JVT), and had been presented to the MPEG committee before. > > Going forward, a more proactive ex ante assessment of known patents, at > least of the participants in the activity, rather than just relying on > statements, would be good practice to check for blocking patents. > > But yes, you are right the court did not blame the JVT process and > certainly not those who took the royalty-free objective seriously. Clear= ly > not everyone shared that goal, and got caught in subverting it. > > But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than jus= t > keep presuming that such things never occur and accept being blind sided, > and has tightened its IPR policy (which provides for third-parties coming > forward with blocking info). > > And yes, any one can sue about anything, and they can lie about their > participation in a standards group. They can fail to disclose. They can > assert patents that end up being ruled as inapplicable. Maybe they will = get > away with it, or maybe as in this case they won't. > > But that isn't a good reason to fail to develop the standards the Web nee= ds > for its open, royalty-free future. Rather, the opposite. If it takes thi= s > kind of extreme behavior and it still doesn't work, then time to keep mov= ing > forward with royalty-free standardization. > > Rob > > http://www.law.com/jsp/article.jsp?id=3D1202435137932 > > "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 > > "Lawyers in the Qualcomm discovery scandal claim that the company misled > and stonewalled them, ultimately leading to the failure to turn over a > mountain of relevant evidence and harsh sanctions from the court." > > The allegations were made in briefs filed Monday by lawyers from the > now-defunct Day Casebeer Batchelder & Madrid < > http://www.law.com/jsp/article.jsp?id=3D1202431679659> , who for the firs= t > time are telling their side of what has become the most infamous discover= y > fiasco in recent times < > http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D900005504954= > . > > > Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major = in > January 2008 for intentionally withholding "tens of thousands of e-mails"= in > an infringement case against Broadcom Corp. involving video compression > technology patents. The company's lawyers -- six from Day Casebeer and on= e > from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in > committing this incredible discovery violation," either knowingly or > recklessly, Major wrote at the time." > > stephen botzko wrote: > > As Stephan Wenger indicated, it is not clear if the JVT actually failed o= r > not. What is clear is that they did everything they reasonably could hav= e > done. There were several folks participating who took the royalty-free > baseline profile objective very seriously. > > Again, all submitted IPR for the baseline tools indicated royalty free > terms. So the JVT had every reason to think they had succeeded. By th= e > time this IPR turned up, H.264 had been standardized for over 2 years. > H.264 implementations were already out there - so any attempts to do > work-arounds would have broken existing implementations (including > implementations in silicon). > > Certainly any existing IETF group would have presumed exactly the same > thing the JVT did. The lesson here is that even if the SDO is > conscientious, an unencumbered codec can not be guaranteed. I don't see a= ny > other way to read this. > > Stephen Botzko > Polycom > > > > On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden > wrote: > > > > > stephen botzko wrote: > > >>> > To date neither ITU-T nor MPEG have ever delivered on this royalty free > undertaking. > >>> > That should be viewed as very *bad* news here, since all the IPR > declarations in JVT for the baseline tools indicated royalty free terms. = In > other words, the SDOs did everything possible to deliver, and when H.264 > baseline was standardized they thought they had succeeded. > > > > I'd suggest that it is hard to see things this way after reading > > http://www.cafc.uscourts.gov/opinions/07-1545.pdf > > The process was enforceable, and enforced. > The patents could have been found earlier, and removed. > > So any "h.264 successor" type work (audio/video/transport) should complet= e, > not drop, the royalty free undertaking. IETF and ITU-T should lead there= , > not give up or hide in a niche. > > See November 10, 2009 "Preliminary call for proposals signals work start > for H.264/MPEG-4 AVC successor" > > > http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+W= ork+Start+For+H264MPEG4+AVC+Successor.aspx > > Rob > > > > > Stephen Botzko > Polycom. > > > > > On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden > wrote: > > > BTW I hear that in MPEG the Chinese National Body initiated a > (re)consideration of royalty free standardization and MPEG has issued a c= all > for comments to other national bodies. > > Someone may want to contact their national MPEG Head of Delegation or > numerous liaisons including IETF, listed at > http://www.itscj.ipsj.or.jp/sc29/. > > At the same time, MPEG is also considering launching new royalty bearing > activities HVC (High Performance Video Coding) and MMT (Multimedia > Transport). http://www.chiariglione.org/mpeg/working_documents.htm > > You may recall that h.264 was launched in 2001 as a joint project between > ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the > "JVT [Joint Video Team] will define a =93baseline=94 profile. That profil= e > should be royalty-free for all implementations." To date neither ITU-T no= r > MPEG have ever delivered on this royalty free undertaking. > > Rob > > Eric Burger wrote: > > > Thank you to everyone who participated in the room and remotely. We > succeeded in getting a lot of work done, and we have a sense of whether o= r > not we have a well-formed problem to solve, if there are people who need = the > work product, if people are willing to work on it, and if the IETF is an > acceptable venue to do the work. In addition, we learned a lot about the > possibilities for cooperating with ITU-T SG 16. > > Please review the minutes and send corrections. > > The minutes are posted to: > http://www.ietf.org/proceedings/09nov/minutes/codec.txt > _______________________________________________ > 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 > > > --0016e65a044e0691cc04788f93c7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Perhaps you should add the word "sincere" to the proposed codec c= harter.=A0 That would certainly fix it.

Stephen Botzko
Polycom
On Tue, Nov 17, 2009 at 6:28 AM, Rob Glidde= n <rob.glidden@sbcglobal.net> wrote:
=20
Stephan:

It doesn't appear there was ever much more than a paper consensus that was undermined by 2003 (see previous email) when patent pools started announcing coverage of the h.264 baseline (years before the Qualcomm litigation).

As the impressive curriculum states on 2001-2003 time frame:

"Fought the political battles to make those contributions pass, despit= e substantial resistance from some of the largest companies in the field.&quo= t;

h= ttp://www.stewe.org/cv-business-wenger.pdf

So I'd suggest a different interpretation, one that does not assume there was a sincere or sustained political consensus. Accepting this, a more realistic forward look is possible.

Rob



Stephan Wenger wrote:
=20 Hi Rob,

I will not comment more on the BC/QC San Diego case, except to say that misconduct before the standardization committee (violation of both written and de-facto practiced rules of the committee) was only one and, as some people have argued, small factor in the ruling. =A0I wish one could come to the conclusion that any misconduct before a standardization committee would automatically render related patents unenforceable (the inapplicable part is a very different story), but I fear that this is too much to hope for.

My current view of the likeliness of success of Codec in relation to JVT=92s success or failure (depending whom you ask):
  1. JVT took on the creation a royalty-free baseline (that is, a part of a standard only, and rightholders may still require a signed license that may be encumbered to the point where it becomes unusable for some open source communities=97clearly a factor for some software companies), in a heavil= y patented field. =A0The vast majority of the participating companies=97enough to create a consensus-based decision in the committee, and many of them known or likely future rightholders=97was in support of that goal.
  2. Codec attempts to take on of creating a standard (not only a baseline of a standard=97rightholders cannot be appeased by arguing they can make money from non-baseline applications) under what the BOF chairs called =93acceptable terms=94--which translate to an open-source friendly non-assert requirement. =A0The field of technology is at least as heavily patented as video. =A0A signifi= cant percentage of companies known to hold a sizeable portfolio of audio/speech codec patents have spoken quite clearly against the goal. =A0It=92s not up to me to declare an IETF consensus on whether acceptable terms are achievable, but if someone were a declaring such a consensus, I would object=97and I=92m sure I would not be alone. =A0In fact= , =93acceptable terms=94, by policy cannot and will not be a hard requirement for the work of a hypothetical codec WG.
Based on these perceptions and facts it seems obvious that it=92s going to be much harder to achieve=97that is also: easier to prevent for those not amicable=97the goals of a hypothetical codec WG when compared to the goals of JVT. =A0
Regards,
Stephan


On 11/15/09 3:17 PM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:
There is another way to read this.

This case has been called "the most infamous discovery fiasco in recen= t times":

- The lawyers were sanctioned
- The patents were held both unenforceable and inapplicable
- Fines were levied
- The law firm crumbled and was sold

But read the case:=A0 these were not patents that turned up two years later.=A0 The two were issued and therefore public in 1995 and 1996 (5 years before the JVT), and had been presented to the MPEG committee before.

Going forward, a more proactive ex ante assessment of known patents, at least of the participants in the activity, rather than just relying on statements, would be good practice to check for blocking patents.

But yes, you are right the court did not blame the JVT process and certainly not those who took the royalty-free objective seriously.=A0 Clearly not everyone shared that goal, and got caught in subverting it.

But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than just keep presuming that such things never occur and accept being blind sided, and has tightened its IPR policy (which provides for third-parties coming forward with blocking info).

And yes, any one can sue about anything, and they can lie about their participation in a standards group.=A0 They can fail to disclose.=A0 They can assert patents that end up being ruled as inapplicable.=A0 Maybe they will get away with it, or maybe as in this case they won't.

But that isn't a good reason to fail to develop the standards the Web needs for its open, royalty-free future.=A0 Rather, the opposite. If it takes this kind of extreme behavior and it still doesn't work, then time to keep moving forward with royalty-free standardization.

Rob

http://www.law.com/jsp/article.jsp?id=3D1202435137932

"Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 200= 9

"Lawyers in the Qualcomm discovery scandal claim that the company misled and stonewalled them, ultimately leading to the failure to turn over a mountain of relevant evidence and harsh sanctions from the court."

The allegations were made in briefs filed Monday by lawyers from the now-defunct Day Casebeer Batchelder & Madrid <http://www.la= w.com/jsp/article.jsp?id=3D1202431679659> , who for the first time are telling their side of what has become the most infamous discovery fiasco in recent times <http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D900005504= 954> .

Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major in January 2008 for intentionally withholding "tens of thousands of e-mails" in an infringement case against Broadcom Corp. involving video compression technology patents. The company's lawyers -- six from Day Casebeer and one from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in committing this incredible discovery violation,= " either knowingly or recklessly, Major wrote at the time."

stephen botzko wrote:
As Stephan Wenger indicated, it is not clear if the JVT actually failed or not.=A0 What is clear is that they did everything they reasonably could have done.=A0 There were several folks participating who took the royalty-free baseline profile objective very seriously.
=A0
Again, all submitted IPR for the baseline tools indicated royalty free terms.=A0 So the JVT had every reason to think they had succeeded.=A0=A0=A0= By the time this IPR turned up, H.264 had been standardized for over 2 years.=A0 H.264 implementations were already out there - so any attempts to do work-arounds would have broken existing implementations (including implementations in silicon).=A0
=A0
Certainly any existing IETF group would have presumed exactly the same thing the JVT did.=A0 The lesson here is that even if the SDO is conscientious, an unencumbered codec can not be guaranteed. I don't see any other way to read this.
=A0
Stephen Botzko
Polycom
=A0
=A0
=A0
On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
=A0

=A0
stephen botzko wrote:
>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
>>>
That should be viewed as very bad news here, since all the IPR declarations in JVT for the baseline tools indicated royalty free terms. In other words, the SDOs did everything possible to deliver, and when H.264 baseline was standardized they thought they had succeeded.
=A0

I'd suggest that it is hard to see things this way after reading
=A0
=A0http://www.cafc.uscourts.gov/opinions/07-1545.pdf
=A0
The process was enforceable, and enforced.
The patents could have been found earlier, and removed.
=A0
So any "h.264 successor" type work (audio/video/transport) should complete, not drop, the royalty free undertaking.=A0 IETF and ITU-T should lead there, not give up or hide in a niche.
=A0
See November 10, 2009 "Preliminary call for proposals signals work start for H.264/MPEG-4 AVC successor"
=A0
=A0h= ttp://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work= +Start+For+H264MPEG4+AVC+Successor.aspx
=A0
Rob

=A0
=A0
Stephen Botzko
Polycom.=A0
=A0
=A0
=A0
=A0
On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
=A0
BTW I hear that in MPEG the Chinese National Body initiated a (re)consideration of royalty free standardization and MPEG has issued a call for comments to other national bodies.
=A0
Someone may want to contact their national MPEG Head of Delegation or numerous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.
=A0
At the same time, MPEG is also considering launching new royalty bearing activities HVC (High Performance Video Coding) and MMT (Multimedia Transport). http://www.chiariglione.org/mpeg/working_= documents.htm
=A0
You may recall that h.264 was launched in 2001 as a joint project between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the "JVT [Joint Video Team] will define a =93baseline= =94 profile. That profile should be royalty-free for all implementations." To date neither ITU-T nor MPEG have ever delivered on this royalty free undertaking.
=A0
Rob
=A0
Eric Burger wrote:
=A0
<= span style=3D"font-size: 11pt;">Thank you to everyone who participated in t= he room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need the work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16.
=A0
Please review the minutes and send corrections.
=A0
The minutes are posted to:
=A0http://www.ietf.org/proceedings/09nov/minutes/codec.txt _______________________________________________
codec mailing list
=A0codec@ietf.org =A0https://www.ietf.org/mailman/listinfo/codec
=A0
=A0

_______________________________________________
codec mailing list
=A0codec@ietf.org =A0https://www.ietf.org/mailman/listinfo/codec
=A0

=A0
=A0

=A0
=A0
=A0

=A0


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


--0016e65a044e0691cc04788f93c7-- From stephen.botzko@gmail.com Tue Nov 17 04:32: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 01C843A6942 for ; Tue, 17 Nov 2009 04:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=1.142, 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 nLS6SZIURfFu for ; Tue, 17 Nov 2009 04:32:06 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E93EF3A684C for ; Tue, 17 Nov 2009 04:32:05 -0800 (PST) Received: by bwz23 with SMTP id 23so6923169bwz.29 for ; Tue, 17 Nov 2009 04:32:01 -0800 (PST) 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=Td6amzaEuToiHTLmItZGYjloyIYJfPDe8X5dsiFxZtk=; b=t6QLx6nCLderTS0uw/htqPo4Fq24Jf9lqoqeAvNNvcyiBIIBuoL9fEQjo6WfXObluI kqMQgaemAXZRGJnE5ZnYv6VgsebtunLkRRir7d8n8GcR2I4bs4jCd8wFRnzw8DQVHB7b jRX/5c4Elnr6crieVnGH63iruS3B7GVS7aMLc= 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=aLWKuuPht9QtgbUh7GJuFAkMQBC35iSNG6zdL6SgCv+p9VtcNvfDlwuh1WeQvcLjo2 5gAGg2+Nnd7MZ0Z5C9K0v+IUdjw5WOSf9S0NT5CCjbULndKcQA/3WyVQvXJUSDSK332w 7oHGLjB9F/nLhBR4bEfbKreaQXJeu06fXiNKk= MIME-Version: 1.0 Received: by 10.102.80.14 with SMTP id d14mr4305058mub.73.1258461118020; Tue, 17 Nov 2009 04:31:58 -0800 (PST) In-Reply-To: <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> Date: Tue, 17 Nov 2009 07:31:57 -0500 Message-ID: <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e65a044ee73d120478904f89 Subject: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 12:32:09 -0000 --0016e65a044ee73d120478904f89 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process. Responses are not profile-specific (since there are no profiles defined at this point). There is more than on= e operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals. Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work. There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally. Having attended some of these meetings, I think it is premature to say who has the upper hand. The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference. Stephen Botzko Polycom On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden wro= te: > Stephen: > > Millions of patents, even a limited search could be quite expensive, > amateur search done without lawyers could be a waste of time. > > I believe all could "stipulate" to these points. > > But obviously, others did do this work. So better can be done. > > Yes, I am critical of JVT for dropping royalty free ball, we can debate w= ho > dropped it and when and whether the ball was yanked from their hands or w= ere > outfoxed, dis-spirited or whatever. > > But the new successor call to h.264 drops any public mention of a > royalty-free at all. So it is clear who has upper hand now -- and this > should not be acceptable. > > Rob > > stephen botzko wrote: > >> I did read the case. And despite the fact that the court did not critici= ze >> the JVT at all, I think that your own posts left a false impression that >> somehow it did. >> >> What you haven't done so far is identify how the IETF (or ITU-T, MPEG) >> could ensure unencumbered standards with any certainty. >> >> Ex-ante assessment of the millions of US patents (+ the millions more >> filed in other countries) is not a practical answer. Perhaps a limited >> search would have caught some patents. But it would not even come close= to >> catching them all. >> >> And of course there are cases where the granted claims are hard to >> interpret, even if you have access to the prosecution history. And other= s >> where the claims are actually invalid. Even a limited search could be q= uite >> expensive (and an amateur search done without lawyers would IMHO be a wa= ste >> of time).. >> >> The JVT made a noble effort, and I really don't see how a normal SDO >> (including the IETF) could do much better. >> >> Stephen Botzko >> Polycom >> >> On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden > rob.glidden@sbcglobal.net>> wrote: >> >> There is another way to read this. >> >> This case has been called "the most infamous discovery fiasco in >> recent times": >> >> - The lawyers were sanctioned >> - The patents were held both unenforceable and inapplicable >> - Fines were levied >> - The law firm crumbled and was sold >> >> But read the case: these were not patents that turned up two >> years later. The two were issued and therefore public in 1995 and >> 1996 (5 years before the JVT), and had been presented to the MPEG >> committee before. >> >> Going forward, a more proactive ex ante assessment of known >> patents, at least of the participants in the activity, rather than >> just relying on statements, would be good practice to check for >> blocking patents. >> >> But yes, you are right the court did not blame the JVT process and >> certainly not those who took the royalty-free objective >> seriously. Clearly not everyone shared that goal, and got caught >> in subverting it. >> >> But no, the subsequent ITU/ISO/IEC Common Patent Policy did more >> than just keep presuming that such things never occur and accept >> being blind sided, and has tightened its IPR policy (which >> provides for third-parties coming forward with blocking info). >> >> And yes, any one can sue about anything, and they can lie about >> their participation in a standards group. They can fail to >> disclose. They can assert patents that end up being ruled as >> inapplicable. Maybe they will get away with it, or maybe as in >> this case they won't. >> >> But that isn't a good reason to fail to develop the standards the >> Web needs for its open, royalty-free future. Rather, the >> opposite. If it takes this kind of extreme behavior and it still >> doesn't work, then time to keep moving forward with royalty-free >> standardization. >> >> Rob >> >> http://www.law.com/jsp/article.jsp?id=3D1202435137932 >> >> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >> >> "Lawyers in the Qualcomm discovery scandal claim that the company >> misled and stonewalled them, ultimately leading to the failure to >> turn over a mountain of relevant evidence and harsh sanctions from >> the court." >> >> The allegations were made in briefs filed Monday by lawyers from >> the now-defunct Day Casebeer Batchelder & Madrid >> , who for the >> >> first time are telling their side of what has become the most >> infamous discovery fiasco in recent times >> < >> http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D90000550495= 4>. >> >> >> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara >> Major in January 2008 for intentionally withholding "tens of >> thousands of e-mails" in an infringement case against Broadcom >> Corp. involving video compression technology patents. The >> company's lawyers -- six from Day Casebeer and one from Heller >> Ehrman -- were also sanctioned for assisting "Qualcomm in >> committing this incredible discovery violation," either knowingly >> or recklessly, Major wrote at the time." >> >> >> stephen botzko wrote: >> >>> As Stephan Wenger indicated, it is not clear if the JVT actually >>> failed or not. What is clear is that they did everything they >>> reasonably could have done. There were several folks >>> participating who took the royalty-free baseline profile >>> objective very seriously. >>> >>> Again, all submitted IPR for the baseline tools indicated royalty >>> free terms. So the JVT had every reason to think they had >>> succeeded. By the time this IPR turned up, H.264 had been >>> standardized for over 2 years. H.264 implementations were >>> already out there - so any attempts to do work-arounds would have >>> broken existing implementations (including implementations in >>> silicon). >>> Certainly any existing IETF group would have presumed exactly the >>> same thing the JVT did. The lesson here is that even if the SDO >>> is conscientious, an unencumbered codec can not be guaranteed. I >>> don't see any other way to read this. >>> >>> Stephen Botzko >>> Polycom >>> >>> >>> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >>> > wrote= : >>> >>> stephen botzko wrote: >>> >>>> >>> >>>> To date neither ITU-T nor MPEG have ever delivered on this >>>> royalty free undertaking. >>>> >>> >>>> That should be viewed as very *bad* news here, since all the >>>> IPR declarations in JVT for the baseline tools indicated >>>> royalty free terms. In other words, the SDOs did everything >>>> possible to deliver, and when H.264 baseline was >>>> standardized they thought they had succeeded. >>>> >>> I'd suggest that it is hard to see things this way after reading >>> >>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>> >>> The process was enforceable, and enforced. >>> The patents could have been found earlier, and removed. >>> >>> So any "h.264 successor" type work (audio/video/transport) >>> should complete, not drop, the royalty free undertaking. >>> IETF and ITU-T should lead there, not give up or hide in a niche. >>> >>> See November 10, 2009 "Preliminary call for proposals signals >>> work start for H.264/MPEG-4 AVC successor" >>> >>> >>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals= +Work+Start+For+H264MPEG4+AVC+Successor.aspx >>> >>> Rob >>> >>> >>> Stephen Botzko >>>> Polycom. >>>> >>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >>>> >>> > wrote: >>>> >>>> BTW I hear that in MPEG the Chinese National Body >>>> initiated a (re)consideration of royalty free >>>> standardization and MPEG has issued a call for comments >>>> to other national bodies. >>>> >>>> Someone may want to contact their national MPEG Head of >>>> Delegation or numerous liaisons including IETF, listed >>>> at http://www.itscj.ipsj.or.jp/sc29/. >>>> >>>> At the same time, MPEG is also considering launching new >>>> royalty bearing activities HVC (High Performance Video >>>> Coding) and MMT (Multimedia Transport). >>>> http://www.chiariglione.org/mpeg/working_documents.htm >>>> >>>> You may recall that h.264 was launched in 2001 as a >>>> joint project between ITU-T Q.6/SG16 and ISO/IEC JTC >>>> 1/SC 29/WG11 with the undertaking that the "JVT [Joint >>>> Video Team] will define a =93baseline=94 profile. That >>>> profile should be royalty-free for all implementations." >>>> To date neither ITU-T nor MPEG have ever delivered on >>>> this royalty free undertaking. >>>> >>>> Rob >>>> >>>> Eric Burger wrote: >>>> >>>> Thank you to everyone who participated in the room >>>> and remotely. We succeeded in getting a lot of work >>>> done, and we have a sense of whether or not we have >>>> a well-formed problem to solve, if there are people >>>> who need the work product, if people are willing to >>>> work on it, and if the IETF is an acceptable venue >>>> to do the work. In addition, we learned a lot about >>>> the possibilities for cooperating with ITU-T SG 16. >>>> >>>> Please review the minutes and send corrections. >>>> >>>> The minutes are posted to: >>>> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>> >>> >> >> > --0016e65a044ee73d120478904f89 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The draft calls for proposals (there are act= ually 2, one from the ITU-T and one from ISO/IEC) start the process.=A0 Responses are not profile-specific (since there are no profiles defined at this point).=A0 There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.=A0 There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationall= y.

Having attended some of these meetings, I think it is premature to say who = has the upper hand.=A0 The effort is just beginning, and almost all of the = meeting focus has been on technical requirements and terms of reference.
Stephen Botzko
Polycom

<= br>

On Tue, Nov 17, 2009 at 6:37 AM, Rob = Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateu= r search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who= dropped it and when and whether the ball was yanked from their hands or we= re outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-f= ree at all. =A0So it is clear who has upper hand now -- and this should not= be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize = the JVT at all, I think that your own posts left a false impression that so= mehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) = could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of =A0US patents (+ the millions more fi= led in other countries) is not a practical answer. =A0Perhaps a limited sea= rch would have caught some patents. =A0But it would not even come close to = catching them all.

And of course there are cases where the granted claims are hard to interpre= t, even if you have access to the prosecution history. And others where the= claims are actually invalid. =A0Even a limited search could be quite expen= sive (and an amateur search done without lawyers would IMHO be a waste of t= ime)..

The JVT made a noble effort, and I really don't see how a normal SDO (i= ncluding the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mail= to:rob.glidd= en@sbcglobal.net>> wrote:

=A0 =A0There is another way to read this.

=A0 =A0This case has been called "the most infamous discovery fiasco = in
=A0 =A0recent times":

=A0 =A0- The lawyers were sanctioned
=A0 =A0- The patents were held both unenforceable and inapplicable
=A0 =A0- Fines were levied
=A0 =A0- The law firm crumbled and was sold

=A0 =A0But read the case: =A0these were not patents that turned up two
=A0 =A0years later. =A0The two were issued and therefore public in 1995 an= d
=A0 =A01996 (5 years before the JVT), and had been presented to the MPEG =A0 =A0committee before.

=A0 =A0Going forward, a more proactive ex ante assessment of known
=A0 =A0patents, at least of the participants in the activity, rather than<= br> =A0 =A0just relying on statements, would be good practice to check for
=A0 =A0blocking patents.

=A0 =A0But yes, you are right the court did not blame the JVT process and<= br> =A0 =A0certainly not those who took the royalty-free objective
=A0 =A0seriously. =A0Clearly not everyone shared that goal, and got caught=
=A0 =A0in subverting it.

=A0 =A0But no, the subsequent ITU/ISO/IEC Common Patent Policy did more =A0 =A0than just keep presuming that such things never occur and accept =A0 =A0being blind sided, and has tightened its IPR policy (which
=A0 =A0provides for third-parties coming forward with blocking info).

=A0 =A0And yes, any one can sue about anything, and they can lie about
=A0 =A0their participation in a standards group. =A0They can fail to
=A0 =A0disclose. =A0They can assert patents that end up being ruled as
=A0 =A0inapplicable. =A0Maybe they will get away with it, or maybe as in =A0 =A0this case they won't.

=A0 =A0But that isn't a good reason to fail to develop the standards t= he
=A0 =A0Web needs for its open, royalty-free future. =A0Rather, the
=A0 =A0opposite. If it takes this kind of extreme behavior and it still =A0 =A0doesn't work, then time to keep moving forward with royalty-fre= e
=A0 =A0standardization.

=A0 =A0Rob

=A0 =A0http://www.law.com/jsp/article.jsp?id=3D1202435137932<= br>
=A0 =A0"Lawyers in Discovery Scandal Say Qualcomm Lied", Novembe= r 3, 2009

=A0 =A0"Lawyers in the Qualcomm discovery scandal claim that the comp= any
=A0 =A0misled and stonewalled them, ultimately leading to the failure to =A0 =A0turn over a mountain of relevant evidence and harsh sanctions from<= br> =A0 =A0the court."

=A0 =A0The allegations were made in briefs filed Monday by lawyers from =A0 =A0the now-defunct Day Casebeer Batchelder & Madrid
=A0 =A0<http://www.law.com/jsp/article.jsp?id=3D1202431679659<= /a>>, who for the

=A0 =A0first time are telling their side of what has become the most
=A0 =A0infamous discovery fiasco in recent times
=A0 =A0Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara<= br> =A0 =A0Major in January 2008 for intentionally withholding "tens of =A0 =A0thousands of e-mails" in an infringement case against Broadcom=
=A0 =A0Corp. involving video compression technology patents. The
=A0 =A0company's lawyers -- six from Day Casebeer and one from Heller<= br> =A0 =A0Ehrman -- were also sanctioned for assisting "Qualcomm in
=A0 =A0committing this incredible discovery violation," either knowin= gly
=A0 =A0or recklessly, Major wrote at the time."


=A0 =A0stephen botzko wrote:
=
=A0 =A0As Stephan Wenger indicated, it is not clear if the JVT actually =A0 =A0failed or not. =A0What is clear is that they did everything they =A0 =A0reasonably could have done. =A0There were several folks
=A0 =A0participating who took the royalty-free baseline profile
=A0 =A0objective very seriously.

=A0 =A0Again, all submitted IPR for the baseline tools indicated royalty =A0 =A0free terms. =A0So the JVT had every reason to think they had
=A0 =A0succeeded. =A0 =A0By the time this IPR turned up, H.264 had been =A0 =A0standardized for over 2 years. =A0H.264 implementations were
=A0 =A0already out there - so any attempts to do work-arounds would have =A0 =A0broken existing implementations (including implementations in
=A0 =A0silicon).
=A0 =A0Certainly any existing IETF group would have presumed exactly the =A0 =A0same thing the JVT did. =A0The lesson here is that even if the SDO<= br> =A0 =A0is conscientious, an unencumbered codec can not be guaranteed. I =A0 =A0don't see any other way to read this.

=A0 =A0Stephen Botzko
=A0 =A0Polycom


=A0 =A0On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
=A0 =A0<= rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:
=A0 =A0 =A0 =A0stephen botzko wrote:
=A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0To date neither ITU-T nor MPEG have ever delivered on this<= br> =A0 =A0 =A0 =A0royalty free undertaking.
=A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0That should be viewed as very *bad* news here, since all th= e
=A0 =A0 =A0 =A0IPR declarations in JVT for the baseline tools indicated =A0 =A0 =A0 =A0royalty free terms. In other words, the SDOs did everything=
=A0 =A0 =A0 =A0possible to deliver, and when H.264 baseline was
=A0 =A0 =A0 =A0standardized they thought they had succeeded.
=A0 =A0 =A0 =A0I'd suggest that it is hard to see things this way afte= r reading

=A0 =A0 =A0 =A0http://www.cafc.uscourts.gov/opinions/07-1545.pdf<= br>
=A0 =A0 =A0 =A0The process was enforceable, and enforced.
=A0 =A0 =A0 =A0The patents could have been found earlier, and removed.

=A0 =A0 =A0 =A0So any "h.264 successor" type work (audio/video/t= ransport)
=A0 =A0 =A0 =A0should complete, not drop, the royalty free undertaking. = =A0 =A0 =A0 =A0IETF and ITU-T should lead there, not give up or hide in a n= iche.

=A0 =A0 =A0 =A0See November 10, 2009 "Preliminary call for proposals = signals
=A0 =A0 =A0 =A0work start for H.264/MPEG-4 AVC successor"

=A0 =A0 =A0 =A0http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals= +Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

=A0 =A0 =A0 =A0Rob


=A0 =A0 =A0 =A0Stephen Botzko
=A0 =A0 =A0 =A0Polycom.
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
=A0 =A0 =A0 =A0<rob.glidden@sbcglobal.net
=A0 =A0 =A0 =A0<mailto:rob.glidden@sbcglobal.net>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0BTW I hear that in MPEG the Chinese National Body =A0 =A0 =A0 =A0 =A0 =A0initiated a (re)consideration of royalty free
=A0 =A0 =A0 =A0 =A0 =A0standardization and MPEG has issued a call for comm= ents
=A0 =A0 =A0 =A0 =A0 =A0to other national bodies.

=A0 =A0 =A0 =A0 =A0 =A0Someone may want to contact their national MPEG Hea= d of
=A0 =A0 =A0 =A0 =A0 =A0Delegation or numerous liaisons including IETF, lis= ted
=A0 =A0 =A0 =A0 =A0 =A0at http://www.itscj.ipsj.or.jp/sc29/.

=A0 =A0 =A0 =A0 =A0 =A0At the same time, MPEG is also considering launchin= g new
=A0 =A0 =A0 =A0 =A0 =A0royalty bearing activities HVC (High Performance Vi= deo
=A0 =A0 =A0 =A0 =A0 =A0Coding) and MMT (Multimedia Transport).
=A0 =A0 =A0 =A0 =A0 =A0http://www.chiariglione.org/mpeg/working_= documents.htm

=A0 =A0 =A0 =A0 =A0 =A0You may recall that h.264 was launched in 2001 as a=
=A0 =A0 =A0 =A0 =A0 =A0joint project between ITU-T Q.6/SG16 and ISO/IEC JT= C
=A0 =A0 =A0 =A0 =A0 =A01/SC 29/WG11 with the undertaking that the "JV= T [Joint
=A0 =A0 =A0 =A0 =A0 =A0Video Team] will define a =93baseline=94 profile. T= hat
=A0 =A0 =A0 =A0 =A0 =A0profile should be royalty-free for all implementati= ons."
=A0 =A0 =A0 =A0 =A0 =A0To date neither ITU-T nor MPEG have ever delivered = on
=A0 =A0 =A0 =A0 =A0 =A0this royalty free undertaking.

=A0 =A0 =A0 =A0 =A0 =A0Rob

=A0 =A0 =A0 =A0 =A0 =A0Eric Burger wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thank you to everyone who participated in t= he room
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and remotely. We succeeded in getting a lot= of work
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0done, and we have a sense of whether or not= we have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a well-formed problem to solve, if there ar= e people
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0who need the work product, if people are wi= lling to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0work on it, and if the IETF is an acceptabl= e venue
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to do the work. In addition, we learned a l= ot about
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the possibilities for cooperating with ITU-= T SG 16.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please review the minutes and send correcti= ons.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The minutes are posted to:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/proceedings/= 09nov/minutes/codec.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0codec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0codec@ietf.org <mailto:codec@ietf.org> =A0 =A0 =A0 =A0 =A0 =A0codec@ietf.org <mailto:codec@ietf.org>







--0016e65a044ee73d120478904f89-- From rob.glidden@sbcglobal.net Tue Nov 17 04:43: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 3F00C28C0CF for ; Tue, 17 Nov 2009 04:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 ZPxsdOGdpQEV for ; Tue, 17 Nov 2009 04:42:59 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id C26C53A693C for ; Tue, 17 Nov 2009 04:42:59 -0800 (PST) Received: (qmail 45561 invoked from network); 17 Nov 2009 12:42:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5n1SoUcM0GlUEUZxcb+VWABv+6ZMAOdvv4vfXHXQi3qDWB/dlX1b7CKlZPF3raDUqVo8L/qJDHfH0iR4NxmrpnW+LiLuH4LfVLgBNx5Sk5iRKjArIxbSzNKvwHM3tgMLIDZLmdOkTUbOzr3heYP14p6YL1fAfbCJTfqQVfzACac= ; Received: from customer-static-2-62-37.iplannetworks.net (rob.glidden@190.2.62.37 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 17 Nov 2009 04:42:42 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: tsU5MMoVM1k1y5hHE4VWcy3tQsURjt3qdDMd2iNlLJ_b3q..jYXffUhT90MW9lpML5oPT8xCPlePp0e4Y.w6d9nAD7srAu9dZgx_BJyefxwLzZxQ4mg1BfibVPlQWv7oZAKreiPvXVq1ycg0jAe_wbVPSIUHyMJmReGVpazesSQERJdW6wZPJpLw2Vj2AXZXNvcYOsLkqwh2Ai5qNGAXDedQN9JWulJSMlx428Oh.jyWR0VML_6zlnce_wM1f4jIzSL5PrmXK8zboEi7XKjECCesIV_NKiejpoMy_QxTC8lFKYgpGBLs2vLZPBImljKMpOk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B029A3B.6060209@sbcglobal.net> Date: Tue, 17 Nov 2009 04:42:35 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stephen botzko References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> In-Reply-To: <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 12:43:01 -0000 As this thread starts off, there appear to be three.

I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.  Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.

Rob

stephen botzko wrote:

The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process.  Responses are not profile-specific (since there are no profiles defined at this point).  There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.  There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally.

Having attended some of these meetings, I think it is premature to say who has the upper hand.  The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateur search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who dropped it and when and whether the ball was yanked from their hands or were outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-free at all.  So it is clear who has upper hand now -- and this should not be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize the JVT at all, I think that your own posts left a false impression that somehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of  US patents (+ the millions more filed in other countries) is not a practical answer.  Perhaps a limited search would have caught some patents.  But it would not even come close to catching them all.

And of course there are cases where the granted claims are hard to interpret, even if you have access to the prosecution history. And others where the claims are actually invalid.  Even a limited search could be quite expensive (and an amateur search done without lawyers would IMHO be a waste of time)..

The JVT made a noble effort, and I really don't see how a normal SDO (including the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

   There is another way to read this.

   This case has been called "the most infamous discovery fiasco in
   recent times":

   - The lawyers were sanctioned
   - The patents were held both unenforceable and inapplicable
   - Fines were levied
   - The law firm crumbled and was sold

   But read the case:  these were not patents that turned up two
   years later.  The two were issued and therefore public in 1995 and
   1996 (5 years before the JVT), and had been presented to the MPEG
   committee before.

   Going forward, a more proactive ex ante assessment of known
   patents, at least of the participants in the activity, rather than
   just relying on statements, would be good practice to check for
   blocking patents.

   But yes, you are right the court did not blame the JVT process and
   certainly not those who took the royalty-free objective
   seriously.  Clearly not everyone shared that goal, and got caught
   in subverting it.

   But no, the subsequent ITU/ISO/IEC Common Patent Policy did more
   than just keep presuming that such things never occur and accept
   being blind sided, and has tightened its IPR policy (which
   provides for third-parties coming forward with blocking info).

   And yes, any one can sue about anything, and they can lie about
   their participation in a standards group.  They can fail to
   disclose.  They can assert patents that end up being ruled as
   inapplicable.  Maybe they will get away with it, or maybe as in
   this case they won't.

   But that isn't a good reason to fail to develop the standards the
   Web needs for its open, royalty-free future.  Rather, the
   opposite. If it takes this kind of extreme behavior and it still
   doesn't work, then time to keep moving forward with royalty-free
   standardization.

   Rob

   http://www.law.com/jsp/article.jsp?id=1202435137932

   "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

   "Lawyers in the Qualcomm discovery scandal claim that the company
   misled and stonewalled them, ultimately leading to the failure to
   turn over a mountain of relevant evidence and harsh sanctions from
   the court."

   The allegations were made in briefs filed Monday by lawyers from
   the now-defunct Day Casebeer Batchelder & Madrid
   <http://www.law.com/jsp/article.jsp?id=1202431679659>, who for the

   first time are telling their side of what has become the most
   infamous discovery fiasco in recent times
   Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara
   Major in January 2008 for intentionally withholding "tens of
   thousands of e-mails" in an infringement case against Broadcom
   Corp. involving video compression technology patents. The
   company's lawyers -- six from Day Casebeer and one from Heller
   Ehrman -- were also sanctioned for assisting "Qualcomm in
   committing this incredible discovery violation," either knowingly
   or recklessly, Major wrote at the time."


   stephen botzko wrote:
   As Stephan Wenger indicated, it is not clear if the JVT actually
   failed or not.  What is clear is that they did everything they
   reasonably could have done.  There were several folks
   participating who took the royalty-free baseline profile
   objective very seriously.

   Again, all submitted IPR for the baseline tools indicated royalty
   free terms.  So the JVT had every reason to think they had
   succeeded.    By the time this IPR turned up, H.264 had been
   standardized for over 2 years.  H.264 implementations were
   already out there - so any attempts to do work-arounds would have
   broken existing implementations (including implementations in
   silicon).
   Certainly any existing IETF group would have presumed exactly the
   same thing the JVT did.  The lesson here is that even if the SDO
   is conscientious, an unencumbered codec can not be guaranteed. I
   don't see any other way to read this.

   Stephen Botzko
   Polycom


   On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
   <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

       stephen botzko wrote:
       >>>
       To date neither ITU-T nor MPEG have ever delivered on this
       royalty free undertaking.
       >>>
       That should be viewed as very *bad* news here, since all the
       IPR declarations in JVT for the baseline tools indicated
       royalty free terms. In other words, the SDOs did everything
       possible to deliver, and when H.264 baseline was
       standardized they thought they had succeeded.
       I'd suggest that it is hard to see things this way after reading

       http://www.cafc.uscourts.gov/opinions/07-1545.pdf

       The process was enforceable, and enforced.
       The patents could have been found earlier, and removed.

       So any "h.264 successor" type work (audio/video/transport)
       should complete, not drop, the royalty free undertaking.        IETF and ITU-T should lead there, not give up or hide in a niche.

       See November 10, 2009 "Preliminary call for proposals signals
       work start for H.264/MPEG-4 AVC successor"

       http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

       Rob


       Stephen Botzko
       Polycom.
       
       On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
       <rob.glidden@sbcglobal.net
       <mailto:rob.glidden@sbcglobal.net>> wrote:

           BTW I hear that in MPEG the Chinese National Body
           initiated a (re)consideration of royalty free
           standardization and MPEG has issued a call for comments
           to other national bodies.

           Someone may want to contact their national MPEG Head of
           Delegation or numerous liaisons including IETF, listed
           at http://www.itscj.ipsj.or.jp/sc29/.

           At the same time, MPEG is also considering launching new
           royalty bearing activities HVC (High Performance Video
           Coding) and MMT (Multimedia Transport).
           http://www.chiariglione.org/mpeg/working_documents.htm

           You may recall that h.264 was launched in 2001 as a
           joint project between ITU-T Q.6/SG16 and ISO/IEC JTC
           1/SC 29/WG11 with the undertaking that the "JVT [Joint
           Video Team] will define a “baseline” profile. That
           profile should be royalty-free for all implementations."
           To date neither ITU-T nor MPEG have ever delivered on
           this royalty free undertaking.

           Rob

           Eric Burger wrote:

               Thank you to everyone who participated in the room
               and remotely. We succeeded in getting a lot of work
               done, and we have a sense of whether or not we have
               a well-formed problem to solve, if there are people
               who need the work product, if people are willing to
               work on it, and if the IETF is an acceptable venue
               to do the work. In addition, we learned a lot about
               the possibilities for cooperating with ITU-T SG 16.

               Please review the minutes and send corrections.

               The minutes are posted to:
               http://www.ietf.org/proceedings/09nov/minutes/codec.txt
               _______________________________________________
               codec mailing list
               codec@ietf.org <mailto:codec@ietf.org>

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


           _______________________________________________
           codec mailing list
           codec@ietf.org <mailto:codec@ietf.org> 








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

From rob.glidden@sbcglobal.net Tue Nov 17 04:47: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 74DC93A68EF for ; Tue, 17 Nov 2009 04:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 DdOZ5bg-yEm5 for ; Tue, 17 Nov 2009 04:47:06 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 43F273A67AC for ; Tue, 17 Nov 2009 04:47:01 -0800 (PST) Received: (qmail 46748 invoked from network); 17 Nov 2009 12:47:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hRmqq09Z0c+0oeFUaKO8pkEyHJteQJPC5Dey4QmPpME5FjWHmwMWsHNNI117nxcuxWmrqS7yzwNyiCJM8vq/WRxslIaSOGJzjVziq2tB+F1b9nO2BWb4J6RuCB94CzvAuwzNvHwYK8wulVjI0irTvriZq2PCzPkXBbS0/SPPr9M= ; Received: from customer-static-2-62-37.iplannetworks.net (rob.glidden@190.2.62.37 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 17 Nov 2009 04:46:59 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: RdOG2R8VM1llApMLDAn2xKivgDIL3TukQSuA_IBo1o_bkUVtdPYbHqXzXsYMLtucqDhvfPaezvzspEC.rCRNNZ7ZDK3SMePPclmhLbQ6SP8.ZgSzIkKbH3KtlqiCR3em6kZFXaZ.QE2Az4A97l55ZL3vbl_bqzRT_SIocidK8lj_Q5Nj0TgeN5SHL2OBYYZEWOL8bYbuFsEa2dlbsKoDx6Fbin8IqbrILKzRHrx9ip9yHOsCDYyqT0FoohXtPFk5A03wNq1r_Knc.xLW8F51Ai.wbYv8V4JStQSPFoPLJsskiIQINGwKHU.U9KLOhmgr4e4DR2v4nhZV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B029B3F.5080804@sbcglobal.net> Date: Tue, 17 Nov 2009 04:46:55 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stephen botzko References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> In-Reply-To: <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 12:47:08 -0000 You jest of course, but of course the opposite. Trust but verify. Rob stephen botzko wrote: > Perhaps you should add the word "sincere" to the proposed codec > charter. That would certainly fix it. > > Stephen Botzko > Polycom > > On Tue, Nov 17, 2009 at 6:28 AM, Rob Glidden > > wrote: > > Stephan: > > It doesn't appear there was ever much more than a paper consensus > that was undermined by 2003 (see previous email) when patent pools > started announcing coverage of the h.264 baseline (years before > the Qualcomm litigation). > > As the impressive curriculum states on 2001-2003 time frame: > > "Fought the political battles to make those contributions pass, > despite substantial resistance from some of the largest companies > in the field." > > http://www.stewe.org/cv-business-wenger.pdf > > So I'd suggest a different interpretation, one that does not > assume there was a sincere or sustained political consensus. > Accepting this, a more realistic forward look is possible. > > Rob > > > > Stephan Wenger wrote: >> Hi Rob, >> >> I will not comment more on the BC/QC San Diego case, except to >> say that misconduct before the standardization committee >> (violation of both written and de-facto practiced rules of the >> committee) was only one and, as some people have argued, small >> factor in the ruling. I wish one could come to the conclusion >> that any misconduct before a standardization committee would >> automatically render related patents unenforceable (the >> inapplicable part is a very different story), but I fear that >> this is too much to hope for. >> >> My current view of the likeliness of success of Codec in relation >> to JVT’s success or failure (depending whom you ask): >> >> 1. JVT took on the creation a /royalty-free/ /baseline /(that >> is, a part of a standard only, and rightholders may still >> require a signed license that may be encumbered to the >> point where it becomes unusable for some open source >> communities—clearly a factor for some software companies), >> in a /heavily patented field./ The vast majority of the >> participating companies—enough to create a consensus-based >> decision in the committee, and many of them known or likely >> future rightholders—was /in support/ of that goal. >> 2. Codec attempts to take on of creating a /standard /(not >> only a baseline of a standard—rightholders cannot be >> appeased by arguing they can make money from non-baseline >> applications) under what the BOF chairs called “acceptable >> terms”--which translate to an /open-source friendly >> non-assert requirement/. The field of technology is at >> least as /heavily patented/ as video. A /significant >> percentage/ of companies known to hold a sizeable portfolio >> of audio/speech codec patents have spoken quite /clearly >> against the goal/. It’s not up to me to declare an IETF >> consensus on whether acceptable terms are achievable, but >> if someone were a declaring such a consensus, I would >> object—and I’m sure I would not be alone. In fact, >> “acceptable terms”, by policy cannot and will not be a hard >> requirement for the work of a hypothetical codec WG. >> >> Based on these perceptions and facts it seems obvious that it’s >> going to be much harder to achieve—that is also: easier to >> prevent for those not amicable—the goals of a hypothetical codec >> WG when compared to the goals of JVT. >> Regards, >> Stephan >> >> >> On 11/15/09 3:17 PM, "Rob Glidden" > > wrote: >> >> There is another way to read this. >> >> This case has been called "the most infamous discovery fiasco >> in recent times": >> >> - The lawyers were sanctioned >> - The patents were held both unenforceable and inapplicable >> - Fines were levied >> - The law firm crumbled and was sold >> >> But read the case: these were not patents that turned up two >> years later. The two were issued and therefore public in >> 1995 and 1996 (5 years before the JVT), and had been >> presented to the MPEG committee before. >> >> Going forward, a more proactive ex ante assessment of known >> patents, at least of the participants in the activity, rather >> than just relying on statements, would be good practice to >> check for blocking patents. >> >> But yes, you are right the court did not blame the JVT >> process and certainly not those who took the royalty-free >> objective seriously. Clearly not everyone shared that goal, >> and got caught in subverting it. >> >> But no, the subsequent ITU/ISO/IEC Common Patent Policy did >> more than just keep presuming that such things never occur >> and accept being blind sided, and has tightened its IPR >> policy (which provides for third-parties coming forward with >> blocking info). >> >> And yes, any one can sue about anything, and they can lie >> about their participation in a standards group. They can >> fail to disclose. They can assert patents that end up being >> ruled as inapplicable. Maybe they will get away with it, or >> maybe as in this case they won't. >> >> But that isn't a good reason to fail to develop the standards >> the Web needs for its open, royalty-free future. Rather, the >> opposite. If it takes this kind of extreme behavior and it >> still doesn't work, then time to keep moving forward with >> royalty-free standardization. >> >> Rob >> >> http://www.law.com/jsp/article.jsp?id=1202435137932 >> >> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, >> 2009 >> >> "Lawyers in the Qualcomm discovery scandal claim that the >> company misled and stonewalled them, ultimately leading to >> the failure to turn over a mountain of relevant evidence and >> harsh sanctions from the court." >> >> The allegations were made in briefs filed Monday by lawyers >> from the now-defunct Day Casebeer Batchelder & Madrid >> , who >> for the first time are telling their side of what has become >> the most infamous discovery fiasco in recent times >> >> . >> >> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge >> Barbara Major in January 2008 for intentionally withholding >> "tens of thousands of e-mails" in an infringement case >> against Broadcom Corp. involving video compression technology >> patents. The company's lawyers -- six from Day Casebeer and >> one from Heller Ehrman -- were also sanctioned for assisting >> "Qualcomm in committing this incredible discovery violation," >> either knowingly or recklessly, Major wrote at the time." >> >> stephen botzko wrote: >> >> As Stephan Wenger indicated, it is not clear if the JVT >> actually failed or not. What is clear is that they did >> everything they reasonably could have done. There were >> several folks participating who took the royalty-free >> baseline profile objective very seriously. >> >> Again, all submitted IPR for the baseline tools indicated >> royalty free terms. So the JVT had every reason to think >> they had succeeded. By the time this IPR turned up, >> H.264 had been standardized for over 2 years. H.264 >> implementations were already out there - so any attempts >> to do work-arounds would have broken existing >> implementations (including implementations in silicon). >> >> Certainly any existing IETF group would have presumed >> exactly the same thing the JVT did. The lesson here is >> that even if the SDO is conscientious, an unencumbered >> codec can not be guaranteed. I don't see any other way to >> read this. >> >> Stephen Botzko >> Polycom >> >> >> >> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >> > > wrote: >> >> >> >> >> stephen botzko wrote: >> >> >>> >> To date neither ITU-T nor MPEG have ever >> delivered on this royalty free undertaking. >> >>> >> That should be viewed as very *bad* news here, >> since all the IPR declarations in JVT for the >> baseline tools indicated royalty free terms. In >> other words, the SDOs did everything possible to >> deliver, and when H.264 baseline was standardized >> they thought they had succeeded. >> >> >> >> I'd suggest that it is hard to see things this way >> after reading >> >> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >> >> The process was enforceable, and enforced. >> The patents could have been found earlier, and removed. >> >> So any "h.264 successor" type work >> (audio/video/transport) should complete, not drop, >> the royalty free undertaking. IETF and ITU-T should >> lead there, not give up or hide in a niche. >> >> See November 10, 2009 "Preliminary call for proposals >> signals work start for H.264/MPEG-4 AVC successor" >> >> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx >> >> Rob >> >> >> >> >> Stephen Botzko >> Polycom. >> >> >> >> >> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >> > > wrote: >> >> >> BTW I hear that in MPEG the Chinese National >> Body initiated a (re)consideration of royalty >> free standardization and MPEG has issued a >> call for comments to other national bodies. >> >> Someone may want to contact their national >> MPEG Head of Delegation or numerous liaisons >> including IETF, listed at >> http://www.itscj.ipsj.or.jp/sc29/. >> >> At the same time, MPEG is also considering >> launching new royalty bearing activities HVC >> (High Performance Video Coding) and MMT >> (Multimedia Transport). >> http://www.chiariglione.org/mpeg/working_documents.htm >> >> You may recall that h.264 was launched in >> 2001 as a joint project between ITU-T >> Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with >> the undertaking that the "JVT [Joint Video >> Team] will define a “baseline” profile. That >> profile should be royalty-free for all >> implementations." To date neither ITU-T nor >> MPEG have ever delivered on this royalty free >> undertaking. >> >> Rob >> >> Eric Burger wrote: >> >> >> Thank you to everyone who participated in >> the room and remotely. We succeeded in >> getting a lot of work done, and we have a >> sense of whether or not we have a >> well-formed problem to solve, if there >> are people who need the work product, if >> people are willing to work on it, and if >> the IETF is an acceptable venue to do the >> work. In addition, we learned a lot about >> the possibilities for cooperating with >> ITU-T SG 16. >> >> Please review the minutes and send >> corrections. >> >> The minutes are posted to: >> http://www.ietf.org/proceedings/09nov/minutes/codec.txt >> _______________________________________________ >> 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 rob.glidden@sbcglobal.net Tue Nov 17 04:57: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 39A3A28C0F0 for ; Tue, 17 Nov 2009 04:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 72zeHa9bi7tg for ; Tue, 17 Nov 2009 04:57:03 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id B88A93A6801 for ; Tue, 17 Nov 2009 04:57:02 -0800 (PST) Received: (qmail 58340 invoked from network); 17 Nov 2009 12:57:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OvKZx3NeR/+LdLOsEyWzBzwSAH+CRQajqM5fp5x9I9NoHukNIQoV76afZ8nNG/+aonpwoi2NNuSeBy1C5JmhNWI3QwQfkLqF3/weUF2Q5sESs82aC2+uIDNleCOzp6X8r8itpAKzPw1fXzSpk6q99mdf5znb+VkvyfQMiPVWwSg= ; Received: from customer-static-2-62-37.iplannetworks.net (rob.glidden@190.2.62.37 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 17 Nov 2009 04:57:01 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: FfpTnXoVM1mO13yvha7h8bUj.s.JuiMgIiBpOWUnVm6QFUkMsyy759dh_Ubf4AnOVcM6gzSaBT767ym2IIu_49ANyf9w92FXsnHH8irksPW93QWVFTju6YU4k9Z_0G5w73JysGkS863_tmN51KtCjXKQkSncU1MF1jaUkEUmN1rN_13.Utv_hdCPQDaELN2i1vngDse3Xj4hEP5jtrcVZq_kADnZ7_H2Sm5M6F_1AJ9YIjESetMaK4OuGM6RkgqdORblzS2lvbahwcX8zkv6ZjwzRvvyvbeRwjpecO0mtYIVPl8wU5s0_rfVZfRiyB0jDNAzmWcUS31eTcEOHUZ8liWyIpxxNj2B2eOk52l2HrZTqp_V7qFrrJlXe2ZcyCyl70TRMQXkhaZJ3mRNPdV2gH9dhla3ctOClwfxOjgw8R3J3Mnj52xhI.KGoGzzT_w0U8tVt2mTS53Q3MQYuel4I.8rmyAPCAWHufkTWQphb0z0XFaJFlueMr0PWyE6z2bgGs0LHXAHZ1.Bit9IEYsQXO2KbKQxxBULyvoSSKIHUkw2tBZwn5SgxBh8ZTWr0IBApajgWrCLFzcnRPY5tWXuA4ynQfbqPuyRnsWMiU951zEbLCmerwVgduG7P1ej._M_.WlnJYvOA7J9XZNHYUIPXiyQopC7BS_tAwvN8BvjVYubvrYywQ.EoyBz29Qpv59uZ2GWHHjDiUdU46JJpUuGSL_VBTkv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B029D9B.1010408@sbcglobal.net> Date: Tue, 17 Nov 2009 04:56:59 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stephen botzko References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4AFE9795.7030706@sbcglobal.net> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> <4B029A3B.6060209@sbcglobal.net> In-Reply-To: <4B029A3B.6060209@sbcglobal.net> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 12:57:05 -0000 And of course, a public draft call for proposals, a "preliminary official call for submissions...signal work start", is counter to a characterization of preliminary activity for which requirements have not been set.

http://www.itu.int/ITU-T/studygroups/com16/ngvc/

I'd restate my encouragement to any one who cares about royalty free standardization to get to work rather than justify the past or status quo.

Rob

Rob Glidden wrote:
As this thread starts off, there appear to be three.

I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.  Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.

Rob

stephen botzko wrote:

The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process.  Responses are not profile-specific (since there are no profiles defined at this point).  There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.  There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally.

Having attended some of these meetings, I think it is premature to say who has the upper hand.  The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateur search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who dropped it and when and whether the ball was yanked from their hands or were outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-free at all.  So it is clear who has upper hand now -- and this should not be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize the JVT at all, I think that your own posts left a false impression that somehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of  US patents (+ the millions more filed in other countries) is not a practical answer.  Perhaps a limited search would have caught some patents.  But it would not even come close to catching them all.

And of course there are cases where the granted claims are hard to interpret, even if you have access to the prosecution history. And others where the claims are actually invalid.  Even a limited search could be quite expensive (and an amateur search done without lawyers would IMHO be a waste of time)..

The JVT made a noble effort, and I really don't see how a normal SDO (including the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

   There is another way to read this.

   This case has been called "the most infamous discovery fiasco in
   recent times":

   - The lawyers were sanctioned
   - The patents were held both unenforceable and inapplicable
   - Fines were levied
   - The law firm crumbled and was sold

   But read the case:  these were not patents that turned up two
   years later.  The two were issued and therefore public in 1995 and
   1996 (5 years before the JVT), and had been presented to the MPEG
   committee before.

   Going forward, a more proactive ex ante assessment of known
   patents, at least of the participants in the activity, rather than
   just relying on statements, would be good practice to check for
   blocking patents.

   But yes, you are right the court did not blame the JVT process and
   certainly not those who took the royalty-free objective
   seriously.  Clearly not everyone shared that goal, and got caught
   in subverting it.

   But no, the subsequent ITU/ISO/IEC Common Patent Policy did more
   than just keep presuming that such things never occur and accept
   being blind sided, and has tightened its IPR policy (which
   provides for third-parties coming forward with blocking info).

   And yes, any one can sue about anything, and they can lie about
   their participation in a standards group.  They can fail to
   disclose.  They can assert patents that end up being ruled as
   inapplicable.  Maybe they will get away with it, or maybe as in
   this case they won't.

   But that isn't a good reason to fail to develop the standards the
   Web needs for its open, royalty-free future.  Rather, the
   opposite. If it takes this kind of extreme behavior and it still
   doesn't work, then time to keep moving forward with royalty-free
   standardization.

   Rob

   http://www.law.com/jsp/article.jsp?id=1202435137932

   "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

   "Lawyers in the Qualcomm discovery scandal claim that the company
   misled and stonewalled them, ultimately leading to the failure to
   turn over a mountain of relevant evidence and harsh sanctions from
   the court."

   The allegations were made in briefs filed Monday by lawyers from
   the now-defunct Day Casebeer Batchelder & Madrid
   <http://www.law.com/jsp/article.jsp?id=1202431679659>, who for the

   first time are telling their side of what has become the most
   infamous discovery fiasco in recent times
   Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara
   Major in January 2008 for intentionally withholding "tens of
   thousands of e-mails" in an infringement case against Broadcom
   Corp. involving video compression technology patents. The
   company's lawyers -- six from Day Casebeer and one from Heller
   Ehrman -- were also sanctioned for assisting "Qualcomm in
   committing this incredible discovery violation," either knowingly
   or recklessly, Major wrote at the time."


   stephen botzko wrote:
   As Stephan Wenger indicated, it is not clear if the JVT actually
   failed or not.  What is clear is that they did everything they
   reasonably could have done.  There were several folks
   participating who took the royalty-free baseline profile
   objective very seriously.

   Again, all submitted IPR for the baseline tools indicated royalty
   free terms.  So the JVT had every reason to think they had
   succeeded.    By the time this IPR turned up, H.264 had been
   standardized for over 2 years.  H.264 implementations were
   already out there - so any attempts to do work-arounds would have
   broken existing implementations (including implementations in
   silicon).
   Certainly any existing IETF group would have presumed exactly the
   same thing the JVT did.  The lesson here is that even if the SDO
   is conscientious, an unencumbered codec can not be guaranteed. I
   don't see any other way to read this.

   Stephen Botzko
   Polycom


   On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
   <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

       stephen botzko wrote:
       >>>
       To date neither ITU-T nor MPEG have ever delivered on this
       royalty free undertaking.
       >>>
       That should be viewed as very *bad* news here, since all the
       IPR declarations in JVT for the baseline tools indicated
       royalty free terms. In other words, the SDOs did everything
       possible to deliver, and when H.264 baseline was
       standardized they thought they had succeeded.
       I'd suggest that it is hard to see things this way after reading

       http://www.cafc.uscourts.gov/opinions/07-1545.pdf

       The process was enforceable, and enforced.
       The patents could have been found earlier, and removed.

       So any "h.264 successor" type work (audio/video/transport)
       should complete, not drop, the royalty free undertaking.        IETF and ITU-T should lead there, not give up or hide in a niche.

       See November 10, 2009 "Preliminary call for proposals signals
       work start for H.264/MPEG-4 AVC successor"

       http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

       Rob


       Stephen Botzko
       Polycom.
       
       On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
       <rob.glidden@sbcglobal.net
       <mailto:rob.glidden@sbcglobal.net>> wrote:

           BTW I hear that in MPEG the Chinese National Body
           initiated a (re)consideration of royalty free
           standardization and MPEG has issued a call for comments
           to other national bodies.

           Someone may want to contact their national MPEG Head of
           Delegation or numerous liaisons including IETF, listed
           at http://www.itscj.ipsj.or.jp/sc29/.

           At the same time, MPEG is also considering launching new
           royalty bearing activities HVC (High Performance Video
           Coding) and MMT (Multimedia Transport).
           http://www.chiariglione.org/mpeg/working_documents.htm

           You may recall that h.264 was launched in 2001 as a
           joint project between ITU-T Q.6/SG16 and ISO/IEC JTC
           1/SC 29/WG11 with the undertaking that the "JVT [Joint
           Video Team] will define a “baseline” profile. That
           profile should be royalty-free for all implementations."
           To date neither ITU-T nor MPEG have ever delivered on
           this royalty free undertaking.

           Rob

           Eric Burger wrote:

               Thank you to everyone who participated in the room
               and remotely. We succeeded in getting a lot of work
               done, and we have a sense of whether or not we have
               a well-formed problem to solve, if there are people
               who need the work product, if people are willing to
               work on it, and if the IETF is an acceptable venue
               to do the work. In addition, we learned a lot about
               the possibilities for cooperating with ITU-T SG 16.

               Please review the minutes and send corrections.

               The minutes are posted to:
               http://www.ietf.org/proceedings/09nov/minutes/codec.txt
               _______________________________________________
               codec mailing list
               codec@ietf.org <mailto:codec@ietf.org>

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


           _______________________________________________
           codec mailing list
           codec@ietf.org <mailto:codec@ietf.org> 








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


From stephen.botzko@gmail.com Tue Nov 17 07:12: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 C5DD53A697C for ; Tue, 17 Nov 2009 07:12:23 -0800 (PST) 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=[AWL=0.762, 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 EGggInDqEhts for ; Tue, 17 Nov 2009 07:12:21 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 548D13A6970 for ; Tue, 17 Nov 2009 07:12:20 -0800 (PST) Received: by fxm7 with SMTP id 7so76998fxm.29 for ; Tue, 17 Nov 2009 07:12:14 -0800 (PST) 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=5tBg2uh1dn4y3BhZ5zqZsug2hw1+5XCJjU6GGa9g2Bw=; b=Azp4icbfac7Akj/IvZehuDxjqUP5xcFtQ+kC/mKtx6ZfAE7J94pkbAFzDWeVeRHFiu 4NZxfGlZhnKrhnLPdtQSRu+9QCza22A476M+vB7Z2sIYvMkb/9cLby6e1c9RHxtuKodg l8bqIAVg0nYHVd3POTp01UJXqX1fPCaWr1ebE= 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=If7wsxTHpdmhSb61AbnO0fdlHjAaEDav8utq03rMRkQvyGYfxmVaAxFTKQS/5nxtIS kf47IhC8DPE39DzMkMB1Tu80AoJG/zIbezraRHGD4pkpNFQeHaNhGlFb3iJuZ/J2kFtE OOTL1yE3KAxSm/gEuQn8n6c2yyag9KH6cfCow= MIME-Version: 1.0 Received: by 10.103.7.31 with SMTP id k31mr4463423mui.48.1258470733891; Tue, 17 Nov 2009 07:12:13 -0800 (PST) In-Reply-To: <4B029A3B.6060209@sbcglobal.net> References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> <4B029A3B.6060209@sbcglobal.net> Date: Tue, 17 Nov 2009 10:12:13 -0500 Message-ID: <6e9223710911170712i465a4892u4cf6bfaca510b9b4@mail.gmail.com> From: stephen botzko To: Rob Glidden , codec@ietf.org Content-Type: multipart/alternative; boundary=0016364174850dc9d10478928dac Subject: Re: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 15:12:23 -0000 --0016364174850dc9d10478928dac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> As this thread starts off, there appear to be three. >>> Three what? There are two draft calls for proposals, with nearly identical text - one from the ITU-T, and one from ISO/IEC (MPEG). Of course there ar= e many contributions and comments, but only two draft call for proposals that I am aware of. Are you saying there is independent work in a different SDO= ? >>> I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR proces= s to an after-thought, is indeed demonstrative of an upper hand. Consider what this would look like if royalty free had upper hand, equal say, or eve= n a seat at table. >>> >From Polycom's perspective, even an unencumbered video standard would need to significantly out-perform H.264 in order to be worth doing. We are providing H.264 anyway, a new codec would be incremental and not a replacement. Before we add one, we would need to see a clear technical improvement over what we are doing now (or a very strong business reason). Like everyone, we prefer unencumbered technology when we can get it. But better performance is a requirement for us for the next gen video standard. So starting from the technical requirements makes sense for us. If it doesn't outperform H.264, it doesn't matter what the terms are. Obviously there are other business models, and other viewpoints. In the end consensu= s prevails, as it does in the IETF. BTW, "terms of reference" in this context is the organizational framework that the ITU-T and ISO/IEC need to establish in order to work together. Without it, there would be two competing standards under development. IMHO this would be very undesirable. I would suggest that we have gotten seriously off topic, as this is not a video codec list. Stephen Botzko Polycom On Tue, Nov 17, 2009 at 7:42 AM, Rob Glidden wro= te: > As this thread starts off, there appear to be three. > > I would assert that putting beginning business focus on technical > requirements and terms of reference, delaying business model and IPR proc= ess > to an after-thought, is indeed demonstrative of an upper hand. Consider > what this would look like if royalty free had upper hand, equal say, or e= ven > a seat at table. > > Rob > > stephen botzko wrote: > > > The draft calls for proposals (there are actually 2, one from the ITU-T a= nd > one from ISO/IEC) start the process. Responses are not profile-specific > (since there are no profiles defined at this point). There is more than = one > operating point envisioned, but it is rather difficult to figure out what > tools belong to what operating point before you have proposals. > > Also ITU-T and ISO/IEC have not yet worked out terms of reference for thi= s > work. There is a desire (largely shared in both communities) to work > together again, but this has not yet been accomplished organizationally. > > Having attended some of these meetings, I think it is premature to say wh= o > has the upper hand. The effort is just beginning, and almost all of the > meeting focus has been on technical requirements and terms of reference. > > Stephen Botzko > Polycom > > > > > On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden w= rote: > >> Stephen: >> >> Millions of patents, even a limited search could be quite expensive, >> amateur search done without lawyers could be a waste of time. >> >> I believe all could "stipulate" to these points. >> >> But obviously, others did do this work. So better can be done. >> >> Yes, I am critical of JVT for dropping royalty free ball, we can debate >> who dropped it and when and whether the ball was yanked from their hands= or >> were outfoxed, dis-spirited or whatever. >> >> But the new successor call to h.264 drops any public mention of a >> royalty-free at all. So it is clear who has upper hand now -- and this >> should not be acceptable. >> >> Rob >> >> stephen botzko wrote: >> >>> I did read the case. And despite the fact that the court did not >>> criticize the JVT at all, I think that your own posts left a false >>> impression that somehow it did. >>> >>> What you haven't done so far is identify how the IETF (or ITU-T, MPEG) >>> could ensure unencumbered standards with any certainty. >>> >>> Ex-ante assessment of the millions of US patents (+ the millions more >>> filed in other countries) is not a practical answer. Perhaps a limited >>> search would have caught some patents. But it would not even come clos= e to >>> catching them all. >>> >>> And of course there are cases where the granted claims are hard to >>> interpret, even if you have access to the prosecution history. And othe= rs >>> where the claims are actually invalid. Even a limited search could be = quite >>> expensive (and an amateur search done without lawyers would IMHO be a w= aste >>> of time).. >>> >>> The JVT made a noble effort, and I really don't see how a normal SDO >>> (including the IETF) could do much better. >>> >>> Stephen Botzko >>> Polycom >>> >>> On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden >> rob.glidden@sbcglobal.net>> wrote: >>> >>> There is another way to read this. >>> >>> This case has been called "the most infamous discovery fiasco in >>> recent times": >>> >>> - The lawyers were sanctioned >>> - The patents were held both unenforceable and inapplicable >>> - Fines were levied >>> - The law firm crumbled and was sold >>> >>> But read the case: these were not patents that turned up two >>> years later. The two were issued and therefore public in 1995 and >>> 1996 (5 years before the JVT), and had been presented to the MPEG >>> committee before. >>> >>> Going forward, a more proactive ex ante assessment of known >>> patents, at least of the participants in the activity, rather than >>> just relying on statements, would be good practice to check for >>> blocking patents. >>> >>> But yes, you are right the court did not blame the JVT process and >>> certainly not those who took the royalty-free objective >>> seriously. Clearly not everyone shared that goal, and got caught >>> in subverting it. >>> >>> But no, the subsequent ITU/ISO/IEC Common Patent Policy did more >>> than just keep presuming that such things never occur and accept >>> being blind sided, and has tightened its IPR policy (which >>> provides for third-parties coming forward with blocking info). >>> >>> And yes, any one can sue about anything, and they can lie about >>> their participation in a standards group. They can fail to >>> disclose. They can assert patents that end up being ruled as >>> inapplicable. Maybe they will get away with it, or maybe as in >>> this case they won't. >>> >>> But that isn't a good reason to fail to develop the standards the >>> Web needs for its open, royalty-free future. Rather, the >>> opposite. If it takes this kind of extreme behavior and it still >>> doesn't work, then time to keep moving forward with royalty-free >>> standardization. >>> >>> Rob >>> >>> http://www.law.com/jsp/article.jsp?id=3D1202435137932 >>> >>> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >>> >>> "Lawyers in the Qualcomm discovery scandal claim that the company >>> misled and stonewalled them, ultimately leading to the failure to >>> turn over a mountain of relevant evidence and harsh sanctions from >>> the court." >>> >>> The allegations were made in briefs filed Monday by lawyers from >>> the now-defunct Day Casebeer Batchelder & Madrid >>> , who for th= e >>> >>> first time are telling their side of what has become the most >>> infamous discovery fiasco in recent times >>> < >>> http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D9000055049= 54 >>> >. >>> >>> >>> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara >>> Major in January 2008 for intentionally withholding "tens of >>> thousands of e-mails" in an infringement case against Broadcom >>> Corp. involving video compression technology patents. The >>> company's lawyers -- six from Day Casebeer and one from Heller >>> Ehrman -- were also sanctioned for assisting "Qualcomm in >>> committing this incredible discovery violation," either knowingly >>> or recklessly, Major wrote at the time." >>> >>> >>> stephen botzko wrote: >>> >>>> As Stephan Wenger indicated, it is not clear if the JVT actually >>>> failed or not. What is clear is that they did everything they >>>> reasonably could have done. There were several folks >>>> participating who took the royalty-free baseline profile >>>> objective very seriously. >>>> >>>> Again, all submitted IPR for the baseline tools indicated royalty >>>> free terms. So the JVT had every reason to think they had >>>> succeeded. By the time this IPR turned up, H.264 had been >>>> standardized for over 2 years. H.264 implementations were >>>> already out there - so any attempts to do work-arounds would have >>>> broken existing implementations (including implementations in >>>> silicon). >>>> Certainly any existing IETF group would have presumed exactly the >>>> same thing the JVT did. The lesson here is that even if the SDO >>>> is conscientious, an unencumbered codec can not be guaranteed. I >>>> don't see any other way to read this. >>>> >>>> Stephen Botzko >>>> Polycom >>>> >>>> >>>> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden >>>> > >>>> wrote: >>>> >>>> stephen botzko wrote: >>>> >>>>> >>> >>>>> To date neither ITU-T nor MPEG have ever delivered on this >>>>> royalty free undertaking. >>>>> >>> >>>>> That should be viewed as very *bad* news here, since all the >>>>> IPR declarations in JVT for the baseline tools indicated >>>>> royalty free terms. In other words, the SDOs did everything >>>>> possible to deliver, and when H.264 baseline was >>>>> standardized they thought they had succeeded. >>>>> >>>> I'd suggest that it is hard to see things this way after readin= g >>>> >>>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>>> >>>> The process was enforceable, and enforced. >>>> The patents could have been found earlier, and removed. >>>> >>>> So any "h.264 successor" type work (audio/video/transport) >>>> should complete, not drop, the royalty free undertaking. >>>> IETF and ITU-T should lead there, not give up or hide in a niche. >>>> >>>> See November 10, 2009 "Preliminary call for proposals signals >>>> work start for H.264/MPEG-4 AVC successor" >>>> >>>> >>>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signal= s+Work+Start+For+H264MPEG4+AVC+Successor.aspx >>>> >>>> Rob >>>> >>>> >>>> Stephen Botzko >>>>> Polycom. >>>>> >>>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden >>>>> >>>> > wrote: >>>>> >>>>> BTW I hear that in MPEG the Chinese National Body >>>>> initiated a (re)consideration of royalty free >>>>> standardization and MPEG has issued a call for comments >>>>> to other national bodies. >>>>> >>>>> Someone may want to contact their national MPEG Head of >>>>> Delegation or numerous liaisons including IETF, listed >>>>> at http://www.itscj.ipsj.or.jp/sc29/. >>>>> >>>>> At the same time, MPEG is also considering launching new >>>>> royalty bearing activities HVC (High Performance Video >>>>> Coding) and MMT (Multimedia Transport). >>>>> http://www.chiariglione.org/mpeg/working_documents.htm >>>>> >>>>> You may recall that h.264 was launched in 2001 as a >>>>> joint project between ITU-T Q.6/SG16 and ISO/IEC JTC >>>>> 1/SC 29/WG11 with the undertaking that the "JVT [Joint >>>>> Video Team] will define a =93baseline=94 profile. That >>>>> profile should be royalty-free for all implementations." >>>>> To date neither ITU-T nor MPEG have ever delivered on >>>>> this royalty free undertaking. >>>>> >>>>> Rob >>>>> >>>>> Eric Burger wrote: >>>>> >>>>> Thank you to everyone who participated in the room >>>>> and remotely. We succeeded in getting a lot of work >>>>> done, and we have a sense of whether or not we have >>>>> a well-formed problem to solve, if there are people >>>>> who need the work product, if people are willing to >>>>> work on it, and if the IETF is an acceptable venue >>>>> to do the work. In addition, we learned a lot about >>>>> the possibilities for cooperating with ITU-T SG 16. >>>>> >>>>> Please review the minutes and send corrections. >>>>> >>>>> The minutes are posted to: >>>>> http://www.ietf.org/proceedings/09nov/minutes/codec.tx= t >>>>> _______________________________________________ >>>>> 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 listcodec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --0016364174850dc9d10478928dac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 As this thread starts off, there appear to be three.=
>>>
Three what?=A0 There are two draft calls for proposals,= with nearly identical text - one from the ITU-T, and one from ISO/IEC (MPE= G).=A0 Of course there are many contributions and comments, but only two dr= aft call for proposals that I am aware of.=A0 Are you saying there is indep= endent work in a different SDO?

>>>
I would assert that putting beginning business focus on= technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.=A0 Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.
>>>
From Polycom's = perspective, even an unencumbered video standard would need to significantl= y out-perform H.264 in order to be worth doing.=A0 We are providing H.264 a= nyway, a new codec would be incremental and not a replacement.=A0 Before we= add one, we would need to see a clear technical improvement over what we a= re doing now (or a very strong business reason).=A0=A0 Like everyone, we pr= efer unencumbered technology when we can get it.=A0 But better performance = is a requirement for us for the next gen video standard.

So starting from the technical requirements makes sense for us.=A0 If i= t doesn't outperform H.264, it doesn't matter what the terms are.= =A0 Obviously there are other business models, and other viewpoints.=A0 In = the end consensus prevails, as it does in the IETF.

BTW, "terms of reference" in this context is the organization= al framework that the ITU-T and ISO/IEC need to establish in order to work = together.=A0 Without it, there would be two competing standards under devel= opment.=A0 IMHO this would be very undesirable.

I would suggest that we have gotten seriously off topic, as this is not= a video codec list.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 7:42 AM, Rob Glidden <rob.glidden@s= bcglobal.net> wrote:
=20 =20
As this thread starts off, there appear to be three.

I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.=A0 Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.

Rob

stephen botzko wrote:

The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process.=A0 Responses are not profile-specific (since there are no profiles defined at this point).=A0 There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.=A0 There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally.

Having attended some of these meetings, I think it is premature to say who has the upper hand.=A0 The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateur search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who dropped it and when and whether the ball was yanked from their hands or were outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-free at all. =A0So it is clear who has upper hand now -- and this should not be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize the JVT at all, I think that your own posts left a false impression that somehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of =A0US patents (+ the millions more filed in other countries) is not a practical answer. =A0Perhaps a limited search would have caught some patents. =A0But it would not even come close to catching them all.

And of course there are cases where the granted claims are hard to interpret, even if you have access to the prosecution history. And others where the claims are actually invalid. =A0Even a limited search could be quite expensive (and an amateur search done without lawyers would IMHO be a waste of time)..

The JVT made a noble effort, and I really don't see how a normal SDO (including the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

=A0 =A0There is another way to read this.

=A0 =A0This case has been called "the most infamous discovery fiasco i= n
=A0 =A0recent times":

=A0 =A0- The lawyers were sanctioned
=A0 =A0- The patents were held both unenforceable and inapplicable
=A0 =A0- Fines were levied
=A0 =A0- The law firm crumbled and was sold

=A0 =A0But read the case: =A0these were not patents that turned up two
=A0 =A0years later. =A0The two were issued and therefore public in 1995 and=
=A0 =A01996 (5 years before the JVT), and had been presented to the MPEG =A0 =A0committee before.

=A0 =A0Going forward, a more proactive ex ante assessment of known
=A0 =A0patents, at least of the participants in the activity, rather than =A0 =A0just relying on statements, would be good practice to check for
=A0 =A0blocking patents.

=A0 =A0But yes, you are right the court did not blame the JVT process and =A0 =A0certainly not those who took the royalty-free objective
=A0 =A0seriously. =A0Clearly not everyone shared that goal, and got caught<= br> =A0 =A0in subverting it.

=A0 =A0But no, the subsequent ITU/ISO/IEC Common Patent Policy did more
=A0 =A0than just keep presuming that such things never occur and accept
=A0 =A0being blind sided, and has tightened its IPR policy (which
=A0 =A0provides for third-parties coming forward with blocking info).

=A0 =A0And yes, any one can sue about anything, and they can lie about
=A0 =A0their participation in a standards group. =A0They can fail to
=A0 =A0disclose. =A0They can assert patents that end up being ruled as
=A0 =A0inapplicable. =A0Maybe they will get away with it, or maybe as in =A0 =A0this case they won't.

=A0 =A0But that isn't a good reason to fail to develop the standards th= e
=A0 =A0Web needs for its open, royalty-free future. =A0Rather, the
=A0 =A0opposite. If it takes this kind of extreme behavior and it still
=A0 =A0doesn't work, then time to keep moving forward with royalty-free=
=A0 =A0standardization.

=A0 =A0Rob

=A0 =A0http://www.law.com/jsp/article.jsp?id=3D1202435137932
=A0 =A0"Lawyers in Discovery Scandal Say Qualcomm Lied", November= 3, 2009

=A0 =A0"Lawyers in the Qualcomm discovery scandal claim that the compa= ny
=A0 =A0misled and stonewalled them, ultimately leading to the failure to =A0 =A0turn over a mountain of relevant evidence and harsh sanctions from =A0 =A0the court."

=A0 =A0The allegations were made in briefs filed Monday by lawyers from
=A0 =A0the now-defunct Day Casebeer Batchelder & Madrid
=A0 =A0<http://www.law.com/jsp/article.jsp?id=3D1202431679659>, who for the

=A0 =A0first time are telling their side of what has become the most
=A0 =A0infamous discovery fiasco in recent times
=A0 =A0Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara
=A0 =A0Major in January 2008 for intentionally withholding "tens of =A0 =A0thousands of e-mails" in an infringement case against Broadcom<= br> =A0 =A0Corp. involving video compression technology patents. The
=A0 =A0company's lawyers -- six from Day Casebeer and one from Heller =A0 =A0Ehrman -- were also sanctioned for assisting "Qualcomm in
=A0 =A0committing this incredible discovery violation," either knowing= ly
=A0 =A0or recklessly, Major wrote at the time."


=A0 =A0stephen botzko wrote:
=A0 =A0As Stephan Wenger indicated, it is not clear if the JVT actually
=A0 =A0failed or not. =A0What is clear is that they did everything they
=A0 =A0reasonably could have done. =A0There were several folks
=A0 =A0participating who took the royalty-free baseline profile
=A0 =A0objective very seriously.

=A0 =A0Again, all submitted IPR for the baseline tools indicated royalty =A0 =A0free terms. =A0So the JVT had every reason to think they had
=A0 =A0succeeded. =A0 =A0By the time this IPR turned up, H.264 had been
=A0 =A0standardized for over 2 years. =A0H.264 implementations were
=A0 =A0already out there - so any attempts to do work-arounds would have =A0 =A0broken existing implementations (including implementations in
=A0 =A0silicon).
=A0 =A0Certainly any existing IETF group would have presumed exactly the =A0 =A0same thing the JVT did. =A0The lesson here is that even if the SDO =A0 =A0is conscientious, an unencumbered codec can not be guaranteed. I
=A0 =A0don't see any other way to read this.

=A0 =A0Stephen Botzko
=A0 =A0Polycom


=A0 =A0On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
=A0 =A0<rob.glidden@sbcglobal.net <mailto:r= ob.glidden@sbcglobal.net>> wrote:

=A0 =A0 =A0 =A0stephen botzko wrote:
=A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0To date neither ITU-T nor MPEG have ever delivered on this =A0 =A0 =A0 =A0royalty free undertaking.
=A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0That should be viewed as very *bad* news here, since all the=
=A0 =A0 =A0 =A0IPR declarations in JVT for the baseline tools indicated
=A0 =A0 =A0 =A0royalty free terms. In other words, the SDOs did everything<= br> =A0 =A0 =A0 =A0possible to deliver, and when H.264 baseline was
=A0 =A0 =A0 =A0standardized they thought they had succeeded.
=A0 =A0 =A0 =A0I'd suggest that it is hard to see things this way after= reading

=A0 =A0 =A0 =A0http://www.cafc.uscourts.gov/opinions/07-1545.pdf
=A0 =A0 =A0 =A0The process was enforceable, and enforced.
=A0 =A0 =A0 =A0The patents could have been found earlier, and removed.

=A0 =A0 =A0 =A0So any "h.264 successor" type work (audio/video/tr= ansport)
=A0 =A0 =A0 =A0should complete, not drop, the royalty free undertaking. =A0= =A0 =A0 =A0IETF and ITU-T should lead there, not give up or hide in a niche.

=A0 =A0 =A0 =A0See November 10, 2009 "Preliminary call for proposals s= ignals
=A0 =A0 =A0 =A0work start for H.264/MPEG-4 AVC successor"

=A0 =A0 =A0 =A0http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals= +Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

=A0 =A0 =A0 =A0Rob


=A0 =A0 =A0 =A0Stephen Botzko
=A0 =A0 =A0 =A0Polycom.
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
=A0 =A0 =A0 =A0<rob.glidden@sbcglobal.net
=A0 =A0 =A0 =A0<mailto:rob.glidden@sbcglobal.net>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0BTW I hear that in MPEG the Chinese National Body =A0 =A0 =A0 =A0 =A0 =A0initiated a (re)consideration of royalty free
=A0 =A0 =A0 =A0 =A0 =A0standardization and MPEG has issued a call for comme= nts
=A0 =A0 =A0 =A0 =A0 =A0to other national bodies.

=A0 =A0 =A0 =A0 =A0 =A0Someone may want to contact their national MPEG Head= of
=A0 =A0 =A0 =A0 =A0 =A0Delegation or numerous liaisons including IETF, list= ed
=A0 =A0 =A0 =A0 =A0 =A0at http://www.itscj.ipsj.or.jp/sc29/.

=A0 =A0 =A0 =A0 =A0 =A0At the same time, MPEG is also considering launching= new
=A0 =A0 =A0 =A0 =A0 =A0royalty bearing activities HVC (High Performance Vid= eo
=A0 =A0 =A0 =A0 =A0 =A0Coding) and MMT (Multimedia Transport).
=A0 =A0 =A0 =A0 =A0 =A0http://www.chiariglione.org/mpeg/working_d= ocuments.htm

=A0 =A0 =A0 =A0 =A0 =A0You may recall that h.264 was launched in 2001 as a<= br> =A0 =A0 =A0 =A0 =A0 =A0joint project between ITU-T Q.6/SG16 and ISO/IEC JTC=
=A0 =A0 =A0 =A0 =A0 =A01/SC 29/WG11 with the undertaking that the "JVT= [Joint
=A0 =A0 =A0 =A0 =A0 =A0Video Team] will define a =93baseline=94 profile. Th= at
=A0 =A0 =A0 =A0 =A0 =A0profile should be royalty-free for all implementatio= ns."
=A0 =A0 =A0 =A0 =A0 =A0To date neither ITU-T nor MPEG have ever delivered o= n
=A0 =A0 =A0 =A0 =A0 =A0this royalty free undertaking.

=A0 =A0 =A0 =A0 =A0 =A0Rob

=A0 =A0 =A0 =A0 =A0 =A0Eric Burger wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thank you to everyone who participated in th= e room
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and remotely. We succeeded in getting a lot = of work
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0done, and we have a sense of whether or not = we have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a well-formed problem to solve, if there are= people
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0who need the work product, if people are wil= ling to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0work on it, and if the IETF is an acceptable= venue
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to do the work. In addition, we learned a lo= t about
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the possibilities for cooperating with ITU-T= SG 16.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please review the minutes and send correctio= ns.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The minutes are posted to:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/proceedings/0= 9nov/minutes/codec.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0____________________________________________= ___
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0codec mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0codec@ietf.org <mailto:codec@ietf.org> =A0 =A0 =A0 =A0 =A0 =A0= codec@ietf.org <mailto:codec@ietf.org> 








_______________________________________________
codec mailing list
codec@ietf.org

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


--0016364174850dc9d10478928dac-- From singer@apple.com Tue Nov 17 11:27: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 E1E9C3A6A58 for ; Tue, 17 Nov 2009 11:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 5Hd0ycPEOHxg for ; Tue, 17 Nov 2009 11:27:51 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 2E2D63A69EC for ; Tue, 17 Nov 2009 11:27:51 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 15FDB79E63D5 for ; Tue, 17 Nov 2009 11:27:50 -0800 (PST) X-AuditID: 11807136-b7bafae000000e8d-5d-4b02f936c5cf Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay15.apple.com (Apple SCV relay) with SMTP id C2.DA.03725.639F20B4; Tue, 17 Nov 2009 11:27:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: David Singer In-Reply-To: <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> Date: Tue, 17 Nov 2009 11:27:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> To: codec@ietf.org X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 19:27:52 -0000 On Nov 17, 2009, at 3:28 , Rob Glidden wrote: > So I'd suggest a different interpretation, one that does not assume = there was a sincere or sustained political consensus. Accepting this, a = more realistic forward look is possible. You are entitled to your opinions, but the effort was sincere and = sustained on the part of large numbers of participants. This is not the = place to go into where things went wrong, but it is worth noting that = MPEG is looking again into the question of royalty-free standards, and = what was learned from that process. David Singer Multimedia and Software Standards, Apple Inc. From stewe@stewe.org Tue Nov 17 12:26: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 21AB128C0D8 for ; Tue, 17 Nov 2009 12:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.305 X-Spam-Level: * X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 V3100eL8O5bM for ; Tue, 17 Nov 2009 12:26:34 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 9FA5D28C16E for ; Tue, 17 Nov 2009 12:26:33 -0800 (PST) Received: from [192.168.1.107] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 494071-1743317 for ; Tue, 17 Nov 2009 21:26:30 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 17 Nov 2009 12:26:26 -0800 From: Stephan Wenger To: "codec@ietf.org" Message-ID: Thread-Topic: Fodder for thought: OWF agreement to augment the IETF patent policy Thread-Index: AcpnxDyDLHfymT43m0+zqXVGfZIJYw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341305590_11958235" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Subject: [codec] Fodder for thought: OWF agreement to augment the IETF patent policy X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Nov 2009 20:26:38 -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_3341305590_11958235 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, I have mentioned this thing in passing before, but now that the release is official, it may be a good time to remind everyone here. Please take a loo= k at=20 http://openwebfoundation.org/2009/11/introducing-the-open-web-foundation-ag= r eement.html, and, if you like the ideas, have your lawyers take a look at the agreement itself. The agreement is designed to provide an as-bulletproof-as-possible, open source friendly, assurance that both copyright and patent rights required for a spec stay available in for the lifetime of the rights. If a group is able to keep track of all contributors, and all contributors are willing to sign this, it provides IMHO a considerably more solid assurance to users than IETF disclosures alone, at least when considering how most of these disclosures have been phrased in the past. Note that the agreement is designed to be signed after standardization is (almost) done, and, therefore, requires a trust relationship between the parties contributing (which could be informal, but perhaps also documented in the form of IETF IPR disclosures). Note further that this exercise, if adopted, would be in addition to the IETF=B9s standards and IPR processes, an= d not replacing them. Regards, Stephan --B_3341305590_11958235 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Fodder for thought: OWF agreement to augment the IETF patent policy<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi all,<BR> I have mentioned this thing in passing before, but now that the release is = official, it may be a good time to remind everyone here.  Please take a= look at <a href=3D"http://openwebfoundation.org/2009/11/introducing-the-open-= web-foundation-agreement.html">http://openwebfoundation.org/2009/11/introduc= ing-the-open-web-foundation-agreement.html</a>, and, if you like the ideas, = have your lawyers take a look at the agreement itself.  The agreement i= s designed to provide an as-bulletproof-as-possible, open source friendly, a= ssurance that both copyright and patent rights required for a spec stay avai= lable in for the lifetime of the rights.  If a group is able to keep tr= ack of all contributors, and all contributors are willing to sign this, it p= rovides IMHO a considerably more solid assurance to users than IETF disclosu= res alone, at least when considering how most of these disclosures have been= phrased in the past.<BR> Note that the agreement is designed to be signed after standardization is (= almost) done, and, therefore, requires a trust relationship between the part= ies contributing (which could be informal, but perhaps also documented in th= e form of IETF IPR disclosures).  Note further that this exercise, if a= dopted, would be in addition to the IETF’s standards and IPR processes= , and not replacing them.<BR> Regards,<BR> Stephan<BR> <BR>   </SPAN></FONT> </BODY> </HTML> --B_3341305590_11958235-- From stewe@stewe.org Tue Nov 17 12:53:03 2009 Return-Path: <stewe@stewe.org> X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C0C3A69AE for <codec@core3.amsl.com>; Tue, 17 Nov 2009 12:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=1.269, 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 2jcnoqpOJ4jB for <codec@core3.amsl.com>; Tue, 17 Nov 2009 12:52:47 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 9BEBB3A67B4 for <codec@ietf.org>; Tue, 17 Nov 2009 12:52:43 -0800 (PST) Received: from [192.168.1.107] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 494104-1743317 for multiple; Tue, 17 Nov 2009 21:52:24 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 17 Nov 2009 12:52:15 -0800 From: Stephan Wenger <stewe@stewe.org> To: Rob Glidden <rob.glidden@sbcglobal.net> Message-ID: <C7284CFF.1DCB6%stewe@stewe.org> Thread-Topic: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted Thread-Index: Acpnx9fKkrnlNTyxdEmj9ErmSC6fNw== In-Reply-To: <4B0288C5.6000300@sbcglobal.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341307142_12039348" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org, stephen botzko <stephen.botzko@gmail.com> Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " <codec.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/codec> List-Post: <mailto:codec@ietf.org> List-Help: <mailto:codec-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Nov 2009 20:53:03 -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_3341307142_12039348 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Rob, Of course there was resistance against a proposed change in business models for baseline video coding patents, and of course there were political battles (for example on the strategic implications of those changes). What matters, though, is that a considerable percentage of the initial resistanc= e against the Royalty-Free Baseline went away after compelling arguments were made. And that consensus was established, on paper, and in reality. You may disagree, but, bluntly put, I was there and able to observe (however biased my perception may have been), and you were not. I think that this may put me in a slightly better position to recollect and document what happened. The most prominent written evidence of consensus is, of course, the JVT terms of reference (ToR, http://www.itu.int/dms_pub/itu-t/oth/34/01/T34010000010001PDFE.pdf). This document was approved by both the SG16 and MPEG managements and plenaries. Do you really think that either ITU SG16 or MPEG would have declared consensus on something like this if it could have been challenged successfully (for example by a claim of false consensus)? Note further that, once the ToR were in place, the provisions therein were followed in every detail, at least until 2004. (From that time on I attended JVT only sporadically, and I=B9m not in the position to comment. Further, baseline wa= s set in 2003; therefore, provisions directly related to baseline are not overly relevant anymore after 2003). Finally, as you may know, there has been quite a bit of litigation around H.264 recently, but AFAIK, no one has ever challenged the ToR or the operative mode of JVT. (Closest to this came, AFAIK, the BC/QC San Diego case, and we all know where that led to.) Regards, Stephan =20 On 11/17/09 3:28 AM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote: > Stephan: >=20 > It doesn't appear there was ever much more than a paper consensus that wa= s > undermined by 2003 (see previous email) when patent pools started announc= ing > coverage of the h.264 baseline (years before the Qualcomm litigation). >=20 > As the impressive curriculum states on 2001-2003 time frame: >=20 > "Fought the political battles to make those contributions pass, despite > substantial resistance from some of the largest companies in the field." >=20 > http://www.stewe.org/cv-business-wenger.pdf >=20 > So I'd suggest a different interpretation, one that does not assume there= was > a sincere or sustained political consensus. Accepting this, a more realis= tic > forward look is possible. >=20 > Rob >=20 >=20 > Stephan Wenger wrote: >> Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Poste= d Hi >> Rob, >> =20 >> I will not comment more on the BC/QC San Diego case, except to say that >> misconduct before the standardization committee (violation of both writt= en >> and de-facto practiced rules of the committee) was only one and, as some >> people have argued, small factor in the ruling. I wish one could come t= o the >> conclusion that any misconduct before a standardization committee would >> automatically render related patents unenforceable (the inapplicable par= t is >> a very different story), but I fear that this is too much to hope for. >> =20 >> My current view of the likeliness of success of Codec in relation to JVT= =B9s >> success or failure (depending whom you ask): >> =20 >> 1. JVT took on the creation a royalty-free baseline (that is, a part of = a >> standard only, and rightholders may still require a signed license that = may >> be encumbered to the point where it becomes unusable for some open sourc= e >> communities=8Bclearly a factor for some software companies), in a heavily >> patented field. The vast majority of the participating companies=8Benough= to >> create a consensus-based decision in the committee, and many of them kno= wn or >> likely future rightholders=8Bwas in support of that goal. >> 2. Codec attempts to take on of creating a standard (not only a baseline= of a >> standard=8Brightholders cannot be appeased by arguing they can make money = from >> non-baseline applications) under what the BOF chairs called =B3acceptable >> terms=B2--which translate to an open-source friendly non-assert requiremen= t. >> The field of technology is at least as heavily patented as video. A >> significant percentage of companies known to hold a sizeable portfolio o= f >> audio/speech codec patents have spoken quite clearly against the goal. = It=B9s >> not up to me to declare an IETF consensus on whether acceptable terms ar= e >> achievable, but if someone were a declaring such a consensus, I would >> object=8Band I=B9m sure I would not be alone. In fact, =B3acceptable terms=B2, = by >> policy cannot and will not be a hard requirement for the work of a >> hypothetical codec WG. >> 3. =20 >> Based on these perceptions and facts it seems obvious that it=B9s going t= o be >> much harder to achieve=8Bthat is also: easier to prevent for those not >> amicable=8Bthe goals of a hypothetical codec WG when compared to the goals= of >> JVT. =20 >> Regards, >> Stephan >> =20 >> =20 >> On 11/15/09 3:17 PM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote: >> =20 >> =20 >>> There is another way to read this. >>> =20 >>> This case has been called "the most infamous discovery fiasco in recent >>> times": >>> =20 >>> - The lawyers were sanctioned >>> - The patents were held both unenforceable and inapplicable >>> - Fines were levied >>> - The law firm crumbled and was sold >>> =20 >>> But read the case: these were not patents that turned up two years lat= er. >>> The two were issued and therefore public in 1995 and 1996 (5 years befo= re >>> the JVT), and had been presented to the MPEG committee before. >>> =20 >>> Going forward, a more proactive ex ante assessment of known patents, at >>> least of the participants in the activity, rather than just relying on >>> statements, would be good practice to check for blocking patents. >>> =20 >>> But yes, you are right the court did not blame the JVT process and cert= ainly >>> not those who took the royalty-free objective seriously. Clearly not >>> everyone shared that goal, and got caught in subverting it. >>> =20 >>> But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than j= ust >>> keep presuming that such things never occur and accept being blind side= d, >>> and has tightened its IPR policy (which provides for third-parties comi= ng >>> forward with blocking info). >>> =20 >>> And yes, any one can sue about anything, and they can lie about their >>> participation in a standards group. They can fail to disclose. They c= an >>> assert patents that end up being ruled as inapplicable. Maybe they wil= l get >>> away with it, or maybe as in this case they won't. >>> =20 >>> But that isn't a good reason to fail to develop the standards the Web n= eeds >>> for its open, royalty-free future. Rather, the opposite. If it takes t= his >>> kind of extreme behavior and it still doesn't work, then time to keep m= oving >>> forward with royalty-free standardization. >>> =20 >>> Rob >>> =20 >>> http://www.law.com/jsp/article.jsp?id=3D1202435137932 >>> =20 >>> "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009 >>> =20 >>> "Lawyers in the Qualcomm discovery scandal claim that the company misle= d and >>> stonewalled them, ultimately leading to the failure to turn over a moun= tain >>> of relevant evidence and harsh sanctions from the court." >>> =20 >>> The allegations were made in briefs filed Monday by lawyers from the >>> now-defunct Day Casebeer Batchelder & Madrid >>> <http://www.law.com/jsp/article.jsp?id=3D1202431679659> , who for the fir= st >>> time are telling their side of what has become the most infamous discov= ery >>> fiasco in recent times >>> <http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D90000550495= 4> . >>> =20 >>> Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Majo= r in >>> January 2008 for intentionally withholding "tens of thousands of e-mail= s" in >>> an infringement case against Broadcom Corp. involving video compression >>> technology patents. The company's lawyers -- six from Day Casebeer and = one >>> from Heller Ehrman -- were also sanctioned for assisting "Qualcomm in >>> committing this incredible discovery violation," either knowingly or >>> recklessly, Major wrote at the time." >>> =20 >>> stephen botzko wrote: >>> =20 >>>> As Stephan Wenger indicated, it is not clear if the JVT actually faile= d or >>>> not. What is clear is that they did everything they reasonably could = have >>>> done. There were several folks participating who took the royalty-fre= e >>>> baseline profile objective very seriously. >>>> =20 >>>> Again, all submitted IPR for the baseline tools indicated royalty free >>>> terms. So the JVT had every reason to think they had succeeded. By= the >>>> time this IPR turned up, H.264 had been standardized for over 2 years. >>>> H.264 implementations were already out there - so any attempts to do >>>> work-arounds would have broken existing implementations (including >>>> implementations in silicon). >>>> =20 >>>> Certainly any existing IETF group would have presumed exactly the same >>>> thing the JVT did. The lesson here is that even if the SDO is >>>> conscientious, an unencumbered codec can not be guaranteed. I don't se= e any >>>> other way to read this. >>>> =20 >>>> Stephen Botzko >>>> Polycom >>>> =20 >>>> =20 >>>> =20 >>>> On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.ne= t> >>>> wrote: >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> stephen botzko wrote: >>>>> =20 >>>>>>>>> >>> >>>>>> To date neither ITU-T nor MPEG have ever delivered on this royalty f= ree >>>>>> undertaking. >>>>>>>>> >>> >>>>>> That should be viewed as very bad news here, since all the IPR >>>>>> declarations in JVT for the baseline tools indicated royalty free te= rms. >>>>>> In other words, the SDOs did everything possible to deliver, and whe= n >>>>>> H.264 baseline was standardized they thought they had succeeded. >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> I'd suggest that it is hard to see things this way after reading >>>>> =20 >>>>> http://www.cafc.uscourts.gov/opinions/07-1545.pdf >>>>> =20 >>>>> The process was enforceable, and enforced. >>>>> The patents could have been found earlier, and removed. >>>>> =20 >>>>> So any "h.264 successor" type work (audio/video/transport) should >>>>> complete, not drop, the royalty free undertaking. IETF and ITU-T sho= uld >>>>> lead there, not give up or hide in a niche. >>>>> =20 >>>>> See November 10, 2009 "Preliminary call for proposals signals work st= art >>>>> for H.264/MPEG-4 AVC successor" >>>>> =20 >>>>> =20 >>>>> http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signa= ls+Wo >>>>> rk+Start+For+H264MPEG4+AVC+Successor.aspx >>>>> =20 >>>>> Rob=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>> Stephen Botzko >>>>>> Polycom. =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.= net> >>>>>> wrote: >>>>>> =20 >>>>>> =20 >>>>>>> BTW I hear that in MPEG the Chinese National Body initiated a >>>>>>> (re)consideration of royalty free standardization and MPEG has issu= ed a >>>>>>> call for comments to other national bodies. >>>>>>> =20 >>>>>>> Someone may want to contact their national MPEG Head of Delegation = or >>>>>>> numerous liaisons including IETF, listed at >>>>>>> http://www.itscj.ipsj.or.jp/sc29/. >>>>>>> =20 >>>>>>> At the same time, MPEG is also considering launching new royalty be= aring >>>>>>> activities HVC (High Performance Video Coding) and MMT (Multimedia >>>>>>> Transport). http://www.chiariglione.org/mpeg/working_documents.htm >>>>>>> =20 >>>>>>> You may recall that h.264 was launched in 2001 as a joint project >>>>>>> between ITU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undert= aking >>>>>>> that the "JVT [Joint Video Team] will define a =B3baseline=B2 profile. = That >>>>>>> profile should be royalty-free for all implementations." To date ne= ither >>>>>>> ITU-T nor MPEG have ever delivered on this royalty free undertaking= . >>>>>>> =20 >>>>>>> Rob >>>>>>> =20 >>>>>>> Eric Burger wrote: >>>>>>> =20 >>>>>>> =20 Thank you to everyone who participated in the room and remotely. We succeeded in getting a lot of work done, and we have a sense of whether or not we have a well-formed problem to solve, if there are people who need th= e work product, if people are willing to work on it, and if the IETF is an acceptable venue to do the work. In addition, we learned a lot about the possibilities for cooperating with ITU-T SG 16. =20 Please review the minutes and send corrections. =20 The minutes are posted to: http://www.ietf.org/proceedings/09nov/minutes/codec.txt _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 =20 =20 >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> codec mailing list >>>>>>> codec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codec >>>>>>> =20 >>>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> =20 >=20 >=20 --B_3341307142_12039348 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Pos= ted Hi Rob,
Of course there was resistance against a proposed change in business models= for baseline video coding patents, and of course there were political battl= es (for example on the strategic implications of those changes).  What = matters, though, is that a considerable percentage of the initial resistance= against the Royalty-Free Baseline went away after compelling arguments were= made.  And that consensus was established, on paper, and in reality. &= nbsp;You may disagree, but, bluntly put, I was there and able to observe (ho= wever biased my perception may have been), and you were not.  I think t= hat this may put me in a slightly better position to recollect and document = what happened.
The most prominent written evidence of consensus is, of course, the JVT ter= ms of reference (ToR, http://www.itu.int/dms_pub/itu-t/oth/34/01/T340100000= 10001PDFE.pdf).  This document was approved by both the SG16 and MP= EG managements and plenaries.  Do you really think that either ITU SG16= or MPEG would have declared consensus on something like this if it could ha= ve been challenged successfully (for example by a claim of false consensus)?=  Note further that, once the ToR were in place, the provisions therein= were followed in every detail, at least until 2004.  (From that time o= n I attended JVT only sporadically, and I’m not in the position to com= ment.  Further, baseline was set in 2003; therefore, provisions directl= y related to baseline are not overly relevant anymore after 2003).  Fin= ally, as you may know, there has been quite a bit of litigation around H.264= recently, but AFAIK, no one has ever challenged the ToR or the operative mo= de of JVT.  (Closest to this came, AFAIK, the BC/QC San Diego case, and= we all know where that led to.)
Regards,
Stephan    


On 11/17/09 3:28 AM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Stephan:

It doesn't appear there was ever much more than a paper consensus that was = undermined by 2003 (see previous email) when patent pools started announcing= coverage of the h.264 baseline (years before the Qualcomm litigation).

As the impressive curriculum states on 2001-2003 time frame:

"Fought the political battles to make those contributions pass, despit= e substantial resistance from some of the largest companies in the field.&qu= ot;

http://www.stewe.org/= cv-business-wenger.pdf

So I'd suggest a different interpretation, one that does not assume there w= as a sincere or sustained political consensus. Accepting this, a more realis= tic forward look is possible.

Rob


Stephan Wenger wrote:
<= SPAN STYLE=3D'font-size:11pt'> Re: [codec] I wonder what is going on at MPEG, = Re: DRAFT Minutes  Posted Hi Rob,
 
I will not comment more on the BC/QC San Diego case, except to say that mis= conduct before the standardization committee (violation of both written and = de-facto practiced rules of the committee) was only one and, as some people = have argued, small factor in the ruling.  I wish one could come to the = conclusion that any misconduct before a standardization committee would auto= matically render related patents unenforceable (the inapplicable part is a v= ery different story), but I fear that this is too much to hope for.
 
My current view of the likeliness of success of Codec in relation to JVT= 217;s success or failure (depending whom you ask):
  
  1. JVT took on the creation a royalty-free ba= seline (that is, a part of a standard only, and rightholders may still r= equire a signed license that may be encumbered to the point where it becomes= unusable for some open source communities—clearly a factor for some s= oftware companies), in a heavily patented field.  The vast major= ity of the participating companies—enough to create a consensus-based = decision in the committee, and many of them known or likely future righthold= ers—was in support of that goal.=20
  2. Codec attempts to take on of creating a standard = (not only a baseline of a standard—rightholders cannot be appeased by = arguing they can make money from non-baseline applications) under what the B= OF chairs called “acceptable terms”--which translate to an op= en-source friendly non-assert requirement.  The field of technology= is at least as heavily patented as video.  A significant per= centage of companies known to hold a sizeable portfolio of audio/speech = codec patents have spoken quite clearly against the goal.  It= 217;s not up to me to declare an IETF consensus on whether acceptable terms = are achievable, but if someone were a declaring such a consensus, I would ob= ject—and I’m sure I would not be alone.  In fact, “ac= ceptable terms”, by policy cannot and will not be a hard requirement f= or the work of a hypothetical codec WG.=20

Based on these perceptions and facts it seems obvious = that it’s going to be much harder to achieve—that is also: easie= r to prevent for those not amicable—the goals of a hypothetical codec = WG when compared to the goals of JVT.  
Regards,
Stephan
 
 
On 11/15/09 3:17 PM, "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:
 
  
<= SPAN STYLE=3D'font-size:11pt'>There is another way to read this.
 
This case has been called "the most infamous discovery fiasco in recen= t times":
 
- The lawyers were sanctioned
- The patents were held both unenforceable and inapplicable
- Fines were levied
- The law firm crumbled and was sold
 
But read the case:  these were not patents that turned up two years la= ter.  The two were issued and therefore public in 1995 and 1996 (5 year= s before the JVT), and had been presented to the MPEG committee before.
 
Going forward, a more proactive ex ante assessment of known patents, at lea= st of the participants in the activity, rather than just relying on statemen= ts, would be good practice to check for blocking patents.
 
But yes, you are right the court did not blame the JVT process and certainl= y not those who took the royalty-free objective seriously. Clearly not every= one shared that goal, and got caught in subverting it.
 
But no, the subsequent ITU/ISO/IEC Common Patent Policy did more than just = keep presuming that such things never occur and accept being blind sided, an= d has tightened its IPR policy (which provides for third-parties coming forw= ard with blocking info).
 
And yes, any one can sue about anything, and they can lie about their parti= cipation in a standards group.  They can fail to disclose.  They c= an assert patents that end up being ruled as inapplicable.  Maybe they = will get away with it, or maybe as in this case they won't.
 
But that isn't a good reason to fail to develop the standards the Web needs= for its open, royalty-free future.  Rather, the opposite. If it takes = this kind of extreme behavior and it still doesn't work, then time to keep m= oving forward with royalty-free standardization.
 
Rob
 
 http://= www.law.com/jsp/article.jsp?id=3D1202435137932
 
"Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 200= 9
 
"Lawyers in the Qualcomm discovery scandal claim that the company misl= ed and stonewalled them, ultimately leading to the failure to turn over a mo= untain of relevant evidence and harsh sanctions from the court."
 
The allegations were made in briefs filed Monday by lawyers from the now-de= funct Day Casebeer Batchelder & Madrid <http://www.law.com/jsp/article.jsp?id=3D12024= 31679659> , who for the first time are telling their side of what has= become the most infamous discovery fiasco in recent times <http://= www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=3D900005504954> . <= BR>  
Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara Major in= January 2008 for intentionally withholding "tens of thousands of e-mai= ls" in an infringement case against Broadcom Corp. involving video comp= ression technology patents. The company's lawyers -- six from Day Casebeer a= nd one from Heller Ehrman -- were also sanctioned for assisting "Qualco= mm in committing this incredible discovery violation," either knowingly= or recklessly, Major wrote at the time."
 
stephen botzko wrote:
  
<= SPAN STYLE=3D'font-size:11pt'>As Stephan Wenger indicated, it is not clear if = the JVT actually failed or not.  What is clear is that they did everyth= ing they reasonably could have done.  There were several folks particip= ating who took the royalty-free baseline profile objective very seriously.  
Again, all submitted IPR for the baseline tools indicated royalty free term= s.  So the JVT had every reason to think they had succeeded.  &nbs= p; By the time this IPR turned up, H.264 had been standardized for over= 2 years.  H.264 implementations were already out there - so any attemp= ts to do work-arounds would have broken existing implementations (including = implementations in silicon).  
 
Certainly any existing IETF group would have presumed exactly the same thin= g the JVT did.  The lesson here is that even if the SDO is conscientiou= s, an unencumbered codec can not be guaranteed. I don't see any other way to= read this.
 
Stephen Botzko
Polycom
 
 
 
On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 
  
<= SPAN STYLE=3D'font-size:11pt'>
 
stephen botzko wrote:
  
<= SPAN STYLE=3D'font-size:11pt'>>>>
To date neither ITU-T nor MPEG have ever delivered on this royalty free und= ertaking.
>>>
That should be viewed as very bad news here, since all the IPR decla= rations in JVT for the baseline tools indicated royalty free terms. In other= words, the SDOs did everything possible to deliver, and when H.264 baseline= was standardized they thought they had succeeded.
 
 
=  
I'd suggest that it is hard to see things this way after reading
 
 http://ww= w.cafc.uscourts.gov/opinions/07-1545.pdf
 
The process was enforceable, and enforced.
The patents could have been found earlier, and removed.
 
So any "h.264 successor" type work (audio/video/transport) should= complete, not drop, the royalty free undertaking.  IETF and ITU-T shou= ld lead there, not give up or hide in a niche.
 
See November 10, 2009 "Preliminary call for proposals signals work sta= rt for H.264/MPEG-4 AVC successor"
 
 http://www.itu.int/= ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG= 4+AVC+Successor.aspx
 
Rob
 
 
 
  
<= SPAN STYLE=3D'font-size:11pt'>Stephen Botzko
Polycom.  
 
 
 
 
On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
 
  
<= SPAN STYLE=3D'font-size:11pt'>BTW I hear that in MPEG the Chinese National Bod= y initiated a (re)consideration of royalty free standardization and MPEG has= issued a call for comments to other national bodies.
 
Someone may want to contact their national MPEG Head of Delegation or numer= ous liaisons including IETF, listed at http://www.itscj.ipsj.or.jp/sc29/.
 
At the same time, MPEG is also considering launching new royalty bearing ac= tivities HVC (High Performance Video Coding) and MMT (Multimedia Transport).= http://www= .chiariglione.org/mpeg/working_documents.htm
 
You may recall that h.264 was launched in 2001 as a joint project between I= TU-T Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with the undertaking that the &qu= ot;JVT [Joint Video Team] will define a “baseline” profile. That= profile should be royalty-free for all implementations." To date neith= er ITU-T nor MPEG have ever delivered on this royalty free undertaking.
 
Rob
 
Eric Burger wrote:
 
  
htt= p://www.ietf.org/proceedings/09nov/minutes/codec.txt
_______________________________________________
codec mailing list
 codec@ietf.org
 https://www.iet= f.org/mailman/listinfo/codec
 
 
 
<= BLOCKQUOTE>
 
_______________________________________________
codec mailing list
 codec@ietf.org
 https://www.iet= f.org/mailman/listinfo/codec
 
 
=  
 
 
 
=  
 
 
 
 
=  
 
 
=
 
 
___________= ____________________________________
codec mailing list
 codec@ietf.org
 https://www.iet= f.org/mailman/listinfo/codec
 


--B_3341307142_12039348-- From rob.glidden@sbcglobal.net Wed Nov 18 02:31: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 17C513A686C for ; Wed, 18 Nov 2009 02:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 J6a-gV7R+xBq for ; Wed, 18 Nov 2009 02:31:57 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 508F23A6820 for ; Wed, 18 Nov 2009 02:31:57 -0800 (PST) Received: (qmail 5204 invoked from network); 18 Nov 2009 10:31:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=c+qoH9Hki5hSGXlP4M0MMsGihsaTjt57t8aeb1ZoYIuT7od0B/eNChI4GMqwOTaDxFeYJ381zEBt7hVsON6T4ZYjwd8Kz+eAzSAWsHRwHXtuhcOnLA2kTVgT8Pr+zEG2KucXPhsjmbgJ/hld/NHQ5kmUyUY/Vz4A4RZm0+IagpE= ; Received: from 218-142-245-190.fibertel.com.ar (rob.glidden@190.245.142.218 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 18 Nov 2009 02:31:51 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: mj6ihvwVM1kZVFdyS2njSpUXviZSowZzOhs9XRGNvkYhzhzo4IjhiOfuJ7OvP1_C1NY478oSILNqNc0YzCCF6uyZAsXM9GxgCJR3.N6YZPYBqmMaKcg19oy2hJaqGaJB5_zS.BkwFCnykzQCl7Kip.SkhxHl92VWOjXpYtdGEf2RhAhrI0iOChSXWQOrIWGWkkyWCFxmKrwX6eUshMD9u4K1pF.oZKlJMxyvczlT4U_DHkwD.d8lzWE_BpqZOLWfr9XvwTRwzzvDR3geE8Gewu8s7srcMhLU1VSYyZv45oxGwSWtBjlbLyrZDlafNGSE8q7fujythcCFRmJlehSVUPHQlZtl4iSoTOQBo37Q4JoC6bai941wmt1WilFHiu2Y8G40iLy5y6mJ0UhrEQztavBc1GjjKLo1gdEuA3Fpma4VFXSGO3YDpJk6EZHcoQhJR7Ee4AW6KQzjmvPv..GAG1EzxcVdAT2Uu8.NUN1ziXkp2gDfF6Z9F_Ug5FLi6axr_DZ.kcCFuXQlanLRLbLFbcoBsOibmABT.LbusP.KZHFkTox0LjHg4DnYp8cSInKupObG5gjITqswTFITJLgnrei3d0CanHjhWz40oZLeul4sJgjqK.mU8LLIosIhA4X_XJ7W42s_mKHXkSaCOL.MUvKGt3vL3Inx9.x..kFWB5Mrbsxp3BbU_Lslh0sySPWUwbCuluR0sNUdVY3lSGNJ3zdtbit.X3GzeN_AgJ6_w2sXH.Wh..LwAKnf15ILArd7BKkCjkbl4A_R__9TRGQIypKwL6R5Bet.dmHP88Zzm4F8TGsRRyhIqieEi07bmw62Xx6gQLmkCWpuu9AZjp0CbVtqoC9RDn2vZtTVTfpph39egMwmGA181tzphzKwh3MDNimVaQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B03CD08.3080709@sbcglobal.net> Date: Wed, 18 Nov 2009 02:31:36 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stephen botzko References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <6e9223710911140351h3c1bfa96h86a854ff3793d3c2@mail.gmail.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> <4B029A3B.6060209@sbcglobal.net> <6e9223710911170712i465a4892u4cf6bfaca510b9b4@mail.gmail.com> In-Reply-To: <6e9223710911170712i465a4892u4cf6bfaca510b9b4@mail.gmail.com> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 18 Nov 2009 10:31:59 -0000 >From Polycom's perspective, even an unencumbered video standard would need to significantly out-perform H.264 in order to be worth doing.

Interesting, do you think this means that Polycom has dropped its public 2003 support for royalty free baseline or further work in that direction?  And disagrees the views of the MPEG convenor stated below in 2008?  I would hope not.

Rob

http://www.imtc.org/press/pressrel/press022003.asp

http://www.chiariglione.org/leonardo/publications/epo2008/index.asp

"I believe MPEG should enlarge its portfolio of standards by offering some that are expected to be royalty free and typically less performing and with less functionality next to those that are state of the art, more performing and with more functionality.

The problem is of course not in that obligation but in the fact that “fair – reasonable – non discriminatory” used to be meaningful words when standards were designed for the needs of one industry whose members generally shared the business model according to which the standard would be used.

So, the problem is not “how many cents, tens of cent or euros of licensing fee is fair and reasonable” but “how can licensing be fair and reasonable without specifying a business model”. The issue is serious and more than one MPEG standard did not have the acceptance it deserved because the licensing terms, perfectly acceptable and probably “fair and reasonable” for certain business models were rejected by those who had different ideas in mind."



stephen botzko wrote:
>>>
   As this thread starts off, there appear to be three.
>>>
Three what?  There are two draft calls for proposals, with nearly identical text - one from the ITU-T, and one from ISO/IEC (MPEG).  Of course there are many contributions and comments, but only two draft call for proposals that I am aware of.  Are you saying there is independent work in a different SDO?

>>>
I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.  Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.
>>>
>From Polycom's perspective, even an unencumbered video standard would need to significantly out-perform H.264 in order to be worth doing.  We are providing H.264 anyway, a new codec would be incremental and not a replacement.  Before we add one, we would need to see a clear technical improvement over what we are doing now (or a very strong business reason).   Like everyone, we prefer unencumbered technology when we can get it.  But better performance is a requirement for us for the next gen video standard.

So starting from the technical requirements makes sense for us.  If it doesn't outperform H.264, it doesn't matter what the terms are.  Obviously there are other business models, and other viewpoints.  In the end consensus prevails, as it does in the IETF.

BTW, "terms of reference" in this context is the organizational framework that the ITU-T and ISO/IEC need to establish in order to work together.  Without it, there would be two competing standards under development.  IMHO this would be very undesirable.

I would suggest that we have gotten seriously off topic, as this is not a video codec list.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 7:42 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
As this thread starts off, there appear to be three.

I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.  Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.

Rob

stephen botzko wrote:

The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process.  Responses are not profile-specific (since there are no profiles defined at this point).  There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.  There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally.

Having attended some of these meetings, I think it is premature to say who has the upper hand.  The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateur search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who dropped it and when and whether the ball was yanked from their hands or were outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-free at all.  So it is clear who has upper hand now -- and this should not be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize the JVT at all, I think that your own posts left a false impression that somehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of  US patents (+ the millions more filed in other countries) is not a practical answer.  Perhaps a limited search would have caught some patents.  But it would not even come close to catching them all.

And of course there are cases where the granted claims are hard to interpret, even if you have access to the prosecution history. And others where the claims are actually invalid.  Even a limited search could be quite expensive (and an amateur search done without lawyers would IMHO be a waste of time)..

The JVT made a noble effort, and I really don't see how a normal SDO (including the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

   There is another way to read this.

   This case has been called "the most infamous discovery fiasco in
   recent times":

   - The lawyers were sanctioned
   - The patents were held both unenforceable and inapplicable
   - Fines were levied
   - The law firm crumbled and was sold

   But read the case:  these were not patents that turned up two
   years later.  The two were issued and therefore public in 1995 and
   1996 (5 years before the JVT), and had been presented to the MPEG
   committee before.

   Going forward, a more proactive ex ante assessment of known
   patents, at least of the participants in the activity, rather than
   just relying on statements, would be good practice to check for
   blocking patents.

   But yes, you are right the court did not blame the JVT process and
   certainly not those who took the royalty-free objective
   seriously.  Clearly not everyone shared that goal, and got caught
   in subverting it.

   But no, the subsequent ITU/ISO/IEC Common Patent Policy did more
   than just keep presuming that such things never occur and accept
   being blind sided, and has tightened its IPR policy (which
   provides for third-parties coming forward with blocking info).

   And yes, any one can sue about anything, and they can lie about
   their participation in a standards group.  They can fail to
   disclose.  They can assert patents that end up being ruled as
   inapplicable.  Maybe they will get away with it, or maybe as in
   this case they won't.

   But that isn't a good reason to fail to develop the standards the
   Web needs for its open, royalty-free future.  Rather, the
   opposite. If it takes this kind of extreme behavior and it still
   doesn't work, then time to keep moving forward with royalty-free
   standardization.

   Rob

   http://www.law.com/jsp/article.jsp?id=1202435137932

   "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

   "Lawyers in the Qualcomm discovery scandal claim that the company
   misled and stonewalled them, ultimately leading to the failure to
   turn over a mountain of relevant evidence and harsh sanctions from
   the court."

   The allegations were made in briefs filed Monday by lawyers from
   the now-defunct Day Casebeer Batchelder & Madrid
   <http://www.law.com/jsp/article.jsp?id=1202431679659>, who for the

   first time are telling their side of what has become the most
   infamous discovery fiasco in recent times
   Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara
   Major in January 2008 for intentionally withholding "tens of
   thousands of e-mails" in an infringement case against Broadcom
   Corp. involving video compression technology patents. The
   company's lawyers -- six from Day Casebeer and one from Heller
   Ehrman -- were also sanctioned for assisting "Qualcomm in
   committing this incredible discovery violation," either knowingly
   or recklessly, Major wrote at the time."


   stephen botzko wrote:
   As Stephan Wenger indicated, it is not clear if the JVT actually
   failed or not.  What is clear is that they did everything they
   reasonably could have done.  There were several folks
   participating who took the royalty-free baseline profile
   objective very seriously.

   Again, all submitted IPR for the baseline tools indicated royalty
   free terms.  So the JVT had every reason to think they had
   succeeded.    By the time this IPR turned up, H.264 had been
   standardized for over 2 years.  H.264 implementations were
   already out there - so any attempts to do work-arounds would have
   broken existing implementations (including implementations in
   silicon).
   Certainly any existing IETF group would have presumed exactly the
   same thing the JVT did.  The lesson here is that even if the SDO
   is conscientious, an unencumbered codec can not be guaranteed. I
   don't see any other way to read this.

   Stephen Botzko
   Polycom


   On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
   <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

       stephen botzko wrote:
       >>>
       To date neither ITU-T nor MPEG have ever delivered on this
       royalty free undertaking.
       >>>
       That should be viewed as very *bad* news here, since all the
       IPR declarations in JVT for the baseline tools indicated
       royalty free terms. In other words, the SDOs did everything
       possible to deliver, and when H.264 baseline was
       standardized they thought they had succeeded.
       I'd suggest that it is hard to see things this way after reading

       http://www.cafc.uscourts.gov/opinions/07-1545.pdf

       The process was enforceable, and enforced.
       The patents could have been found earlier, and removed.

       So any "h.264 successor" type work (audio/video/transport)
       should complete, not drop, the royalty free undertaking.        IETF and ITU-T should lead there, not give up or hide in a niche.

       See November 10, 2009 "Preliminary call for proposals signals
       work start for H.264/MPEG-4 AVC successor"

       http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

       Rob


       Stephen Botzko
       Polycom.
       
       On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
       <rob.glidden@sbcglobal.net
       <mailto:rob.glidden@sbcglobal.net>> wrote:

           BTW I hear that in MPEG the Chinese National Body
           initiated a (re)consideration of royalty free
           standardization and MPEG has issued a call for comments
           to other national bodies.

           Someone may want to contact their national MPEG Head of
           Delegation or numerous liaisons including IETF, listed
           at http://www.itscj.ipsj.or.jp/sc29/.

           At the same time, MPEG is also considering launching new
           royalty bearing activities HVC (High Performance Video
           Coding) and MMT (Multimedia Transport).
           http://www.chiariglione.org/mpeg/working_documents.htm

           You may recall that h.264 was launched in 2001 as a
           joint project between ITU-T Q.6/SG16 and ISO/IEC JTC
           1/SC 29/WG11 with the undertaking that the "JVT [Joint
           Video Team] will define a “baseline” profile. That
           profile should be royalty-free for all implementations."
           To date neither ITU-T nor MPEG have ever delivered on
           this royalty free undertaking.

           Rob

           Eric Burger wrote:

               Thank you to everyone who participated in the room
               and remotely. We succeeded in getting a lot of work
               done, and we have a sense of whether or not we have
               a well-formed problem to solve, if there are people
               who need the work product, if people are willing to
               work on it, and if the IETF is an acceptable venue
               to do the work. In addition, we learned a lot about
               the possibilities for cooperating with ITU-T SG 16.

               Please review the minutes and send corrections.

               The minutes are posted to:
               http://www.ietf.org/proceedings/09nov/minutes/codec.txt
               _______________________________________________
               codec mailing list
               codec@ietf.org <mailto:codec@ietf.org>

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


           _______________________________________________
           codec mailing list
           codec@ietf.org <mailto:codec@ietf.org> 








_______________________________________________
codec mailing list
codec@ietf.org

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



From rob.glidden@sbcglobal.net Wed Nov 18 02: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 140963A68B1 for ; Wed, 18 Nov 2009 02:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=2.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 PEDWW6EBp8xa for ; Wed, 18 Nov 2009 02:34:45 -0800 (PST) Received: from smtp101.sbc.mail.gq1.yahoo.com (smtp101.sbc.mail.gq1.yahoo.com [67.195.15.60]) by core3.amsl.com (Postfix) with SMTP id 643AC3A686C for ; Wed, 18 Nov 2009 02:34:45 -0800 (PST) Received: (qmail 60462 invoked from network); 18 Nov 2009 10:34:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mvvkNPJM2+ouDrorAfHx5gssvfC3drzRigHXTPhPUOgMnmXraeiUR1F+lktZw6YpvgKwPZW0UOBWN2sE+Myg1u0j9/ou2hZYTNaac+yLlpSB52M6esqaXHJKXUbX6zDiF7JdoWA8QNr+ZnGAcY4MfPw0zOJHUoPD9xmXN7FOTtY= ; Received: from 218-142-245-190.fibertel.com.ar (rob.glidden@190.245.142.218 with plain) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 18 Nov 2009 02:34:42 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: 3tAKW9MVM1k3BynX3f8tmFM6Gj_jjbcyw1z93EqFHIz50H23.Vy4LXbglcbPTSD6raWixVU6b.F2qzsfyxvOWq9aR9O0_6cZk.BBTOsGKFLSuO_N49ixkCqco5vSFxz.AvUhPyv0Ff0Fsm66CTN1RFgLtILujBLNiRHXuVbBmA0ttpvQBVjxECOYL_KI5FGNiB2Zx1SXMzozAztLRpgE70rePkXohplzYmFnojSKVdyhhtYOv1WXnk6KkHoUu9Q0lfvclhC6ChqV8.MOYdcDyFSl6endaLGtqo6ZWy3D9TYzqquCLdAUYNz0XVqQEEhcxWC2LjvGBuqUnoaawQszipaKY1RDiGF9ozV_H9nx4U2gmhoLinAvXEEvCjm1kzuF03S0NP25Umv7uGCwwfOMWcVIyqwUIKFqgXPBc9KL1pXe67B_fBqndUvnGjkfe5ZArXnW8Ai9K.Dh_w2Mif7cr6WhtuENfcbpPvO72CGHIIbECZxw6yTRIr_Ew6CnfmOj_F65eQbxPTP42.dbuBAqIiRT..JcmyEhDPlaBuD7ZaWMGjWd6ByiMzmbXdzCqtK_TKig01AnVyEhH_RRkYDm0wGdkDAL8dSfbOFGuF_KJMesOrw4s8EUmq5xZ5tCWuDlT7NdEwD20b5dA4A2lv3imhK_zYJI8YzIqyR5_I_fJkkFXYu9nF4092rqcNzMujuB_tLvKJ37Gi4_mUCqZ_IqnMCfYxPUHdJ9S6cA1CPcd5Hue9NhD3Id3glajfYOJZKQFMmNOLcV1TPH7vbNm6rNaifi4axmAsoEP6U5HvMrlXcPBRzonjWwCDCD30oGwN0g X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B03CDBE.8040005@sbcglobal.net> Date: Wed, 18 Nov 2009 02:34:38 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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, stephen botzko Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 18 Nov 2009 10:34:47 -0000 >Do you really think that either ITU SG16 or MPEG would have declared consensus on something like this if it could have been challenged successfully (for example by a claim of false consensus)? Stephan: Time has shown that some had very very different views of consensus. Rob Stephan Wenger wrote: > Hi Rob, > Of course there was resistance against a proposed change in business > models for baseline video coding patents, and of course there were > political battles (for example on the strategic implications of those > changes). What matters, though, is that a considerable percentage of > the initial resistance against the Royalty-Free Baseline went away > after compelling arguments were made. And that consensus was > established, on paper, and in reality. You may disagree, but, bluntly > put, I was there and able to observe (however biased my perception may > have been), and you were not. I think that this may put me in a > slightly better position to recollect and document what happened. > The most prominent written evidence of consensus is, of course, the > JVT terms of reference (ToR, > http://www.itu.int/dms_pub/itu-t/oth/34/01/T34010000010001PDFE.pdf). > This document was approved by both the SG16 and MPEG managements and > plenaries. Do you really think that either ITU SG16 or MPEG would have > declared consensus on something like this if it could have been > challenged successfully (for example by a claim of false consensus)? > Note further that, once the ToR were in place, the provisions therein > were followed in every detail, at least until 2004. (From that time on > I attended JVT only sporadically, and I’m not in the position to > comment. Further, baseline was set in 2003; therefore, provisions > directly related to baseline are not overly relevant anymore after > 2003). Finally, as you may know, there has been quite a bit of > litigation around H.264 recently, but AFAIK, no one has ever > challenged the ToR or the operative mode of JVT. (Closest to this > came, AFAIK, the BC/QC San Diego case, and we all know where that led to.) > Regards, > Stephan > > > On 11/17/09 3:28 AM, "Rob Glidden" wrote: > > Stephan: > > It doesn't appear there was ever much more than a paper consensus > that was undermined by 2003 (see previous email) when patent pools > started announcing coverage of the h.264 baseline (years before > the Qualcomm litigation). > > As the impressive curriculum states on 2001-2003 time frame: > > "Fought the political battles to make those contributions pass, > despite substantial resistance from some of the largest companies > in the field." > > http://www.stewe.org/cv-business-wenger.pdf > > So I'd suggest a different interpretation, one that does not > assume there was a sincere or sustained political consensus. > Accepting this, a more realistic forward look is possible. > > Rob > > > Stephan Wenger wrote: > > Re: [codec] I wonder what is going on at MPEG, Re: DRAFT > Minutes Posted Hi Rob, > > I will not comment more on the BC/QC San Diego case, except to > say that misconduct before the standardization committee > (violation of both written and de-facto practiced rules of the > committee) was only one and, as some people have argued, small > factor in the ruling. I wish one could come to the conclusion > that any misconduct before a standardization committee would > automatically render related patents unenforceable (the > inapplicable part is a very different story), but I fear that > this is too much to hope for. > > My current view of the likeliness of success of Codec in > relation to JVT’s success or failure (depending whom you ask): > > 1. JVT took on the creation a /royalty-free/ /baseline > /(that is, a part of a standard only, and rightholders > may still require a signed license that may be > encumbered to the point where it becomes unusable for > some open source communities—clearly a factor for some > software companies), in a /heavily patented field./ The > vast majority of the participating companies—enough to > create a consensus-based decision in the committee, and > many of them known or likely future rightholders—was /in > support/ of that goal. > 2. Codec attempts to take on of creating a /standard /(not > only a baseline of a standard—rightholders cannot be > appeased by arguing they can make money from > non-baseline applications) under what the BOF chairs > called “acceptable terms”--which translate to an > /open-source friendly non-assert requirement/. The field > of technology is at least as /heavily patented/ as > video. A /significant percentage/ of companies known to > hold a sizeable portfolio of audio/speech codec patents > have spoken quite /clearly against the goal/. It’s not > up to me to declare an IETF consensus on whether > acceptable terms are achievable, but if someone were a > declaring such a consensus, I would object—and I’m sure > I would not be alone. In fact, “acceptable terms”, by > policy cannot and will not be a hard requirement for the > work of a hypothetical codec WG. > 3. > > Based on these perceptions and facts it seems obvious that > it’s going to be much harder to achieve—that is also: easier > to prevent for those not amicable—the goals of a hypothetical > codec WG when compared to the goals of JVT. > Regards, > Stephan > > > On 11/15/09 3:17 PM, "Rob Glidden" > wrote: > > > There is another way to read this. > > This case has been called "the most infamous discovery > fiasco in recent times": > > - The lawyers were sanctioned > - The patents were held both unenforceable and inapplicable > - Fines were levied > - The law firm crumbled and was sold > > But read the case: these were not patents that turned up > two years later. The two were issued and therefore public > in 1995 and 1996 (5 years before the JVT), and had been > presented to the MPEG committee before. > > Going forward, a more proactive ex ante assessment of > known patents, at least of the participants in the > activity, rather than just relying on statements, would be > good practice to check for blocking patents. > > But yes, you are right the court did not blame the JVT > process and certainly not those who took the royalty-free > objective seriously. Clearly not everyone shared that > goal, and got caught in subverting it. > > But no, the subsequent ITU/ISO/IEC Common Patent Policy > did more than just keep presuming that such things never > occur and accept being blind sided, and has tightened its > IPR policy (which provides for third-parties coming > forward with blocking info). > > And yes, any one can sue about anything, and they can lie > about their participation in a standards group. They can > fail to disclose. They can assert patents that end up > being ruled as inapplicable. Maybe they will get away with > it, or maybe as in this case they won't. > > But that isn't a good reason to fail to develop the > standards the Web needs for its open, royalty-free future. > Rather, the opposite. If it takes this kind of extreme > behavior and it still doesn't work, then time to keep > moving forward with royalty-free standardization. > > Rob > > http://www.law.com/jsp/article.jsp?id=1202435137932 > > "Lawyers in Discovery Scandal Say Qualcomm Lied", November > 3, 2009 > > "Lawyers in the Qualcomm discovery scandal claim that the > company misled and stonewalled them, ultimately leading to > the failure to turn over a mountain of relevant evidence > and harsh sanctions from the court." > > The allegations were made in briefs filed Monday by > lawyers from the now-defunct Day Casebeer Batchelder & > Madrid > , > who for the first time are telling their side of what has > become the most infamous discovery fiasco in recent times > > . > > Qualcomm Inc. was sanctioned by San Diego Magistrate Judge > Barbara Major in January 2008 for intentionally > withholding "tens of thousands of e-mails" in an > infringement case against Broadcom Corp. involving video > compression technology patents. The company's lawyers -- > six from Day Casebeer and one from Heller Ehrman -- were > also sanctioned for assisting "Qualcomm in committing this > incredible discovery violation," either knowingly or > recklessly, Major wrote at the time." > > stephen botzko wrote: > > As Stephan Wenger indicated, it is not clear if the > JVT actually failed or not. What is clear is that they > did everything they reasonably could have done. There > were several folks participating who took the > royalty-free baseline profile objective very seriously. > > Again, all submitted IPR for the baseline tools > indicated royalty free terms. So the JVT had every > reason to think they had succeeded. By the time this > IPR turned up, H.264 had been standardized for over 2 > years. H.264 implementations were already out there - > so any attempts to do work-arounds would have broken > existing implementations (including implementations in > silicon). > > Certainly any existing IETF group would have presumed > exactly the same thing the JVT did. The lesson here is > that even if the SDO is conscientious, an unencumbered > codec can not be guaranteed. I don't see any other way > to read this. > > Stephen Botzko > Polycom > > > > On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden > wrote: > > > > > stephen botzko wrote: > > >>> > To date neither ITU-T nor MPEG have ever > delivered on this royalty free undertaking. > >>> > That should be viewed as very *bad* news here, > since all the IPR declarations in JVT for the > baseline tools indicated royalty free terms. > In other words, the SDOs did everything > possible to deliver, and when H.264 baseline > was standardized they thought they had succeeded. > > > > I'd suggest that it is hard to see things this way > after reading > > http://www.cafc.uscourts.gov/opinions/07-1545.pdf > > The process was enforceable, and enforced. > The patents could have been found earlier, and > removed. > > So any "h.264 successor" type work > (audio/video/transport) should complete, not drop, > the royalty free undertaking. IETF and ITU-T > should lead there, not give up or hide in a niche. > > See November 10, 2009 "Preliminary call for > proposals signals work start for H.264/MPEG-4 AVC > successor" > > http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx > > Rob > > > > > Stephen Botzko > Polycom. > > > > > On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden > wrote: > > > BTW I hear that in MPEG the Chinese > National Body initiated a > (re)consideration of royalty free > standardization and MPEG has issued a call > for comments to other national bodies. > > Someone may want to contact their national > MPEG Head of Delegation or numerous > liaisons including IETF, listed at > http://www.itscj.ipsj.or.jp/sc29/. > > At the same time, MPEG is also considering > launching new royalty bearing activities > HVC (High Performance Video Coding) and > MMT (Multimedia Transport). > http://www.chiariglione.org/mpeg/working_documents.htm > > You may recall that h.264 was launched in > 2001 as a joint project between ITU-T > Q.6/SG16 and ISO/IEC JTC 1/SC 29/WG11 with > the undertaking that the "JVT [Joint Video > Team] will define a “baseline” profile. > That profile should be royalty-free for > all implementations." To date neither > ITU-T nor MPEG have ever delivered on this > royalty free undertaking. > > Rob > > Eric Burger wrote: > > > Thank you to everyone who participated in the room and remotely. We > succeeded in getting a lot of work done, and we have a sense of > whether or not we have a well-formed problem to solve, if there are > people who need the work product, if people are willing to work on it, > and if the IETF is an acceptable venue to do the work. In addition, we > learned a lot about the possibilities for cooperating with ITU-T SG 16. > > Please review the minutes and send corrections. > > The minutes are posted to: > http://www.ietf.org/proceedings/09nov/minutes/codec.txt > _______________________________________________ > 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 rob.glidden@sbcglobal.net Wed Nov 18 02:43: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 3A27728C0DD for ; Wed, 18 Nov 2009 02:43:59 -0800 (PST) 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=-0.193, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Yb+KxWVmhhFy for ; Wed, 18 Nov 2009 02:43:58 -0800 (PST) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 8288D28C0CE for ; Wed, 18 Nov 2009 02:43:58 -0800 (PST) Received: (qmail 84756 invoked from network); 18 Nov 2009 10:43:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Q6h33WSFrALCEYaH+UJHZkw8Pa0RUV0Y0Dsk0CzWBlCAM+eYXVwKFgFQuDIzhWS3OLERRQ0ZyGEv4nDiT3mD8U/2+uauOYbiLr4fLnES4cQIrNg+bS/z0bW5DvJ7wb7kplwB3F+hof2gaTt4tWXtGoMcSeyjeTSp0BvvtyybfaY= ; Received: from 218-142-245-190.fibertel.com.ar (rob.glidden@190.245.142.218 with plain) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 18 Nov 2009 02:43:54 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: fJfVKFIVM1mGvRJCSbA7_P7MaUN02jzV7aY2afH4zmrsdpHa66bLKeMYbJxTSRMlB4EPqfFOpqDJF4SjjEJaWtoOgl.T4QCAwhp0v3v0zZT0qT2n7P._SkkRXA8PpjMaSqLdQlbgHm6wY4ZhVRlftq4.CAapJbMx4hKNnjUgd9adx.BYoJStHqzmqmH7KYUudE99uG05EMjOUyvptSq63v0PhSXdMfmSJVCMC7UnQVt01X50twUknMt2gkj.1qSvJZAjOyyY_VOfJ_xtYwTJv1ln9_0cVCasvVWW9sMxvDXZ0_zCqTqHQjAtKr39AlPvkTo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B03CFE6.4000607@sbcglobal.net> Date: Wed, 18 Nov 2009 02:43:50 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Singer References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> In-Reply-To: <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 18 Nov 2009 10:43:59 -0000 David: Yes there is a mention of this at http://multimediacommunication.blogspot.com/2009/10/mpeg-news-report-from-90th-meeting-in.html Here is a simple and fair test of whether there is "sincere and sustained" support for royalty free goal/profile/baseline/standard etc -- is it included in new work by ITU, ISO/MPEG (and ITEF). Bonus points for addressing lessons learned and evolving process/approach. Rob David Singer wrote: > On Nov 17, 2009, at 3:28 , Rob Glidden wrote: > > >> So I'd suggest a different interpretation, one that does not assume there was a sincere or sustained political consensus. Accepting this, a more realistic forward look is possible. >> > > You are entitled to your opinions, but the effort was sincere and sustained on the part of large numbers of participants. This is not the place to go into where things went wrong, but it is worth noting that MPEG is looking again into the question of royalty-free standards, and what was learned from that process. > > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From rob.glidden@sbcglobal.net Wed Nov 18 02:52: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 E842E28C0CE for ; Wed, 18 Nov 2009 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 wTmInXpDbJhm for ; Wed, 18 Nov 2009 02:52:08 -0800 (PST) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 555C33A6A8E for ; Wed, 18 Nov 2009 02:51:57 -0800 (PST) Received: (qmail 85909 invoked from network); 18 Nov 2009 10:51:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uAcFtIDLQuAJleJEgwNZD9w7NZNVutSTNp3rjSgex2MZApnKFXLwqo2tzqnZrne580k/8f4c6R87nPCwFSIazaX+2qjkbvp5ItkYkWdKFZGy0Upbb3MvJxkjnb217nz//OxsgW0Buo/h8JH7Tf3atRUXrbDZeOEeznIcY03HQDI= ; Received: from 218-142-245-190.fibertel.com.ar (rob.glidden@190.245.142.218 with plain) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 18 Nov 2009 02:51:54 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: C1P6sCkVM1kw3VF0O7x92qi34pCFG_ZSCXPBi5ysm5Qp3.iohe5_SMT.Y81BUcV_MFAaecMJ.kpgUImXRwIUmZ1VuskqgL4Gz0fc5550uACkVys5Kqjaa8SVHRe_oOdwMX2YCRdnoBSG1JMdmR8zFkyXzZUqdwXVTvYLKo_V.jJ8_7yCN111D7Erx6FfyKp5vPVBZmxuxSl8HG7ypS8Oe_NKoKYwfjpNE.Qy4ULETnHP3iATP95u2tXF4IRyvu6xMPU0WjQXnBlVbKJwaEvJOER1EWpvmJGFRNUzKdFNluqbBGZvjJugsfa8O4MW1IfZTNE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B03D1C7.4090607@sbcglobal.net> Date: Wed, 18 Nov 2009 02:51:51 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stephen botzko , codec@ietf.org References: <363A37F7-FF19-4FB1-B530-EF5637327CB3@standardstrack.com> <4B00099D.7040201@sbcglobal.net> <6e9223710911151354m42fcc162m9d5612e2879891e@mail.gmail.com> <4B008C19.6010905@sbcglobal.net> <6e9223710911151608k79ab5c25i7632ba2eb8f62a24@mail.gmail.com> <4B028B0B.8040808@sbcglobal.net> <6e9223710911170431x2b3d18abkff91e8ed144174ad@mail.gmail.com> <6e9223710911170431o42d2c898pd67a01bda248e536@mail.gmail.com> <4B029A3B.6060209@sbcglobal.net> <4B029D9B.1010408@sbcglobal.net> <6e9223710911170717v7b521ba7i495b88522fde63d3@mail.gmail.com> In-Reply-To: <6e9223710911170717v7b521ba7i495b88522fde63d3@mail.gmail.com> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [codec] Fwd: I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 18 Nov 2009 10:52:10 -0000 Stephen:

Thanks for the heads-up.  Like I said, looks like this is a jumping gun on proper terms of reference restating and rejuvenating royalty free goal/baseline/profile/standard.

Rob

stephen botzko wrote:
Feel free to submit something.  Be aware that the cost for subjective testing is likely to be around 5000 Euros and will be paid for by the submitters.

Stephen Botzko


On Tue, Nov 17, 2009 at 7:56 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
And of course, a public draft call for proposals, a "preliminary official call for submissions...signal work start", is counter to a characterization of preliminary activity for which requirements have not been set.

http://www.itu.int/ITU-T/studygroups/com16/ngvc/

I'd restate my encouragement to any one who cares about royalty free standardization to get to work rather than justify the past or status quo.

Rob


Rob Glidden wrote:
As this thread starts off, there appear to be three.

I would assert that putting beginning business focus on technical requirements and terms of reference, delaying business model and IPR process to an after-thought, is indeed demonstrative of an upper hand.  Consider what this would look like if royalty free had upper hand, equal say, or even a seat at table.

Rob

stephen botzko wrote:

The draft calls for proposals (there are actually 2, one from the ITU-T and one from ISO/IEC) start the process.  Responses are not profile-specific (since there are no profiles defined at this point).  There is more than one operating point envisioned, but it is rather difficult to figure out what tools belong to what operating point before you have proposals.

Also ITU-T and ISO/IEC have not yet worked out terms of reference for this work.  There is a desire (largely shared in both communities) to work together again, but this has not yet been accomplished organizationally.

Having attended some of these meetings, I think it is premature to say who has the upper hand.  The effort is just beginning, and almost all of the meeting focus has been on technical requirements and terms of reference.

Stephen Botzko
Polycom




On Tue, Nov 17, 2009 at 6:37 AM, Rob Glidden <rob.glidden@sbcglobal.net> wrote:
Stephen:

Millions of patents, even a limited search could be quite expensive, amateur search done without lawyers could be a waste of time.

I believe all could "stipulate" to these points.

But obviously, others did do this work. So better can be done.

Yes, I am critical of JVT for dropping royalty free ball, we can debate who dropped it and when and whether the ball was yanked from their hands or were outfoxed, dis-spirited or whatever.

But the new successor call to h.264 drops any public mention of a royalty-free at all.  So it is clear who has upper hand now -- and this should not be acceptable.

Rob

stephen botzko wrote:
I did read the case. And despite the fact that the court did not criticize the JVT at all, I think that your own posts left a false impression that somehow it did.

What you haven't done so far is identify how the IETF (or ITU-T, MPEG) could ensure unencumbered standards with any certainty.

Ex-ante assessment of the millions of  US patents (+ the millions more filed in other countries) is not a practical answer.  Perhaps a limited search would have caught some patents.  But it would not even come close to catching them all.

And of course there are cases where the granted claims are hard to interpret, even if you have access to the prosecution history. And others where the claims are actually invalid.  Even a limited search could be quite expensive (and an amateur search done without lawyers would IMHO be a waste of time)..

The JVT made a noble effort, and I really don't see how a normal SDO (including the IETF) could do much better.

Stephen Botzko
Polycom

On Sun, Nov 15, 2009 at 6:17 PM, Rob Glidden <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

   There is another way to read this.

   This case has been called "the most infamous discovery fiasco in
   recent times":

   - The lawyers were sanctioned
   - The patents were held both unenforceable and inapplicable
   - Fines were levied
   - The law firm crumbled and was sold

   But read the case:  these were not patents that turned up two
   years later.  The two were issued and therefore public in 1995 and
   1996 (5 years before the JVT), and had been presented to the MPEG
   committee before.

   Going forward, a more proactive ex ante assessment of known
   patents, at least of the participants in the activity, rather than
   just relying on statements, would be good practice to check for
   blocking patents.

   But yes, you are right the court did not blame the JVT process and
   certainly not those who took the royalty-free objective
   seriously.  Clearly not everyone shared that goal, and got caught
   in subverting it.

   But no, the subsequent ITU/ISO/IEC Common Patent Policy did more
   than just keep presuming that such things never occur and accept
   being blind sided, and has tightened its IPR policy (which
   provides for third-parties coming forward with blocking info).

   And yes, any one can sue about anything, and they can lie about
   their participation in a standards group.  They can fail to
   disclose.  They can assert patents that end up being ruled as
   inapplicable.  Maybe they will get away with it, or maybe as in
   this case they won't.

   But that isn't a good reason to fail to develop the standards the
   Web needs for its open, royalty-free future.  Rather, the
   opposite. If it takes this kind of extreme behavior and it still
   doesn't work, then time to keep moving forward with royalty-free
   standardization.

   Rob

   http://www.law.com/jsp/article.jsp?id=1202435137932

   "Lawyers in Discovery Scandal Say Qualcomm Lied", November 3, 2009

   "Lawyers in the Qualcomm discovery scandal claim that the company
   misled and stonewalled them, ultimately leading to the failure to
   turn over a mountain of relevant evidence and harsh sanctions from
   the court."

   The allegations were made in briefs filed Monday by lawyers from
   the now-defunct Day Casebeer Batchelder & Madrid
   <http://www.law.com/jsp/article.jsp?id=1202431679659>, who for the

   first time are telling their side of what has become the most
   infamous discovery fiasco in recent times
   Qualcomm Inc. was sanctioned by San Diego Magistrate Judge Barbara
   Major in January 2008 for intentionally withholding "tens of
   thousands of e-mails" in an infringement case against Broadcom
   Corp. involving video compression technology patents. The
   company's lawyers -- six from Day Casebeer and one from Heller
   Ehrman -- were also sanctioned for assisting "Qualcomm in
   committing this incredible discovery violation," either knowingly
   or recklessly, Major wrote at the time."


   stephen botzko wrote:
   As Stephan Wenger indicated, it is not clear if the JVT actually
   failed or not.  What is clear is that they did everything they
   reasonably could have done.  There were several folks
   participating who took the royalty-free baseline profile
   objective very seriously.

   Again, all submitted IPR for the baseline tools indicated royalty
   free terms.  So the JVT had every reason to think they had
   succeeded.    By the time this IPR turned up, H.264 had been
   standardized for over 2 years.  H.264 implementations were
   already out there - so any attempts to do work-arounds would have
   broken existing implementations (including implementations in
   silicon).
   Certainly any existing IETF group would have presumed exactly the
   same thing the JVT did.  The lesson here is that even if the SDO
   is conscientious, an unencumbered codec can not be guaranteed. I
   don't see any other way to read this.

   Stephen Botzko
   Polycom


   On Sun, Nov 15, 2009 at 9:01 AM, Rob Glidden
   <rob.glidden@sbcglobal.net <mailto:rob.glidden@sbcglobal.net>> wrote:

       stephen botzko wrote:
       >>>
       To date neither ITU-T nor MPEG have ever delivered on this
       royalty free undertaking.
       >>>
       That should be viewed as very *bad* news here, since all the
       IPR declarations in JVT for the baseline tools indicated
       royalty free terms. In other words, the SDOs did everything
       possible to deliver, and when H.264 baseline was
       standardized they thought they had succeeded.
       I'd suggest that it is hard to see things this way after reading

       http://www.cafc.uscourts.gov/opinions/07-1545.pdf

       The process was enforceable, and enforced.
       The patents could have been found earlier, and removed.

       So any "h.264 successor" type work (audio/video/transport)
       should complete, not drop, the royalty free undertaking.        IETF and ITU-T should lead there, not give up or hide in a niche.

       See November 10, 2009 "Preliminary call for proposals signals
       work start for H.264/MPEG-4 AVC successor"

       http://www.itu.int/ITU-T/newslog/Preliminary+Call+For+Proposals+Signals+Work+Start+For+H264MPEG4+AVC+Successor.aspx

       Rob


       Stephen Botzko
       Polycom.
       
       On Sat, Nov 14, 2009 at 6:42 AM, Rob Glidden
       <rob.glidden@sbcglobal.net
       <mailto:rob.glidden@sbcglobal.net>> wrote:

           BTW I hear that in MPEG the Chinese National Body
           initiated a (re)consideration of royalty free
           standardization and MPEG has issued a call for comments
           to other national bodies.

           Someone may want to contact their national MPEG Head of
           Delegation or numerous liaisons including IETF, listed
           at http://www.itscj.ipsj.or.jp/sc29/.

           At the same time, MPEG is also considering launching new
           royalty bearing activities HVC (High Performance Video
           Coding) and MMT (Multimedia Transport).
           http://www.chiariglione.org/mpeg/working_documents.htm

           You may recall that h.264 was launched in 2001 as a
           joint project between ITU-T Q.6/SG16 and ISO/IEC JTC
           1/SC 29/WG11 with the undertaking that the "JVT [Joint
           Video Team] will define a “baseline” profile. That
           profile should be royalty-free for all implementations."
           To date neither ITU-T nor MPEG have ever delivered on
           this royalty free undertaking.

           Rob

           Eric Burger wrote:

               Thank you to everyone who participated in the room
               and remotely. We succeeded in getting a lot of work
               done, and we have a sense of whether or not we have
               a well-formed problem to solve, if there are people
               who need the work product, if people are willing to
               work on it, and if the IETF is an acceptable venue
               to do the work. In addition, we learned a lot about
               the possibilities for cooperating with ITU-T SG 16.

               Please review the minutes and send corrections.

               The minutes are posted to:
               http://www.ietf.org/proceedings/09nov/minutes/codec.txt
               _______________________________________________
               codec mailing list
               codec@ietf.org <mailto:codec@ietf.org>

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


           _______________________________________________
           codec mailing list
           codec@ietf.org <mailto:codec@ietf.org> 








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




From stpeter@stpeter.im Thu Nov 19 20: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 D6FB53A67E5 for ; Thu, 19 Nov 2009 20:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 gatnVYikT2up for ; Thu, 19 Nov 2009 20:21:50 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 515473A67EC for ; Thu, 19 Nov 2009 20:21:50 -0800 (PST) Received: from squire.local (ip-216-17-182-30.rev.frii.com [216.17.182.30]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22D8940D13 for ; Thu, 19 Nov 2009 21:21:45 -0700 (MST) Message-ID: <4B06194F.2090604@stpeter.im> Date: Thu, 19 Nov 2009 21:21:35 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708090801060402030400" Subject: [codec] updated minutes from IETF 76 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 20 Nov 2009 04:21:52 -0000 This is a cryptographically signed message in MIME format. --------------ms030708090801060402030400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I have taken the time to listen to the audio recording, based on which I have corrected the minutes. I have pasted them below, and also uploaded them to the following URL: http://www.ietf.org/proceedings/09nov/minutes/codec.txt (Unfortunately, the audio recording cuts out a few minutes before the send of the session, but I think it captures all the hums and hand-raisings requested by the chairs.) Please let the BoF chairs know if you have further corrections. /psa ###### ======================================================================== CODEC BOF IETF#76 CODEC Meeting Minutes Thursday, November 12, 2009, 1300-1500 (Afternoon Session I -- Orchid East) Chairs: Eric Burger and Peter Saint-Andre Scribes: Daryl Malas and Enrico Marocco Minutes Editor: Peter Saint-Andre Agenda: Slides: Audio: Chat Log: NOTE: These minutes do not summarize the content of the presentations. Refer to the slides and audio recording for that information. ======================================================================== Introduction and Agenda Bashing Presented by: Eric Burger ======================================================================== IETF NOTE WELL statement reiterated. Jabber scribe and note taker recognized. Logistics noted. Agenda bashing. Eric Burger summarizes BoF results from Stockholm as well as work completed since then. Roni Even: Is the goal of this working group to produce one codec? Eric Burger: Most likely one, but maybe 2 -- this is something for us to discuss. Not going to replicate Study Group 16 and become a codec factory. Eric Burger summarizes the possible approaches... Bob Hinden: In order to do something royalty free implies that we've done an infinite amount of IPR searching and that would be hard to guarantee. Peter Saint-Andre: It is well understood that there is no guarantee. Gregory Lebovitz: A lot of the legal, procedural aspects have been vetted on the mailing list. Stephan Wenger: The only realistic goal is to attempt to standardize something where no IPR disclosures that are not acceptable to the WG have been filed with the IETF. Basavaraj Patil: Are you suggesting that none of the existing codecs are "good", that they are not optimized for the internet, or that they are not royalty free? Eric Burger: There are good codecs and widely implemented codecs and freely-available codecs. The goal is to create one aligning with all three of those features -- it's the intersection of high quality, optimized for the Internet, and royalty free that's empty. ======================================================================== ITU-T Speech and Audio Coding (ITU-T Study Group 16) Presentation Presented by: Yusuke Hiwasaki ======================================================================== Yusuke Hisawaki provides an overview to clarify ITU-T speech/audio coding standardization process, but not an official ITU-T position (refer to the liaison statement). Gregory Lebovitz: Is a sector member an organization that can bring multiple people or an individual? Yusuke Hiwasaki: It can be both. Yusuke Hiwasaki continues presentation, discussing alternative of a focus group... Stephan Wenger: It is my understand that a focus group cannot create a recommendation or a standard, only a report. Is that correct? Yusuke Hiwasaki: Yes. Question relayed from the Jabber room about whether working documents are freely available. Yusuke Hiwasaki: Documents from work at the question level are closed, at least officially. Non-normative comment by Stephan Wenger: Many documents at the "question" level are readily available on an anonymous FTP server. That is not official, published policy, but is often the case. Yusuke Hiwasaki continues presentation, descrbing another alternative: a joint effort, such as the Joint Video Team that produced H.264 between ITU-T SG 16 and ISO/IEC. ======================================================================== Guidelines for proposed codec working group Presented by: Jean-Marc Valin ======================================================================== Jean-Marc Valin provides an overview of the proposed working group procedures, as described in draft-valin-codec-guidelines. Roni Evan: When you say identify requirement: a requirement for a specific codec for a specific application? Roni Evan: At what stage do you go from individual drafts to working group drafts? Eric Burger: That would be a WG decision in accordance with IETF process. Larry Masinter: The first time a WG issues a document, it becomes a WG item. Roni Evan: All of the tasks outlined here would be with reference to individual drafts, no? Eric Burger: That is my assumption, but that is really for the WG to determine, because that is standard IETF practice. Larry Masinter: How would you deal with differences of opinion about the priority of requirements? Russ Housley: Rough consensus and running code. Larry Masinter: But there is a process for getting to rough consensus on things like that, I'm not sure where that is in this process. Eric Burger: This is IETF process. Peter Saint-Andre: Larry, do you think that every WG needs to define processes for reaching consensus, or do you think that there are special requirements in this case? Larry Masinter: It seemed to me that the largest source of dissension would come from requirements for different applications, which would underlie different choices. Having a process where you presume agreement early in the process was fuzzy. Eric Burger: Point taken. Adrian Farrel: On the proposed process, "iteratively improve requirements based on received contributions" -- does this begin at the start of a working group, before contributions are solicited? Jean-Marc Valin: There is no working group at this point, so no contributions can be "improved" yet. But there are already contributions on the table. So there is some overlap here, and that's unavoidable. Colin Perkins: In the past some WGs have assumed that there is some signficance to accepting a draft as a WG item. Concern that there might be a formalized process for determining when an individual draft becomes a working group item. Eric Burger: The plan is to generate one, two, or three documents, but there is no plan at this point to create a formalized process because the plan is to get it done and close the WG. Colin Perkins: I don't think there is a standardized model in the IETF about when to accept an individual draft as a WG item. Jean-Marc Valin continues his presentation... Christian Hoene: What is the definition of "party" with respect to participation / contribution, does that include companies and standardization bodies? Eric Burger: This is the IETF, it's individuals. Jean-Marc Valin: Anyone. Julien Meuric: It looks to me that this typical IETF process, but I would have expected more focus on codec work specifically, such as coordination with other SDOs. Eric Burger: That's not a clarification question, that is coming up in following slides. Ingemar Johansson: Does requirements mean only technical requirements or also non-technical requirements (IPR etc.)? Roni Evan: My understanding is that contributors would need to disclose their code. Eric Burger: This is the difference between IETF and other SDOs, IPR is taken into consideration during the technical work. So, yes, IPR disclosures would be required. Stephan Wenger: I don't agree that this a defining characteristic because in the ITU you can IPR into account. In practice not openly discussed, but in practice it is often discussed. Eric Burger: I promise that we will discuss this. Jean-Marc Valin continues his presentation... Roni Evan: In order to enable evaluation, would someone be required to provide their test results? Jean-Marc Valin: Yes, this is assumed. Roni Evan: It would be helpful to make that clear. It will take you five years to finish this work... Jean-Marc Valin continues his presentation... Colin Perkins: What do you mean by the final codec? I-D that goes to WG Last Call, Proposed Standard RFC, Draft Standard RFC, Internet Standard RFC? Jean-Marc Valin: I am not an expert on IETF process, but I would assume the WG would decide. My personal opinion is that this should happen close in time to WG Last Call. Jean-Marc Valin continues his presentation... Roni Evan: If companies decide to bring their own codec, how do you decide which codec is good? Presumably a result of testing? Jean-MarcValin : Our proposal is to say, bring your codec, and we will work together in an effort to produce something that's even better. Roni Evan: The process is not clear to me. You want to merge them. You need to have some definitions. How do you decide what is better? Eric Burger: So the question is: how do you compare solutions? And the answer may be, this may be one of the first things the working group tries to determine. Jon Peterson: Point of order. The purpose of a working groups is for people to bring their ideas and try to gain consensus. Can we stop asking this question? Xavier Marjou: One of the main goals seems to be to produce a royalty free codec. With this process I see no guarantee that this can be achieved. Peter Saint-Andre: There are no guarantees. Eric Burger: We realize this is a risk. Xavier Marjou: Do you want to create a WG whose main goal is not achievable? Eric Burger: The goal of *guaranteed* royalty free output is not achievable, however there are many existence proofs of royalty free codecs. Julien Meuric: As part of the qualification process, will you consider interoperability with legacy codecs? Jean-Marc Valin: It is not a goal of the working group to have legacy compatibility. Christian Hoene: You want to fulfill all requirements. What do you mean? Isn't that the holy grail? Jean-Marc Valin: We mean the three goals mentioned in the charter. Larry Masinter: Several things in this process seem to be unusual for the IETF: developing code and IPR. Are there precendents in other WGs? Stephan Wenger: An example of doing this was iLBC, which was based on open-source code. Not necessarily a successful example. My personal opinion is that iLBC was not evaluated by people knowledgeable in this field, no interest by people in the room, rubber stamped. Peter Saint-Andre: So the problem was they did not have a real WG such as the one being proposed here. Jean-Francois Mule: Stephan, I disagree that evaluation was not done on iLBC. I have proof I can show you offline. Michael Knappe: There has been a lot of discussion about interworking, how things would work in real environments. Noboru Harada: Regarding bit-exact definitions, what are the plans to ensure quality? Jean-Marc Valin: Our goal will be to ensure quality. The point of the conformance testing tools will be to make sure that the quality is the same. ======================================================================== Charter Discussion Presented by: Peter Saint-Andre ======================================================================== Peter Saint-Andre presenting... Larry Masinter: Why would you want more than one codec? Why does it have an objective to design "a very small number of codecs"? Peter Saint-Andre: Our desire is to come up with one, but in reality, we might end up with several. The objective is open to allowing the potential for more than one. Larry Masinter: So accomodating that as an objective... Peter Saint-Andre: Agreed, maybe the charter needs to state as a goal: "Try to design one". Larry Masinter: Also, "not a rubber stamp" is a negative statement, what is the positive goal that you want to do? Peter Saint-Andre: I think the goal is that people would make contributions and that the group would work together to take the best concepts from each contribution to produce something that is better than any one of the contributions and greater than the sum of its parts. Roni Evan: I'm starting to be happier about what you as saying about the number of codecs, because I think the requirements and charter should say the goal is to develop only one codec. Peter Saint-Andre: Agree this should be changed and/or clarified. Basavaraj Patil: Is the goal for people to bring their codec in and get a "rubber stamp"? Peter Saint-Andre: No rubber stamps. Basavaraj Patil: What is the benchmark and baseline to be considered for publication as an RFC? Peter Saint-Andre: This is the job of the requirements document, based on which the WG will reach consensus. Roni Evan: The problem is there are too many wide-band codecs in the market today. This group should determine one, and recommend it to the community. That would help solve the problem, don't provide options. John Klensin: Concern in that the IETF is not set up to provide conformance testing in order to validate a potential codec. We don't have mechanisms for that here. Colin Perkins: John, we do have such a mechanism. We have interoperability testing before proceeding to Draft Standard. The same process would apply here. The working groups can do this, we did it in AVT. Peter Saint-Andre continues presenting... Eric Burger: Are we missing any goals? Stephan Wenger: (Slide 6) While I do not agree that the goals are reachable, I think these are the right goals. Basavaraj Patil: (Slide 6) Where did these business goals come from? >From inside or outside. Peter Saint-Andre: These goals came from previous meetings and the mailing list discussions. Gregory Lebovitz: I have observed that a group of people came into the IETF from the community and put forth a desire to accomplish what's summarized on this slide. Once this set of goals was made public, then there was some agreement and some objections. The community has not come to consensus on the goals, but these represent some of the goals from previous discussions. Peter Saint-Andre: We create WGs for people who want to do the work. We're trying to provide a forum for the people who want to do this work. Noboru Habana: If existing codecs can be presented and meet the criteria, will they be selected for this work (e.g., G.722)? Why should we work on new codecs when we have G.722? Peter Saint-Andre: People coming to the IETF and asking to do this work believe they can do better than existing codecs. Noboru Habana: But we are sure that there is no IPR on G.722. Peter Saint-Andre: There is no point in putting an RFC number on a codec that has already been standardized by the ITU-T. Noboru Habana: What would we do if someone brings an old codec to the WG? Eric Burger: Any existing technology must be at least 20 years old, so we can ensure no IPR issues. I was a naysayer about iLBC, saying that the lawsuits would occur, and they have not occurred. I have been proven wrong about the ability of the community to create, effectively, royalty free work output. Basavaraj Patil: Should the working group rely on an IETF legal "team" to continuously monitor the work to ensure we are not violating IPR? Eric Burger: This was discussed on the mailing list. That would be more expensive than paying royalties. Basavaraj Patil: How are you going to ensure that it will be royalty free? Eric Burger: This is the IETF, we have never strived for perfection. Basavaraj Patil: Why are we doing this in the IETF? Peter Saint-Andre: People have come to the IETF asking to do the work here. Stephan Wenger: If there are a group of people interested in a working group, then it should fall somewhere in the IETF. One point missing: the work must call somewhere within the mission of the IETF. The mission of the IETF is to make the Internet better, and I do not think adding another codec qualifies making the Internet better. I think the goal of this work is to make a codec better for some people on the Internet and a certain group of companies, and not for the Internet as a whole. Koen Vos: I do not agree that G.722 is IPR free. There have been annexes added to G.722 recently that have been essential to make it work over the Internet. Jean-Marc Valin: I don't see how this is different than the rest of the work being done by the IETF. The goal is to develop this work in the same way as all other work in the IETF with regard to IPR. About G.722, I think we can do better. Yusuke Hiwasaki: About G.722, I want to make a clarification: those PLCs (packet-loss concealments) are Appendices, not Annexes. And Appendices are not mandatory part of Recommendations. Also, G.722 has been accepted as a codec for ETSI and it is regarded important. Larry Masinter: When people get together for a standard, everyone has different business goals. I would request the "business goals" are merely a statement of consideration and not a requirement for the charter. Let individuals come up with their own business goals, just provide fair warning about this as a common goal among those who want to participate.. Ingemar Johansson: Are we creating technical work to solve a business problem? Peter Saint-Andre: I think this is semantics, we needed a name for these considerations and didn't want to use the word "legal". Perhaps "other" or "non-technical" considerations is more appropriate. Ingemar Johansson: I do not think the IETF should be trying to do codec work, because there is concern over businesses being able to charge for this. I think this is opening up anyway, and there's no need for the IETF to do this from a technical perspective. Peter Saint-Andre: My goal in assisting with this effort is to help the Jabber open-source community by providing a single codec that can be widely implemented and easily distributed. Stephan Wenger: I do not think the "open-source" community is special. They could become competitors of regular businesses. We should not be working to specifically help them (creating unfair competition). Basavaraj Patil: As far as I know the IETF is working on protocols, and codec expertise does not reside here. The IETF should have told these people to do the work elsewhere. It is incorrect for the IETF to do this kind of work. Joe Hidebrand: (Comments from the Jabber room) - The WG is responsible for balancing considerations and that is the job of the WG. Producing a new codec makes the Internet better if it is adopted, if not then it does not harm. Koen Vos: There have been multiple objections on the mailing list from ITU-T individuals. How does ITU-T think it can be helpful? Eric Burger: Yusuke, could you clarify that, because it's my understanding that in the ITU-T an "objection" has a special status, it's not an objections if just a few people express disagreement. Yusuke Hiwasaki: Correct, objections would be really difficult at ITU-T because that happens at the State level. Xavier Marjou: I'm confused, did you say that you will remove the business goals? Peter Saint-Andre: I said I mislabeled them. Non-technical perhaps, or "other" goals. Christian Hoene: It is good to develop a codec for people who cannot afford the "cost-basis" codecs, the poor people of the world who don't have access to high technology. Peter Saint-Andre: I agree, they are among our stakeholders. Colin Perkins: Regarding IPR rules, there are many other WGs following this process without any issues, they can have their own strong preferences, including for unencumbered technologies. We have lots of existence proofs of other groups working this way, so it should not be a problem. Stephan Wenger: I suggest that we avoid discussions on whether the ITU is appropriate venue and instead focus on whether the IETF is an appropriate venue. Koen Vos: I don't understand why is the ITU-T so worried about the IETF working on this? Concerned about duplication of effort? Yusuke Hiwasaki: Some members of the ITU-T have showed concerns, but I do not think they are speaking as a representatives of the ITU-T. What we are trying to do is to find a way to cooperate, we are willing to help and cooperate in this work. Jean-Marc Valin: I think our views may not be that far apart. The IETF is very willing to work with the ITU-T, and I think forming a working group is a very good method for working with the ITU-T and Study Group 16. This can be the basis of good collaboration. Colin Perkins: There may be people willing to license software if the technology is approved as a standard, but it appears the working group will not accept this because they want a grant up front. Eric Burger: This was addressed on the mailing list. We can assuage those concerns because standard procedure is that IPR is granted upon stndardization, not up front. Christian Hoene: Cooperation with ITU-T is important, but it's not clear how that would happen. Eric Burger: To be worked out. Eric Burger calls questions... Hum: Who here is interested in working on a CODEC in keeping with BCP 79 for use on the Internet? Fair number of hums. Hum forumulation in progress... [Of those who hummed, are the problem statement, charter, and documents clear? Or, do we need to do more work on these items?] Russ Housley: I am concerned with that question. Let's look at the standard questions from RFC 5434. Is there a problem to be solved? Is there a constituency that cares about it? Are there people willing to do the work? Those are the three big questions. I'd like to see people raise their hands. Peter Saint-Andre: Please raise your hand if you are interested in actually working on this within the Internet Standard Process by writing drafts, reviewing drafts, characterization, testing, etc. 20 hands (15 in room/5 Jabber) Peter Saint-Andre: Of those, please raise your hand if you think the IETF is the right place to do this work. 20 hands (14 in room/6 Jabber) Basavaraj Patil: I would like to see a show of hands of people who do not want to see the work done at the IETF... Peter Saint-Andre: Of those who want to do the work, how many do not want to see this work done at the IETF? Zero hands. Gregory Lebovitz: I would like to see, just for the record, a show of hands of the people who don't want to see this work happen at the IETF. We might be able to infer that those people don't want to do the work and don't want to the IETF to do this work. Peter Saint-Andre: Raise your hand if you think that work of this kind should not happen at all at the IETF. 28 hands. Peter Saint-Andre: How many people think this could potentially be done successfully in an interaction between the IETF and the ITU-T? 21 hands. Stephan Wenger: Suggested question: I would like to know how many think this work is achievable / has a reasonable chance of success. Peter Saint-Andre: Raise your hand if you think this work has a reasonable chance of success somewhere (e.g., at IETF or via cooperation between IETF and ITU-T). 30 hands. Peter Saint-Andre: Raise your hand if you think this work does not have a reasonable chance of success anywhere. 8 hands. [audio stream cuts off here!] Gregory Lebovitz: In conclusion, there is a shared desire between the IETF and ITU-T to clearly articulate a practical mechanism to work together. This must be worked out and documented. END --------------ms030708090801060402030400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTEyMDA0MjEzNVowIwYJKoZIhvcNAQkEMRYEFOIbN6HIsD8n3T7ra6Vl Az3wvYqpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEARHTL/QJasfisSb2rLi00cIqnhPnQyRrkXOVjwonI b+SkFyoexv8Vf4d5ZNglizn47VRaCSZ0KweYUV4wrDupKm5wHrGckqXU3Pz6cNs9oILSJgUT CiAa8vGgj8c/57+BiQ3uxhGpwAvrxcazhEGyktIofBJBRAru3sJzWbzIz96B0eVgkGM1AUwU bz3GxpYgfPGPE9SXW8r3DwisNiF86Hrn5mc5UMjeIqM/8AI7QXMTy7tjBhC0ye8sitKtpr5z c4iv6hhs3k7H3CwEjh+xAvIAZSu5luk2hTO3HVAeBtX9kYtKVseXsXQCfQbHmJBNv83/nj2r xmjNmFYMGX1ygwAAAAAAAA== --------------ms030708090801060402030400--