From jmvalin@mozilla.com Tue Nov 1 11:15:12 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5941221F8E77 for ; Tue, 1 Nov 2011 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gRR2jw+YWRd for ; Tue, 1 Nov 2011 11:15:08 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 48B6F21F8D86 for ; Tue, 1 Nov 2011 11:15:08 -0700 (PDT) Received: from [192.168.1.15] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 2A1384AEE39; Tue, 1 Nov 2011 11:14:50 -0700 (PDT) Message-ID: <4EB0374D.7070701@mozilla.com> Date: Tue, 01 Nov 2011 14:15:41 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jonathan Rosenberg References: <4EAF4419.3000502@jdrosen.net> In-Reply-To: <4EAF4419.3000502@jdrosen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:15:12 -0000 This new draft addresses issues that were raised during the first WGLC by the WG participants and chairs, as well as 3GPP and ITU-T SG16 liaisons. It also fixes several issues that were discovered during extensive testing of the code. While most of the code modifications were either encoder changes or reformatting changes, there were a few decoder changes. Among the changes: - Fixes for several glitches caused by mode switching and corner cases (changes bit-stream for SILK-only stereo and hybrid stereo modes, other modes are unaffected) - Implementation of CBR for SILK-only, which means that CBR is now available in all modes - The code has been checked on multiple architectures, including an automated build system on x86 and SPARC (https://mf4.xiph.org/jenkins/) - A single set of opus_* types throughout the code - Test vectors are now provided (on the website for size reasons) - Improved documentation of both the encoder and decoder Cheers, Jean-Marc On 31/10/11 08:58 PM, Jonathan Rosenberg wrote: > The chairs would like to initiate a ~3-week WGLC on > draft-ietf-codec-opus-10 > (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/) which will end > November 19, coincident with the conclusion of the Taipei IETF. > > Please note that this document has several IPR claims against it: > > Xiph.org: https://datatracker.ietf.org/ipr/1524/ > Broadcom: https://datatracker.ietf.org/ipr/1526/ > Skype: https://datatracker.ietf.org/ipr/1602/ > Qualcomm: https://datatracker.ietf.org/ipr/1520/ > > The IETF cannot take a position on validity of these claims. It is up to > IETF participants to make their own decisions. Participants are > encouraged to form an opinion about whether you would like to proceed > with publication of this document under these declarations, or whether > you would like to suggest changes, which you should do during the last > call period. As always, we will proceed based on consensus of the > working group. > > Thanks, > Jonathan R. > > From jmvalin@mozilla.com Tue Nov 1 15:34:27 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88221F9BEA for ; Tue, 1 Nov 2011 15:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcP72+-hkegC for ; Tue, 1 Nov 2011 15:34:22 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id AF24911E8124 for ; Tue, 1 Nov 2011 15:34:22 -0700 (PDT) Received: from [192.168.1.15] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id B55184AEDE5 for ; Tue, 1 Nov 2011 15:34:20 -0700 (PDT) Message-ID: <4EB07420.9010706@mozilla.com> Date: Tue, 01 Nov 2011 18:35:12 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: codec@ietf.org References: <4EAF4419.3000502@jdrosen.net> <4EB0374D.7070701@mozilla.com> In-Reply-To: <4EB0374D.7070701@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:34:27 -0000 I forgot to mention, you can also get the source code directly from: http://downloads.xiph.org/releases/opus/opus-0.9.8.tar.gz This package includes the same code as in the draft, but it also contains MSVC project files, an autoconf build system, and a test suite. Also, the test vectors are located at http://opus-codec.org/testvectors/opus_testvectors-draft10.tar.gz Last thing, for those who want to start using Opus, we now have some API documentation available at: http://opus-codec.org/docs/ Cheers, Jean-Marc On 01/11/11 02:15 PM, Jean-Marc Valin wrote: > This new draft addresses issues that were raised during the first WGLC > by the WG participants and chairs, as well as 3GPP and ITU-T SG16 > liaisons. It also fixes several issues that were discovered during > extensive testing of the code. While most of the code modifications were > either encoder changes or reformatting changes, there were a few decoder > changes. Among the changes: > - Fixes for several glitches caused by mode switching and corner cases > (changes bit-stream for SILK-only stereo and hybrid stereo modes, other > modes are unaffected) > - Implementation of CBR for SILK-only, which means that CBR is now > available in all modes > - The code has been checked on multiple architectures, including an > automated build system on x86 and SPARC (https://mf4.xiph.org/jenkins/) > - A single set of opus_* types throughout the code > - Test vectors are now provided (on the website for size reasons) > - Improved documentation of both the encoder and decoder > > Cheers, > > Jean-Marc > > On 31/10/11 08:58 PM, Jonathan Rosenberg wrote: >> The chairs would like to initiate a ~3-week WGLC on >> draft-ietf-codec-opus-10 >> (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/) which will end >> November 19, coincident with the conclusion of the Taipei IETF. >> >> Please note that this document has several IPR claims against it: >> >> Xiph.org: https://datatracker.ietf.org/ipr/1524/ >> Broadcom: https://datatracker.ietf.org/ipr/1526/ >> Skype: https://datatracker.ietf.org/ipr/1602/ >> Qualcomm: https://datatracker.ietf.org/ipr/1520/ >> >> The IETF cannot take a position on validity of these claims. It is up to >> IETF participants to make their own decisions. Participants are >> encouraged to form an opinion about whether you would like to proceed >> with publication of this document under these declarations, or whether >> you would like to suggest changes, which you should do during the last >> call period. As always, we will proceed based on consensus of the >> working group. >> >> Thanks, >> Jonathan R. >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From erik.norvell@ericsson.com Wed Nov 9 04:30:24 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C175121F8C44 for ; Wed, 9 Nov 2011 04:30:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OleJAnmKbqs4 for ; Wed, 9 Nov 2011 04:30:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 458D121F8B1B for ; Wed, 9 Nov 2011 04:30:19 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-55-4eba725ac06e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.64.13753.A527ABE4; Wed, 9 Nov 2011 13:30:18 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 9 Nov 2011 13:30:17 +0100 From: Erik Norvell To: "codec@ietf.org" Date: Wed, 9 Nov 2011 13:30:17 +0100 Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AcyYMVSePoU4Z6qITC2pjj9MbtXeAwGqdqfw Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> References: <4EAF4419.3000502@jdrosen.net> In-Reply-To: <4EAF4419.3000502@jdrosen.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 12:30:24 -0000 Hi all,=20 I am not in any way against the use of patented technology in IETF in gener= al, but I think many people agree that this is not the expected outcome of = this WG. The main arguments for starting this WG is that it should produce = an unencumbered codec. Still, there is an opportunity in trying to achieve = an unencumbered codec by ensuring the largest possible freedom in the imple= mentation. For this reason, I suggest the standard compliance defined in te= rms of closeness to the test vectors should be removed. In consequence, thi= s will render the specified OPUS encoder and decoder c-code to informative = only.=20 I would like to note in this context that other standards bodies often appl= y the criterion of compliance to test vectors not with the only objective o= f ensuring a defined quality level but also to have means of enforcing the = use of the IPRs of a reference implementation. Given the original goal of t= he codec WG of providing an unencumbered codec, this latter aspect should b= e irrelevant in the context of our group. The current situation is that there are no constraints on the encoder other= than that it should produce a readable bitstream. It may change the qualit= y in any direction. In the interest of maximizing the implementation freedo= m, the same should apply for the decoder. This means the only constraint fo= r both the encoder and the decoder would be that they can write and read th= e bit stream format, respectively. With regards to the desire to achieve the best possible quality when using = the IETF codec, I think that - given that there was in any case no plan to = have strong encoder compliance criteria - there is no loss in relaxing the = compliance criteria even for the decoder. Rather, it can be foreseen that t= he market will choose the best performing implementation and we can be sure= that especially for the decoding end that it will be in the biggest intere= st of providers of a product to use an implementation that guarantees the h= ighest quality. It might be that implementers have less incentive of provid= ing the best possible encoders since this will actually not impact the dire= ctly perceived quality of the product (it would only hurt someone else on t= he far end). However, we would in any case have had this potential problem = and even here I believe that the market mechanisms will work leading to the= use of high-quality implementations. On a general perspective, specifying = only the bit stream in a normative fashion will allow to continuously impro= ve both encoders and decoders over the (informative-only) reference impleme= ntations of the standard.=20 Best regards,=20 Erik =20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Jonathan Rosenberg > Sent: den 1 november 2011 01:58 > To: codec@ietf.org > Subject: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > The chairs would like to initiate a ~3-week WGLC on=20 > draft-ietf-codec-opus-10 > (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/)=20 > which will end November 19, coincident with the conclusion of=20 > the Taipei IETF. >=20 > Please note that this document has several IPR claims against it: >=20 > Xiph.org: https://datatracker.ietf.org/ipr/1524/ > Broadcom: https://datatracker.ietf.org/ipr/1526/ > Skype: https://datatracker.ietf.org/ipr/1602/ > Qualcomm: https://datatracker.ietf.org/ipr/1520/ >=20 > The IETF cannot take a position on validity of these claims.=20 > It is up to IETF participants to make their own decisions.=20 > Participants are encouraged to form an opinion about whether=20 > you would like to proceed with publication of this document=20 > under these declarations, or whether you would like to=20 > suggest changes, which you should do during the last call=20 > period. As always, we will proceed based on consensus of the=20 > working group. >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > Skype Chief Technology Strategist > jdrosen@skype.net http://www.skype.com > jdrosen@jdrosen.net http://www.jdrosen.net >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > = From jmvalin@mozilla.com Wed Nov 9 12:09:42 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C178021F85BB for ; Wed, 9 Nov 2011 12:09:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOVG9KFIP-lN for ; Wed, 9 Nov 2011 12:09:39 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA521F85B9 for ; Wed, 9 Nov 2011 12:09:38 -0800 (PST) Received: from [192.168.1.15] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 513DD4AEDC6; Wed, 9 Nov 2011 12:09:37 -0800 (PST) Message-ID: <4EBADE3B.4000904@mozilla.com> Date: Wed, 09 Nov 2011 15:10:35 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Erik Norvell References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:09:42 -0000 Hi Erik, With respect to IPR, I'd like to refer you to the statement made by Monty on the rtcweb mailing list: http://www.ietf.org/mail-archive/web/rtcweb/current/msg02646.html Now, I do agree in principle with the idea of "ensuring the largest possible freedom in the implementation" and that's certainly what we've done for the encoder. Now, when it comes to the decoder, it's a different matter because it's what defines the bit-stream. If you remove any requirements based on test vectors, then the spec becomes meaningless. Even a G.729 decoder would produce some audio output when sent an Opus bit-stream. What would prevent someone from saying it implements the Opus specification? In general, considering the fact that the decoder is fairly straightforward with little room for alternate implementations (unlike the encoder), the space of changes which change the output but which remain usefully compatible is fairly small and probably not useful for patent avoidance. But if the issue was ever to arise, the IETF could easily publish an updated spec with new test vectors that remains compatible with the original spec. Cheers, Jean-Marc On 09/11/11 07:30 AM, Erik Norvell wrote: > Hi all, > > I am not in any way against the use of patented technology in IETF in general, but I think many people agree that this is not the expected outcome of this WG. The main arguments for starting this WG is that it should produce an unencumbered codec. Still, there is an opportunity in trying to achieve an unencumbered codec by ensuring the largest possible freedom in the implementation. For this reason, I suggest the standard compliance defined in terms of closeness to the test vectors should be removed. In consequence, this will render the specified OPUS encoder and decoder c-code to informative only. > > I would like to note in this context that other standards bodies often apply the criterion of compliance to test vectors not with the only objective of ensuring a defined quality level but also to have means of enforcing the use of the IPRs of a reference implementation. Given the original goal of the codec WG of providing an unencumbered codec, this latter aspect should be irrelevant in the context of our group. > > The current situation is that there are no constraints on the encoder other than that it should produce a readable bitstream. It may change the quality in any direction. In the interest of maximizing the implementation freedom, the same should apply for the decoder. This means the only constraint for both the encoder and the decoder would be that they can write and read the bit stream format, respectively. > > With regards to the desire to achieve the best possible quality when using the IETF codec, I think that - given that there was in any case no plan to have strong encoder compliance criteria - there is no loss in relaxing the compliance criteria even for the decoder. Rather, it can be foreseen that the market will choose the best performing implementation and we can be sure that especially for the decoding end that it will be in the biggest interest of providers of a product to use an implementation that guarantees the highest quality. It might be that implementers have less incentive of providing the best possible encoders since this will actually not impact the directly perceived quality of the product (it would only hurt someone else on the far end). However, we would in any case have had this potential problem and even here I believe that the market mechanisms will work leading to the use of high-quality implementations. On a general perspective, specifying only the bit st > ream in a normative fashion will allow to continuously improve both encoders and decoders over the (informative-only) reference implementations of the standard. > > Best regards, > Erik > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] >> On Behalf Of Jonathan Rosenberg >> Sent: den 1 november 2011 01:58 >> To: codec@ietf.org >> Subject: [codec] WGLC #2 for draft-ietf-codec-opus-10 >> >> The chairs would like to initiate a ~3-week WGLC on >> draft-ietf-codec-opus-10 >> (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/) >> which will end November 19, coincident with the conclusion of >> the Taipei IETF. >> >> Please note that this document has several IPR claims against it: >> >> Xiph.org: https://datatracker.ietf.org/ipr/1524/ >> Broadcom: https://datatracker.ietf.org/ipr/1526/ >> Skype: https://datatracker.ietf.org/ipr/1602/ >> Qualcomm: https://datatracker.ietf.org/ipr/1520/ >> >> The IETF cannot take a position on validity of these claims. >> It is up to IETF participants to make their own decisions. >> Participants are encouraged to form an opinion about whether >> you would like to proceed with publication of this document >> under these declarations, or whether you would like to >> suggest changes, which you should do during the last call >> period. As always, we will proceed based on consensus of the >> working group. >> >> Thanks, >> Jonathan R. >> >> >> -- >> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen >> Skype Chief Technology Strategist >> jdrosen@skype.net http://www.skype.com >> jdrosen@jdrosen.net http://www.jdrosen.net >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Fri Nov 11 21:59:11 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317BF21F84FC for ; Fri, 11 Nov 2011 21:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2ohv1r0ow0P for ; Fri, 11 Nov 2011 21:59:10 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 685C621F84FA for ; Fri, 11 Nov 2011 21:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6030; q=dns/txt; s=iport; t=1321077550; x=1322287150; h=from:subject:date:references:to:message-id:mime-version; bh=QVTmUNh9gT023dgliyN1iHKBMCutmftlirqS6knSQjk=; b=ePfIQQVu3o6F6WFoHaDPBPG7IWs64xlAvC1afE3S7aqm8h/uTL3E/kPc r6aCHIKlJCGogDtCZzY1uoi5dta205v5TH1TA1AvGcIpJscc//y8p/4fX yjgjbbti0uS5cbiBM8q1YQrKdLly0d0r2ZVBxDruqlZzUzgYoszkgaur/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFACoKvk6rRDoI/2dsb2JhbABCmmuPQ4EFgXIBAQECAQESARpRCxwDAQIvTQIIGSKHYAiYUwGdZwSJG2MEiA6MH5IF X-IronPort-AV: E=Sophos;i="4.69,498,1315180800"; d="scan'208,217";a="13823337" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 12 Nov 2011 05:59:09 +0000 Received: from sjc-vpn6-1496.cisco.com (sjc-vpn6-1496.cisco.com [10.21.125.216]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAC5x8ww002623 for ; Sat, 12 Nov 2011 05:59:08 GMT From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_431D7A6E-40AC-49B0-8B25-02F21E322C18" Date: Sat, 12 Nov 2011 13:59:07 +0800 References: <20111112045526.7821.86080@ietfa.amsl.com> To: codec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [codec] Fwd: New Liaison Statement, "LS to IETF CODEC WG on the IETF OPUS codec" X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 05:59:11 -0000 --Apple-Mail=_431D7A6E-40AC-49B0-8B25-02F21E322C18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We received the following liaison.=20 Begin forwarded message: > From: "Liaison Statement Management Tool" > Subject: New Liaison Statement, "LS to IETF CODEC WG on the IETF OPUS = codec" > Date: November 12, 2011 12:55:26 PM GMT+08:00 > To: "Cullen Jennings (fluffy)" , = > Cc: "Gonzalo Camarillo" , "Robert = Sparks" , "Internet Wideband Audio Codec = Discussion List" , "ITU TSBSG12" , = >=20 > Title: LS to IETF CODEC WG on the IETF OPUS codec > Submission Date: 2011-11-11 > URL of the IETF Web page: /liaison/1110/ > Please reply by 2012-03-01 > From: ITU-T SG 12 (Catherine Quinquis ) > To: Internet Wideband Audio Codec (fluffy@cisco.com, = jdrosen@jdrosen.net) > Cc: Gonzalo Camarillo ,Robert Sparks = ,Internet Wideband Audio Codec Discussion List = ,ITU TSBSG12 > Reponse Contact: catherine.quinquis@orange.com > Technical Contact: > Purpose: For action >=20 > Body: > Attachment(s): >=20 > LS to IETF CODEC WG on the IETF OPUS codec = https://datatracker.ietf.org/documents/LIAISON/file1293.pdf >=20 >=20 >=20 --Apple-Mail=_431D7A6E-40AC-49B0-8B25-02F21E322C18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: "Liaison Statement = Management Tool" <lsmt@ietf.org>
Subject: = New Liaison Statement, "LS to IETF CODEC WG on the = IETF OPUS codec"
Date: November 12, 2011 12:55:26 PM = GMT+08:00
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, <jdrosen@jdrosen.net>
=
Cc: "Gonzalo Camarillo" = <gonzalo.camarillo@ericsson.= com>, "Robert Sparks" <rjsparks@nostrum.com>, = "Internet Wideband Audio Codec Discussion List" <codec@ietf.org>, "ITU TSBSG12" = <tsbsg12@itu.int>, <catherine.quinquis@orange.co= m>

New Liaison Statement, "LS to IETF CODEC WG on the IETF OPUS = codec"

Title: LS = to IETF CODEC WG on the IETF OPUS codec
Submission Date: 2011-11-11
URL of the IETF Web page: /liaison/1110/
Please reply by 2012-03-01
From: ITU-T SG 12 (Catherine Quinquis <catherine.quinquis@orange.co= m>)
To: Internet Wideband Audio Codec (fluffy@cisco.com, jdrosen@jdrosen.net)
Cc: Gonzalo Camarillo <gonzalo.camarillo@ericsson.= com>,Robert Sparks <rjsparks@nostrum.com>,Internet= Wideband Audio Codec Discussion List <codec@ietf.org>,ITU TSBSG12 <tsbsg12@itu.int>
Reponse Contact: catherine.quinquis@orange.co= m
Technical Contact:
Purpose: For action

Body:
Attachment(s):

    LS to IETF CODEC WG on the IETF OPUS codec https= ://datatracker.ietf.org/documents/LIAISON/file1293.pdf


= --Apple-Mail=_431D7A6E-40AC-49B0-8B25-02F21E322C18-- From mans.nilsson@sverigesradio.se Tue Nov 8 03:27:41 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3E621F8C84 for ; Tue, 8 Nov 2011 03:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbl4LZjoMow8 for ; Tue, 8 Nov 2011 03:27:41 -0800 (PST) Received: from stoexedge02.sr.se (mail-2.sverigesradio.se [192.121.194.171]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F721F8BF7 for ; Tue, 8 Nov 2011 03:27:39 -0800 (PST) Received: from STOEXCASHT02.sr.se (134.25.11.15) by mail-2.sverigesradio.se (192.121.194.171) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 8 Nov 2011 12:26:22 +0100 Received: from STOEXMBX02.sr.se ([fe80::c92a:3554:4d98:d95f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 12:27:37 +0100 From: =?iso-8859-1?Q?M=E5ns_Nilsson?= To: Jonathan Rosenberg Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AQHMmDFaSsvW/XT2FUmiBgMTYUHFHJWi0aWA Date: Tue, 8 Nov 2011 11:27:35 +0000 Message-ID: <6C675C25-5588-414A-8FFB-995161F4E3F4@sr.se> References: <4EAF4419.3000502@jdrosen.net> In-Reply-To: <4EAF4419.3000502@jdrosen.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-32-994549844" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 13 Nov 2011 05:51:50 -0800 Cc: "" Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:16:44 -0000 --Apple-Mail-32-994549844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 1 nov 2011 kl. 01.58 skrev Jonathan Rosenberg: > The chairs would like to initiate a ~3-week WGLC on = draft-ietf-codec-opus-10=20 I have read the document and TTBOMK the IPR statements and support it = being advanced up the standardisation ladder.=20 --=20 M=E5ns Nilsson Sveriges Radio +46 8 784 2326 +46 705989668 Tv=E5 saker verkar vara oundvikliga i milj=F6er med d=E5ligt chefsskap:=20= Det f=F6rsta =E4r horribla beslut, det andra att det inte g=E5r att f=F6ra en diskussion om f=F6rh=E5llandena= . Mats Svegfors 2010 --Apple-Mail-32-994549844 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: =?iso-8859-1?Q?Detta_=E4r_en_digitalt_signerad_del_av_brevet?= Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAk65EiIACgkQ02/pMZDM1cVxAQCeKb5z72nC61EmYWkVmMOwwtKj oKgAn2tgt8osvWXF2jMWy9SZF8O5owhW =SdJu -----END PGP SIGNATURE----- --Apple-Mail-32-994549844-- From erik.norvell@ericsson.com Tue Nov 15 00:05:24 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293911E8085 for ; Tue, 15 Nov 2011 00:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7BFunYwiIPl for ; Tue, 15 Nov 2011 00:05:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BE11E8081 for ; Tue, 15 Nov 2011 00:05:18 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-a4-4ec21d3d513d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 46.57.09514.D3D12CE4; Tue, 15 Nov 2011 09:05:17 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 15 Nov 2011 09:05:17 +0100 From: Erik Norvell To: Jean-Marc Valin Date: Tue, 15 Nov 2011 09:05:16 +0100 Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AcyfG4M9ZsoQLpIFTgi2dvJUrFoVbQEUZ3nw Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9FEE83D@ESESSCMS0351.eemea.ericsson.se> References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EBADE3B.4000904@mozilla.com> In-Reply-To: <4EBADE3B.4000904@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:05:24 -0000 Hi Jean-Marc, Defining the bit stream does not require a normative decoder. It is defined= by the encoder and decoder specification, regardless of whether they are n= ormative or informative. Yes, G.729 could decode whatever raw data you inpu= t to some nonsense audio, but I cannot see why anyone would do that and cal= l it Opus. It is not more likely than anyone using the G.729 encoder and ca= lling the output an Opus bitstream, which the current setup permits in the = same line of argumentation. What will count in the end on the marketplace i= s the quality of specific encoder and decoder implementations a provider ca= n offer. If this quality is not limited since there is still the implementa= tion freedom it will just be a plus. One problem with the proposed way of conformance testing with normative dec= oder becomes already apparent with the separate test vectors for the FIXED = and FLOAT implementations. At least for the mono test vectors 3 and 4, the = FIXED implementation fails when comparing to the FLOAT test vector and vice= versa. How could we define conformance in such a way that two different bu= t definitely valid implementations fail meeting the conformance criterion o= f the respective other implementation?=20 If already the difference between FIXED and FLOAT is enough to make the con= formance test fail, it definitely shows that the proposed way of conformanc= e verification needs to be revised. Best regards, Erik=20 > -----Original Message----- > From: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20 > Sent: den 9 november 2011 21:11 > To: Erik Norvell > Cc: codec@ietf.org > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > Hi Erik, >=20 > With respect to IPR, I'd like to refer you to the statement=20 > made by Monty on the rtcweb mailing list: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg02646.html >=20 > Now, I do agree in principle with the idea of "ensuring the=20 > largest possible freedom in the implementation" and that's=20 > certainly what we've done for the encoder. Now, when it comes=20 > to the decoder, it's a different matter because it's what=20 > defines the bit-stream. If you remove any requirements based=20 > on test vectors, then the spec becomes meaningless. Even a=20 > G.729 decoder would produce some audio output when sent an=20 > Opus bit-stream. What would prevent someone from saying it=20 > implements the Opus specification? >=20 > In general, considering the fact that the decoder is fairly=20 > straightforward with little room for alternate=20 > implementations (unlike the encoder), the space of changes=20 > which change the output but which remain usefully compatible=20 > is fairly small and probably not useful for patent avoidance.=20 > But if the issue was ever to arise, the IETF could easily=20 > publish an updated spec with new test vectors that remains=20 > compatible with the original spec. >=20 > Cheers, >=20 > Jean-Marc >=20 > On 09/11/11 07:30 AM, Erik Norvell wrote: > > Hi all, > >=20 > > I am not in any way against the use of patented technology=20 > in IETF in general, but I think many people agree that this=20 > is not the expected outcome of this WG. The main arguments=20 > for starting this WG is that it should produce an=20 > unencumbered codec. Still, there is an opportunity in trying=20 > to achieve an unencumbered codec by ensuring the largest=20 > possible freedom in the implementation. For this reason, I=20 > suggest the standard compliance defined in terms of closeness=20 > to the test vectors should be removed. In consequence, this=20 > will render the specified OPUS encoder and decoder c-code to=20 > informative only.=20 > >=20 > > I would like to note in this context that other standards=20 > bodies often apply the criterion of compliance to test=20 > vectors not with the only objective of ensuring a defined=20 > quality level but also to have means of enforcing the use of=20 > the IPRs of a reference implementation. Given the original=20 > goal of the codec WG of providing an unencumbered codec, this=20 > latter aspect should be irrelevant in the context of our group. > >=20 > > The current situation is that there are no constraints on=20 > the encoder other than that it should produce a readable=20 > bitstream. It may change the quality in any direction. In the=20 > interest of maximizing the implementation freedom, the same=20 > should apply for the decoder. This means the only constraint=20 > for both the encoder and the decoder would be that they can=20 > write and read the bit stream format, respectively. > >=20 > > With regards to the desire to achieve the best possible=20 > quality when=20 > > using the IETF codec, I think that - given that there was=20 > in any case=20 > > no plan to have strong encoder compliance criteria - there=20 > is no loss=20 > > in relaxing the compliance criteria even for the decoder.=20 > Rather, it=20 > > can be foreseen that the market will choose the best performing=20 > > implementation and we can be sure that especially for the=20 > decoding end=20 > > that it will be in the biggest interest of providers of a=20 > product to=20 > > use an implementation that guarantees the highest quality.=20 > It might be=20 > > that implementers have less incentive of providing the best=20 > possible=20 > > encoders since this will actually not impact the directly perceived=20 > > quality of the product (it would only hurt someone else on the far=20 > > end). However, we would in any case have had this potential problem=20 > > and even here I believe that the market mechanisms will=20 > work leading=20 > > to the use of high-quality implementations. On a general=20 > perspective,=20 > > specifying only the bit > st > > ream in a normative fashion will allow to continuously=20 > improve both encoders and decoders over the=20 > (informative-only) reference implementations of the standard.=20 > >=20 > > Best regards, > > Erik > >=20 > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On=20 > >> Behalf Of Jonathan Rosenberg > >> Sent: den 1 november 2011 01:58 > >> To: codec@ietf.org > >> Subject: [codec] WGLC #2 for draft-ietf-codec-opus-10 > >> > >> The chairs would like to initiate a ~3-week WGLC on=20 > >> draft-ietf-codec-opus-10 > >> (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/) > >> which will end November 19, coincident with the conclusion of the=20 > >> Taipei IETF. > >> > >> Please note that this document has several IPR claims against it: > >> > >> Xiph.org: https://datatracker.ietf.org/ipr/1524/ > >> Broadcom: https://datatracker.ietf.org/ipr/1526/ > >> Skype: https://datatracker.ietf.org/ipr/1602/ > >> Qualcomm: https://datatracker.ietf.org/ipr/1520/ > >> > >> The IETF cannot take a position on validity of these claims.=20 > >> It is up to IETF participants to make their own decisions.=20 > >> Participants are encouraged to form an opinion about whether you=20 > >> would like to proceed with publication of this document=20 > under these=20 > >> declarations, or whether you would like to suggest=20 > changes, which you=20 > >> should do during the last call period. As always, we will proceed=20 > >> based on consensus of the working group. > >> > >> Thanks, > >> Jonathan R. > >> > >> > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > >> Skype Chief Technology Strategist > >> jdrosen@skype.net http://www.skype.com > >> jdrosen@jdrosen.net =20 > http://www.jdrosen.net > >> > >> _______________________________________________ > >> 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 > = From ietf@meetecho.com Tue Nov 15 06:44:56 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF811E80D7 for ; Tue, 15 Nov 2011 06:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxX+FouBfxay for ; Tue, 15 Nov 2011 06:44:56 -0800 (PST) Received: from smtpw2.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id C289211E80C6 for ; Tue, 15 Nov 2011 06:44:55 -0800 (PST) Received: (qmail 14787 invoked by uid 89); 15 Nov 2011 14:44:52 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 15 Nov 2011 14:44:51 -0000 Date: Tue, 15 Nov 2011 15:44:51 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: codec@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.143 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [codec] Meetecho support for CODEC WG meeting session X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:44:56 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system for = tomorrow's CODEC WG meeting session.=0A=0AAccess to the on-line session (= including audio and video streams) will be available from 1:00pm at:=0Aht= tp://www.meetecho.com/ietf82/codec=0A=0AThe Meetecho session automaticall= y logs you into the standard IETF jabber room. So, from there, you can ha= ve an integrated experience involving all media and allowing you to inter= act with the room.=0A=0AA tutorial of interactivity features of the tool = can be found at:=0Ahttp://www.meetecho.com/ietf82/tutorials=0A=0AFor furt= her information you can contact us at ietf-support@meetecho.com.=0A=0AChe= ers,=0Athe Meetecho team=0A=C2=A0=0A--=C2=A0=0AMeetecho s.r.l.=0AWeb Conf= erencing and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From bmschwar@fas.harvard.edu Tue Nov 15 07:39:14 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4611E8082 for ; Tue, 15 Nov 2011 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V00gfwPru3ER for ; Tue, 15 Nov 2011 07:39:10 -0800 (PST) Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by ietfa.amsl.com (Postfix) with ESMTP id 384CC21F8B79 for ; Tue, 15 Nov 2011 07:39:07 -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 2AB2A46E650; Tue, 15 Nov 2011 10:39:06 -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=A6OtYpefXm1aM0W J2oeyqwJtTWbG170p6SljVsSRty4=; b=E6j94B+fzgM5HDrRCPWgIShvx0+vZeL Q5gbw+26PiNTot51Taq8+IH7mNEAQAkVZesYbntQz3OaJ4Nw1pC2Wen9sAJY35Oo q7IV1qdHKm9+B9RNxJXs3Ek2eWhgvMmKGkdXabws/VK2n/wSIRJHREjsQhf3jUxv dhgAe3A8qUmw= 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=LuV19QskR K4Yvk6AqAC5OS0DE04/n4amLiPJwo+MAAhjHgV6r+KSHQ4IeWBfGnHrCIFfN9KTu Kqig6YhLy3MuLRiF0dyk1+Y01sMHUF4BYFrt+9vacJJDW6eDde03gXJo1esIVTxB d0mGy8Eng5KXuGSQmyQgiGv/8EGyugogJ4= Received: from [172.23.141.79] (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 us24.unix.fas.harvard.edu (Postfix) with ESMTPSA id 25F2646E64E; Tue, 15 Nov 2011 10:39:06 -0500 (EST) Message-ID: <4EC28796.5090502@fas.harvard.edu> Date: Tue, 15 Nov 2011 10:39:02 -0500 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Erik Norvell References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig039D322E9E0F44122934F545" Cc: "codec@ietf.org" Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 15:39:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig039D322E9E0F44122934F545 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/09/2011 07:30 AM, Erik Norvell wrote: > The current situation is that there are no constraints on the encoder o= ther than that it should produce a readable bitstream. It may change the = quality in any direction. In the interest of maximizing the implementatio= n freedom, the same should apply for the decoder. The above suggestion is impossible as a matter of logic, because our purpose is interoperability. If the decoder is normatively specified, then an encoder may be designed so that the output of a compliant decoder sounds like the original input audio. This is our current situation. If the encoder is normatively specified, then a decoder may be designed s= o that its output sounds like the original input audio encoded by a compliant encoder. If neither the encoder nor the decoder is normatively specified, then neither can be designed with any expectation of what sort of output will be produced. Without any normative specification, it would be trivial to build a compliant but non-interoperable encoder-decoder pair. Such an encoder would write valid Opus bitstreams, but these bitstreams would only sound like the original input audio when played through the corresponding decoder. Similarly, the decoder would not produce correct audio output when connected to other encoder implementations. Of course, this is all old news. We have already reached consensus on this issue, which is why it is all explicitly built into the document tha= t guides our process here: http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/?include_text= =3D1 See Sections 4.1 and 4.3. --Ben --------------enig039D322E9E0F44122934F545 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7Ch5cACgkQUJT6e6HFtqTVLwCeJZs1mPlp0rQ0ag6tuZnc7xc+ c5IAnRPaL+PBJOElbsbSCEdY273gYbme =rZrM -----END PGP SIGNATURE----- --------------enig039D322E9E0F44122934F545-- From hoene@uni-tuebingen.de Tue Nov 15 13:01:06 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3772611E80C8 for ; Tue, 15 Nov 2011 13:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQP5Kj0hcMz7 for ; Tue, 15 Nov 2011 13:01:05 -0800 (PST) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6339A11E80BA for ; Tue, 15 Nov 2011 13:01:05 -0800 (PST) Received: from hoeneT60 (p5482B0A1.dip.t-dialin.net [84.130.176.161]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id pAFL0tg8008537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Nov 2011 22:01:02 +0100 From: "Christian Hoene" To: "'Erik Norvell'" , "'Jean-Marc Valin'" References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EBADE3B.4000904@mozilla.com> <027A93CE4A670242BD91A44E37105AEF3BB9FEE83D@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9FEE83D@ESESSCMS0351.eemea.ericsson.se> Date: Tue, 15 Nov 2011 22:01:05 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <005d01cca3d9$b551a800$1ff4f800$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdnFS6OFAQH0NkTgh2ZlsqwZro7AGUNOupAXky+fEBu000pJXmMw0w Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:01:06 -0000 > One problem with the proposed way of conformance testing with normative > decoder becomes already apparent with the separate test vectors for the > FIXED and FLOAT implementations. At least for the mono test vectors 3 and > 4, the FIXED implementation fails when comparing to the FLOAT test vector > and vice versa. [Christian Hoene] Is this a bug that needs to be fixed? From jmvalin@jmvalin.ca Tue Nov 15 14:52:06 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89B1F0C97 for ; Tue, 15 Nov 2011 14:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khi3kcHtzUG2 for ; Tue, 15 Nov 2011 14:52:05 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id BAA891F0C96 for ; Tue, 15 Nov 2011 14:52:05 -0800 (PST) Received: from [192.168.1.112] (60-248-154-172.HINET-IP.hinet.net [60.248.154.172]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 8846C4AEDF0; Tue, 15 Nov 2011 14:52:03 -0800 (PST) Message-ID: <4EC2ED47.5030005@jmvalin.ca> Date: Wed, 16 Nov 2011 06:52:55 +0800 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christian Hoene References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EBADE3B.4000904@mozilla.com> <027A93CE4A670242BD91A44E37105AEF3BB9FEE83D@ESESSCMS0351.eemea.ericsson.se> <005d01cca3d9$b551a800$1ff4f800$@uni-tuebingen.de> In-Reply-To: <005d01cca3d9$b551a800$1ff4f800$@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:52:06 -0000 On 16/11/11 05:01 AM, Christian Hoene wrote: >> One problem with the proposed way of conformance testing with normative >> decoder becomes already apparent with the separate test vectors for the >> FIXED and FLOAT implementations. At least for the mono test vectors 3 and >> 4, the FIXED implementation fails when comparing to the FLOAT test vector >> and vice versa. > > [Christian Hoene] Is this a bug that needs to be fixed? No (I checked). It's merely due to the comparison tool being quite strict, which is also why we decided to provide both float and fixed testing tools. I've prepared a slide to discuss this topic in more details during the meeting, so don't worry. Cheers, Jean-Marc From erik.norvell@ericsson.com Wed Nov 16 00:38:06 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2321F94B8 for ; Wed, 16 Nov 2011 00:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUcnDF6yt93P for ; Wed, 16 Nov 2011 00:38:05 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7861021F94B7 for ; Wed, 16 Nov 2011 00:38:05 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-2e-4ec3766b13a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.FF.09514.B6673CE4; Wed, 16 Nov 2011 09:38:04 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 16 Nov 2011 09:38:03 +0100 From: Erik Norvell To: "bens@alum.mit.edu" Date: Wed, 16 Nov 2011 09:38:01 +0100 Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AcyjrLc0MWtZYeBRTnC0kwsd6/+21QAjh0bg Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> In-Reply-To: <4EC28796.5090502@fas.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 08:38:06 -0000 Dear Ben, I am afraid but I strongly disagree with your logic. Interoperability is given through the definition of the meaning of each bit= of the bitstream. =20 One way of achieving such a definition is to require - for an(y) encoder to interoperate with the specified (reference) decoder = and vice-versa - for an(y) decoder to interoperate with the specified (reference) encoder. While such a definition obviously relies on a reference encoder and a refer= ence decoder, it is by no means necessary to make any of them normative.=20 Best regards, Erik > -----Original Message----- > From: Benjamin M. Schwartz [mailto:bmschwar@fas.harvard.edu]=20 > Sent: den 15 november 2011 16:39 > To: Erik Norvell > Cc: codec@ietf.org > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > On 11/09/2011 07:30 AM, Erik Norvell wrote: > > The current situation is that there are no constraints on=20 > the encoder other than that it should produce a readable=20 > bitstream. It may change the quality in any direction. In the=20 > interest of maximizing the implementation freedom, the same=20 > should apply for the decoder. >=20 > The above suggestion is impossible as a matter of logic,=20 > because our purpose is interoperability. >=20 > If the decoder is normatively specified, then an encoder may=20 > be designed so that the output of a compliant decoder sounds=20 > like the original input audio. This is our current situation. >=20 > If the encoder is normatively specified, then a decoder may=20 > be designed so that its output sounds like the original input=20 > audio encoded by a compliant encoder. >=20 > If neither the encoder nor the decoder is normatively=20 > specified, then neither can be designed with any expectation=20 > of what sort of output will be produced. >=20 > Without any normative specification, it would be trivial to=20 > build a compliant but non-interoperable encoder-decoder pair.=20 > Such an encoder would write valid Opus bitstreams, but these=20 > bitstreams would only sound like the original input audio=20 > when played through the corresponding decoder. Similarly,=20 > the decoder would not produce correct audio output when=20 > connected to other encoder implementations. >=20 > Of course, this is all old news. We have already reached=20 > consensus on this issue, which is why it is all explicitly=20 > built into the document that guides our process here: >=20 > http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/?i nclude_text=3D1 >=20 > See Sections 4.1 and 4.3. >=20 > --Ben >=20 > = From hoene@uni-tuebingen.de Wed Nov 16 02:37:11 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2CE21F95A8 for ; Wed, 16 Nov 2011 02:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=3.910, BAYES_00=-2.599, HELO_EQ_DE=0.35, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ+JCS8SpFr2 for ; Wed, 16 Nov 2011 02:37:10 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47521F95A7 for ; Wed, 16 Nov 2011 02:37:10 -0800 (PST) Received: from hoeneT60 (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id pAGAb1I2025987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 11:37:01 +0100 From: "Christian Hoene" To: "'Erik Norvell'" , References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> Date: Wed, 16 Nov 2011 11:37:12 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdnFS6OFAQH0NkTgh2ZlsqwZro7AGUNOupAij5lN0BmDDfU5XisbAQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx05); id=12264-YrlI1T Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:37:11 -0000 Hi, I would suggest to split two things: First, we need a notion for standard conformance because of the legal IPR requirements (can be more relaxing). Second, we need some tests in respect to interoperability (should be more straight). Both tests need to fulfill different requirements. Also, I like Erik's idea to allow for algorithms to replace patented stuff in the codec - even if the quality is a bit worse. With best regards, Christian Hoene > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Erik Norvell > Sent: Wednesday, November 16, 2011 9:38 AM > To: bens@alum.mit.edu > Cc: codec@ietf.org > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 > > Dear Ben, > > I am afraid but I strongly disagree with your logic. > > Interoperability is given through the definition of the meaning of each bit of > the bitstream. > > One way of achieving such a definition is to require > - for an(y) encoder to interoperate with the specified (reference) decoder > and vice-versa > - for an(y) decoder to interoperate with the specified (reference) encoder. > > While such a definition obviously relies on a reference encoder and a > reference decoder, it is by no means necessary to make any of them > normative. > > Best regards, > Erik > > > -----Original Message----- > > From: Benjamin M. Schwartz [mailto:bmschwar@fas.harvard.edu] > > Sent: den 15 november 2011 16:39 > > To: Erik Norvell > > Cc: codec@ietf.org > > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 > > > > On 11/09/2011 07:30 AM, Erik Norvell wrote: > > > The current situation is that there are no constraints on > > the encoder other than that it should produce a readable > > bitstream. It may change the quality in any direction. In the > > interest of maximizing the implementation freedom, the same > > should apply for the decoder. > > > > The above suggestion is impossible as a matter of logic, > > because our purpose is interoperability. > > > > If the decoder is normatively specified, then an encoder may > > be designed so that the output of a compliant decoder sounds > > like the original input audio. This is our current situation. > > > > If the encoder is normatively specified, then a decoder may > > be designed so that its output sounds like the original input > > audio encoded by a compliant encoder. > > > > If neither the encoder nor the decoder is normatively > > specified, then neither can be designed with any expectation > > of what sort of output will be produced. > > > > Without any normative specification, it would be trivial to > > build a compliant but non-interoperable encoder-decoder pair. > > Such an encoder would write valid Opus bitstreams, but these > > bitstreams would only sound like the original input audio > > when played through the corresponding decoder. Similarly, > > the decoder would not produce correct audio output when > > connected to other encoder implementations. > > > > Of course, this is all old news. We have already reached > > consensus on this issue, which is why it is all explicitly > > built into the document that guides our process here: > > > > http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/?i > nclude_text=1 > > > > See Sections 4.1 and 4.3. > > > > --Ben > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron@debian.org Wed Nov 16 11:18:20 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3335111E80DF for ; Wed, 16 Nov 2011 11:18: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+jp5Ty6aaca for ; Wed, 16 Nov 2011 11:18:19 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBC311E80C9 for ; Wed, 16 Nov 2011 11:18:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOILxE55LS0m/2dsb2JhbABDqgKBBoFyAQEEATocKAsLGC4UGA2IObkyiTRjBI0QhyMBkg8 Received: from ppp121-45-45-38.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.45.38]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Nov 2011 05:48:16 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 083844F8F3 for ; Thu, 17 Nov 2011 05:48:15 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DDgTPrNqqTsI for ; Thu, 17 Nov 2011 05:48:14 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4559F4F8FE; Thu, 17 Nov 2011 05:48:14 +1030 (CST) Date: Thu, 17 Nov 2011 05:48:14 +1030 From: Ron To: codec@ietf.org Message-ID: <20111116191814.GF765@audi.shelbyville.oz> References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:18:20 -0000 On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > Hi, > > I would suggest to split two things: > > First, we need a notion for standard conformance because of the legal IPR > requirements (can be more relaxing). > Second, we need some tests in respect to interoperability (should be more > straight). > > Both tests need to fulfill different requirements. I don't see these as different requirements at all. The IPR in this case is not being used to protect a revenue stream garnered from unwitting users of the technology - it is being used to protect the interoperability guarantees that can be offered to end users. Separating these two things, and watering down the protection offered by the IPR does not offer any benefit to users, only to implementers who might be tempted to compromise on interoperability. Possibly for 'practical' reasons, and possibly for 'commercial' reasons of their own - but their reasons don't matter, only the end effect, a degraded user experience, is the important consideration (to avoid) here. There is one requirement. Good interoperability. IPR grant conformance is the only binding method we have of ensuring this. As heretical as it may seem to the FRAND profit seekers - the real profit to be made here from patents is an enhanced and assured user experience. Of course, since I don't actually own any of the IPR, I can't speak for the people who do, or for their motives - but this is what I see as their most valuable gift to us, above and beyond the actual technology itself. > Also, I like Erik's idea to allow for algorithms to replace patented stuff > in the codec - even if the quality is a bit worse. I think this is a fallacy. It was argued that this extra freedom might allow people to produce a 'better' decoder. That seems like nonsense to me, the decoder is never going to be able to recover information that simply isn't there - the best it can do is recover all of it with tight fidelity. Which is what the current conformance test tries to measure. It was also argued that this freedom might allow people to produce a worse decoder. That seems like something we should strongly avoid. There seem to be only three reasons to do this: - Save cycles on underpowered systems. But the requirements already include assessing complexity guarantees are within reasonable bounds. - Sidestep the IPR to produce systems that are not fully interoperable but can still claim (some semblance of) conformance. - Provide distortive 'enhancements' that some users may assess as being pleasing on a first brief listen, but which reduce the real fidelity of the output. (eg. simulate mp3 distortion for the people who listening tests actually prove like that more than lossless original) Both those latter cases carry a danger of sounding like crap if future (real) enhancements are made to the encoder which actually does increase the real fidelity and information content of the encoded signal. The likelihood of such improvements being made to the encoder is high, so I think this is a real jeopardy which we should not inflict upon end users or limit future encoder work by. The decoder should decode the bitstream accurately. If it cannot, then it should not claim to decode Opus. People are always free to sidestep the IPR and make something that sounds worse. They just shouldn't be encouraged or allowed to then also misrepresent that as Opus and mislead the users that this group set out to serve. As some of the liaisons have reminded us, we're here because we wanted to *raise* the bar, not to just continue Business As Usual in patented codec proliferation. So we should do just that. And make everyone happy :) IMO Ron From koen.vos@skype.net Wed Nov 16 18:48:35 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34611E80C7 for ; Wed, 16 Nov 2011 18:48:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOnxso008Rqc for ; Wed, 16 Nov 2011 18:48:34 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5911E80B0 for ; Wed, 16 Nov 2011 18:48:34 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 99F2816F3; Thu, 17 Nov 2011 03:48:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=jo1GPpFqAplpk8zrOhNZQx3XPFo= ; b=u6mu9KH2GBn6wLaL3olyeC+GXBg82xpRO0ZWvLE+UwnoQ9PG6fgqelHQORmN L/y+sHDVRySR4hlvIB+FD+s7uV//gW0fnK+0VnRoKwAcc/ArCVRURAfLz7bpF7NO eVLJKFwMZYdQ0LIWYEjyKGF90LZPlYbJZK22sSYZpF/KShI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=Jc1AQyBbaSxFTJRuPYA459 5I+pHHNOFgZya5l2aQza6CmMqcgWS1orWeIVyMYrmSzSnFB+e2MFYSMbxmD2hKfT cXaf+BDJQOiCvUeexaKbzpuzvnroiEgXsyM3XGL8f31MWrOO3k1wHDqpSDjv2+97 q/hePN9XZZJFQdFcCnOSs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 98425CF; Thu, 17 Nov 2011 03:48:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8105C3506E57; Thu, 17 Nov 2011 03:48:32 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2CXmF5JAn1h; Thu, 17 Nov 2011 03:48:30 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id E2F6D3506E39; Thu, 17 Nov 2011 03:48:30 +0100 (CET) Date: Thu, 17 Nov 2011 03:48:30 +0100 (CET) From: Koen Vos To: Ron Message-ID: <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> In-Reply-To: <20111116191814.GF765@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [60.248.96.35] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org Subject: [codec] Compare tool sensitivity X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:48:35 -0000 (Changed the thread subject) Ron wrote: > There is one requirement. Good interoperability. I agree completely. All compliant future encoders and decoders should work well together. This also prevents embrace-and-extend tactics. However, within the space of guaranteed interop, there are benefits to being lenient: 1. The decoder may be improved for specific use cases, by finding a different tradeoff between quality, delay, complexity, etc. For instance in a non-real time application it may help to have a resampler with higher quality, at the cost of higher delay and complexity. 2. A limited decoder may be better. For instance, an Opus-to-PSTN gateway only needs a decoder to generate 8 kHz output signals. Allowing such a decoder enables optimizations in terms of memory and CPU. (Of course the decoder would still have to decode any Opus bitstream, including one with more than NB content.) 3. The current test disqualifies a huge space of decoders that sound (virtually) identical. Simply getting the sign wrong of the output signal shouldn't make a company liable for a patent lawsuit. A non-goal for the WG, in my opinion, is to ensure that all users get the quality they are deemed to deserve. While nobody wants decoders that sound like crap, few users will stick with an application that plays out a jingle whenever an Opus bitstream is received. And we already allow crappy _encoders_. I prefer the market place to weed out crap over threats of litigation. While there's no perfect solution, I think Jean-Marc and I will come up with a compare tool that provides a small -but useful- amount of freedom to change the decoder without breaking the interop guarantee. koen. ----- Original Message ----- From: "Ron" To: codec@ietf.org Sent: Thursday, November 17, 2011 3:18:14 AM Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > Hi, > > I would suggest to split two things: > > First, we need a notion for standard conformance because of the legal IPR > requirements (can be more relaxing). > Second, we need some tests in respect to interoperability (should be more > straight). > > Both tests need to fulfill different requirements. I don't see these as different requirements at all. The IPR in this case is not being used to protect a revenue stream garnered from unwitting users of the technology - it is being used to protect the interoperability guarantees that can be offered to end users. Separating these two things, and watering down the protection offered by the IPR does not offer any benefit to users, only to implementers who might be tempted to compromise on interoperability. Possibly for 'practical' reasons, and possibly for 'commercial' reasons of their own - but their reasons don't matter, only the end effect, a degraded user experience, is the important consideration (to avoid) here. There is one requirement. Good interoperability. IPR grant conformance is the only binding method we have of ensuring this. As heretical as it may seem to the FRAND profit seekers - the real profit to be made here from patents is an enhanced and assured user experience. Of course, since I don't actually own any of the IPR, I can't speak for the people who do, or for their motives - but this is what I see as their most valuable gift to us, above and beyond the actual technology itself. > Also, I like Erik's idea to allow for algorithms to replace patented stuff > in the codec - even if the quality is a bit worse. I think this is a fallacy. It was argued that this extra freedom might allow people to produce a 'better' decoder. That seems like nonsense to me, the decoder is never going to be able to recover information that simply isn't there - the best it can do is recover all of it with tight fidelity. Which is what the current conformance test tries to measure. It was also argued that this freedom might allow people to produce a worse decoder. That seems like something we should strongly avoid. There seem to be only three reasons to do this: - Save cycles on underpowered systems. But the requirements already include assessing complexity guarantees are within reasonable bounds. - Sidestep the IPR to produce systems that are not fully interoperable but can still claim (some semblance of) conformance. - Provide distortive 'enhancements' that some users may assess as being pleasing on a first brief listen, but which reduce the real fidelity of the output. (eg. simulate mp3 distortion for the people who listening tests actually prove like that more than lossless original) Both those latter cases carry a danger of sounding like crap if future (real) enhancements are made to the encoder which actually does increase the real fidelity and information content of the encoded signal. The likelihood of such improvements being made to the encoder is high, so I think this is a real jeopardy which we should not inflict upon end users or limit future encoder work by. The decoder should decode the bitstream accurately. If it cannot, then it should not claim to decode Opus. People are always free to sidestep the IPR and make something that sounds worse. They just shouldn't be encouraged or allowed to then also misrepresent that as Opus and mislead the users that this group set out to serve. As some of the liaisons have reminded us, we're here because we wanted to *raise* the bar, not to just continue Business As Usual in patented codec proliferation. So we should do just that. And make everyone happy :) IMO Ron _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Thu Nov 17 01:33:07 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B121F9935 for ; Thu, 17 Nov 2011 01:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.294 X-Spam-Level: X-Spam-Status: No, score=-4.294 tagged_above=-999 required=5 tests=[AWL=1.955, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7DqMx6Rq--j for ; Thu, 17 Nov 2011 01:33:06 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id C599421F993E for ; Thu, 17 Nov 2011 01:33:05 -0800 (PST) Received: from hoeneT60 (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id pAH9WkUM028634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2011 10:32:58 +0100 From: "Christian Hoene" To: "'Ron'" , References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> <20111116191814.GF765@audi.shelbyville.oz> In-Reply-To: <20111116191814.GF765@audi.shelbyville.oz> Date: Thu, 17 Nov 2011 10:32:58 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <00b401cca50b$ec086c20$c4194460$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdnFS6OFAQH0NkTgh2ZlsqwZro7AGUNOupAij5lN0BmDDfUwGte1jAAemny8qVx3VgYA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx05); id=26634-VWQ9Ty Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:33:07 -0000 Hi Ron, > On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > > Hi, > > > > I would suggest to split two things: > > > > First, we need a notion for standard conformance because of the legal IPR > > requirements (can be more relaxing). > > Second, we need some tests in respect to interoperability (should be more > > straight). > > > > Both tests need to fulfill different requirements. > > I don't see these as different requirements at all. > > The IPR in this case is not being used to protect a revenue stream garnered > from unwitting users of the technology - it is being used to protect the > interoperability guarantees that can be offered to end users. [Christian Hoene] Sorry, this would be the first standard (that I am aware of) that you can be suited for a standard implementation that is not interoperability - no matter whether it is intentionally or not just a bug. Sorry, but if having bugs in software implementations is not allowed we will have any software at all. Each complex software product has bugs. If you can be charged for every bug in your Opus implementation that limits interoperability, then using Opus will become more expensive as there might be a risk that you have to pay royalties. Insuring this risk is costly. Also, too strict rules would limit any technology progress. This should be avoided in any case. With best regards, Christian From jmvalin@mozilla.com Thu Nov 17 01:56:28 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7442C21F9B92 for ; Thu, 17 Nov 2011 01:56:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRIkGUtUHaGj for ; Thu, 17 Nov 2011 01:56:25 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 00CC321F9B90 for ; Thu, 17 Nov 2011 01:56:25 -0800 (PST) Received: from [130.129.51.78] (dhcp-334e.meeting.ietf.org [130.129.51.78]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 1BFA74AED8D; Thu, 17 Nov 2011 01:56:22 -0800 (PST) Message-ID: <4EC4DA7F.8020502@mozilla.com> Date: Thu, 17 Nov 2011 17:57:19 +0800 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christian Hoene References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> <20111116191814.GF765@audi.shelbyville.oz> <00b401cca50b$ec086c20$c4194460$@uni-tuebingen.de> In-Reply-To: <00b401cca50b$ec086c20$c4194460$@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:56:28 -0000 On 17/11/11 05:32 PM, Christian Hoene wrote: > If you can be charged for every bug in your Opus implementation that limits > interoperability, then using Opus will become more expensive as there might > be a risk that you have to pay royalties. Insuring this risk is costly. Please keep in mind that the conformance test is restricted to test vectors, so there is no risk. Either you pass or you fail and you know that very early on. If it turns out that your decoder fails to correctly decode something other than the test vectors, then you're still "compliant" and the IPR licenses still apply. So regardless of how wide or narrow the compliance test is, there will not be any uncertainty because it will always only apply to the test vectors. That being said, Koen and I are working on the actual test and we should soon have something that is worth showing. Jean-Marc From erik.norvell@ericsson.com Thu Nov 17 05:21:00 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C61011E8121 for ; Thu, 17 Nov 2011 05:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPXCAuSuvF0v for ; Thu, 17 Nov 2011 05:20:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E911E811F for ; Thu, 17 Nov 2011 05:20:58 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-f8-4ec50a395390 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 51.52.09514.93A05CE4; Thu, 17 Nov 2011 14:20:57 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 17 Nov 2011 14:20:57 +0100 From: Erik Norvell To: Ron , "codec@ietf.org" Date: Thu, 17 Nov 2011 14:20:56 +0100 Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AcyklIIoniaTh5LHTyCHOr9zzb7mkAAlx7Zw Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se> References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> <20111116191814.GF765@audi.shelbyville.oz> In-Reply-To: <20111116191814.GF765@audi.shelbyville.oz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 13:21:00 -0000 Ron, You are talking about interoperability guarantees and that the IPRs in the = codec would serve the purpose to offer these guarantees rather than to prot= ect a revenue stream garnered from unwitting users of the technology.=20 =20 I don't believe that the threat of potential litigation is the only way to = maintain interoperability between implementations. Further, I would regard = any discussion about the purpose of IPRs in OPUS as useless. In general ter= ms it is however an undisputable fact that OPUS is not as unencumbered as i= t was the original desire of the group. Hence, please respect that every im= plementer may want to make his own balance of the quality of his product us= ing OPUS on the one hand and the licensing cost/risk stemming from the encu= mbrance of the codec on the other hand. With this background I simply reque= st to respect that implementers may want to have their implementation freed= om. Concerning interoperability itself you seem to confuse this term with a gua= rantee to offer the best possible quality. I don't think that we can go tha= t far. It is definitely not logical given that the encoder would in any cas= e only be informative. So even if you are using a bit exact decoder impleme= ntation you have no quality guarantees because the encoder might be crappy.= (In fact, you don't even have interoperability guaranteed.) Hence, it make= s no sense to be extremely relaxed on the encoding end and at the same time= to be very restrictive on the decoding end. A reasonable definition of the= term interoperability would be required first. In my view interoperability= of a given encoder/decoder pair can only mean that the decoder can produce= a 'useful output' from any bitstreams produced by the encoder operated in = any possible setting. The term useful output should relate to intelligibili= ty, but quality expectations should not be associated with interoperability= . Finally, you seem certain that decoder enhancements are not possible while = encoder enhancements would be. I think there are numerous examples where th= e decoding end of existing (speech) codecs were enhanced. Such enhancements= would be disqualified by a too narrow conformance test even though the dec= oder should be considered interoperable. =20 Best regards Erik=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Ron > Sent: den 16 november 2011 20:18 > To: codec@ietf.org > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > > Hi, > >=20 > > I would suggest to split two things:=20 > >=20 > > First, we need a notion for standard conformance because of=20 > the legal=20 > > IPR requirements (can be more relaxing). > > Second, we need some tests in respect to interoperability=20 > (should be=20 > > more straight). > >=20 > > Both tests need to fulfill different requirements. >=20 > I don't see these as different requirements at all. >=20 > The IPR in this case is not being used to protect a revenue=20 > stream garnered from unwitting users of the technology - it=20 > is being used to protect the interoperability guarantees that=20 > can be offered to end users. >=20 > Separating these two things, and watering down the protection=20 > offered by the IPR does not offer any benefit to users, only=20 > to implementers who might be tempted to compromise on=20 > interoperability. Possibly for 'practical' > reasons, and possibly for 'commercial' reasons of their own -=20 > but their reasons don't matter, only the end effect, a=20 > degraded user experience, is the important consideration (to=20 > avoid) here. >=20 > There is one requirement. Good interoperability. IPR grant=20 > conformance is the only binding method we have of ensuring=20 > this. As heretical as it may seem to the FRAND profit=20 > seekers - the real profit to be made here from patents is an=20 > enhanced and assured user experience. >=20 > Of course, since I don't actually own any of the IPR, I can't=20 > speak for the people who do, or for their motives - but this=20 > is what I see as their most valuable gift to us, above and=20 > beyond the actual technology itself. >=20 >=20 > > Also, I like Erik's idea to allow for algorithms to replace=20 > patented=20 > > stuff in the codec - even if the quality is a bit worse. >=20 > I think this is a fallacy. It was argued that this extra=20 > freedom might allow people to produce a 'better' decoder. =20 > That seems like nonsense to me, the decoder is never going to=20 > be able to recover information that simply isn't there - the=20 > best it can do is recover all of it with tight fidelity. =20 > Which is what the current conformance test tries to measure. >=20 > It was also argued that this freedom might allow people to=20 > produce a worse decoder. That seems like something we should=20 > strongly avoid. > There seem to be only three reasons to do this: >=20 > - Save cycles on underpowered systems. > But the requirements already include assessing complexity=20 > guarantees > are within reasonable bounds. >=20 > - Sidestep the IPR to produce systems that are not fully=20 > interoperable > but can still claim (some semblance of) conformance. >=20 > - Provide distortive 'enhancements' that some users may=20 > assess as being > pleasing on a first brief listen, but which reduce the=20 > real fidelity > of the output. (eg. simulate mp3 distortion for the people who > listening tests actually prove like that more than=20 > lossless original) >=20 > Both those latter cases carry a danger of sounding like crap if future > (real) enhancements are made to the encoder which actually=20 > does increase the real fidelity and information content of=20 > the encoded signal. >=20 > The likelihood of such improvements being made to the encoder=20 > is high, so I think this is a real jeopardy which we should=20 > not inflict upon end users or limit future encoder work by. >=20 > The decoder should decode the bitstream accurately. If it=20 > cannot, then it should not claim to decode Opus. People are=20 > always free to sidestep the IPR and make something that=20 > sounds worse. They just shouldn't be encouraged or allowed=20 > to then also misrepresent that as Opus and mislead the users=20 > that this group set out to serve. As some of the liaisons=20 > have reminded us, we're here because we wanted to *raise* the=20 > bar, not to just continue Business As Usual in patented codec=20 > proliferation. > So we should do just that. And make everyone happy :) >=20 > IMO >=20 > Ron >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > = From erik.norvell@ericsson.com Thu Nov 17 05:42:25 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15BD21F9A16 for ; Thu, 17 Nov 2011 05:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAWMGiM-iEox for ; Thu, 17 Nov 2011 05:42:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B0A4321F9A13 for ; Thu, 17 Nov 2011 05:42:24 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-fe-4ec50f3f73e7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 53.C7.13753.F3F05CE4; Thu, 17 Nov 2011 14:42:23 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.130]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 17 Nov 2011 14:42:23 +0100 From: Erik Norvell To: Koen Vos , Ron Date: Thu, 17 Nov 2011 14:42:22 +0100 Thread-Topic: [codec] Compare tool sensitivity Thread-Index: Acyk02iKuVbTbOU8TG6YChNseq1BbwAW0uog Message-ID: <027A93CE4A670242BD91A44E37105AEF3BB9FEF1EE@ESESSCMS0351.eemea.ericsson.se> References: <20111116191814.GF765@audi.shelbyville.oz> <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> In-Reply-To: <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" Subject: Re: [codec] Compare tool sensitivity X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 13:42:26 -0000 Hi Koen, I agree with your arguments. When it comes to the solution I believe we can= allow even a large amount of freedom and still show interoperability. Best regards, Erik=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Koen Vos > Sent: den 17 november 2011 03:49 > To: Ron > Cc: codec@ietf.org > Subject: [codec] Compare tool sensitivity >=20 > (Changed the thread subject) >=20 > Ron wrote: > > There is one requirement. Good interoperability. >=20 > I agree completely. All compliant future encoders and=20 > decoders should work well together. This also prevents=20 > embrace-and-extend tactics. >=20 > However, within the space of guaranteed interop, there are=20 > benefits to being lenient: >=20 > 1. The decoder may be improved for specific use cases, by=20 > finding a different tradeoff between quality, delay,=20 > complexity, etc. For instance in a non-real time application=20 > it may help to have a resampler with higher quality, at the=20 > cost of higher delay and complexity. >=20 > 2. A limited decoder may be better. For instance, an=20 > Opus-to-PSTN gateway only needs a decoder to generate 8 kHz=20 > output signals. Allowing such a decoder enables=20 > optimizations in terms of memory and CPU. (Of course the=20 > decoder would still have to decode any Opus bitstream,=20 > including one with more than NB content.) =20 >=20 > 3. The current test disqualifies a huge space of decoders=20 > that sound (virtually) identical. Simply getting the sign=20 > wrong of the output signal shouldn't make a company liable=20 > for a patent lawsuit. >=20 > A non-goal for the WG, in my opinion, is to ensure that all=20 > users get the quality they are deemed to deserve. While=20 > nobody wants decoders that sound like crap, few users will=20 > stick with an application that plays out a jingle whenever an=20 > Opus bitstream is received. And we already allow crappy=20 > _encoders_. I prefer the market place to weed out crap over=20 > threats of litigation. >=20 > While there's no perfect solution, I think Jean-Marc and I=20 > will come up with a compare tool that provides a small -but=20 > useful- amount of freedom to change the decoder without=20 > breaking the interop guarantee. >=20 > koen. >=20 >=20 > ----- Original Message ----- > From: "Ron" > To: codec@ietf.org > Sent: Thursday, November 17, 2011 3:18:14 AM > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > > Hi, > >=20 > > I would suggest to split two things:=20 > >=20 > > First, we need a notion for standard conformance because of=20 > the legal=20 > > IPR requirements (can be more relaxing). > > Second, we need some tests in respect to interoperability=20 > (should be=20 > > more straight). > >=20 > > Both tests need to fulfill different requirements. >=20 > I don't see these as different requirements at all. >=20 > The IPR in this case is not being used to protect a revenue=20 > stream garnered from unwitting users of the technology - it=20 > is being used to protect the interoperability guarantees that=20 > can be offered to end users. >=20 > Separating these two things, and watering down the protection=20 > offered by the IPR does not offer any benefit to users, only=20 > to implementers who might be tempted to compromise on=20 > interoperability. Possibly for 'practical' > reasons, and possibly for 'commercial' reasons of their own -=20 > but their reasons don't matter, only the end effect, a=20 > degraded user experience, is the important consideration (to=20 > avoid) here. >=20 > There is one requirement. Good interoperability. IPR grant=20 > conformance is the only binding method we have of ensuring=20 > this. As heretical as it may seem to the FRAND profit=20 > seekers - the real profit to be made here from patents is an=20 > enhanced and assured user experience. >=20 > Of course, since I don't actually own any of the IPR, I can't=20 > speak for the people who do, or for their motives - but this=20 > is what I see as their most valuable gift to us, above and=20 > beyond the actual technology itself. >=20 >=20 > > Also, I like Erik's idea to allow for algorithms to replace=20 > patented=20 > > stuff in the codec - even if the quality is a bit worse. >=20 > I think this is a fallacy. It was argued that this extra=20 > freedom might allow people to produce a 'better' decoder. =20 > That seems like nonsense to me, the decoder is never going to=20 > be able to recover information that simply isn't there - the=20 > best it can do is recover all of it with tight fidelity. =20 > Which is what the current conformance test tries to measure. >=20 > It was also argued that this freedom might allow people to=20 > produce a worse decoder. That seems like something we should=20 > strongly avoid. > There seem to be only three reasons to do this: >=20 > - Save cycles on underpowered systems. > But the requirements already include assessing complexity=20 > guarantees > are within reasonable bounds. >=20 > - Sidestep the IPR to produce systems that are not fully=20 > interoperable > but can still claim (some semblance of) conformance. >=20 > - Provide distortive 'enhancements' that some users may=20 > assess as being > pleasing on a first brief listen, but which reduce the=20 > real fidelity > of the output. (eg. simulate mp3 distortion for the people who > listening tests actually prove like that more than=20 > lossless original) >=20 > Both those latter cases carry a danger of sounding like crap if future > (real) enhancements are made to the encoder which actually=20 > does increase the real fidelity and information content of=20 > the encoded signal. >=20 > The likelihood of such improvements being made to the encoder=20 > is high, so I think this is a real jeopardy which we should=20 > not inflict upon end users or limit future encoder work by. >=20 > The decoder should decode the bitstream accurately. If it=20 > cannot, then it should not claim to decode Opus. People are=20 > always free to sidestep the IPR and make something that=20 > sounds worse. They just shouldn't be encouraged or allowed=20 > to then also misrepresent that as Opus and mislead the users=20 > that this group set out to serve. As some of the liaisons=20 > have reminded us, we're here because we wanted to *raise* the=20 > bar, not to just continue Business As Usual in patented codec=20 > proliferation. > So we should do just that. And make everyone happy :) >=20 > IMO >=20 > Ron >=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 ron@debian.org Thu Nov 17 06:50:40 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248D11E80BE for ; Thu, 17 Nov 2011 06:50:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm-hPW3IB+tv for ; Thu, 17 Nov 2011 06:50:40 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C564311E808D for ; Thu, 17 Nov 2011 06:50:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPoexU55LS0m/2dsb2JhbABCqimBBoFyAQEFDiwcDw8VCxguFBgNvj2KFwSNEYcjAZIP Received: from ppp121-45-45-38.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.45.38]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Nov 2011 01:20:30 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8383A4F8F3 for ; Fri, 18 Nov 2011 01:13:37 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9CvwdkQU+pZp for ; Fri, 18 Nov 2011 01:13:36 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BC8FE4F8FE; Fri, 18 Nov 2011 01:13:36 +1030 (CST) Date: Fri, 18 Nov 2011 01:13:36 +1030 From: Ron To: codec@ietf.org Message-ID: <20111117144336.GG765@audi.shelbyville.oz> References: <4EAF4419.3000502@jdrosen.net> <027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se> <4EC28796.5090502@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se> <011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de> <20111116191814.GF765@audi.shelbyville.oz> <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:50:41 -0000 Hi Erik, On Thu, Nov 17, 2011 at 02:20:56PM +0100, Erik Norvell wrote: > Ron, > > You are talking about interoperability guarantees and that the IPRs in the codec would serve the purpose to offer these guarantees rather than to protect a revenue stream garnered from unwitting users of the technology. > > I don't believe that the threat of potential litigation is the only way to maintain interoperability between implementations. Further, I would regard any discussion about the purpose of IPRs in OPUS as useless. In general terms it is however an undisputable fact that OPUS is not as unencumbered as it was the original desire of the group. Hence, please respect that every implementer may want to make his own balance of the quality of his product using OPUS on the one hand and the licensing cost/risk stemming from the encumbrance of the codec on the other hand. With this background I simply request to respect that implementers may want to have their implementation freedom. > > Concerning interoperability itself you seem to confuse this term with a guarantee to offer the best possible quality. I don't think that we can go that far. It is definitely not logical given that the encoder would in any case only be informative. So even if you are using a bit exact decoder implementation you have no quality guarantees because the encoder might be crappy. (In fact, you don't even have interoperability guaranteed.) Hence, it makes no sense to be extremely relaxed on the encoding end and at the same time to be very restrictive on the decoding end. A reasonable definition of the term interoperability would be required first. In my view interoperability of a given encoder/decoder pair can only mean that the decoder can produce a 'useful output' from any bitstreams produced by the encoder operated in any possible setting. The term useful output should relate to intelligibility, but quality expectations should not be associated with interoperability. > > Finally, you seem certain that decoder enhancements are not possible while encoder enhancements would be. I think there are numerous examples where the decoding end of existing (speech) codecs were enhanced. Such enhancements would be disqualified by a too narrow conformance test even though the decoder should be considered interoperable. I think you give an excellent meta-example here of the dangers inherent to "enhanced decoding". You seem to have extrapolated quite broadly from the bitstream I presented you, and I declare your output to be clearly non-conformant to the reference :) I didn't say anything about guaranteeing absolute quality. That's a function of the encoder. In order to be able to optimise that function though we need a decoder that is deterministic. The reference encoder is Free, both in licence and royalty terms, and is basically transparent over a wide range of bitrates. I don't think we need to worry about the people who might write crappy encoders. Nobody will use them, or nobody will listen to their content if they do. That's quite a different issue from people selling hardware with crap decoders in their firmware, or people publishing listening tests with the crap but conformant decoder they wrote over the weekend. If you really can't live without distorting 'decoder enhancements' like bass boost or whatever, you can always add that as a post processing stage. Defining compliance in terms of "my mom thinks it sounds ok" or something similarly handwavy is not good engineering. I agree with Koen that we should not preclude things which reasonable people, with an interest in the codec actually succeeding, would consider an acceptable implementation. I strongly disagree with the attempts to define "I could understand 5 out of the 7 words" as being within that bound of acceptable. I'm pretty sure you'll still be able to do that without treading on anyone's IPR. So let's just let Koen and Jean-Marc find a middle ground, shall we. I'm pretty sure they'll do as good a job on that as they have with the codec to date. Faithfully Ron From mramalho@cisco.com Thu Nov 17 07:55:54 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E2D11E80C9 for ; Thu, 17 Nov 2011 07:55: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnQbhA9LAEGg for ; Thu, 17 Nov 2011 07:55:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0711E8106 for ; Thu, 17 Nov 2011 07:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=8773; q=dns/txt; s=iport; t=1321545348; x=1322754948; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=qFjlltRfRbcmlxO6YGCf7+pteV5js3UVJVmJ4rdXmI8=; b=YyolRG5A2b0i4F5+YcEWZRrkt0JxABEMs84igFj6+1WhNEOAumUKLa8I nwk8h7EAhtCVZ3Rqun8IX5Yl3pa9vilw9CJFokffixcgAZYOeD2axul1X H9FC+vw9lRsBwJCHF3rSjbIG6WasAOgeuKDPhWyaQ0psN4duzGHJDc32g A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAAA8uxU6tJXHA/2dsb2JhbABCmXqQMoEFgXIBAQEDAQEBAQsEAR0KKwkQBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah2AIl14Bnk4EiTRjBIgVkWSMVw X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; d="scan'208";a="36960080" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Nov 2011 15:55:47 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAHFtmWc007430; Thu, 17 Nov 2011 15:55:48 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 09:55:47 -0600 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, 17 Nov 2011 09:55:46 -0600 Message-ID: <999109E6BC528947A871CDEB5EB908A00501D09A@XMB-RCD-209.cisco.com> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] WGLC #2 for draft-ietf-codec-opus-10 Thread-Index: AcyklIIoniaTh5LHTyCHOr9zzb7mkAAlx7ZwAAT+ayA= References: <4EAF4419.3000502@jdrosen.net><027A93CE4A670242BD91A44E37105AEF3BB9CEAE91@ESESSCMS0351.eemea.ericsson.se><4EC28796.5090502@fas.harvard.edu><027A93CE4A670242BD91A44E37105AEF3BB9FEEC3F@ESESSCMS0351.eemea.ericsson.se><011701cca44b$b525d640$1f7182c0$@uni-tuebingen.de><20111116191814.GF765@audi.shelbyville.oz> <027A93CE4A670242BD91A44E37105AEF3BB9FEF1D2@ESESSCMS0351.eemea.ericsson.se> From: "Michael Ramalho (mramalho)" To: "Erik Norvell" , "Ron" , X-OriginalArrivalTime: 17 Nov 2011 15:55:47.0954 (UTC) FILETIME=[5F701520:01CCA541] Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:55:54 -0000 All, Re: " Further, I would regard any discussion about the purpose of IPRs in OPUS as useless. In general terms it is however an undisputable fact that OPUS is not as unencumbered as it was the original desire of the group." Sorry for dropping in late on this thread, and my comment is not specific to Ron's comment (Ron, your email is simply convenient - don't read my reply to your email to be referencing you specifically). I think Ron's comment is particularly interesting given Skype's IPR statement (Skype: https://datatracker.ietf.org/ipr/1602/ ). Assuming that MSFT does close on the Skype acquisition, the royalty-free language appears to me to come with the condition that the receiving entity agrees to not sue MSFT for ANY MSFT patent (even those patents NOT RELATED to OPUS). I am not a lawyer, but here is the language: Skype will retain the right to terminate the license and assert its patents (including the right to claim past royalties) against any licensee that asserts or whose affiliate asserts >>>ANY<<< patent (either directly or indirectly) against Skype or any of Skype's affiliates or >>>SUCCESSORS IN TITLE<<<. That, to some companies, may be a really big legal concession to make for use of an audio codec. I am not a lawyer, but I did stay at a Holiday Inn Express last night (joke only to be understood by US attendees) ... Michael Ramalho, Ph.D. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Erik Norvell Sent: Thursday, November 17, 2011 8:21 AM To: Ron; codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 Ron, You are talking about interoperability guarantees and that the IPRs in the codec would serve the purpose to offer these guarantees rather than to protect a revenue stream garnered from unwitting users of the technology.=20 =20 I don't believe that the threat of potential litigation is the only way to maintain interoperability between implementations. Further, I would regard any discussion about the purpose of IPRs in OPUS as useless. In general terms it is however an undisputable fact that OPUS is not as unencumbered as it was the original desire of the group. Hence, please respect that every implementer may want to make his own balance of the quality of his product using OPUS on the one hand and the licensing cost/risk stemming from the encumbrance of the codec on the other hand. With this background I simply request to respect that implementers may want to have their implementation freedom. Concerning interoperability itself you seem to confuse this term with a guarantee to offer the best possible quality. I don't think that we can go that far. It is definitely not logical given that the encoder would in any case only be informative. So even if you are using a bit exact decoder implementation you have no quality guarantees because the encoder might be crappy. (In fact, you don't even have interoperability guaranteed.) Hence, it makes no sense to be extremely relaxed on the encoding end and at the same time to be very restrictive on the decoding end. A reasonable definition of the term interoperability would be required first. In my view interoperability of a given encoder/decoder pair can only mean that the decoder can produce a 'useful output' from any bitstreams produced by the encoder operated in any possible setting. The term useful output should relate to intelligibility, but quality expectations should not be associated with interoperability. Finally, you seem certain that decoder enhancements are not possible while encoder enhancements would be. I think there are numerous examples where the decoding end of existing (speech) codecs were enhanced. Such enhancements would be disqualified by a too narrow conformance test even though the decoder should be considered interoperable. =20 Best regards Erik=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Ron > Sent: den 16 november 2011 20:18 > To: codec@ietf.org > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 >=20 > On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > > Hi, > >=20 > > I would suggest to split two things:=20 > >=20 > > First, we need a notion for standard conformance because of=20 > the legal=20 > > IPR requirements (can be more relaxing). > > Second, we need some tests in respect to interoperability=20 > (should be=20 > > more straight). > >=20 > > Both tests need to fulfill different requirements. >=20 > I don't see these as different requirements at all. >=20 > The IPR in this case is not being used to protect a revenue=20 > stream garnered from unwitting users of the technology - it=20 > is being used to protect the interoperability guarantees that=20 > can be offered to end users. >=20 > Separating these two things, and watering down the protection=20 > offered by the IPR does not offer any benefit to users, only=20 > to implementers who might be tempted to compromise on=20 > interoperability. Possibly for 'practical' > reasons, and possibly for 'commercial' reasons of their own -=20 > but their reasons don't matter, only the end effect, a=20 > degraded user experience, is the important consideration (to=20 > avoid) here. >=20 > There is one requirement. Good interoperability. IPR grant=20 > conformance is the only binding method we have of ensuring=20 > this. As heretical as it may seem to the FRAND profit=20 > seekers - the real profit to be made here from patents is an=20 > enhanced and assured user experience. >=20 > Of course, since I don't actually own any of the IPR, I can't=20 > speak for the people who do, or for their motives - but this=20 > is what I see as their most valuable gift to us, above and=20 > beyond the actual technology itself. >=20 >=20 > > Also, I like Erik's idea to allow for algorithms to replace=20 > patented=20 > > stuff in the codec - even if the quality is a bit worse. >=20 > I think this is a fallacy. It was argued that this extra=20 > freedom might allow people to produce a 'better' decoder. =20 > That seems like nonsense to me, the decoder is never going to=20 > be able to recover information that simply isn't there - the=20 > best it can do is recover all of it with tight fidelity. =20 > Which is what the current conformance test tries to measure. >=20 > It was also argued that this freedom might allow people to=20 > produce a worse decoder. That seems like something we should=20 > strongly avoid. > There seem to be only three reasons to do this: >=20 > - Save cycles on underpowered systems. > But the requirements already include assessing complexity=20 > guarantees > are within reasonable bounds. >=20 > - Sidestep the IPR to produce systems that are not fully=20 > interoperable > but can still claim (some semblance of) conformance. >=20 > - Provide distortive 'enhancements' that some users may=20 > assess as being > pleasing on a first brief listen, but which reduce the=20 > real fidelity > of the output. (eg. simulate mp3 distortion for the people who > listening tests actually prove like that more than=20 > lossless original) >=20 > Both those latter cases carry a danger of sounding like crap if future > (real) enhancements are made to the encoder which actually=20 > does increase the real fidelity and information content of=20 > the encoded signal. >=20 > The likelihood of such improvements being made to the encoder=20 > is high, so I think this is a real jeopardy which we should=20 > not inflict upon end users or limit future encoder work by. >=20 > The decoder should decode the bitstream accurately. If it=20 > cannot, then it should not claim to decode Opus. People are=20 > always free to sidestep the IPR and make something that=20 > sounds worse. They just shouldn't be encouraged or allowed=20 > to then also misrepresent that as Opus and mislead the users=20 > that this group set out to serve. As some of the liaisons=20 > have reminded us, we're here because we wanted to *raise* the=20 > bar, not to just continue Business As Usual in patented codec=20 > proliferation. > So we should do just that. And make everyone happy :) >=20 > IMO >=20 > Ron >=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 From jridges@masque.com Fri Nov 18 06:29:03 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7C21F8AFB for ; Fri, 18 Nov 2011 06:29:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BuTVBoG6DDJ for ; Fri, 18 Nov 2011 06:29:03 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id 37CEF21F8AF9 for ; Fri, 18 Nov 2011 06:29:03 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id DBFBB1602AD for ; Fri, 18 Nov 2011 07:29:02 -0700 (MST) Message-ID: <4EC66BAE.9000600@masque.com> Date: Fri, 18 Nov 2011 07:29:02 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:29:03 -0000 Hi, Since the codec conformance is a hot topic right now, I thought I would ask a (probably dumb) question. Is it possible to create a conforming (and thus unencumbered) Opus codec from the reference implementation that can use a sample rate of, say, 44100 Hz? If so, what are the rules that would guarantee conformance? Thanks, John Ridges From gmaxwell@juniper.net Fri Nov 18 07:19:59 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D37121F8AD9 for ; Fri, 18 Nov 2011 07:19: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnX7h61s+cIq for ; Fri, 18 Nov 2011 07:19:55 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 41B9121F8AD8 for ; Fri, 18 Nov 2011 07:19:55 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTsZ3mX/AAo3ZOXs9TTEhTWymR0thOoA3@postini.com; Fri, 18 Nov 2011 07:19:55 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; Fri, 18 Nov 2011 07:18:12 -0800 From: Gregory Maxwell To: John Ridges , "codec@ietf.org" Date: Fri, 18 Nov 2011 07:18:11 -0800 Thread-Topic: [codec] Conformance with unusual sample rates Thread-Index: Acyl/nPnzJ3payWGST25aUfeyNLk7gAA0JuH Message-ID: References: <4EC66BAE.9000600@masque.com> In-Reply-To: <4EC66BAE.9000600@masque.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 15:19:59 -0000 John Ridges [jridges@masque.com] wrote: > Since the codec conformance is a hot topic right now, I thought I would > ask a (probably dumb) question. Is it possible to create a conforming > (and thus unencumbered) Opus codec from the reference implementation > that can use a sample rate of, say, 44100 Hz? If so, what are the rules > that would guarantee conformance? Thanks, The _correct way_ to use Opus with 44100 Hz is to use a resampler.=20 This is, for example, how the opus-tools package uses the reference library to support any input and output sampling rates the user desires, transparently and painlessly. (https://git.xiph.org/?p=3Dusers/jm/opus-tool= s.git) Personally, I think that it's most accurate to think of Opus as a sample-ra= teless format. Any rate can go into the encoder, you get packets out at 2.5-120ms= =20 intervals, and any rate can come out of the decoder. For particular rates (8000,12000,16000,24000,48000) the conversion from opus to audio is extra efficient so those are the ones that the reference library supports directl= y. (But not other rates because platform specific optimized resampling would do better) The computational cost of a resampler is not significant compared to the codec, there is no quality impact from a reasonable resampler. Any other option and you'd suffer from loss of coding efficiency, loss of interoperability, lost of on the fly mode agility, etc. = From bmschwar@fas.harvard.edu Fri Nov 18 07:56:30 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908D221F869E for ; Fri, 18 Nov 2011 07:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hQ-3ZolxkGY for ; Fri, 18 Nov 2011 07:56:26 -0800 (PST) Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A41821F8678 for ; Fri, 18 Nov 2011 07:56:26 -0800 (PST) Received: from us25.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 141B61D7DA2; Fri, 18 Nov 2011 10:56:24 -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=z/r40czn96I+2P9 gS/0t7v2R0Sun+izpQL+p+/zSZ6Y=; b=fu7+SXjkEqrc/wUrNF0U2KjFz1BSri1 gsqunb3Rx497v/t+F1KveeQnViLo41nEy6ym+XP1WZsw0X8w7eNg/oG7CgWNacvp tVqVAWoenuCSI4arCG40r6+aLJ1yV2OUWG6IedvVS+Ce0br9lNoxS03NtFPMSok/ 8pqzxR9Quzt8= 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=sJwnM4wbD lUJzxErsYtkYhH7NONYEniHUbdBjhREI6syVG/tN0kdt9xy8b3i8sSRdNHgZgY7t bV7PoY0ywTcjHgllVZn0ovQRJEga8Qjt3EfXxJW2XDqXWx10IQx7ILg552S0QxTE 7q4Lj/KurNqRUmpq4WWQSP4n5RpiIAZyiI= Received: from [172.23.141.71] (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 us25.unix.fas.harvard.edu (Postfix) with ESMTPSA id 0E5491D7D9F; Fri, 18 Nov 2011 10:56:24 -0500 (EST) Message-ID: <4EC68024.8010308@fas.harvard.edu> Date: Fri, 18 Nov 2011 10:56:20 -0500 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: John Ridges References: <4EC66BAE.9000600@masque.com> In-Reply-To: <4EC66BAE.9000600@masque.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD62933EA467C6ECE6E11BBE1" Cc: codec@ietf.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 15:56:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD62933EA467C6ECE6E11BBE1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/18/2011 09:29 AM, John Ridges wrote: > Is it possible to create a conforming (and > thus unencumbered) Opus codec from the reference implementation that ca= n > use a sample rate of, say, 44100 Hz? It depends what you mean. One answer is "no". Opus always operates at a fixed nominal samplerate o= f 48000 Hz. Another answer is "yes", because you are of course always free to resampl= e your inputs before encoding, and to resample the outputs after decoding. If you figure out a way to use less CPU by integrating your resampler int= o the decoder then that's just a trivial implementation detail. Another answer is "yes, in Opus-custom". Opus-custom is a non-interoperable Opus-derived codec development system, defined as part of the Opus standard [1]. Opus-custom can be driven at different samplerates, including 44100 Hz. --Ben P.S. I do agree that clarifying our text on this point might be helpful. [1] http://tools.ietf.org/html/draft-ietf-codec-opus-10#section-6.2 --------------enigD62933EA467C6ECE6E11BBE1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7GgCUACgkQUJT6e6HFtqSYFACcCMOWw8ZUVouhSYwH4C2vCt7h mGsAn067DVGHdQ420BYU5EaSnexLmPP/ =UREU -----END PGP SIGNATURE----- --------------enigD62933EA467C6ECE6E11BBE1-- From gmaxwell@juniper.net Fri Nov 18 08:13:32 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A873D21F8A96 for ; Fri, 18 Nov 2011 08:13:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUFwR1eZO4er for ; Fri, 18 Nov 2011 08:13:32 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC721F84CD for ; Fri, 18 Nov 2011 08:13:31 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTsaEHz3BcePnzPp9Gubt/2V2vS9s0Qsz@postini.com; Fri, 18 Nov 2011 08:13:31 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; Fri, 18 Nov 2011 08:10:51 -0800 From: Gregory Maxwell To: "bens@alum.mit.edu" , John Ridges Date: Fri, 18 Nov 2011 08:07:52 -0800 Thread-Topic: [codec] Conformance with unusual sample rates Thread-Index: AcymCqU/+I/JzKCdSJyeVTTShHxl1QAAZS/a Message-ID: References: <4EC66BAE.9000600@masque.com>,<4EC68024.8010308@fas.harvard.edu> In-Reply-To: <4EC68024.8010308@fas.harvard.edu> 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] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 16:13:32 -0000 Behalf Of Benjamin M. Schwartz [bmschwar@fas.harvard.edu]: > One answer is "no". Opus always operates at a fixed nominal samplerate o= f > 48000 Hz. It's not really any more true to say 48k there than to say 8k, 12k, 16k, 24= k other than the fact that you'd timestamp it at 48k.=20 Which is why I think it's most accurate to describe it as rate-less. From jridges@masque.com Fri Nov 18 08:20:51 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9321F8A67 for ; Fri, 18 Nov 2011 08:20: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21u+ma0vfjoG for ; Fri, 18 Nov 2011 08:20:50 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id BF1DB21F88AB for ; Fri, 18 Nov 2011 08:20:50 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id 4352C1602A6; Fri, 18 Nov 2011 09:20:50 -0700 (MST) Message-ID: <4EC685E1.3070000@masque.com> Date: Fri, 18 Nov 2011 09:20:49 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: bens@alum.mit.edu References: <4EC66BAE.9000600@masque.com> <4EC68024.8010308@fas.harvard.edu> In-Reply-To: <4EC68024.8010308@fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 16:20:51 -0000 Thank-you for clarifying that. I also have another application where I need to use 16 ms frames and it looks like Opus-custom would allow me to do that. John Ridges On 11/18/2011 8:56 AM, Benjamin M. Schwartz wrote: > On 11/18/2011 09:29 AM, John Ridges wrote: >> Is it possible to create a conforming (and >> thus unencumbered) Opus codec from the reference implementation that can >> use a sample rate of, say, 44100 Hz? > It depends what you mean. > > One answer is "no". Opus always operates at a fixed nominal samplerate of > 48000 Hz. > > Another answer is "yes", because you are of course always free to resample > your inputs before encoding, and to resample the outputs after decoding. > If you figure out a way to use less CPU by integrating your resampler into > the decoder then that's just a trivial implementation detail. > > Another answer is "yes, in Opus-custom". Opus-custom is a > non-interoperable Opus-derived codec development system, defined as part > of the Opus standard [1]. Opus-custom can be driven at different > samplerates, including 44100 Hz. > > --Ben > > P.S. I do agree that clarifying our text on this point might be helpful. > > [1] http://tools.ietf.org/html/draft-ietf-codec-opus-10#section-6.2 > From giles@thaumas.net Fri Nov 18 13:54:08 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68C711E80E4 for ; Fri, 18 Nov 2011 13:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyPcghcwJ1uX for ; Fri, 18 Nov 2011 13:54:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1096211E80DE for ; Fri, 18 Nov 2011 13:54:07 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so712029vbb.31 for ; Fri, 18 Nov 2011 13:54:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.16.243 with SMTP id j19mr5310623vdd.109.1321653246290; Fri, 18 Nov 2011 13:54:06 -0800 (PST) Received: by 10.220.205.196 with HTTP; Fri, 18 Nov 2011 13:54:06 -0800 (PST) X-Originating-IP: [184.71.166.126] In-Reply-To: <4EAF4419.3000502@jdrosen.net> References: <4EAF4419.3000502@jdrosen.net> Date: Fri, 18 Nov 2011 13:54:06 -0800 Message-ID: From: Ralph Giles To: Jean-Marc Valin Content-Type: multipart/mixed; boundary=bcaec5014dc142eaa604b20960ad Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:54:08 -0000 --bcaec5014dc142eaa604b20960ad Content-Type: text/plain; charset=UTF-8 Please find attached a patch fixes some editorial issues with opus-10 draft. -r --bcaec5014dc142eaa604b20960ad Content-Type: application/octet-stream; name="0001-Fix-various-typing-and-spelling-errors-in-the-draft.patch" Content-Disposition: attachment; filename="0001-Fix-various-typing-and-spelling-errors-in-the-draft.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv5q7nx00 RnJvbSAyMTU5MzgxMzllYWFmOGE0ZTkwNTA2OTJkNTQ3NGUxYzQ3OTc3OWQ0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSYWxwaCBHaWxlcyA8Z2lsZXNAbW96aWxsYS5jb20+CkRhdGU6 IEZyaSwgMTggTm92IDIwMTEgMTM6NDg6MDEgLTA4MDAKU3ViamVjdDogW1BBVENIXSBGaXggdmFy aW91cyB0eXBpbmcgYW5kIHNwZWxsaW5nIGVycm9ycyBpbiB0aGUgZHJhZnQuCgpBbHNvIHJlZ3Vs YXJpc2VzIHNvbWUgQ2FuYWRpYW4gc3BlbGxpbmcgdG8gVVMgbGlrZSB0aGUgcmVzdCBvZgp0aGUg ZG9jdW1lbnQuCi0tLQogZG9jL2RyYWZ0LWlldGYtY29kZWMtb3B1cy54bWwgfCAgIDI2ICsrKysr KysrKysrKystLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKyks IDEzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RvYy9kcmFmdC1pZXRmLWNvZGVjLW9wdXMu eG1sIGIvZG9jL2RyYWZ0LWlldGYtY29kZWMtb3B1cy54bWwKaW5kZXggYTUxOTlmNC4uZDUzYzIw ZSAxMDA2NDQKLS0tIGEvZG9jL2RyYWZ0LWlldGYtY29kZWMtb3B1cy54bWwKKysrIGIvZG9jL2Ry YWZ0LWlldGYtY29kZWMtb3B1cy54bWwKQEAgLTI2Niw3ICsyNjYsNyBAQCBBIHNhbXBsZSByYXRl IG9mIDI0Jm5ic3A7a0h6IGFsc28gbWFrZXMgcmVzYW1wbGluZyBpbiB0aGUgTURDVCBsYXllciBl YXNpZXIsCiAgYXMgMjQgZXZlbmx5IGRpdmlkZXMgNDgsIGFuZCB3aGVuIDI0Jm5ic3A7a0h6IGlz IHN1ZmZpY2llbnQsIGl0IGNhbiBzYXZlCiAgY29tcHV0YXRpb24gaW4gb3RoZXIgcHJvY2Vzc2lu Zywgc3VjaCBhcyBBY291c3RpYyBFY2hvIENhbmNlbGxhdGlvbiAoQUVDKS4KIEV4cGVyaW1lbnRh bCBjaGFuZ2VzIHRvIHRoZSBiYW5kIGxheW91dCB0byBhbGxvdyBhIDE2Jm5ic3A7a0h6IGN1dG9m ZgotICgzMiZuYnNwO2tIeiBlZmZlY3RpdmUgc2FtcGxlIHJhdGUpIHNob3dlZCBwb3RlbnRpYWwg cXVhbGl0eSBkZWdyZWRhdGlvbnMgYXQKKyAoMzImbmJzcDtrSHogZWZmZWN0aXZlIHNhbXBsZSBy YXRlKSBzaG93ZWQgcG90ZW50aWFsIHF1YWxpdHkgZGVncmFkYXRpb25zIGF0CiAgb3RoZXIgc2Ft cGxlIHJhdGVzLCBhbmQgYXQgdHlwaWNhbCBiaXRyYXRlcyB0aGUgbnVtYmVyIG9mIGJpdHMgc2F2 ZWQgYnkgdXNpbmcKICBzdWNoIGEgY3V0b2ZmIGluc3RlYWQgb2YgY29kaW5nIGluIGZ1bGxiYW5k IChGQikgbW9kZSBpcyB2ZXJ5IHNtYWxsLgogVGhlcmVmb3JlLCBpZiBhbiBhcHBsaWNhdGlvbiB3 aXNoZXMgdG8gcHJvY2VzcyBhIHNpZ25hbCBzYW1wbGVkIGF0IDMyJm5ic3A7a0h6LApAQCAtNDI3 Miw3ICs0MjcyLDcgQEAgVGhlIGRlY29kZXIgY2hvb3NlcyB0aGUgUERGIGZvciB0aGUgc2lnbiBi YXNlZCBvbiB0aGUgc2lnbmFsIHR5cGUgYW5kCiAgcXVhbnRpemF0aW9uIG9mZnNldCB0eXBlIChm cm9tIDx4cmVmIHRhcmdldD0ic2lsa19mcmFtZV90eXBlIi8+KSBhbmQgdGhlCiAgbnVtYmVyIG9m IHB1bHNlcyBpbiB0aGUgYmxvY2sgKGZyb20gPHhyZWYgdGFyZ2V0PSJzaWxrX3B1bHNlX2NvdW50 cyIvPikuCiBUaGUgbnVtYmVyIG9mIHB1bHNlcyBpbiB0aGUgYmxvY2sgZG9lcyBub3QgdGFrZSBp bnRvIGFjY291bnQgYW55IExTQnMuCi1Nb3N0IFBERnMgYXJlIHNrZXdlZCB0b3dhcmRzIG5lZ2F0 aXZlIHNpZ25zIGJlY2F1c2Ugb2YgdGhlIHF1YW50aXphdG9uIG9mZnNldCwKK01vc3QgUERGcyBh cmUgc2tld2VkIHRvd2FyZHMgbmVnYXRpdmUgc2lnbnMgYmVjYXVzZSBvZiB0aGUgcXVhbnRpemF0 aW9uIG9mZnNldCwKICBidXQgdGhlIFBERnMgZm9yIHplcm8gcHVsc2VzIGFyZSBoaWdobHkgc2tl d2VkIHRvd2FyZHMgcG9zaXRpdmUgc2lnbnMuCiBJZiBhIGJsb2NrIGNvbnRhaW5zIG1hbnkgcG9z aXRpdmUgY29lZmZpY2llbnRzLCBpdCBpcyBzb21ldGltZXMgYmVuZWZpY2lhbCB0bwogIGNvZGUg aXQgc29sZWx5IHVzaW5nIExTQnMgKGkuZS4sIHdpdGggemVybyBwdWxzZXMpLCBzaW5jZSB0aGUg ZW5jb2RlciBtYXkgYmUKQEAgLTQ2MjgsNyArNDYyOCw3IEBAIEZvciB0aGUgZmlyc3QgZnJhbWUg YWZ0ZXIgYSBkZWNvZGVyIHJlc2V0LCB6ZXJvcyBhcmUgdXNlZCBpbnN0ZWFkLgogQWZ0ZXIgc3Rl cmVvIHVubWl4aW5nIChpZiBhbnkpLCB0aGUgZGVjb2RlciBhcHBsaWVzIHJlc2FtcGxpbmcgdG8g Y29udmVydCB0aGUKICBkZWNvZGVkIFNJTEsgb3V0cHV0IHRvIHRoZSBzYW1wbGUgcmF0ZSBkZXNp cmVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4KIFRoaXMgaXMgbmVjZXNzYXJ5IHdoZW4gZGVjb2Rpbmcg YSBIeWJyaWQgZnJhbWUgYXQgU1dCIG9yIEZCIHNhbXBsZSByYXRlcywgb3IKLSB3aGVudmVyIHRo ZSBkZWNvZGVyIHdhbnRzIHRoZSBvdXRwdXQgYXQgYSBkaWZmZXJlbnQgc2FtcGxlIHJhdGUgdGhh biB0aGUKKyB3aGVuZXZlciB0aGUgZGVjb2RlciB3YW50cyB0aGUgb3V0cHV0IGF0IGEgZGlmZmVy ZW50IHNhbXBsZSByYXRlIHRoYW4gdGhlCiAgaW50ZXJuYWwgU0lMSyBzYW1wbGluZyByYXRlIChl LmcuLCB0byBhbGxvdyBhIGNvbnN0YW50IHNhbXBsZSByYXRlIHdoZW4gdGhlCiAgYXVkaW8gYmFu ZHdpZHRoIGNoYW5nZXMsIG9yIHRvIGFsbG93IG1peGluZyB3aXRoIGF1ZGlvIGZyb20gb3RoZXIK ICBhcHBsaWNhdGlvbnMpLgpAQCAtNTA5MSw3ICs1MDkxLDcgQEAgYW5kIHRoZSB3aG9sZSBiYWxh bmNlIGFyZSBhcHBsaWVkLCByZXNwZWN0aXZlbHkuCiAKIDx0PgogRGVjb2Rpbmcgb2YgUFZRIHZl Y3RvcnMgaXMgaW1wbGVtZW50ZWQgaW4gZGVjb2RlX3B1bHNlcygpIChjd3JzLmMpLgotVGhlIHVp cXVlIGNvZGV3b3JkIGluZGV4IGlzIGRlY29kZWQgYXMgYSB1bmlmb3JtbHktZGlzdHJpYnV0ZWQg aW50ZWdlciB2YWx1ZSBiZXR3ZWVuIDAgYW5kCitUaGUgdW5pcXVlIGNvZGV3b3JkIGluZGV4IGlz IGRlY29kZWQgYXMgYSB1bmlmb3JtbHktZGlzdHJpYnV0ZWQgaW50ZWdlciB2YWx1ZSBiZXR3ZWVu IDAgYW5kCiBWKE4sSyktMSwgd2hlcmUgVihOLEspIGlzIHRoZSBudW1iZXIgb2YgcG9zc2libGUg Y29tYmluYXRpb25zIG9mIEsgcHVsc2VzIGluIAogTiBzYW1wbGVzLiBUaGUgaW5kZXggaXMgdGhl biBjb252ZXJ0ZWQgdG8gYSB2ZWN0b3IgaW4gdGhlIHNhbWUgd2F5IHNwZWNpZmllZCBpbgogPHhy ZWYgdGFyZ2V0PSJQVlEiPjwveHJlZj4uIFRoZSBpbmRleGluZyBpcyBiYXNlZCBvbiB0aGUgY2Fs Y3VsYXRpb24gb2YgVihOLEspCkBAIC01MTEzLDE1ICs1MTEzLDE1IEBAIHRoZXkgYXJlIGVxdWl2 YWxlbnQgdG8gdGhlIG1hdGhlbWF0aWNhbCBkZWZpbml0aW9uLgogPC90PgogCiA8dD4KLVRoZSBk ZWNvZGVkIHZlY3RvciBpcyBub3JtYWxpc2VkIHN1Y2ggdGhhdCBpdHMKK1RoZSBkZWNvZGVkIHZl Y3RvciBpcyBub3JtYWxpemVkIHN1Y2ggdGhhdCBpdHMKIEwyLW5vcm0gZXF1YWxzIG9uZS4KIDwv dD4KIDwvc2VjdGlvbj4KIAogPHNlY3Rpb24gYW5jaG9yPSJzcHJlYWRpbmciIHRpdGxlPSJTcHJl YWRpbmciPgogPHQ+Ci1UaGUgbm9ybWFsaXNlZCB2ZWN0b3IgZGVjb2RlZCBpbiA8eHJlZiB0YXJn ZXQ9ImN3cnMtZGVjb2RlciIvPiBpcyB0aGVuIHJvdGF0ZWQKLWZvciB0aGUgcHVycG9zZSBvZiBh dm9pZGluZyB0b25hbCBhcnRlZmFjdHMuIFRoZSByb3RhdGlvbiBnYWluIGlzIGVxdWFsIHRvCitU aGUgbm9ybWFsaXplZCB2ZWN0b3IgZGVjb2RlZCBpbiA8eHJlZiB0YXJnZXQ9ImN3cnMtZGVjb2Rl ciIvPiBpcyB0aGVuIHJvdGF0ZWQKK2ZvciB0aGUgcHVycG9zZSBvZiBhdm9pZGluZyB0b25hbCBh cnRpZmFjdHMuIFRoZSByb3RhdGlvbiBnYWluIGlzIGVxdWFsIHRvCiA8ZmlndXJlIGFsaWduPSJj ZW50ZXIiPgogPGFydHdvcmsgYWxpZ249ImNlbnRlciI+PCFbQ0RBVEFbCiBnX3IgPSBOIC8gKE4g KyBmX3IqSykKQEAgLTYwMTMsNyArNjAxMyw3IEBAIGZsPXN1bShmKGkpLGk8ayksIGZoPWZsK2Yo aSksIGFuZCBmdD1zdW0oZihpKSkuCiA8dD4KIFRoZSBpbnB1dCBzaWduYWwncyBzYW1wbGluZyBy YXRlIGlzIGFkanVzdGVkIGJ5IGEgc2FtcGxlIHJhdGUgY29udmVyc2lvbgogbW9kdWxlIHNvIHRo YXQgaXQgbWF0Y2hlcyB0aGUgU0lMSyBpbnRlcm5hbCBzYW1wbGluZyByYXRlLiAgCi1UaGUgaW5w dXQgdG8gdGhlIHNhbXBsZSByYXRlIGNvbnZlcnRvciBpcyBkZWxheWVkIGJ5IGEgbnVtYmVyIG9m IHNhbXBsZXMKK1RoZSBpbnB1dCB0byB0aGUgc2FtcGxlIHJhdGUgY29udmVydGVyIGlzIGRlbGF5 ZWQgYnkgYSBudW1iZXIgb2Ygc2FtcGxlcwogZGVwZW5kaW5nIG9uIHRoZSBzYW1wbGUgcmF0ZSBy YXRpbywgc3VjaCB0aGF0IHRoZSBvdmVyYWxsIGRlbGF5IGlzIGNvbnN0YW50CiBmb3IgYWxsIGlu cHV0IGFuZCBvdXRwdXQgc2FtcGxlIHJhdGVzLgogPC90PgpAQCAtNjYwNSw3ICs2NjA1LDcgQEAg cXVhbnRpemF0aW9uIGVycm9ycyBhbmQgdGhlIGJpdHJhdGUuCiBUaGUgd2VpZ2h0cyBmb3IgdGhl IHF1YW50aXphdGlvbiBlcnJvcnMgYXJlIHRoZSBJbnZlcnNlCiBIYXJtb25pYyBNZWFuIFdlaWdo dGluZyAoSUhNVykgZnVuY3Rpb24gcHJvcG9zZWQgYnkgTGFyb2lhIGV0IGFsLgogKHNlZSA8eHJl ZiB0YXJnZXQ9Imxhcm9pYS1pY2Fzc3AiIC8+KS4gCi1UaGVzZSB3ZWlnaHRzIGFyZSByZWZlcmVk IHRvIGhlcmUgYXMgTGFyb2lhIHdlaWdodHMuCitUaGVzZSB3ZWlnaHRzIGFyZSByZWZlcnJlZCB0 byBoZXJlIGFzIExhcm9pYSB3ZWlnaHRzLgogPC90PgogPHQ+CiBUaGUgTFNGIHF1YW50aXplciBj b25zaXN0cyBvZiB0d28gc3RhZ2VzLgpAQCAtNjY1MCw3ICs2NjUwLDcgQEAgYmV0dGVyIGluIHRo ZSByZXZlcnNlIGRpcmVjdGlvbi4KIDx0PgogVGhlIHF1YW50aXphdGlvbiBpbmRleCBvZiB0aGUg Zmlyc3Qgc3RhZ2UgaXMgZW50cm9weSBjb2RlZC4KIFRoZSBxdWFudGl6YXRpb24gc2VxdWVuY2Ug ZnJvbSB0aGUgc2Vjb25kIHN0YWdlIGlzIGFsc28gZW50cm9weQotY29kZWQsIHdoZXJlIGZvciBl YWNoIGVsZW1udCB0aGUgcHJvYmFiaWxpdHkgdGFibGUgaXMgY2hvc2VuIAorY29kZWQsIHdoZXJl IGZvciBlYWNoIGVsZW1lbnQgdGhlIHByb2JhYmlsaXR5IHRhYmxlIGlzIGNob3NlbgogZGVwZW5k aW5nIG9uIHRoZSB2ZWN0b3IgaW5kZXggZnJvbSB0aGUgZmlyc3QgYW5kIHRoZSBsb2NhdGlvbiAK IG9mIHRoYXQgZWxlbWVudCBpbiB0aGUgTFNGIHZlY3Rvci4KIDwvdD4KQEAgLTY4MzQsNyArNjgz NCw3IEBAIEVuZXJneSBxdWFudGl6YXRpb24gKGJvdGggY29hcnNlIGFuZCBmaW5lKSBjYW4gYmUg ZWFzaWx5IHVuZGVyc3Rvb2QgZnJvbSB0aGUgZGVjCiBGb3IgYWxsIHVzZWZ1bCBiaXRyYXRlcywg dGhlIGNvYXJzZSBxdWFudGl6ZXIgYWx3YXlzIGNob29zZXMgdGhlIHF1YW50aXplZCBsb2cgZW5l cmd5IHZhbHVlIHRoYXQgCiBtaW5pbWl6ZXMgdGhlIGVycm9yIGZvciBlYWNoIGJhbmQuIE9ubHkg YXQgdmVyeSBsb3cgcmF0ZSBkb2VzIHRoZSBlbmNvZGVyIGFsbG93IGxhcmdlciBlcnJvcnMgdG8K IG1pbmltaXplIHRoZSByYXRlIGFuZCBhdm9pZCB1c2luZyBtb3JlIGJpdHMgdGhhbiBhcmUgYXZh aWxhYmxlLiBXaGVuIHRoZQotYXZhaWFsYmxlIENQVSByZXF1aXJlbWVudHMgYWxsb3cgaXQsIGl0 IGlzIGJlc3QgdG8gdHJ5IGVuY29kaW5nIHRoZSBjb2Fyc2UgZW5lcmd5IGJvdGggd2l0aCBhbmQg d2l0aG91dAorYXZhaWxhYmxlIENQVSByZXF1aXJlbWVudHMgYWxsb3cgaXQsIGl0IGlzIGJlc3Qg dG8gdHJ5IGVuY29kaW5nIHRoZSBjb2Fyc2UgZW5lcmd5IGJvdGggd2l0aCBhbmQgd2l0aG91dAog aW50ZXItZnJhbWUgcHJlZGljdGlvbiBzdWNoIHRoYXQgdGhlIGJlc3QgcHJlZGljdGlvbiBtb2Rl IGNhbiBiZSBzZWxlY3RlZC4gVGhlIG9wdGltYWwgbW9kZSBkZXBlbmRzIG9uCiB0aGUgY29kaW5n IHJhdGUsIHRoZSBhdmFpbGFibGUgYml0LXJhdGUsIGFuZCB0aGUgY3VycmVudCByYXRlIG9mIHBh Y2tldCBsb3NzLiAKIDwvdD4KQEAgLTcwMzUsNyArNzAzNSw3IEBAIENvbXBsaWFuY2Ugd2l0aCB0 aGlzIHNwZWNpZmljYXRpb24gbWVhbnMgdGhhdCBhIGRlY29kZXIncyBvdXRwdXQgTVVTVCBiZQog IHdpdGggdGhlIGNvZGUpIHdoZW4gY29tcGFyZWQgdG8gdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbiBmb3IgZWFjaCBvZiB0aGUgCiAgdGVzdCB2ZWN0b3JzIHByb3ZpZGVkIChzZWUgPHhyZWYg dGFyZ2V0PSJ0ZXN0LXZlY3RvcnMiPjwveHJlZj4pLiBFaXRoZXIgdGhlIGZsb2F0aW5nLXBvaW50 CiAgaW1wbGVtZW50YXRpb24gb3IgdGhlIGZpeGVkLXBvaW50IGltcGxlbWVudGF0aW9uIGNhbiBi ZSB1c2VkIGFzIGEgcmVmZXJlbmNlIGFuZCBiZWluZwotIHdpdGhpbiB0aGUgdGhyZXNob2xkIGZv ciBvbmUgb2YgdGhlIHR3byBpcyBzdWZmaWNpZW50LiBJbiBhZGRpdGlvbiwgYSBjb21waWxhbnQK KyB3aXRoaW4gdGhlIHRocmVzaG9sZCBmb3Igb25lIG9mIHRoZSB0d28gaXMgc3VmZmljaWVudC4g SW4gYWRkaXRpb24sIGEgY29tcGxpYW50CiAgZGVjb2RlciBpbXBsZW1lbnRhdGlvbiBNVVNUIGhh dmUgdGhlIHNhbWUgZmluYWwgcmFuZ2UgZGVjb2RlciBzdGF0ZSBhcyB0aGF0IG9mIHRoZQogIHJl ZmVyZW5jZSBkZWNvZGVyLiAKIDwvdD4KQEAgLTczNjksNyArNzM2OSw3IEBAIGZvciB0d28ncyBj b21wbGVtZW50IGFyY2hpdGVjdHVyZXM6CiA8dD5SaWdodCBzaGlmdHMgb2YgbmVnYXRpdmUgdmFs dWVzIGFyZSBjb25zaXN0ZW50IHdpdGggdHdvJ3MgY29tcGxlbWVudCBhcml0aG1ldGljLCBzbyB0 aGF0IGE+PmIgaXMgZXF1aXZhbGVudCB0byBmbG9vcihhLygyXmIpKTwvdD4KIDx0PkZvciBjb252 ZXJzaW9uIHRvIGEgc2lnbmVkIGludGVnZXIgb2YgTiBiaXRzLCB0aGUgdmFsdWUgaXMgcmVkdWNl ZCBtb2R1bG8gMl5OIHRvIGJlIHdpdGhpbiByYW5nZSBvZiB0aGUgdHlwZTwvdD4KIDx0PlRoZSBy ZXN1bHQgb2YgaW50ZWdlciBkaXZpc2lvbiBvZiBhIG5lZ2F0aXZlIHZhbHVlcyBpcyB0cnVuY2F0 ZWQgdG93YXJkcyB6ZXJvPC90PgotPHQ+VGhlIGNvbXBpbGVyIHByb3ZpZGVzIGEgNjQtYml0IGlu dGVnZXIgdHlwZSAoYSBDOTkgcmVxdWlyZW1lbnQgd2hpY2ggaXMgc3VwcG9ydGVkIGJ5IG1vc3Qg Yzg5IGNvbXBpbGVycyk8L3Q+Cis8dD5UaGUgY29tcGlsZXIgcHJvdmlkZXMgYSA2NC1iaXQgaW50 ZWdlciB0eXBlIChhIEM5OSByZXF1aXJlbWVudCB3aGljaCBpcyBzdXBwb3J0ZWQgYnkgbW9zdCBD ODkgY29tcGlsZXJzKTwvdD4KIDwvbGlzdD4KIDwvdD4KIAotLSAKMS43LjYuNAoK --bcaec5014dc142eaa604b20960ad-- From prvs=296376356=tterribe@xiph.org Fri Nov 18 14:12:47 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36921F8500 for ; Fri, 18 Nov 2011 14:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAV4nz9XbIWb for ; Fri, 18 Nov 2011 14:12:46 -0800 (PST) Received: from mxip2i.isis.unc.edu (mxip2i.isis.unc.edu [152.2.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8121F84FB for ; Fri, 18 Nov 2011 14:12:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAK/Xxk6sGgRa/2dsb2JhbABDhQGkO4IBgXIBAQQBIxVAAQULCxoCBRYLAgIJAwIBAgFFEwEHAod/pHmRf4Ewh1GBFgSIF4NbiEeFKRSMZQ X-IronPort-AV: E=Sophos;i="4.69,534,1315195200"; d="scan'208";a="228817891" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip2o.isis.unc.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2011 17:12:44 -0500 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 60.248.154.172 Received: from [192.168.1.153] (60-248-154-172.HINET-IP.hinet.net [60.248.154.172]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id pAIMCeCa013571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2011 17:12:43 -0500 (EST) Message-ID: <4EC6D857.2080706@xiph.org> Date: Fri, 18 Nov 2011 14:12:39 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: codec@ietf.org References: <4EAF4419.3000502@jdrosen.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:12:47 -0000 > Please find attached a patch fixes some editorial issues with opus-10 draft. Thanks. I'd already corrected a couple of those locally, but I'll make sure the rest get applied. From stewe@stewe.org Fri Nov 18 14:17:38 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10B21F8876 for ; Fri, 18 Nov 2011 14:17:38 -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.699, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE3UP3QVNyDu for ; Fri, 18 Nov 2011 14:17:38 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8331621F886A for ; Fri, 18 Nov 2011 14:17:37 -0800 (PST) Received: from [172.20.2.107] (unverified [203.69.99.17]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1574-1743317 for multiple; Fri, 18 Nov 2011 23:17:35 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 19 Nov 2011 06:16:46 +0800 From: Stephan Wenger To: John Ridges , Message-ID: Thread-Topic: [codec] Conformance with unusual sample rates In-Reply-To: <4EC66BAE.9000600@masque.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 203.69.99.17 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:17:38 -0000 Hi, Whether a conforming opus implementation is indeed "unencumbered" is not for us to decide. The one thing conformance should buy you is that you can rely on the assurances provided in the IPR declarations against opus. Arguably, even ALL of those create encumbrances, for example restriction in your use of your own patents due to reciprocity conditions and whatnot. Stephan On 11.18.2011 22:29 , "John Ridges" wrote: >Hi, > >Since the codec conformance is a hot topic right now, I thought I would >ask a (probably dumb) question. Is it possible to create a conforming >(and thus unencumbered) Opus codec from the reference implementation >that can use a sample rate of, say, 44100 Hz? If so, what are the rules >that would guarantee conformance? Thanks, > >John Ridges > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jridges@masque.com Fri Nov 18 14:26:14 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231FB11E80AF for ; Fri, 18 Nov 2011 14:26:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPsww2QK0+gU for ; Fri, 18 Nov 2011 14:26:13 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id 392BB11E80AD for ; Fri, 18 Nov 2011 14:26:13 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id 49C821602A6; Fri, 18 Nov 2011 15:26:12 -0700 (MST) Message-ID: <4EC6DB82.4020100@masque.com> Date: Fri, 18 Nov 2011 15:26:10 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:26:14 -0000 I agree that it was a poor choice of words on my part. What I really wanted to know was whether I could use Opus in a particular way without violating the terms of the IPR declarations, and that question has been answered to my satisfaction. John Ridges On 11/18/2011 3:16 PM, Stephan Wenger wrote: > Hi, > Whether a conforming opus implementation is indeed "unencumbered" is not > for us to decide. The one thing conformance should buy you is that you > can rely on the assurances provided in the IPR declarations against opus. > Arguably, even ALL of those create encumbrances, for example restriction > in your use of your own patents due to reciprocity conditions and whatnot. > Stephan > > On 11.18.2011 22:29 , "John Ridges" wrote: > >> Hi, >> >> Since the codec conformance is a hot topic right now, I thought I would >> ask a (probably dumb) question. Is it possible to create a conforming >> (and thus unencumbered) Opus codec from the reference implementation >> that can use a sample rate of, say, 44100 Hz? If so, what are the rules >> that would guarantee conformance? Thanks, >> >> John Ridges >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > From stewe@stewe.org Fri Nov 18 14:27:33 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FF11E80B3 for ; Fri, 18 Nov 2011 14:27:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urFsN34VycGL for ; Fri, 18 Nov 2011 14:27:32 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCF811E80AD for ; Fri, 18 Nov 2011 14:27:31 -0800 (PST) Received: from [172.20.2.107] (unverified [203.69.99.17]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1579-1743317 for multiple; Fri, 18 Nov 2011 23:27:30 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 19 Nov 2011 06:26:14 +0800 From: Stephan Wenger To: John Ridges , Message-ID: Thread-Topic: [codec] Conformance with unusual sample rates In-Reply-To: <4EC685E1.3070000@masque.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 203.69.99.17 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:27:33 -0000 Uh. Scary discussion. I believe we may well be unchartered territory here. Remember the "green light / red light" discussion we had here in Taipei? I'm fairly certain that both 16 ms frames and 44.1 kHz sample rate would fail the colored lights test, with the text vectors considered today, even if we were defining conformance very loosely. In such a case, I don't think that you can necessarily rely with any certainty on the IPR declarations provided. Stephan On 11.19.2011 00:20 , "John Ridges" wrote: >Thank-you for clarifying that. I also have another application where I >need to use 16 ms frames and it looks like Opus-custom would allow me to >do that. > >John Ridges > >On 11/18/2011 8:56 AM, Benjamin M. Schwartz wrote: >> On 11/18/2011 09:29 AM, John Ridges wrote: >>> Is it possible to create a conforming (and >>> thus unencumbered) Opus codec from the reference implementation that >>>can >>> use a sample rate of, say, 44100 Hz? >> It depends what you mean. >> >> One answer is "no". Opus always operates at a fixed nominal samplerate >>of >> 48000 Hz. >> >> Another answer is "yes", because you are of course always free to >>resample >> your inputs before encoding, and to resample the outputs after decoding. >> If you figure out a way to use less CPU by integrating your resampler >>into >> the decoder then that's just a trivial implementation detail. >> >> Another answer is "yes, in Opus-custom". Opus-custom is a >> non-interoperable Opus-derived codec development system, defined as part >> of the Opus standard [1]. Opus-custom can be driven at different >> samplerates, including 44100 Hz. >> >> --Ben >> >> P.S. I do agree that clarifying our text on this point might be helpful. >> >> [1] http://tools.ietf.org/html/draft-ietf-codec-opus-10#section-6.2 >> > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jridges@masque.com Fri Nov 18 14:45:00 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1D221F8B1E for ; Fri, 18 Nov 2011 14:45:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Uik0rMTgyQp for ; Fri, 18 Nov 2011 14:45:00 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0939B21F8B16 for ; Fri, 18 Nov 2011 14:45:00 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id 207011602A6; Fri, 18 Nov 2011 15:44:57 -0700 (MST) Message-ID: <4EC6DFE6.3080006@masque.com> Date: Fri, 18 Nov 2011 15:44:54 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:45:01 -0000 Well, I'm not a lawyer, but it doesn't seem right that a standard should invite you to use the reference implementation in a way that would violate its own IPR declarations. It makes me wonder if there are ways of inadvertently misusing the codec's API that would do so as well. John Ridges On 11/18/2011 3:26 PM, Stephan Wenger wrote: > Uh. Scary discussion. > I believe we may well be unchartered territory here. Remember the "green > light / red light" discussion we had here in Taipei? I'm fairly certain > that both 16 ms frames and 44.1 kHz sample rate would fail the colored > lights test, with the text vectors considered today, even if we were > defining conformance very loosely. In such a case, I don't think that you > can necessarily rely with any certainty on the IPR declarations provided. > Stephan > > On 11.19.2011 00:20 , "John Ridges" wrote: > >> Thank-you for clarifying that. I also have another application where I >> need to use 16 ms frames and it looks like Opus-custom would allow me to >> do that. >> >> John Ridges >> >> On 11/18/2011 8:56 AM, Benjamin M. Schwartz wrote: >>> On 11/18/2011 09:29 AM, John Ridges wrote: >>>> Is it possible to create a conforming (and >>>> thus unencumbered) Opus codec from the reference implementation that >>>> can >>>> use a sample rate of, say, 44100 Hz? >>> It depends what you mean. >>> >>> One answer is "no". Opus always operates at a fixed nominal samplerate >>> of >>> 48000 Hz. >>> >>> Another answer is "yes", because you are of course always free to >>> resample >>> your inputs before encoding, and to resample the outputs after decoding. >>> If you figure out a way to use less CPU by integrating your resampler >>> into >>> the decoder then that's just a trivial implementation detail. >>> >>> Another answer is "yes, in Opus-custom". Opus-custom is a >>> non-interoperable Opus-derived codec development system, defined as part >>> of the Opus standard [1]. Opus-custom can be driven at different >>> samplerates, including 44100 Hz. >>> >>> --Ben >>> >>> P.S. I do agree that clarifying our text on this point might be helpful. >>> >>> [1] http://tools.ietf.org/html/draft-ietf-codec-opus-10#section-6.2 >>> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > From gmaxwell@juniper.net Fri Nov 18 14:45:32 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF06811E8091 for ; Fri, 18 Nov 2011 14:45:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP5tPFrIuYU5 for ; Fri, 18 Nov 2011 14:45:32 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id CF81721F8B1E for ; Fri, 18 Nov 2011 14:45:31 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbgBj7YK95I9Qubc3TdEjTOWSmZQSna@postini.com; Fri, 18 Nov 2011 14:45:31 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; Fri, 18 Nov 2011 14:41:27 -0800 From: Gregory Maxwell To: Stephan Wenger , John Ridges , "bens@alum.mit.edu" Date: Fri, 18 Nov 2011 14:41:26 -0800 Thread-Topic: [codec] Conformance with unusual sample rates Thread-Index: AcymQUXhblDxfzGuT0+tx/oU/KOnGgAAII0a Message-ID: References: <4EC685E1.3070000@masque.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:45:33 -0000 Stephan Wenger [stewe@stewe.org]: > Uh. Scary discussion. > I believe we may well be unchartered territory here. Remember the "green > light / red light" discussion we had here in Taipei? I'm fairly certain > that both 16 ms frames and 44.1 kHz sample rate would fail the colored > lights test, with the text vectors considered today, even if we were > defining conformance very loosely. In such a case, I don't think that yo= u >can necessarily rely with any certainty on the IPR declarations provided. The conformance requirement is that the implementation can correctly decode the test vectors as stated It doesn't require the codec to correctly decode every conceivable sequence of bits. The discussion here is not related to modified or incompatible versions of = Opus,=20 but about things specifically described in the draft. Perhaps you'd like to reconsider your statement? From ron@debian.org Fri Nov 18 15:08:05 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20521F84A1 for ; Fri, 18 Nov 2011 15:08: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3f+f9AjpPzr for ; Fri, 18 Nov 2011 15:08:04 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 641F921F849E for ; Fri, 18 Nov 2011 15:08:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF7kxk520hTR/2dsb2JhbAA9Bqo3gQaBcgEBBTocMwsYLhQYDb8ihm4UgxUEjRSHJAGSFA Received: from ppp118-210-20-209.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.20.209]) by ipmail07.adl2.internode.on.net with ESMTP; 19 Nov 2011 09:38:01 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C7BDB4F8F3 for ; Sat, 19 Nov 2011 09:37:59 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PpMcGWlMerTv for ; Sat, 19 Nov 2011 09:37:59 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id F1F944F8FE; Sat, 19 Nov 2011 09:37:58 +1030 (CST) Date: Sat, 19 Nov 2011 09:37:58 +1030 From: Ron To: codec@ietf.org Message-ID: <20111118230758.GM4041@audi.shelbyville.oz> References: <4EC66BAE.9000600@masque.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 23:08:05 -0000 On Sat, Nov 19, 2011 at 06:16:46AM +0800, Stephan Wenger wrote: > Hi, > Whether a conforming opus implementation is indeed "unencumbered" is not > for us to decide. The one thing conformance should buy you is that you > can rely on the assurances provided in the IPR declarations against opus. > Arguably, even ALL of those create encumbrances, for example restriction > in your use of your own patents due to reciprocity conditions and whatnot. > Stephan Unarguably, that only affects the tiny minority of players who might be planning on using their own patents for whatnot though. So arguably, that might be called a Freedom. 99.9% reciprocally, Ron From gmaxwell@juniper.net Fri Nov 18 15:09:36 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEDF21F8509 for ; Fri, 18 Nov 2011 15:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTsfSlaf1tGE for ; Fri, 18 Nov 2011 15:09:35 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E921F8500 for ; Fri, 18 Nov 2011 15:09:35 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsblrRtRwxGPFBqWMZBbPPCGZxwt0z3L@postini.com; Fri, 18 Nov 2011 15:09:35 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; Fri, 18 Nov 2011 15:06:42 -0800 From: Gregory Maxwell To: John Ridges Date: Fri, 18 Nov 2011 15:06:41 -0800 Thread-Topic: [codec] Conformance with unusual sample rates Thread-Index: AcymQ7bdyInuyNLTQyKESvYnS3g3cgAAA2Ra Message-ID: References: ,<4EC6DFE6.3080006@masque.com> In-Reply-To: <4EC6DFE6.3080006@masque.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bens@alum.mit.edu" , "codec@ietf.org" Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 23:09:36 -0000 John Ridges [jridges@masque.com]: > Well, I'm not a lawyer, but it doesn't seem right that a standard should > invite you to use the reference implementation in a way that would >violate its own IPR declarations. It makes me wonder if there are ways > of inadvertently misusing the codec's API that would do so as well. Obviously. This is the purpose of language like: [warning generic language from an IPR statement is contained in the paragraph below] "Specification means, [...] (b) any reference implementation (each, a =93Reference Implementation=94) published by the IETF Codec Working Group in the request for comments [...] . Licensed patents [...] in the case of (b) above, use of the reference implementation to the extent it infringes such patent" My expectation is that the red light / green-light stuff is moot if you ar= e using an IETF published reference implementation as is. This is the reasonable and expected thing, and to the best of my knowledge it was the intention of the parties that contributed to the process. Other things are permitted as well, subject to the conformance requirements, but if you want to be extra paranoid, and want to take the easy way out, using the reference itself will cover you. If you've found some reason to believe otherwise, please contact me and I'll either point you to whatever you're missing or fuss at people to get it fixed. (This is a generic invitation, open to any and all comers= ,=20 if there is too much interest I'll write a FAQ outside of the working group or something=85) From jridges@masque.com Fri Nov 18 15:31:44 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F31F0C45 for ; Fri, 18 Nov 2011 15:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5raCkXBMGgN for ; Fri, 18 Nov 2011 15:31:43 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id CB4701F0C40 for ; Fri, 18 Nov 2011 15:31:43 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id D7EC71602A6; Fri, 18 Nov 2011 16:31:42 -0700 (MST) Message-ID: <4EC6EADC.1070102@masque.com> Date: Fri, 18 Nov 2011 16:31:40 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Gregory Maxwell References: , <4EC6DFE6.3080006@masque.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "bens@alum.mit.edu" , "codec@ietf.org" Subject: Re: [codec] Conformance with unusual sample rates X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 23:31:44 -0000 Mr. Maxwell, I apologize for spreading any FUD. Your statement is what I had expected (and hoped for). I was thrown a bit by Mr. Wenger's concerns. For my part, I consider this matter closed. John Ridges On 11/18/2011 4:06 PM, Gregory Maxwell wrote: > John Ridges [jridges@masque.com]: >> Well, I'm not a lawyer, but it doesn't seem right that a standard should >> invite you to use the reference implementation in a way that would >> violate its own IPR declarations. It makes me wonder if there are ways >> of inadvertently misusing the codec's API that would do so as well. > Obviously. > > This is the purpose of language like: [warning generic language from an IPR > statement is contained in the paragraph below] > > "Specification means, [...] > (b) any reference implementation (each, a “Reference Implementation”) > published by the IETF Codec Working Group in the request for comments > [...] . Licensed patents [...] in the case of (b) above, use of the > reference implementation to the extent it infringes such patent" > > My expectation is that the red light / green-light stuff is moot if you are > using an IETF published reference implementation as is. This is the > reasonable and expected thing, and to the best of my knowledge it was > the intention of the parties that contributed to the process. > > Other things are permitted as well, subject to the conformance > requirements, but if you want to be extra paranoid, and want to take > the easy way out, using the reference itself will cover you. > > If you've found some reason to believe otherwise, please contact me > and I'll either point you to whatever you're missing or fuss at people > to get it fixed. (This is a generic invitation, open to any and all comers, > if there is too much interest I'll write a FAQ outside of the working > group or something…) > > > From giles@thaumas.net Fri Nov 18 16:17:32 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A931E11E809D for ; Fri, 18 Nov 2011 16:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QinnbzrwBEZR for ; Fri, 18 Nov 2011 16:17:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2192611E8086 for ; Fri, 18 Nov 2011 16:17:32 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so822428vbb.31 for ; Fri, 18 Nov 2011 16:17:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.179.38 with SMTP id dd6mr5558211vdc.126.1321661851511; Fri, 18 Nov 2011 16:17:31 -0800 (PST) Received: by 10.220.205.196 with HTTP; Fri, 18 Nov 2011 16:17:31 -0800 (PST) X-Originating-IP: [184.71.166.126] In-Reply-To: References: <4EAF4419.3000502@jdrosen.net> Date: Fri, 18 Nov 2011 16:17:31 -0800 Message-ID: From: Ralph Giles To: Jean-Marc Valin Content-Type: multipart/mixed; boundary=bcaec51a78422c2d3c04b20b6151 Cc: codec@ietf.org Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 00:17:32 -0000 --bcaec51a78422c2d3c04b20b6151 Content-Type: text/plain; charset=UTF-8 Here are two more small patches, fixing issues with the API documentation in the implementation headers. -r --bcaec51a78422c2d3c04b20b6151 Content-Type: application/octet-stream; name="0002-Fix-a-typo-in-the-header-documentation.patch" Content-Disposition: attachment; filename="0002-Fix-a-typo-in-the-header-documentation.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv5vbkom1 RnJvbSA1MjEwNzZmY2Q1Mjg2MzMzNzhhNWRiZDhlMzA0M2RmOTI5MTY4NGZhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSYWxwaCBHaWxlcyA8Z2lsZXNAbW96aWxsYS5jb20+CkRhdGU6 IEZyaSwgMTggTm92IDIwMTEgMTU6NTY6NDMgLTA4MDAKU3ViamVjdDogW1BBVENIIDIvM10gRml4 IGEgdHlwbyBpbiB0aGUgaGVhZGVyIGRvY3VtZW50YXRpb24uCgotLS0KIGluY2x1ZGUvb3B1cy5o IHwgICAgMiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25z KC0pCgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9vcHVzLmggYi9pbmNsdWRlL29wdXMuaAppbmRleCBj NTUyZmMyLi43MzMwNWJiIDEwMDY0NAotLS0gYS9pbmNsdWRlL29wdXMuaAorKysgYi9pbmNsdWRl L29wdXMuaApAQCAtNDU1LDcgKzQ1NSw3IEBAIE9QVVNfRVhQT1JUIGludCBvcHVzX3BhY2tldF9n ZXRfc2FtcGxlc19wZXJfZnJhbWUoY29uc3QgdW5zaWduZWQgY2hhciAqZGF0YSwgb3B1CiAgICov CiBPUFVTX0VYUE9SVCBpbnQgb3B1c19wYWNrZXRfZ2V0X25iX2NoYW5uZWxzKGNvbnN0IHVuc2ln bmVkIGNoYXIgKmRhdGEpOwogCi0vKiogR2V0cyB0aGUgbnVtYmVyIG9mIGZyYW1lIGluIGFuIE9w dXMgcGFja2V0LgorLyoqIEdldHMgdGhlIG51bWJlciBvZiBmcmFtZXMgaW4gYW4gT3B1cyBwYWNr ZXQuCiAgICogQHBhcmFtIFtpbl0gcGFja2V0IDx0dD5jaGFyKjwvdHQ+OiBPcHVzIHBhY2tldAog ICAqIEBwYXJhbSBbaW5dIGxlbiA8dHQ+aW50PC90dD46IExlbmd0aCBvZiBwYWNrZXQKICAgKiBA cmV0dXJucyBOdW1iZXIgb2YgZnJhbWVzCi0tIAoxLjcuNi40Cgo= --bcaec51a78422c2d3c04b20b6151 Content-Type: application/octet-stream; name="0003-Correct-a-broken-link-in-the-header-documentation.patch" Content-Disposition: attachment; filename="0003-Correct-a-broken-link-in-the-header-documentation.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv5vc7vn2 RnJvbSAxN2MzM2YwNGZhMDFiMWYyMWJiY2FlMzMyN2U1ZDFlODBhY2MxMzQ3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSYWxwaCBHaWxlcyA8Z2lsZXNAbW96aWxsYS5jb20+CkRhdGU6 IEZyaSwgMTggTm92IDIwMTEgMTU6NTc6MzMgLTA4MDAKU3ViamVjdDogW1BBVENIIDMvM10gQ29y cmVjdCBhIGJyb2tlbiBsaW5rIGluIHRoZSBoZWFkZXIgZG9jdW1lbnRhdGlvbi4KCi0tLQogaW5j bHVkZS9vcHVzLmggfCAgICAyICstCiAxIGZpbGVzIGNoYW5nZWQsIDEgaW5zZXJ0aW9ucygrKSwg MSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9pbmNsdWRlL29wdXMuaCBiL2luY2x1ZGUvb3B1 cy5oCmluZGV4IDczMzA1YmIuLjIxYzUwOGEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvb3B1cy5oCisr KyBiL2luY2x1ZGUvb3B1cy5oCkBAIC0zOTgsNyArMzk4LDcgQEAgT1BVU19FWFBPUlQgaW50IG9w dXNfZGVjb2RlX2Zsb2F0KAogKTsKIAogLyoqIFBlcmZvcm0gYSBDVEwgZnVuY3Rpb24gb24gYW4g T3B1cyBkZWNvZGVyLgotICAqIEBzZWUgZGVjb2RlcmN0bHMKKyAgKiBAc2VlIGdlbmVyaWNjdGxz CiAgICovCiBPUFVTX0VYUE9SVCBpbnQgb3B1c19kZWNvZGVyX2N0bChPcHVzRGVjb2RlciAqc3Qs IGludCByZXF1ZXN0LCAuLi4pOwogCi0tIAoxLjcuNi40Cgo= --bcaec51a78422c2d3c04b20b6151-- From ietf@meetecho.com Mon Nov 21 06:34:50 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8691F0C36 for ; Mon, 21 Nov 2011 06:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.807 X-Spam-Level: X-Spam-Status: No, score=0.807 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL5okAqnKdKf for ; Mon, 21 Nov 2011 06:34:46 -0800 (PST) Received: from smtplq03.aruba.it (smtplq-out18.aruba.it [62.149.158.38]) by ietfa.amsl.com (Postfix) with SMTP id A01C81F0C48 for ; Mon, 21 Nov 2011 06:34:45 -0800 (PST) Received: (qmail 18826 invoked by uid 89); 21 Nov 2011 14:34:44 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq03.aruba.it with SMTP; 21 Nov 2011 14:34:44 -0000 Received: (qmail 11711 invoked by uid 89); 21 Nov 2011 14:34:44 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp5.ad.aruba.it with SMTP; 21 Nov 2011 14:34:44 -0000 Message-ID: <4ECA6176.1050809@meetecho.com> Date: Mon, 21 Nov 2011 15:34:30 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [codec] CODEC session recording available X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:34:50 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of CODEC session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings#CODEC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From neerlent@gmail.com Sat Nov 19 14:12:16 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A521F86B3 for ; Sat, 19 Nov 2011 14:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh953AVox2dy for ; Sat, 19 Nov 2011 14:12:16 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0621F8672 for ; Sat, 19 Nov 2011 14:12:12 -0800 (PST) Received: by eyg24 with SMTP id 24so5207746eyg.31 for ; Sat, 19 Nov 2011 14:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=gMyzjQG5JCZJvRPa5d//XDrMaTiiM1vdpPZMgIgEXpg=; b=Elde4jJRWfiCjSTL40Yy00XimIB7VEgAKgvaVkdKK2uQNsCC0ZC3rC5X2BIb70+goF M35DuAS2+u/5blA/0z4Ov+ZuAeCd7eLQGp7oN8ENBPJNDHTzj8gC6dtE4bUSVSWoxCEs Hml1woneoejrP529AYCSahhjtdMamGGtraMTk= MIME-Version: 1.0 Received: by 10.14.9.21 with SMTP id 21mr629751ees.181.1321740730098; Sat, 19 Nov 2011 14:12:10 -0800 (PST) Received: by 10.14.97.138 with HTTP; Sat, 19 Nov 2011 14:12:10 -0800 (PST) Date: Sat, 19 Nov 2011 14:12:10 -0800 Message-ID: From: neerlent@gmail.com To: codec@ietf.org Content-Type: multipart/mixed; boundary=0016364c7b65b3e44a04b21dbec5 X-Mailman-Approved-At: Mon, 21 Nov 2011 08:10:26 -0800 Subject: [codec] Opus codec on Analog Devices SHARC DSPs - patch needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 22:22:53 -0000 --0016364c7b65b3e44a04b21dbec5 Content-Type: multipart/alternative; boundary=0016364c7b65b3e44304b21dbec3 --0016364c7b65b3e44304b21dbec3 Content-Type: text/plain; charset=ISO-8859-1 Hello, I am currently considering the use of the Opus codec for an audio streaming application that would run on an Analog Devices SHARC DSP. Since it is a 32-bit floating-point DSP, I assumed it would be relatively easy to get the Opus floating-point code building for the SHARC. I am only interested in the CELT mode of operation, so I created a project that included opus_custom_demo.c and all necessary files for the demo to build. I found one issue that prevents the CELT code from building for the SHARC DSP. The file bands.c contains a variable named "bank", which is used in several places in the file. The SHARC C compiler treats "bank" as a reserved keyword for specifying what memory block a piece of data should go in. I've attached a patch that renames variables named "bank" to "band" in both bands.c and bands.h. Let me know if you will consider making this change. Thanks, Matt Kotvis --0016364c7b65b3e44304b21dbec3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I am currently considering the use of the Opus codec for=20 an audio streaming application that would run on an Analog Devices SHARC DSP.=A0 Since it is a 32-bit floating-point DSP, I assumed it would be=20 relatively easy to get the Opus floating-point code building for the=20 SHARC.=A0 I am only interested in the CELT mode of operation, so I created a project that included opus_custom_demo.c and all necessary files for=20 the demo to build.

I found one issue that prevents the CELT code from building for the=20 SHARC DSP.=A0 The file bands.c contains a variable named "bank", = which is=20 used in several places in the file.=A0 The SHARC C compiler treats "ba= nk"=20 as a reserved keyword for specifying what memory block a piece of data=20 should go in.=A0

I've attached a patch that renames variables n= amed "bank" to "band" in both bands.c and bands.h.=A0 L= et me know if you will consider making this change.

Thanks,

Matt Kotvis --0016364c7b65b3e44304b21dbec3-- --0016364c7b65b3e44a04b21dbec5 Content-Type: application/octet-stream; name="rename_bank_to_band.patch" Content-Disposition: attachment; filename="rename_bank_to_band.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv75s8x90 RnJvbSBjY2Y3NzlkMWZjMWM4NmIyYzg4MDBmMjJiYzg2NzExNWJkYjU2MDhlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0IEtvdHZpcyA8bmVlcmxlbnRAZ21haWwuY29tPgpEYXRl OiBGcmksIDE4IE5vdiAyMDExIDIxOjExOjUzIC0wODAwClN1YmplY3Q6IFtQQVRDSF0gY2hhbmdl IHZhcmlhYmxlcyBuYW1lZCAiYmFuayIgdG8gImJhbmQiIHNpbmNlIEFuYWxvZyBEZXZpY2VzCiBT SEFSQyBDIGNvbXBpbGVyIHRyZWF0cyAiYmFuayIgYXMgYSBrZXl3b3JkCgotLS0KIGNlbHQvYmFu ZHMuYyB8ICAgMzYgKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tCiBjZWx0L2Jh bmRzLmggfCAgICAyICstCiAyIGZpbGVzIGNoYW5nZWQsIDE5IGluc2VydGlvbnMoKyksIDE5IGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2NlbHQvYmFuZHMuYyBiL2NlbHQvYmFuZHMuYwppbmRl eCA2NjY4NjNmLi5mY2QxMTgzIDEwMDY0NAotLS0gYS9jZWx0L2JhbmRzLmMKKysrIGIvY2VsdC9i YW5kcy5jCkBAIC03NSw3ICs3NSw3IEBAIHN0YXRpYyBpbnQgYml0ZXhhY3RfbG9nMnRhbihpbnQg aXNpbixpbnQgaWNvcykKIAogI2lmZGVmIEZJWEVEX1BPSU5UCiAvKiBDb21wdXRlIHRoZSBhbXBs aXR1ZGUgKHNxcnQgZW5lcmd5KSBpbiBlYWNoIG9mIHRoZSBiYW5kcyAqLwotdm9pZCBjb21wdXRl X2JhbmRfZW5lcmdpZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0 X2VuZXIgKmJhbmssIGludCBlbmQsIGludCBfQywgaW50IE0pCit2b2lkIGNvbXB1dGVfYmFuZF9l bmVyZ2llcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNlbHRfZW5lciAq YmFuZCwgaW50IGVuZCwgaW50IF9DLCBpbnQgTSkKIHsKICAgIGludCBpLCBjLCBOOwogICAgY29u c3Qgb3B1c19pbnQxNiAqZUJhbmRzID0gbS0+ZUJhbmRzOwpAQCAtMTAyLDE4ICsxMDIsMTggQEAg dm9pZCBjb21wdXRlX2JhbmRfZW5lcmdpZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRf c2lnICpYLCBjZWx0X2VuZXIgKmJhbmsKICAgICAgICAgICAgIH0gd2hpbGUgKCsrajxNKmVCYW5k c1tpKzFdKTsKICAgICAgICAgICAgIC8qIFdlJ3JlIGFkZGluZyBvbmUgaGVyZSB0byBtYWtlIGRh bW4gc3VyZSB3ZSBuZXZlciBlbmQgdXAgd2l0aCBhIHBpdGNoIHZlY3RvciB0aGF0J3MKICAgICAg ICAgICAgICAgIGxhcmdlciB0aGFuIHVuaXR5IG5vcm0gKi8KLSAgICAgICAgICAgIGJhbmtbaStj Km0tPm5iRUJhbmRzXSA9IEVQU0lMT04rVlNIUjMyKEVYVEVORDMyKGNlbHRfc3FydChzdW0pKSwt c2hpZnQpOworICAgICAgICAgICAgYmFuZFtpK2MqbS0+bmJFQmFuZHNdID0gRVBTSUxPTitWU0hS MzIoRVhURU5EMzIoY2VsdF9zcXJ0KHN1bSkpLC1zaGlmdCk7CiAgICAgICAgICB9IGVsc2Ugewot ICAgICAgICAgICAgYmFua1tpK2MqbS0+bmJFQmFuZHNdID0gRVBTSUxPTjsKKyAgICAgICAgICAg IGJhbmRbaStjKm0tPm5iRUJhbmRzXSA9IEVQU0lMT047CiAgICAgICAgICB9Ci0gICAgICAgICAv KnByaW50ZiAoIiVmICIsIGJhbmtbaStjKm0tPm5iRUJhbmRzXSk7Ki8KKyAgICAgICAgIC8qcHJp bnRmICgiJWYgIiwgYmFuZFtpK2MqbS0+bmJFQmFuZHNdKTsqLwogICAgICAgfQogICAgfSB3aGls ZSAoKytjPEMpOwogICAgLypwcmludGYgKCJcbiIpOyovCiB9CiAKIC8qIE5vcm1hbGlzZSBlYWNo IGJhbmQgc3VjaCB0aGF0IHRoZSBlbmVyZ3kgaXMgb25lLiAqLwotdm9pZCBub3JtYWxpc2VfYmFu ZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICogcmVzdHJpY3QgZnJlcSwgY2Vs dF9ub3JtICogcmVzdHJpY3QgWCwgY29uc3QgY2VsdF9lbmVyICpiYW5rLCBpbnQgZW5kLCBpbnQg X0MsIGludCBNKQordm9pZCBub3JtYWxpc2VfYmFuZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0 IGNlbHRfc2lnICogcmVzdHJpY3QgZnJlcSwgY2VsdF9ub3JtICogcmVzdHJpY3QgWCwgY29uc3Qg Y2VsdF9lbmVyICpiYW5kLCBpbnQgZW5kLCBpbnQgX0MsIGludCBNKQogewogICAgaW50IGksIGMs IE47CiAgICBjb25zdCBvcHVzX2ludDE2ICplQmFuZHMgPSBtLT5lQmFuZHM7CkBAIC0xMjQsOCAr MTI0LDggQEAgdm9pZCBub3JtYWxpc2VfYmFuZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNl bHRfc2lnICogcmVzdHJpY3QgZnJlcSwgY2VsdF9ub3IKICAgICAgICAgIG9wdXNfdmFsMTYgZzsK ICAgICAgICAgIGludCBqLHNoaWZ0OwogICAgICAgICAgb3B1c192YWwxNiBFOwotICAgICAgICAg c2hpZnQgPSBjZWx0X3psb2cyKGJhbmtbaStjKm0tPm5iRUJhbmRzXSktMTM7Ci0gICAgICAgICBF ID0gVlNIUjMyKGJhbmtbaStjKm0tPm5iRUJhbmRzXSwgc2hpZnQpOworICAgICAgICAgc2hpZnQg PSBjZWx0X3psb2cyKGJhbmRbaStjKm0tPm5iRUJhbmRzXSktMTM7CisgICAgICAgICBFID0gVlNI UjMyKGJhbmRbaStjKm0tPm5iRUJhbmRzXSwgc2hpZnQpOwogICAgICAgICAgZyA9IEVYVFJBQ1Qx NihjZWx0X3JjcChTSEwzMihFLDMpKSk7CiAgICAgICAgICBqPU0qZUJhbmRzW2ldOyBkbyB7CiAg ICAgICAgICAgICBYW2orYypOXSA9IE1VTFQxNl8xNl9RMTUoVlNIUjMyKGZyZXFbaitjKk5dLHNo aWZ0LTEpLGcpOwpAQCAtMTM2LDcgKzEzNiw3IEBAIHZvaWQgbm9ybWFsaXNlX2JhbmRzKGNvbnN0 IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9yCiAK ICNlbHNlIC8qIEZJWEVEX1BPSU5UICovCiAvKiBDb21wdXRlIHRoZSBhbXBsaXR1ZGUgKHNxcnQg ZW5lcmd5KSBpbiBlYWNoIG9mIHRoZSBiYW5kcyAqLwotdm9pZCBjb21wdXRlX2JhbmRfZW5lcmdp ZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0X2VuZXIgKmJhbmss IGludCBlbmQsIGludCBfQywgaW50IE0pCit2b2lkIGNvbXB1dGVfYmFuZF9lbmVyZ2llcyhjb25z dCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNlbHRfZW5lciAqYmFuZCwgaW50IGVu ZCwgaW50IF9DLCBpbnQgTSkKIHsKICAgIGludCBpLCBjLCBOOwogICAgY29uc3Qgb3B1c19pbnQx NiAqZUJhbmRzID0gbS0+ZUJhbmRzOwpAQCAtMTQ5LDE1ICsxNDksMTUgQEAgdm9pZCBjb21wdXRl X2JhbmRfZW5lcmdpZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0 X2VuZXIgKmJhbmsKICAgICAgICAgIG9wdXNfdmFsMzIgc3VtID0gMWUtMjdmOwogICAgICAgICAg Zm9yIChqPU0qZUJhbmRzW2ldO2o8TSplQmFuZHNbaSsxXTtqKyspCiAgICAgICAgICAgICBzdW0g Kz0gWFtqK2MqTl0qWFtqK2MqTl07Ci0gICAgICAgICBiYW5rW2krYyptLT5uYkVCYW5kc10gPSBj ZWx0X3NxcnQoc3VtKTsKLSAgICAgICAgIC8qcHJpbnRmICgiJWYgIiwgYmFua1tpK2MqbS0+bmJF QmFuZHNdKTsqLworICAgICAgICAgYmFuZFtpK2MqbS0+bmJFQmFuZHNdID0gY2VsdF9zcXJ0KHN1 bSk7CisgICAgICAgICAvKnByaW50ZiAoIiVmICIsIGJhbmRbaStjKm0tPm5iRUJhbmRzXSk7Ki8K ICAgICAgIH0KICAgIH0gd2hpbGUgKCsrYzxDKTsKICAgIC8qcHJpbnRmICgiXG4iKTsqLwogfQog CiAvKiBOb3JtYWxpc2UgZWFjaCBiYW5kIHN1Y2ggdGhhdCB0aGUgZW5lcmd5IGlzIG9uZS4gKi8K LXZvaWQgbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAq IHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9ybSAqIHJlc3RyaWN0IFgsIGNvbnN0IGNlbHRfZW5lciAq YmFuaywgaW50IGVuZCwgaW50IF9DLCBpbnQgTSkKK3ZvaWQgbm9ybWFsaXNlX2JhbmRzKGNvbnN0 IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9ybSAq IHJlc3RyaWN0IFgsIGNvbnN0IGNlbHRfZW5lciAqYmFuZCwgaW50IGVuZCwgaW50IF9DLCBpbnQg TSkKIHsKICAgIGludCBpLCBjLCBOOwogICAgY29uc3Qgb3B1c19pbnQxNiAqZUJhbmRzID0gbS0+ ZUJhbmRzOwpAQCAtMTY3LDcgKzE2Nyw3IEBAIHZvaWQgbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENF TFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9yCiAgICAg ICBmb3IgKGk9MDtpPGVuZDtpKyspCiAgICAgICB7CiAgICAgICAgICBpbnQgajsKLSAgICAgICAg IG9wdXNfdmFsMTYgZyA9IDEuZi8oMWUtMjdmK2JhbmtbaStjKm0tPm5iRUJhbmRzXSk7CisgICAg ICAgICBvcHVzX3ZhbDE2IGcgPSAxLmYvKDFlLTI3ZitiYW5kW2krYyptLT5uYkVCYW5kc10pOwog ICAgICAgICAgZm9yIChqPU0qZUJhbmRzW2ldO2o8TSplQmFuZHNbaSsxXTtqKyspCiAgICAgICAg ICAgICBYW2orYypOXSA9IGZyZXFbaitjKk5dKmc7CiAgICAgICB9CkBAIC0xNzcsNyArMTc3LDcg QEAgdm9pZCBub3JtYWxpc2VfYmFuZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2ln ICogcmVzdHJpY3QgZnJlcSwgY2VsdF9ub3IKICNlbmRpZiAvKiBGSVhFRF9QT0lOVCAqLwogCiAv KiBEZS1ub3JtYWxpc2UgdGhlIGVuZXJneSB0byBwcm9kdWNlIHRoZSBzeW50aGVzaXMgZnJvbSB0 aGUgdW5pdC1lbmVyZ3kgYmFuZHMgKi8KLXZvaWQgZGVub3JtYWxpc2VfYmFuZHMoY29uc3QgQ0VM VE1vZGUgKm0sIGNvbnN0IGNlbHRfbm9ybSAqIHJlc3RyaWN0IFgsIGNlbHRfc2lnICogcmVzdHJp Y3QgZnJlcSwgY29uc3QgY2VsdF9lbmVyICpiYW5rLCBpbnQgZW5kLCBpbnQgX0MsIGludCBNKQor dm9pZCBkZW5vcm1hbGlzZV9iYW5kcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9ub3Jt ICogcmVzdHJpY3QgWCwgY2VsdF9zaWcgKiByZXN0cmljdCBmcmVxLCBjb25zdCBjZWx0X2VuZXIg KmJhbmQsIGludCBlbmQsIGludCBfQywgaW50IE0pCiB7CiAgICBpbnQgaSwgYywgTjsKICAgIGNv bnN0IG9wdXNfaW50MTYgKmVCYW5kcyA9IG0tPmVCYW5kczsKQEAgLTE5Miw3ICsxOTIsNyBAQCB2 b2lkIGRlbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X25vcm0g KiByZXN0cmljdCBYLCBjZWx0X3NpZwogICAgICAgZm9yIChpPTA7aTxlbmQ7aSsrKQogICAgICAg ewogICAgICAgICAgaW50IGosIGJhbmRfZW5kOwotICAgICAgICAgb3B1c192YWwzMiBnID0gU0hS MzIoYmFua1tpK2MqbS0+bmJFQmFuZHNdLDEpOworICAgICAgICAgb3B1c192YWwzMiBnID0gU0hS MzIoYmFuZFtpK2MqbS0+bmJFQmFuZHNdLDEpOwogICAgICAgICAgaj1NKmVCYW5kc1tpXTsKICAg ICAgICAgIGJhbmRfZW5kID0gTSplQmFuZHNbaSsxXTsKICAgICAgICAgIGRvIHsKQEAgLTI5Niw3 ICsyOTYsNyBAQCB2b2lkIGFudGlfY29sbGFwc2UoY29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9y bSAqX1gsIHVuc2lnbmVkIGNoYXIgKmNvbGxhcHNlX21hcwogICAgfQogfQogCi1zdGF0aWMgdm9p ZCBpbnRlbnNpdHlfc3RlcmVvKGNvbnN0IENFTFRNb2RlICptLCBjZWx0X25vcm0gKlgsIGNlbHRf bm9ybSAqWSwgY29uc3QgY2VsdF9lbmVyICpiYW5rLCBpbnQgYmFuZElELCBpbnQgTikKK3N0YXRp YyB2b2lkIGludGVuc2l0eV9zdGVyZW8oY29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9ybSAqWCwg Y2VsdF9ub3JtICpZLCBjb25zdCBjZWx0X2VuZXIgKmJhbmQsIGludCBiYW5kSUQsIGludCBOKQog ewogICAgaW50IGkgPSBiYW5kSUQ7CiAgICBpbnQgajsKQEAgLTMwNCwxMCArMzA0LDEwIEBAIHN0 YXRpYyB2b2lkIGludGVuc2l0eV9zdGVyZW8oY29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9ybSAq WCwgY2VsdF9ub3JtICpZLCBjb25zCiAgICBvcHVzX3ZhbDE2IGxlZnQsIHJpZ2h0OwogICAgb3B1 c192YWwxNiBub3JtOwogI2lmZGVmIEZJWEVEX1BPSU5UCi0gICBpbnQgc2hpZnQgPSBjZWx0X3ps b2cyKE1BWDMyKGJhbmtbaV0sIGJhbmtbaSttLT5uYkVCYW5kc10pKS0xMzsKKyAgIGludCBzaGlm dCA9IGNlbHRfemxvZzIoTUFYMzIoYmFuZFtpXSwgYmFuZFtpK20tPm5iRUJhbmRzXSkpLTEzOwog I2VuZGlmCi0gICBsZWZ0ID0gVlNIUjMyKGJhbmtbaV0sc2hpZnQpOwotICAgcmlnaHQgPSBWU0hS MzIoYmFua1tpK20tPm5iRUJhbmRzXSxzaGlmdCk7CisgICBsZWZ0ID0gVlNIUjMyKGJhbmRbaV0s c2hpZnQpOworICAgcmlnaHQgPSBWU0hSMzIoYmFuZFtpK20tPm5iRUJhbmRzXSxzaGlmdCk7CiAg ICBub3JtID0gRVBTSUxPTiArIGNlbHRfc3FydChFUFNJTE9OK01VTFQxNl8xNihsZWZ0LGxlZnQp K01VTFQxNl8xNihyaWdodCxyaWdodCkpOwogICAgYTEgPSBESVYzMl8xNihTSEwzMihFWFRFTkQz MihsZWZ0KSwxNCksbm9ybSk7CiAgICBhMiA9IERJVjMyXzE2KFNITDMyKEVYVEVORDMyKHJpZ2h0 KSwxNCksbm9ybSk7CmRpZmYgLS1naXQgYS9jZWx0L2JhbmRzLmggYi9jZWx0L2JhbmRzLmgKaW5k ZXggMjVjMGEwMC4uMzQ4NTkzYiAxMDA2NDQKLS0tIGEvY2VsdC9iYW5kcy5oCisrKyBiL2NlbHQv YmFuZHMuaApAQCAtNDMsNyArNDMsNyBAQAogICovCiB2b2lkIGNvbXB1dGVfYmFuZF9lbmVyZ2ll cyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNlbHRfZW5lciAqYmFuZHMs IGludCBlbmQsIGludCBfQywgaW50IE0pOwogCi0vKnZvaWQgY29tcHV0ZV9ub2lzZV9lbmVyZ2ll cyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNvbnN0IG9wdXNfdmFsMTYg KnRvbmFsaXR5LCBjZWx0X2VuZXIgKmJhbmspOyovCisvKnZvaWQgY29tcHV0ZV9ub2lzZV9lbmVy Z2llcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNvbnN0IG9wdXNfdmFs MTYgKnRvbmFsaXR5LCBjZWx0X2VuZXIgKmJhbmQpOyovCiAKIC8qKiBOb3JtYWxpc2UgZWFjaCBi YW5kIG9mIFggc3VjaCB0aGF0IHRoZSBlbmVyZ3kgaW4gZWFjaCBiYW5kIGlzCiAgICAgZXF1YWwg dG8gMQotLSAKMS43LjYubXN5c2dpdC4wCgo= --0016364c7b65b3e44a04b21dbec5-- From jmvalin@mozilla.com Tue Nov 22 07:49:51 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE091F0C4D for ; Tue, 22 Nov 2011 07:49:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID+ZhiQWn0B9 for ; Tue, 22 Nov 2011 07:49:50 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9001F0C4F for ; Tue, 22 Nov 2011 07:49:50 -0800 (PST) Received: from [192.168.1.15] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id E69864AEDC7; Tue, 22 Nov 2011 07:49:48 -0800 (PST) Message-ID: <4ECBC4DC.10302@mozilla.com> Date: Tue, 22 Nov 2011 10:50:52 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: neerlent@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Opus codec on Analog Devices SHARC DSPs - patch needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 15:49:51 -0000 Sounds like a reasonable (and very low risk) change to make. Thanks, Jean-Marc On 19/11/11 05:12 PM, neerlent@gmail.com wrote: > Hello, > > I am currently considering the use of the Opus codec for an audio > streaming application that would run on an Analog Devices SHARC DSP. > Since it is a 32-bit floating-point DSP, I assumed it would be > relatively easy to get the Opus floating-point code building for the > SHARC. I am only interested in the CELT mode of operation, so I created > a project that included opus_custom_demo.c and all necessary files for > the demo to build. > > I found one issue that prevents the CELT code from building for the > SHARC DSP. The file bands.c contains a variable named "bank", which is > used in several places in the file. The SHARC C compiler treats "bank" > as a reserved keyword for specifying what memory block a piece of data > should go in. > > I've attached a patch that renames variables named "bank" to "band" in > both bands.c and bands.h. Let me know if you will consider making this > change. > > Thanks, > > Matt Kotvis > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jridges@masque.com Tue Nov 22 12:45:29 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45CA21F8B03 for ; Tue, 22 Nov 2011 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUi-yKpG3PS2 for ; Tue, 22 Nov 2011 12:45:28 -0800 (PST) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA03521F8B02 for ; Tue, 22 Nov 2011 12:45:28 -0800 (PST) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id B11E01602AB for ; Tue, 22 Nov 2011 13:45:27 -0700 (MST) Message-ID: <4ECC09E5.9070707@masque.com> Date: Tue, 22 Nov 2011 13:45:25 -0700 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Opus codec on Analog Devices SHARC DSPs - patch needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 20:45:29 -0000 Hello all. I realize it's rather late in the game, but I can't help but notice that several function in the CELT fork of the code use variable names that are formatted as system specific macros (e.g. _C). From the GNU docs: http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html 3.7.3 System-specific Predefined Macros The C preprocessor normally predefines several macros that indicate what type of system and machine is in use. They are obviously different on each target supported by GCC. This manual, being for all systems and machines, cannot tell you what their names are, but you can use cpp -dM to see them all. See Invocation . All system-specific predefined macros expand to the constant 1, so you can test them with either `#ifdef' or `#if'. The C standard requires that all system-specific macros be part of the reserved namespace. All names which begin with two underscores, or an underscore and a capital letter, are reserved for the compiler and library to use as they wish. However, historically system-specific macros have had names with no special prefix; for instance, it is common to find |unix| defined on Unix systems. For all such macros, GCC provides a parallel macro with two underscores added at the beginning and the end. If |unix| is defined, |__unix__| will be defined too. There will never be more than two underscores; the parallel of |_mips| is |__mips__|. When the -ansi option, or any -std option that requests strict conformance, is given to the compiler, all the system-specific predefined macros outside the reserved namespace are suppressed. The parallel macros, inside the reserved namespace, remain defined. We are slowly phasing out all predefined macros which are outside the reserved namespace. You should never use them in new programs, and we encourage you to correct older code to use the parallel macros whenever you find it. We don't recommend you use the system-specific macros that are in the reserved namespace, either. It is better in the long run to check specifically for features you need, using a tool such as autoconf. I urge that these variables be renamed, as some build systems will fail to build the code (most notably the Android NDK). John Ridges From giles@thaumas.net Tue Nov 29 14:11:45 2011 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655B711E8128 for ; Tue, 29 Nov 2011 14:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At314Jp5bGYJ for ; Tue, 29 Nov 2011 14:11:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8C11E8126 for ; Tue, 29 Nov 2011 14:11:41 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so7035113vcb.31 for ; Tue, 29 Nov 2011 14:11:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.87.8 with SMTP id u8mr5547551vcl.5.1322604700863; Tue, 29 Nov 2011 14:11:40 -0800 (PST) Received: by 10.220.157.9 with HTTP; Tue, 29 Nov 2011 14:11:40 -0800 (PST) X-Originating-IP: [184.71.166.126] In-Reply-To: <4ECC09E5.9070707@masque.com> References: <4ECC09E5.9070707@masque.com> Date: Tue, 29 Nov 2011 14:11:40 -0800 Message-ID: From: Ralph Giles To: John Ridges Content-Type: multipart/mixed; boundary=0016364ee59a5f8efc04b2e6e7fd Cc: codec@ietf.org Subject: Re: [codec] Opus codec on Analog Devices SHARC DSPs - patch needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 22:11:45 -0000 --0016364ee59a5f8efc04b2e6e7fd Content-Type: text/plain; charset=UTF-8 On 22 November 2011 12:45, John Ridges wrote: > I realize it's rather late in the game, but I can't help but notice that > several function in the CELT fork of the code use variable names that are > formatted as system specific macros (e.g. _C). Thanks for pointing this out. I've attached a patch which addresses the issue. -r --0016364ee59a5f8efc04b2e6e7fd Content-Type: application/octet-stream; name="0001-Rename-_FOO-to-avoid-potentional-collisions-with-res.patch" Content-Disposition: attachment; filename="0001-Rename-_FOO-to-avoid-potentional-collisions-with-res.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvlgofrt0 RnJvbSBmMGEzOTlhNmUyNzVjMWYzYzEyYTczMDVkZjQ1NTFlZDg4ZDRhM2Q2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSYWxwaCBHaWxlcyA8Z2lsZXNAbW96aWxsYS5jb20+CkRhdGU6 IEZyaSwgMjUgTm92IDIwMTEgMTM6MDI6MDAgLTA4MDAKU3ViamVjdDogW1BBVENIXSBSZW5hbWUg J19GT08nIHRvIGF2b2lkIHBvdGVudGlvbmFsIGNvbGxpc2lvbnMgd2l0aCByZXNlcnZlZAogaWRl bnRpZmllcnMuCgpDIHJlc2VydmVzIGlkZW50aWZpZXJzIG9mIHRoZSBmcm9tIF9bQS1aXSsgYW5k IHdlIGhhdmUgYSBudW1iZXIgb2YKdGhvc2UgaW4gdGhlIGNvZGUuIFRoaXMgcGF0Y2ggcmVuYW1l cyB0aGUgdmFyaW91cyBmdW5jdGlvbiBhcmd1bWVudHMsCk1BQ1JPUyBhbmQgcHJlcHJvY2Vzc29y IHN5bWJvbHMgdG8gYXZvaWQgdGhlIHJlc2VydmVkIGZvcm0uCgpJdCBhbHNvIHJlbW92ZXMgdGhl IENIQU5ORUxTKCkgbWFjcm8gYWx0b2dldGhlci4gVGhpcyB3YXMgYQptaW5vciBvcHRpbWl6YXRp b24gZm9yIFRJIERTUCB0byBmb3JjZSBhIG1vbm8tb25seSBidWlsZCwKYXMgd2VyZSB0aGUgYXNz b2NpYXRlZCBsb2NhbCAnY29uc3QnIHZlcnNpb25zLiBTaW5jZSBzdGVyZW8Kc3VwcG9ydCBpcyBt YW5kaXRvcnksIGl0IHdhc24ndCB3b3J0aCBrZWVwaW5nLgoKVGhhbmtzIHRvIEpvaG4gUmlkZ2Vz IGZvciByYWlzaW5nIHRoZSBpc3N1ZSwgYW5kIEplYW4tTWFyYyBWYWxpbgphbmQgR3JlZyBNYXh3 ZWxsIGZvciByZXZpZXdpbmcgdGhlIGNoYW5nZXMuCi0tLQogY2VsdC9iYW5kcy5jICAgICAgICAg ICAgIHwgICAzNCArKysrKysrKysrLS0tLS0tLS0tLS0tLS0tCiBjZWx0L2JhbmRzLmggICAgICAg ICAgICAgfCAgIDEwICsrKystLS0tCiBjZWx0L2NlbHQuYyAgICAgICAgICAgICAgfCAgIDI5ICsr KysrKysrKystLS0tLS0tLS0tLS0KIGNlbHQvY2VsdC5oICAgICAgICAgICAgICB8ICAgIDIgKy0K IGNlbHQvZml4ZWRfZGVidWcuaCAgICAgICB8ICAgNjAgKysrKysrKysrKysrKysrKysrKysrKyst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogY2VsdC9tb2Rlcy5oICAgICAgICAgICAgIHwgICAgOCAt LS0tLS0KIGNlbHQvcGl0Y2guYyAgICAgICAgICAgICB8ICAgMTkgKysrKysrKy0tLS0tLS0KIGNl bHQvcGl0Y2guaCAgICAgICAgICAgICB8ICAgIDYgKystLQogY2VsdC9xdWFudF9iYW5kcy5jICAg ICAgIHwgICAyNyArKysrKysrLS0tLS0tLS0tLS0tLQogY2VsdC9xdWFudF9iYW5kcy5oICAgICAg IHwgICAxNiArKysrKystLS0tLS0KIGNlbHQvcmF0ZS5jICAgICAgICAgICAgICB8ICAgIDYgKy0t LQogY2VsdC9yYXRlLmggICAgICAgICAgICAgIHwgICAgMiArLQogY2VsdC9zdGFja19hbGxvYy5o ICAgICAgIHwgICAxMCArKysrLS0tLQogaW5jbHVkZS9vcHVzX3R5cGVzLmggICAgIHwgICAgNiAr Ky0tCiBzaWxrL0lubGluZXMuaCAgICAgICAgICAgfCAgICA2ICsrLS0KIHNpbGsvTWFjcm9Db3Vu dC5oICAgICAgICB8ICAgIDQgKy0KIHNpbGsvTWFjcm9EZWJ1Zy5oICAgICAgICB8ICAgIDYgKyst LQogc2lsay9TaWdQcm9jX0ZJWC5oICAgICAgIHwgICAgNiArKy0tCiBzaWxrL2RlYnVnLmggICAg ICAgICAgICAgfCAgICA2ICsrLS0KIHNpbGsvZmxvYXQvU2lnUHJvY19GTFAuaCB8ICAgIDYgKyst LQogc2lsay9tYWNyb3MuaCAgICAgICAgICAgIHwgICAgNiArKy0tCiBzaWxrL3Jlc2FtcGxlcl9w cml2YXRlLmggfCAgICAzICstCiBzaWxrL3Jlc2FtcGxlcl9yb20uaCAgICAgfCAgICA2ICsrLS0K IHNpbGsvdHVuaW5nX3BhcmFtZXRlcnMuaCB8ICAgIDIgKy0KIHNpbGsvdHlwZWRlZi5oICAgICAg ICAgICB8ICAgIDYgKystLQogc3JjL29wdXNfcHJpdmF0ZS5oICAgICAgIHwgICAgMiArLQogMjYg ZmlsZXMgY2hhbmdlZCwgMTMyIGluc2VydGlvbnMoKyksIDE2MiBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS9jZWx0L2JhbmRzLmMgYi9jZWx0L2JhbmRzLmMKaW5kZXggNjY2ODYzZi4uNDQ2MWZm YSAxMDA2NDQKLS0tIGEvY2VsdC9iYW5kcy5jCisrKyBiL2NlbHQvYmFuZHMuYwpAQCAtNzUsMTEg Kzc1LDEwIEBAIHN0YXRpYyBpbnQgYml0ZXhhY3RfbG9nMnRhbihpbnQgaXNpbixpbnQgaWNvcykK IAogI2lmZGVmIEZJWEVEX1BPSU5UCiAvKiBDb21wdXRlIHRoZSBhbXBsaXR1ZGUgKHNxcnQgZW5l cmd5KSBpbiBlYWNoIG9mIHRoZSBiYW5kcyAqLwotdm9pZCBjb21wdXRlX2JhbmRfZW5lcmdpZXMo Y29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0X2VuZXIgKmJhbmssIGlu dCBlbmQsIGludCBfQywgaW50IE0pCit2b2lkIGNvbXB1dGVfYmFuZF9lbmVyZ2llcyhjb25zdCBD RUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcgKlgsIGNlbHRfZW5lciAqYmFuaywgaW50IGVuZCwg aW50IEMsIGludCBNKQogewogICAgaW50IGksIGMsIE47CiAgICBjb25zdCBvcHVzX2ludDE2ICpl QmFuZHMgPSBtLT5lQmFuZHM7Ci0gICBjb25zdCBpbnQgQyA9IENIQU5ORUxTKF9DKTsKICAgIE4g PSBNKm0tPnNob3J0TWRjdFNpemU7CiAgICBjPTA7IGRvIHsKICAgICAgIGZvciAoaT0wO2k8ZW5k O2krKykKQEAgLTExMywxMSArMTEyLDEwIEBAIHZvaWQgY29tcHV0ZV9iYW5kX2VuZXJnaWVzKGNv bnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqWCwgY2VsdF9lbmVyICpiYW5rCiB9CiAK IC8qIE5vcm1hbGlzZSBlYWNoIGJhbmQgc3VjaCB0aGF0IHRoZSBlbmVyZ3kgaXMgb25lLiAqLwot dm9pZCBub3JtYWxpc2VfYmFuZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICog cmVzdHJpY3QgZnJlcSwgY2VsdF9ub3JtICogcmVzdHJpY3QgWCwgY29uc3QgY2VsdF9lbmVyICpi YW5rLCBpbnQgZW5kLCBpbnQgX0MsIGludCBNKQordm9pZCBub3JtYWxpc2VfYmFuZHMoY29uc3Qg Q0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICogcmVzdHJpY3QgZnJlcSwgY2VsdF9ub3JtICog cmVzdHJpY3QgWCwgY29uc3QgY2VsdF9lbmVyICpiYW5rLCBpbnQgZW5kLCBpbnQgQywgaW50IE0p CiB7CiAgICBpbnQgaSwgYywgTjsKICAgIGNvbnN0IG9wdXNfaW50MTYgKmVCYW5kcyA9IG0tPmVC YW5kczsKLSAgIGNvbnN0IGludCBDID0gQ0hBTk5FTFMoX0MpOwogICAgTiA9IE0qbS0+c2hvcnRN ZGN0U2l6ZTsKICAgIGM9MDsgZG8gewogICAgICAgaT0wOyBkbyB7CkBAIC0xMzYsMTEgKzEzNCwx MCBAQCB2b2lkIG5vcm1hbGlzZV9iYW5kcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9z aWcgKiByZXN0cmljdCBmcmVxLCBjZWx0X25vcgogCiAjZWxzZSAvKiBGSVhFRF9QT0lOVCAqLwog LyogQ29tcHV0ZSB0aGUgYW1wbGl0dWRlIChzcXJ0IGVuZXJneSkgaW4gZWFjaCBvZiB0aGUgYmFu ZHMgKi8KLXZvaWQgY29tcHV0ZV9iYW5kX2VuZXJnaWVzKGNvbnN0IENFTFRNb2RlICptLCBjb25z dCBjZWx0X3NpZyAqWCwgY2VsdF9lbmVyICpiYW5rLCBpbnQgZW5kLCBpbnQgX0MsIGludCBNKQor dm9pZCBjb21wdXRlX2JhbmRfZW5lcmdpZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRf c2lnICpYLCBjZWx0X2VuZXIgKmJhbmssIGludCBlbmQsIGludCBDLCBpbnQgTSkKIHsKICAgIGlu dCBpLCBjLCBOOwogICAgY29uc3Qgb3B1c19pbnQxNiAqZUJhbmRzID0gbS0+ZUJhbmRzOwotICAg Y29uc3QgaW50IEMgPSBDSEFOTkVMUyhfQyk7CiAgICBOID0gTSptLT5zaG9ydE1kY3RTaXplOwog ICAgYz0wOyBkbyB7CiAgICAgICBmb3IgKGk9MDtpPGVuZDtpKyspCkBAIC0xNTcsMTEgKzE1NCwx MCBAQCB2b2lkIGNvbXB1dGVfYmFuZF9lbmVyZ2llcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3Qg Y2VsdF9zaWcgKlgsIGNlbHRfZW5lciAqYmFuawogfQogCiAvKiBOb3JtYWxpc2UgZWFjaCBiYW5k IHN1Y2ggdGhhdCB0aGUgZW5lcmd5IGlzIG9uZS4gKi8KLXZvaWQgbm9ybWFsaXNlX2JhbmRzKGNv bnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9y bSAqIHJlc3RyaWN0IFgsIGNvbnN0IGNlbHRfZW5lciAqYmFuaywgaW50IGVuZCwgaW50IF9DLCBp bnQgTSkKK3ZvaWQgbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0 X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9ybSAqIHJlc3RyaWN0IFgsIGNvbnN0IGNlbHRf ZW5lciAqYmFuaywgaW50IGVuZCwgaW50IEMsIGludCBNKQogewogICAgaW50IGksIGMsIE47CiAg ICBjb25zdCBvcHVzX2ludDE2ICplQmFuZHMgPSBtLT5lQmFuZHM7Ci0gICBjb25zdCBpbnQgQyA9 IENIQU5ORUxTKF9DKTsKICAgIE4gPSBNKm0tPnNob3J0TWRjdFNpemU7CiAgICBjPTA7IGRvIHsK ICAgICAgIGZvciAoaT0wO2k8ZW5kO2krKykKQEAgLTE3NywxMSArMTczLDEwIEBAIHZvaWQgbm9y bWFsaXNlX2JhbmRzKGNvbnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0 IGZyZXEsIGNlbHRfbm9yCiAjZW5kaWYgLyogRklYRURfUE9JTlQgKi8KIAogLyogRGUtbm9ybWFs aXNlIHRoZSBlbmVyZ3kgdG8gcHJvZHVjZSB0aGUgc3ludGhlc2lzIGZyb20gdGhlIHVuaXQtZW5l cmd5IGJhbmRzICovCi12b2lkIGRlbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENFTFRNb2RlICptLCBj b25zdCBjZWx0X25vcm0gKiByZXN0cmljdCBYLCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNv bnN0IGNlbHRfZW5lciAqYmFuaywgaW50IGVuZCwgaW50IF9DLCBpbnQgTSkKK3ZvaWQgZGVub3Jt YWxpc2VfYmFuZHMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfbm9ybSAqIHJlc3RyaWN0 IFgsIGNlbHRfc2lnICogcmVzdHJpY3QgZnJlcSwgY29uc3QgY2VsdF9lbmVyICpiYW5rLCBpbnQg ZW5kLCBpbnQgQywgaW50IE0pCiB7CiAgICBpbnQgaSwgYywgTjsKICAgIGNvbnN0IG9wdXNfaW50 MTYgKmVCYW5kcyA9IG0tPmVCYW5kczsKLSAgIGNvbnN0IGludCBDID0gQ0hBTk5FTFMoX0MpOwog ICAgTiA9IE0qbS0+c2hvcnRNZGN0U2l6ZTsKICAgIGNlbHRfYXNzZXJ0MihDPD0yLCAiZGVub3Jt YWxpc2VfYmFuZHMoKSBub3QgaW1wbGVtZW50ZWQgZm9yID4yIGNoYW5uZWxzIik7CiAgICBjPTA7 IGRvIHsKQEAgLTIwNiw3ICsyMDEsNyBAQCB2b2lkIGRlbm9ybWFsaXNlX2JhbmRzKGNvbnN0IENF TFRNb2RlICptLCBjb25zdCBjZWx0X25vcm0gKiByZXN0cmljdCBYLCBjZWx0X3NpZwogfQogCiAv KiBUaGlzIHByZXZlbnRzIGVuZXJneSBjb2xsYXBzZSBmb3IgdHJhbnNpZW50cyB3aXRoIG11bHRp cGxlIHNob3J0IE1EQ1RzICovCi12b2lkIGFudGlfY29sbGFwc2UoY29uc3QgQ0VMVE1vZGUgKm0s IGNlbHRfbm9ybSAqX1gsIHVuc2lnbmVkIGNoYXIgKmNvbGxhcHNlX21hc2tzLCBpbnQgTE0sIGlu dCBDLCBpbnQgQ0MsIGludCBzaXplLAordm9pZCBhbnRpX2NvbGxhcHNlKGNvbnN0IENFTFRNb2Rl ICptLCBjZWx0X25vcm0gKlhfLCB1bnNpZ25lZCBjaGFyICpjb2xsYXBzZV9tYXNrcywgaW50IExN LCBpbnQgQywgaW50IENDLCBpbnQgc2l6ZSwKICAgICAgIGludCBzdGFydCwgaW50IGVuZCwgb3B1 c192YWwxNiAqbG9nRSwgb3B1c192YWwxNiAqcHJldjFsb2dFLAogICAgICAgb3B1c192YWwxNiAq cHJldjJsb2dFLCBpbnQgKnB1bHNlcywgb3B1c191aW50MzIgc2VlZCkKIHsKQEAgLTI3NCw3ICsy NjksNyBAQCB2b2lkIGFudGlfY29sbGFwc2UoY29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9ybSAq X1gsIHVuc2lnbmVkIGNoYXIgKmNvbGxhcHNlX21hcwogICAgICAgICAgciA9IE1JTjE2KHRocmVz aCwgcik7CiAgICAgICAgICByID0gcipzcXJ0XzE7CiAjZW5kaWYKLSAgICAgICAgIFggPSBfWCtj KnNpemUrKG0tPmVCYW5kc1tpXTw8TE0pOworICAgICAgICAgWCA9IFhfK2Mqc2l6ZSsobS0+ZUJh bmRzW2ldPDxMTSk7CiAgICAgICAgICBmb3IgKGs9MDtrPDE8PExNO2srKykKICAgICAgICAgIHsK ICAgICAgICAgICAgIC8qIERldGVjdCBjb2xsYXBzZSAqLwpAQCAtMzk0LDExICszODksMTAgQEAg c3RhdGljIHZvaWQgc3RlcmVvX21lcmdlKGNlbHRfbm9ybSAqWCwgY2VsdF9ub3JtICpZLCBvcHVz X3ZhbDE2IG1pZCwgaW50IE4pCiAvKiBEZWNpZGUgd2hldGhlciB3ZSBzaG91bGQgc3ByZWFkIHRo ZSBwdWxzZXMgaW4gdGhlIGN1cnJlbnQgZnJhbWUgKi8KIGludCBzcHJlYWRpbmdfZGVjaXNpb24o Y29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9ybSAqWCwgaW50ICphdmVyYWdlLAogICAgICAgaW50 IGxhc3RfZGVjaXNpb24sIGludCAqaGZfYXZlcmFnZSwgaW50ICp0YXBzZXRfZGVjaXNpb24sIGlu dCB1cGRhdGVfaGYsCi0gICAgICBpbnQgZW5kLCBpbnQgX0MsIGludCBNKQorICAgICAgaW50IGVu ZCwgaW50IEMsIGludCBNKQogewogICAgaW50IGksIGMsIE4wOwogICAgaW50IHN1bSA9IDAsIG5i QmFuZHM9MDsKLSAgIGNvbnN0IGludCBDID0gQ0hBTk5FTFMoX0MpOwogICAgY29uc3Qgb3B1c19p bnQxNiAqIHJlc3RyaWN0IGVCYW5kcyA9IG0tPmVCYW5kczsKICAgIGludCBkZWNpc2lvbjsKICAg IGludCBoZl9zdW09MDsKQEAgLTExNzEsNyArMTE2NSw3IEBAIHN0YXRpYyB1bnNpZ25lZCBxdWFu dF9iYW5kKGludCBlbmNvZGUsIGNvbnN0IENFTFRNb2RlICptLCBpbnQgaSwgY2VsdF9ub3JtICpY LCBjCiB9CiAKIHZvaWQgcXVhbnRfYWxsX2JhbmRzKGludCBlbmNvZGUsIGNvbnN0IENFTFRNb2Rl ICptLCBpbnQgc3RhcnQsIGludCBlbmQsCi0gICAgICBjZWx0X25vcm0gKl9YLCBjZWx0X25vcm0g Kl9ZLCB1bnNpZ25lZCBjaGFyICpjb2xsYXBzZV9tYXNrcywgY29uc3QgY2VsdF9lbmVyICpiYW5k RSwgaW50ICpwdWxzZXMsCisgICAgICBjZWx0X25vcm0gKlhfLCBjZWx0X25vcm0gKllfLCB1bnNp Z25lZCBjaGFyICpjb2xsYXBzZV9tYXNrcywgY29uc3QgY2VsdF9lbmVyICpiYW5kRSwgaW50ICpw dWxzZXMsCiAgICAgICBpbnQgc2hvcnRCbG9ja3MsIGludCBzcHJlYWQsIGludCBkdWFsX3N0ZXJl bywgaW50IGludGVuc2l0eSwgaW50ICp0Zl9yZXMsCiAgICAgICBvcHVzX2ludDMyIHRvdGFsX2Jp dHMsIG9wdXNfaW50MzIgYmFsYW5jZSwgZWNfY3R4ICplYywgaW50IExNLCBpbnQgY29kZWRCYW5k cywgb3B1c191aW50MzIgKnNlZWQpCiB7CkBAIC0xMTg1LDcgKzExNzksNyBAQCB2b2lkIHF1YW50 X2FsbF9iYW5kcyhpbnQgZW5jb2RlLCBjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQg ZW5kLAogICAgaW50IE07CiAgICBpbnQgbG93YmFuZF9vZmZzZXQ7CiAgICBpbnQgdXBkYXRlX2xv d2JhbmQgPSAxOwotICAgaW50IEMgPSBfWSAhPSBOVUxMID8gMiA6IDE7CisgICBpbnQgQyA9IFlf ICE9IE5VTEwgPyAyIDogMTsKICNpZmRlZiBSRVNZTlRICiAgICBpbnQgcmVzeW50aCA9IDE7CiAj ZWxzZQpAQCAtMTIxMyw5ICsxMjA3LDkgQEAgdm9pZCBxdWFudF9hbGxfYmFuZHMoaW50IGVuY29k ZSwgY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwKICAgICAgIHVuc2lnbmVk IHhfY207CiAgICAgICB1bnNpZ25lZCB5X2NtOwogCi0gICAgICBYID0gX1grTSplQmFuZHNbaV07 Ci0gICAgICBpZiAoX1khPU5VTEwpCi0gICAgICAgICBZID0gX1krTSplQmFuZHNbaV07CisgICAg ICBYID0gWF8rTSplQmFuZHNbaV07CisgICAgICBpZiAoWV8hPU5VTEwpCisgICAgICAgICBZID0g WV8rTSplQmFuZHNbaV07CiAgICAgICBlbHNlCiAgICAgICAgICBZID0gTlVMTDsKICAgICAgIE4g PSBNKmVCYW5kc1tpKzFdLU0qZUJhbmRzW2ldOwpAQCAtMTI0MCw3ICsxMjM0LDcgQEAgdm9pZCBx dWFudF9hbGxfYmFuZHMoaW50IGVuY29kZSwgY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwg aW50IGVuZCwKICAgICAgIGlmIChpPj1tLT5lZmZFQmFuZHMpCiAgICAgICB7CiAgICAgICAgICBY PW5vcm07Ci0gICAgICAgICBpZiAoX1khPU5VTEwpCisgICAgICAgICBpZiAoWV8hPU5VTEwpCiAg ICAgICAgICAgICBZID0gbm9ybTsKICAgICAgIH0KIApkaWZmIC0tZ2l0IGEvY2VsdC9iYW5kcy5o IGIvY2VsdC9iYW5kcy5oCmluZGV4IDI1YzBhMDAuLjBmNmQ3YzAgMTAwNjQ0Ci0tLSBhL2NlbHQv YmFuZHMuaAorKysgYi9jZWx0L2JhbmRzLmgKQEAgLTQxLDcgKzQxLDcgQEAKICAqIEBwYXJhbSBY IFNwZWN0cnVtCiAgKiBAcGFyYW0gYmFuZHMgU3F1YXJlIHJvb3Qgb2YgdGhlIGVuZXJneSBmb3Ig ZWFjaCBiYW5kIChyZXR1cm5lZCkKICAqLwotdm9pZCBjb21wdXRlX2JhbmRfZW5lcmdpZXMoY29u c3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0X2VuZXIgKmJhbmRzLCBpbnQg ZW5kLCBpbnQgX0MsIGludCBNKTsKK3ZvaWQgY29tcHV0ZV9iYW5kX2VuZXJnaWVzKGNvbnN0IENF TFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqWCwgY2VsdF9lbmVyICpiYW5kcywgaW50IGVuZCwg aW50IEMsIGludCBNKTsKIAogLyp2b2lkIGNvbXB1dGVfbm9pc2VfZW5lcmdpZXMoY29uc3QgQ0VM VE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjb25zdCBvcHVzX3ZhbDE2ICp0b25hbGl0eSwg Y2VsdF9lbmVyICpiYW5rKTsqLwogCkBAIC01MSwxNCArNTEsMTQgQEAgdm9pZCBjb21wdXRlX2Jh bmRfZW5lcmdpZXMoY29uc3QgQ0VMVE1vZGUgKm0sIGNvbnN0IGNlbHRfc2lnICpYLCBjZWx0X2Vu ZXIgKmJhbmQKICAqIEBwYXJhbSBYIFNwZWN0cnVtIChyZXR1cm5lZCBub3JtYWxpc2VkKQogICog QHBhcmFtIGJhbmRzIFNxdWFyZSByb290IG9mIHRoZSBlbmVyZ3kgZm9yIGVhY2ggYmFuZAogICov Ci12b2lkIG5vcm1hbGlzZV9iYW5kcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2VsdF9zaWcg KiByZXN0cmljdCBmcmVxLCBjZWx0X25vcm0gKiByZXN0cmljdCBYLCBjb25zdCBjZWx0X2VuZXIg KmJhbmRzLCBpbnQgZW5kLCBpbnQgX0MsIGludCBNKTsKK3ZvaWQgbm9ybWFsaXNlX2JhbmRzKGNv bnN0IENFTFRNb2RlICptLCBjb25zdCBjZWx0X3NpZyAqIHJlc3RyaWN0IGZyZXEsIGNlbHRfbm9y bSAqIHJlc3RyaWN0IFgsIGNvbnN0IGNlbHRfZW5lciAqYmFuZHMsIGludCBlbmQsIGludCBDLCBp bnQgTSk7CiAKIC8qKiBEZW5vcm1hbGlzZSBlYWNoIGJhbmQgb2YgWCB0byByZXN0b3JlIGZ1bGwg YW1wbGl0dWRlCiAgKiBAcGFyYW0gbSBNb2RlIGRhdGEKICAqIEBwYXJhbSBYIFNwZWN0cnVtIChy ZXR1cm5lZCBkZS1ub3JtYWxpc2VkKQogICogQHBhcmFtIGJhbmRzIFNxdWFyZSByb290IG9mIHRo ZSBlbmVyZ3kgZm9yIGVhY2ggYmFuZAogICovCi12b2lkIGRlbm9ybWFsaXNlX2JhbmRzKGNvbnN0 IENFTFRNb2RlICptLCBjb25zdCBjZWx0X25vcm0gKiByZXN0cmljdCBYLCBjZWx0X3NpZyAqIHJl c3RyaWN0IGZyZXEsIGNvbnN0IGNlbHRfZW5lciAqYmFuZHMsIGludCBlbmQsIGludCBfQywgaW50 IE0pOwordm9pZCBkZW5vcm1hbGlzZV9iYW5kcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2Vs dF9ub3JtICogcmVzdHJpY3QgWCwgY2VsdF9zaWcgKiByZXN0cmljdCBmcmVxLCBjb25zdCBjZWx0 X2VuZXIgKmJhbmRzLCBpbnQgZW5kLCBpbnQgQywgaW50IE0pOwogCiAjZGVmaW5lIFNQUkVBRF9O T05FICAgICAgICgwKQogI2RlZmluZSBTUFJFQURfTElHSFQgICAgICAoMSkKQEAgLTY3LDcgKzY3 LDcgQEAgdm9pZCBkZW5vcm1hbGlzZV9iYW5kcyhjb25zdCBDRUxUTW9kZSAqbSwgY29uc3QgY2Vs dF9ub3JtICogcmVzdHJpY3QgWCwgY2VsdF9zaWcKIAogaW50IHNwcmVhZGluZ19kZWNpc2lvbihj b25zdCBDRUxUTW9kZSAqbSwgY2VsdF9ub3JtICpYLCBpbnQgKmF2ZXJhZ2UsCiAgICAgICBpbnQg bGFzdF9kZWNpc2lvbiwgaW50ICpoZl9hdmVyYWdlLCBpbnQgKnRhcHNldF9kZWNpc2lvbiwgaW50 IHVwZGF0ZV9oZiwKLSAgICAgIGludCBlbmQsIGludCBfQywgaW50IE0pOworICAgICAgaW50IGVu ZCwgaW50IEMsIGludCBNKTsKIAogI2lmZGVmIE1FQVNVUkVfTk9STV9NU0UKIHZvaWQgbWVhc3Vy ZV9ub3JtX21zZShjb25zdCBDRUxUTW9kZSAqbSwgZmxvYXQgKlgsIGZsb2F0ICpYMCwgZmxvYXQg KmJhbmRFLCBmbG9hdCAqYmFuZEUwLCBpbnQgTSwgaW50IE4sIGludCBDKTsKQEAgLTg2LDcgKzg2 LDcgQEAgdm9pZCBxdWFudF9hbGxfYmFuZHMoaW50IGVuY29kZSwgY29uc3QgQ0VMVE1vZGUgKm0s IGludCBzdGFydCwgaW50IGVuZCwKICAgICAgIGludCB0aW1lX2RvbWFpbiwgaW50IGZvbGQsIGlu dCBkdWFsX3N0ZXJlbywgaW50IGludGVuc2l0eSwgaW50ICp0Zl9yZXMsCiAgICAgICBvcHVzX2lu dDMyIHRvdGFsX2JpdHMsIG9wdXNfaW50MzIgYmFsYW5jZSwgZWNfY3R4ICplYywgaW50IE0sIGlu dCBjb2RlZEJhbmRzLCBvcHVzX3VpbnQzMiAqc2VlZCk7CiAKLXZvaWQgYW50aV9jb2xsYXBzZShj b25zdCBDRUxUTW9kZSAqbSwgY2VsdF9ub3JtICpfWCwgdW5zaWduZWQgY2hhciAqY29sbGFwc2Vf bWFza3MsIGludCBMTSwgaW50IEMsIGludCBDQywgaW50IHNpemUsCit2b2lkIGFudGlfY29sbGFw c2UoY29uc3QgQ0VMVE1vZGUgKm0sIGNlbHRfbm9ybSAqWF8sIHVuc2lnbmVkIGNoYXIgKmNvbGxh cHNlX21hc2tzLCBpbnQgTE0sIGludCBDLCBpbnQgQ0MsIGludCBzaXplLAogICAgICAgaW50IHN0 YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpsb2dFLCBvcHVzX3ZhbDE2ICpwcmV2MWxvZ0UsCiAg ICAgICBvcHVzX3ZhbDE2ICpwcmV2MmxvZ0UsIGludCAqcHVsc2VzLCBvcHVzX3VpbnQzMiBzZWVk KTsKIApkaWZmIC0tZ2l0IGEvY2VsdC9jZWx0LmMgYi9jZWx0L2NlbHQuYwppbmRleCA1MmE4ZjJm Li5lZWVkMDVhIDEwMDY0NAotLS0gYS9jZWx0L2NlbHQuYworKysgYi9jZWx0L2NlbHQuYwpAQCAt MTAwLDcgKzEwMCw3IEBAIHN0YXRpYyBpbmxpbmUgaW50IGZyb21PcHVzKHVuc2lnbmVkIGNoYXIg YykKICAgIGVsc2UKICAgICAgIHJldHVybiBmcm9tT3B1c1RhYmxlWyhjPj4zKS0xNl0gfCAoYyYw eDcpOwogfQotI2VuZGlmIC8qQ1VTVE9NX01PREVTKi8KKyNlbmRpZiAvKiBDVVNUT01fTU9ERVMg Ki8KIAogI2RlZmluZSBDT01CRklMVEVSX01BWFBFUklPRCAxMDI0CiAjZGVmaW5lIENPTUJGSUxU RVJfTUlOUEVSSU9EIDE1CkBAIC0zODMsOSArMzgzLDggQEAgc3RhdGljIGludCB0cmFuc2llbnRf YW5hbHlzaXMoY29uc3Qgb3B1c192YWwzMiAqIHJlc3RyaWN0IGluLCBpbnQgbGVuLCBpbnQgQywK IAogLyoqIEFwcGx5IHdpbmRvdyBhbmQgY29tcHV0ZSB0aGUgTURDVCBmb3IgYWxsIHN1Yi1mcmFt ZXMgYW5kCiAgICAgYWxsIGNoYW5uZWxzIGluIGEgZnJhbWUgKi8KLXN0YXRpYyB2b2lkIGNvbXB1 dGVfbWRjdHMoY29uc3QgQ0VMVE1vZGUgKm1vZGUsIGludCBzaG9ydEJsb2NrcywgY2VsdF9zaWcg KiByZXN0cmljdCBpbiwgY2VsdF9zaWcgKiByZXN0cmljdCBvdXQsIGludCBfQywgaW50IExNKQor c3RhdGljIHZvaWQgY29tcHV0ZV9tZGN0cyhjb25zdCBDRUxUTW9kZSAqbW9kZSwgaW50IHNob3J0 QmxvY2tzLCBjZWx0X3NpZyAqIHJlc3RyaWN0IGluLCBjZWx0X3NpZyAqIHJlc3RyaWN0IG91dCwg aW50IEMsIGludCBMTSkKIHsKLSAgIGNvbnN0IGludCBDID0gQ0hBTk5FTFMoX0MpOwogICAgaWYg KEM9PTEgJiYgIXNob3J0QmxvY2tzKQogICAgewogICAgICAgY29uc3QgaW50IG92ZXJsYXAgPSBP VkVSTEFQKG1vZGUpOwpAQCAtNDE0LDEwICs0MTMsOSBAQCBzdGF0aWMgdm9pZCBjb21wdXRlX21k Y3RzKGNvbnN0IENFTFRNb2RlICptb2RlLCBpbnQgc2hvcnRCbG9ja3MsIGNlbHRfc2lnICogcmVz dAogICAgIGFsbCBjaGFubmVscyBpbiBhIGZyYW1lICovCiBzdGF0aWMgdm9pZCBjb21wdXRlX2lu dl9tZGN0cyhjb25zdCBDRUxUTW9kZSAqbW9kZSwgaW50IHNob3J0QmxvY2tzLCBjZWx0X3NpZyAq WCwKICAgICAgIGNlbHRfc2lnICogcmVzdHJpY3Qgb3V0X21lbVtdLAotICAgICAgY2VsdF9zaWcg KiByZXN0cmljdCBvdmVybGFwX21lbVtdLCBpbnQgX0MsIGludCBMTSkKKyAgICAgIGNlbHRfc2ln ICogcmVzdHJpY3Qgb3ZlcmxhcF9tZW1bXSwgaW50IEMsIGludCBMTSkKIHsKICAgIGludCBjOwot ICAgY29uc3QgaW50IEMgPSBDSEFOTkVMUyhfQyk7CiAgICBjb25zdCBpbnQgTiA9IG1vZGUtPnNo b3J0TWRjdFNpemU8PExNOwogICAgY29uc3QgaW50IG92ZXJsYXAgPSBPVkVSTEFQKG1vZGUpOwog ICAgVkFSREVDTChvcHVzX3ZhbDMyLCB4KTsKQEAgLTQ1NCw5ICs0NTIsOCBAQCBzdGF0aWMgdm9p ZCBjb21wdXRlX2ludl9tZGN0cyhjb25zdCBDRUxUTW9kZSAqbW9kZSwgaW50IHNob3J0QmxvY2tz LCBjZWx0X3NpZyAqWAogICAgUkVTVE9SRV9TVEFDSzsKIH0KIAotc3RhdGljIHZvaWQgZGVlbXBo YXNpcyhjZWx0X3NpZyAqaW5bXSwgb3B1c192YWwxNiAqcGNtLCBpbnQgTiwgaW50IF9DLCBpbnQg ZG93bnNhbXBsZSwgY29uc3Qgb3B1c192YWwxNiAqY29lZiwgY2VsdF9zaWcgKm1lbSkKK3N0YXRp YyB2b2lkIGRlZW1waGFzaXMoY2VsdF9zaWcgKmluW10sIG9wdXNfdmFsMTYgKnBjbSwgaW50IE4s IGludCBDLCBpbnQgZG93bnNhbXBsZSwgY29uc3Qgb3B1c192YWwxNiAqY29lZiwgY2VsdF9zaWcg Km1lbSkKIHsKLSAgIGNvbnN0IGludCBDID0gQ0hBTk5FTFMoX0MpOwogICAgaW50IGM7CiAgICBp bnQgY291bnQ9MDsKICAgIGM9MDsgZG8gewpAQCAtOTAyLDggKzg5OSw4IEBAIGludCBjZWx0X2Vu Y29kZV93aXRoX2VjKENFTFRFbmNvZGVyICogcmVzdHJpY3Qgc3QsIGNvbnN0IG9wdXNfdmFsMTYg KiBwY20sIGludCBmCiAgICBvcHVzX3ZhbDE2ICpvbGRCYW5kRSwgKm9sZExvZ0UsICpvbGRMb2dF MjsKICAgIGludCBzaG9ydEJsb2Nrcz0wOwogICAgaW50IGlzVHJhbnNpZW50PTA7Ci0gICBjb25z dCBpbnQgQ0MgPSBDSEFOTkVMUyhzdC0+Y2hhbm5lbHMpOwotICAgY29uc3QgaW50IEMgPSBDSEFO TkVMUyhzdC0+c3RyZWFtX2NoYW5uZWxzKTsKKyAgIGNvbnN0IGludCBDQyA9IHN0LT5jaGFubmVs czsKKyAgIGNvbnN0IGludCBDID0gc3QtPnN0cmVhbV9jaGFubmVsczsKICAgIGludCBMTSwgTTsK ICAgIGludCB0Zl9zZWxlY3Q7CiAgICBpbnQgbmJGaWxsZWRCeXRlcywgbmJBdmFpbGFibGVCeXRl czsKQEAgLTE2OTIsNyArMTY4OSw3IEBAIGludCBvcHVzX2N1c3RvbV9lbmNvZGVfZmxvYXQoQ0VM VEVuY29kZXIgKiByZXN0cmljdCBzdCwgY29uc3QgZmxvYXQgKiBwY20sIGludCBmCiAgICBpZiAo cGNtPT1OVUxMKQogICAgICAgcmV0dXJuIE9QVVNfQkFEX0FSRzsKIAotICAgQyA9IENIQU5ORUxT KHN0LT5jaGFubmVscyk7CisgICBDID0gc3QtPmNoYW5uZWxzOwogICAgTiA9IGZyYW1lX3NpemU7 CiAgICBBTExPQyhpbiwgQypOLCBvcHVzX2ludDE2KTsKIApAQCAtMTcxOSw3ICsxNzE2LDcgQEAg aW50IG9wdXNfY3VzdG9tX2VuY29kZShDRUxURW5jb2RlciAqIHJlc3RyaWN0IHN0LCBjb25zdCBv cHVzX2ludDE2ICogcGNtLCBpbnQgZnIKICAgIGlmIChwY209PU5VTEwpCiAgICAgICByZXR1cm4g T1BVU19CQURfQVJHOwogCi0gICBDPUNIQU5ORUxTKHN0LT5jaGFubmVscyk7CisgICBDPXN0LT5j aGFubmVsczsKICAgIE49ZnJhbWVfc2l6ZTsKICAgIEFMTE9DKGluLCBDKk4sIGNlbHRfc2lnKTsK ICAgIGZvciAoaj0wO2o8QypOO2orKykgewpAQCAtMjAxMyw3ICsyMDEwLDcgQEAgc3RhdGljIHZv aWQgY2VsdF9kZWNvZGVfbG9zdChDRUxURGVjb2RlciAqIHJlc3RyaWN0IHN0LCBvcHVzX3ZhbDE2 ICogcmVzdHJpY3QgcGMKICAgIGludCBvdmVybGFwID0gc3QtPm1vZGUtPm92ZXJsYXA7CiAgICBv cHVzX3ZhbDE2IGZhZGUgPSBRMTVPTkU7CiAgICBpbnQgaSwgbGVuOwotICAgY29uc3QgaW50IEMg PSBDSEFOTkVMUyhzdC0+Y2hhbm5lbHMpOworICAgY29uc3QgaW50IEMgPSBzdC0+Y2hhbm5lbHM7 CiAgICBpbnQgb2Zmc2V0OwogICAgY2VsdF9zaWcgKm91dF9tZW1bMl07CiAgICBjZWx0X3NpZyAq ZGVjb2RlX21lbVsyXTsKQEAgLTIyOTMsNyArMjI5MCw3IEBAIGludCBjZWx0X2RlY29kZV93aXRo X2VjKENFTFREZWNvZGVyICogcmVzdHJpY3Qgc3QsIGNvbnN0IHVuc2lnbmVkIGNoYXIgKmRhdGEs IGluCiAgICBpbnQgc2hvcnRCbG9ja3M7CiAgICBpbnQgaXNUcmFuc2llbnQ7CiAgICBpbnQgaW50 cmFfZW5lcjsKLSAgIGNvbnN0IGludCBDQyA9IENIQU5ORUxTKHN0LT5jaGFubmVscyk7CisgICBj b25zdCBpbnQgQ0MgPSBzdC0+Y2hhbm5lbHM7CiAgICBpbnQgTE0sIE07CiAgICBpbnQgZWZmRW5k OwogICAgaW50IGNvZGVkQmFuZHM7CkBAIC0yMzEwLDcgKzIzMDcsNyBAQCBpbnQgY2VsdF9kZWNv ZGVfd2l0aF9lYyhDRUxURGVjb2RlciAqIHJlc3RyaWN0IHN0LCBjb25zdCB1bnNpZ25lZCBjaGFy ICpkYXRhLCBpbgogICAgaW50IGFudGlfY29sbGFwc2VfcnN2OwogICAgaW50IGFudGlfY29sbGFw c2Vfb249MDsKICAgIGludCBzaWxlbmNlOwotICAgaW50IEMgPSBDSEFOTkVMUyhzdC0+c3RyZWFt X2NoYW5uZWxzKTsKKyAgIGludCBDID0gc3QtPnN0cmVhbV9jaGFubmVsczsKICAgIEFMTE9DX1NU QUNLOwogCiAgICBmcmFtZV9zaXplICo9IHN0LT5kb3duc2FtcGxlOwpAQCAtMjY2NCw3ICsyNjYx LDcgQEAgaW50IG9wdXNfY3VzdG9tX2RlY29kZV9mbG9hdChDRUxURGVjb2RlciAqIHJlc3RyaWN0 IHN0LCBjb25zdCB1bnNpZ25lZCBjaGFyICpkYXQKICAgIGlmIChwY209PU5VTEwpCiAgICAgICBy ZXR1cm4gT1BVU19CQURfQVJHOwogCi0gICBDID0gQ0hBTk5FTFMoc3QtPmNoYW5uZWxzKTsKKyAg IEMgPSBzdC0+Y2hhbm5lbHM7CiAgICBOID0gZnJhbWVfc2l6ZTsKIAogICAgQUxMT0Mob3V0LCBD Kk4sIG9wdXNfaW50MTYpOwpAQCAtMjY5NCw3ICsyNjkxLDcgQEAgaW50IG9wdXNfY3VzdG9tX2Rl Y29kZShDRUxURGVjb2RlciAqIHJlc3RyaWN0IHN0LCBjb25zdCB1bnNpZ25lZCBjaGFyICpkYXRh LCBpbnQKICAgIGlmIChwY209PU5VTEwpCiAgICAgICByZXR1cm4gT1BVU19CQURfQVJHOwogCi0g ICBDID0gQ0hBTk5FTFMoc3QtPmNoYW5uZWxzKTsKKyAgIEMgPSBzdC0+Y2hhbm5lbHM7CiAgICBO ID0gZnJhbWVfc2l6ZTsKICAgIEFMTE9DKG91dCwgQypOLCBjZWx0X3NpZyk7CiAKZGlmZiAtLWdp dCBhL2NlbHQvY2VsdC5oIGIvY2VsdC9jZWx0LmgKaW5kZXggN2ExMDYzYy4uMjM0YTE3YiAxMDA2 NDQKLS0tIGEvY2VsdC9jZWx0LmgKKysrIGIvY2VsdC9jZWx0LmgKQEAgLTExNCw0ICsxMTQsNCBA QCBpbnQgY2VsdF9kZWNvZGVfd2l0aF9lYyhPcHVzQ3VzdG9tRGVjb2RlciAqIHJlc3RyaWN0IHN0 LCBjb25zdCB1bnNpZ25lZCBjaGFyICpkYQogfQogI2VuZGlmCiAKLSNlbmRpZiAvKkNFTFRfSCAq LworI2VuZGlmIC8qIENFTFRfSCAqLwpkaWZmIC0tZ2l0IGEvY2VsdC9maXhlZF9kZWJ1Zy5oIGIv Y2VsdC9maXhlZF9kZWJ1Zy5oCmluZGV4IDJmMTlkMTAuLmJjZTAyOTYgMTAwNjQ0Ci0tLSBhL2Nl bHQvZml4ZWRfZGVidWcuaAorKysgYi9jZWx0L2ZpeGVkX2RlYnVnLmgKQEAgLTgzLDggKzgzLDgg QEAgc3RhdGljIGlubGluZSBpbnQgTkVHMzIobG9uZyBsb25nIHgpCiAgICByZXR1cm4gcmVzOwog fQogCi0jZGVmaW5lIEVYVFJBQ1QxNih4KSBfRVhUUkFDVDE2KHgsIF9fRklMRV9fLCBfX0xJTkVf XykKLXN0YXRpYyBpbmxpbmUgc2hvcnQgX0VYVFJBQ1QxNihpbnQgeCwgY2hhciAqZmlsZSwgaW50 IGxpbmUpCisjZGVmaW5lIEVYVFJBQ1QxNih4KSBFWFRSQUNUMTZfKHgsIF9fRklMRV9fLCBfX0xJ TkVfXykKK3N0YXRpYyBpbmxpbmUgc2hvcnQgRVhUUkFDVDE2XyhpbnQgeCwgY2hhciAqZmlsZSwg aW50IGxpbmUpCiB7CiAgICBpbnQgcmVzOwogICAgaWYgKCFWRVJJRllfU0hPUlQoeCkpCkBAIC05 Niw4ICs5Niw4IEBAIHN0YXRpYyBpbmxpbmUgc2hvcnQgX0VYVFJBQ1QxNihpbnQgeCwgY2hhciAq ZmlsZSwgaW50IGxpbmUpCiAgICByZXR1cm4gcmVzOwogfQogCi0jZGVmaW5lIEVYVEVORDMyKHgp IF9FWFRFTkQzMih4LCBfX0ZJTEVfXywgX19MSU5FX18pCi1zdGF0aWMgaW5saW5lIGludCBfRVhU RU5EMzIoaW50IHgsIGNoYXIgKmZpbGUsIGludCBsaW5lKQorI2RlZmluZSBFWFRFTkQzMih4KSBF WFRFTkQzMl8oeCwgX19GSUxFX18sIF9fTElORV9fKQorc3RhdGljIGlubGluZSBpbnQgRVhURU5E MzJfKGludCB4LCBjaGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgIGludCByZXM7CiAgICBpZiAo IVZFUklGWV9TSE9SVCh4KSkKQEAgLTEwOSw4ICsxMDksOCBAQCBzdGF0aWMgaW5saW5lIGludCBf RVhURU5EMzIoaW50IHgsIGNoYXIgKmZpbGUsIGludCBsaW5lKQogICAgcmV0dXJuIHJlczsKIH0K IAotI2RlZmluZSBTSFIxNihhLCBzaGlmdCkgX1NIUjE2KGEsIHNoaWZ0LCBfX0ZJTEVfXywgX19M SU5FX18pCi1zdGF0aWMgaW5saW5lIHNob3J0IF9TSFIxNihpbnQgYSwgaW50IHNoaWZ0LCBjaGFy ICpmaWxlLCBpbnQgbGluZSkKKyNkZWZpbmUgU0hSMTYoYSwgc2hpZnQpIFNIUjE2XyhhLCBzaGlm dCwgX19GSUxFX18sIF9fTElORV9fKQorc3RhdGljIGlubGluZSBzaG9ydCBTSFIxNl8oaW50IGEs IGludCBzaGlmdCwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICBpbnQgcmVzOwogICAgaWYg KCFWRVJJRllfU0hPUlQoYSkgfHwgIVZFUklGWV9TSE9SVChzaGlmdCkpCkBAIC0xMjMsOCArMTIz LDggQEAgc3RhdGljIGlubGluZSBzaG9ydCBfU0hSMTYoaW50IGEsIGludCBzaGlmdCwgY2hhciAq ZmlsZSwgaW50IGxpbmUpCiAgICBjZWx0X21pcHMrKzsKICAgIHJldHVybiByZXM7CiB9Ci0jZGVm aW5lIFNITDE2KGEsIHNoaWZ0KSBfU0hMMTYoYSwgc2hpZnQsIF9fRklMRV9fLCBfX0xJTkVfXykK LXN0YXRpYyBpbmxpbmUgc2hvcnQgX1NITDE2KGludCBhLCBpbnQgc2hpZnQsIGNoYXIgKmZpbGUs IGludCBsaW5lKQorI2RlZmluZSBTSEwxNihhLCBzaGlmdCkgU0hMMTZfKGEsIHNoaWZ0LCBfX0ZJ TEVfXywgX19MSU5FX18pCitzdGF0aWMgaW5saW5lIHNob3J0IFNITDE2XyhpbnQgYSwgaW50IHNo aWZ0LCBjaGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgIGludCByZXM7CiAgICBpZiAoIVZFUklG WV9TSE9SVChhKSB8fCAhVkVSSUZZX1NIT1JUKHNoaWZ0KSkKQEAgLTE3OSw4ICsxNzksOCBAQCBz dGF0aWMgaW5saW5lIGludCBTSEwzMihsb25nIGxvbmcgYSwgaW50IHNoaWZ0KQogLy8jZGVmaW5l IFNIUihhLHNoaWZ0KSAoKGEpID4+IChzaGlmdCkpCiAvLyNkZWZpbmUgU0hMKGEsc2hpZnQpICgo YSkgPDwgKHNoaWZ0KSkKIAotI2RlZmluZSBBREQxNihhLCBiKSBfQUREMTYoYSwgYiwgX19GSUxF X18sIF9fTElORV9fKQotc3RhdGljIGlubGluZSBzaG9ydCBfQUREMTYoaW50IGEsIGludCBiLCBj aGFyICpmaWxlLCBpbnQgbGluZSkKKyNkZWZpbmUgQUREMTYoYSwgYikgQUREMTZfKGEsIGIsIF9f RklMRV9fLCBfX0xJTkVfXykKK3N0YXRpYyBpbmxpbmUgc2hvcnQgQUREMTZfKGludCBhLCBpbnQg YiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICBpbnQgcmVzOwogICAgaWYgKCFWRVJJRllf U0hPUlQoYSkgfHwgIVZFUklGWV9TSE9SVChiKSkKQEAgLTE5Niw4ICsxOTYsOCBAQCBzdGF0aWMg aW5saW5lIHNob3J0IF9BREQxNihpbnQgYSwgaW50IGIsIGNoYXIgKmZpbGUsIGludCBsaW5lKQog ICAgcmV0dXJuIHJlczsKIH0KIAotI2RlZmluZSBTVUIxNihhLCBiKSBfU1VCMTYoYSwgYiwgX19G SUxFX18sIF9fTElORV9fKQotc3RhdGljIGlubGluZSBzaG9ydCBfU1VCMTYoaW50IGEsIGludCBi LCBjaGFyICpmaWxlLCBpbnQgbGluZSkKKyNkZWZpbmUgU1VCMTYoYSwgYikgU1VCMTZfKGEsIGIs IF9fRklMRV9fLCBfX0xJTkVfXykKK3N0YXRpYyBpbmxpbmUgc2hvcnQgU1VCMTZfKGludCBhLCBp bnQgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICBpbnQgcmVzOwogICAgaWYgKCFWRVJJ RllfU0hPUlQoYSkgfHwgIVZFUklGWV9TSE9SVChiKSkKQEAgLTIxMSw4ICsyMTEsOCBAQCBzdGF0 aWMgaW5saW5lIHNob3J0IF9TVUIxNihpbnQgYSwgaW50IGIsIGNoYXIgKmZpbGUsIGludCBsaW5l KQogICAgcmV0dXJuIHJlczsKIH0KIAotI2RlZmluZSBBREQzMihhLCBiKSBfQUREMzIoYSwgYiwg X19GSUxFX18sIF9fTElORV9fKQotc3RhdGljIGlubGluZSBpbnQgX0FERDMyKGxvbmcgbG9uZyBh LCBsb25nIGxvbmcgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCisjZGVmaW5lIEFERDMyKGEsIGIp IEFERDMyXyhhLCBiLCBfX0ZJTEVfXywgX19MSU5FX18pCitzdGF0aWMgaW5saW5lIGludCBBREQz Ml8obG9uZyBsb25nIGEsIGxvbmcgbG9uZyBiLCBjaGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAg IGxvbmcgbG9uZyByZXM7CiAgICBpZiAoIVZFUklGWV9JTlQoYSkgfHwgIVZFUklGWV9JTlQoYikp CkBAIC0yMjgsOCArMjI4LDggQEAgc3RhdGljIGlubGluZSBpbnQgX0FERDMyKGxvbmcgbG9uZyBh LCBsb25nIGxvbmcgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiAgICByZXR1cm4gcmVzOwogfQog Ci0jZGVmaW5lIFNVQjMyKGEsIGIpIF9TVUIzMihhLCBiLCBfX0ZJTEVfXywgX19MSU5FX18pCi1z dGF0aWMgaW5saW5lIGludCBfU1VCMzIobG9uZyBsb25nIGEsIGxvbmcgbG9uZyBiLCBjaGFyICpm aWxlLCBpbnQgbGluZSkKKyNkZWZpbmUgU1VCMzIoYSwgYikgU1VCMzJfKGEsIGIsIF9fRklMRV9f LCBfX0xJTkVfXykKK3N0YXRpYyBpbmxpbmUgaW50IFNVQjMyXyhsb25nIGxvbmcgYSwgbG9uZyBs b25nIGIsIGNoYXIgKmZpbGUsIGludCBsaW5lKQogewogICAgbG9uZyBsb25nIHJlczsKICAgIGlm ICghVkVSSUZZX0lOVChhKSB8fCAhVkVSSUZZX0lOVChiKSkKQEAgLTI0NCw4ICsyNDQsOCBAQCBz dGF0aWMgaW5saW5lIGludCBfU1VCMzIobG9uZyBsb25nIGEsIGxvbmcgbG9uZyBiLCBjaGFyICpm aWxlLCBpbnQgbGluZSkKIH0KIAogI3VuZGVmIFVBREQzMgotI2RlZmluZSBVQUREMzIoYSwgYikg X1VBREQzMihhLCBiLCBfX0ZJTEVfXywgX19MSU5FX18pCi1zdGF0aWMgaW5saW5lIHVuc2lnbmVk IGludCBfVUFERDMyKHVuc2lnbmVkIGxvbmcgbG9uZyBhLCB1bnNpZ25lZCBsb25nIGxvbmcgYiwg Y2hhciAqZmlsZSwgaW50IGxpbmUpCisjZGVmaW5lIFVBREQzMihhLCBiKSBVQUREMzJfKGEsIGIs IF9fRklMRV9fLCBfX0xJTkVfXykKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IFVBREQzMl8o dW5zaWduZWQgbG9uZyBsb25nIGEsIHVuc2lnbmVkIGxvbmcgbG9uZyBiLCBjaGFyICpmaWxlLCBp bnQgbGluZSkKIHsKICAgIGxvbmcgbG9uZyByZXM7CiAgICBpZiAoIVZFUklGWV9VSU5UKGEpIHx8 ICFWRVJJRllfVUlOVChiKSkKQEAgLTI2Miw4ICsyNjIsOCBAQCBzdGF0aWMgaW5saW5lIHVuc2ln bmVkIGludCBfVUFERDMyKHVuc2lnbmVkIGxvbmcgbG9uZyBhLCB1bnNpZ25lZCBsb25nIGxvbmcg YiwgYwogfQogCiAjdW5kZWYgVVNVQjMyCi0jZGVmaW5lIFVTVUIzMihhLCBiKSBfVVNVQjMyKGEs IGIsIF9fRklMRV9fLCBfX0xJTkVfXykKLXN0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IF9VU1VC MzIodW5zaWduZWQgbG9uZyBsb25nIGEsIHVuc2lnbmVkIGxvbmcgbG9uZyBiLCBjaGFyICpmaWxl LCBpbnQgbGluZSkKKyNkZWZpbmUgVVNVQjMyKGEsIGIpIFVTVUIzMl8oYSwgYiwgX19GSUxFX18s IF9fTElORV9fKQorc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgVVNVQjMyXyh1bnNpZ25lZCBs b25nIGxvbmcgYSwgdW5zaWduZWQgbG9uZyBsb25nIGIsIGNoYXIgKmZpbGUsIGludCBsaW5lKQog ewogICAgbG9uZyBsb25nIHJlczsKICAgIGlmICghVkVSSUZZX1VJTlQoYSkgfHwgIVZFUklGWV9V SU5UKGIpKQpAQCAtMjk0LDggKzI5NCw4IEBAIHN0YXRpYyBpbmxpbmUgc2hvcnQgTVVMVDE2XzE2 XzE2KGludCBhLCBpbnQgYikKICAgIHJldHVybiByZXM7CiB9CiAKLSNkZWZpbmUgTVVMVDE2XzE2 KGEsIGIpIF9NVUxUMTZfMTYoYSwgYiwgX19GSUxFX18sIF9fTElORV9fKQotc3RhdGljIGlubGlu ZSBpbnQgX01VTFQxNl8xNihpbnQgYSwgaW50IGIsIGNoYXIgKmZpbGUsIGludCBsaW5lKQorI2Rl ZmluZSBNVUxUMTZfMTYoYSwgYikgTVVMVDE2XzE2XyhhLCBiLCBfX0ZJTEVfXywgX19MSU5FX18p CitzdGF0aWMgaW5saW5lIGludCBNVUxUMTZfMTZfKGludCBhLCBpbnQgYiwgY2hhciAqZmlsZSwg aW50IGxpbmUpCiB7CiAgICBsb25nIGxvbmcgcmVzOwogICAgaWYgKCFWRVJJRllfU0hPUlQoYSkg fHwgIVZFUklGWV9TSE9SVChiKSkKQEAgLTMxMSw4ICszMTEsOCBAQCBzdGF0aWMgaW5saW5lIGlu dCBfTVVMVDE2XzE2KGludCBhLCBpbnQgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiAKICNkZWZp bmUgTUFDMTZfMTYoYyxhLGIpICAgICAoY2VsdF9taXBzLT0yLEFERDMyKChjKSxNVUxUMTZfMTYo KGEpLChiKSkpKQogCi0jZGVmaW5lIE1VTFQxNl8zMl9RWChhLCBiLCBRKSBfTVVMVDE2XzMyX1FY KGEsIGIsIFEsIF9fRklMRV9fLCBfX0xJTkVfXykKLXN0YXRpYyBpbmxpbmUgaW50IF9NVUxUMTZf MzJfUVgoaW50IGEsIGxvbmcgbG9uZyBiLCBpbnQgUSwgY2hhciAqZmlsZSwgaW50IGxpbmUpCisj ZGVmaW5lIE1VTFQxNl8zMl9RWChhLCBiLCBRKSBNVUxUMTZfMzJfUVhfKGEsIGIsIFEsIF9fRklM RV9fLCBfX0xJTkVfXykKK3N0YXRpYyBpbmxpbmUgaW50IE1VTFQxNl8zMl9RWF8oaW50IGEsIGxv bmcgbG9uZyBiLCBpbnQgUSwgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICBsb25nIGxvbmcg cmVzOwogICAgaWYgKCFWRVJJRllfU0hPUlQoYSkgfHwgIVZFUklGWV9JTlQoYikpCkBAIC0zODcs OCArMzg3LDggQEAgc3RhdGljIGlubGluZSBzaG9ydCBNVUxUMTZfMTZfUTE0KGludCBhLCBpbnQg YikKICAgIHJldHVybiByZXM7CiB9CiAKLSNkZWZpbmUgTVVMVDE2XzE2X1ExNShhLCBiKSBfTVVM VDE2XzE2X1ExNShhLCBiLCBfX0ZJTEVfXywgX19MSU5FX18pCi1zdGF0aWMgaW5saW5lIHNob3J0 IF9NVUxUMTZfMTZfUTE1KGludCBhLCBpbnQgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCisjZGVm aW5lIE1VTFQxNl8xNl9RMTUoYSwgYikgTVVMVDE2XzE2X1ExNV8oYSwgYiwgX19GSUxFX18sIF9f TElORV9fKQorc3RhdGljIGlubGluZSBzaG9ydCBNVUxUMTZfMTZfUTE1XyhpbnQgYSwgaW50IGIs IGNoYXIgKmZpbGUsIGludCBsaW5lKQogewogICAgbG9uZyBsb25nIHJlczsKICAgIGlmICghVkVS SUZZX1NIT1JUKGEpIHx8ICFWRVJJRllfU0hPUlQoYikpCkBAIC00NTcsOSArNDU3LDkgQEAgc3Rh dGljIGlubGluZSBzaG9ydCBNVUxUMTZfMTZfUDE1KGludCBhLCBpbnQgYikKICAgIHJldHVybiBy ZXM7CiB9CiAKLSNkZWZpbmUgRElWMzJfMTYoYSwgYikgX0RJVjMyXzE2KGEsIGIsIF9fRklMRV9f LCBfX0xJTkVfXykKKyNkZWZpbmUgRElWMzJfMTYoYSwgYikgRElWMzJfMTZfKGEsIGIsIF9fRklM RV9fLCBfX0xJTkVfXykKIAotc3RhdGljIGlubGluZSBpbnQgX0RJVjMyXzE2KGxvbmcgbG9uZyBh LCBsb25nIGxvbmcgYiwgY2hhciAqZmlsZSwgaW50IGxpbmUpCitzdGF0aWMgaW5saW5lIGludCBE SVYzMl8xNl8obG9uZyBsb25nIGEsIGxvbmcgbG9uZyBiLCBjaGFyICpmaWxlLCBpbnQgbGluZSkK IHsKICAgIGxvbmcgbG9uZyByZXM7CiAgICBpZiAoYj09MCkKQEAgLTQ4NCw4ICs0ODQsOCBAQCBz dGF0aWMgaW5saW5lIGludCBfRElWMzJfMTYobG9uZyBsb25nIGEsIGxvbmcgbG9uZyBiLCBjaGFy ICpmaWxlLCBpbnQgbGluZSkKICAgIHJldHVybiByZXM7CiB9CiAKLSNkZWZpbmUgRElWMzIoYSwg YikgX0RJVjMyKGEsIGIsIF9fRklMRV9fLCBfX0xJTkVfXykKLXN0YXRpYyBpbmxpbmUgaW50IF9E SVYzMihsb25nIGxvbmcgYSwgbG9uZyBsb25nIGIsIGNoYXIgKmZpbGUsIGludCBsaW5lKQorI2Rl ZmluZSBESVYzMihhLCBiKSBESVYzMl8oYSwgYiwgX19GSUxFX18sIF9fTElORV9fKQorc3RhdGlj IGlubGluZSBpbnQgRElWMzJfKGxvbmcgbG9uZyBhLCBsb25nIGxvbmcgYiwgY2hhciAqZmlsZSwg aW50IGxpbmUpCiB7CiAgICBsb25nIGxvbmcgcmVzOwogICAgaWYgKGI9PTApCmRpZmYgLS1naXQg YS9jZWx0L21vZGVzLmggYi9jZWx0L21vZGVzLmgKaW5kZXggYWZkNzFiMy4uODU4M2EzZSAxMDA2 NDQKLS0tIGEvY2VsdC9tb2Rlcy5oCisrKyBiL2NlbHQvbW9kZXMuaApAQCAtMzksMTQgKzM5LDYg QEAKIAogI2RlZmluZSBNQVhfUEVSSU9EIDEwMjQKIAotI2lmbmRlZiBDSEFOTkVMUwotIyBpZmRl ZiBESVNBQkxFX1NURVJFTwotIyAgZGVmaW5lIENIQU5ORUxTKF9DKSAoMSkKLSMgZWxzZQotIyAg ZGVmaW5lIENIQU5ORUxTKF9DKSAoX0MpCi0jIGVuZGlmCi0jZW5kaWYKLQogI2lmbmRlZiBPVkVS TEFQCiAjZGVmaW5lIE9WRVJMQVAobW9kZSkgKChtb2RlKS0+b3ZlcmxhcCkKICNlbmRpZgpkaWZm IC0tZ2l0IGEvY2VsdC9waXRjaC5jIGIvY2VsdC9waXRjaC5jCmluZGV4IDNiYzEwODQuLmI0MDc5 MDIgMTAwNjQ0Ci0tLSBhL2NlbHQvcGl0Y2guYworKysgYi9jZWx0L3BpdGNoLmMKQEAgLTk4LDEz ICs5OCwxMiBAQCBzdGF0aWMgdm9pZCBmaW5kX2Jlc3RfcGl0Y2gob3B1c192YWwzMiAqeGNvcnIs IG9wdXNfdmFsMTYgKnksIGludCBsZW4sCiB9CiAKIHZvaWQgcGl0Y2hfZG93bnNhbXBsZShjZWx0 X3NpZyAqIHJlc3RyaWN0IHhbXSwgb3B1c192YWwxNiAqIHJlc3RyaWN0IHhfbHAsCi0gICAgICBp bnQgbGVuLCBpbnQgX0MpCisgICAgICBpbnQgbGVuLCBpbnQgQykKIHsKICAgIGludCBpOwogICAg b3B1c192YWwzMiBhY1s1XTsKICAgIG9wdXNfdmFsMTYgdG1wPVExNU9ORTsKICAgIG9wdXNfdmFs MTYgbHBjWzRdLCBtZW1bNF09ezAsMCwwLDB9OwotICAgY29uc3QgaW50IEMgPSBDSEFOTkVMUyhf Qyk7CiAgICBmb3IgKGk9MTtpPGxlbj4+MTtpKyspCiAgICAgICB4X2xwW2ldID0gU0hSMzIoSEFM RjMyKEhBTEYzMih4WzBdWygyKmktMSldK3hbMF1bKDIqaSsxKV0pK3hbMF1bMippXSksIFNJR19T SElGVCszKTsKICAgIHhfbHBbMF0gPSBTSFIzMihIQUxGMzIoSEFMRjMyKHhbMF1bMV0pK3hbMF1b MF0pLCBTSUdfU0hJRlQrMyk7CkBAIC0yNTksNyArMjU4LDcgQEAgdm9pZCBwaXRjaF9zZWFyY2go Y29uc3Qgb3B1c192YWwxNiAqIHJlc3RyaWN0IHhfbHAsIG9wdXNfdmFsMTYgKiByZXN0cmljdCB5 LAogCiBzdGF0aWMgY29uc3QgaW50IHNlY29uZF9jaGVja1sxNl0gPSB7MCwgMCwgMywgMiwgMywg MiwgNSwgMiwgMywgMiwgMywgMiwgNSwgMiwgMywgMn07CiBvcHVzX3ZhbDE2IHJlbW92ZV9kb3Vi bGluZyhvcHVzX3ZhbDE2ICp4LCBpbnQgbWF4cGVyaW9kLCBpbnQgbWlucGVyaW9kLAotICAgICAg aW50IE4sIGludCAqX1QwLCBpbnQgcHJldl9wZXJpb2QsIG9wdXNfdmFsMTYgcHJldl9nYWluKQor ICAgICAgaW50IE4sIGludCAqVDBfLCBpbnQgcHJldl9wZXJpb2QsIG9wdXNfdmFsMTYgcHJldl9n YWluKQogewogICAgaW50IGssIGksIFQsIFQwOwogICAgb3B1c192YWwxNiBnLCBnMDsKQEAgLTI3 MywxNCArMjcyLDE0IEBAIG9wdXNfdmFsMTYgcmVtb3ZlX2RvdWJsaW5nKG9wdXNfdmFsMTYgKngs IGludCBtYXhwZXJpb2QsIGludCBtaW5wZXJpb2QsCiAgICBtaW5wZXJpb2QwID0gbWlucGVyaW9k OwogICAgbWF4cGVyaW9kIC89IDI7CiAgICBtaW5wZXJpb2QgLz0gMjsKLSAgICpfVDAgLz0gMjsK KyAgICpUMF8gLz0gMjsKICAgIHByZXZfcGVyaW9kIC89IDI7CiAgICBOIC89IDI7CiAgICB4ICs9 IG1heHBlcmlvZDsKLSAgIGlmICgqX1QwPj1tYXhwZXJpb2QpCi0gICAgICAqX1QwPW1heHBlcmlv ZC0xOworICAgaWYgKCpUMF8+PW1heHBlcmlvZCkKKyAgICAgICpUMF89bWF4cGVyaW9kLTE7CiAK LSAgIFQgPSBUMCA9ICpfVDA7CisgICBUID0gVDAgPSAqVDBfOwogICAgeHg9eHk9eXk9MDsKICAg IGZvciAoaT0wO2k8TjtpKyspCiAgICB7CkBAIC0zNzgsOSArMzc3LDkgQEAgb3B1c192YWwxNiBy ZW1vdmVfZG91Ymxpbmcob3B1c192YWwxNiAqeCwgaW50IG1heHBlcmlvZCwgaW50IG1pbnBlcmlv ZCwKICAgICAgIG9mZnNldCA9IDA7CiAgICBpZiAocGcgPiBnKQogICAgICAgcGcgPSBnOwotICAg Kl9UMCA9IDIqVCtvZmZzZXQ7CisgICAqVDBfID0gMipUK29mZnNldDsKIAotICAgaWYgKCpfVDA8 bWlucGVyaW9kMCkKLSAgICAgICpfVDA9bWlucGVyaW9kMDsKKyAgIGlmICgqVDBfPG1pbnBlcmlv ZDApCisgICAgICAqVDBfPW1pbnBlcmlvZDA7CiAgICByZXR1cm4gcGc7CiB9CmRpZmYgLS1naXQg YS9jZWx0L3BpdGNoLmggYi9jZWx0L3BpdGNoLmgKaW5kZXggYmRmYTRkMC4uZWRlMTA3MSAxMDA2 NDQKLS0tIGEvY2VsdC9waXRjaC5oCisrKyBiL2NlbHQvcGl0Y2guaApAQCAtMzEsMTMgKzMxLDEz IEBACiAgICBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRiBT VUNIIERBTUFHRS4KICovCiAKLSNpZm5kZWYgX1BJVENIX0gKLSNkZWZpbmUgX1BJVENIX0gKKyNp Zm5kZWYgUElUQ0hfSAorI2RlZmluZSBQSVRDSF9ICiAKICNpbmNsdWRlICJtb2Rlcy5oIgogCiB2 b2lkIHBpdGNoX2Rvd25zYW1wbGUoY2VsdF9zaWcgKiByZXN0cmljdCB4W10sIG9wdXNfdmFsMTYg KiByZXN0cmljdCB4X2xwLAotICAgICAgaW50IGxlbiwgaW50IF9DKTsKKyAgICAgIGludCBsZW4s IGludCBDKTsKIAogdm9pZCBwaXRjaF9zZWFyY2goY29uc3Qgb3B1c192YWwxNiAqIHJlc3RyaWN0 IHhfbHAsIG9wdXNfdmFsMTYgKiByZXN0cmljdCB5LAogICAgICAgICAgICAgICAgICAgaW50IGxl biwgaW50IG1heF9waXRjaCwgaW50ICpwaXRjaCk7CmRpZmYgLS1naXQgYS9jZWx0L3F1YW50X2Jh bmRzLmMgYi9jZWx0L3F1YW50X2JhbmRzLmMKaW5kZXggMWVmNjdkMC4uMDRhODE5ZSAxMDA2NDQK LS0tIGEvY2VsdC9xdWFudF9iYW5kcy5jCisrKyBiL2NlbHQvcXVhbnRfYmFuZHMuYwpAQCAtMTU3 LDkgKzE1Nyw4IEBAIHN0YXRpYyBpbnQgcXVhbnRfY29hcnNlX2VuZXJneV9pbXBsKGNvbnN0IENF TFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQsCiAgICAgICBjb25zdCBvcHVzX3ZhbDE2ICpl QmFuZHMsIG9wdXNfdmFsMTYgKm9sZEVCYW5kcywKICAgICAgIG9wdXNfaW50MzIgYnVkZ2V0LCBv cHVzX2ludDMyIHRlbGwsCiAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICpwcm9iX21vZGVsLCBv cHVzX3ZhbDE2ICplcnJvciwgZWNfZW5jICplbmMsCi0gICAgICBpbnQgX0MsIGludCBMTSwgaW50 IGludHJhLCBvcHVzX3ZhbDE2IG1heF9kZWNheSkKKyAgICAgIGludCBDLCBpbnQgTE0sIGludCBp bnRyYSwgb3B1c192YWwxNiBtYXhfZGVjYXkpCiB7Ci0gICBjb25zdCBpbnQgQyA9IENIQU5ORUxT KF9DKTsKICAgIGludCBpLCBjOwogICAgaW50IGJhZG5lc3MgPSAwOwogICAgb3B1c192YWwzMiBw cmV2WzJdID0gezAsMH07CkBAIC0yNTksMTAgKzI1OCw5IEBAIHN0YXRpYyBpbnQgcXVhbnRfY29h cnNlX2VuZXJneV9pbXBsKGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQsCiAK IHZvaWQgcXVhbnRfY29hcnNlX2VuZXJneShjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBp bnQgZW5kLCBpbnQgZWZmRW5kLAogICAgICAgY29uc3Qgb3B1c192YWwxNiAqZUJhbmRzLCBvcHVz X3ZhbDE2ICpvbGRFQmFuZHMsIG9wdXNfdWludDMyIGJ1ZGdldCwKLSAgICAgIG9wdXNfdmFsMTYg KmVycm9yLCBlY19lbmMgKmVuYywgaW50IF9DLCBpbnQgTE0sIGludCBuYkF2YWlsYWJsZUJ5dGVz LAorICAgICAgb3B1c192YWwxNiAqZXJyb3IsIGVjX2VuYyAqZW5jLCBpbnQgQywgaW50IExNLCBp bnQgbmJBdmFpbGFibGVCeXRlcywKICAgICAgIGludCBmb3JjZV9pbnRyYSwgb3B1c192YWwzMiAq ZGVsYXllZEludHJhLCBpbnQgdHdvX3Bhc3MsIGludCBsb3NzX3JhdGUpCiB7Ci0gICBjb25zdCBp bnQgQyA9IENIQU5ORUxTKF9DKTsKICAgIGludCBpbnRyYTsKICAgIG9wdXNfdmFsMTYgbWF4X2Rl Y2F5OwogICAgVkFSREVDTChvcHVzX3ZhbDE2LCBvbGRFQmFuZHNfaW50cmEpOwpAQCAtMzUyLDEw ICszNTAsOSBAQCB2b2lkIHF1YW50X2NvYXJzZV9lbmVyZ3koY29uc3QgQ0VMVE1vZGUgKm0sIGlu dCBzdGFydCwgaW50IGVuZCwgaW50IGVmZkVuZCwKICAgIFJFU1RPUkVfU1RBQ0s7CiB9CiAKLXZv aWQgcXVhbnRfZmluZV9lbmVyZ3koY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVu ZCwgb3B1c192YWwxNiAqb2xkRUJhbmRzLCBvcHVzX3ZhbDE2ICplcnJvciwgaW50ICpmaW5lX3F1 YW50LCBlY19lbmMgKmVuYywgaW50IF9DKQordm9pZCBxdWFudF9maW5lX2VuZXJneShjb25zdCBD RUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpvbGRFQmFuZHMsIG9w dXNfdmFsMTYgKmVycm9yLCBpbnQgKmZpbmVfcXVhbnQsIGVjX2VuYyAqZW5jLCBpbnQgQykKIHsK ICAgIGludCBpLCBjOwotICAgY29uc3QgaW50IEMgPSBDSEFOTkVMUyhfQyk7CiAKICAgIC8qIEVu Y29kZSBmaW5lciByZXNvbHV0aW9uICovCiAgICBmb3IgKGk9c3RhcnQ7aTxlbmQ7aSsrKQpAQCAt MzkwLDEwICszODcsOSBAQCB2b2lkIHF1YW50X2ZpbmVfZW5lcmd5KGNvbnN0IENFTFRNb2RlICpt LCBpbnQgc3RhcnQsIGludCBlbmQsIG9wdXNfdmFsMTYgKm9sZEVCYQogICAgfQogfQogCi12b2lk IHF1YW50X2VuZXJneV9maW5hbGlzZShjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQg ZW5kLCBvcHVzX3ZhbDE2ICpvbGRFQmFuZHMsIG9wdXNfdmFsMTYgKmVycm9yLCBpbnQgKmZpbmVf cXVhbnQsIGludCAqZmluZV9wcmlvcml0eSwgaW50IGJpdHNfbGVmdCwgZWNfZW5jICplbmMsIGlu dCBfQykKK3ZvaWQgcXVhbnRfZW5lcmd5X2ZpbmFsaXNlKGNvbnN0IENFTFRNb2RlICptLCBpbnQg c3RhcnQsIGludCBlbmQsIG9wdXNfdmFsMTYgKm9sZEVCYW5kcywgb3B1c192YWwxNiAqZXJyb3Is IGludCAqZmluZV9xdWFudCwgaW50ICpmaW5lX3ByaW9yaXR5LCBpbnQgYml0c19sZWZ0LCBlY19l bmMgKmVuYywgaW50IEMpCiB7CiAgICBpbnQgaSwgcHJpbywgYzsKLSAgIGNvbnN0IGludCBDID0g Q0hBTk5FTFMoX0MpOwogCiAgICAvKiBVc2UgdXAgdGhlIHJlbWFpbmluZyBiaXRzICovCiAgICBm b3IgKHByaW89MDtwcmlvPDI7cHJpbysrKQpAQCAtNDIwLDE0ICs0MTYsMTMgQEAgdm9pZCBxdWFu dF9lbmVyZ3lfZmluYWxpc2UoY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwg b3B1c192YWwxNiAqb2wKICAgIH0KIH0KIAotdm9pZCB1bnF1YW50X2NvYXJzZV9lbmVyZ3koY29u c3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRz LCBpbnQgaW50cmEsIGVjX2RlYyAqZGVjLCBpbnQgX0MsIGludCBMTSkKK3ZvaWQgdW5xdWFudF9j b2Fyc2VfZW5lcmd5KGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQsIG9wdXNf dmFsMTYgKm9sZEVCYW5kcywgaW50IGludHJhLCBlY19kZWMgKmRlYywgaW50IEMsIGludCBMTSkK IHsKICAgIGNvbnN0IHVuc2lnbmVkIGNoYXIgKnByb2JfbW9kZWwgPSBlX3Byb2JfbW9kZWxbTE1d W2ludHJhXTsKICAgIGludCBpLCBjOwogICAgb3B1c192YWwzMiBwcmV2WzJdID0gezAsIDB9Owog ICAgb3B1c192YWwxNiBjb2VmOwogICAgb3B1c192YWwxNiBiZXRhOwotICAgY29uc3QgaW50IEMg PSBDSEFOTkVMUyhfQyk7CiAgICBvcHVzX2ludDMyIGJ1ZGdldDsKICAgIG9wdXNfaW50MzIgdGVs bDsKIApAQCAtNDg2LDEwICs0ODEsOSBAQCB2b2lkIHVucXVhbnRfY29hcnNlX2VuZXJneShjb25z dCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpvbAogICAgfQog fQogCi12b2lkIHVucXVhbnRfZmluZV9lbmVyZ3koY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFy dCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRzLCBpbnQgKmZpbmVfcXVhbnQsIGVjX2Rl YyAqZGVjLCBpbnQgX0MpCit2b2lkIHVucXVhbnRfZmluZV9lbmVyZ3koY29uc3QgQ0VMVE1vZGUg Km0sIGludCBzdGFydCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRzLCBpbnQgKmZpbmVf cXVhbnQsIGVjX2RlYyAqZGVjLCBpbnQgQykKIHsKICAgIGludCBpLCBjOwotICAgY29uc3QgaW50 IEMgPSBDSEFOTkVMUyhfQyk7CiAgICAvKiBEZWNvZGUgZmluZXIgcmVzb2x1dGlvbiAqLwogICAg Zm9yIChpPXN0YXJ0O2k8ZW5kO2krKykKICAgIHsKQEAgLTUxMCwxMCArNTA0LDkgQEAgdm9pZCB1 bnF1YW50X2ZpbmVfZW5lcmd5KGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQs IG9wdXNfdmFsMTYgKm9sZEUKICAgIH0KIH0KIAotdm9pZCB1bnF1YW50X2VuZXJneV9maW5hbGlz ZShjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpvbGRF QmFuZHMsIGludCAqZmluZV9xdWFudCwgIGludCAqZmluZV9wcmlvcml0eSwgaW50IGJpdHNfbGVm dCwgZWNfZGVjICpkZWMsIGludCBfQykKK3ZvaWQgdW5xdWFudF9lbmVyZ3lfZmluYWxpc2UoY29u c3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRz LCBpbnQgKmZpbmVfcXVhbnQsICBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBiaXRzX2xlZnQsIGVj X2RlYyAqZGVjLCBpbnQgQykKIHsKICAgIGludCBpLCBwcmlvLCBjOwotICAgY29uc3QgaW50IEMg PSBDSEFOTkVMUyhfQyk7CiAKICAgIC8qIFVzZSB1cCB0aGUgcmVtYWluaW5nIGJpdHMgKi8KICAg IGZvciAocHJpbz0wO3ByaW88MjtwcmlvKyspCkBAIC01NDAsMTAgKzUzMyw5IEBAIHZvaWQgdW5x dWFudF9lbmVyZ3lfZmluYWxpc2UoY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVu ZCwgb3B1c192YWwxNiAqCiB9CiAKIHZvaWQgbG9nMkFtcChjb25zdCBDRUxUTW9kZSAqbSwgaW50 IHN0YXJ0LCBpbnQgZW5kLAotICAgICAgY2VsdF9lbmVyICplQmFuZHMsIGNvbnN0IG9wdXNfdmFs MTYgKm9sZEVCYW5kcywgaW50IF9DKQorICAgICAgY2VsdF9lbmVyICplQmFuZHMsIGNvbnN0IG9w dXNfdmFsMTYgKm9sZEVCYW5kcywgaW50IEMpCiB7CiAgICBpbnQgYywgaTsKLSAgIGNvbnN0IGlu dCBDID0gQ0hBTk5FTFMoX0MpOwogICAgYz0wOwogICAgZG8gewogICAgICAgZm9yIChpPTA7aTxz dGFydDtpKyspCkBAIC01NjAsMTAgKzU1Miw5IEBAIHZvaWQgbG9nMkFtcChjb25zdCBDRUxUTW9k ZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLAogfQogCiB2b2lkIGFtcDJMb2cyKGNvbnN0IENFTFRN b2RlICptLCBpbnQgZWZmRW5kLCBpbnQgZW5kLAotICAgICAgY2VsdF9lbmVyICpiYW5kRSwgb3B1 c192YWwxNiAqYmFuZExvZ0UsIGludCBfQykKKyAgICAgIGNlbHRfZW5lciAqYmFuZEUsIG9wdXNf dmFsMTYgKmJhbmRMb2dFLCBpbnQgQykKIHsKICAgIGludCBjLCBpOwotICAgY29uc3QgaW50IEMg PSBDSEFOTkVMUyhfQyk7CiAgICBjPTA7CiAgICBkbyB7CiAgICAgICBmb3IgKGk9MDtpPGVmZkVu ZDtpKyspCmRpZmYgLS1naXQgYS9jZWx0L3F1YW50X2JhbmRzLmggYi9jZWx0L3F1YW50X2JhbmRz LmgKaW5kZXggNDRjMDhkZS4uYjkxM2UwYiAxMDA2NDQKLS0tIGEvY2VsdC9xdWFudF9iYW5kcy5o CisrKyBiL2NlbHQvcXVhbnRfYmFuZHMuaApAQCAtMzYsMjUgKzM2LDI1IEBACiAjaW5jbHVkZSAi bWF0aG9wcy5oIgogCiB2b2lkIGFtcDJMb2cyKGNvbnN0IENFTFRNb2RlICptLCBpbnQgZWZmRW5k LCBpbnQgZW5kLAotICAgICAgY2VsdF9lbmVyICpiYW5kRSwgb3B1c192YWwxNiAqYmFuZExvZ0Us IGludCBfQyk7CisgICAgICBjZWx0X2VuZXIgKmJhbmRFLCBvcHVzX3ZhbDE2ICpiYW5kTG9nRSwg aW50IEMpOwogCiB2b2lkIGxvZzJBbXAoY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50 IGVuZCwKLSAgICAgIGNlbHRfZW5lciAqZUJhbmRzLCBjb25zdCBvcHVzX3ZhbDE2ICpvbGRFQmFu ZHMsIGludCBfQyk7CisgICAgICBjZWx0X2VuZXIgKmVCYW5kcywgY29uc3Qgb3B1c192YWwxNiAq b2xkRUJhbmRzLCBpbnQgQyk7CiAKIHZvaWQgcXVhbnRfY29hcnNlX2VuZXJneShjb25zdCBDRUxU TW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBpbnQgZWZmRW5kLAogICAgICAgY29uc3Qgb3B1 c192YWwxNiAqZUJhbmRzLCBvcHVzX3ZhbDE2ICpvbGRFQmFuZHMsIG9wdXNfdWludDMyIGJ1ZGdl dCwKLSAgICAgIG9wdXNfdmFsMTYgKmVycm9yLCBlY19lbmMgKmVuYywgaW50IF9DLCBpbnQgTE0s CisgICAgICBvcHVzX3ZhbDE2ICplcnJvciwgZWNfZW5jICplbmMsIGludCBDLCBpbnQgTE0sCiAg ICAgICBpbnQgbmJBdmFpbGFibGVCeXRlcywgaW50IGZvcmNlX2ludHJhLCBvcHVzX3ZhbDMyICpk ZWxheWVkSW50cmEsCiAgICAgICBpbnQgdHdvX3Bhc3MsIGludCBsb3NzX3JhdGUpOwogCi12b2lk IHF1YW50X2ZpbmVfZW5lcmd5KGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQs IG9wdXNfdmFsMTYgKm9sZEVCYW5kcywgb3B1c192YWwxNiAqZXJyb3IsIGludCAqZmluZV9xdWFu dCwgZWNfZW5jICplbmMsIGludCBfQyk7Cit2b2lkIHF1YW50X2ZpbmVfZW5lcmd5KGNvbnN0IENF TFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQsIG9wdXNfdmFsMTYgKm9sZEVCYW5kcywgb3B1 c192YWwxNiAqZXJyb3IsIGludCAqZmluZV9xdWFudCwgZWNfZW5jICplbmMsIGludCBDKTsKIAot dm9pZCBxdWFudF9lbmVyZ3lfZmluYWxpc2UoY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwg aW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRzLCBvcHVzX3ZhbDE2ICplcnJvciwgaW50ICpm aW5lX3F1YW50LCBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBiaXRzX2xlZnQsIGVjX2VuYyAqZW5j LCBpbnQgX0MpOwordm9pZCBxdWFudF9lbmVyZ3lfZmluYWxpc2UoY29uc3QgQ0VMVE1vZGUgKm0s IGludCBzdGFydCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRzLCBvcHVzX3ZhbDE2ICpl cnJvciwgaW50ICpmaW5lX3F1YW50LCBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBiaXRzX2xlZnQs IGVjX2VuYyAqZW5jLCBpbnQgQyk7CiAKLXZvaWQgdW5xdWFudF9jb2Fyc2VfZW5lcmd5KGNvbnN0 IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQsIG9wdXNfdmFsMTYgKm9sZEVCYW5kcywg aW50IGludHJhLCBlY19kZWMgKmRlYywgaW50IF9DLCBpbnQgTE0pOwordm9pZCB1bnF1YW50X2Nv YXJzZV9lbmVyZ3koY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwgb3B1c192 YWwxNiAqb2xkRUJhbmRzLCBpbnQgaW50cmEsIGVjX2RlYyAqZGVjLCBpbnQgQywgaW50IExNKTsK IAotdm9pZCB1bnF1YW50X2ZpbmVfZW5lcmd5KGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQs IGludCBlbmQsIG9wdXNfdmFsMTYgKm9sZEVCYW5kcywgaW50ICpmaW5lX3F1YW50LCBlY19kZWMg KmRlYywgaW50IF9DKTsKK3ZvaWQgdW5xdWFudF9maW5lX2VuZXJneShjb25zdCBDRUxUTW9kZSAq bSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpvbGRFQmFuZHMsIGludCAqZmluZV9x dWFudCwgZWNfZGVjICpkZWMsIGludCBDKTsKIAotdm9pZCB1bnF1YW50X2VuZXJneV9maW5hbGlz ZShjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0LCBpbnQgZW5kLCBvcHVzX3ZhbDE2ICpvbGRF QmFuZHMsIGludCAqZmluZV9xdWFudCwgaW50ICpmaW5lX3ByaW9yaXR5LCBpbnQgYml0c19sZWZ0 LCBlY19kZWMgKmRlYywgaW50IF9DKTsKK3ZvaWQgdW5xdWFudF9lbmVyZ3lfZmluYWxpc2UoY29u c3QgQ0VMVE1vZGUgKm0sIGludCBzdGFydCwgaW50IGVuZCwgb3B1c192YWwxNiAqb2xkRUJhbmRz LCBpbnQgKmZpbmVfcXVhbnQsIGludCAqZmluZV9wcmlvcml0eSwgaW50IGJpdHNfbGVmdCwgZWNf ZGVjICpkZWMsIGludCBDKTsKIAogI2VuZGlmIC8qIFFVQU5UX0JBTkRTICovCmRpZmYgLS1naXQg YS9jZWx0L3JhdGUuYyBiL2NlbHQvcmF0ZS5jCmluZGV4IGMxYWQ2OTAuLmIzOWE5NDQgMTAwNjQ0 Ci0tLSBhL2NlbHQvcmF0ZS5jCisrKyBiL2NlbHQvcmF0ZS5jCkBAIC0yNDgsMTMgKzI0OCwxMiBA QCB2b2lkIGNvbXB1dGVfcHVsc2VfY2FjaGUoQ0VMVE1vZGUgKm0sIGludCBMTSkKIHN0YXRpYyBp bmxpbmUgaW50IGludGVycF9iaXRzMnB1bHNlcyhjb25zdCBDRUxUTW9kZSAqbSwgaW50IHN0YXJ0 LCBpbnQgZW5kLCBpbnQgc2tpcF9zdGFydCwKICAgICAgIGNvbnN0IGludCAqYml0czEsIGNvbnN0 IGludCAqYml0czIsIGNvbnN0IGludCAqdGhyZXNoLCBjb25zdCBpbnQgKmNhcCwgb3B1c19pbnQz MiB0b3RhbCwgb3B1c19pbnQzMiAqX2JhbGFuY2UsCiAgICAgICBpbnQgc2tpcF9yc3YsIGludCAq aW50ZW5zaXR5LCBpbnQgaW50ZW5zaXR5X3JzdiwgaW50ICpkdWFsX3N0ZXJlbywgaW50IGR1YWxf c3RlcmVvX3JzdiwgaW50ICpiaXRzLAotICAgICAgaW50ICplYml0cywgaW50ICpmaW5lX3ByaW9y aXR5LCBpbnQgX0MsIGludCBMTSwgZWNfY3R4ICplYywgaW50IGVuY29kZSwgaW50IHByZXYpCisg ICAgICBpbnQgKmViaXRzLCBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBDLCBpbnQgTE0sIGVjX2N0 eCAqZWMsIGludCBlbmNvZGUsIGludCBwcmV2KQogewogICAgb3B1c19pbnQzMiBwc3VtOwogICAg aW50IGxvLCBoaTsKICAgIGludCBpLCBqOwogICAgaW50IGxvZ007Ci0gICBjb25zdCBpbnQgQyA9 IENIQU5ORUxTKF9DKTsKICAgIGludCBzdGVyZW87CiAgICBpbnQgY29kZWRCYW5kcz0tMTsKICAg IGludCBhbGxvY19mbG9vcjsKQEAgLTUyNSwxMCArNTI0LDkgQEAgc3RhdGljIGlubGluZSBpbnQg aW50ZXJwX2JpdHMycHVsc2VzKGNvbnN0IENFTFRNb2RlICptLCBpbnQgc3RhcnQsIGludCBlbmQs IGludAogfQogCiBpbnQgY29tcHV0ZV9hbGxvY2F0aW9uKGNvbnN0IENFTFRNb2RlICptLCBpbnQg c3RhcnQsIGludCBlbmQsIGNvbnN0IGludCAqb2Zmc2V0cywgY29uc3QgaW50ICpjYXAsIGludCBh bGxvY190cmltLCBpbnQgKmludGVuc2l0eSwgaW50ICpkdWFsX3N0ZXJlbywKLSAgICAgIG9wdXNf aW50MzIgdG90YWwsIG9wdXNfaW50MzIgKmJhbGFuY2UsIGludCAqcHVsc2VzLCBpbnQgKmViaXRz LCBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBfQywgaW50IExNLCBlY19jdHggKmVjLCBpbnQgZW5j b2RlLCBpbnQgcHJldikKKyAgICAgIG9wdXNfaW50MzIgdG90YWwsIG9wdXNfaW50MzIgKmJhbGFu Y2UsIGludCAqcHVsc2VzLCBpbnQgKmViaXRzLCBpbnQgKmZpbmVfcHJpb3JpdHksIGludCBDLCBp bnQgTE0sIGVjX2N0eCAqZWMsIGludCBlbmNvZGUsIGludCBwcmV2KQogewogICAgaW50IGxvLCBo aSwgbGVuLCBqOwotICAgY29uc3QgaW50IEMgPSBDSEFOTkVMUyhfQyk7CiAgICBpbnQgY29kZWRC YW5kczsKICAgIGludCBza2lwX3N0YXJ0OwogICAgaW50IHNraXBfcnN2OwpkaWZmIC0tZ2l0IGEv Y2VsdC9yYXRlLmggYi9jZWx0L3JhdGUuaAppbmRleCBkMTlkMGIzLi4zMGMzY2MxIDEwMDY0NAot LS0gYS9jZWx0L3JhdGUuaAorKysgYi9jZWx0L3JhdGUuaApAQCAtOTYsNiArOTYsNiBAQCBzdGF0 aWMgaW5saW5lIGludCBwdWxzZXMyYml0cyhjb25zdCBDRUxUTW9kZSAqbSwgaW50IGJhbmQsIGlu dCBMTSwgaW50IHB1bHNlcykKICBAcmV0dXJuIFRvdGFsIG51bWJlciBvZiBiaXRzIGFsbG9jYXRl ZAogKi8KIGludCBjb21wdXRlX2FsbG9jYXRpb24oY29uc3QgQ0VMVE1vZGUgKm0sIGludCBzdGFy dCwgaW50IGVuZCwgY29uc3QgaW50ICpvZmZzZXRzLCBjb25zdCBpbnQgKmNhcCwgaW50IGFsbG9j X3RyaW0sIGludCAqaW50ZW5zaXR5LCBpbnQgKmR1YWxfc3Rlcm8sCi0gICAgICBvcHVzX2ludDMy IHRvdGFsLCBvcHVzX2ludDMyICpiYWxhbmNlLCBpbnQgKnB1bHNlcywgaW50ICplYml0cywgaW50 ICpmaW5lX3ByaW9yaXR5LCBpbnQgX0MsIGludCBMTSwgZWNfY3R4ICplYywgaW50IGVuY29kZSwg aW50IHByZXYpOworICAgICAgb3B1c19pbnQzMiB0b3RhbCwgb3B1c19pbnQzMiAqYmFsYW5jZSwg aW50ICpwdWxzZXMsIGludCAqZWJpdHMsIGludCAqZmluZV9wcmlvcml0eSwgaW50IEMsIGludCBM TSwgZWNfY3R4ICplYywgaW50IGVuY29kZSwgaW50IHByZXYpOwogCiAjZW5kaWYKZGlmZiAtLWdp dCBhL2NlbHQvc3RhY2tfYWxsb2MuaCBiL2NlbHQvc3RhY2tfYWxsb2MuaAppbmRleCA1MTJmNTI5 Li5iZTAxZTIwIDEwMDY0NAotLS0gYS9jZWx0L3N0YWNrX2FsbG9jLmgKKysrIGIvY2VsdC9zdGFj a19hbGxvYy5oCkBAIC0xMDksNyArMTA5LDcgQEAKIGNoYXIgKmdsb2JhbF9zdGFjaz0wOwogI2Vs c2UKIGV4dGVybiBjaGFyICpnbG9iYWxfc3RhY2s7Ci0jZW5kaWYgLypDRUxUX0MqLworI2VuZGlm IC8qIENFTFRfQyAqLwogCiAjaWZkZWYgRU5BQkxFX1ZBTEdSSU5ECiAKQEAgLTExOSw3ICsxMTks NyBAQCBleHRlcm4gY2hhciAqZ2xvYmFsX3N0YWNrOwogY2hhciAqZ2xvYmFsX3N0YWNrX3RvcD0w OwogI2Vsc2UKIGV4dGVybiBjaGFyICpnbG9iYWxfc3RhY2tfdG9wOwotI2VuZGlmIC8qQ0VMVF9D Ki8KKyNlbmRpZiAvKiBDRUxUX0MgKi8KIAogI2RlZmluZSBBTElHTihzdGFjaywgc2l6ZSkgKChz dGFjaykgKz0gKChzaXplKSAtIChsb25nKShzdGFjaykpICYgKChzaXplKSAtIDEpKQogI2RlZmlu ZSBQVVNIKHN0YWNrLCBzaXplLCB0eXBlKSAoVkFMR1JJTkRfTUFLRV9NRU1fTk9BQ0NFU1Moc3Rh Y2ssIGdsb2JhbF9zdGFja190b3Atc3RhY2spLEFMSUdOKChzdGFjayksc2l6ZW9mKHR5cGUpL3Np emVvZihjaGFyKSksVkFMR1JJTkRfTUFLRV9NRU1fVU5ERUZJTkVEKHN0YWNrLCAoKHNpemUpKnNp emVvZih0eXBlKS9zaXplb2YoY2hhcikpKSwoc3RhY2spKz0oMiooc2l6ZSkqc2l6ZW9mKHR5cGUp L3NpemVvZihjaGFyKSksKHR5cGUqKSgoc3RhY2spLSgyKihzaXplKSpzaXplb2YodHlwZSkvc2l6 ZW9mKGNoYXIpKSkpCkBAIC0xMzMsMTMgKzEzMywxMyBAQCBleHRlcm4gY2hhciAqZ2xvYmFsX3N0 YWNrX3RvcDsKICNkZWZpbmUgUkVTVE9SRV9TVEFDSyAoZ2xvYmFsX3N0YWNrID0gX3NhdmVkX3N0 YWNrKQogI2RlZmluZSBBTExPQ19TVEFDSyBjaGFyICpfc2F2ZWRfc3RhY2s7IChnbG9iYWxfc3Rh Y2sgPSAoZ2xvYmFsX3N0YWNrPT0wKSA/IG9wdXNfYWxsb2Nfc2NyYXRjaChHTE9CQUxfU1RBQ0tf U0laRSkgOiBnbG9iYWxfc3RhY2spOyBfc2F2ZWRfc3RhY2sgPSBnbG9iYWxfc3RhY2s7CiAKLSNl bmRpZiAvKkVOQUJMRV9WQUxHUklORCovCisjZW5kaWYgLyogRU5BQkxFX1ZBTEdSSU5EICovCiAK ICNpbmNsdWRlICJvc19zdXBwb3J0LmgiCiAjZGVmaW5lIFZBUkRFQ0wodHlwZSwgdmFyKSB0eXBl ICp2YXIKICNkZWZpbmUgQUxMT0ModmFyLCBzaXplLCB0eXBlKSB2YXIgPSBQVVNIKGdsb2JhbF9z dGFjaywgc2l6ZSwgdHlwZSkKICNkZWZpbmUgU0FWRV9TVEFDSyBjaGFyICpfc2F2ZWRfc3RhY2sg PSBnbG9iYWxfc3RhY2s7CiAKLSNlbmRpZiAvKlZBUl9BUlJBWVMqLworI2VuZGlmIC8qIFZBUl9B UlJBWVMgKi8KIAotI2VuZGlmIC8qU1RBQ0tfQUxMT0NfSCovCisjZW5kaWYgLyogU1RBQ0tfQUxM T0NfSCAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9vcHVzX3R5cGVzLmggYi9pbmNsdWRlL29wdXNf dHlwZXMuaAppbmRleCBhZDBiOWRkLi5iMDAxZWI0IDEwMDY0NAotLS0gYS9pbmNsdWRlL29wdXNf dHlwZXMuaAorKysgYi9pbmNsdWRlL29wdXNfdHlwZXMuaApAQCAtMzAsOCArMzAsOCBAQAogICAg QGZpbGUgb3B1c190eXBlcy5oCiAgICBAYnJpZWYgT3B1cyByZWZlcmVuY2UgaW1wbGVtZW50YXRp b24gdHlwZXMKICovCi0jaWZuZGVmIF9PUFVTX1RZUEVTX0gKLSNkZWZpbmUgX09QVVNfVFlQRVNf SAorI2lmbmRlZiBPUFVTX1RZUEVTX0gKKyNkZWZpbmUgT1BVU19UWVBFU19ICiAKIC8qIFVzZSB0 aGUgcmVhbCBzdGRpbnQuaCBpZiBpdCdzIHRoZXJlICh0YWtlbiBmcm9tIFBhdWwgSHNpZWgncyBw c3RkaW50LmgpICovCiAjaWYgKGRlZmluZWQoX19TVERDX18pICYmIF9fU1REQ19fICYmIF9fU1RE Q19WRVJTSU9OX18gPj0gMTk5OTAxTCkgfHwgKGRlZmluZWQoX19HTlVDX18pICYmIChkZWZpbmVk KF9TVERJTlRfSCkgfHwgZGVmaW5lZChfU1RESU5UX0hfKSkgfHwgZGVmaW5lZCAoSEFWRV9TVERJ TlRfSCkpCkBAIC0xNTYsNCArMTU2LDQgQEAKICNkZWZpbmUgb3B1c191aW50NjQgICAgICB1bnNp Z25lZCBsb25nIGxvbmcKICNkZWZpbmUgb3B1c191aW50OCAgICAgICB1bnNpZ25lZCBjaGFyCiAK LSNlbmRpZiAgLyogX09QVVNfVFlQRVNfSCAqLworI2VuZGlmICAvKiBPUFVTX1RZUEVTX0ggKi8K ZGlmZiAtLWdpdCBhL3NpbGsvSW5saW5lcy5oIGIvc2lsay9JbmxpbmVzLmgKaW5kZXggMjZiM2I1 YS4uODQ1OGM5NyAxMDA2NDQKLS0tIGEvc2lsay9JbmxpbmVzLmgKKysrIGIvc2lsay9JbmxpbmVz LmgKQEAgLTI5LDggKzI5LDggQEAgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9G IFRIRSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KICAqICBcYnJpZWYgc2lsa19JbmxpbmVz LmggZGVmaW5lcyBpbmxpbmUgc2lnbmFsIHByb2Nlc3NpbmcgZnVuY3Rpb25zLgogICovCiAKLSNp Zm5kZWYgX1NJTEtfRklYX0lOTElORVNfSF8KLSNkZWZpbmUgX1NJTEtfRklYX0lOTElORVNfSF8K KyNpZm5kZWYgU0lMS19GSVhfSU5MSU5FU19ICisjZGVmaW5lIFNJTEtfRklYX0lOTElORVNfSAog CiAjaWZkZWYgIF9fY3BsdXNwbHVzCiBleHRlcm4gIkMiCkBAIC0xODUsNCArMTg1LDQgQEAgc3Rh dGljIGlubGluZSBvcHVzX2ludDMyIHNpbGtfSU5WRVJTRTMyX3ZhclEoICAgLyogTyAgICByZXR1 cm5zIGEgZ29vZCBhcHByb3hpbWEKIH0KICNlbmRpZgogCi0jZW5kaWYgLypfU0lMS19GSVhfSU5M SU5FU19IXyovCisjZW5kaWYgLyogU0lMS19GSVhfSU5MSU5FU19IICovCmRpZmYgLS1naXQgYS9z aWxrL01hY3JvQ291bnQuaCBiL3NpbGsvTWFjcm9Db3VudC5oCmluZGV4IDk4ZWFjZmIuLjUwOWM5 YzIgMTAwNjQ0Ci0tLSBhL3NpbGsvTWFjcm9Db3VudC5oCisrKyBiL3NpbGsvTWFjcm9Db3VudC5o CkBAIC0yNSw4ICsyNSw4IEBAIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENP TlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUCiBPRiBUSElTIFNPRlRXQVJFLCBFVkVO IElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiovCiAKLSNpZm5kZWYgX1NJR1BST0NGSVhfQVBJX01BQ1JPQ09VTlRfSF8KLSNkZWZpbmUg X1NJR1BST0NGSVhfQVBJX01BQ1JPQ09VTlRfSF8KKyNpZm5kZWYgU0lHUFJPQ0ZJWF9BUElfTUFD Uk9DT1VOVF9ICisjZGVmaW5lIFNJR1BST0NGSVhfQVBJX01BQ1JPQ09VTlRfSAogI2luY2x1ZGUg PHN0ZGlvLmg+CiAKICNpZmRlZiAgICBzaWxrX01BQ1JPX0NPVU5UCmRpZmYgLS1naXQgYS9zaWxr L01hY3JvRGVidWcuaCBiL3NpbGsvTWFjcm9EZWJ1Zy5oCmluZGV4IGU0MDdiODAuLjhhZGY0NGUg MTAwNjQ0Ci0tLSBhL3NpbGsvTWFjcm9EZWJ1Zy5oCisrKyBiL3NpbGsvTWFjcm9EZWJ1Zy5oCkBA IC0yNSw4ICsyNSw4IEBAIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUCiBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KiovCiAKLSNpZm5kZWYgX01BQ1JPX0RFQlVHX0hfCi0jZGVmaW5lIF9NQUNST19ERUJVR19IXwor I2lmbmRlZiBNQUNST19ERUJVR19ICisjZGVmaW5lIE1BQ1JPX0RFQlVHX0gKIAogLyogUmVkZWZp bmUgbWFjcm8gZnVuY3Rpb25zIHdpdGggZXh0ZW5zaXZlIGFzc2VydGlvbiBpbiBERUJVRyBtb2Rl LgogICAgQXMgZnVuY3Rpb25zIGNhbid0IGJlIHVuZGVmaW5lZCwgdGhpcyBmaWxlIGNhbid0IHdv cmsgd2l0aCBTaWdQcm9jRklYX01hY3JvQ291bnQuaCAqLwpAQCAtNTY2LDQgKzU2Niw0IEBAIHN0 YXRpYyBpbmxpbmUgb3B1c19pbnQzMiBzaWxrX0NIRUNLX0ZJVDMyKCBvcHVzX2ludDY0IGEgKXsK ICovCiAKICNlbmRpZgotI2VuZGlmIC8qIF9NQUNST19ERUJVR19IXyAqLworI2VuZGlmIC8qIE1B Q1JPX0RFQlVHX0ggKi8KZGlmZiAtLWdpdCBhL3NpbGsvU2lnUHJvY19GSVguaCBiL3NpbGsvU2ln UHJvY19GSVguaAppbmRleCBhODBhYzk3Li42YTRlM2Y0IDEwMDY0NAotLS0gYS9zaWxrL1NpZ1By b2NfRklYLmgKKysrIGIvc2lsay9TaWdQcm9jX0ZJWC5oCkBAIC0yNSw4ICsyNSw4IEBAIEFOWSBU SEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZ LCBPUiBUT1JUCiBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJ QklMSVRZIE9GIFNVQ0ggREFNQUdFLgogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAKLSNpZm5kZWYgX1NJTEtf U0lHUFJPQ19GSVhfSF8KLSNkZWZpbmUgX1NJTEtfU0lHUFJPQ19GSVhfSF8KKyNpZm5kZWYgU0lM S19TSUdQUk9DX0ZJWF9ICisjZGVmaW5lIFNJTEtfU0lHUFJPQ19GSVhfSAogCiAjaWZkZWYgIF9f Y3BsdXNwbHVzCiBleHRlcm4gIkMiCkBAIC01OTEsNCArNTkxLDQgQEAgc3RhdGljIGlubGluZSBv cHVzX2ludDY0IHNpbGtfbWF4XzY0KG9wdXNfaW50NjQgYSwgb3B1c19pbnQ2NCBiKQogfQogI2Vu ZGlmCiAKLSNlbmRpZgorI2VuZGlmIC8qIFNJTEtfU0lHUFJPQ19GSVhfSCAqLwpkaWZmIC0tZ2l0 IGEvc2lsay9kZWJ1Zy5oIGIvc2lsay9kZWJ1Zy5oCmluZGV4IGEzZWE1Y2QuLjVhNmIxYTEgMTAw NjQ0Ci0tLSBhL3NpbGsvZGVidWcuaAorKysgYi9zaWxrL2RlYnVnLmgKQEAgLTI1LDggKzI1LDgg QEAgQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBM SUFCSUxJVFksIE9SIFRPUlQKIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU SEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAotI2lmbmRl ZiBfU0lMS19ERUJVR19IXwotI2RlZmluZSBfU0lMS19ERUJVR19IXworI2lmbmRlZiBTSUxLX0RF QlVHX0gKKyNkZWZpbmUgU0lMS19ERUJVR19ICiAKICNpZmRlZiBfV0lOMzIKICNkZWZpbmUgX0NS VF9TRUNVUkVfTk9fREVQUkVDQVRFICAgIDEKQEAgLTI4NCw0ICsyODQsNCBAQCBleHRlcm4gaW50 IHNpbGtfZGVidWdfc3RvcmVfY291bnQ7CiB9CiAjZW5kaWYKIAotI2VuZGlmIC8qIF9TSUxLX0RF QlVHX0hfICovCisjZW5kaWYgLyogU0lMS19ERUJVR19IICovCmRpZmYgLS1naXQgYS9zaWxrL2Zs b2F0L1NpZ1Byb2NfRkxQLmggYi9zaWxrL2Zsb2F0L1NpZ1Byb2NfRkxQLmgKaW5kZXggYmYxZDhl ZS4uN2IyYmEwOCAxMDA2NDQKLS0tIGEvc2lsay9mbG9hdC9TaWdQcm9jX0ZMUC5oCisrKyBiL3Np bGsvZmxvYXQvU2lnUHJvY19GTFAuaApAQCAtMjUsOCArMjUsOCBAQCBBTlkgVEhFT1JZIE9GIExJ QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVAog T0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRiBT VUNIIERBTUFHRS4KICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqLwogCi0jaWZuZGVmIF9TSUxLX1NJR1BST0NfRkxQ X0hfCi0jZGVmaW5lIF9TSUxLX1NJR1BST0NfRkxQX0hfCisjaWZuZGVmIFNJTEtfU0lHUFJPQ19G TFBfSAorI2RlZmluZSBTSUxLX1NJR1BST0NfRkxQX0gKIAogI2luY2x1ZGUgIlNpZ1Byb2NfRklY LmgiCiAjaW5jbHVkZSA8bWF0aC5oPgpAQCAtMjE0LDQgKzIxNCw0IEBAIHN0YXRpYyBpbmxpbmUg c2lsa19mbG9hdCBzaWxrX2xvZzIoIGRvdWJsZSB4ICkKIH0KICNlbmRpZgogCi0jZW5kaWYKKyNl bmRpZiAvKiBTSUxLX1NJR1BST0NfRkxQX0ggKi8KZGlmZiAtLWdpdCBhL3NpbGsvbWFjcm9zLmgg Yi9zaWxrL21hY3Jvcy5oCmluZGV4IDkxMzVkZGUuLmUzYWIwZTcgMTAwNjQ0Ci0tLSBhL3NpbGsv bWFjcm9zLmgKKysrIGIvc2lsay9tYWNyb3MuaApAQCAtMjUsOCArMjUsOCBAQCBBTlkgVEhFT1JZ IE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1Ig VE9SVAogT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRiBTVUNIIERBTUFHRS4KICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwogCi0jaWZuZGVmIF9TSUxLX0FQSV9D X0hfCi0jZGVmaW5lIF9TSUxLX0FQSV9DX0hfCisjaWZuZGVmIFNJTEtfQVBJX0NfSAorI2RlZmlu ZSBTSUxLX0FQSV9DX0gKIAogLyogVGhpcyBpcyBhbiBpbmxpbmUgaGVhZGVyIGZpbGUgZm9yIGdl bmVyYWwgcGxhdGZvcm0uICovCiAKQEAgLTEyOCw1ICsxMjgsNSBAQCBzdGF0aWMgaW5saW5lIG9w dXNfaW50MzIgc2lsa19DTFozMihvcHVzX2ludDMyIGluMzIpCiAjZW5kaWYKICNkZWZpbmUgbWF0 cml4X2NfYWRyKE1hdHJpeF9iYXNlX2Fkciwgcm93LCBjb2x1bW4sIE0pICAgICAgICAoTWF0cml4 X2Jhc2VfYWRyICsgKChyb3cpKyhNKSooY29sdW1uKSkpCiAKLSNlbmRpZiAvKiBfU0lMS19BUElf Q19IXyAqLworI2VuZGlmIC8qIFNJTEtfQVBJX0NfSCAqLwogCmRpZmYgLS1naXQgYS9zaWxrL3Jl c2FtcGxlcl9wcml2YXRlLmggYi9zaWxrL3Jlc2FtcGxlcl9wcml2YXRlLmgKaW5kZXggNTBhNjZj Zi4uOWUxNGMwZiAxMDA2NDQKLS0tIGEvc2lsay9yZXNhbXBsZXJfcHJpdmF0ZS5oCisrKyBiL3Np bGsvcmVzYW1wbGVyX3ByaXZhdGUuaApAQCAtODMsNSArODMsNCBAQCB2b2lkIHNpbGtfcmVzYW1w bGVyX3ByaXZhdGVfQVIyKAogI2lmZGVmIF9fY3BsdXNwbHVzCiB9CiAjZW5kaWYKLSNlbmRpZiAv KiBTSUxLX1JFU0FNUExFUl9IKi8KLQorI2VuZGlmIC8qIFNJTEtfUkVTQU1QTEVSX0ggKi8KZGlm ZiAtLWdpdCBhL3NpbGsvcmVzYW1wbGVyX3JvbS5oIGIvc2lsay9yZXNhbXBsZXJfcm9tLmgKaW5k ZXggMGVlYjk0NC4uZTI3M2Q2NCAxMDA2NDQKLS0tIGEvc2lsay9yZXNhbXBsZXJfcm9tLmgKKysr IGIvc2lsay9yZXNhbXBsZXJfcm9tLmgKQEAgLTI1LDggKzI1LDggQEAgQU5ZIFRIRU9SWSBPRiBM SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQK IE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0Yg U1VDSCBEQU1BR0UuCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAotI2lmbmRlZiBfU0lMS19GSVhfUkVTQU1Q TEVSX1JPTV9IXwotI2RlZmluZSBfU0lMS19GSVhfUkVTQU1QTEVSX1JPTV9IXworI2lmbmRlZiBT SUxLX0ZJWF9SRVNBTVBMRVJfUk9NX0gKKyNkZWZpbmUgU0lMS19GSVhfUkVTQU1QTEVSX1JPTV9I CiAKICNpZmRlZiAgX19jcGx1c3BsdXMKIGV4dGVybiAiQyIKQEAgLTYyLDQgKzYyLDQgQEAgZXh0 ZXJuIGNvbnN0IG9wdXNfaW50MTYgc2lsa19yZXNhbXBsZXJfZnJhY19GSVJfMTQ0WyAxNDQgXVsg UkVTQU1QTEVSX09SREVSX0ZJUl8KIH0KICNlbmRpZgogCi0jZW5kaWYgLyogX1NJTEtfRklYX1JF U0FNUExFUl9ST01fSF8qLworI2VuZGlmIC8qIFNJTEtfRklYX1JFU0FNUExFUl9ST01fSCAqLwpk aWZmIC0tZ2l0IGEvc2lsay90dW5pbmdfcGFyYW1ldGVycy5oIGIvc2lsay90dW5pbmdfcGFyYW1l dGVycy5oCmluZGV4IDA3ZDkzNzkuLmQ0MmE5NjMgMTAwNjQ0Ci0tLSBhL3NpbGsvdHVuaW5nX3Bh cmFtZXRlcnMuaAorKysgYi9zaWxrL3R1bmluZ19wYXJhbWV0ZXJzLmgKQEAgLTE2Nyw0ICsxNjcs NCBAQCBleHRlcm4gIkMiCiB9CiAjZW5kaWYKIAotI2VuZGlmIC8qIFNJTEtfVFVOSU5HX1BBUkFN RVRFUlNfSCovCisjZW5kaWYgLyogU0lMS19UVU5JTkdfUEFSQU1FVEVSU19IICovCmRpZmYgLS1n aXQgYS9zaWxrL3R5cGVkZWYuaCBiL3NpbGsvdHlwZWRlZi5oCmluZGV4IDI2ZmVhNjUuLmUyNTlk NzUgMTAwNjQ0Ci0tLSBhL3NpbGsvdHlwZWRlZi5oCisrKyBiL3NpbGsvdHlwZWRlZi5oCkBAIC0y NSw4ICsyNSw4IEBAIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNU LCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUCiBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFE VklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiov CiAKLSNpZm5kZWYgX1NJTEtfVFlQRURFRl9IXwotI2RlZmluZSBfU0lMS19UWVBFREVGX0hfCisj aWZuZGVmIFNJTEtfVFlQRURFRl9ICisjZGVmaW5lIFNJTEtfVFlQRURFRl9ICiAKICNpbmNsdWRl ICJvcHVzX3R5cGVzLmgiCiAKQEAgLTk5LDQgKzk5LDQgQEAgc3RhdGljIGlubGluZSB2b2lkIF9z aWxrX2ZhdGFsKGNvbnN0IGNoYXIgKnN0ciwgY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCiAj IGVuZGlmCiAjZW5kaWYKIAotI2VuZGlmCisjZW5kaWYgLyogU0lMS19UWVBFREVGX0ggKi8KZGlm ZiAtLWdpdCBhL3NyYy9vcHVzX3ByaXZhdGUuaCBiL3NyYy9vcHVzX3ByaXZhdGUuaAppbmRleCBi MzUzNzA1Li5jNzllNGIzIDEwMDY0NAotLS0gYS9zcmMvb3B1c19wcml2YXRlLmgKKysrIGIvc3Jj L29wdXNfcHJpdmF0ZS5oCkBAIC04Myw0ICs4Myw0IEBAIHN0YXRpYyBpbmxpbmUgaW50IGFsaWdu KGludCBpKQogCiBpbnQgb3B1c19yZXBhY2tldGl6ZXJfb3V0X3JhbmdlX2ltcGwoT3B1c1JlcGFj a2V0aXplciAqcnAsIGludCBiZWdpbiwgaW50IGVuZCwgdW5zaWduZWQgY2hhciAqZGF0YSwgaW50 IG1heGxlbiwgaW50IHNlbGZfZGVsaW1pdGVkKTsKIAotI2VuZGlmIC8qIE9QVVNfUFJJVkFURV9I XyAqLworI2VuZGlmIC8qIE9QVVNfUFJJVkFURV9IICovCi0tIAoxLjcuNi40Cgo= --0016364ee59a5f8efc04b2e6e7fd--