From ietf-ipr@ietf.org Fri Apr 13 07:52:10 2012 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 6B1CB21F85CF; Fri, 13 Apr 2012 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb-knb0fH+xN; Fri, 13 Apr 2012 07:52:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D63E21F84B6; Fri, 13 Apr 2012 07:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: jmvalin@jmvalin.ca, koen.vos@skype.net, tterriberry@mozilla.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413145210.20398.25342.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 07:52:10 -0700 Cc: fluffy@cisco.com, codec@ietf.org, ipr-announce@ietf.org Subject: [codec] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2) 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, 13 Apr 2012 14:52:10 -0000 Dear Jean-Marc Valin, Koen Vos, Tim Terriberry: An IPR disclosure that pertains to your Internet-Draft entitled "Definitio= n of the Opus Audio Codec" (draft-ietf-codec-opus) was submitted to the IETF Secretariat on 2012-04-02 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1741/). The = title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2).""); The IETF Secretariat From jridges@masque.com Fri Apr 13 08:14:49 2012 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 5F7AE21F87A0 for ; Fri, 13 Apr 2012 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5UppWHnDwIF for ; Fri, 13 Apr 2012 08:14:49 -0700 (PDT) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id E31EE21F8741 for ; Fri, 13 Apr 2012 08:14:48 -0700 (PDT) Received: from [127.0.0.1] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id BE9211602A6 for ; Fri, 13 Apr 2012 09:14:47 -0600 (MDT) Message-ID: <4F8842E5.9090608@masque.com> Date: Fri, 13 Apr 2012 09:14:45 -0600 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [codec] Unreachable code in recent commit 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, 13 Apr 2012 15:14:49 -0000 Hi JM, I think you forgot to delete the last line in the fixed-point version of the "frac_div32" function in mathops.c in the CELT code. Cheers, John Ridges From jmvalin@mozilla.com Fri Apr 13 09:35:37 2012 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 0245D21F8694 for ; Fri, 13 Apr 2012 09:35:37 -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 Z2fNaE02uWy0 for ; Fri, 13 Apr 2012 09:35:36 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id A69AC21F87F7 for ; Fri, 13 Apr 2012 09:35:26 -0700 (PDT) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id AF2844AEDE4; Fri, 13 Apr 2012 09:35:25 -0700 (PDT) Message-ID: <4F8855CC.3090805@mozilla.com> Date: Fri, 13 Apr 2012 12:35:24 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: John Ridges References: <4F8842E5.9090608@masque.com> In-Reply-To: <4F8842E5.9090608@masque.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Unreachable code in recent commit 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, 13 Apr 2012 16:35:37 -0000 Oops. Thanks for paying attention. This is fixed now. Jean-Marc On 13/04/12 11:14 AM, John Ridges wrote: > Hi JM, > > I think you forgot to delete the last line in the fixed-point version of > the "frac_div32" function in mathops.c in the CELT code. > > Cheers, > John Ridges > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Mon Apr 16 06:10:59 2012 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 9920321F8721 for ; Mon, 16 Apr 2012 06:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 bal6F18Qnrng for ; Mon, 16 Apr 2012 06:10:59 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id 83CAA21F8710 for ; Mon, 16 Apr 2012 06:10:58 -0700 (PDT) Received: from hoeneT60 (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q3GDFnRb002324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Apr 2012 15:15:50 +0200 From: "Christian Hoene" To: Date: Mon, 16 Apr 2012 15:11:00 +0200 Organization: =?utf-8?Q?Universit=C3=A4t_T=C3=BCbingen?= Message-ID: <008b01cd1bd2$5ecc45a0$1c64d0e0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0b0ltJCKxJCkElQg6a+DiDL6ul2g== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx08) Subject: [codec] New test results on Opus? 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, 16 Apr 2012 13:10:59 -0000 Dear all, if any new or updates listening-only tests on Opus are available, please = send them to me so that I can update the codec quality draft = accordingly. If available, please send me any documents or data that is available in = addition to the slides shown at the 82nd IETF meeting. Thanks Christian=20 -- Dr.-Ing. Christian Hoene University of T=C3=BCbingen, Chair of Communication Networks Research Group Interactive Communication Systems (ICS) Sand 13, 72076 T=C3=BCbingen, Germany Tel +49 7071 2970532, www.net.uni-tuebingen.de From rjsparks@nostrum.com Wed Apr 18 13:14:30 2012 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 90BA621F84D2 for ; Wed, 18 Apr 2012 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Rgbd9Ox0bl for ; Wed, 18 Apr 2012 13:14:25 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1064521F84C8 for ; Wed, 18 Apr 2012 13:14:24 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3IKENrV095712 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Apr 2012 15:14:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F8F209F.90505@nostrum.com> Date: Wed, 18 Apr 2012 15:14:23 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [codec] AD review: draft-ietf-codec-opus-11 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, 18 Apr 2012 20:14:30 -0000 Summary: This draft is almost ready for IETF last call, but has a few issues to discuss and address with a revised ID before starting that review 1) Section 10 (Copying considerations) appears to be trying to say something different from what the copyright notice on the first page says. Do we still need this section? Can it be removed at this time? 2) Can we set the license blocks in the code components (the files in the gzipped tarball) to use the license in the TLP? (See section 4.c) 3) The text in section 6.2 leaves the standardization status of Opus Custom very unclear. Is this, and the associated code, part of this standard? If so, "not supported by the main Opus specification" is very confusing. Please clarify this section. 4) The draft claims the test vectors will be in some IETF meeting's proceedings. What is the plan to make that true? It would be optimal to have that done now, and a reference pointing to where they are in the proceedings added. 5) It would help to be very explicit about bit order somewhere early in the document. Have I missed where this is discussed already? (See section 3.1's description of the "top five bits" - these aren't the most significant bits per the diagram). If there's the opportunity for ambiguity, please also make sure byte order is explicitly described. For instance, this would help the reader figure out which byte is len[1] and which is len[0] in section 3.2.1. 6) There are several terms that someone practiced in this field would be expected to know, but it would help to add a reference to a definition or description. Examples: whitening filter, Hadamard transform, Schur algorithm, Viterbi algorithm, Burg's method. Similarly, adding a reference to an explanation of denormalized numbers would help. 7) Did the recommendations for using CBR in section 2.1.8 track the final conclusions of RFC6562? That RFC indicates VBR is unsafe even for unconstrained conversations if the information contained is highly sensitive. 8) (nit, but please adjust) Section 3.2.5 speaks of Abitrary numbers of frames. It's not arbitrary, it's properly between 2 and 32. 9) The description in 3.2.5 in the paragraph after figure 5 is confusing. It conflates padding with framing overhead, and it appears to allow saying that I have 254 bits of padding in more than one way. Is that intentional? 10) Section 3.4's title says it is going to talk about "Extending Opus". Instead, it talks about what packets are well formed, and requires the implementation to ignore everything else. It effectively says "All malformed packets might be the result of extensions" but doesn't discuss what the extension mechanisms are. I suggest retitling the section to something like "Receiving malformed packets", and adding a single sentence noting that extensions may cause implementations of _this_ spec to treat their packets as malformed. 11) I don't think you need 2119 MAYs in section 4.1.3 (Overall, the documents use of 2119 keywords is solid). 12) Section 4.1.5.1 and .2 - using a lower case L in these formulas (that also contain the digit form of one) is cruel. You have no control over what font the reader is going to view these formula with. Please consider a symbol that is less likely to be ambiguous. 13) An observation, not necessarily a request for change: It took me some time to convince myself that the description in 4.1.5.2 and the code in ec_tell_frac did the same thing. 14) Section 4.2.7.5.7 (for future efforts, please consider restructuring when you find yourself creating outlines that go this deep) - The constant 163838 is not explained in the text, but it is in the code. Could you move the explanation into the document? (And please do the same with any other constants that have an explanation like this). 15) To help avoid confusion about whether the URIs provided in the reference section are informative or normative references, please recast them as references and put them in the intended section. See RFC6581 for a recent example of using URIs in references. 16) The language in section A.2 will not age well after this is published as an RFC. At least add "As of the time of publication of this memo". It would also be good to clarify here that any changes in the repository and snapshots you are pointing to are NOT changes to the standard. 17) Similarly, references to the active project from inside the code contained here will not age well. The github reference in the README for instance will almost certainly be wrong in a few years, and it introduces ambiguity about whether what it's pointing to is part of the standard. Please consider making a version of the README that's specific to this particular snapshot (and say "this RFC" or "this memo" there instead of "this draft") 18) The sed in the draft for extracting the archive uses a gnu extension. It will not work for posix sed. There, \s matches a lower-case S. This would be more portable: s/^...###// 19) I've asked several people to sanity check the build. Here is some important feedback I've received: *) The Makefile uses GNU extensions extensively, and hardcodes the use of gcc (in spite of the claim that the code should compile with any C89 or C99 compiler). It shouldn't be hard to remove the gnuisms from the makefile so that it would work on a strictly posix system (and more likely work with windows systems). *) The compile generates warnings: celt/bands.c:204: warning: unused parameter ‘CC’ src/opus_decoder.c:533: warning: ‘count’ may be used uninitialized in this function *) run_vectors.sh relies on seq which doesn't exist as seq on many platforms. You can get it on OS/X through ports as gseq. This should be documented at least. *) The build leaves .o files lying around in the source. 20) Consider adjusting the comment about being sure in ./celt/bands.c compute_band_energies 21) Throughout the code there are printfs and fprintfs of a debugging nature commented out (sometimes inconsistently). Why have these been left as is? Are you absolutely certain that there is no path to one of the statements that hasn't been commented out in the library code that would cause a runtime write to stdout or stderr? celt/fixed_debug.h is particular is pretty inconsistent with what's commented out and what isn't. 22) celt/cwrs.c contains nearly two pages of exposition in a comment, complete with references. Why isn't this in the main draft text instead? 23) celt/ecintrin.h contains a discussion of patents and prior art around abs(). An RFC isn't the place for this discussion - can this part of the comment be adjusted? 24) celt/entdec.c contains a very long comment that contains an opinion about encumberment of the range decode algorithm. It's not clear who the speaker is where the comment says "to my knowledge". Please adjust this taking publication in an RFC into consideration. 25) celt/kiss_fft.h has a block starting ATTENTION! that is advertisement for a set of files in a tools/ directory that does not appear to be part of this snapshot. 26) In celt/vq.c exp_rotation, there are some large blocks commented out that appear to be debugging diagnostics. Do they need to remain in the code? If so, could they be guarded with ifdefs instead of comments to make it clearer what's going on? 27) In celt/vq.c exp_rotation, there's a comment saying "I _think_ it is bit-exact". It's not clear who the speaker is. Is there still uncertainty about this? 28) In celt/vq.c exp_rotation, there's a comment that asks "Do we have sufficient accuracy here?" It's not clear if that's a question about whether the code is being accurate enough. If so, does that uncertainty still exist? Please adjust the comment appropriately. 29) include/opus_types.h contains a comment saying /* opus_types.h taken from libogg */. Please clarify - I don't think you meant to say this file was taken from the libogg source tree. What is it trying to say? 30) include/opus_defines.h says 'Best for "standard" VoIP/videoconference applications where listening quality and intelligibility matter most'. What does "standard" mean here? 31) silk/float/noise_shape_analysis_FLP.c : Similar to point 6) above, but there's no analogous text in the body of the draft to point to: What is a "monic" filter? 32) silk/MacroCount.h defines silk_PrintCount() but nothing seems to be using it. Is this another bit of debugging code that is (effectively) commented out? Does it need to be part of this snapshot? 33) Is "private" in the filenames of src/opus_private.h and the various silk/resampler_private files anything more than a historic artifact? 34) in src/opus_private.h, is this bit of documentation still accurate?: * @note This interface is currently more aspiration than actuality. It's * ultimately expected to bias an automatic signal classifier, but it currently * just shifts the static bitrate to mode mapping around a little bit. 35) John Ridges reported an unreachable line on the list on Apr 13. From tterribe@xiph.org Wed Apr 18 13:45:03 2012 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 9211011E8091 for ; Wed, 18 Apr 2012 13:45:03 -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 NdFeahMKcvpg for ; Wed, 18 Apr 2012 13:44:59 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 8414811E80A2 for ; Wed, 18 Apr 2012 13:44:59 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 2A6BC4AED8E; Wed, 18 Apr 2012 13:44:59 -0700 (PDT) Message-ID: <4F8F27CA.4010800@xiph.org> Date: Wed, 18 Apr 2012 13:44:58 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: Robert Sparks References: <4F8F209F.90505@nostrum.com> In-Reply-To: <4F8F209F.90505@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 18 Apr 2012 20:45:03 -0000 Thank you for the detailed review. While we will of course address all the comments, I wanted to make one brief point now. Robert Sparks wrote: > 22) celt/cwrs.c contains nearly two pages of exposition in a comment, > complete with references. Why isn't this in the main draft text instead? The exposition here primarily concerns a specific set of optimizations, designed to minimize the required ROM usage at the expense of more complex code. These are not the only way to implement these functions. For example, the code I posted at http://www.ietf.org/mail-archive/web/codec/current/msg02140.html simply uses a moderately-sized lookup table, and requires none of these explanations. It reimplements the entire decoding half of cwrs.c, roughly 300 lines of code, in one function that is less than 20 lines, including comments. The text in the spec tries to limit itself to the simplest mathematical definition of the process, for ease of understanding, leaving specific optimizations to the implementor. It also references the same paper the code does. From ron@debian.org Thu Apr 19 06:01:40 2012 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 41E8521F85D0 for ; Thu, 19 Apr 2012 06:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 UiYIP5ehP97W for ; Thu, 19 Apr 2012 06:01:36 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id D187521F85D3 for ; Thu, 19 Apr 2012 06:01:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADYMkE920nFk/2dsb2JhbABDsUCBCIIJAQEFOhwjEAsOCi4UGA0kiCEMuluPWmMEiFqFLodmAYESjymCdw Received: from ppp118-210-113-100.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.113.100]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Apr 2012 22:31:33 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 7C80F4F8F3; Thu, 19 Apr 2012 22:31:32 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q-lmSSZ7HbUf; Thu, 19 Apr 2012 22:31:28 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 312CE4F8FE; Thu, 19 Apr 2012 22:31:28 +0930 (CST) Date: Thu, 19 Apr 2012 22:31:28 +0930 From: Ron To: Robert Sparks Message-ID: <20120419130128.GE12062@audi.shelbyville.oz> References: <4F8F209F.90505@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8F209F.90505@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 19 Apr 2012 13:01:40 -0000 Hi Robert, I'll add my warm thanks for the obvious effort and attention that you've put into reviewing this draft too. This is a non-trivial contribution that I'm very happy to see. On Wed, Apr 18, 2012 at 03:14:23PM -0500, Robert Sparks wrote: > 1) Section 10 (Copying considerations) appears to be trying to say > something different from what the copyright notice on the first page > says. Do we still need this section? Can it be removed at this time? The intention of this section was to make explicit that the authors are granting additional rights to those of the TLP. Similar to the grants that were added in, for example: http://tools.ietf.org/html/rfc3492#appendix-B http://tools.ietf.org/html/rfc4501#section-8 http://tools.ietf.org/html/rfc5215#section-11 http://tools.ietf.org/html/rfc5334#section-12 The main difference here was a desire to be clear that the source code components were not included in this additional grant and remained under the usual IETF BSD licence for such parts. While the TLP is fairly clear that the IETF avoids becoming involved in making such additional grants and it is up to the document authors to do so if they wish, there is no desire for this clause to add confusion; so if there is better language that we should use there which fits with the intent, then I'd welcome suggestions for how it might be improved. I requested that this be added so that we could include this text in the supporting documentation of the Debian packages for libopus, which we would not be able to do without this additional grant of rights. Best, Ron From internet-drafts@ietf.org Mon Apr 23 22:49:49 2012 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 C7FD711E8080; Mon, 23 Apr 2012 22:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlD5XI3eHdxS; Mon, 23 Apr 2012 22:49:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5478421F84CF; Mon, 23 Apr 2012 22:49:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120424054949.17840.93555.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 22:49:49 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-12.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 05:49:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-12.txt Pages : 326 Date : 2012-04-23 This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-opus-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-opus-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus/ From jmvalin@mozilla.com Mon Apr 23 22:54:45 2012 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 72B2811E80A3 for ; Mon, 23 Apr 2012 22:54:45 -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 xOicNjjfZKHy for ; Mon, 23 Apr 2012 22:54:43 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 75FD011E80A2 for ; Mon, 23 Apr 2012 22:54:43 -0700 (PDT) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 1FCEF4AEDA1; Mon, 23 Apr 2012 22:54:42 -0700 (PDT) Message-ID: <4F964021.1040707@mozilla.com> Date: Tue, 24 Apr 2012 01:54:41 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Robert Sparks References: <4F8F209F.90505@nostrum.com> In-Reply-To: <4F8F209F.90505@nostrum.com> Content-Type: multipart/mixed; boundary="------------000101010109090701050906" Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 24 Apr 2012 05:54:45 -0000 This is a multi-part message in MIME format. --------------000101010109090701050906 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Robert, Thank you very much for spending the time to go through this draft. I've attached the list of changes made by all the authors to address the issues you raised. Cheers, Jean-Marc On 18/04/12 04:14 PM, Robert Sparks wrote: > Summary: This draft is almost ready for IETF last call, but has a few > issues to discuss and address with a revised ID before starting that review > > 1) Section 10 (Copying considerations) appears to be trying to say > something different from what the copyright notice on the first page > says. Do we still need this section? Can it be removed at this time? > > 2) Can we set the license blocks in the code components (the files in > the gzipped tarball) to use the license in the TLP? (See > > section 4.c) > > 3) The text in section 6.2 leaves the standardization status of Opus > Custom very unclear. Is this, and the associated code, part of this > standard? If so, "not supported by the main Opus specification" is very > confusing. Please clarify this section. > > 4) The draft claims the test vectors will be in some IETF meeting's > proceedings. What is the plan to make that true? It would be optimal to > have that done now, and a reference pointing to where they are in the > proceedings added. > > 5) It would help to be very explicit about bit order somewhere early in > the document. Have I missed where this is discussed already? (See > section 3.1's description of the "top five bits" - these aren't the most > significant bits per the diagram). If there's the opportunity for > ambiguity, please also make sure byte order is explicitly described. For > instance, this would help the reader figure out which byte is len[1] and > which is len[0] in section 3.2.1. > > 6) There are several terms that someone practiced in this field would be > expected to know, but it would help to add a reference to a definition > or description. Examples: whitening filter, Hadamard transform, Schur > algorithm, Viterbi algorithm, Burg's method. Similarly, adding a > reference to an explanation of denormalized numbers would help. > > 7) Did the recommendations for using CBR in section 2.1.8 track the > final conclusions of RFC6562? That RFC indicates VBR is unsafe even for > unconstrained conversations if the information contained is highly > sensitive. > > 8) (nit, but please adjust) Section 3.2.5 speaks of Abitrary numbers of > frames. It's not arbitrary, it's properly between 2 and 32. > > 9) The description in 3.2.5 in the paragraph after figure 5 is > confusing. It conflates padding with framing overhead, and it appears to > allow saying that I have 254 bits of padding in more than one way. Is > that intentional? > > 10) Section 3.4's title says it is going to talk about "Extending Opus". > Instead, it talks about what packets are well formed, and requires the > implementation to ignore everything else. It effectively says "All > malformed packets might be the result of extensions" but doesn't discuss > what the extension mechanisms are. I suggest retitling the section to > something like "Receiving malformed packets", and adding a single > sentence noting that extensions may cause implementations of _this_ spec > to treat their packets as malformed. > > 11) I don't think you need 2119 MAYs in section 4.1.3 (Overall, the > documents use of 2119 keywords is solid). > > 12) Section 4.1.5.1 and .2 - using a lower case L in these formulas > (that also contain the digit form of one) is cruel. You have no control > over what font the reader is going to view these formula with. Please > consider a symbol that is less likely to be ambiguous. > > 13) An observation, not necessarily a request for change: It took me > some time to convince myself that the description in 4.1.5.2 and the > code in ec_tell_frac did the same thing. > > 14) Section 4.2.7.5.7 (for future efforts, please consider restructuring > when you find yourself creating outlines that go this deep) - The > constant 163838 is not explained in the text, but it is in the code. > Could you move the explanation into the document? (And please do the > same with any other constants that have an explanation like this). > > 15) To help avoid confusion about whether the URIs provided in the > reference section are informative or normative references, please recast > them as references and put them in the intended section. See RFC6581 for > a recent example of using URIs in references. > > 16) The language in section A.2 will not age well after this is > published as an RFC. At least add "As of the time of publication of this > memo". It would also be good to clarify here that any changes in the > repository and snapshots you are pointing to are NOT changes to the > standard. > > 17) Similarly, references to the active project from inside the code > contained here will not age well. The github reference in the README for > instance will almost certainly be wrong in a few years, and it > introduces ambiguity about whether what it's pointing to is part of the > standard. Please consider making a version of the README that's specific > to this particular snapshot (and say "this RFC" or "this memo" there > instead of "this draft") > > 18) The sed in the draft for extracting the archive uses a gnu > extension. It will not work for posix sed. There, \s matches a > lower-case S. This would be more portable: > s/^...###// > > 19) I've asked several people to sanity check the build. Here is some > important feedback I've received: > *) The Makefile uses GNU extensions extensively, and hardcodes the use > of gcc (in spite of the claim that the code should compile with any C89 > or C99 compiler). It shouldn't be hard to remove the gnuisms from the > makefile so that it would work on a strictly posix system (and more > likely work with windows systems). > *) The compile generates warnings: > celt/bands.c:204: warning: unused parameter ‘CC’ > src/opus_decoder.c:533: warning: ‘count’ may be used uninitialized in > this function > *) run_vectors.sh relies on seq which doesn't exist as seq on many > platforms. You can get it on OS/X through ports as gseq. This should be > documented at least. > *) The build leaves .o files lying around in the source. > > 20) Consider adjusting the comment about being sure in ./celt/bands.c > compute_band_energies > > 21) Throughout the code there are printfs and fprintfs of a debugging > nature commented out (sometimes inconsistently). Why have these been > left as is? Are you absolutely certain that there is no path to one of > the statements that hasn't been commented out in the library code that > would cause a runtime write to stdout or stderr? celt/fixed_debug.h is > particular is pretty inconsistent with what's commented out and what isn't. > > 22) celt/cwrs.c contains nearly two pages of exposition in a comment, > complete with references. Why isn't this in the main draft text instead? > > 23) celt/ecintrin.h contains a discussion of patents and prior art > around abs(). An RFC isn't the place for this discussion - can this part > of the comment be adjusted? > > 24) celt/entdec.c contains a very long comment that contains an opinion > about encumberment of the range decode algorithm. It's not clear who the > speaker is where the comment says "to my knowledge". Please adjust this > taking publication in an RFC into consideration. > > 25) celt/kiss_fft.h has a block starting ATTENTION! that is > advertisement for a set of files in a tools/ directory that does not > appear to be part of this snapshot. > > 26) In celt/vq.c exp_rotation, there are some large blocks commented out > that appear to be debugging diagnostics. Do they need to remain in the > code? If so, could they be guarded with ifdefs instead of comments to > make it clearer what's going on? > > 27) In celt/vq.c exp_rotation, there's a comment saying "I _think_ it is > bit-exact". It's not clear who the speaker is. Is there still > uncertainty about this? > > 28) In celt/vq.c exp_rotation, there's a comment that asks "Do we have > sufficient accuracy here?" It's not clear if that's a question about > whether the code is being accurate enough. If so, does that uncertainty > still exist? Please adjust the comment appropriately. > > 29) include/opus_types.h contains a comment saying /* opus_types.h taken > from libogg */. Please clarify - I don't think you meant to say this > file was taken from the libogg source tree. What is it trying to say? > > 30) include/opus_defines.h says 'Best for "standard" > VoIP/videoconference applications where listening quality and > intelligibility matter most'. What does "standard" mean here? > > 31) silk/float/noise_shape_analysis_FLP.c : Similar to point 6) above, > but there's no analogous text in the body of the draft to point to: What > is a "monic" filter? > > 32) silk/MacroCount.h defines silk_PrintCount() but nothing seems to be > using it. Is this another bit of debugging code that is (effectively) > commented out? Does it need to be part of this snapshot? > > 33) Is "private" in the filenames of src/opus_private.h and the various > silk/resampler_private files anything more than a historic artifact? > > 34) in src/opus_private.h, is this bit of documentation still accurate?: > * @note This interface is currently more aspiration than actuality. It's > * ultimately expected to bias an automatic signal classifier, but it > currently > * just shifts the static bitrate to mode mapping around a little bit. > > 35) John Ridges reported an unreachable line on the list on Apr 13. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --------------000101010109090701050906 Content-Type: text/plain; charset=UTF-8; name="AD-response.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="AD-response.txt" On 18/04/12 04:14 PM, Robert Sparks wrote: > 1) Section 10 (Copying considerations) appears to be trying to say > something different from what the copyright notice on the first page > says. Do we still need this section? Can it be removed at this time? See Ron's previous email for details. > 2) Can we set the license blocks in the code components (the files in > the gzipped tarball) to use the license in the TLP? (See > > section 4.c) We have updated the license text in the C files and the COPYING file to match the license text you linked above. > 3) The text in section 6.2 leaves the standardization status of Opus > Custom very unclear. Is this, and the associated code, part of this > standard? If so, "not supported by the main Opus specification" is very > confusing. Please clarify this section. This paragraph was rewritten. The new text is: "Opus Custom is an OPTIONAL part of the specification that is defined to handle special sample rates and frame rates that are not supported by the main Opus specification. Use of Opus Custom is discouraged for all but very special applications for which a frame size different from 2.5, 5, 10, or 20 ms is needed (for either complexity or latency reasons). Because Opus Custom is optional, applications using that part of the specification may not be compatible with other applications implementing Opus. In Opus Custom operation, only the CELT layer is available, using the opus_custom_* function calls in opus_custom.h." > 4) The draft claims the test vectors will be in some IETF meeting's > proceedings. What is the plan to make that true? It would be optimal to > have that done now, and a reference pointing to where they are in the > proceedings added. The test vectors have now been uploaded in the Paris meeting proceedings and the updated draft has a link to that. > 5) It would help to be very explicit about bit order somewhere early in > the document. Have I missed where this is discussed already? (See > section 3.1's description of the "top five bits" - these aren't the most > significant bits per the diagram). If there's the opportunity for > ambiguity, please also make sure byte order is explicitly described. For > instance, this would help the reader figure out which byte is len[1] and > which is len[0] in section 3.2.1. This is probably due to the author's mis-understanding of the conventions involved in these bit diagrams. In every other context, bit 0 is the least significant, and bit 7 the most significant of a byte (and indeed this seemed to be true from the examples in other drafts, but these were bad examples). The diagrams have been updated to conform to the convention (as near as can be reverse engineered) from, e.g., RFC 796, and an explanatory note has been added to the beginning of section 3. Hopefully this makes the diagrams clearer. This also required some changes in the text (to reflect the ordering of fields, or where bits were referred to by number). > 6) There are several terms that someone practiced in this field would be > expected to know, but it would help to add a reference to a definition > or description. Examples: whitening filter, Hadamard transform, Schur > algorithm, Viterbi algorithm, Burg's method. Similarly, adding a > reference to an explanation of denormalized numbers would help. Included references for many technical terms, including the ones listed above. > 7) Did the recommendations for using CBR in section 2.1.8 track the > final conclusions of RFC6562? That RFC indicates VBR is unsafe even for > unconstrained conversations if the information contained is highly > sensitive. Updated the text to reflect this: "When encryption is used for an audio stream that is either highly constrained (e.g. yes/no, recorded prompts) or highly sensitive" > 8) (nit, but please adjust) Section 3.2.5 speaks of Abitrary numbers of > frames. It's not arbitrary, it's properly between 2 and 32. Replaced "arbitrary" by "signaled". > 9) The description in 3.2.5 in the paragraph after figure 5 is > confusing. It conflates padding with framing overhead, and it appears to > allow saying that I have 254 bits of padding in more than one way. Is > that intentional? 254 _bytes_ of padding, not bits, but otherwise yes, that is intentional. The two ways of saying you have 254 bytes of padding require 1 and 2 bytes themselves to describe. So the total size of the packet is increased by 255 and 256 bytes, respectively. I added a paragraph of text to the draft to make this more explicit, and stopped referring to P as the "total padding". If anyone can think of additional changes which would make this text clearer, please suggest them. > 10) Section 3.4's title says it is going to talk about "Extending Opus". > Instead, it talks about what packets are well formed, and requires the > implementation to ignore everything else. It effectively says "All > malformed packets might be the result of extensions" but doesn't discuss > what the extension mechanisms are. I suggest retitling the section to > something like "Receiving malformed packets", and adding a single > sentence noting that extensions may cause implementations of _this_ spec > to treat their packets as malformed. The section was retitled as proposed, and the suggested sentence added. > 11) I don't think you need 2119 MAYs in section 4.1.3 (Overall, the > documents use of 2119 keywords is solid). Fixed. > 12) Section 4.1.5.1 and .2 - using a lower case L in these formulas > (that also contain the digit form of one) is cruel. You have no control > over what font the reader is going to view these formula with. Please > consider a symbol that is less likely to be ambiguous. Changed "l" to "lg" > 13) An observation, not necessarily a request for change: It took me > some time to convince myself that the description in 4.1.5.2 and the > code in ec_tell_frac did the same thing. > > 14) Section 4.2.7.5.7 (for future efforts, please consider restructuring > when you find yourself creating outlines that go this deep) - The > constant 163838 is not explained in the text, but it is in the code. > Could you move the explanation into the document? (And please do the > same with any other constants that have an explanation like this). The text had noted that this constant was "chosen to avoid overflow in subsequent calculations" (which we thought was a better explanation than the one in the code, which merely gives a formula and leaves the reader to figure out where it was derived from). But we added an explicit sentence with the formula from the code. Explanations for four other constants were also added. > 15) To help avoid confusion about whether the URIs provided in the > reference section are informative or normative references, please recast > them as references and put them in the intended section. See RFC6581 for > a recent example of using URIs in references. Changed all URIs to informative references. > 16) The language in section A.2 will not age well after this is > published as an RFC. At least add "As of the time of publication of this > memo". It would also be good to clarify here that any changes in the > repository and snapshots you are pointing to are NOT changes to the > standard. Changed the text to be clearer: "As of the time of publication of this memo, up-to-date source code implementing this standard is available in a Git repository." The section was also renamed "Up-to-date Implementation". > 17) Similarly, references to the active project from inside the code > contained here will not age well. The github reference in the README for > instance will almost certainly be wrong in a few years, and it > introduces ambiguity about whether what it's pointing to is part of the > standard. Please consider making a version of the README that's specific > to this particular snapshot (and say "this RFC" or "this memo" there > instead of "this draft") Replaced draft with "RFC" and marked the git repository as being the "latest implementation of this standard at the time of publication" > 18) The sed in the draft for extracting the archive uses a gnu > extension. It will not work for posix sed. There, \s matches a > lower-case S. This would be more portable: > s/^...###// Thanks, didn't know that. Applied the change. > 19) I've asked several people to sanity check the build. Here is some > important feedback I've received: > *) The Makefile uses GNU extensions extensively, and hardcodes the use > of gcc (in spite of the claim that the code should compile with any C89 > or C99 compiler). It shouldn't be hard to remove the gnuisms from the > makefile so that it would work on a strictly posix system (and more > likely work with windows systems). Removing the gnuisms from the Makefile isn't trivial (if anyone in the WG feels strongly about this, a patch would be welcome), but at least we changed CC=gcc to CC=cc. Also, the draft now now lists an alternate way to compile without a Makefile: cc -O2 -g -o opus_demo src/opus_demo.c `cat *.mk | grep -v fixed | sed -e 's/.*=//' -e 's/\\\\//'` -DOPUS_BUILD -Iinclude -Icelt -Isilk -Isilk/float -Drestrict= -lm > *) The compile generates warnings: > celt/bands.c:204: warning: unused parameter ‘CC’ Fixed. > src/opus_decoder.c:533: warning: ‘count’ may be used uninitialized in > this function The code was obviously correct, but some compilers (e.g. older gcc, but not current gcc) are really dumb and do not realize that (toc&0x3) has to be between 0 and 3. We now work around this by replacing the "case 3:" with "default:". > *) run_vectors.sh relies on seq which doesn't exist as seq on many > platforms. You can get it on OS/X through ports as gseq. This should be > documented at least. The use of `seq ...` was expanded, so seq is no longer needed. > *) The build leaves .o files lying around in the source. This doesn't sound like a big problem. There is a make clean target to clean things up, but a patch is welcome if anyone has an alternative approach that would avoid the clutter in the first place. > 20) Consider adjusting the comment about being sure in ./celt/bands.c > compute_band_energies Comment updated to: "We're adding one here to ensure the normalized band isn't larger than unity norm" > 21) Throughout the code there are printfs and fprintfs of a debugging > nature commented out (sometimes inconsistently). Why have these been > left as is? Are you absolutely certain that there is no path to one of > the statements that hasn't been commented out in the library code that > would cause a runtime write to stdout or stderr? celt/fixed_debug.h is > particular is pretty inconsistent with what's commented out and what isn't. The celt/fixed_debug.h header is included to verify the fixed-point implementation. It's not actually included when compiling unless FIXED_DEBUG is defined. This is the only case where the code can output to stderr (along with assertions when enabled). > 22) celt/cwrs.c contains nearly two pages of exposition in a comment, > complete with references. Why isn't this in the main draft text instead? See Tim's previous email. However, the explanations in the text did leave the details of the conversion between a vector and a codebook index to the cited reference. To make things easier to understand (and for those without access to the IEEE paywall), a particularly simple description of these conversion functions was added. > 23) celt/ecintrin.h contains a discussion of patents and prior art > around abs(). An RFC isn't the place for this discussion - can this part > of the comment be adjusted? This comment was simply removed. > 24) celt/entdec.c contains a very long comment that contains an opinion > about encumberment of the range decode algorithm. It's not clear who the > speaker is where the comment says "to my knowledge". Please adjust this > taking publication in an RFC into consideration. The discussions of encumbrance were removed. These were obsolete anyway (they were written over a decade ago, and many of the patents in this area have since expired). > 25) celt/kiss_fft.h has a block starting ATTENTION! that is > advertisement for a set of files in a tools/ directory that does not > appear to be part of this snapshot. Comment removed. > 26) In celt/vq.c exp_rotation, there are some large blocks commented out > that appear to be debugging diagnostics. Do they need to remain in the > code? If so, could they be guarded with ifdefs instead of comments to > make it clearer what's going on? Diagnostics code removed. > 27) In celt/vq.c exp_rotation, there's a comment saying "I _think_ it is > bit-exact". It's not clear who the speaker is. Is there still > uncertainty about this? We verified this it is exact and removed the "I think..." sentence. > 28) In celt/vq.c exp_rotation, there's a comment that asks "Do we have > sufficient accuracy here?" It's not clear if that's a question about > whether the code is being accurate enough. If so, does that uncertainty > still exist? Please adjust the comment appropriately. Comment removed. > 29) include/opus_types.h contains a comment saying /* opus_types.h taken > from libogg */. Please clarify - I don't think you meant to say this > file was taken from the libogg source tree. What is it trying to say? Yes, this was taken (and modified) from the libogg source tree (was originally called ogg_types). > 30) include/opus_defines.h says 'Best for "standard" > VoIP/videoconference applications where listening quality and > intelligibility matter most'. What does "standard" mean here? s/standard/most/ > 31) silk/float/noise_shape_analysis_FLP.c : Similar to point 6) above, > but there's no analogous text in the body of the draft to point to: What > is a "monic" filter? Added the following note in noise_shape_analysis_FIX.c and noise_shape_analysis_FLP.c: "A monic filter is one with the first coefficient equal to 1.0. In Silk we omit the first coefficient in an array of coefficients, for monic filters." > 32) silk/MacroCount.h defines silk_PrintCount() but nothing seems to be > using it. Is this another bit of debugging code that is (effectively) > commented out? Does it need to be part of this snapshot? The silk_PrintCount() function is useful for diagnostic at development time. It is not built by default (requires silk_MACRO_COUNT to be defined). > 33) Is "private" in the filenames of src/opus_private.h and the various > silk/resampler_private files anything more than a historic artifact? In the case of src/opus_private.h, private just means that these definitions are not meant to be exported as part of the API. In the case of silk/resampler_private, it indicates a private API within Opus. > 34) in src/opus_private.h, is this bit of documentation still accurate?: > * @note This interface is currently more aspiration than actuality. It's > * ultimately expected to bias an automatic signal classifier, but it > currently > * just shifts the static bitrate to mode mapping around a little bit. Yes, this is still accurate. This is an encoder-only control that is currently there as a base for future improvements. > 35) John Ridges reported an unreachable line on the list on Apr 13. The email was referring to a newer (development) version of the implementation in git, and which is not meant to be included in the RFC. --------------000101010109090701050906-- From rjsparks@nostrum.com Thu Apr 26 12:37:34 2012 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 5AFF221E80D6 for ; Thu, 26 Apr 2012 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2s19TkqLmrC for ; Thu, 26 Apr 2012 12:37:33 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88DAC21E8185 for ; Thu, 26 Apr 2012 12:37:33 -0700 (PDT) Received: from unexplicable.local (pool-71-244-61-199.dllstx.fios.verizon.net [71.244.61.199]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3QJbVMB058868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 14:37:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F99A3FB.2090601@nostrum.com> Date: Thu, 26 Apr 2012 14:37:31 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jean-Marc Valin References: <4F8F209F.90505@nostrum.com> <4F964021.1040707@mozilla.com> In-Reply-To: <4F964021.1040707@mozilla.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.244.61.199 is authenticated by a trusted mechanism) Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 26 Apr 2012 19:37:34 -0000 I've requested IETF LC for -12. Some continued discussion on a few points. On 4/24/12 12:54 AM, Jean-Marc Valin wrote: > > 3) The text in section 6.2 leaves the standardization status of Opus > > Custom very unclear. Is this, and the associated code, part of this > > standard? If so, "not supported by the main Opus specification" is very > > confusing. Please clarify this section. > > This paragraph was rewritten. The new text is: > > "Opus Custom is an OPTIONAL part of the specification that is defined to > handle special sample rates and frame rates that are not supported by the > main Opus specification. Use of Opus Custom is discouraged for all but > very > special applications for which a frame size different from 2.5, 5, 10, > or 20 ms is > needed (for either complexity or latency reasons). Because Opus Custom is > optional, applications using that part of the specification may not be > compatible > with other applications implementing Opus. In Opus Custom operation, > only the CELT layer is available, using the opus_custom_* function > calls in opus_custom.h." I think what you're trying to say (especially with the next to last sentence there) is that a stream encoded using Opus Custom cannot be expected to be decodable by all Opus implementations. Is there signaling inband about its use? If not, can the text say something about not using it unless you've told the recipient about it out of band? > > > > 5) It would help to be very explicit about bit order somewhere early in > > the document. Have I missed where this is discussed already? (See > > section 3.1's description of the "top five bits" - these aren't the most > > significant bits per the diagram). If there's the opportunity for > > ambiguity, please also make sure byte order is explicitly described. For > > instance, this would help the reader figure out which byte is len[1] and > > which is len[0] in section 3.2.1. > > This is probably due to the author's mis-understanding of the conventions > involved in these bit diagrams. In every other context, bit 0 is the least > significant, and bit 7 the most significant of a byte (and indeed this > seemed to be true from the examples in other drafts, but these were bad > examples). The diagrams have been updated to conform to the convention (as > near as can be reverse engineered) from, e.g., RFC 796, and an explanatory > note has been added to the beginning of section 3. Hopefully this makes > the diagrams clearer. This also required some changes in the text (to > reflect the ordering of fields, or where bits were referred to by number). This is a big chunk of change to the text, and done impressively quickly. It looks correctly executed to me. WG members should review this during IETF LC _very_ carefully. > > > > 16) The language in section A.2 will not age well after this is > > published as an RFC. At least add "As of the time of publication of this > > memo". It would also be good to clarify here that any changes in the > > repository and snapshots you are pointing to are NOT changes to the > > standard. > > Changed the text to be clearer: > "As of the time of publication of this memo, up-to-date source code > implementing > this standard is available in a Git repository." The section was also > renamed > "Up-to-date Implementation". Which still leaves confusion. The reference implementation is the code in the RFC. If the code in git changes (and you obviously expect it to change), it is no longer the reference implementation for this standard (it is a conforming implementation). It needs to be clearer that the code that's in this document remains normative. (if changes become necessary, they will be done with another RFC). > > > 17) Similarly, references to the active project from inside the code > > contained here will not age well. The github reference in the README for > > instance will almost certainly be wrong in a few years, and it > > introduces ambiguity about whether what it's pointing to is part of the > > standard. Please consider making a version of the README that's specific > > to this particular snapshot (and say "this RFC" or "this memo" there > > instead of "this draft") > > Replaced draft with "RFC" and marked the git repository as being the > "latest implementation of this standard at the time of publication" Same issue as above. Please make it clear that the RFC _remains_ the definition of the standard. > > > 29) include/opus_types.h contains a comment saying /* opus_types.h taken > > from libogg */. Please clarify - I don't think you meant to say this > > file was taken from the libogg source tree. What is it trying to say? > > Yes, this was taken (and modified) from the libogg source tree (was > originally called ogg_types). Probably should say "based on" instead of "taken from" then? RjS From rjsparks@nostrum.com Thu Apr 26 12:58:14 2012 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 8F9B021F87A0 for ; Thu, 26 Apr 2012 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyHuW2rZCzeu for ; Thu, 26 Apr 2012 12:58:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D524B21F879E for ; Thu, 26 Apr 2012 12:58:13 -0700 (PDT) Received: from unexplicable.local (pool-71-244-61-199.dllstx.fios.verizon.net [71.244.61.199]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3QJw77u062130 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 14:58:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F99A8CF.3000103@nostrum.com> Date: Thu, 26 Apr 2012 14:58:07 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ron References: <4F8F209F.90505@nostrum.com> <20120419130128.GE12062@audi.shelbyville.oz> In-Reply-To: <20120419130128.GE12062@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.244.61.199 is authenticated by a trusted mechanism) Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 26 Apr 2012 19:58:14 -0000 Note that I've requested IETF LC for version -12 (which includes this section). I'd like to continue this conversation. All the examples below are from before the current TLP (4) was in place. As you note the TLP does not restrict the authors from making the grants you describe. Why is it important to include this statement as part of _this_ document? If you are able to do what you need without the section (which is what I think you're saying below), removing it removes any _chance_ of confusion. If you are not able to do what you want without the section, we need to talk about the TLP. (If that's the case, could you call out the constraint that is in your way?) RjS On 4/19/12 8:01 AM, Ron wrote: > Hi Robert, > > I'll add my warm thanks for the obvious effort and attention that you've > put into reviewing this draft too. This is a non-trivial contribution > that I'm very happy to see. > > On Wed, Apr 18, 2012 at 03:14:23PM -0500, Robert Sparks wrote: >> 1) Section 10 (Copying considerations) appears to be trying to say >> something different from what the copyright notice on the first page >> says. Do we still need this section? Can it be removed at this time? > The intention of this section was to make explicit that the authors are > granting additional rights to those of the TLP. Similar to the grants > that were added in, for example: > > http://tools.ietf.org/html/rfc3492#appendix-B > http://tools.ietf.org/html/rfc4501#section-8 > http://tools.ietf.org/html/rfc5215#section-11 > http://tools.ietf.org/html/rfc5334#section-12 > > The main difference here was a desire to be clear that the source code > components were not included in this additional grant and remained under > the usual IETF BSD licence for such parts. > > While the TLP is fairly clear that the IETF avoids becoming involved in > making such additional grants and it is up to the document authors to > do so if they wish, there is no desire for this clause to add confusion; > so if there is better language that we should use there which fits with > the intent, then I'd welcome suggestions for how it might be improved. > > I requested that this be added so that we could include this text in the > supporting documentation of the Debian packages for libopus, which we > would not be able to do without this additional grant of rights. > > Best, > Ron > > From iesg-secretary@ietf.org Thu Apr 26 13:20:57 2012 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 C5A5521F87A2; Thu, 26 Apr 2012 13:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm3qhVGW3hr2; Thu, 26 Apr 2012 13:20:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD4321F866A; Thu, 26 Apr 2012 13:20:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2012 13:20:56 -0700 Cc: codec@ietf.org Subject: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:20:57 -0000 The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Definition of the Opus Audio Codec' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1712/ http://datatracker.ietf.org/ipr/1602/ http://datatracker.ietf.org/ipr/1445/ http://datatracker.ietf.org/ipr/1446/ http://datatracker.ietf.org/ipr/1447/ http://datatracker.ietf.org/ipr/1741/ http://datatracker.ietf.org/ipr/1670/ http://datatracker.ietf.org/ipr/1520/ http://datatracker.ietf.org/ipr/1524/ http://datatracker.ietf.org/ipr/1525/ http://datatracker.ietf.org/ipr/1526/ From tterribe@xiph.org Thu Apr 26 13:43:30 2012 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 0D60B21F8799 for ; Thu, 26 Apr 2012 13:43:30 -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 qokFxFGJavP7 for ; Thu, 26 Apr 2012 13:43:28 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 8054F21F879D for ; Thu, 26 Apr 2012 13:43:28 -0700 (PDT) Received: from [10.250.5.141] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id F09604AED81 for ; Thu, 26 Apr 2012 13:43:27 -0700 (PDT) Message-ID: <4F99B36F.8000908@xiph.org> Date: Thu, 26 Apr 2012 13:43:27 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120305 SeaMonkey/2.7.1 MIME-Version: 1.0 To: codec@ietf.org References: <4F8F209F.90505@nostrum.com> <4F964021.1040707@mozilla.com> <4F99A3FB.2090601@nostrum.com> In-Reply-To: <4F99A3FB.2090601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 26 Apr 2012 20:43:30 -0000 Robert Sparks wrote: > This is a big chunk of change to the text, and done impressively quickly. > It looks correctly executed to me. WG members should review this during > IETF LC > _very_ carefully. Yes, please. I asked a few others I knew had implemented Opus packet parsing about these diagrams and was told, "Oh yeah, I couldn't make heads or tails of them, so I just read the code." I'm glad Robert actually said something about them. From kpfleming@digium.com Thu Apr 26 14:03:50 2012 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 EDA3E21E80B0 for ; Thu, 26 Apr 2012 14:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4wlJUL1pIPd for ; Thu, 26 Apr 2012 14:03:49 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C546711E8073 for ; Thu, 26 Apr 2012 14:03:49 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SNVqv-0004XQ-17 for codec@ietf.org; Thu, 26 Apr 2012 16:03:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 0C6AFD8004 for ; Thu, 26 Apr 2012 16:03:49 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQZxPeSTQq9L for ; Thu, 26 Apr 2012 16:03:48 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 78CEFD8002 for ; Thu, 26 Apr 2012 16:03:48 -0500 (CDT) Message-ID: <4F99B829.8020400@digium.com> Date: Thu, 26 Apr 2012 16:03:37 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: codec@ietf.org References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> In-Reply-To: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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, 26 Apr 2012 21:03:51 -0000 On 04/26/2012 03:20 PM, The IESG wrote: > > The IESG has received a request from the Internet Wideband Audio Codec WG > (codec) to consider the following document: > - 'Definition of the Opus Audio Codec' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-05-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Now that this draft has reached IETF LC, is it time to resurrect the expired draft-spittka-payload-rtp-opus-00 and get it heading towards publication by the PAYLOAD WG as well? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From jmvalin@mozilla.com Thu Apr 26 15:24:24 2012 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 D28F621F87C6 for ; Thu, 26 Apr 2012 15:24:22 -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 ZWxpdQCZ9Ieq for ; Thu, 26 Apr 2012 15:24: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 557E721F87C3 for ; Thu, 26 Apr 2012 15:24:22 -0700 (PDT) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id C3E194AEDBB; Thu, 26 Apr 2012 15:24:21 -0700 (PDT) Message-ID: <4F99CB14.3040204@mozilla.com> Date: Thu, 26 Apr 2012 18:24:20 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Kevin P. Fleming" References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> In-Reply-To: <4F99B829.8020400@digium.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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, 26 Apr 2012 22:24:24 -0000 > Now that this draft has reached IETF LC, is it time to resurrect the > expired draft-spittka-payload-rtp-opus-00 and get it heading towards > publication by the PAYLOAD WG as well? Sounds like a good idea! Please send any comment you have. Jean-Marc From kpfleming@digium.com Thu Apr 26 15:43:45 2012 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 73D6721F87C4 for ; Thu, 26 Apr 2012 15:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.881 X-Spam-Level: X-Spam-Status: No, score=-105.881 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 tnVMBBAU6ev1 for ; Thu, 26 Apr 2012 15:43:44 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C990721F87BF for ; Thu, 26 Apr 2012 15:43:44 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SNXPc-0005kK-Dz for codec@ietf.org; Thu, 26 Apr 2012 17:43:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 67467D8004 for ; Thu, 26 Apr 2012 17:43:44 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS7cHpnbJ7PY for ; Thu, 26 Apr 2012 17:43:44 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id ED0EED8002 for ; Thu, 26 Apr 2012 17:43:43 -0500 (CDT) Message-ID: <4F99CF95.1040709@digium.com> Date: Thu, 26 Apr 2012 17:43:33 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 CC: codec@ietf.org References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> <4F99CB14.3040204@mozilla.com> In-Reply-To: <4F99CB14.3040204@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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, 26 Apr 2012 22:43:45 -0000 On 04/26/2012 05:24 PM, Jean-Marc Valin wrote: >> Now that this draft has reached IETF LC, is it time to resurrect the >> expired draft-spittka-payload-rtp-opus-00 and get it heading towards >> publication by the PAYLOAD WG as well? > > Sounds like a good idea! Please send any comment you have. Well, it seems like the first thing to do would be to request that PAYLOAD adopt it as a working document to meet the December 2012 milestone. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ron@debian.org Fri Apr 27 13:32:08 2012 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 747BF21F84E1 for ; Fri, 27 Apr 2012 13:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 qUfSVlcvaIpk for ; Fri, 27 Apr 2012 13:32:07 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD3321F8694 for ; Fri, 27 Apr 2012 13:32:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEEBm095LXH5/2dsb2JhbABEsgOBCIIJAQEEATocIwULCw4KLhQYDSQuh20Eu1mRHQSIYYUvh2wBkECCeA Received: from ppp121-45-113-249.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.113.249]) by ipmail05.adl6.internode.on.net with ESMTP; 28 Apr 2012 06:02:05 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D19DB4F8F3; Sat, 28 Apr 2012 06:02:03 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JbazZLf9ZmqT; Sat, 28 Apr 2012 06:02:03 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id EE5764F8FE; Sat, 28 Apr 2012 06:02:02 +0930 (CST) Date: Sat, 28 Apr 2012 06:02:02 +0930 From: Ron To: Robert Sparks Message-ID: <20120427203202.GN17863@audi.shelbyville.oz> References: <4F8F209F.90505@nostrum.com> <20120419130128.GE12062@audi.shelbyville.oz> <4F99A8CF.3000103@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F99A8CF.3000103@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: codec@ietf.org, codec-chairs@tools.ietf.org, draft-ietf-codec-opus@tools.ietf.org Subject: Re: [codec] AD review: draft-ietf-codec-opus-11 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, 27 Apr 2012 20:32:08 -0000 On Thu, Apr 26, 2012 at 02:58:07PM -0500, Robert Sparks wrote: > Note that I've requested IETF LC for version -12 (which includes > this section). > > I'd like to continue this conversation. > > All the examples below are from before the current TLP (4) was in place. Ah, that detail had slipped past me, though I did refer to the text of the current TLP to see if the reasons for adding this were still applicable. > As you note the TLP does not restrict the authors from making the > grants you describe. > Why is it important to include this statement as part of _this_ document? We could indeed include this as a separate, external, grant statement. It wasn't clear to me that this would be less confusing than having a single document with a grant similar to the previous examples, but that solution would also work for me, yes. The curious twist with this particular document is that the normative sections of it are the code, which are BSD licenced and allow the extra modification rights granted by section 10 - while the informative parts of the text may not be modified, and so could not be updated to document any changes made to a particular implementation of the code without this extra grant. Since the encoder specification is also not normative, and there is known scope to make improvements to it, the value of being able to do this, both to the people making such changes, and to the WG which may later find reason to fold them into an updated RFC, does seem more than just whimsical in this case. > If you are able to do what you need without the section (which is > what I think you're saying > below), removing it removes any _chance_ of confusion. > > If you are not able to do what you want without the section, we need > to talk about the TLP. > (If that's the case, could you call out the constraint that is in your way?) The restrictions on modification in 3.c and 3.d are I think the only part of the TLP that we'd need to waive to match the intent of section 10. The crux here (for me) is that Debian (among others) considers the right to modification an essential element to not spending our entire lives as developers reinventing the wheels of our fathers from scratch. Not having to ask permission (or to charter a WG) before performing some experiment (of which most will never go anywhere before being abandoned) is a powerful enabler of progress. The ones that are successful will naturally seek for broader acceptance and formalisation (and may then reasonably seek to engage with or charter a WG to do so). But being able to do (and publish) those initial experiments is an important part of the process. This WG has been a living testament to how the initial informal legwork to produce two good codecs could then come together in an open and formal collaboration and produce a result so far outstanding beyond prior art and expectations, that both doubters and advocates had to compete over whose jaws have since dropped the most. Signing off on that, and sealing it as an interoperable standard now seems correct. Erecting artificial barriers to further experimentation down these lines though, I'm less sure about ... The right to future experimentation does not conflict with the desire for a fixed standard guaranteeing interoperability today. Both are essential if progress is to continue its steady march. So if there is a possibility of future versions of the TLP finding some suitable language to accommodate this case, without the need for these additional grants, and while still meeting the concerns of the IETF about maintaining the integrity and reliability of its publications, then that would be a very interesting conversation to continue. Though it's surely out of the scope of this WG (and I'm not sure offhand exactly where the appropriate place for that would be). A grant which allowed modification, but which prohibited misrepresenting modified versions as an RFC, or which required attribution to the original document and source, would remove the blocking constraint. The former is the condition we placed on the extra grant in section 10, the latter is indicated by the current TLP, and would be an acceptable restriction if it also allowed for producing clearly marked, modified works outside of a formal working group. If nothing else, this would permit Debian to include the relevant RFCs in the documentation of packages which implement them. But my broader wish is for something a little more than that, for more than just Debian too. Cheers, Ron From fluffy@iii.ca Sun Apr 29 09:29:05 2012 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 8DFDE21F84EE for ; Sun, 29 Apr 2012 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 RbYAp0NpMKXU for ; Sun, 29 Apr 2012 09:29:04 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C89C121F84EA for ; Sun, 29 Apr 2012 09:29:04 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 40EA122E259; Sun, 29 Apr 2012 12:28:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F99B829.8020400@digium.com> Date: Sun, 29 Apr 2012 10:28:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> To: Kevin P. Fleming X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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: Sun, 29 Apr 2012 16:29:05 -0000 Yes, we should get draft-spittka-payload-rtp-opus-00 moving.=20 One suggestion on it ... I suspect it would be easier to get both the = RTP payload and storage format done quicker if they were separate into = two drafts. Clearly the payload needs to be done in PAYLOAD WG but folks = might want to ping the RAI and APPS ADs about where it makes sense to do = the storage format - might want to consider Apps for that.=20 On Apr 26, 2012, at 3:03 PM, Kevin P. Fleming wrote: > On 04/26/2012 03:20 PM, The IESG wrote: >>=20 >> The IESG has received a request from the Internet Wideband Audio = Codec WG >> (codec) to consider the following document: >> - 'Definition of the Opus Audio Codec' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-05-10. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >=20 > Now that this draft has reached IETF LC, is it time to resurrect the = expired draft-spittka-payload-rtp-opus-00 and get it heading towards = publication by the PAYLOAD WG as well? >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: = kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From tterribe@xiph.org Sun Apr 29 09:46:45 2012 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 7813921F84B4 for ; Sun, 29 Apr 2012 09:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 oCaG9pxxNvaU for ; Sun, 29 Apr 2012 09:46:44 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id A443D21F84B2 for ; Sun, 29 Apr 2012 09:46:44 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 324424AEE3B for ; Sun, 29 Apr 2012 09:46:44 -0700 (PDT) Message-ID: <4F9D7073.5050303@xiph.org> Date: Sun, 29 Apr 2012 09:46:43 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 CC: codec@ietf.org References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> In-Reply-To: <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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: Sun, 29 Apr 2012 16:46:45 -0000 Cullen Jennings wrote: > One suggestion on it ... I suspect it would be easier to get both the RTP > payload and storage format done quicker if they were separate into two drafts. > Clearly the payload needs to be done in PAYLOAD WG but folks might want to > ping the RAI and APPS ADs about where it makes sense to do the storage format > - might want to consider Apps for that. This makes a lot of sense. For the storage format, RFC 3533 (Ogg) was done in transport, IIRC. But Apps might be better. Should we be targeting standards-track or informational for it? From fluffy@iii.ca Sun Apr 29 12:07:51 2012 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 EF5AA21F85A1 for ; Sun, 29 Apr 2012 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 8b5iIrzdIbBB for ; Sun, 29 Apr 2012 12:07:50 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 719C721F8599 for ; Sun, 29 Apr 2012 12:07:50 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DC89322E253; Sun, 29 Apr 2012 15:07:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F9D7073.5050303@xiph.org> Date: Sun, 29 Apr 2012 13:07:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1F97A125-A0D2-4129-8179-30EA9F63588F@iii.ca> References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> <4F9D7073.5050303@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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: Sun, 29 Apr 2012 19:07:51 -0000 On Apr 29, 2012, at 10:46 AM, Timothy B. Terriberry wrote: > Cullen Jennings wrote: >> One suggestion on it ... I suspect it would be easier to get both the = RTP > > payload and storage format done quicker if they were separate into = two drafts. > > Clearly the payload needs to be done in PAYLOAD WG but folks might = want to > > ping the RAI and APPS ADs about where it makes sense to do the = storage format > > - might want to consider Apps for that. >=20 > This makes a lot of sense. For the storage format, RFC 3533 (Ogg) was = done in transport, IIRC. But Apps might be better. Should we be = targeting standards-track or informational for it? The RTP payload needs to be standards track but for the storage format, = I can't see much advantage of PS over Info and Info is typically faster = but not a big deal either way. I really don't know where the best place = to do it is because I suspect there are multiple places where it could = be done. But in cases like this, I like to go ask the ADs what they want = and then you don't have any later surprises and when people ask you why = you choose X instead of Y, you can just tell them the ADs told you so = and not have to spend time debating it.=20 From tterribe@xiph.org Sun Apr 29 12:27:14 2012 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 A49A721F85C0 for ; Sun, 29 Apr 2012 12:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 71e0EhDrcHpj for ; Sun, 29 Apr 2012 12:27:13 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 872EE21F856A for ; Sun, 29 Apr 2012 12:27:13 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id CD8714AEE3E for ; Sun, 29 Apr 2012 12:27:12 -0700 (PDT) Message-ID: <4F9D9610.4030608@xiph.org> Date: Sun, 29 Apr 2012 12:27:12 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: codec@ietf.org References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> <4F9D7073.5050303@xiph.org> <1F97A125-A0D2-4129-8179-30EA9F63588F@iii.ca> In-Reply-To: <1F97A125-A0D2-4129-8179-30EA9F63588F@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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: Sun, 29 Apr 2012 19:27:14 -0000 Cullen Jennings wrote: > cases like this, I like to go ask the ADs what they want and then you don't > have any later surprises and when people ask you why you choose X instead of > Y, you can just tell them the ADs told you so and not have to spend time > debating it. Okay, I'll clean up the storage spec we have in our wiki today and ping the ADs about it to see what they think. From stewe@stewe.org Mon Apr 30 15:53:21 2012 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 E8D7421E80F3; Mon, 30 Apr 2012 15:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.822 X-Spam-Level: X-Spam-Status: No, score=-3.822 tagged_above=-999 required=5 tests=[AWL=-0.223, 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 a244f2sqpV8g; Mon, 30 Apr 2012 15:53:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id D304121E80E2; Mon, 30 Apr 2012 15:53:20 -0700 (PDT) Received: from mail94-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Apr 2012 22:53:12 +0000 Received: from mail94-am1 (localhost [127.0.0.1]) by mail94-am1-R.bigfish.com (Postfix) with ESMTP id D0DCC4603EC; Mon, 30 Apr 2012 22:53:12 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz936eK1432N41c5N98dKzz1202h1082kzz8275ch1033IL8275dhz2fh2a8h668h839h944he5bh) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail94-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail94-am1 (localhost.localdomain [127.0.0.1]) by mail94-am1 (MessageSwitch) id 1335826389868658_9496; Mon, 30 Apr 2012 22:53:09 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.232]) by mail94-am1.bigfish.com (Postfix) with ESMTP id C66BC340045; Mon, 30 Apr 2012 22:53:09 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Apr 2012 22:53:09 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.237]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0143.004; Mon, 30 Apr 2012 22:53:13 +0000 From: Stephan Wenger To: SM , "ietf@ietf.org" , "codec@ietf.org" Thread-Topic: Last Call: (Definition of the Opus Audio Codec) to Proposed Standard Thread-Index: AQHNJyQFLlac4d7Mn0K5mHaRhatRkA== Date: Mon, 30 Apr 2012 22:53:13 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20120430120153.0947ed48@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "codec-chairs@tools.ietf.org" Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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, 30 Apr 2012 22:53:22 -0000 Hi, This subject was also raised by our AD on the codec mailing list. The statement is about spec text copyright (with the possible exception of the word "use", which is loaded in this context, see BSD license and implicit patent grant ambiguity). Insofar, the patent licensing statement received appear to be irrelevant to this discussion. Generally speaking, according to the TLP, the authors are free to provide a wider copyright grant than the TLP is providing, and they intend to do so with this section. See also here: http://www.ietf.org/mail-archive/web/codec/current/msg02845.html for some justification. The question of whether a section in the subject doc is the right place for such a grant has not yet been answered. My view on the latter: it's not. One issue of having such a notice is that it expressly allows derivative work, possibly WITHOUT removing the IETF boilerplate and the TLP copyright notice first. This would go against language and spirit of the TLP. We (the IETF) does NOT want and do not allow derivative work of our specs outside of the IETF process. The authors are free to publish the opus spec elsewhere, with whatever copyright grants they wish to attach to. But they should first remove any references of the doc being an IETF-RFC or , more precisely, falling under the TLP. =20 Stephan On 4.30.2012 21:05 , "SM" wrote: >At 13:20 26-04-2012, The IESG wrote: >>The IESG has received a request from the Internet Wideband Audio Codec WG >>(codec) to consider the following document: >>- 'Definition of the Opus Audio Codec' >> as a Proposed Standard > >Section 10 about "copying conditions" mentions "without >royalty". There was a message to the CODEC mailing list about the >Qualcomm IPR disclosure. The Licensing declaration in the Huawei IPR >disclosures do not mention royalty-free. Was that taken into account >by the authors for the statement in Section 10? > >Could the authors please clarify what they mean by "the work" in the >following: > > "The authors agree to grant third parties the irrevocable right to > copy, use and distribute the work (excluding Code Components > available under the simplified BSD license)" > >Regards, >-sm =20 > > From ron@debian.org Mon Apr 30 18:40:43 2012 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 AF2A521E80F4; Mon, 30 Apr 2012 18:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 cu2obWOmrXZM; Mon, 30 Apr 2012 18:40:43 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id B8FEB21E8011; Mon, 30 Apr 2012 18:40:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAGQ+n095LXH5/2dsb2JhbABEr2aCf4EIggkBAQU6HCMQCw4KIwsUGA0kiB+6NZAsYwSIYoUvh2wBkEKCeA Received: from ppp121-45-113-249.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.113.249]) by ipmail06.adl6.internode.on.net with ESMTP; 01 May 2012 11:10:40 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 68A224F8F3; Tue, 1 May 2012 11:10:38 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rcjKB0XYAb4z; Tue, 1 May 2012 11:10:37 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C8FD54F8FE; Tue, 1 May 2012 11:10:37 +0930 (CST) Date: Tue, 1 May 2012 11:10:37 +0930 From: Ron To: Stephan Wenger Message-ID: <20120501014037.GA18009@audi.shelbyville.oz> References: <6.2.5.6.2.20120430120153.0947ed48@resistor.net> 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) Cc: SM , "codec-chairs@tools.ietf.org" , "codec@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Definition of the Opus Audio Codec) to Proposed Standard 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 May 2012 01:40:43 -0000 Hi Stephan, On Mon, Apr 30, 2012 at 10:53:13PM +0000, Stephan Wenger wrote: > The question of whether a section in the subject doc is > the right place for such a grant has not yet been answered. > My view on the latter: it's not. One issue of having such a notice is > that it expressly allows derivative work, possibly WITHOUT removing the > IETF boilerplate and the TLP copyright notice first. Except that the additional grant explicitly requires that: "redistributed modified works do not contain misleading author, version, name of work, or endorsement information." And my understanding is that the sort of misrepresentations which you suggest are already well protected against in established law. So I don't think that this would weaken the IETF's position in the event of such a thing happening, and I'm not aware of any such problem occurring with any of the RFCs that are already published containing such a grant. Similarly there exist other RFCs which already have external grants too, and there has been no hint of trouble or an inability to prevent it if it arose with those either, has there? If this clause becomes a blocker, then we should simply remove it, but in that case it would be good to have clear reasons why it became a blocker, since the things you say you fear here, I see as already being prohibited anyway. I agree with you that this is an entirely separate issue to the validity or other implications of any of the IPR claims though. But on that note, have you had any clarification from Huawei as to whether they believe their newly acquired patent actually does read on this technology? Last I had heard on that there was some doubt and they were still studying it? It would be nice to have them officially clear that up. Cheers, Ron