From mknappe@juniper.net Thu Sep 2 06:29:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4AA3A68DE for ; Thu, 2 Sep 2010 06:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.689 X-Spam-Level: X-Spam-Status: No, score=-104.689 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31-nw-eyQ27g for ; Thu, 2 Sep 2010 06:29:02 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id B6E583A688C for ; Thu, 2 Sep 2010 06:29:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTH+mu8W2y/o+dkkPjkrI1TWtu/6xs1NV@postini.com; Thu, 02 Sep 2010 06:29:33 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Sep 2010 06:25:35 -0700 From: Michael Knappe To: Roman Shpount Date: Thu, 2 Sep 2010 06:25:32 -0700 Thread-Topic: [codec] Semi-formal codec quality testing Thread-Index: ActIf0BMnV8kYK8US02iqCeRYH1UGACIxELe Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Semi-formal codec quality testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:29:04 -0000 Roman, Requirements are hopefully quite reasonable: A) a quiet =91NC25=92 listening environment of approx 35 dBA or less ambien= t noise. Not a necessity to be an acoustically treated room for reverberati= on control given that listening will done over headphones, but it doesn=92t= hurt either. This can be an existing room, but an ISOBOOTH will also work = great. B) a computer that can run a MUSHRA assessment tool (like RateIt or MUSHRAM= ) C) a high quality D/A convertor connected via USB or Firewire to the assess= ment computer (e.g. Benchmark DAC, Metric Halo ULN-2, Apogee miniDAC) D) high quality headphone amp and playback level calibration (many good con= vertors like the Metric Halo also have a good quality headphone amp built i= n) - playback calibration can be set via an Etymotic in-ear microphone =96 = we=92ll decide on a standard calibration scheme shortly E) high quality headphones =96 a decent set of dynamic headphones with flat= frequency response and reasonably detailed (e.g. AKG 240DF, Sennheiser HD6= 00), Stax electrostatics also great. Let me know if you have any questions at all, Cheers, Mike On 8/30/10 1:09 PM, "Roman Shpount" wrote: Can you provide a brief description of test site requirements that are need= ed to participate in this? What do you consider a reasonable playback envir= onment? Would we need regular or trained listeners? _____________ Roman Shpount On Fri, Aug 27, 2010 at 6:07 PM, Michael Knappe wrote= : As discussed at IETF78, we=92d like to see a number of organizations / corp= orations donate time and effort to participate in =91semi-formal=92 audio q= uality testing of the output of this working group. This would not be a pai= d activity, and would require each organization to provide a suitable liste= ning environment and playback equipment chain for their testing. My estimat= e is that a reasonable controlled playback environment can be put together = for approximately 5-10K, but many organizations interested in this activity= are likely to already possess the bulk of the setup. If you=92re interested, please email back so I can get an estimate of the n= umber of independent test sites we=92ll eventually have, and we=92ll begin = the process of collaborating on the mailing list to put together source mat= erial, test cases, etc. Cheers, Mike _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Thu Sep 2 06:31:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A553A695D for ; Thu, 2 Sep 2010 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.943 X-Spam-Level: X-Spam-Status: No, score=-105.943 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfCu6ff4VYrK for ; Thu, 2 Sep 2010 06:31:42 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 47C4C3A68DE for ; Thu, 2 Sep 2010 06:31:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTH+nWuLdQLcSYCwTtC/vdzj01gdisIXY@postini.com; Thu, 02 Sep 2010 06:32:12 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Sep 2010 06:29:25 -0700 From: Michael Knappe To: Roman Shpount Date: Thu, 2 Sep 2010 06:29:22 -0700 Thread-Topic: [codec] Semi-formal codec quality testing Thread-Index: ActIf0BMnV8kYK8US02iqCeRYH1UGACIxELeAAAiRtA= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Semi-formal codec quality testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:31:43 -0000 Forgot to add that a demographic cross-section of regular listeners is pref= erred, but will also be useful to run tests with expert listeners as well. Cheers, Mike On 9/2/10 6:25 AM, "Michael Knappe" wrote: Roman, Requirements are hopefully quite reasonable: A) a quiet =91NC25=92 listening environment of approx 35 dBA or less ambien= t noise. Not a necessity to be an acoustically treated room for reverberati= on control given that listening will done over headphones, but it doesn=92t= hurt either. This can be an existing room, but an ISOBOOTH will also work = great. B) a computer that can run a MUSHRA assessment tool (like RateIt or MUSHRAM= ) C) a high quality D/A convertor connected via USB or Firewire to the assess= ment computer (e.g. Benchmark DAC, Metric Halo ULN-2, Apogee miniDAC) D) high quality headphone amp and playback level calibration (many good con= vertors like the Metric Halo also have a good quality headphone amp built i= n) - playback calibration can be set via an Etymotic in-ear microphone =96 = we=92ll decide on a standard calibration scheme shortly E) high quality headphones =96 a decent set of dynamic headphones with flat= frequency response and reasonably detailed (e.g. AKG 240DF, Sennheiser HD6= 00), Stax electrostatics also great. Let me know if you have any questions at all, Cheers, Mike On 8/30/10 1:09 PM, "Roman Shpount" wrote: Can you provide a brief description of test site requirements that are need= ed to participate in this? What do you consider a reasonable playback envir= onment? Would we need regular or trained listeners? _____________ Roman Shpount On Fri, Aug 27, 2010 at 6:07 PM, Michael Knappe wrote= : As discussed at IETF78, we=92d like to see a number of organizations / corp= orations donate time and effort to participate in =91semi-formal=92 audio q= uality testing of the output of this working group. This would not be a pai= d activity, and would require each organization to provide a suitable liste= ning environment and playback equipment chain for their testing. My estimat= e is that a reasonable controlled playback environment can be put together = for approximately 5-10K, but many organizations interested in this activity= are likely to already possess the bulk of the setup. If you=92re interested, please email back so I can get an estimate of the n= umber of independent test sites we=92ll eventually have, and we=92ll begin = the process of collaborating on the mailing list to put together source mat= erial, test cases, etc. Cheers, Mike _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From Anisse.Taleb@huawei.com Thu Sep 2 07:19:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEDA3A6A27 for ; Thu, 2 Sep 2010 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9teDnfncAtG for ; Thu, 2 Sep 2010 07:19:38 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A78BA3A6A00 for ; Thu, 2 Sep 2010 07:19:38 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8400GNEIHJUQ@usaga01-in.huawei.com> for codec@ietf.org; Thu, 02 Sep 2010 07:20:07 -0700 (PDT) Received: from Moou ([210.21.213.195]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0L8400LSIIGY2J@usaga01-in.huawei.com> for codec@ietf.org; Thu, 02 Sep 2010 07:20:07 -0700 (PDT) Date: Thu, 02 Sep 2010 16:19:47 +0200 From: Anisse Taleb In-reply-to: To: 'Michael Knappe' , 'Roman Shpount' Message-id: <009301cb4aa9$f26d5110$d747f330$%taleb@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: sv Content-transfer-encoding: 7BIT Thread-index: ActIf0BMnV8kYK8US02iqCeRYH1UGACIxELeAAAiRtAAAZwz4A== References: Cc: codec@ietf.org Subject: Re: [codec] Semi-formal codec quality testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:19:39 -0000 Dear Michael, I wonder what do you mean by Regular listeners ? Note that according to BS.1534 (Mushra), quoted section 4. for conveninece : " Although the MUSHRA test method is not intended to be applied to small impairments, it is still recommended that experienced listeners should be used. These listeners should have experience in listening to sound in a critical way. Such listeners will give a more reliable result more quickly than non-experienced listeners. It is also important to note that most non-experienced listeners tend to become more sensitive to the various types of artefacts after frequent exposure." Kind regards, /Anisse > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Michael Knappe > Sent: den 2 september 2010 15:29 > To: Roman Shpount > Cc: codec@ietf.org > Subject: Re: [codec] Semi-formal codec quality testing > > Forgot to add that a demographic cross-section of regular listeners is > preferred, but will also be useful to run tests with expert listeners > as well. > > Cheers, > > Mike > > > On 9/2/10 6:25 AM, "Michael Knappe" wrote: > > Roman, > > Requirements are hopefully quite reasonable: > > A) a quiet 'NC25' listening environment of approx 35 dBA or less > ambient noise. Not a necessity to be an acoustically treated room for > reverberation control given that listening will done over headphones, > but it doesn't hurt either. This can be an existing room, but an > ISOBOOTH will also work great. > B) a computer that can run a MUSHRA assessment tool (like RateIt or > MUSHRAM) > C) a high quality D/A convertor connected via USB or Firewire to the > assessment computer (e.g. Benchmark DAC, Metric Halo ULN-2, Apogee > miniDAC) > D) high quality headphone amp and playback level calibration (many good > convertors like the Metric Halo also have a good quality headphone amp > built in) - playback calibration can be set via an Etymotic in-ear > microphone - we'll decide on a standard calibration scheme shortly > E) high quality headphones - a decent set of dynamic headphones with > flat frequency response and reasonably detailed (e.g. AKG 240DF, > Sennheiser HD600), Stax electrostatics also great. > > Let me know if you have any questions at all, > > Cheers, > > Mike > > > On 8/30/10 1:09 PM, "Roman Shpount" wrote: > > Can you provide a brief description of test site requirements that are > needed to participate in this? What do you consider a reasonable > playback environment? Would we need regular or trained listeners? > _____________ > Roman Shpount > > > On Fri, Aug 27, 2010 at 6:07 PM, Michael Knappe > wrote: > As discussed at IETF78, we'd like to see a number of organizations / > corporations donate time and effort to participate in 'semi-formal' > audio quality testing of the output of this working group. This would > not be a paid activity, and would require each organization to provide > a suitable listening environment and playback equipment chain for their > testing. My estimate is that a reasonable controlled playback > environment can be put together for approximately 5-10K, but many > organizations interested in this activity are likely to already possess > the bulk of the setup. > > If you're interested, please email back so I can get an estimate of the > number of independent test sites we'll eventually have, and we'll begin > the process of collaborating on the mailing list to put together source > material, test cases, etc. > > Cheers, > > Mike > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Thu Sep 2 07:44:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853713A6A56 for ; Thu, 2 Sep 2010 07:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXCGiREM3cjw for ; Thu, 2 Sep 2010 07:44:57 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 7F7F43A6A55 for ; Thu, 2 Sep 2010 07:44:56 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Sep 2010 10:45:25 -0400 Message-ID: <4C7FB885.1010404@octasic.com> Date: Thu, 02 Sep 2010 10:45:25 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Anisse Taleb References: <009301cb4aa9$f26d5110$d747f330$%taleb@huawei.com> In-Reply-To: <009301cb4aa9$f26d5110$d747f330$%taleb@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2010 14:45:25.0808 (UTC) FILETIME=[7AABFB00:01CB4AAD] Cc: codec@ietf.org Subject: Re: [codec] Semi-formal codec quality testing X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:44:58 -0000 Hi, > Such listeners will give a more reliable result more quickly than > non-experienced listeners. From my experience, this shouldn't be too much of a problem because unless two codecs are very close in quality, MUSHRA tends to produce statistically significant results pretty quickly, even with naive listeners. This is what happened with the informal listening test we did on the hybrid codec. That being said, it surely wouldn't hurt have some experienced listeners to confirm any results we get with naive listeners. Cheers, Jean-Marc On 10-09-02 10:19 AM, Anisse Taleb wrote: > Dear Michael, > > I wonder what do you mean by Regular listeners ? Note that according to > BS.1534 (Mushra), quoted section 4. for conveninece : > > " Although the MUSHRA test method is not intended to be applied to small > impairments, it is still > recommended that experienced listeners should be used. These listeners > should have experience in > listening to sound in a critical way. Such listeners will give a more > reliable result more quickly than > non-experienced listeners. It is also important to note that most > non-experienced listeners tend to > become more sensitive to the various types of artefacts after frequent > exposure." > > > Kind regards, > /Anisse > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Michael Knappe >> Sent: den 2 september 2010 15:29 >> To: Roman Shpount >> Cc: codec@ietf.org >> Subject: Re: [codec] Semi-formal codec quality testing >> >> Forgot to add that a demographic cross-section of regular listeners is >> preferred, but will also be useful to run tests with expert listeners >> as well. >> >> Cheers, >> >> Mike >> >> >> On 9/2/10 6:25 AM, "Michael Knappe" wrote: >> >> Roman, >> >> Requirements are hopefully quite reasonable: >> >> A) a quiet 'NC25' listening environment of approx 35 dBA or less >> ambient noise. Not a necessity to be an acoustically treated room for >> reverberation control given that listening will done over headphones, >> but it doesn't hurt either. This can be an existing room, but an >> ISOBOOTH will also work great. >> B) a computer that can run a MUSHRA assessment tool (like RateIt or >> MUSHRAM) >> C) a high quality D/A convertor connected via USB or Firewire to the >> assessment computer (e.g. Benchmark DAC, Metric Halo ULN-2, Apogee >> miniDAC) >> D) high quality headphone amp and playback level calibration (many good >> convertors like the Metric Halo also have a good quality headphone amp >> built in) - playback calibration can be set via an Etymotic in-ear >> microphone - we'll decide on a standard calibration scheme shortly >> E) high quality headphones - a decent set of dynamic headphones with >> flat frequency response and reasonably detailed (e.g. AKG 240DF, >> Sennheiser HD600), Stax electrostatics also great. >> >> Let me know if you have any questions at all, >> >> Cheers, >> >> Mike >> >> >> On 8/30/10 1:09 PM, "Roman Shpount" wrote: >> >> Can you provide a brief description of test site requirements that are >> needed to participate in this? What do you consider a reasonable >> playback environment? Would we need regular or trained listeners? >> _____________ >> Roman Shpount >> >> >> On Fri, Aug 27, 2010 at 6:07 PM, Michael Knappe >> wrote: >> As discussed at IETF78, we'd like to see a number of organizations / >> corporations donate time and effort to participate in 'semi-formal' >> audio quality testing of the output of this working group. This would >> not be a paid activity, and would require each organization to provide >> a suitable listening environment and playback equipment chain for their >> testing. My estimate is that a reasonable controlled playback >> environment can be put together for approximately 5-10K, but many >> organizations interested in this activity are likely to already possess >> the bulk of the setup. >> >> If you're interested, please email back so I can get an estimate of the >> number of independent test sites we'll eventually have, and we'll begin >> the process of collaborating on the mailing list to put together source >> material, test cases, etc. >> >> Cheers, >> >> Mike >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Tue Sep 7 05:47:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB313A6A12 for ; Tue, 7 Sep 2010 05:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvFPUxW1Lwi7 for ; Tue, 7 Sep 2010 05:47:01 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id C83FE3A68F8 for ; Tue, 7 Sep 2010 05:47:00 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Sep 2010 08:47:28 -0400 Message-ID: <4C863460.5030903@octasic.com> Date: Tue, 07 Sep 2010 08:47:28 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2010 12:47:28.0484 (UTC) FILETIME=[D452CA40:01CB4E8A] Subject: [codec] Development update X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 12:47:07 -0000 Hi, For those interested in following the codec development, I just thought I'd point a (non-exhaustive) TODO list on the wiki http://trac.tools.ietf.org/wg/codec/trac/wiki/Hybrid_TODO as well as some recent posts on my blog: http://jmspeex.livejournal.com/ As usual, the code is available in git at git://git.xiph.org/users/jm/ietfcodec.git with the latest commit information at http://git.xiph.org/?p=users/jm/ietfcodec.git Cheers, Jean-Marc From mknappe@juniper.net Fri Sep 10 08:54:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DBF3A6835 for ; Fri, 10 Sep 2010 08:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.984 X-Spam-Level: X-Spam-Status: No, score=-105.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb0bkF1tS7TA for ; Fri, 10 Sep 2010 08:54:45 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3964E3A6846 for ; Fri, 10 Sep 2010 08:54:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTIpU3QzXP6V52DtncbdWdkCrZ98XdtXJ@postini.com; Fri, 10 Sep 2010 08:55:12 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 10 Sep 2010 08:51:50 -0700 From: Michael Knappe To: Jean-Marc Valin , "codec@ietf.org" Date: Fri, 10 Sep 2010 08:51:47 -0700 Thread-Topic: [codec] Comments on draft-valin-codec-guidelines-05.txt Thread-Index: ActD2KufWGnEIN4IRUSzdeXh2THrPwNJ2dVX Message-ID: In-Reply-To: <4C744278.5040506@octasic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] Comments on draft-valin-codec-guidelines-05.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 15:54:46 -0000 Everyone, If you haven't already, please review Jean-Marc's latest version of the guidelines (draft-valin-codec-guidelines-06) which can be found at: http://datatracker.ietf.org/doc/draft-valin-codec-guidelines/ Please reply to the mailing list with any comments you have on this iteration, let's get this one ready to bring in as a WG -00. Cheers, Mike On 8/24/10 3:06 PM, "Jean-Marc Valin" wrote: > Hi Stephen, everyone, >=20 > On 10-08-24 02:39 PM, Stephan Wenger wrote: >>> These were the subject of some debate at the previous meeting, so I'm >>> not addressing it right now. >>=20 >> That's fine and the right approach. However, I believe we need to come = to a >> consensus of some form of a working assumption for all three questions >> before it makes sense to accept the draft as a WG document. >=20 > We need consensus on everything before going to WGLC, but I don't see why > we need it for having this as a WG item. >=20 >> Here, and also later, I use the term "technology draft" or "technology R= FC" >> for the textual description of the final codec; it's called "Specificati= on >> of a codec" in the charter. The charter currently does not reflect dire= ctly >> the (perceived?) need for a permanent document covering the reference >> implementation. I'm in favor of such a document (std track or informati= onal >> RFC), and I'm in favor of putting the code into its own, code-only docum= ent >> and not into a section of the specification RFC, for size reasons (one n= ever >> knows--perhaps there will be a FPO and an integer reference implementati= on >> at some point, or more than one specifictaion covering different operati= on >> points, and so on). >=20 > We definitely need a place to put the reference implementation. I also > agree that having the entire code in the appendix of an RFC is a bit > inconvenient. Now the question is where should that code live? Does the > IETF have a more convenient way to hold source code than 72-column ASCII? > Any suggestion on where to put the reference implementation? There's also > the question of what the reference implementation should look like. Shoul= d > it be just floating point, just fixed-point, both? Should it be reasonabl= y > optimised (without anything platform-specific) or should the code be > optimised for readability rather than speed? >=20 >>>> 14. 4. Requirements..., third paragraph, =B3normative=B2. =B3normat= ive >>>> requirements=B2 is wrong here. What we are talking here are nei= ther >>>> requirements, nor are they normative. Tightening up the languag= e >>>> is left an an exercise to the reader. :-) >>>=20 >>> I'm talking about minimizing the number of MUSTs required to be >>> compliant with the standard. How would you phrase that? >>=20 >> Perhaps out of content, but that is what I think we could say: "It is th= e >> intention of the group to allow the greatest possible choice of freedom = in >> implementing the specification. Accordingly, the number of binding RFC2= 119 >> keywords is going to be the minimum still allowing for interopable >> implementations." >=20 > Thanks for the suggestion. I've added it as is. >=20 >> You know that you are binding your hands with such a formulation? In a >> highly contested area, all kinds of political compromises end up in deal= s >> such as "if you MUST implement my patent, then I MUST implement yours" a= nd >> so on. (Although the opposite case--removing MUST requirements in favor= of >> unmotivated SHOULD or MAY is much more the norm.) >=20 > The reasoning for having as little binding keywords is mainly technical. = It > will allow future encoders to produce better quality audio than what the > reference encoder will do. MP3 is a good example of that. Current encoder= s > are *much* better than the original ones (which were already much better > than the really bad reference implementation). >=20 >>>=20 >>>> 15. 4. Requirements..., fourth paragraph: I don=B9t think we have >>>> consensus re bit-exact decoders (or lack thereof). There is a >>>> whole can of licensing worms attached to non-bit-exact decoders= . >>>> Suggest to strike this paragraph, or, at least, document the la= ck >>>> of WG consensus before accepting this as WG item (alternatively= , >>>> force consensus now, but I don=B9t think all the facts are on t= he >>>> table and sufficiently discussed yet). >>>=20 >>> IIRC most WG participants agreed that we didn't need to "force" >>> implementers to be bit-exact as long as they had bit-exactness as an >>> option to simplify implementation. After all, forcing bit exactness >>> means one can never use floating-point. >>=20 >> Up to the chairs to make a consensus call. >=20 > Well, that's in the minutes anyway. I remember people saying that > bit-exactness can be *useful* and I agree. The current text just says tha= t > that you don't *have* to be bit-exact to be conformant, it doesn't say yo= u > can't be if you want to save time on testing. >=20 >>> Already saying "Unless a particular profile is defined", not that there >>> will be profiles. I don't think we've ever discussed whether profiles >>> are acceptable or not, so I'm leaving this hear. That being said, the >>> codec we proposed does not have profiles. >>=20 >> I don't care about your proposal, nor should you as the editor of this >> draft. This is one of the problems we have with the composition of this >> WG... >> That said, on the subject matter, I'm fairly neutral, and I should have >> expressed myself. What I aimed to say was that I don't think we have an= y >> consensus in this area yet. >=20 > Exactly. Which is why the current wording does not say whether profiles a= re > good or bad. And even if/when we decide on having profiles or not having > them, I don't think that belongs to the guidelines. >=20 >> Let me give it a stab: >>=20 >> I believe the business intention is not to require error concealment at = all. >> Accordingly, there cannot be a conformance test for error concealment. = It >> can be subject to characterization tests, though... >>=20 >> So this is what could go in 4.4: >> To ensure freedom of implementation, decoder-side only error concealment >> does not need to be specified, although an informal description of the >> reference implementation's PLC algorithm, if any, is desirable. Obvious= ly, >> any information signaled in the bitstream intended to aid PLC needs to b= e >> specified. >=20 > Used your suggestion again, though I changed the first sentence to: >=20 > To ensure freedom of implementation, decoder-side only error concealment > does not need to be specified, although the reference implementation shou= ld > include the same PLC algorithm as used in the testing phase. >=20 > Just like the reference implementation needs to contain a working encoder > (even though the encoder would not be strictly specified), I also think t= he > PLC should be part of the reference implementation (not just an informal > description). >=20 >> And move the sentence about minimum requirements of PLC efficiency to an >> appropriate place in section 3. >=20 > Left it in that section because it's still talking about normative issues= , > not really about testing to decide whether we did a good job with the cod= ec. >=20 > Cheers, >=20 > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From root@core3.amsl.com Fri Sep 10 14:00:01 2010 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E40493A6B1B; Fri, 10 Sep 2010 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100910210001.E40493A6B1B@core3.amsl.com> Date: Fri, 10 Sep 2010 14:00:01 -0700 (PDT) Cc: codec@ietf.org Subject: [codec] I-D Action:draft-ietf-codec-description-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Definition of the IETF Interactive Audio Codec Author(s) : J. Valin, K. Vos Filename : draft-ietf-codec-description-00.txt Pages : 12 Date : 2010-09-10 This document describes a codec designed for interactive speech and audio transmission over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-description-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-codec-description-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-10135216.I-D@ietf.org> --NextPart-- From gmaxwell@juniper.net Thu Sep 23 11:47:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18E93A6A30 for ; Thu, 23 Sep 2010 11:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLoGTYvQw+vq for ; Thu, 23 Sep 2010 11:46:55 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 8E16D3A67D4 for ; Thu, 23 Sep 2010 11:46:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTJugvOkUgst9tz+E0Bd6Wh+D4ofIHI74@postini.com; Thu, 23 Sep 2010 11:47:25 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 23 Sep 2010 11:45:53 -0700 From: Gregory Maxwell To: "codec@ietf.org" Date: Thu, 23 Sep 2010 11:45:52 -0700 Thread-Topic: A Digital Media Primer for Geeks Thread-Index: AQHLW0+MINFaFdGBzEmw5byvp4Za5g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [codec] A Digital Media Primer for Geeks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 18:47:03 -0000 For a number of weeks a number of people involved with Xiph.Org have been w= orking on an introductory video for a technical audience about digital mult= imedia. This first video covers only the very most basic material=97 basically digi= tization and signal representations for audio and video=97, so it probably = isn't news to many of the people in this working group. But I expect that s= ome people with more 'protocol' than signal processing background will find= it informative. Hopefully we'll have the opportunity to produce follow on material to each = everyone else everything we know about this subject area. The video is available at http://www.xiph.org/video/ and there is also a "Wiki edition" of this project, at http://wiki.xiph.org= /A_Digital_Media_Primer_For_Geeks_%28episode_1%29 which links extensively= to third party resources for those eager to continue learning beyond the s= tarting point the video provides. Feedback, and especially additional refe= rences for the Wiki would be greatly appropriated. Enjoy, =20 From jdrosen@jdrosen.net Fri Sep 24 11:29:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F8E3A6AA2 for ; Fri, 24 Sep 2010 11:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.335 X-Spam-Level: X-Spam-Status: No, score=-101.335 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laq3R6SPgv3I for ; Fri, 24 Sep 2010 11:29:27 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id 8F1073A6A96 for ; Fri, 24 Sep 2010 11:29:27 -0700 (PDT) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OzD0k-0007dE-OZ for codec@ietf.org; Fri, 24 Sep 2010 14:28:42 -0400 Message-ID: <4C9CEE29.1090600@jdrosen.net> Date: Fri, 24 Sep 2010 14:30:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [codec] Adopting draft-valin-codec-guidelines-06 as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 18:29:28 -0000 At the last IETF meeting, we discussed adopting the codec guidelines document as a working group item. This did not pass, due to concerns over whether it was in the right direction. We put out a call for alternative documents over the next 5 week period. Some text was proposed by Stephan for inclusion, which was incorporated into the document. Stephan also contributed some comments, including a few open issues which still require some discussion. However, the chairs feel that it is not necessary for all open items to be closed prior to adopting a document as a working group item. Indeed, discussion on the content of the document is a good sign that it is a reasonable foundation for the working group item. Given the lack of alternative documents to use as a starting point, the chairs plan on adopting this as a working group item in two weeks time. If you disagree, please speak up - and even better - submit an alternative document. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From jdrosen@jdrosen.net Fri Sep 24 12:08:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E543A69E3 for ; Fri, 24 Sep 2010 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-LFDXgZmDbM for ; Fri, 24 Sep 2010 12:08:37 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id 0511C3A6783 for ; Fri, 24 Sep 2010 12:08:37 -0700 (PDT) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OzDce-00012o-6m for codec@ietf.org; Fri, 24 Sep 2010 15:07:52 -0400 Message-ID: <4C9CF757.9090705@jdrosen.net> Date: Fri, 24 Sep 2010 15:09:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 19:08:38 -0000 One of the open issues we need to close on - and document in the guidelines specification - is what the format of our codec specification deliverable will be. Firstly - one thing is clear - whatever the format is (code or textual descriptions) - it needs to be in an RFC. Including source code into an RFC is not ideal, but for purposes of IETF process that is the only thing we can officially produce. Participants can of course place that code in any repository they like, and we can even include a link to it in the RFC. However, the formal normative specification of the codec must be within a standards track RFC. In terms of whether the specification is code, text, or both - we need to gain consensus on this. It is my understanding that source code is ultimately the most exact way to specify the codec. A detailed description is also included, and in case of conflict, the code would win. In IETF terms this means that the code is actually the normative specification. iLBC includes the code itself in an appendix. As such, it would seem to make sense to follow this precedent. Thus, our deliverable would be a single document, containing a reasonably detailed codec description, along with an appendix containing the actual code. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From kpfleming@digium.com Fri Sep 24 12:13:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD4D3A67A3 for ; Fri, 24 Sep 2010 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.155 X-Spam-Level: X-Spam-Status: No, score=-105.155 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfimioRiveN3 for ; Fri, 24 Sep 2010 12:13:14 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 1B0E63A69E3 for ; Fri, 24 Sep 2010 12:13:14 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OzDiL-0006pW-T6 for codec@ietf.org; Fri, 24 Sep 2010 14:13:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id D353AD8194 for ; Fri, 24 Sep 2010 14:13:45 -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 qNU75hDCZAhp for ; Fri, 24 Sep 2010 14:13:45 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 833E8D8192 for ; Fri, 24 Sep 2010 14:13:45 -0500 (CDT) Message-ID: <4C9CF869.9050509@digium.com> Date: Fri, 24 Sep 2010 14:13:45 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: codec@ietf.org References: <4C9CF757.9090705@jdrosen.net> In-Reply-To: <4C9CF757.9090705@jdrosen.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Kevin P. Fleming" List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 19:13:18 -0000 On 09/24/2010 02:09 PM, Jonathan Rosenberg wrote: > One of the open issues we need to close on - and document in the > guidelines specification - is what the format of our codec specification > deliverable will be. > > Firstly - one thing is clear - whatever the format is (code or textual > descriptions) - it needs to be in an RFC. Including source code into an > RFC is not ideal, but for purposes of IETF process that is the only > thing we can officially produce. Participants can of course place that > code in any repository they like, and we can even include a link to it > in the RFC. However, the formal normative specification of the codec > must be within a standards track RFC. > > In terms of whether the specification is code, text, or both - we need > to gain consensus on this. It is my understanding that source code is > ultimately the most exact way to specify the codec. A detailed > description is also included, and in case of conflict, the code would > win. In IETF terms this means that the code is actually the normative > specification. > > iLBC includes the code itself in an appendix. As such, it would seem to > make sense to follow this precedent. Thus, our deliverable would be a > single document, containing a reasonably detailed codec description, > along with an appendix containing the actual code. This makes sense to me; my only reservation would be that we can't allow the situation with iLBC licensing to exist with this codec. Even though the iLBC source code is present in the RFC, usage of it is covered by license agreements with GIPS, in spite of the fact that the code in the RFC contains no copyright statements by or other references to GIPS. It's murky and inconvenient, so let's not let that happen again :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From jdrosen@jdrosen.net Fri Sep 24 12:16:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4E33A6B59 for ; Fri, 24 Sep 2010 12:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PKm6x0Pweq9 for ; Fri, 24 Sep 2010 12:16:12 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id 393C63A6B5F for ; Fri, 24 Sep 2010 12:16:10 -0700 (PDT) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OzDjx-0001N1-Ds for codec@ietf.org; Fri, 24 Sep 2010 15:15:25 -0400 Message-ID: <4C9CF91C.2000907@jdrosen.net> Date: Fri, 24 Sep 2010 15:16:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [codec] Codec testing and the IETF process X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 19:16:22 -0000 [as chair] One of the questions raised by Stephan in his mail to the list: http://www.ietf.org/mail-archive/web/codec/current/msg01784.html Raises a really important process question - is the issuance of the codec RFC gated on completion of one or more characterization tests, and do those test results themselves need to be included in a separate informational document which is issued alongside the actual codec specification. From an IETF perspective, this is certainly NOT a requirement. In general, the IETF does not require formal testing of interoperability or specification correctness prior to issuance of a proposed standard RFC. Indeed, such testing is normally done at draft standards stage. As such, IETF rules certainly allow us to request publication of the codec specification without a single test having been done. As a working group, we are in a position to decide whether we do want more prior to asking IESG to approve the specification. Our consensus on this should also be documented in the guidelines spec once we achieve it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From stewe@stewe.org Fri Sep 24 12:33:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB403A69B5 for ; Fri, 24 Sep 2010 12:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv-Y5zJfdlRc for ; Fri, 24 Sep 2010 12:33:34 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id BBA373A6978 for ; Fri, 24 Sep 2010 12:33:33 -0700 (PDT) Received: from [192.168.1.105] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 795015-1743317 for multiple; Fri, 24 Sep 2010 21:34:02 +0200 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 24 Sep 2010 12:33:45 -0700 From: Stephan Wenger To: Jonathan Rosenberg , Message-ID: Thread-Topic: [codec] Format for the codec specification Thread-Index: ActcH2bhtNp61rr/xUy/ojU1uxjqgg== In-Reply-To: <4C9CF757.9090705@jdrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 19:33:35 -0000 I also think we should make the code normative, as the speech codec people commonly do for their bit-exact encoder/decoder specs. However, someone will have to explain to me how this can be done without requiring bit-exactness. If we were deciding to use code as the normative description, then I would prefer to have that code ONLY in a single document. It may be worthwhile to consider zipping the source code directory, coding it in BASE64, and then copy-pasting it into the RFC. This way we could overcome many of the shortcomings of putting a large software project into a printout format. We should check with the AD and the RFC editor first, how they view such a submission. Finally, it should be clear that the code RFC (as all RFCs) falls under the IETF's copyright and patent policies. As for the copyright part, people should be aware that the IETF does not allow any other copyright notices but its own in such an RFC. In other words, if the code maintainers want to make the code available also under a non-IETF license (one of the open source licenses, for example), they a) have to make sure that this license allows for such dual licensing (GPL, for example, does IMO not), and b) remove the statements of this license from the code provided to the IETF, and c) (depending on that license) remove the IETF license text from the code provided to the open source repository. Tedious, but doable, I think. Stephan On 9.24.2010 12:09 , "Jonathan Rosenberg" wrote: > One of the open issues we need to close on - and document in the > guidelines specification - is what the format of our codec specification > deliverable will be. > > Firstly - one thing is clear - whatever the format is (code or textual > descriptions) - it needs to be in an RFC. Including source code into an > RFC is not ideal, but for purposes of IETF process that is the only > thing we can officially produce. Participants can of course place that > code in any repository they like, and we can even include a link to it > in the RFC. However, the formal normative specification of the codec > must be within a standards track RFC. > > In terms of whether the specification is code, text, or both - we need > to gain consensus on this. It is my understanding that source code is > ultimately the most exact way to specify the codec. A detailed > description is also included, and in case of conflict, the code would > win. In IETF terms this means that the code is actually the normative > specification. > > iLBC includes the code itself in an appendix. As such, it would seem to > make sense to follow this precedent. Thus, our deliverable would be a > single document, containing a reasonably detailed codec description, > along with an appendix containing the actual code. > > Comments? > > -Jonathan R. From jean-marc.valin@usherbrooke.ca Fri Sep 24 13:37:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FF33A6A45 for ; Fri, 24 Sep 2010 13:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+36KykSAjOw for ; Fri, 24 Sep 2010 13:37:24 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 6E7353A6802 for ; Fri, 24 Sep 2010 13:37:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by vl-mh-mrz21.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L99003JPQN3OS80@vl-mh-mrz21.ip.videotron.ca> for codec@ietf.org; Fri, 24 Sep 2010 16:37:51 -0400 (EDT) Message-id: <4C9D0C24.5080302@usherbrooke.ca> Date: Fri, 24 Sep 2010 16:37:56 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Stephan Wenger References: In-reply-to: Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 20:37:26 -0000 On 10-09-24 03:33 PM, Stephan Wenger wrote: > I also think we should make the code normative, as the speech codec people > commonly do for their bit-exact encoder/decoder specs. However, someone > will have to explain to me how this can be done without requiring > bit-exactness. There is no need to mandate bit-exactness. Many codecs are actually specified in floating-point. For example, if I'm not mistaken, the following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 (probably others). As far as I know, the spec says how much you can deviate from the float reference (not to mention that it's impossible to always be bit-exact with a float reference in the first place). > If we were deciding to use code as the normative description, then I would > prefer to have that code ONLY in a single document. It may be worthwhile to > consider zipping the source code directory, coding it in BASE64, and then > copy-pasting it into the RFC. This way we could overcome many of the > shortcomings of putting a large software project into a printout format. We > should check with the AD and the RFC editor first, how they view such a > submission. I'm not against base64 encoding if the IETF will allow it. We could even have a C version of the base64 decoder to make sure that the RFC is "self-contained". > Finally, it should be clear that the code RFC (as all RFCs) falls under the > IETF's copyright and patent policies. As for the copyright part, people > should be aware that the IETF does not allow any other copyright notices but > its own in such an RFC. In other words, if the code maintainers want to > make the code available also under a non-IETF license (one of the open > source licenses, for example), they a) have to make sure that this license > allows for such dual licensing (GPL, for example, does IMO not), The BSD license is compatible with the GPL, which means that it is OK, to take BSD code, modify it, and then slap a GPL license on top of the modified version (without removing the existing BSD license). In general, there are many cases of dual licensing involving the GPL. Also, note that the code we're talking about has been available under the BSD (and not the GPL) right from the start. Jean-Marc > and b) > remove the statements of this license from the code provided to the IETF, > and c) (depending on that license) remove the IETF license text from the > code provided to the open source repository. Tedious, but doable, I think. > > Stephan > > > > > > > On 9.24.2010 12:09 , "Jonathan Rosenberg" wrote: > >> One of the open issues we need to close on - and document in the >> guidelines specification - is what the format of our codec specification >> deliverable will be. >> >> Firstly - one thing is clear - whatever the format is (code or textual >> descriptions) - it needs to be in an RFC. Including source code into an >> RFC is not ideal, but for purposes of IETF process that is the only >> thing we can officially produce. Participants can of course place that >> code in any repository they like, and we can even include a link to it >> in the RFC. However, the formal normative specification of the codec >> must be within a standards track RFC. >> >> In terms of whether the specification is code, text, or both - we need >> to gain consensus on this. It is my understanding that source code is >> ultimately the most exact way to specify the codec. A detailed >> description is also included, and in case of conflict, the code would >> win. In IETF terms this means that the code is actually the normative >> specification. >> >> iLBC includes the code itself in an appendix. As such, it would seem to >> make sense to follow this precedent. Thus, our deliverable would be a >> single document, containing a reasonably detailed codec description, >> along with an appendix containing the actual code. >> >> Comments? >> >> -Jonathan R. > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From stpeter@stpeter.im Fri Sep 24 13:42:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358FD3A691F for ; Fri, 24 Sep 2010 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFHJmIWXTKw1 for ; Fri, 24 Sep 2010 13:42:14 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DF9943A67D4 for ; Fri, 24 Sep 2010 13:42:13 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99A2E40074; Fri, 24 Sep 2010 14:47:51 -0600 (MDT) Message-ID: <4C9D0D44.6080706@stpeter.im> Date: Fri, 24 Sep 2010 14:42:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jean-Marc Valin References: <4C9D0C24.5080302@usherbrooke.ca> In-Reply-To: <4C9D0C24.5080302@usherbrooke.ca> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 20:42:15 -0000 On 9/24/10 2:37 PM, Jean-Marc Valin wrote: > On 10-09-24 03:33 PM, Stephan Wenger wrote: > >> Finally, it should be clear that the code RFC (as all RFCs) falls >> under the >> IETF's copyright and patent policies. As for the copyright part, people >> should be aware that the IETF does not allow any other copyright >> notices but >> its own in such an RFC. In other words, if the code maintainers want to >> make the code available also under a non-IETF license (one of the open >> source licenses, for example), they a) have to make sure that this >> license >> allows for such dual licensing (GPL, for example, does IMO not), > > The BSD license is compatible with the GPL, which means that it is OK, > to take BSD code, modify it, and then slap a GPL license on top of the > modified version (without removing the existing BSD license). In > general, there are many cases of dual licensing involving the GPL. Also, > note that the code we're talking about has been available under the BSD > (and not the GPL) right from the start. Right, the current IETF copyright notices states: Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. So IMHO there's no need to jump through any hoops here. Peter -- Peter Saint-Andre https://stpeter.im/ From ron.even.tlv@gmail.com Fri Sep 24 15:08:19 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9043A6A7A for ; Fri, 24 Sep 2010 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWDFiYz3WgYp for ; Fri, 24 Sep 2010 15:08:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2290C3A69AE for ; Fri, 24 Sep 2010 15:08:16 -0700 (PDT) Received: by bwz9 with SMTP id 9so2937462bwz.31 for ; Fri, 24 Sep 2010 15:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=MsAFeFO1rEmt2K2NI2BWuSSZ7ZaeKd/7Dgz0ZFgIpgY=; b=u+ATX/6J0yi0TY6SxQE1/Rd4c3t6iQfGFA26roqFYUw6ePYle8iqKW7huL5Mqe+s8j QFeyzctOUC+8omqBjACcnExUAMgkXvi1lSbMXPm5wRMuzzZ7K6nc7MD9RAGDg5NaWuc0 zQPWBpnCeHvBFDLO3Q+mLQr9FRDhbmy0Z3/RM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=FytLlltD6wKp/cIv5JR0sY7gDQNlz8+r++ptRNEYppgTDQdZxzHwoFcZ4eGz0YNiYe jx/hu+v8TWnmw58XwBLWFyQEsp58IDghHAOfyyFkd/Ph9dSBf1MWJyfbrfHKphsGZYjy D82fc670BKhAy6zUG5zBVRgKH20yLNPlAeIE8= Received: by 10.204.102.68 with SMTP id f4mr2643558bko.30.1285366128754; Fri, 24 Sep 2010 15:08:48 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-28-2.red.bezeqint.net [79.183.28.2]) by mx.google.com with ESMTPS id f16sm1949139bkd.4.2010.09.24.15.08.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Sep 2010 15:08:46 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Stephan Wenger'" References: <4C9D0C24.5080302@usherbrooke.ca> In-Reply-To: <4C9D0C24.5080302@usherbrooke.ca> Date: Sat, 25 Sep 2010 00:06:56 +0200 Message-ID: <4c9d216e.1021cc0a.658d.51bf@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActcKGVo8eu25NFzQriKZPNBhELiegADDfWw Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 22:08:19 -0000 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Friday, September 24, 2010 10:38 PM > To: Stephan Wenger > Cc: codec@ietf.org > Subject: Re: [codec] Format for the codec specification > > On 10-09-24 03:33 PM, Stephan Wenger wrote: > > I also think we should make the code normative, as the speech codec > people > > commonly do for their bit-exact encoder/decoder specs. However, > someone > > will have to explain to me how this can be done without requiring > > bit-exactness. > > There is no need to mandate bit-exactness. Many codecs are actually > specified in floating-point. For example, if I'm not mistaken, the > following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 > (probably others). As far as I know, the spec says how much you can > deviate from the float reference (not to mention that it's impossible > to > always be bit-exact with a float reference in the first place). > Section 6.5 from ITU-T G.719 6.5 Description of the codec The description of the coding algorithm of this Recommendation is made in terms of bit-exact fixed-point mathematical operations. The ANSI-C code indicated in clause 10, which constitutes an integral part of this Recommendation, reflects this bit-exact, fixed-point descriptive approach. The mathematical descriptions of the encoder and decoder can be implemented in other fashions, possibly leading to a codec implementation which does not comply with this Recommendation. Therefore, the algorithm description of the ANSI-C code of clause 10 shall take precedence over the mathematical descriptions whenever discrepancies are found. A set of test signals, which can be used together with the ANSI-C code in order to verify bit-exactness, is available as an electronic attachment to this Recommendation. Roni Even From jean-marc.valin@usherbrooke.ca Fri Sep 24 16:21:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9582A3A69A8 for ; Fri, 24 Sep 2010 16:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B8usT4i-VwL for ; Fri, 24 Sep 2010 16:21:12 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 5C40A3A6814 for ; Fri, 24 Sep 2010 16:21:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L99003P2Y84BCF0@VL-MR-MRZ20.ip.videotron.ca> for codec@ietf.org; Fri, 24 Sep 2010 19:21:40 -0400 (EDT) Message-id: <4C9D3288.1000608@usherbrooke.ca> Date: Fri, 24 Sep 2010 19:21:44 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Roni Even References: <4C9D0C24.5080302@usherbrooke.ca> <4c9d216e.1021cc0a.658d.51bf@mx.google.com> In-reply-to: <4c9d216e.1021cc0a.658d.51bf@mx.google.com> Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 23:21:13 -0000 Hi Roni, Thanks for the correction on the case of G.719. Despite that, my point still stands: there *are* codecs for which the decoder is standardized without a bit-exact definition. As long as we define the amount of deviation permitted, then there is no problem. Oh, and I do agree that the C code should take precedence over the mathematical description. Cheers, Jean-Marc On 10-09-24 06:06 PM, Roni Even wrote: > 6.5 Description of the codec > The description of the coding algorithm of this Recommendation is made in > terms of bit-exact > fixed-point mathematical operations. The ANSI-C code indicated in clause 10, > which constitutes an > integral part of this Recommendation, reflects this bit-exact, fixed-point > descriptive approach. The > mathematical descriptions of the encoder and decoder can be implemented in > other fashions, > possibly leading to a codec implementation which does not comply with this > Recommendation. > Therefore, the algorithm description of the ANSI-C code of clause 10 shall > take precedence over the > mathematical descriptions whenever discrepancies are found. A set of test > signals, which can be > used together with the ANSI-C code in order to verify bit-exactness, is > available as an electronic > attachment to this Recommendation. > > > Roni Even > > > From root@core3.amsl.com Fri Sep 24 16:30:04 2010 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 324B23A6B31; Fri, 24 Sep 2010 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100924233003.324B23A6B31@core3.amsl.com> Date: Fri, 24 Sep 2010 16:30:01 -0700 (PDT) Cc: codec@ietf.org Subject: [codec] I-D Action:draft-ietf-codec-harmony-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 23:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Definition of the Harmony Audio Codec Author(s) : J. Valin, K. Vos Filename : draft-ietf-codec-harmony-00.txt Pages : 12 Date : 2010-09-24 This document describes the Harmony codec, designed for interactive speech and audio transmission over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-harmony-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-codec-harmony-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-24162851.I-D@ietf.org> --NextPart-- From stewe@stewe.org Fri Sep 24 17:52:19 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D263A682C for ; Fri, 24 Sep 2010 17:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7EPBbXru4c4 for ; Fri, 24 Sep 2010 17:52:17 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 526803A67FA for ; Fri, 24 Sep 2010 17:52:14 -0700 (PDT) Received: from [192.168.1.105] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 795170-1743317 for multiple; Sat, 25 Sep 2010 02:52:46 +0200 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 24 Sep 2010 17:52:38 -0700 From: Stephan Wenger To: Jean-Marc Valin Message-ID: Thread-Topic: [codec] Format for the codec specification Thread-Index: ActcS/MJ/4uK7ME+ykmPSpGmQ5UbgA== In-Reply-To: <4C9D0C24.5080302@usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 00:52:19 -0000 I forgot that you are currently working under the BSD license. Keep it that way, and I have no concerns on the licensing front, as IETF code components are under essentially the same license. Stephan On 9.24.2010 13:37 , "Jean-Marc Valin" wrote: > On 10-09-24 03:33 PM, Stephan Wenger wrote: >> I also think we should make the code normative, as the speech codec people >> commonly do for their bit-exact encoder/decoder specs. However, someone >> will have to explain to me how this can be done without requiring >> bit-exactness. > > There is no need to mandate bit-exactness. Many codecs are actually > specified in floating-point. For example, if I'm not mistaken, the > following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 > (probably others). As far as I know, the spec says how much you can > deviate from the float reference (not to mention that it's impossible to > always be bit-exact with a float reference in the first place). > >> If we were deciding to use code as the normative description, then I would >> prefer to have that code ONLY in a single document. It may be worthwhile to >> consider zipping the source code directory, coding it in BASE64, and then >> copy-pasting it into the RFC. This way we could overcome many of the >> shortcomings of putting a large software project into a printout format. We >> should check with the AD and the RFC editor first, how they view such a >> submission. > > I'm not against base64 encoding if the IETF will allow it. We could even > have a C version of the base64 decoder to make sure that the RFC is > "self-contained". > >> Finally, it should be clear that the code RFC (as all RFCs) falls under the >> IETF's copyright and patent policies. As for the copyright part, people >> should be aware that the IETF does not allow any other copyright notices but >> its own in such an RFC. In other words, if the code maintainers want to >> make the code available also under a non-IETF license (one of the open >> source licenses, for example), they a) have to make sure that this license >> allows for such dual licensing (GPL, for example, does IMO not), > > The BSD license is compatible with the GPL, which means that it is OK, > to take BSD code, modify it, and then slap a GPL license on top of the > modified version (without removing the existing BSD license). In > general, there are many cases of dual licensing involving the GPL. Also, > note that the code we're talking about has been available under the BSD > (and not the GPL) right from the start. > > Jean-Marc > >> and b) >> remove the statements of this license from the code provided to the IETF, >> and c) (depending on that license) remove the IETF license text from the >> code provided to the open source repository. Tedious, but doable, I think. >> >> Stephan >> >> >> >> >> >> >> On 9.24.2010 12:09 , "Jonathan Rosenberg" wrote: >> >>> One of the open issues we need to close on - and document in the >>> guidelines specification - is what the format of our codec specification >>> deliverable will be. >>> >>> Firstly - one thing is clear - whatever the format is (code or textual >>> descriptions) - it needs to be in an RFC. Including source code into an >>> RFC is not ideal, but for purposes of IETF process that is the only >>> thing we can officially produce. Participants can of course place that >>> code in any repository they like, and we can even include a link to it >>> in the RFC. However, the formal normative specification of the codec >>> must be within a standards track RFC. >>> >>> In terms of whether the specification is code, text, or both - we need >>> to gain consensus on this. It is my understanding that source code is >>> ultimately the most exact way to specify the codec. A detailed >>> description is also included, and in case of conflict, the code would >>> win. In IETF terms this means that the code is actually the normative >>> specification. >>> >>> iLBC includes the code itself in an appendix. As such, it would seem to >>> make sense to follow this precedent. Thus, our deliverable would be a >>> single document, containing a reasonably detailed codec description, >>> along with an appendix containing the actual code. >>> >>> Comments? >>> >>> -Jonathan R. >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> From stewe@stewe.org Fri Sep 24 18:21:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849803A6B66 for ; Fri, 24 Sep 2010 18:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMQRujVv1DtS for ; Fri, 24 Sep 2010 18:21:42 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 28CB83A682C for ; Fri, 24 Sep 2010 18:21:41 -0700 (PDT) Received: from [192.168.1.105] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 795183-1743317 for multiple; Sat, 25 Sep 2010 03:22:14 +0200 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 24 Sep 2010 18:22:06 -0700 From: Stephan Wenger To: Jonathan Rosenberg , Message-ID: Thread-Topic: [codec] Adopting draft-valin-codec-guidelines-06 as a WG item Thread-Index: ActcUBDZ9dguzCaxcEKDVnYvpVxdOw== In-Reply-To: <4C9CEE29.1090600@jdrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [codec] Adopting draft-valin-codec-guidelines-06 as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 01:21:43 -0000 > > If you disagree, please speak up - and even better - submit an > alternative document. Hi all, My preference would be to resolve strategic issues such as text/code being normative (where it seems we are very close to consensus: code it should be), bit-exact or not (and what are the conformance points if its not bit-exactness), and characterization gating, before accepting the draft as a WG item. That said, I'm willing to support the adoption of the draft as WG item even in the absence of this consensus, but only under the following two conditions: 1. The draft clearly states that there is no consensus yet on the subject of bit-exactness. 2. The draft clearly states that there is no consensus yet on the subject of characterization gating (in the sense of Jonathan's email sent a couple of hours ago). These conditions represent my points 11 and 15 of my email sent to this list on August 21, on neither of which I'm in agreement with the current language (or the current intention), nor I have seen any movement on the proponents on the other side towards a compromise/consensus position. I don't have the bandwidth this week or next to suggest alternative language, but will try to do so within the two week time window Jonathan proposed. In order to move things forward: in both cases, I have no problems if the current text stays in, as long as it is made unambiguously clear that this is not a consensus position, but rather one possible option for a resolution of the question, and that other options are expressedly solicited. The reason for these requests are hopefully obvious: a WG draft should represent the consensus of the WG, and should not contain non-consensus positions without disclaimers. Stephan On 9.24.2010 11:30 , "Jonathan Rosenberg" wrote: > At the last IETF meeting, we discussed adopting the codec guidelines > document as a working group item. This did not pass, due to concerns > over whether it was in the right direction. We put out a call for > alternative documents over the next 5 week period. > > Some text was proposed by Stephan for inclusion, which was incorporated > into the document. Stephan also contributed some comments, including a > few open issues which still require some discussion. > > However, the chairs feel that it is not necessary for all open items to > be closed prior to adopting a document as a working group item. Indeed, > discussion on the content of the document is a good sign that it is a > reasonable foundation for the working group item. Given the lack of > alternative documents to use as a starting point, the chairs plan on > adopting this as a working group item in two weeks time. > > If you disagree, please speak up - and even better - submit an > alternative document. > > Thanks, > Jonathan R. From jean-marc.valin@usherbrooke.ca Fri Sep 24 20:30:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561663A6A04 for ; Fri, 24 Sep 2010 20:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlBZ6zQ6kKOg for ; Fri, 24 Sep 2010 20:30:35 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 2DC543A6851 for ; Fri, 24 Sep 2010 20:30:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L9A002DB9RQDFA0@VL-MR-MRZ20.ip.videotron.ca> for codec@ietf.org; Fri, 24 Sep 2010 23:31:03 -0400 (EDT) Message-id: <4C9D6CFB.8050006@usherbrooke.ca> Date: Fri, 24 Sep 2010 23:31:07 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Stephan Wenger References: In-reply-to: Cc: codec@ietf.org Subject: Re: [codec] Adopting draft-valin-codec-guidelines-06 as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 03:30:38 -0000 On 10-09-24 09:22 PM, Stephan Wenger wrote: > My preference would be to resolve strategic issues such as text/code being > normative (where it seems we are very close to consensus: code it should > be), Considering that I have not heard anyone argue against code being the reference, I assume there is consensus on that. Anyone disagrees on that? If not, I'll add that to the draft. > bit-exact or not (and what are the conformance points if its not > bit-exactness), Again, from the previous IETF meeting (logs at http://www.ietf.org/jabber/logs/codec/2010-07-26.txt) I thought most/all agreed with having a fixed-point reference, but not "force" implementations to be bit-exact with it. The current draft already mentions that and leaves it up to the codec draft to specify the exact conformance requirements. > and characterization gating, Well, that may be the only one that's still being debated. I think that can be resolved after adopting the draft. Cheers, Jean-Marc > before accepting the draft as a > WG item. > That said, I'm willing to support the adoption of the draft as WG > item even in the absence of this consensus, but only under the following two > conditions: > > 1. The draft clearly states that there is no consensus yet on the subject of > bit-exactness. > 2. The draft clearly states that there is no consensus yet on the subject of > characterization gating (in the sense of Jonathan's email sent a couple of > hours ago). > > These conditions represent my points 11 and 15 of my email sent to this list > on August 21, on neither of which I'm in agreement with the current language > (or the current intention), nor I have seen any movement on the proponents > on the other side towards a compromise/consensus position. I don't have the > bandwidth this week or next to suggest alternative language, but will try to > do so within the two week time window Jonathan proposed. > > In order to move things forward: in both cases, I have no problems if the > current text stays in, as long as it is made unambiguously clear that this > is not a consensus position, but rather one possible option for a resolution > of the question, and that other options are expressedly solicited. > > The reason for these requests are hopefully obvious: a WG draft should > represent the consensus of the WG, and should not contain non-consensus > positions without disclaimers. > > Stephan > > > > On 9.24.2010 11:30 , "Jonathan Rosenberg" wrote: > >> At the last IETF meeting, we discussed adopting the codec guidelines >> document as a working group item. This did not pass, due to concerns >> over whether it was in the right direction. We put out a call for >> alternative documents over the next 5 week period. >> >> Some text was proposed by Stephan for inclusion, which was incorporated >> into the document. Stephan also contributed some comments, including a >> few open issues which still require some discussion. >> >> However, the chairs feel that it is not necessary for all open items to >> be closed prior to adopting a document as a working group item. Indeed, >> discussion on the content of the document is a good sign that it is a >> reasonable foundation for the working group item. Given the lack of >> alternative documents to use as a starting point, the chairs plan on >> adopting this as a working group item in two weeks time. >> >> If you disagree, please speak up - and even better - submit an >> alternative document. >> >> Thanks, >> Jonathan R. > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From riccardo.bernardini@uniud.it Sat Sep 25 02:00:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF5A3A6A7E for ; Sat, 25 Sep 2010 02:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.277 X-Spam-Level: *** X-Spam-Status: No, score=3.277 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNRrnYQwKxg4 for ; Sat, 25 Sep 2010 02:00:13 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by core3.amsl.com (Postfix) with ESMTP id 09E2D3A6A8A for ; Sat, 25 Sep 2010 02:00:13 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 8C1AFB72413 for ; Sat, 25 Sep 2010 10:55:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.226]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10025) with ESMTP id fFeAqCYmy4nX for ; Sat, 25 Sep 2010 10:55:26 +0200 (CEST) Received: from webmail.uniud.it (webmail1.cc.uniud.it [158.110.1.17]) by smtp.uniud.it (Postfix) with ESMTPA id E5C2C1E002 for ; Sat, 25 Sep 2010 10:55:25 +0200 (CEST) Received: from 109.52.137.133 ([109.52.137.133]) by webmail.uniud.it (Horde Framework) with HTTP; Sat, 25 Sep 2010 10:55:23 +0200 Message-ID: <20100925105523.15884gktkx78i41n@webmail.uniud.it> Date: Sat, 25 Sep 2010 10:55:23 +0200 From: Riccardo Bernardini To: codec@ietf.org References: <4C9D0C24.5080302@usherbrooke.ca> <4c9d216e.1021cc0a.658d.51bf@mx.google.com> <4C9D3288.1000608@usherbrooke.ca> In-Reply-To: <4C9D3288.1000608@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 09:00:14 -0000 Quoting Jean-Marc Valin : > Hi Roni, > > Thanks for the correction on the case of G.719. Despite that, my =20 > point still stands: there *are* codecs for which the decoder is =20 > standardized without a bit-exact definition. As long as we define =20 > the amount of deviation permitted, then there is no problem. > > Oh, and I do agree that the C code should take precedence over the =20 > mathematical description. A question just came to my mind: what about bugs in the C code? =20 Suppose, for example, that the algorithm requires the computation of a =20 DCT of a block of samples and that there is some typo in the constants =20 used in the C code, so that what the C code computes is not the DCT, =20 but something similar and the difference is such that it really does =20 not matter in most cases, but causes very bad performances (when =20 compared with theoretical description) in others. In this case, the =20 precedence would go to the "wrong" description. I agree that the example above is somehow weak (I just invented it =20 "on the spot"), but I hope that spirit is clear: it could happen that =20 despite of all attention we could pay, some subtle but important bugs =20 could find their way to the C code. Also I agree that we can always =20 publish an errata or an RFC that obsolete the old one. Another doubt about having a C code as a normative reference: could =20 portability issues make the code "ambiguous"? For example, a code =20 could use the assumption that int is _exactly_ 32 bits long and short =20 is _exactly_ 16 bits. If the same code is run on a processor that =20 uses, say, 64 bits for int and 32 for shorts, maybe the results could =20 be different. Of course, you can solve this _specific_ issue by =20 including stdint.h (not available everywhere, though) and using types =20 like int16_t, but what I want to point out is that we must pay =20 attention to this type of portability issues, if we want the meaning =20 of the C code being non-ambiguous. Another example, much more subtle, =20 could be int foo[3]; int goo, foo=3D3; int *pt; pt =3D (int*) foo; goo =3D (int) pt; /* Is really pt=3D=3Dfoo? */ As far as I know (but I am not a C language-lawyer), the standard =20 grants that conversion pointer-to-integer-to-pointer will give the =20 original pointer back, but nothing is said about the case above =20 (imagine an architecture where addresses can be only even). Although =20 the code above would work on a typical x86 architecture, I would not =20 use it in a code that should play the role of a reference. By the way, I agree that the code above is quite silly, but I seen =20 things like this used, for example, in multi-thread applications where =20 the programmer wanted to pass an integer by using a function that =20 expected a pointer. What about using some other language with less portability issues, =20 such as Ada or Java? Better yet, some language with a semantic =20 formally defined? (I do not know any, but maybe someone does) [Oh, by the way, I *do not want* to start a flame war about which =20 language to use. Rather than fighting over it, I would go with C. I =20 just wanted to share with you some doubts of mine.] Although I agree that errors and ambiguities could creep in the =20 mathematical description, maybe it is easier to write a correct and =20 unambiguous mathematical description rather than a program code (in =20 whatever language is written). > Cheers, > > =09Jean-Marc > > On 10-09-24 06:06 PM, Roni Even wrote: >> 6.5 Description of the codec >> The description of the coding algorithm of this Recommendation is made in >> terms of bit-exact >> fixed-point mathematical operations. The ANSI-C code indicated in clause = 10, >> which constitutes an >> integral part of this Recommendation, reflects this bit-exact, fixed-poin= t >> descriptive approach. The >> mathematical descriptions of the encoder and decoder can be implemented i= n >> other fashions, >> possibly leading to a codec implementation which does not comply with thi= s >> Recommendation. >> Therefore, the algorithm description of the ANSI-C code of clause 10 shal= l >> take precedence over the >> mathematical descriptions whenever discrepancies are found. A set of test >> signals, which can be >> used together with the ANSI-C code in order to verify bit-exactness, is >> available as an electronic >> attachment to this Recommendation. >> >> >> Roni Even >> >> >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --=20 Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - CSIT -Universita' di Udine From riccardo.bernardini@uniud.it Sat Sep 25 02:09:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0594C3A6A7D for ; Sat, 25 Sep 2010 02:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.277 X-Spam-Level: *** X-Spam-Status: No, score=3.277 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIe7BRPiGSaX for ; Sat, 25 Sep 2010 02:09:54 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by core3.amsl.com (Postfix) with ESMTP id 36A373A6A6D for ; Sat, 25 Sep 2010 02:09:45 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 8CA36B7241F for ; Sat, 25 Sep 2010 11:10:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.226]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10025) with ESMTP id oAy94CNVQ7Wo for ; Sat, 25 Sep 2010 11:10:18 +0200 (CEST) Received: from webmail.uniud.it (webmail1.cc.uniud.it [158.110.1.17]) by smtp.uniud.it (Postfix) with ESMTPA id 5A2D81E002 for ; Sat, 25 Sep 2010 11:10:18 +0200 (CEST) Received: from 109.52.137.133 ([109.52.137.133]) by webmail.uniud.it (Horde Framework) with HTTP; Sat, 25 Sep 2010 11:10:16 +0200 Message-ID: <20100925111016.69714ruwnefzma9k@webmail.uniud.it> Date: Sat, 25 Sep 2010 11:10:16 +0200 From: Riccardo Bernardini To: codec@ietf.org References: <4C9D6CFB.8050006@usherbrooke.ca> In-Reply-To: <4C9D6CFB.8050006@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) Subject: Re: [codec] Adopting draft-valin-codec-guidelines-06 as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 09:09:59 -0000 X-List-Received-Date: Sat, 25 Sep 2010 09:09:59 -0000 Quoting Jean-Marc Valin : > On 10-09-24 09:22 PM, Stephan Wenger wrote: >> My preference would be to resolve strategic issues such as text/code bein= g >> normative (where it seems we are very close to consensus: code it should >> be), > > Considering that I have not heard anyone argue against code being =20 > the reference, I assume there is consensus on that. Anyone disagrees =20 > on that? If not, I'll add that to the draft. > I have a (weak) doubt about having code as reference. I elaborated =20 about it in a reply of mine to thread (of this WG) about format =20 specification (I would give you the link to the archive, but it seems =20 that it is not archived yet). I would not repeat it here (it is a =20 fairly long message), but the bottom line is that maybe C code has =20 few trapdoors that make it less than ideal to write an "ultimate =20 specification" of something. How I said, it is just a very weak =20 objection. --=20 Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - CSIT -Universita' di Udine From jean-marc.valin@usherbrooke.ca Sat Sep 25 07:23:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6356D3A6AFB for ; Sat, 25 Sep 2010 07:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd00szyFVkd6 for ; Sat, 25 Sep 2010 07:23:50 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 70EB53A6901 for ; Sat, 25 Sep 2010 07:23:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MRZ22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L9B0093P3ZE9BC0@VL-MR-MRZ22.ip.videotron.ca> for codec@ietf.org; Sat, 25 Sep 2010 10:23:39 -0400 (EDT) Message-id: <4C9E05EA.9010307@usherbrooke.ca> Date: Sat, 25 Sep 2010 10:23:38 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Riccardo Bernardini References: <4C9D0C24.5080302@usherbrooke.ca> <4c9d216e.1021cc0a.658d.51bf@mx.google.com> <4C9D3288.1000608@usherbrooke.ca> <20100925105523.15884gktkx78i41n@webmail.uniud.it> In-reply-to: <20100925105523.15884gktkx78i41n@webmail.uniud.it> Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 14:23:51 -0000 On 10-09-25 04:55 AM, Riccardo Bernardini wrote: > A question just came to my mind: what about bugs in the C code? Suppose, > for example, that the algorithm requires the computation of a DCT of a > block of samples and that there is some typo in the constants used in > the C code, so that what the C code computes is not the DCT, but > something similar and the difference is such that it really does not > matter in most cases, but causes very bad performances (when compared > with theoretical description) in others. In this case, the precedence > would go to the "wrong" description. Judging from the bugs I have had in CELT over the development, these tend to be a lot more subtle than what you describe above, like corner cases that likely would not be covered by the text description either. In any case, should an error be found in the source code, the best would be to simply publish an updated version. > Another doubt about having a C code as a normative reference: could > portability issues make the code "ambiguous"? For example, a code could > use the assumption that int is _exactly_ 32 bits long and short is > _exactly_ 16 bits. If the same code is run on a processor that uses, > say, 64 bits for int and 32 for shorts, maybe the results could be > different. Of course, you can solve this _specific_ issue by including > stdint.h (not available everywhere, though) and using types like > int16_t, but what I want to point out is that we must pay attention to > this type of portability issues, if we want the meaning of the C code > being non-ambiguous. Another example, much more subtle, could be That's already how the CELT and SILK source code are written. There are typedefs for integers with exactly 16 bits or exactly 32 bits. > As far as I know (but I am not a C language-lawyer), the standard grants > that conversion pointer-to-integer-to-pointer will give the original > pointer back, but nothing is said about the case above (imagine an > architecture where addresses can be only even). Although the code above > would work on a typical x86 architecture, I would not use it in a code > that should play the role of a reference. Assuming that pointers can be stored in integers is bad and we just have to make sure not to have any of that in the reference source code. There's no need for it in a codec anyway. > Although I agree that errors and ambiguities could creep in the > mathematical description, maybe it is easier to write a correct and > unambiguous mathematical description rather than a program code (in > whatever language is written). Quite the other way around. Writing a correct and unambiguous mathematical description for thousands of line of code is nearly impossible. Either you write it in plain English and get all the ambiguities of natural language, or you write *everything* with equations, in which case what you have is the equivalent of pseudo-code. Also, a C reference has the advantage that you can verify it simply by compiling it. Cheers, Jean-Marc From tme@americafree.tv Sat Sep 25 12:59:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471A03A6A5A for ; Sat, 25 Sep 2010 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.44 X-Spam-Level: X-Spam-Status: No, score=-101.44 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-3gD2fIIBcq for ; Sat, 25 Sep 2010 12:59:08 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0F3E63A69E4 for ; Sat, 25 Sep 2010 12:59:07 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9A4268EC1578; Sat, 25 Sep 2010 15:52:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <4C9D0C24.5080302@usherbrooke.ca> Date: Sat, 25 Sep 2010 15:52:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C9D0C24.5080302@usherbrooke.ca> To: Jean-Marc Valin X-Mailer: Apple Mail (2.1081) Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 19:59:09 -0000 On Sep 24, 2010, at 4:37 PM, Jean-Marc Valin wrote: > On 10-09-24 03:33 PM, Stephan Wenger wrote: >> I also think we should make the code normative, as the speech codec = people >> commonly do for their bit-exact encoder/decoder specs. However, = someone >> will have to explain to me how this can be done without requiring >> bit-exactness. >=20 > There is no need to mandate bit-exactness. Many codecs are actually = specified in floating-point. For example, if I'm not mistaken, the = following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 = (probably others). As far as I know, the spec says how much you can = deviate from the float reference (not to mention that it's impossible to = always be bit-exact with a float reference in the first place). >=20 >> If we were deciding to use code as the normative description, then I = would >> prefer to have that code ONLY in a single document. It may be = worthwhile to >> consider zipping the source code directory, coding it in BASE64, and = then >> copy-pasting it into the RFC. This way we could overcome many of the >> shortcomings of putting a large software project into a printout = format. We >> should check with the AD and the RFC editor first, how they view such = a >> submission. >=20 > I'm not against base64 encoding if the IETF will allow it. We could = even have a C version of the base64 decoder to make sure that the RFC is = "self-contained". >=20 >> Finally, it should be clear that the code RFC (as all RFCs) falls = under the >> IETF's copyright and patent policies. Correct. >> As for the copyright part, people >> should be aware that the IETF does not allow any other copyright = notices but >> its own in such an RFC. Correct >> In other words, if the code maintainers want to >> make the code available also under a non-IETF license (one of the = open >> source licenses, for example), they a) have to make sure that this = license >> allows for such dual licensing (GPL, for example, does IMO not), >=20 > The BSD license is compatible with the GPL, which means that it is OK, = to take BSD code, modify it, and then slap a GPL license on top of the = modified version (without removing the existing BSD license). In = general, there are many cases of dual licensing involving the GPL. Also, = note that the code we're talking about has been available under the BSD = (and not the GPL) right from the start. You are certainly free to do that on your own, but under the current = Trust Legal Provisions http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf the code on published RFCs has to have the BSD license. Regards Marshall >=20 > Jean-Marc >=20 >> and b) >> remove the statements of this license from the code provided to the = IETF, >> and c) (depending on that license) remove the IETF license text from = the >> code provided to the open source repository. Tedious, but doable, I = think. >>=20 >> Stephan >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 9.24.2010 12:09 , "Jonathan Rosenberg" = wrote: >>=20 >>> One of the open issues we need to close on - and document in the >>> guidelines specification - is what the format of our codec = specification >>> deliverable will be. >>>=20 >>> Firstly - one thing is clear - whatever the format is (code or = textual >>> descriptions) - it needs to be in an RFC. Including source code into = an >>> RFC is not ideal, but for purposes of IETF process that is the only >>> thing we can officially produce. Participants can of course place = that >>> code in any repository they like, and we can even include a link to = it >>> in the RFC. However, the formal normative specification of the codec >>> must be within a standards track RFC. >>>=20 >>> In terms of whether the specification is code, text, or both - we = need >>> to gain consensus on this. It is my understanding that source code = is >>> ultimately the most exact way to specify the codec. A detailed >>> description is also included, and in case of conflict, the code = would >>> win. In IETF terms this means that the code is actually the = normative >>> specification. >>>=20 >>> iLBC includes the code itself in an appendix. As such, it would seem = to >>> make sense to follow this precedent. Thus, our deliverable would be = a >>> single document, containing a reasonably detailed codec description, >>> along with an appendix containing the actual code. >>>=20 >>> Comments? >>>=20 >>> -Jonathan R. >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 From jonas.svedberg@ericsson.com Tue Sep 28 06:00:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C65C3A6AED for ; Tue, 28 Sep 2010 06:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_40=-0.185, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utRnZgbrhdoU for ; Tue, 28 Sep 2010 06:00:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6CA803A6ABA for ; Tue, 28 Sep 2010 06:00:09 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-20-4ca1e701b6db Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.6A.27351.107E1AC4; Tue, 28 Sep 2010 15:00:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 28 Sep 2010 15:00:48 +0200 From: Jonas Svedberg To: Marshall Eubanks Date: Tue, 28 Sep 2010 15:00:47 +0200 Thread-Topic: [codec] Format for the codec specification Thread-Index: Actc7DVUUhzGdk9mQRiXIg3YnlSqbwCDgf4g Message-ID: References: <4C9D0C24.5080302@usherbrooke.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 13:00:11 -0000 Hi all If I understand Marshall's point correctly, the Trust Legal Provisions ind= icates something regarding publishing, which is not completely clear in t= he current guidelines draft. =20 In the proposed guidelines page 10, it is now stated: " 5. In accordance with BCP 78 [TRUST], the source code for the reference implementation must be made available under a BSD-style license (or whatever license is defined as acceptable by the IETF Trust when the Internet-Draft defining the reference implementation is published)." To me it seems as the final point Marshall made: "the code on published RFCs has to have the BSD license." ,is a clearer and stricter wording than what is present in the current prop= osed guidelines, which uses the looser term "BSD-style", and further leaves= other options open (in the parenthesis), and therefore makes the publishin= g directions in the guidelines quite unclear, to the developers.=20 =20 With this observation in mind it seems as the Guidelines publishing related= section should be updated.=20 -- =20 With regard to formats and publishing in general,=20 is there any precedence in IETF of having, the WG output split into sever= al entities/specs ?=20 (e.g sending side/receiving side or impl.A-fix/impl.B-Float) =20 e.g. One could imagine having the receiving side definitions specified i= n one RFC, and the sending side definitions as another RFC,=20 or even leave the sending side unspecified within IETF(e.g. as a separa= te open source project, which would then mainly take care of sending side c= ode maintenance, assuming that maintenance issues on the sending side are m= uch more frequent than on the receiving side). =20 //BR Jonas -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of M= arshall Eubanks Sent: den 25 september 2010 21:52 To: Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] Format for the codec specification On Sep 24, 2010, at 4:37 PM, Jean-Marc Valin wrote: > On 10-09-24 03:33 PM, Stephan Wenger wrote: >> I also think we should make the code normative, as the speech codec=20 >> people commonly do for their bit-exact encoder/decoder specs. =20 >> However, someone will have to explain to me how this can be done=20 >> without requiring bit-exactness. >=20 > There is no need to mandate bit-exactness. Many codecs are actually speci= fied in floating-point. For example, if I'm not mistaken, the following cod= ecs have a floating-point reference: MP3, EVRC-A/B, G.719 (probably others)= . As far as I know, the spec says how much you can deviate from the float r= eference (not to mention that it's impossible to always be bit-exact with a= float reference in the first place). >=20 >> If we were deciding to use code as the normative description, then I=20 >> would prefer to have that code ONLY in a single document. It may be=20 >> worthwhile to consider zipping the source code directory, coding it=20 >> in BASE64, and then copy-pasting it into the RFC. This way we could=20 >> overcome many of the shortcomings of putting a large software project=20 >> into a printout format. We should check with the AD and the RFC=20 >> editor first, how they view such a submission. >=20 > I'm not against base64 encoding if the IETF will allow it. We could even = have a C version of the base64 decoder to make sure that the RFC is "self-c= ontained". >=20 >> Finally, it should be clear that the code RFC (as all RFCs) falls=20 >> under the IETF's copyright and patent policies. Correct. >> As for the copyright part, people >> should be aware that the IETF does not allow any other copyright=20 >> notices but its own in such an RFC. Correct >> In other words, if the code maintainers want to make the code=20 >> available also under a non-IETF license (one of the open source=20 >> licenses, for example), they a) have to make sure that this license=20 >> allows for such dual licensing (GPL, for example, does IMO not), >=20 > The BSD license is compatible with the GPL, which means that it is OK, to= take BSD code, modify it, and then slap a GPL license on top of the modifi= ed version (without removing the existing BSD license). In general, there a= re many cases of dual licensing involving the GPL. Also, note that the code= we're talking about has been available under the BSD (and not the GPL) rig= ht from the start. You are certainly free to do that on your own, but under the current Trust = Legal Provisions http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf the code on published RFCs has to have the BSD license. Regards Marshall >=20 > Jean-Marc >=20 >> and b) >> remove the statements of this license from the code provided to the=20 >> IETF, and c) (depending on that license) remove the IETF license text=20 >> from the code provided to the open source repository. Tedious, but doab= le, I think. >>=20 >> Stephan >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 9.24.2010 12:09 , "Jonathan Rosenberg" wrote: >>=20 >>> One of the open issues we need to close on - and document in the=20 >>> guidelines specification - is what the format of our codec=20 >>> specification deliverable will be. >>>=20 >>> Firstly - one thing is clear - whatever the format is (code or=20 >>> textual >>> descriptions) - it needs to be in an RFC. Including source code into=20 >>> an RFC is not ideal, but for purposes of IETF process that is the=20 >>> only thing we can officially produce. Participants can of course=20 >>> place that code in any repository they like, and we can even include=20 >>> a link to it in the RFC. However, the formal normative specification=20 >>> of the codec must be within a standards track RFC. >>>=20 >>> In terms of whether the specification is code, text, or both - we=20 >>> need to gain consensus on this. It is my understanding that source=20 >>> code is ultimately the most exact way to specify the codec. A=20 >>> detailed description is also included, and in case of conflict, the=20 >>> code would win. In IETF terms this means that the code is actually=20 >>> the normative specification. >>>=20 >>> iLBC includes the code itself in an appendix. As such, it would seem=20 >>> to make sense to follow this precedent. Thus, our deliverable would=20 >>> be a single document, containing a reasonably detailed codec=20 >>> description, along with an appendix containing the actual code. >>>=20 >>> Comments? >>>=20 >>> -Jonathan R. >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Tue Sep 28 17:51:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0753A6E66 for ; Tue, 28 Sep 2010 17:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0geGgsqPzz5 for ; Tue, 28 Sep 2010 17:51:14 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id BF85D3A6BEB for ; Tue, 28 Sep 2010 17:51:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MRZ22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L9H00FQKH2KNDH0@VL-MR-MRZ22.ip.videotron.ca> for codec@ietf.org; Tue, 28 Sep 2010 20:51:56 -0400 (EDT) Message-id: <4CA28DAD.8090905@usherbrooke.ca> Date: Tue, 28 Sep 2010 20:51:57 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Jonas Svedberg References: <4C9D0C24.5080302@usherbrooke.ca> In-reply-to: Cc: "codec@ietf.org" Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 00:51:15 -0000 On 10-09-28 09:00 AM, Jonas Svedberg wrote: > " 5. In accordance with BCP 78 [TRUST], the source code for the > reference implementation must be made available under a BSD-style > license (or whatever license is defined as acceptable by the IETF > Trust when the Internet-Draft defining the reference implementation > is published)." > > To me it seems as the final point Marshall made: "the code on > published RFCs has to have the BSD license." > > ,is a clearer and stricter wording than what is present in the > current proposed guidelines, which uses the looser term "BSD-style", > and further leaves other options open (in the parenthesis), and > therefore makes the publishing directions in the guidelines quite > unclear, to the developers. I believe the current wording is based on Stephen Wenger's argument about "what if BCP78 were to specify a different license?" I don't have a strong opinion on this detail, you two can sort this out :-) > With regard to formats and publishing in general, is there any > precedence in IETF of having, the WG output split into several > entities/specs ? (e.g sending side/receiving side or > impl.A-fix/impl.B-Float) > > e.g. One could imagine having the receiving side definitions > specified in one RFC, and the sending side definitions as another > RFC, or even leave the sending side unspecified within IETF(e.g. as > a separate open source project, which would then mainly take care of > sending side code maintenance, assuming that maintenance issues on > the sending side are much more frequent than on the receiving side). Normally, the decoder should be normative, which the encoder should not be. Technically, the RFC could contain only the decoder, though practically we need an encoder reference implementation. Since the encoder would likely not be normative, it would probably not be necessary to update the RFC for encoder-side improvements and the decoder is unlikely to change too much. Also, note that there's quite a bit of code that is shared between the encoder and decoder, fixed-point and floating point, so it would seem logical/simpler to have a single document here. But again, I don't have a strong opinion at this point. Cheers, Jean-Marc From stephen.botzko@gmail.com Tue Sep 28 19:27:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2373A6C0C for ; Tue, 28 Sep 2010 19:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqTVgklbNMlN for ; Tue, 28 Sep 2010 19:27:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C796D3A6BFC for ; Tue, 28 Sep 2010 19:27:39 -0700 (PDT) Received: by qwc9 with SMTP id 9so237256qwc.31 for ; Tue, 28 Sep 2010 19:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NZdcb7QbylHnL9iCBU5IJdTmGysXCMbes1kAkLNkRjg=; b=lkAW2XZEnKN5urOG2LEjikHYZBJZGzdpIDPERK608UV1TVUxzhXcvvGwTt8+d1yUTZ cDjiUAxIg1DleEv/hnElkUpr76LeNuB0ngt/DpvuDpN3glWYA1lMNRkhCFhd+lmKf1Kf //c3qH1Cu1fVdt7VWvtMZOSzriga7NqSPbTNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VY4GBDNJL5L4sCfVbUZRJTVYPB/7M6zKhmAvWK/VrfDj/1A+wkeAPHqLJ3ztOemSNm rp0KjyuXVuSQWIH+zrjayPnsyPOMokwopEOLGHO1iCOiihWtvcFOQHVuo8Yq9kXRs/IN EIJAIHeZE0fUphtOAeE913kE5eF5DX8QGhbg0= MIME-Version: 1.0 Received: by 10.224.28.77 with SMTP id l13mr594321qac.375.1285727301770; Tue, 28 Sep 2010 19:28:21 -0700 (PDT) Received: by 10.229.63.14 with HTTP; Tue, 28 Sep 2010 19:28:21 -0700 (PDT) In-Reply-To: <4CA28DAD.8090905@usherbrooke.ca> References: <4C9D0C24.5080302@usherbrooke.ca> <4CA28DAD.8090905@usherbrooke.ca> Date: Tue, 28 Sep 2010 22:28:21 -0400 Message-ID: From: Stephen Botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=0015175caa2419ae7704915cb7fa Cc: "codec@ietf.org" Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 02:27:41 -0000 --0015175caa2419ae7704915cb7fa Content-Type: text/plain; charset=ISO-8859-1 >>> Normally, the decoder should be normative, which the encoder should not be. >>> I think this is an assumption on your part. Some groups in other SDOs make the encoder normative as well. Though I've never heard clear reasons, it seems to me that the "decoder-only" folks are mostly focused on applications with a massive encoder/decoder imbalance, while the "encoder and decoder" folks tend to be focused on applications with equal numbers of encoder and decoders. That seems logical, since if there are relatively few encoders, it is easier to solve any quality problems, and the content providers have very strong financial incentives to do so. So I am thinking that making the encoder normative makes sense, given that this application is centered on VOIP, so we want to ensure consistent quality in all endpoints. Regards Stephen Botzko On Tue, Sep 28, 2010 at 8:51 PM, Jean-Marc Valin < jean-marc.valin@usherbrooke.ca> wrote: > On 10-09-28 09:00 AM, Jonas Svedberg wrote: > >> " 5. In accordance with BCP 78 [TRUST], the source code for the >> reference implementation must be made available under a BSD-style >> license (or whatever license is defined as acceptable by the IETF >> Trust when the Internet-Draft defining the reference implementation >> is published)." >> >> To me it seems as the final point Marshall made: "the code on >> published RFCs has to have the BSD license." >> >> ,is a clearer and stricter wording than what is present in the >> current proposed guidelines, which uses the looser term "BSD-style", >> and further leaves other options open (in the parenthesis), and >> therefore makes the publishing directions in the guidelines quite >> unclear, to the developers. >> > > I believe the current wording is based on Stephen Wenger's argument about > "what if BCP78 were to specify a different license?" I don't have a strong > opinion on this detail, you two can sort this out :-) > > > With regard to formats and publishing in general, is there any >> precedence in IETF of having, the WG output split into several >> entities/specs ? (e.g sending side/receiving side or >> impl.A-fix/impl.B-Float) >> >> e.g. One could imagine having the receiving side definitions >> specified in one RFC, and the sending side definitions as another >> RFC, or even leave the sending side unspecified within IETF(e.g. as >> a separate open source project, which would then mainly take care of >> sending side code maintenance, assuming that maintenance issues on >> the sending side are much more frequent than on the receiving side). >> > > Normally, the decoder should be normative, which the encoder should not be. > Technically, the RFC could contain only the decoder, though practically we > need an encoder reference implementation. Since the encoder would likely not > be normative, it would probably not be necessary to update the RFC for > encoder-side improvements and the decoder is unlikely to change too much. > Also, note that there's quite a bit of code that is shared between the > encoder and decoder, fixed-point and floating point, so it would seem > logical/simpler to have a single document here. But again, I don't have a > strong opinion at this point. > > Cheers, > > Jean-Marc > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0015175caa2419ae7704915cb7fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 Normally, the decoder should be normative, which the= encoder should not be.
>>>
I think this is an assumption o= n your part.=A0 Some groups in other SDOs make the encoder normative as wel= l.

Though I've never heard clear reasons, it seems to me that the &quo= t;decoder-only" folks are mostly focused on applications with a massiv= e encoder/decoder imbalance, while the "encoder and decoder" folk= s tend to be focused on applications with equal numbers of encoder and deco= ders.=A0 That seems logical, since if there are relatively few encoders, it= is easier to solve any quality problems, and the content providers have ve= ry strong financial incentives to do so.

So I am thinking that making the encoder normative makes sense, given t= hat this application is centered on VOIP, so we want to ensure consistent q= uality in all endpoints.

Regards
Stephen Botzko

On Tue, Sep 28, 2010 at 8:51 PM, Jean-Marc Valin <jean-marc.valin@usherbrooke.c= a> wrote:
On 10-09-28 09:00 AM, Jonas Svedberg wrote:
" =A05. =A0In accordance with BCP 78 [TRUST], the source code for the<= br> reference implementation must be made available under a BSD-style
license (or whatever license is defined as acceptable by the IETF
Trust when the Internet-Draft defining the reference implementation
is published)."

To me it seems as the final point Marshall made: "the code on
published RFCs has to have the BSD license."

,is a clearer and stricter wording than what is present in the
current proposed guidelines, which uses the looser term "BSD-style&quo= t;,
and further leaves other options open (in the parenthesis), and
therefore makes the publishing directions in the guidelines quite
unclear, to the developers.

I believe the current wording is based on Stephen Wenger's argument abo= ut "what if BCP78 were to specify a different license?" I don'= ;t have a strong opinion on this detail, you two can sort this out :-)


With regard to =A0formats and publishing in general, is there any
precedence in IETF of having, the WG output split into several
entities/specs ? (e.g sending side/receiving side or
impl.A-fix/impl.B-Float)

e.g. One could imagine having the receiving side definitions
specified in one RFC, and the sending side definitions as another
RFC, or even leave the sending side unspecified within IETF(e.g. as
a separate open source project, which would then mainly take care of
sending side code maintenance, assuming that maintenance issues on
the sending side are much more frequent than on the receiving side).

Normally, the decoder should be normative, which the encoder should not be.= Technically, the RFC could contain only the decoder, though practically we= need an encoder reference implementation. Since the encoder would likely n= ot be normative, it would probably not be necessary to update the RFC for e= ncoder-side improvements and the decoder is unlikely to change too much. Al= so, note that there's quite a bit of code that is shared between the en= coder and decoder, fixed-point and floating point, so it would seem logical= /simpler to have a single document here. But again, I don't have a stro= ng opinion at this point.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc

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

--0015175caa2419ae7704915cb7fa-- From jean-marc.valin@usherbrooke.ca Tue Sep 28 19:45:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302DA3A6DB2 for ; Tue, 28 Sep 2010 19:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKsOOUBvP33s for ; Tue, 28 Sep 2010 19:45:20 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 0AAA63A6BFC for ; Tue, 28 Sep 2010 19:45:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MO-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L9H00HICMCN3FB0@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Tue, 28 Sep 2010 22:46:02 -0400 (EDT) Message-id: <4CA2A868.4060205@usherbrooke.ca> Date: Tue, 28 Sep 2010 22:46:00 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Stephen Botzko References: <4C9D0C24.5080302@usherbrooke.ca> <4CA28DAD.8090905@usherbrooke.ca> In-reply-to: Cc: "codec@ietf.org" Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 02:45:21 -0000 On 10-09-28 10:28 PM, Stephen Botzko wrote: > Though I've never heard clear reasons, it seems to me that the > "decoder-only" folks are mostly focused on applications with a massive > encoder/decoder imbalance, while the "encoder and decoder" folks tend to > be focused on applications with equal numbers of encoder and decoders. I think the main logic here is that when your codec leaves very few degrees of freedom to the encoder (the extreme case being an ADPCM codec, but CELP generally falls into that as well), then it's fine to have the encoder being normative. Voice codecs have typically fallen into that category because they were smaller than music codecs. Where I think it makes sense to *not* have a normative encoder is when the encoder has a lot of freedom. For example, an MP3 encoder has the freedom to define it's own psycho acoustic model, decide when to use short windows, and so on. And we have seen just how much MP3 encoders have improved over the years. This would have been impossible if the encoder had been specified normatively. I would say that the current codec we have here is closer to MP3 than it is to (e.g.) G.729. There is a *lot* of freedom in the encoder. Not only in how to switch between its three main modes (SILK, CELT, hybrid), but within each of these modes. Because of that, I believe that encoders will continue to evolve and get better over time, just like they did for MP3. > So I am thinking that making the encoder normative makes sense, given > that this application is centered on VOIP, so we want to ensure > consistent quality in all endpoints. I don't really see a problem with quality. Most implementors will likely end up using either the reference encoder, or improvement that got made over time. I don't think anyone will complain with having better quality than the standard specified. Cheers, Jean-Marc From stewe@stewe.org Tue Sep 28 22:03:32 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FBF3A6E67 for ; Tue, 28 Sep 2010 22:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL9Pl-B8VtWw for ; Tue, 28 Sep 2010 22:03:30 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 613A33A6E16 for ; Tue, 28 Sep 2010 22:03:28 -0700 (PDT) Received: from [192.168.1.105] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 799407-1743317 for multiple; Wed, 29 Sep 2010 07:04:08 +0200 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 28 Sep 2010 22:03:55 -0700 From: Stephan Wenger To: Jean-Marc Valin , Stephen Botzko Message-ID: Thread-Topic: [codec] Format for the codec specification Thread-Index: Actfk7dI0cu+Dc4iEkmdSSxG64JFuQ== In-Reply-To: <4CA2A868.4060205@usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 05:03:32 -0000 Hi all, especially Jean-Marc and Stephen, I think you are both thinking too technical on this question. My understanding is that the speech codecs from the ITU and from 3GPP and 3GPP2 are/have been mostly telco driven developments. In many legislations, Telcos have to offer their customers a guaranteed quality level. It is easier for them to ensure that level to be achieved by disallowing vendor differentiation in quality. Personally, I believe that a codec targeted for a best effort network is best designed without a strict encoder specification. That said, I continue to argue that we will be better off with a bit-exact decoder design. Again, the reason is not technical, but (patent-) licensing related. While it is comparatively easy, in a bit-exact decoder design, to determine whether a given patent claim is essential to practice the standard, this is not the case for a design that is based on bitstream syntax, aspects of the decoder operation, and minimum performance requirements (which, I believe, is roughly where some people are heading). Note that it is even more important for a royalty-free codec development to have a clear understanding about which claims are essential, than for a RAND codec. The reason is simple: in the RF case, the development has to stay clear of any and all claims that may not be available under "exotic" (in this industry) RF terms, whereas for a RAND codec, people only have to worry about the inclusion of claims that may not be available for RAND licensing at all (which are very few in this industry). As a result, a non bit-exact decoder design has to be much more conservative in exercising technology (as more claims may be swept in by advanced designs) than a bit exact decoder design, neutralizing, IMO, most of the positive effects a non bit-exact design may have from a performance viewpoint. In summary, I continue to argue in favor of the MPEG model: (bit-exactly) standardize the bitstream and the decoder operation on it. A test-model level encoder design document is desirable as well, as could be minimum performance specs for the encoder, but, IMO, neither need to be normative. Regards, Stephan On 9.28.2010 19:46 , "Jean-Marc Valin" wrote: > On 10-09-28 10:28 PM, Stephen Botzko wrote: >> Though I've never heard clear reasons, it seems to me that the >> "decoder-only" folks are mostly focused on applications with a massive >> encoder/decoder imbalance, while the "encoder and decoder" folks tend to >> be focused on applications with equal numbers of encoder and decoders. > > I think the main logic here is that when your codec leaves very few > degrees of freedom to the encoder (the extreme case being an ADPCM > codec, but CELP generally falls into that as well), then it's fine to > have the encoder being normative. Voice codecs have typically fallen > into that category because they were smaller than music codecs. Where I > think it makes sense to *not* have a normative encoder is when the > encoder has a lot of freedom. For example, an MP3 encoder has the > freedom to define it's own psycho acoustic model, decide when to use > short windows, and so on. And we have seen just how much MP3 encoders > have improved over the years. This would have been impossible if the > encoder had been specified normatively. > > I would say that the current codec we have here is closer to MP3 than it > is to (e.g.) G.729. There is a *lot* of freedom in the encoder. Not only > in how to switch between its three main modes (SILK, CELT, hybrid), but > within each of these modes. Because of that, I believe that encoders > will continue to evolve and get better over time, just like they did for > MP3. > >> So I am thinking that making the encoder normative makes sense, given >> that this application is centered on VOIP, so we want to ensure >> consistent quality in all endpoints. > > I don't really see a problem with quality. Most implementors will likely > end up using either the reference encoder, or improvement that got made > over time. I don't think anyone will complain with having better quality > than the standard specified. > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Wed Sep 29 03:55:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF113A6D3B for ; Wed, 29 Sep 2010 03:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2aSWr6SapNL for ; Wed, 29 Sep 2010 03:55:20 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id D53293A6D2A for ; Wed, 29 Sep 2010 03:55:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L9I006J191ACLA0@VL-MR-MRZ20.ip.videotron.ca> for codec@ietf.org; Wed, 29 Sep 2010 06:55:58 -0400 (EDT) Message-id: <4CA31B43.5050107@usherbrooke.ca> Date: Wed, 29 Sep 2010 06:56:03 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 To: Stephan Wenger References: In-reply-to: Cc: "codec@ietf.org" , Stephen Botzko Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 10:55:21 -0000 Hi Stephen, > In summary, I continue to argue in favor of the MPEG model: (bit-exactly) > standardize the bitstream and the decoder operation on it. Actually, to the best of my knowledge, MPEG does *not* specify the decoder in a bit-exact way. IIRC the spec has a floating-point decoder and then says by how much the output is allowed to deviate from the reference decoder. The same strategy is used in EVRB (A and B). This makes sense. Otherwise, we can argue for years over how exactly to define a multiplication (e.g. whether to round and how) because there's about a dozen different ways you can define some of these basic operations. Jean-Marc On 10-09-29 01:03 AM, Stephan Wenger wrote: > Hi all, especially Jean-Marc and Stephen, > > I think you are both thinking too technical on this question. My > understanding is that the speech codecs from the ITU and from 3GPP and 3GPP2 > are/have been mostly telco driven developments. In many legislations, > Telcos have to offer their customers a guaranteed quality level. It is > easier for them to ensure that level to be achieved by disallowing vendor > differentiation in quality. > > Personally, I believe that a codec targeted for a best effort network is > best designed without a strict encoder specification. > > That said, I continue to argue that we will be better off with a bit-exact > decoder design. Again, the reason is not technical, but (patent-) licensing > related. While it is comparatively easy, in a bit-exact decoder design, to > determine whether a given patent claim is essential to practice the > standard, this is not the case for a design that is based on bitstream > syntax, aspects of the decoder operation, and minimum performance > requirements (which, I believe, is roughly where some people are heading). > > Note that it is even more important for a royalty-free codec development to > have a clear understanding about which claims are essential, than for a RAND > codec. The reason is simple: in the RF case, the development has to stay > clear of any and all claims that may not be available under "exotic" (in > this industry) RF terms, whereas for a RAND codec, people only have to worry > about the inclusion of claims that may not be available for RAND licensing > at all (which are very few in this industry). As a result, a non bit-exact > decoder design has to be much more conservative in exercising technology (as > more claims may be swept in by advanced designs) than a bit exact decoder > design, neutralizing, IMO, most of the positive effects a non bit-exact > design may have from a performance viewpoint. > > In summary, I continue to argue in favor of the MPEG model: (bit-exactly) > standardize the bitstream and the decoder operation on it. > > A test-model level encoder design document is desirable as well, as could be > minimum performance specs for the encoder, but, IMO, neither need to be > normative. > > Regards, > Stephan > > > > > > On 9.28.2010 19:46 , "Jean-Marc Valin" > wrote: > >> On 10-09-28 10:28 PM, Stephen Botzko wrote: >>> Though I've never heard clear reasons, it seems to me that the >>> "decoder-only" folks are mostly focused on applications with a massive >>> encoder/decoder imbalance, while the "encoder and decoder" folks tend to >>> be focused on applications with equal numbers of encoder and decoders. >> >> I think the main logic here is that when your codec leaves very few >> degrees of freedom to the encoder (the extreme case being an ADPCM >> codec, but CELP generally falls into that as well), then it's fine to >> have the encoder being normative. Voice codecs have typically fallen >> into that category because they were smaller than music codecs. Where I >> think it makes sense to *not* have a normative encoder is when the >> encoder has a lot of freedom. For example, an MP3 encoder has the >> freedom to define it's own psycho acoustic model, decide when to use >> short windows, and so on. And we have seen just how much MP3 encoders >> have improved over the years. This would have been impossible if the >> encoder had been specified normatively. >> >> I would say that the current codec we have here is closer to MP3 than it >> is to (e.g.) G.729. There is a *lot* of freedom in the encoder. Not only >> in how to switch between its three main modes (SILK, CELT, hybrid), but >> within each of these modes. Because of that, I believe that encoders >> will continue to evolve and get better over time, just like they did for >> MP3. >> >>> So I am thinking that making the encoder normative makes sense, given >>> that this application is centered on VOIP, so we want to ensure >>> consistent quality in all endpoints. >> >> I don't really see a problem with quality. Most implementors will likely >> end up using either the reference encoder, or improvement that got made >> over time. I don't think anyone will complain with having better quality >> than the standard specified. >> >> Cheers, >> >> Jean-Marc >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > > From bmschwar@fas.harvard.edu Wed Sep 29 07:04:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0D13A6EA6 for ; Wed, 29 Sep 2010 07:04:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eUpJU7bdEQ9 for ; Wed, 29 Sep 2010 07:04:00 -0700 (PDT) Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by core3.amsl.com (Postfix) with ESMTP id 85E993A6E0A for ; Wed, 29 Sep 2010 07:04:00 -0700 (PDT) Received: from us24.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us24.unix.fas.harvard.edu (Postfix) with ESMTP id 93C8A46E161; Wed, 29 Sep 2010 10:04:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=/ccsq0CVe4EYPUe ykQo56dfTqVbbOqNnWIzEfgiJfAg=; b=Q9k0LDuGIepcowedXVyyaiIAfvKXq+0 Yy843L8vynQO85kEPLtLe4TDHyhZQaJI0PyVHZTU/SjVptakhOPXxsI3S+j7FBTX BqoxHlZYqGLYiTWFCxvgQCSQq2VwdpSBK/lWa+p+Bq9CiSqQP9n9vqRJ/VAktv++ vRArG2Z/zz/4= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=G/jttdWy8 pPQue9cWLunDJTkQtGDzrwRTpy3vcC/S7rbIMR+ktUFF0EBQU1T7gIisUYm+ogFa VB8inUCEzlmlYrsy6IRr1A5enW7+d6TkIqhe+1WdbVNiOZgvsqbT6w5yLV74MhvR n8uV63abd5VcXbXi2N3mljNTFv6q2222Cg= Received: from [192.168.1.140] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us24.unix.fas.harvard.edu (Postfix) with ESMTPSA id 7E0F546E113; Wed, 29 Sep 2010 10:04:43 -0400 (EDT) Message-ID: <4CA3477A.4070007@fas.harvard.edu> Date: Wed, 29 Sep 2010 10:04:42 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig574BC01945984B4E4FBA7467" Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Format for the codec specification X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:04:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig574BC01945984B4E4FBA7467 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/29/2010 01:03 AM, Stephan Wenger wrote: > As a result, a non bit-exact > decoder design has to be much more conservative in exercising technolog= y (as > more claims may be swept in by advanced designs) than a bit exact decod= er > design, neutralizing, IMO, most of the positive effects a non bit-exact= > design may have from a performance viewpoint. Surely the converse logic also applies. A non-bitexact decoder can more easily be modified to dodge any unexpected patent claims brought against it, because its designers are not restricted to alterations that do not affect the output. Personally, I favor the following: We should produce a fixed-point reference decoder, specified bit-exactly in code and text. We should indicate that implementors who require a guaranteed level of service should follow this bit-exact specification. We should _not_ set any limits on the deviation of other decoders from this bit-exact specificati= on. Reasoning: We should provide a bit-exact decoder specification because otherwise it is unclear how to optimize the encoder later. A codec with no licensing restrictions has no gatekeeper, so any restrictions on performance would be unenforceable in practice. The lack= of restrictions also means that the codec can easily be extremely widely implemented, enabling commodity competition between different implementors. Competition can keep quality high. Large single-vendor deployments, without internal competition, are likely= to have a contractually required level of service, in which case the RFC would direct the implementor to remain bit-exact. One option we have would be to specify the decoder under two different names: "$CODEC" and "Bit-Exact $CODEC". --Ben --------------enig574BC01945984B4E4FBA7467 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyjR3oACgkQUJT6e6HFtqSNjgCfRdhod5mQs5qvSW3ZS0eWD9Wh c/gAn1Pg+wNp6/c7qHY2Xm+YsqrPNB6B =dX+5 -----END PGP SIGNATURE----- --------------enig574BC01945984B4E4FBA7467-- From mknappe@juniper.net Wed Sep 29 14:54:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6FF3A6C43 for ; Wed, 29 Sep 2010 14:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.72 X-Spam-Level: X-Spam-Status: No, score=-104.72 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFxWUyeAZm1H for ; Wed, 29 Sep 2010 14:54:46 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 8FEB73A6C09 for ; Wed, 29 Sep 2010 14:54:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTKO10kewrvfOFan9vnhrXqq6qVa9b2kD@postini.com; Wed, 29 Sep 2010 14:55:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 29 Sep 2010 14:55:24 -0700 From: Michael Knappe To: "codec@ietf.org" Date: Wed, 29 Sep 2010 14:55:21 -0700 Thread-Topic: [codec] McGill university speech database Thread-Index: ActgIQL1rV2vEHjq5UuWF93xCyy/iQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [codec] McGill university speech database X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 21:54:50 -0000 Just received permission from Dr. Peter Kabal at McGill University to use t= heir 1400 utterance, 24 different talker (12 male, 12 female) Harvard sente= nce speech database for our codec testing efforts in the IETF codec WG. Inc= ludes the original 48 kHz files. My preference is just to put the McGill li= nk to the 539 MB CD ISO image file up on the codec wiki, if that sounds ok = with everyone I will get final permission to post the link from Dr. Kabal a= nd get them up on the wiki asap. Next step is to work on getting rights to representative music content. A c= apella vocals (e.g. Tom=92s Diner) , orchestral crescendo=92s, castanets, s= olo violin, jazz trumpet/ensembles, rock/electronica etc would all be good = to include for testing, please reply with any suggestions. Thanks to Jean-Marc for the pointer to Dr. Kabal and the speech database! Cheers, Mike