From mknappe@juniper.net Wed Jan 12 01:31:57 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453BF28C11A for ; Wed, 12 Jan 2011 01:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.389 X-Spam-Level: X-Spam-Status: No, score=-106.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 M6fQwx4+L+ph for ; Wed, 12 Jan 2011 01:31:55 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 66C8228C118 for ; Wed, 12 Jan 2011 01:31:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTS11jx3lIFhYDafATrXgF3k7IN1YuG2S@postini.com; Wed, 12 Jan 2011 01:34:14 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 12 Jan 2011 01:32:37 -0800 From: Michael Knappe To: Christian Hoene , "codec@ietf.org" Date: Wed, 12 Jan 2011 01:32:35 -0800 Thread-Topic: [codec] Testing Codec Quality Thread-Index: AcuS0pQ1qPinbi39R6KAd6QdOO+jfAfaRC0B Message-ID: In-Reply-To: <000f01cb92d2$96d04490$c470cdb0$@de> 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] Testing Codec Quality 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, 12 Jan 2011 09:31:57 -0000 Christian - WOW, what a fantastic document! I encourage everyone to read this through and provide comments back to the mailing list. In particular, check out section 10.2 which lists detailed considerations for the proposed semi-formal testing with the 6+ volunteer 'test houses'. One of the issues we've been dealing with in our discussions is how to divide up testing of even a simplified list of codec configuratio= n and operational permutations (Christian easily came up with 48 different test cases) between the test houses. The plan is to have a very short list of basic codec test cases that every test house repeats, along with a longe= r list of permutations that is divided among the test houses. We do need to add a section outlining the proposed widescale informal listening tests via a web based mushra app that will be done alongside the semi-formal testing. Look for that app soon at www.open-codec.com, we're working on getting that app up and running as we speak. Thanks again to Christian for all the effort put into this doc. Cheers,=20 Mike On 12/3/10 2:12 AM, "Christian Hoene" wrote: > Hi, >=20 > one important question back to the days where iLBC was submitted to the I= ETF > was: how do we know whether iLBC is a technical sound contribution to the > IETF? >=20 > The draft http://www.ietf.org/id/draft-hoene-codec-quality-00.pdf address= es > this question in the context of this WG. The first chapters describe well > established procedures on how to test a codec (and goes a bit beyond that > where needed). Finally, Chapter 10 suggests a procedure on how to test II= AC > (or Opus). >=20 > Timely feedback is welcomed as the testing shall start soon. >=20 > With best regards, >=20 > Christian >=20 >=20 > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Thu Jan 13 14:25:21 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0C43A6C01 for ; Thu, 13 Jan 2011 14:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMEpBCTpxLlV for ; Thu, 13 Jan 2011 14:25:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 77B473A6BFE for ; Thu, 13 Jan 2011 14:25:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFAEALL02rRN+K/2dsb2JhbACWOY4Uc6QJmDWFTASEaIYogyI Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2011 22:27:44 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0DMRhZc011499 for ; Thu, 13 Jan 2011 22:27:43 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 15:29:19 -0700 Message-Id: <6963A8AD-F30C-4688-909A-68D4FEAF91C2@cisco.com> To: codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [codec] Next Steps for WG 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, 13 Jan 2011 22:25:21 -0000 The OPUS draft authors believe the bitstream for OPUS will be ready to = be "frozen" by the end of the month. At that point we plan to spend the = following month testing and, baring any surprises, will likely go to = WGLC after that.=20 There has been some questions about what "frozen" means in IETF context. = The bitstream could change any time up to when the IESG approves it = which is after Working Group Last call and after IETF Last Call so there = is no guarantee that nothing will change but ... by "frozen" we mean = that we believe no changes are needed and don't plan to make changes = unless some significant problem is found. Thanks, Cullen, Jonathan, and Mike From roman@telurix.com Thu Jan 13 16:32:40 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9E128B23E for ; Thu, 13 Jan 2011 16:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivYWR+YInAJQ for ; Thu, 13 Jan 2011 16:32:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AFA6B3A6784 for ; Thu, 13 Jan 2011 16:32:38 -0800 (PST) Received: by iwn40 with SMTP id 40so2197906iwn.31 for ; Thu, 13 Jan 2011 16:35:02 -0800 (PST) Received: by 10.42.240.2 with SMTP id ky2mr86413icb.460.1294965301727; Thu, 13 Jan 2011 16:35:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id f7sm393138icq.5.2011.01.13.16.34.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 16:35:00 -0800 (PST) Received: by iyi42 with SMTP id 42so2227327iyi.31 for ; Thu, 13 Jan 2011 16:34:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.199.77 with SMTP id er13mr80736ibb.44.1294965298679; Thu, 13 Jan 2011 16:34:58 -0800 (PST) Received: by 10.231.20.139 with HTTP; Thu, 13 Jan 2011 16:34:58 -0800 (PST) In-Reply-To: <6963A8AD-F30C-4688-909A-68D4FEAF91C2@cisco.com> References: <6963A8AD-F30C-4688-909A-68D4FEAF91C2@cisco.com> Date: Thu, 13 Jan 2011 19:34:58 -0500 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=90e6ba47682b9fd2b10499c39aef Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 14 Jan 2011 00:32:40 -0000 --90e6ba47682b9fd2b10499c39aef Content-Type: text/plain; charset=ISO-8859-1 Just out of curiosity, have the OPUS codec been review against the list of requirements that we put together? In particular, I raised the requirement that multiple encoded streams form different sources can be efficiently combined. Is it possible with OPUS? If it is, then how? _____________________________ Roman Shpount - www.telurix.com On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings wrote: > > The OPUS draft authors believe the bitstream for OPUS will be ready to be > "frozen" by the end of the month. At that point we plan to spend the > following month testing and, baring any surprises, will likely go to WGLC > after that. > > There has been some questions about what "frozen" means in IETF context. > The bitstream could change any time up to when the IESG approves it which is > after Working Group Last call and after IETF Last Call so there is no > guarantee that nothing will change but ... by "frozen" we mean that we > believe no changes are needed and don't plan to make changes unless some > significant problem is found. > > Thanks, > Cullen, Jonathan, and Mike > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --90e6ba47682b9fd2b10499c39aef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just out of curiosity, have the OPUS codec been review against the list of = requirements that we put together?

In particular, I raised the requi= rement that multiple encoded streams form different sources can be efficien= tly combined. Is it possible with OPUS? If it is, then how?
_____________________________
Roman Shpount - www.telurix.com


On Thu, Jan 13, 2011 at 5:29 PM, Cullen = Jennings <fluffy@c= isco.com> wrote:

The OPUS draft authors believe the bitstream for OPUS will be ready to be &= quot;frozen" by the end of the month. At that point we plan to spend t= he following month testing and, baring any surprises, will likely go to WGL= C after that.

There has been some questions about what "frozen" means in IETF c= ontext. The bitstream could change any time up to when the IESG approves it= which is after Working Group Last call and after IETF Last Call so there i= s no guarantee that nothing will change but ... =A0by "frozen" we= mean that we believe no changes are needed and don't plan to make chan= ges unless some significant problem is found.

Thanks,
Cullen, Jonathan, and Mike


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

--90e6ba47682b9fd2b10499c39aef-- From jmvalin@jmvalin.ca Thu Jan 13 18:48:34 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07223A6C3C for ; Thu, 13 Jan 2011 18:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExGeUdZeJPVf for ; Thu, 13 Jan 2011 18:48:33 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 748673A6819 for ; Thu, 13 Jan 2011 18:48:33 -0800 (PST) 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 <0LEZ002L8RWW6AA0@VL-MR-MRZ22.ip.videotron.ca> for codec@ietf.org; Thu, 13 Jan 2011 21:50:57 -0500 (EST) Message-id: <4D2FBA0F.3040904@jmvalin.ca> Date: Thu, 13 Jan 2011 21:50:55 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 To: Roman Shpount References: <6963A8AD-F30C-4688-909A-68D4FEAF91C2@cisco.com> In-reply-to: Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 14 Jan 2011 02:48:34 -0000 Hi Roman, We believe that we meet all requirements that were identified. As for mixing multiple encoded streams, that was marked as desirable in the draft because it's very hard to achieve without sacrificing efficiency. To some extent, if you constrain the Opus encoder to a subset of the available options (CELT only without short blocks or post-filter), then you can create streams that can be mixed at roughly half the normal complexity. I think that's about as much as we can do here. Cheers, Jean-Marc On 11-01-13 07:34 PM, Roman Shpount wrote: > Just out of curiosity, have the OPUS codec been review against the list > of requirements that we put together? > > In particular, I raised the requirement that multiple encoded streams > form different sources can be efficiently combined. Is it possible with > OPUS? If it is, then how? > _____________________________ > Roman Shpount - www.telurix.com > > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings > wrote: > > > The OPUS draft authors believe the bitstream for OPUS will be ready > to be "frozen" by the end of the month. At that point we plan to > spend the following month testing and, baring any surprises, will > likely go to WGLC after that. > > There has been some questions about what "frozen" means in IETF > context. The bitstream could change any time up to when the IESG > approves it which is after Working Group Last call and after IETF > Last Call so there is no guarantee that nothing will change but ... > by "frozen" we mean that we believe no changes are needed and > don't plan to make changes unless some significant problem is found. > > Thanks, > Cullen, Jonathan, and 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 hoene@uni-tuebingen.de Fri Jan 14 00:24:41 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4147F3A6C58 for ; Fri, 14 Jan 2011 00:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM0Va-OT2n9V for ; Fri, 14 Jan 2011 00:24:40 -0800 (PST) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id B17A93A6AB9 for ; Fri, 14 Jan 2011 00:24:39 -0800 (PST) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p0E8R1xx022878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jan 2011 09:27:02 +0100 From: "Christian Hoene" To: "'Jean-Marc Valin'" , "'Roman Shpount'" References: <6963A8AD-F30C-4688-909A-68D4FEAF91C2@cisco.com> <4D2FBA0F.3040904@jmvalin.ca> In-Reply-To: <4D2FBA0F.3040904@jmvalin.ca> Date: Fri, 14 Jan 2011 09:27:02 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJktPotNG8jvenizKbKD0XJxNxZmgJCrN5+AbafNDqSflScYA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 14 Jan 2011 08:24:41 -0000 The easiest way to mix the multiple streams is to take advantage of the DTX feature, which is available in the Silk and hybrid mode. However, I am not aware whether DTX or VAD is supported in the CELT mode. Christian > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Friday, January 14, 2011 3:51 AM > To: Roman Shpount > Cc: codec@ietf.org > Subject: Re: [codec] Next Steps for WG > > Hi Roman, > > We believe that we meet all requirements that were identified. As for mixing > multiple encoded streams, that was marked as desirable in the draft because > it's very hard to achieve without sacrificing efficiency. > To some extent, if you constrain the Opus encoder to a subset of the > available options (CELT only without short blocks or post-filter), then you can > create streams that can be mixed at roughly half the normal complexity. I > think that's about as much as we can do here. > > Cheers, > > Jean-Marc > > On 11-01-13 07:34 PM, Roman Shpount wrote: > > Just out of curiosity, have the OPUS codec been review against the > > list of requirements that we put together? > > > > In particular, I raised the requirement that multiple encoded streams > > form different sources can be efficiently combined. Is it possible > > with OPUS? If it is, then how? > > _____________________________ > > Roman Shpount - www.telurix.com > > > > > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings > > wrote: > > > > > > The OPUS draft authors believe the bitstream for OPUS will be ready > > to be "frozen" by the end of the month. At that point we plan to > > spend the following month testing and, baring any surprises, will > > likely go to WGLC after that. > > > > There has been some questions about what "frozen" means in IETF > > context. The bitstream could change any time up to when the IESG > > approves it which is after Working Group Last call and after IETF > > Last Call so there is no guarantee that nothing will change but ... > > by "frozen" we mean that we believe no changes are needed and > > don't plan to make changes unless some significant problem is found. > > > > Thanks, > > Cullen, Jonathan, and 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 koen.vos@skype.net Fri Jan 14 13:38:49 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5613A6C87 for ; Fri, 14 Jan 2011 13:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 KPEfcQ17xMgD for ; Fri, 14 Jan 2011 13:38:47 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 4A81B3A6BD4 for ; Fri, 14 Jan 2011 13:38:47 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A778D16F7; Fri, 14 Jan 2011 22:41:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=oA7kW7CIt+oFxUZ/NgNsCjozK+o= ; b=VqacI2kVDcldRJpI09xXObwlEXBdUSohX7SpmJZ2Pc2huQjKpV9OfQ3iZucF kbIq+FmPCbXoyzOYL2UVT8G4TpcP4WbLKcsntGvvWBcAEI0OmMyTHvTTyAiS3Q3d eK5/AloUyPqsuM0Ds4UkH3gikmH8VOW5DzQYWJFdjA9n+bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=jRWlcZEEOeEfZRrehbMgZO gKmaxqw4HqRJeOJ8m15d89/Eyks+DusGw0FA6dA+3Hmjffc9DbPcpIVT+aKjlr+M RnEwwAS0vHgJUFHDkSjWfifTe41GoWhblpzAsRpG2fc1xgfzqLTd1VmRK6ZgFo+E ra1CKA1g4hU4D/vNUsfUw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9C8FB7F3; Fri, 14 Jan 2011 22:41:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7904E3507791; Fri, 14 Jan 2011 22:41:12 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7FmkM8CMjzo; Fri, 14 Jan 2011 22:41:10 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 8509B3506F82; Fri, 14 Jan 2011 22:41:10 +0100 (CET) Date: Fri, 14 Jan 2011 22:41:10 +0100 (CET) From: Koen Vos To: Christian Hoene Message-ID: <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> In-Reply-To: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 14 Jan 2011 21:38:49 -0000 Even without DTX, the Voice modes will expose a Voice Activity flag in the decoder API. This will reveal without any decoding whether a payload contains active speech. And all decoder modes have low CPU demands, so decoding all streams to determine which ones are most active is relatively cheap. koen. ----- Original Message ----- From: "Christian Hoene" To: "Jean-Marc Valin" , "Roman Shpount" Cc: codec@ietf.org Sent: Friday, January 14, 2011 12:27:02 AM Subject: Re: [codec] Next Steps for WG The easiest way to mix the multiple streams is to take advantage of the DTX feature, which is available in the Silk and hybrid mode. However, I am not aware whether DTX or VAD is supported in the CELT mode. Christian > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Friday, January 14, 2011 3:51 AM > To: Roman Shpount > Cc: codec@ietf.org > Subject: Re: [codec] Next Steps for WG > > Hi Roman, > > We believe that we meet all requirements that were identified. As for mixing > multiple encoded streams, that was marked as desirable in the draft because > it's very hard to achieve without sacrificing efficiency. > To some extent, if you constrain the Opus encoder to a subset of the > available options (CELT only without short blocks or post-filter), then you can > create streams that can be mixed at roughly half the normal complexity. I > think that's about as much as we can do here. > > Cheers, > > Jean-Marc > > On 11-01-13 07:34 PM, Roman Shpount wrote: > > Just out of curiosity, have the OPUS codec been review against the > > list of requirements that we put together? > > > > In particular, I raised the requirement that multiple encoded streams > > form different sources can be efficiently combined. Is it possible > > with OPUS? If it is, then how? > > _____________________________ > > Roman Shpount - www.telurix.com > > > > > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings > > wrote: > > > > > > The OPUS draft authors believe the bitstream for OPUS will be ready > > to be "frozen" by the end of the month. At that point we plan to > > spend the following month testing and, baring any surprises, will > > likely go to WGLC after that. > > > > There has been some questions about what "frozen" means in IETF > > context. The bitstream could change any time up to when the IESG > > approves it which is after Working Group Last call and after IETF > > Last Call so there is no guarantee that nothing will change but ... > > by "frozen" we mean that we believe no changes are needed and > > don't plan to make changes unless some significant problem is found. > > > > Thanks, > > Cullen, Jonathan, and 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 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From roman@telurix.com Fri Jan 14 21:24:47 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE043A6BBD for ; Fri, 14 Jan 2011 21:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD7eHUkqeO2S for ; Fri, 14 Jan 2011 21:24:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1F69B3A689A for ; Fri, 14 Jan 2011 21:24:44 -0800 (PST) Received: by iyi42 with SMTP id 42so3390175iyi.31 for ; Fri, 14 Jan 2011 21:27:12 -0800 (PST) Received: by 10.231.16.73 with SMTP id n9mr445809iba.113.1295069230479; Fri, 14 Jan 2011 21:27:10 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id gy41sm1590223ibb.5.2011.01.14.21.27.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 21:27:09 -0800 (PST) Received: by iwn40 with SMTP id 40so3364080iwn.31 for ; Fri, 14 Jan 2011 21:27:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.74 with SMTP id f10mr1602811iba.119.1295069227614; Fri, 14 Jan 2011 21:27:07 -0800 (PST) Received: by 10.231.20.139 with HTTP; Fri, 14 Jan 2011 21:27:07 -0800 (PST) In-Reply-To: <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> References: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> Date: Sat, 15 Jan 2011 00:27:07 -0500 Message-ID: From: Roman Shpount To: Koen Vos Content-Type: multipart/alternative; boundary=00221532cb384582af0499dbcda1 Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 15 Jan 2011 05:24:47 -0000 --00221532cb384582af0499dbcda1 Content-Type: text/plain; charset=ISO-8859-1 My question was not as much about the VAD, as about multiple stream combining. What I want is to implement is switching between multiple talker based on VAD (computation of which is done by some external methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that it can immediately start correctly decoding the new audio without a glitch. So, the minimum requirement would be to have a flag or a packet that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio history stored on the conferencing server, and to send this decoder state to the remote party so that it can be synchronized. I don't think this should affect the codec performance. This is just something that needs to be accommodated in the bitstream by adding a packet type which either resets the decoder state or sets it to some specified value. I would also prefer if this was working across all the codec modes and did not require the conferencing server from restricting what kinds of encoded audio it can accept. _____________ Roman Shpount On Fri, Jan 14, 2011 at 4:41 PM, Koen Vos wrote: > Even without DTX, the Voice modes will expose a Voice Activity flag in the > decoder API. This will reveal without any decoding whether a payload > contains active speech. > > And all decoder modes have low CPU demands, so decoding all streams to > determine which ones are most active is relatively cheap. > > koen. > > > ----- Original Message ----- > From: "Christian Hoene" > To: "Jean-Marc Valin" , "Roman Shpount" < > roman@telurix.com> > Cc: codec@ietf.org > Sent: Friday, January 14, 2011 12:27:02 AM > Subject: Re: [codec] Next Steps for WG > > The easiest way to mix the multiple streams is to take advantage of the DTX > feature, which is available in the Silk and hybrid mode. However, I am not > aware whether DTX or VAD is supported in the CELT mode. > > Christian > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Jean-Marc Valin > > Sent: Friday, January 14, 2011 3:51 AM > > To: Roman Shpount > > Cc: codec@ietf.org > > Subject: Re: [codec] Next Steps for WG > > > > Hi Roman, > > > > We believe that we meet all requirements that were identified. As for > mixing > > multiple encoded streams, that was marked as desirable in the draft > because > > it's very hard to achieve without sacrificing efficiency. > > To some extent, if you constrain the Opus encoder to a subset of the > > available options (CELT only without short blocks or post-filter), then > you can > > create streams that can be mixed at roughly half the normal complexity. I > > think that's about as much as we can do here. > > > > Cheers, > > > > Jean-Marc > > > > On 11-01-13 07:34 PM, Roman Shpount wrote: > > > Just out of curiosity, have the OPUS codec been review against the > > > list of requirements that we put together? > > > > > > In particular, I raised the requirement that multiple encoded streams > > > form different sources can be efficiently combined. Is it possible > > > with OPUS? If it is, then how? > > > _____________________________ > > > Roman Shpount - www.telurix.com > > > > > > > > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings > > > wrote: > > > > > > > > > The OPUS draft authors believe the bitstream for OPUS will be ready > > > to be "frozen" by the end of the month. At that point we plan to > > > spend the following month testing and, baring any surprises, will > > > likely go to WGLC after that. > > > > > > There has been some questions about what "frozen" means in IETF > > > context. The bitstream could change any time up to when the IESG > > > approves it which is after Working Group Last call and after IETF > > > Last Call so there is no guarantee that nothing will change but ... > > > by "frozen" we mean that we believe no changes are needed and > > > don't plan to make changes unless some significant problem is > found. > > > > > > Thanks, > > > Cullen, Jonathan, and 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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --00221532cb384582af0499dbcda1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My question was not as much about the VAD, as about multiple stream combini= ng. What I want is to implement is switching between multiple talker based = on VAD (computation of which is done by some external methods). In this cas= e we need to indicate to the remote party that this is a new stream and ide= ally get the remote decoder in such a state that it can immediately start c= orrectly decoding the new audio without a glitch. So, the minimum requireme= nt would be to have a flag or a packet that indicates the decoder that it n= eeds to reset its state. Ideally, we need an algorithm to get the proper de= coder state based on some audio history stored on the conferencing server, = and to send this decoder state to the remote party so that it can be synchr= onized. I don't think this should affect the codec performance. This is= just something that needs to be accommodated in the bitstream by adding a = packet type which either resets the decoder state or sets it to some specif= ied value.

I would also prefer if this was working across all the codec modes and = did not require the conferencing server from restricting what kinds of enco= ded audio it can accept.
_____________
Roman Shpount

On Fri, Jan 14, 2011 at 4:41 PM, Koen Vo= s <koen.vos@skyp= e.net> wrote:
Even without DTX, the Voice modes will expose a Voice Activity flag in the = decoder API. This will reveal without any decoding whether a payload contai= ns active speech.

And all decoder modes have low CPU demands, so decoding all streams to dete= rmine which ones are most active is relatively cheap.

koen.


----- Original Message -----
From: "Christian Hoene" <hoene@uni-tuebingen.de>
To: "Jean-Marc Valin" <j= mvalin@jmvalin.ca>, "Roman Shpount" <roman@telurix.com>
Cc: codec@ietf.org
Sent: Friday, January 14, 2011 12:27:02 AM
Subject: Re: [codec] Next Steps for WG

The easiest way to mix the multiple streams is to take advantage of the DTX=
feature, which is available in the Silk and hybrid mode. However, I am not<= br> aware whether DTX or VAD is supported in the CELT mode.

Christian

> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On Behalf
> Of Jean-Marc Valin
> Sent: Friday, January 14, 2011 3:51 AM
> To: Roman Shpount
> Cc: codec@ietf.org
> Subject: Re: [codec] Next Steps for WG
>
> Hi Roman,
>
> We believe that we meet all requirements that were identified. As for<= br> mixing
> multiple encoded streams, that was marked as desirable in the draft because
> it's very hard to achieve without sacrificing efficiency.
> To some extent, if you constrain the Opus encoder to a subset of the > available options (CELT only without short blocks or post-filter), the= n
you can
> create streams that can be mixed at roughly half the normal complexity= . I
> think that's about as much as we can do here.
>
> Cheers,
>
> =A0 =A0 =A0 Jean-Marc
>
> On 11-01-13 07:34 PM, Roman Shpount wrote:
> > Just out of curiosity, have the OPUS codec been review against th= e
> > list of requirements that we put together?
> >
> > In particular, I raised the requirement that multiple encoded str= eams
> > form different sources can be efficiently combined. Is it possibl= e
> > with OPUS? If it is, then how?
> > _____________________________
> > Roman Shpount - www.telurix.com <http://www.telurix.com>
> >
> >
> > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings <fluffy@cisco.com
> > <mailto:fluffy@cisco.com>> wrote:
> >
> >
> > =A0 =A0 The OPUS draft authors believe the bitstream for OPUS wil= l be ready
> > =A0 =A0 to be "frozen" by the end of the month. At that= point we plan to
> > =A0 =A0 spend the following month testing and, baring any surpris= es, will
> > =A0 =A0 likely go to WGLC after that.
> >
> > =A0 =A0 There has been some questions about what "frozen&quo= t; means in IETF
> > =A0 =A0 context. The bitstream could change any time up to when t= he IESG
> > =A0 =A0 approves it which is after Working Group Last call and af= ter IETF
> > =A0 =A0 Last Call so there is no guarantee that nothing will chan= ge but ...
> > =A0 =A0 =A0 by "frozen" we mean that we believe no chan= ges are needed and
> > =A0 =A0 don't plan to make changes unless some significant pr= oblem is found.
> >
> > =A0 =A0 Thanks,
> > =A0 =A0 Cullen, Jonathan, and Mike
> >
> >
> > =A0 =A0 _______________________________________________
> > =A0 =A0 codec mailing list
> > =A0 =A0 codec@ietf.org <= mailto:codec@ietf.org>
> > =A0 =A0 https://www.ietf.org/mailman/listinfo/codec
> >
> >
> >
> >
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://www.ietf.org/mailman/listinfo/codec
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec

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

--00221532cb384582af0499dbcda1-- From kpfleming@digium.com Sat Jan 15 05:10:06 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821433A6D43 for ; Sat, 15 Jan 2011 05:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIVdDzv4iefz for ; Sat, 15 Jan 2011 05:10:05 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 50A103A6D21 for ; Sat, 15 Jan 2011 05:10:05 -0800 (PST) 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 1Pe5vl-0000mw-16 for codec@ietf.org; Sat, 15 Jan 2011 07:12:33 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id EAC08D8193 for ; Sat, 15 Jan 2011 07:12:32 -0600 (CST) 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 yASF-02kRvXT for ; Sat, 15 Jan 2011 07:12:29 -0600 (CST) Received: from [192.168.1.6] (173-24-207-63.client.mchsi.com [173.24.207.63]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1BAADD8192 for ; Sat, 15 Jan 2011 07:12:29 -0600 (CST) Message-ID: <4D319D36.8010607@digium.com> Date: Sat, 15 Jan 2011 07:12:22 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: codec@ietf.org References: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Next Steps for WG 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, 15 Jan 2011 13:10:06 -0000 On 01/14/2011 11:27 PM, Roman Shpount wrote: > My question was not as much about the VAD, as about multiple stream > combining. What I want is to implement is switching between multiple > talker based on VAD (computation of which is done by some external > methods). In this case we need to indicate to the remote party that this > is a new stream and ideally get the remote decoder in such a state that > it can immediately start correctly decoding the new audio without a > glitch. So, the minimum requirement would be to have a flag or a packet > that indicates the decoder that it needs to reset its state. Ideally, we > need an algorithm to get the proper decoder state based on some audio > history stored on the conferencing server, and to send this decoder > state to the remote party so that it can be synchronized. I don't think > this should affect the codec performance. This is just something that > needs to be accommodated in the bitstream by adding a packet type which > either resets the decoder state or sets it to some specified value. This sort of mechanism already exists when using RTP as the transport mechanism, by setting the marker bit and changing the SSRC to indicate that the payload in the packet is from a different source than the previous packet. In my opinion there's no need for the codec bitstream to have any provisions for such an indication. -- 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 roman@telurix.com Sat Jan 15 14:05:10 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1233A6B46 for ; Sat, 15 Jan 2011 14:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGxllRXX7YvK for ; Sat, 15 Jan 2011 14:05:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 82CBE3A6B3A for ; Sat, 15 Jan 2011 14:05:03 -0800 (PST) Received: by iyi42 with SMTP id 42so3857520iyi.31 for ; Sat, 15 Jan 2011 14:07:32 -0800 (PST) Received: by 10.42.166.138 with SMTP id o10mr2542329icy.37.1295129251686; Sat, 15 Jan 2011 14:07:31 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id c4sm2088107ict.7.2011.01.15.14.07.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 14:07:30 -0800 (PST) Received: by iwn40 with SMTP id 40so3827277iwn.31 for ; Sat, 15 Jan 2011 14:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.37.70 with SMTP id w6mr2323007ibd.169.1295129248752; Sat, 15 Jan 2011 14:07:28 -0800 (PST) Received: by 10.231.20.139 with HTTP; Sat, 15 Jan 2011 14:07:28 -0800 (PST) In-Reply-To: <4D319D36.8010607@digium.com> References: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> <4D319D36.8010607@digium.com> Date: Sat, 15 Jan 2011 17:07:28 -0500 Message-ID: From: Roman Shpount To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=002215048dabcf65020499e9c684 Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 15 Jan 2011 22:05:10 -0000 --002215048dabcf65020499e9c684 Content-Type: text/plain; charset=ISO-8859-1 First of all, CODEC definition should be independent from the transport protocol, and we might need this functionality when RTP SSRC are not available. Furthermore, in case of RTP, there are two problems with your suggestion: 1. Quite a few clients do not allow remote party to change SSRC without the re-Invite. SIP clients note SSRC of the first received RTP packet and ignore RTP packets with different SSRC 2. Even when the client allows switching of SSRC on the fly, a few initial RTP packets are typically discarded due to RTP probation. After this, clients typically need to pre-fill the jitter buffer, and only after this start audio playback. This produces from 40ms to 100ms gap in audio. This is very audible and highly undesirable. Finally, what I was looking for was a bit more then just decoder reset. Ideally I wanted to set decoder state to a known value to start decoding audio packets that I will send to it. P.S. As a side note, Intel Performance Primitives CODECs implement a packet type in its wave file format that resets the decoder. This packet is used to simplify implementation of performance and regression tests. I think they are using standard sized packet with all bits set to zero for this purpose. We can at least do something similar. _____________ Roman Shpount On Sat, Jan 15, 2011 at 8:12 AM, Kevin P. Fleming wrote: > On 01/14/2011 11:27 PM, Roman Shpount wrote: > >> My question was not as much about the VAD, as about multiple stream >> combining. What I want is to implement is switching between multiple >> talker based on VAD (computation of which is done by some external >> methods). In this case we need to indicate to the remote party that this >> is a new stream and ideally get the remote decoder in such a state that >> it can immediately start correctly decoding the new audio without a >> glitch. So, the minimum requirement would be to have a flag or a packet >> that indicates the decoder that it needs to reset its state. Ideally, we >> need an algorithm to get the proper decoder state based on some audio >> history stored on the conferencing server, and to send this decoder >> state to the remote party so that it can be synchronized. I don't think >> this should affect the codec performance. This is just something that >> needs to be accommodated in the bitstream by adding a packet type which >> either resets the decoder state or sets it to some specified value. >> > > This sort of mechanism already exists when using RTP as the transport > mechanism, by setting the marker bit and changing the SSRC to indicate that > the payload in the packet is from a different source than the previous > packet. In my opinion there's no need for the codec bitstream to have any > provisions for such an indication. > > -- > 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 > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --002215048dabcf65020499e9c684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First of all, CODEC definition should be independent from the transport pro= tocol, and we might need this functionality when RTP SSRC are not available= .

Furthermore, in case of RTP, there are two problems with your sugg= estion:

1. Quite a few clients do not allow remote party to change SSRC without= the re-Invite. SIP clients note SSRC of the first received RTP packet and = ignore RTP packets with different SSRC

2. Even when the client allow= s switching of SSRC on the fly, a few initial RTP packets are typically dis= carded due to RTP probation. After this, clients typically need to pre-fill= the jitter buffer, and only after this start audio playback. This produces= from 40ms to 100ms gap in audio. This is very audible and highly undesirab= le.

Finally, what I was looking for was a bit more then just decoder reset.= Ideally I wanted to set decoder state to a known value to start decoding a= udio packets that I will send to it.

P.S. As a side note, Intel Perf= ormance Primitives CODECs implement a packet type in its wave file format t= hat resets the decoder. This packet is used to simplify implementation of p= erformance and regression tests. I think they are using standard sized pack= et with all bits set to zero for this purpose. We can at least do something= similar.

_____________
Roman Shpount


On Sat, Jan 15, 2011 at 8:12 AM, Kevin P= . Fleming <kpf= leming@digium.com> wrote:
On 01/14/2011 11:27 PM, Roman Shpount wrote:
My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple
talker based on VAD (computation of which is done by some external
methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that
it can immediately start correctly decoding the new audio without a
glitch. So, the minimum requirement would be to have a flag or a packet
that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio
history stored on the conferencing server, and to send this decoder
state to the remote party so that it can be synchronized. I don't think=
this should affect the codec performance. This is just something that
needs to be accommodated in the bitstream by adding a packet type which
either resets the decoder state or sets it to some specified value.

This sort of mechanism already exists when using RTP as the transport mecha= nism, by setting the marker bit and changing the SSRC to indicate that the = payload in the packet is from a different source than the previous packet. = In my opinion there's no need for the codec bitstream to have any provi= sions for such an indication.

--
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.dig= ium.com & www= .asterisk.org

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

--002215048dabcf65020499e9c684-- From csp@csperkins.org Sat Jan 15 14:33:37 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9C93A6B96 for ; Sat, 15 Jan 2011 14:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 6-VPmwj03Fhl for ; Sat, 15 Jan 2011 14:33:36 -0800 (PST) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 722E13A6B46 for ; Sat, 15 Jan 2011 14:33:35 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PeEj6-000613-XC; Sat, 15 Jan 2011 22:36:04 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-379--1003818200 From: Colin Perkins In-Reply-To: Date: Sat, 15 Jan 2011 22:36:01 +0000 Message-Id: <0C039039-9A96-4978-A648-7BE756E2E02B@csperkins.org> References: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de> <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra> <4D319D36.8010607@digium.com> To: Roman Shpount X-Mailer: Apple Mail (2.1082) Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 15 Jan 2011 22:33:37 -0000 --Apple-Mail-379--1003818200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Jan 2011, at 22:07, Roman Shpount wrote: > First of all, CODEC definition should be independent from the = transport protocol, and we might need this functionality when RTP SSRC = are not available. >=20 > Furthermore, in case of RTP, there are two problems with your = suggestion: >=20 > 1. Quite a few clients do not allow remote party to change SSRC = without the re-Invite. SIP clients note SSRC of the first received RTP = packet and ignore RTP packets with different SSRC If they do, then they're broken. RFC 3550 is very clear that the RTP = SSRC can change at any time, due to SSRC collisions, changes in the = transport address of the source, or source restarts. > 2. Even when the client allows switching of SSRC on the fly, a few = initial RTP packets are typically discarded due to RTP probation. After = this, clients typically need to pre-fill the jitter buffer, and only = after this start audio playback. This produces from 40ms to 100ms gap in = audio. This is very audible and highly undesirable. The two initial packets needed to establish an RTP stream as valid don't = have to be discarded. They can be used to pre-fill the jitter buffer, = and decoded once the stream is established as being valid. Only if the = jitter buffer is smaller than two packets (the MIN_SEQUENTIAL parameter = used to establish a source as valid) should a gap in the playout occur = due to an SSRC change, and even then that gap should be possible to = conceal.=20 Colin > Finally, what I was looking for was a bit more then just decoder = reset. Ideally I wanted to set decoder state to a known value to start = decoding audio packets that I will send to it. >=20 > P.S. As a side note, Intel Performance Primitives CODECs implement a = packet type in its wave file format that resets the decoder. This packet = is used to simplify implementation of performance and regression tests. = I think they are using standard sized packet with all bits set to zero = for this purpose. We can at least do something similar. >=20 > _____________ > Roman Shpount >=20 >=20 > On Sat, Jan 15, 2011 at 8:12 AM, Kevin P. Fleming = wrote: > On 01/14/2011 11:27 PM, Roman Shpount wrote: > My question was not as much about the VAD, as about multiple stream > combining. What I want is to implement is switching between multiple > talker based on VAD (computation of which is done by some external > methods). In this case we need to indicate to the remote party that = this > is a new stream and ideally get the remote decoder in such a state = that > it can immediately start correctly decoding the new audio without a > glitch. So, the minimum requirement would be to have a flag or a = packet > that indicates the decoder that it needs to reset its state. Ideally, = we > need an algorithm to get the proper decoder state based on some audio > history stored on the conferencing server, and to send this decoder > state to the remote party so that it can be synchronized. I don't = think > this should affect the codec performance. This is just something that > needs to be accommodated in the bitstream by adding a packet type = which > either resets the decoder state or sets it to some specified value. >=20 > This sort of mechanism already exists when using RTP as the transport = mechanism, by setting the marker bit and changing the SSRC to indicate = that the payload in the packet is from a different source than the = previous packet. In my opinion there's no need for the codec bitstream = to have any provisions for such an indication. >=20 > --=20 > 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 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-379--1003818200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii First of all, CODEC definition = should be independent from the transport protocol, and we might need = this functionality when RTP SSRC are not available.

Furthermore, = in case of RTP, there are two problems with your suggestion:

1. Quite a few clients do not allow remote party to change SSRC = without the re-Invite. SIP clients note SSRC of the first received RTP = packet and ignore RTP packets with different = SSRC

If they do, then they're = broken. RFC 3550 is very clear that the RTP SSRC can change at any time, = due to SSRC collisions, changes in the transport address of the source, = or source restarts.

2. Even when the = client allows switching of SSRC on the fly, a few initial RTP packets = are typically discarded due to RTP probation. After this, clients = typically need to pre-fill the jitter buffer, and only after this start = audio playback. This produces from 40ms to 100ms gap in audio. This is = very audible and highly = undesirable.

The two initial packets = needed to establish an RTP stream as valid don't have to be discarded. = They can be used to pre-fill the jitter buffer, and decoded once the = stream is established as being valid. Only if the jitter buffer is = smaller than two packets (the MIN_SEQUENTIAL parameter used to establish = a source as valid) should a gap in the playout occur due to an SSRC = change, and even then that gap should be possible to = conceal. 

Colin



Finally, what I was = looking for was a bit more then just decoder reset. Ideally I wanted to = set decoder state to a known value to start decoding audio packets that = I will send to it.

P.S. As a side note, Intel Performance = Primitives CODECs implement a packet type in its wave file format that = resets the decoder. This packet is used to simplify implementation of = performance and regression tests. I think they are using standard sized = packet with all bits set to zero for this purpose. We can at least do = something similar.

_____________
Roman Shpount


On Sat, Jan 15, 2011 at 8:12 AM, = Kevin P. Fleming <kpfleming@digium.com> = wrote:
On 01/14/2011 11:27 PM, Roman Shpount wrote:
My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple
talker based on VAD (computation of which is done by some external
methods). In this case we need to indicate to the remote party that = this
is a new stream and ideally get the remote decoder in such a state = that
it can immediately start correctly decoding the new audio without a
glitch. So, the minimum requirement would be to have a flag or a = packet
that indicates the decoder that it needs to reset its state. Ideally, = we
need an algorithm to get the proper decoder state based on some = audio
history stored on the conferencing server, and to send this decoder
state to the remote party so that it can be synchronized. I don't = think
this should affect the codec performance. This is just something = that
needs to be accommodated in the bitstream by adding a packet type = which
either resets the decoder state or sets it to some specified value.

This sort of mechanism already exists when using RTP as the transport = mechanism, by setting the marker bit and changing the SSRC to indicate = that the payload in the packet is from a different source than the = previous packet. In my opinion there's no need for the codec bitstream = to have any provisions for such an indication.

--
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

_______________________________________________
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



-- 
Colin Perkins



= --Apple-Mail-379--1003818200-- From koen.vos@skype.net Tue Jan 18 14:32:48 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5938028C0FA for ; Tue, 18 Jan 2011 14:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 JDRQQbrIbaDT for ; Tue, 18 Jan 2011 14:32:46 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id D18633A7021 for ; Tue, 18 Jan 2011 14:32:45 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id ED4B2170C; Tue, 18 Jan 2011 23:35:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type; s= mx; bh=bJSvSoq6vrUbM5n+MFCZJcYsbuQ=; b=dc0NG7x4VRGzDzDt5n8Fdwj4K U/d/+QEFK5RWFlmU3/zZUkMhiwK1+di3fjMjGC1eUKwc1nnSaA6cNrLYuV1BAwNc 5mhRm3UeMp6+D4CBZ1TWlA6eQH+rRr0CoW/BzVxJbK1D960+hPZtQaY1PEaVZVn0 bsNTr62MlDKDObFHdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type; q=dns ; s=mx; b=dfa74D94/27wmG6w3ZYwuUGdyRPbgncMQuMkqIcGw4q5IHD7MKjvf2 5OQdeS5urj0FwxSbkY4zuHWpQF8c+VoWMAGqE4HVihlryDL1nAXyEVLi86rvP8OT L8lALhgyFFoiy29rybnn9u6OnjNI/0Tw9+DSBeMvbr7K/iRbp2pqI= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id EBA6D7FD; Tue, 18 Jan 2011 23:35:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CCF933507D1E; Tue, 18 Jan 2011 23:35:22 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+iCOiE2JVAu; Tue, 18 Jan 2011 23:35:20 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 8AF22350703C; Tue, 18 Jan 2011 23:35:20 +0100 (CET) Date: Tue, 18 Jan 2011 23:35:20 +0100 (CET) From: Koen Vos To: Roman Shpount Message-ID: <148861739.1112857.1295390120406.JavaMail.root@lu2-zimbra> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1112856_1656715763.1295390120404" X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 18 Jan 2011 22:32:48 -0000 ------=_Part_1112856_1656715763.1295390120404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Roman: Jean-Marc and I discussed this a bit, and this is how we see it: Resetting the decoder state would lead to a discontinuity in the output signal and may create an objectionable "click" sound. Moreover, the incoming stream that's enabled in the switching node at the moment of the decoder reset may depend on the last frame before the switch. So the first few frames would not be decoded correctly. Coding and transmitting the decoder state doesn't overcome the discontinuity problem. And it would add a lot of complications and code to Opus. A better method seems to be: 1. Determine if the first frame after switching has significant dependencies on the previous frame (i.e., long-term prediction in the case of SILK, or energy prediction in the case of CELT) 2a: If yes: decode the first frame and re-encode it independently. After that, switch to the new stream. 2b. If no: simply switch to the new stream immediately. This ensures a smooth transition and fast convergence to the correct output signal for the new stream. best, koen. ----- Original Message ----- From: "Roman Shpount" To: "Kevin P. Fleming" Cc: codec@ietf.org Sent: Saturday, January 15, 2011 2:07:28 PM Subject: Re: [codec] Next Steps for WG First of all, CODEC definition should be independent from the transport protocol, and we might need this functionality when RTP SSRC are not available. Furthermore, in case of RTP, there are two problems with your suggestion: 1. Quite a few clients do not allow remote party to change SSRC without the re-Invite. SIP clients note SSRC of the first received RTP packet and ignore RTP packets with different SSRC 2. Even when the client allows switching of SSRC on the fly, a few initial RTP packets are typically discarded due to RTP probation. After this, clients typically need to pre-fill the jitter buffer, and only after this start audio playback. This produces from 40ms to 100ms gap in audio. This is very audible and highly undesirable. Finally, what I was looking for was a bit more then just decoder reset. Ideally I wanted to set decoder state to a known value to start decoding audio packets that I will send to it. P.S. As a side note, Intel Performance Primitives CODECs implement a packet type in its wave file format that resets the decoder. This packet is used to simplify implementation of performance and regression tests. I think they are using standard sized packet with all bits set to zero for this purpose. We can at least do something similar. _____________ Roman Shpount On Sat, Jan 15, 2011 at 8:12 AM, Kevin P. Fleming < kpfleming@digium.com > wrote: On 01/14/2011 11:27 PM, Roman Shpount wrote: My question was not as much about the VAD, as about multiple stream combining. What I want is to implement is switching between multiple talker based on VAD (computation of which is done by some external methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that it can immediately start correctly decoding the new audio without a glitch. So, the minimum requirement would be to have a flag or a packet that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio history stored on the conferencing server, and to send this decoder state to the remote party so that it can be synchronized. I don't think this should affect the codec performance. This is just something that needs to be accommodated in the bitstream by adding a packet type which either resets the decoder state or sets it to some specified value. This sort of mechanism already exists when using RTP as the transport mechanism, by setting the marker bit and changing the SSRC to indicate that the payload in the packet is from a different source than the previous packet. In my opinion there's no need for the codec bitstream to have any provisions for such an indication. -- 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 _______________________________________________ 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 ------=_Part_1112856_1656715763.1295390120404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >Roman:

Jean-Marc and I discussed this a bit, and this is how we see= it:

Resetting the decoder state would lead to a discontinuity in th= e output signal and may create an objectionable "click" sound.  Moreov= er, the incoming stream that's enabled in the switching node at the moment = of the decoder reset may depend on the last frame before the switch. So the= first few frames would not be decoded correctly.

Coding and transmi= tting the decoder state doesn't overcome the discontinuity problem.  A= nd it would add a lot of complications and code to Opus. 

A be= tter method seems to be:
1. Determine if the first frame after switching= has significant dependencies on the previous frame (i.e., long-term predic= tion in the case of SILK, or energy prediction in the case of CELT)
2a: = If yes: decode the first frame and re-encode it independently.  After = that, switch to the new stream.
2b. If no: simply switch to the new stream immediately.
This ensures a s= mooth transition and fast convergence to the correct output signal for the = new stream.

best,
koen.


From: = "Roman Shpount" <roman@telurix.com>
To: "Kevin P. Fleming" = <kpfleming@digium.com>
Cc: codec@ietf.org
Sent: S= aturday, January 15, 2011 2:07:28 PM
Subject: Re: [codec] Next St= eps for WG

First of all, CODEC definition should be independent from= the transport protocol, and we might need this functionality when RTP SSRC= are not available.

Furthermore, in case of RTP, there are two probl= ems with your suggestion:

1. Quite a few clients do not allow remote party to change SSRC without= the re-Invite. SIP clients note SSRC of the first received RTP packet and = ignore RTP packets with different SSRC

2. Even when the client allow= s switching of SSRC on the fly, a few initial RTP packets are typically dis= carded due to RTP probation. After this, clients typically need to pre-fill= the jitter buffer, and only after this start audio playback. This produces= from 40ms to 100ms gap in audio. This is very audible and highly undesirab= le.

Finally, what I was looking for was a bit more then just decoder reset.= Ideally I wanted to set decoder state to a known value to start decoding a= udio packets that I will send to it.

P.S. As a side note, Intel Perf= ormance Primitives CODECs implement a packet type in its wave file format t= hat resets the decoder. This packet is used to simplify implementation of p= erformance and regression tests. I think they are using standard sized pack= et with all bits set to zero for this purpose. We can at least do something= similar.

_____________
Roman Shpount


On Sat, Jan 15, 2011 at 8:12 AM, Kevin P= . Fleming <kpfleming@digium.com> wrote:
On 01/14/2011 11:27 PM, Roman Shpount wrote:
My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple
talker based on VAD (computation of which is done by some external
methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that
it can immediately start correctly decoding the new audio without a
glitch. So, the minimum requirement would be to have a flag or a packet
that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio
history stored on the conferencing server, and to send this decoder
state to the remote party so that it can be synchronized. I don't think
this should affect the codec performance. This is just something that
needs to be accommodated in the bitstream by adding a packet type which
either resets the decoder state or sets it to some specified value.

This sort of mechanism already exists when using RTP as the transport mecha= nism, by setting the marker bit and changing the SSRC to indicate that the = payload in the packet is from a different source than the previous packet. = In my opinion there's no need for the codec bitstream to have any provision= s for such an indication.

--
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.dig= ium.com & www= .asterisk.org

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


_______________________________________________
codec mailing listcodec@ietf.org
https://www.ietf.org/mailman/listinfo/codec
------=_Part_1112856_1656715763.1295390120404-- From roman@telurix.com Tue Jan 18 14:52:37 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF1828C0FA for ; Tue, 18 Jan 2011 14:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPWXxr-zJwhd for ; Tue, 18 Jan 2011 14:52:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6824728C0D7 for ; Tue, 18 Jan 2011 14:52:34 -0800 (PST) Received: by iyi42 with SMTP id 42so158074iyi.31 for ; Tue, 18 Jan 2011 14:55:12 -0800 (PST) Received: by 10.42.169.4 with SMTP id z4mr7141498icy.71.1295391312258; Tue, 18 Jan 2011 14:55:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id u5sm4800045ics.6.2011.01.18.14.55.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 14:55:11 -0800 (PST) Received: by iyi42 with SMTP id 42so158046iyi.31 for ; Tue, 18 Jan 2011 14:55:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.16.68 with SMTP id n4mr6865805iba.94.1295391309907; Tue, 18 Jan 2011 14:55:09 -0800 (PST) Received: by 10.231.20.139 with HTTP; Tue, 18 Jan 2011 14:55:09 -0800 (PST) In-Reply-To: <148861739.1112857.1295390120406.JavaMail.root@lu2-zimbra> References: <148861739.1112857.1295390120406.JavaMail.root@lu2-zimbra> Date: Tue, 18 Jan 2011 17:55:09 -0500 Message-ID: From: Roman Shpount To: Koen Vos Content-Type: multipart/alternative; boundary=00221532c58cdf480e049a26cabe Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 18 Jan 2011 22:52:37 -0000 --00221532c58cdf480e049a26cabe Content-Type: text/plain; charset=ISO-8859-1 Thank you, this is very helpful. What I was considering was something similar: Typically you have one speaker in the conference with short periods of double talk. I was thinking that decoding, mixing and encoding using independent frames the double talk period with the few initial frames of the new speaker, and then switching to a new speaker stream would sound the most natural and will only require re-encoding for short periods of time. Thank you for your great work, _____________________________ Roman Shpount - www.telurix.com On Tue, Jan 18, 2011 at 5:35 PM, Koen Vos wrote: > Roman: > > Jean-Marc and I discussed this a bit, and this is how we see it: > > Resetting the decoder state would lead to a discontinuity in the output > signal and may create an objectionable "click" sound. Moreover, the > incoming stream that's enabled in the switching node at the moment of the > decoder reset may depend on the last frame before the switch. So the first > few frames would not be decoded correctly. > > Coding and transmitting the decoder state doesn't overcome the > discontinuity problem. And it would add a lot of complications and code to > Opus. > > A better method seems to be: > 1. Determine if the first frame after switching has significant > dependencies on the previous frame (i.e., long-term prediction in the case > of SILK, or energy prediction in the case of CELT) > 2a: If yes: decode the first frame and re-encode it independently. After > that, switch to the new stream. > 2b. If no: simply switch to the new stream immediately. > This ensures a smooth transition and fast convergence to the correct output > signal for the new stream. > > best, > koen. > > > ------------------------------ > *From: *"Roman Shpount" > *To: *"Kevin P. Fleming" > *Cc: *codec@ietf.org > *Sent: *Saturday, January 15, 2011 2:07:28 PM > > *Subject: *Re: [codec] Next Steps for WG > > First of all, CODEC definition should be independent from the transport > protocol, and we might need this functionality when RTP SSRC are not > available. > > Furthermore, in case of RTP, there are two problems with your suggestion: > > 1. Quite a few clients do not allow remote party to change SSRC without the > re-Invite. SIP clients note SSRC of the first received RTP packet and ignore > RTP packets with different SSRC > > 2. Even when the client allows switching of SSRC on the fly, a few initial > RTP packets are typically discarded due to RTP probation. After this, > clients typically need to pre-fill the jitter buffer, and only after this > start audio playback. This produces from 40ms to 100ms gap in audio. This is > very audible and highly undesirable. > > Finally, what I was looking for was a bit more then just decoder reset. > Ideally I wanted to set decoder state to a known value to start decoding > audio packets that I will send to it. > > P.S. As a side note, Intel Performance Primitives CODECs implement a packet > type in its wave file format that resets the decoder. This packet is used to > simplify implementation of performance and regression tests. I think they > are using standard sized packet with all bits set to zero for this purpose. > We can at least do something similar. > > _____________ > Roman Shpount > > > On Sat, Jan 15, 2011 at 8:12 AM, Kevin P. Fleming wrote: > >> On 01/14/2011 11:27 PM, Roman Shpount wrote: >> >>> My question was not as much about the VAD, as about multiple stream >>> combining. What I want is to implement is switching between multiple >>> talker based on VAD (computation of which is done by some external >>> methods). In this case we need to indicate to the remote party that this >>> is a new stream and ideally get the remote decoder in such a state that >>> it can immediately start correctly decoding the new audio without a >>> glitch. So, the minimum requirement would be to have a flag or a packet >>> that indicates the decoder that it needs to reset its state. Ideally, we >>> need an algorithm to get the proper decoder state based on some audio >>> history stored on the conferencing server, and to send this decoder >>> state to the remote party so that it can be synchronized. I don't think >>> this should affect the codec performance. This is just something that >>> needs to be accommodated in the bitstream by adding a packet type which >>> either resets the decoder state or sets it to some specified value. >>> >> >> This sort of mechanism already exists when using RTP as the transport >> mechanism, by setting the marker bit and changing the SSRC to indicate that >> the payload in the packet is from a different source than the previous >> packet. In my opinion there's no need for the codec bitstream to have any >> provisions for such an indication. >> >> -- >> 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 >> >> _______________________________________________ >> 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 > --00221532c58cdf480e049a26cabe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you, this is very helpful.

What I was considering was somethi= ng similar: Typically you have one speaker in the conference with short per= iods of double talk. I was thinking that decoding, mixing and encoding usin= g independent frames the double talk period with the few initial frames of = the new speaker, and then switching to a new speaker stream would sound the= most natural and will only require re-encoding for short periods of time.<= br>
Thank you for your great work,
_______________________= ______
Roman Shpount - www.telurix.co= m


On Tue, Jan 18, 2011 at 5:35 PM, Koen Vo= s <koen.vos@skyp= e.net> wrote:
Roman:

Jean-Marc and I discussed this a bit, and this i= s how we see it:

Resetting the decoder state would lead to a discont= inuity in the output signal and may create an objectionable "click&quo= t; sound.=A0 Moreover, the incoming stream that's enabled in the switch= ing node at the moment of the decoder reset may depend on the last frame be= fore the switch. So the first few frames would not be decoded correctly.
Coding and transmitting the decoder state doesn't overcome the disc= ontinuity problem.=A0 And it would add a lot of complications and code to O= pus.=A0

A better method seems to be:
1. Determine if the first f= rame after switching has significant dependencies on the previous frame (i.= e., long-term prediction in the case of SILK, or energy prediction in the c= ase of CELT)
2a: If yes: decode the first frame and re-encode it independently.=A0 After= that, switch to the new stream.
2b. If no: simply switch to the new stream immediately.
This ensures a s= mooth transition and fast convergence to the correct output signal for the = new stream.

best,
koen.


From: "Roman S= hpount" <rom= an@telurix.com>
To: "Kevin P. Fleming" <kpfleming@digium.com>
Cc: codec@ietf.org
Sen= t: Saturday, January 15, 2011 2:07:28 PM

Subject: Re: [codec] Next Steps for WG

First of all, CODEC definition should be independent = from the transport protocol, and we might need this functionality when RTP = SSRC are not available.

Furthermore, in case of RTP, there are two problems with your suggestio= n:

1. Quite a few clients do not allow remote party to change SSRC without= the re-Invite. SIP clients note SSRC of the first received RTP packet and = ignore RTP packets with different SSRC

2. Even when the client allow= s switching of SSRC on the fly, a few initial RTP packets are typically dis= carded due to RTP probation. After this, clients typically need to pre-fill= the jitter buffer, and only after this start audio playback. This produces= from 40ms to 100ms gap in audio. This is very audible and highly undesirab= le.

Finally, what I was looking for was a bit more then just decoder reset.= Ideally I wanted to set decoder state to a known value to start decoding a= udio packets that I will send to it.

P.S. As a side note, Intel Perf= ormance Primitives CODECs implement a packet type in its wave file format t= hat resets the decoder. This packet is used to simplify implementation of p= erformance and regression tests. I think they are using standard sized pack= et with all bits set to zero for this purpose. We can at least do something= similar.

_____________
Roman Shpount


On Sat, Jan 15, 2011 at 8:12 AM, Kevin P= . Fleming <kpfleming@digium.com> wrote:
On 01/14/2011 11:27 PM, Roman Shpount wrote:
My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple
talker based on VAD (computation of which is done by some external
methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that
it can immediately start correctly decoding the new audio without a
glitch. So, the minimum requirement would be to have a flag or a packet
that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio
history stored on the conferencing server, and to send this decoder
state to the remote party so that it can be synchronized. I don't think=
this should affect the codec performance. This is just something that
needs to be accommodated in the bitstream by adding a packet type which
either resets the decoder state or sets it to some specified value.

This sort of mechanism already exists when using RTP as the transport mecha= nism, by setting the marker bit and changing the SSRC to indicate that the = payload in the packet is from a different source than the previous packet. = In my opinion there's no need for the codec bitstream to have any provi= sions for such an indication.

--
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.dig= ium.com & www= .asterisk.org

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


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

--00221532c58cdf480e049a26cabe-- From koen.vos@skype.net Tue Jan 18 15:11:22 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE79928C13C for ; Tue, 18 Jan 2011 15:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 jpg0WJctL+hj for ; Tue, 18 Jan 2011 15:11:15 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 15EFA3A6F64 for ; Tue, 18 Jan 2011 15:11:15 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C88A3170C; Wed, 19 Jan 2011 00:13:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type; s= mx; bh=SEiin+RfHkqLer1bY7rMQI48muw=; b=EvPwAYymhUYUHs/YQ41o2wUkg HUitlcJrCi+aJ4rQ7q3JsuWjiBWFRiO+pbUcIcZkou/3Pf7Z5Fu7m9/+OZif+zc8 mjSyVwzEFCkI2O9QJXUcHmKf3Rs30PeB/QLoHlCt5kGWWceXA2ZRgyBC5uipViyV 772psIJgMQJesbowy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type; q=dns ; s=mx; b=rzlNTx5HyyVPl30I/LKpFikEvCi4OohD+5KxubCfNLvNj2Gs0LUmcs r9CCO9wIEJU5icrqS2rX9K/UenniO8wEsgO18VZ633u1kMtqn1h9NMq9aXKIjJiU DI88H1BcWoP7cLY0kt3nMfAFBpp6tMYrD7jU4EHusS3il7Vi4zEuw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C3F3E16FC; Wed, 19 Jan 2011 00:13:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 96BF13507DB1; Wed, 19 Jan 2011 00:13:52 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6807sHO4ndq; Wed, 19 Jan 2011 00:13:50 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id DFA5C3507DA4; Wed, 19 Jan 2011 00:13:50 +0100 (CET) Date: Wed, 19 Jan 2011 00:13:50 +0100 (CET) From: Koen Vos To: Roman Shpount Message-ID: <785740794.1113907.1295392430782.JavaMail.root@lu2-zimbra> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1113906_217516684.1295392430780" X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org Subject: Re: [codec] Next Steps for WG 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, 18 Jan 2011 23:11:23 -0000 ------=_Part_1113906_217516684.1295392430780 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit That should work. Make sure to get the time alignment right by adjusting for look-ahead etc. And only the first frame of the double talk period has to be coded independently; for the others you could let the encoder decide. In general, whenever you're adding or removing a stream from the mix you want an independent frame. best, koen. ----- Original Message ----- From: "Roman Shpount" To: "Koen Vos" Cc: codec@ietf.org Sent: Tuesday, January 18, 2011 2:55:09 PM Subject: Re: [codec] Next Steps for WG Thank you, this is very helpful. What I was considering was something similar: Typically you have one speaker in the conference with short periods of double talk. I was thinking that decoding, mixing and encoding using independent frames the double talk period with the few initial frames of the new speaker, and then switching to a new speaker stream would sound the most natural and will only require re-encoding for short periods of time. Thank you for your great work, _____________________________ Roman Shpount - www.telurix.com On Tue, Jan 18, 2011 at 5:35 PM, Koen Vos < koen.vos@skype.net > wrote: Roman: Jean-Marc and I discussed this a bit, and this is how we see it: Resetting the decoder state would lead to a discontinuity in the output signal and may create an objectionable "click" sound. Moreover, the incoming stream that's enabled in the switching node at the moment of the decoder reset may depend on the last frame before the switch. So the first few frames would not be decoded correctly. Coding and transmitting the decoder state doesn't overcome the discontinuity problem. And it would add a lot of complications and code to Opus. A better method seems to be: 1. Determine if the first frame after switching has significant dependencies on the previous frame (i.e., long-term prediction in the case of SILK, or energy prediction in the case of CELT) 2a: If yes: decode the first frame and re-encode it independently. After that, switch to the new stream. 2b. If no: simply switch to the new stream immediately. This ensures a smooth transition and fast convergence to the correct output signal for the new stream. best, koen. From: "Roman Shpount" < roman@telurix.com > To: "Kevin P. Fleming" < kpfleming@digium.com > Cc: codec@ietf.org Sent: Saturday, January 15, 2011 2:07:28 PM Subject: Re: [codec] Next Steps for WG First of all, CODEC definition should be independent from the transport protocol, and we might need this functionality when RTP SSRC are not available. Furthermore, in case of RTP, there are two problems with your suggestion: 1. Quite a few clients do not allow remote party to change SSRC without the re-Invite. SIP clients note SSRC of the first received RTP packet and ignore RTP packets with different SSRC 2. Even when the client allows switching of SSRC on the fly, a few initial RTP packets are typically discarded due to RTP probation. After this, clients typically need to pre-fill the jitter buffer, and only after this start audio playback. This produces from 40ms to 100ms gap in audio. This is very audible and highly undesirable. Finally, what I was looking for was a bit more then just decoder reset. Ideally I wanted to set decoder state to a known value to start decoding audio packets that I will send to it. P.S. As a side note, Intel Performance Primitives CODECs implement a packet type in its wave file format that resets the decoder. This packet is used to simplify implementation of performance and regression tests. I think they are using standard sized packet with all bits set to zero for this purpose. We can at least do something similar. _____________ Roman Shpount On Sat, Jan 15, 2011 at 8:12 AM, Kevin P. Fleming < kpfleming@digium.com > wrote: On 01/14/2011 11:27 PM, Roman Shpount wrote: My question was not as much about the VAD, as about multiple stream combining. What I want is to implement is switching between multiple talker based on VAD (computation of which is done by some external methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that it can immediately start correctly decoding the new audio without a glitch. So, the minimum requirement would be to have a flag or a packet that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio history stored on the conferencing server, and to send this decoder state to the remote party so that it can be synchronized. I don't think this should affect the codec performance. This is just something that needs to be accommodated in the bitstream by adding a packet type which either resets the decoder state or sets it to some specified value. This sort of mechanism already exists when using RTP as the transport mechanism, by setting the marker bit and changing the SSRC to indicate that the payload in the packet is from a different source than the previous packet. In my opinion there's no need for the codec bitstream to have any provisions for such an indication. -- 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 _______________________________________________ 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 ------=_Part_1113906_217516684.1295392430780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >That should work. 
Make sure to get the time alignment right by a= djusting for look-ahead etc. 
And only the first frame of the doub= le talk period has to be coded independently; for the others you could let = the encoder decide.  In general, whenever you're adding or removing a = stream from the mix you want an independent frame.

best,
koen.

From: "Roman Shpount" <roman@telurix.co= m>
To: "Koen Vos" <koen.vos@skype.net>
Cc: cod= ec@ietf.org
Sent: Tuesday, January 18, 2011 2:55:09 PM
Subj= ect: Re: [codec] Next Steps for WG

Thank you, this is very helpf= ul.

What I was considering was something similar: Typically you hav= e one speaker in the conference with short periods of double talk. I was th= inking that decoding, mixing and encoding using independent frames the doub= le talk period with the few initial frames of the new speaker, and then swi= tching to a new speaker stream would sound the most natural and will only r= equire re-encoding for short periods of time.

Thank you for your great work,
_______________________= ______
Roman Shpount - www.telurix.com


On Tue, Jan 18, 2011 at 5:35 PM, Koen Vo= s <koen.vos@skype.net> wrote:
Roman:

Jean-Marc and I discussed this a bit, and this i= s how we see it:

Resetting the decoder state would lead to a discont= inuity in the output signal and may create an objectionable "click" sound.&= nbsp; Moreover, the incoming stream that's enabled in the switching node at= the moment of the decoder reset may depend on the last frame before the sw= itch. So the first few frames would not be decoded correctly.

Coding and transmitting the decoder state doesn't overcome the disconti= nuity problem.  And it would add a lot of complications and code to Op= us. 

A better method seems to be:
1. Determine if the first= frame after switching has significant dependencies on the previous frame (= i.e., long-term prediction in the case of SILK, or energy prediction in the= case of CELT)
2a: If yes: decode the first frame and re-encode it independently.  Af= ter that, switch to the new stream.
2b. If no: simply switch to the new stream immediately.
This ensures a s= mooth transition and fast convergence to the correct output signal for the = new stream.

best,
koen.


From: "Roman Shpoun= t" <roman@telurix= .com>
To: "Kevin P. Fleming" <kpfleming@digium.com>
Cc: codec@ietf.org
Sent: Sat= urday, January 15, 2011 2:07:28 PM

Subject: Re: [codec] Next Steps for WG

First of all, CODEC definition should be independent = from the transport protocol, and we might need this functionality when RTP = SSRC are not available.

Furthermore, in case of RTP, there are two problems with your suggestio= n:

1. Quite a few clients do not allow remote party to change SSRC without= the re-Invite. SIP clients note SSRC of the first received RTP packet and = ignore RTP packets with different SSRC

2. Even when the client allow= s switching of SSRC on the fly, a few initial RTP packets are typically dis= carded due to RTP probation. After this, clients typically need to pre-fill= the jitter buffer, and only after this start audio playback. This produces= from 40ms to 100ms gap in audio. This is very audible and highly undesirab= le.

Finally, what I was looking for was a bit more then just decoder reset.= Ideally I wanted to set decoder state to a known value to start decoding a= udio packets that I will send to it.

P.S. As a side note, Intel Perf= ormance Primitives CODECs implement a packet type in its wave file format t= hat resets the decoder. This packet is used to simplify implementation of p= erformance and regression tests. I think they are using standard sized pack= et with all bits set to zero for this purpose. We can at least do something= similar.

_____________
Roman Shpount


On Sat, Jan 15, 2011 at 8:12 AM, Kevin P= . Fleming <kpfleming@digium.com> wrote:
On 01/14/2011 11:27 PM, Roman Shpount wrote:
My question was not as much about the VAD, as about multiple stream
combining. What I want is to implement is switching between multiple
talker based on VAD (computation of which is done by some external
methods). In this case we need to indicate to the remote party that this is a new stream and ideally get the remote decoder in such a state that
it can immediately start correctly decoding the new audio without a
glitch. So, the minimum requirement would be to have a flag or a packet
that indicates the decoder that it needs to reset its state. Ideally, we need an algorithm to get the proper decoder state based on some audio
history stored on the conferencing server, and to send this decoder
state to the remote party so that it can be synchronized. I don't think
this should affect the codec performance. This is just something that
needs to be accommodated in the bitstream by adding a packet type which
either resets the decoder state or sets it to some specified value.

This sort of mechanism already exists when using RTP as the transport mecha= nism, by setting the marker bit and changing the SSRC to indicate that the = payload in the packet is from a different source than the previous packet. = In my opinion there's no need for the codec bitstream to have any provision= s for such an indication.

--
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.dig= ium.com & www= .asterisk.org

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


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

------=_Part_1113906_217516684.1295392430780-- From Internet-Drafts@ietf.org Fri Jan 21 19:30:03 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7995D3A68AB; Fri, 21 Jan 2011 19:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 Lo-xkREDoyy7; Fri, 21 Jan 2011 19:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D2D3A681F; Fri, 21 Jan 2011 19:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110122033002.26861.48760.idtracker@localhost> Date: Fri, 21 Jan 2011 19:30:02 -0800 Cc: codec@ietf.org Subject: [codec] I-D Action:draft-ietf-codec-guidelines-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: Sat, 22 Jan 2011 03:30:03 -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 : Guidelines for the Codec Development Within the IETF Author(s) : J. Valin, et al. Filename : draft-ietf-codec-guidelines-00.txt Pages : 19 Date : 2011-01-21 This document provides general guidelines for work on developing and specifying a codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-guidelines-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-guidelines-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-21192944.I-D@ietf.org> --NextPart-- From jdrosen@jdrosen.net Sat Jan 22 05:06:14 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716BE3A6922 for ; Sat, 22 Jan 2011 05:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 7GY4WEeBa+C6 for ; Sat, 22 Jan 2011 05:06:13 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.118]) by core3.amsl.com (Postfix) with ESMTP id 5DD773A6921 for ; Sat, 22 Jan 2011 05:06:13 -0800 (PST) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.15]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PgdDC-0002fI-3e for codec@ietf.org; Sat, 22 Jan 2011 08:09:02 -0500 Message-ID: <4D3AD6EA.5020607@jdrosen.net> Date: Sat, 22 Jan 2011 08:08:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 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] 3 week WGLC on draft-ietf-codec-requirements-02 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, 22 Jan 2011 13:06:14 -0000 The authors believe that the requirements document is complete. The chairs would like to now issue a 3 week working group last call for draft-ietf-codec-requirements-02. At the end of 3 weeks, if no comments have been received, we will pass the document to the IESG for approval. 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 hoene@uni-tuebingen.de Sun Jan 23 00:17:05 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE2A3A6359 for ; Sun, 23 Jan 2011 00:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnzV97iHkMaV for ; Sun, 23 Jan 2011 00:17:04 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id F21393A6405 for ; Sun, 23 Jan 2011 00:17:03 -0800 (PST) Received: from hoeneT60 (tmo-051-96.customers.d1-online.com [80.187.51.96]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p0N8Jcpe025790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Jan 2011 09:19:48 +0100 From: "Christian Hoene" To: "'Jonathan Rosenberg'" , References: <4D3AD6EA.5020607@jdrosen.net> In-Reply-To: <4D3AD6EA.5020607@jdrosen.net> Date: Sun, 23 Jan 2011 09:19:27 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWDjsml9J24OP+D1jOWj/YeoWjlpNJjKjg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx05) Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Sun, 23 Jan 2011 08:17:05 -0000 > The authors believe that the requirements document is complete. [Christian Hoene] Which authors? So far this document has only two selected editors. >The chairs > would like to now issue a 3 week working group last call for draft-ietf-codec- > requirements-02. At the end of 3 weeks, if no comments have been > received, we will pass the document to the IESG for approval. [Christian Hoene] Despite hundreds of emails, what were exchanged on this mailing list on issues regarding requirements, the editors have been reluctant to update the requirements document according to the consensus process on this mailing list. If I compare draft-ietf-codec-requirement-02 with draft-valin-codec-requirements-02, I only see editorial changes. https://tools.ietf.org/rfcdiff?url1=draft-ietf-codec-requirements-02&difftyp e=--html&submit=Go!&url2=draft-valin-codec-requirements-02 Sorry guys, if I see this I become very cynical on the standardization process at the IETF. The editors have not done their job and the chairs do not care. At the end, it all looks like rubberstamping with a little bit of theater. Christian From stephen.botzko@gmail.com Mon Jan 24 10:47:05 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED9C3A698F for ; Mon, 24 Jan 2011 10:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC9dkvz8Ju8e for ; Mon, 24 Jan 2011 10:47:04 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E5C213A68FB for ; Mon, 24 Jan 2011 10:47:03 -0800 (PST) Received: by qyj19 with SMTP id 19so4555879qyj.10 for ; Mon, 24 Jan 2011 10:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sf5SZOBnbI4Q9CMKDtoW9orZXs0NJ5pRtNxgUm3EGIo=; b=Thqempk+Qi0H3ygrHS74jYNhGDzXoKKFMf6cX1G6slBAH9/ZlnhlXIvJ+EsdN4i5g0 sh4ymaDd64pp4n3nSYAtxZLfc14HBoUAYSaTnAu/dLxXn7rUtl8L5+LxadWrnbB8m92+ pfGFQrpf1gP0UTWWaqYqYujbQSDyRFSY1tEnQ= 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=siqwnk9dHUtN3fxdJibqdYYR/rijKt9NVtUWICr1NQYpY8EdWDwU587ilV2kjLvI8C IuoVLwaLpYtTxRhQmLW/Gi2A07Jr8Svr87J3211SWs+D/okIC385yM0yTdinVJU+QIJt YLxQoFJ6ttdZYLrz4swU+HaNRThjq6gHTf/bA= MIME-Version: 1.0 Received: by 10.224.60.210 with SMTP id q18mr4383474qah.245.1295894998464; Mon, 24 Jan 2011 10:49:58 -0800 (PST) Received: by 10.220.128.30 with HTTP; Mon, 24 Jan 2011 10:49:58 -0800 (PST) In-Reply-To: <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> Date: Mon, 24 Jan 2011 13:49:58 -0500 Message-ID: From: Stephen Botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0015175ce05e0cba35049a9c11b5 Cc: codec@ietf.org Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 18:47:05 -0000 --0015175ce05e0cba35049a9c11b5 Content-Type: text/plain; charset=ISO-8859-1 >>> [Christian Hoene] Despite hundreds of emails, what were exchanged on this mailing list on issues regarding requirements, the editors have been reluctant to update the requirements document according to the consensus process on this mailing list. >>> Christian - perhaps you could post a list of the issues you see that haven't been addressed? Stephen Botzko On Sun, Jan 23, 2011 at 3:19 AM, Christian Hoene wrote: > > The authors believe that the requirements document is complete. > > [Christian Hoene] Which authors? So far this document has only two selected > editors. > > >The chairs > > would like to now issue a 3 week working group last call for > draft-ietf-codec- > > requirements-02. At the end of 3 weeks, if no comments have been > > received, we will pass the document to the IESG for approval. > > [Christian Hoene] Despite hundreds of emails, what were exchanged on this > mailing list on issues regarding requirements, the editors have been > reluctant to update the requirements document according to the consensus > process on this mailing list. > > If I compare draft-ietf-codec-requirement-02 with > draft-valin-codec-requirements-02, I only see editorial changes. > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-codec-requirements-02&difftyp > e=--html&submit=Go!&url2=draft-valin-codec-requirements-02 > > Sorry guys, if I see this I become very cynical on the standardization > process at the IETF. The editors have not done their job and the chairs > do > not care. At the end, it all looks like rubberstamping with a little bit of > theater. > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0015175ce05e0cba35049a9c11b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
[Christian Hoene] Despite hundreds of emails, what were exc= hanged on this
mailing list on issues regarding requirements, the editors have been
reluctant to update the requirements document according to the consensus process on this mailing list.
>>>
Christian - perhaps you co= uld post a list of the issues you see that haven't been addressed?
<= br>Stephen Botzko

On Sun, Jan 23, 2011 at= 3:19 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
> The authors believe that the requirements document is complete.

[Christian Hoene] Which authors? So far this document has only two se= lected
editors.

>The chairs
> would like to now issue a 3 week working group last call for
draft-ietf-codec-
> requirements-02. At the end of 3 weeks, if no comments have been
> received, we will pass the document to the IESG for approval.

[Christian Hoene] Despite hundreds of emails, what were exchanged on = this
mailing list on issues regarding requirements, the editors have been
reluctant to update the requirements document according to the consensus process on this mailing list.

If I compare draft-ietf-codec-requirement-02 with
draft-valin-codec-requirements-02, I only see editorial changes.
https://tools.ietf.org/rfcdiff?url1= =3Ddraft-ietf-codec-requirements-02&difftyp
e=3D--html&submit=3DGo!&url2=3Ddraft-valin-codec-requirements-02
Sorry guys, if I see this I become very cynical on the standardization
process at the IETF. =A0 The editors have not done their job and the chairs= do
not care. At the end, it all looks like rubberstamping with a little bit of=
theater.

Christian


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

--0015175ce05e0cba35049a9c11b5-- From hoene@uni-tuebingen.de Mon Jan 24 12:07:49 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6642F3A693C for ; Mon, 24 Jan 2011 12:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUGNscJ58CDj for ; Mon, 24 Jan 2011 12:07:48 -0800 (PST) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 452CA3A6904 for ; Mon, 24 Jan 2011 12:07:48 -0800 (PST) Received: from hoeneT60 (p5B2011D8.dip0.t-ipconnect.de [91.32.17.216]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p0OKAYvQ011263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jan 2011 21:10:40 +0100 From: "Christian Hoene" To: "'Stephen Botzko'" References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> In-Reply-To: Date: Mon, 24 Jan 2011 21:10:35 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CBBC0B.28715810" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWDjsml9J24OP+D1jOWj/YeoWjlgHEh91YAdiRriCTLvNgEA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx05) Cc: codec@ietf.org Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 20:07:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0011_01CBBC0B.28715810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christian - perhaps you could post a list of the issues you see that haven't been addressed? [Christian Hoene] No Stephen, these issues have been written down in previous emails, drafts and issues in the Trac. They can be read by anybody anytime. Thus, I do not see any benefit of repeating them again if the editors continue to ignore any input. Indeed, they did not improve the draft despite sound technical reasons. Even if somebody is not fully involved in the technical details: It is very odd that despite many hundreds emails and many discussions since starting this WG the editors have not updated the draft beside minor changes such as the boilerplate and typos. Even if the lack of any update was not intentionally, the editors missed to do their job because they were too lazy or rather too busy doing other thinks. I would be sad if all the fruitful discussions here and all the good contributions of many industry experts should have been in vain. Even if not all requirements can be met by Opus, a proper requirements document may be relevant for future solutions or other SDOs. CH ------=_NextPart_000_0011_01CBBC0B.28715810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christian - perhaps you could post a list of the issues you = see that haven't been addressed?

[Christian Hoene] No Stephen, these issues have been written down in = previous emails, drafts and issues in the Trac. They can be read by = anybody anytime. Thus, I do not see any benefit of repeating them again = if the editors continue to ignore any input. Indeed, they did not = improve the draft despite sound technical reasons. =

Even if somebody is not fully involved in the technical details: It = is very odd that despite many hundreds emails and many discussions since = starting this WG the editors have not updated the draft beside minor = changes such as the boilerplate and typos. =

Even if the lack of any update was not intentionally, the editors = missed to do their job because they were too lazy or rather too busy = doing other thinks.

I would be sad if all the fruitful discussions here and all the good = contributions of many industry experts should have been in vain. Even if = not all requirements can be met by Opus, a proper requirements document = may be relevant for future solutions or other = SDOs.

CH

------=_NextPart_000_0011_01CBBC0B.28715810-- From stewe@stewe.org Mon Jan 24 12:33:22 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8B83A693C for ; Mon, 24 Jan 2011 12:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4j-EimfaFkE for ; Mon, 24 Jan 2011 12:33:20 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id F26AE3A6962 for ; Mon, 24 Jan 2011 12:33:19 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 55232-1743317 for multiple; Mon, 24 Jan 2011 21:36:14 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 24 Jan 2011 12:36:06 -0800 From: Stephan Wenger To: Christian Hoene , 'Stephen Botzko' Message-ID: Thread-Topic: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 In-Reply-To: <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3378717373_14165870" 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] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 20:33:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3378717373_14165870 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Christian: I can understand your frustration, and to some extent I share it. However, the purpose of a WGLC is to bring up issues that the editors have missed or not acted upon. So let's bring them up. All: The tracker is supposed to be one organized form of keeping issues alive and make sure that they have been addressed adequately. The tracker can be found at http://trac.tools.ietf.org/wg/codec/trac/report. I believe that most requirements-related issues have been entered into the tracker in some form, although, in order to see whether an issue has been addressed according to the WG consensus or to get a full picture of all issues, one would have to review the mailing list as well. But the tracker is a good starting point. Thanks, Stephan From: Christian Hoene Organization: Universitat Tubingen Date: Mon, 24 Jan 2011 21:10:35 +0100 To: 'Stephen Botzko' Cc: Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 Christian - perhaps you could post a list of the issues you see that haven't been addressed? [Christian Hoene] No Stephen, these issues have been written down in previous emails, drafts and issues in the Trac. They can be read by anybody anytime. Thus, I do not see any benefit of repeating them again if the editors continue to ignore any input. Indeed, they did not improve the draft despite sound technical reasons. Even if somebody is not fully involved in the technical details: It is very odd that despite many hundreds emails and many discussions since starting this WG the editors have not updated the draft beside minor changes such as the boilerplate and typos. Even if the lack of any update was not intentionally, the editors missed to do their job because they were too lazy or rather too busy doing other thinks. I would be sad if all the fruitful discussions here and all the good contributions of many industry experts should have been in vain. Even if not all requirements can be met by Opus, a proper requirements document may be relevant for future solutions or other SDOs. CH _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --B_3378717373_14165870 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Christian:
I ca= n understand your frustration, and to some extent I share it.  However,= the purpose of a WGLC is to bring up issues that the editors have missed or= not acted upon.  So let's bring them up.  

All:
The tracker is supposed to be one organized form of keepin= g issues alive and make sure that they have been addressed adequately.  = ;The tracker can be found at http://trac.tools.ietf.org/wg/codec/trac/report.  I= believe that most requirements-related issues have been entered into the tr= acker in some form, although, in order to see whether an issue has been addr= essed according to the WG consensus or to get a full picture of all issues, = one would have to review the mailing list as well.  But the tracker is = a good starting point.

Thanks,
Stephan


From: C= hristian Hoene <hoene@uni-tuebing= en.de>
Organization: Univer= sitat Tubingen
Date: Mon, 24 Jan 2= 011 21:10:35 +0100
To: 'Stephen Bo= tzko' <stephen.botzko@gmail.com= >
Cc: <codec@ietf.org>
Subj= ect: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02
=

Christian - perhaps you could post a list of the iss= ues you see that haven't been addressed?

=

[Christian Hoene] No Stephen, these iss= ues have been written down in previous emails, drafts and issues in the Trac= . They can be read by anybody anytime. Thus, I do not see any benefit of rep= eating them again if the editors continue to ignore any input. Indeed, they = did not improve the draft despite sound technical reasons.

Even if somebody is not fully involved in the technical= details: It is very odd that despite many hundreds emails and many discussi= ons since starting this WG the editors have not updated the draft beside min= or changes such as the boilerplate and typos.

=

Even if the lack of any update was not intentionally, the editors mi= ssed to do their job because they were too lazy or rather too busy doing oth= er thinks.

I would be sad if all the fr= uitful discussions here and all the good contributions of many industry expe= rts should have been in vain. Even if not all requirements can be met by Opu= s, a proper requirements document may be relevant for future solutions or ot= her SDOs.

CH<= /p>

_______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/= mailman/listinfo/codec --B_3378717373_14165870-- From trac@tools.ietf.org Mon Jan 24 14:36:08 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AE03A69B0 for ; Mon, 24 Jan 2011 14:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sj8Pe8OyqhZa for ; Mon, 24 Jan 2011 14:36:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 58DE13A69A6 for ; Mon, 24 Jan 2011 14:36:07 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhV3t-0001c7-2s; Mon, 24 Jan 2011 14:39:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:39:01 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/13#comment:4 Message-ID: <071.27f927ef2e20706537842f044ce8adb3@tools.ietf.org> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #13 (new): reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:36:08 -0000 #13: reference use-cases and topologies! Comment(by gmaxwell@…): As far as I can tell, this request is redundant to RFC 5117, as pointed out above. Can we go ahead and close out this ticket? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 14:39:46 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710B43A69AF for ; Mon, 24 Jan 2011 14:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 n6BZb-Ha2FJX for ; Mon, 24 Jan 2011 14:39:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CCEEB3A699E for ; Mon, 24 Jan 2011 14:39:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhV7R-0001lF-95; Mon, 24 Jan 2011 14:42:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:42:41 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/20#comment:4 Message-ID: <071.db5c101e648f25a7408bb7ea15cd3ebe@tools.ietf.org> References: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #20 (new): Computational complexity? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:39:46 -0000 #20: Computational complexity? Comment(by gmaxwell@…): Section 4.4 of draft-ietf-codec-requirements-02 appears to address this point. Is there any opposition to closing this ticket? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 14:44:02 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F1C3A6998 for ; Mon, 24 Jan 2011 14:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DJIO4CUdXruM for ; Mon, 24 Jan 2011 14:44:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E18D93A697B for ; Mon, 24 Jan 2011 14:44:01 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVBP-0003Eb-Jc; Mon, 24 Jan 2011 14:46:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:46:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/21#comment:3 Message-ID: <071.77650995bff3514ed4a2b17c2f8ac184@tools.ietf.org> References: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #21 (new): Supporting Wireless Links? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:44:02 -0000 #21: Supporting Wireless Links? Comment(by gmaxwell@…): Wireless IP is a packet-loss channel like all other IP networks. The requirements draft suggests that bit-error robustness is useful for non- packet-loss channels, but I don't see what more is required on this subject. Is any further activity required on this point? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: jean-marc.valin@… Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 14:46:45 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363A53A69B4 for ; Mon, 24 Jan 2011 14:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 oixdypjuivFc for ; Mon, 24 Jan 2011 14:46:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7B43A3A697B for ; Mon, 24 Jan 2011 14:46:44 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVEB-0006NI-Ag; Mon, 24 Jan 2011 14:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:49:39 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/22#comment:2 Message-ID: <071.2b6152636f56b0407f59c27ba2cfd6b3@tools.ietf.org> References: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #22 (closed): Memory Usage? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:46:45 -0000 #22: Memory Usage? Changes (by gmaxwell@…): * status: new => closed * resolution: => worksforme Comment: This is addressed in the final paragraph of section 4.4 of draft-ietf- codec-requirements-02.txt. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: - | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 14:48:40 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1479B3A69A5 for ; Mon, 24 Jan 2011 14:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZK5SoRtY-HXT for ; Mon, 24 Jan 2011 14:48:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 105E13A697B for ; Mon, 24 Jan 2011 14:48:39 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVG3-0006S8-24; Mon, 24 Jan 2011 14:51:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:51:34 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/25#comment:1 Message-ID: <071.684193b38e6c92954181211c5fb39e92@tools.ietf.org> References: <062.fa1ef2502db4c466d61a6fc906191800@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <062.fa1ef2502db4c466d61a6fc906191800@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #25 (new): Supported audio contents X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:48:40 -0000 #25: Supported audio contents Comment(by gmaxwell@…): Section 2. Lists a number of applications, and for each of those it breaks out some of the content requirements. I believe the actual testing procedure is out of scope for the requirements RFC. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 14:52:00 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E183A69B6 for ; Mon, 24 Jan 2011 14:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 lJ7aHtNUI1mh for ; Mon, 24 Jan 2011 14:51:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 09BF83A69B4 for ; Mon, 24 Jan 2011 14:51:59 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVJG-0006XZ-Uk; Mon, 24 Jan 2011 14:54:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Mon, 24 Jan 2011 22:54:54 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/26#comment:1 Message-ID: <071.8b17e3b163ccf8abc1bd53f67a28f983@tools.ietf.org> References: <062.e0143a819120da8641009b7ca8a91dcf@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <062.e0143a819120da8641009b7ca8a91dcf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #26 (new): Comparing the CODEC to other codecs... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:52:00 -0000 #26: Comparing the CODEC to other codecs... Comment(by gmaxwell@…): There are thousands of codecs in existence. The requirements specify a number of baseline comparison points of codecs nearest the current application space. Considering the significant workload required to add another codec in a comparison, I don't believe any omission here is actually an issue unless there is a clear consensus that we need to add additional codecs to the baseline set. I believe we can close this issue. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From jean-marc.valin@octasic.com Mon Jan 24 15:06:02 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E5B3A69B5 for ; Mon, 24 Jan 2011 15:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeHSbTpBhWjQ for ; Mon, 24 Jan 2011 15:06:01 -0800 (PST) Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07-srv.bellnexxia.net [207.236.237.41]) by core3.amsl.com (Postfix) with ESMTP id 02D563A697B for ; Mon, 24 Jan 2011 15:06:00 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110124230855.TGJO3521.toroondcbmts07-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Mon, 24 Jan 2011 18:08:55 -0500 Received: from toip53-bus.srvr.bell.ca ([67.69.240.54]) by toip58-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 18:08:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+VPU3PPaAN/2dsb2JhbACkbHO7WIVQBIRwiVUG Received: from mail.octasic.com ([207.61.160.13]) by toip53-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 18:08:39 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 18:08:39 -0500 Message-ID: <4D3E0676.1040704@octasic.com> Date: Mon, 24 Jan 2011 18:08:38 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christian Hoene References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> In-Reply-To: <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, 'Stephen Botzko' Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 23:06:02 -0000 Christian, I actually responded to the last comments you made a while ago (oct 2010). One issue I pointed out was your use of RFC2119 keywords, which (AFAIK) aren't appropriate for a requirements draft (the requirements aren't a standard). So statements like "Any codec specified by the IETF MUST be well specified", besides stating the obvious, are inappropriate. There were also comments that just did not belong to this draft, such as the section on collaboration with other WGs. Collaboration is not a characteristic of a codec. So essentially, I merged the uncontroversial suggestion, but that's all I could do. As far as I'm aware, there's nothing in the current draft that goes against the consensus of the WG. If there are, please point to specific issues and to statements made by others (not just you) asking for the change. Cheers, Jean-Marc On 11-01-24 03:10 PM, Christian Hoene wrote: > Christian - perhaps you could post a list of the issues you see that > haven't been addressed? > > */[Christian Hoene] No Stephen, these issues have been written down in > previous emails, drafts and issues in the Trac. They can be read by anybody > anytime. Thus, I do not see any benefit of repeating them again if the > editors continue to ignore any input. Indeed, they did not improve the > draft despite sound technical reasons. /* > > */Even if somebody is not fully involved in the technical details: It is > very odd that despite many hundreds emails and many discussions since > starting this WG the editors have not updated the draft beside minor > changes such as the boilerplate and typos. /* > > */Even if the lack of any update was not intentionally, the editors missed > to do their job because they were too lazy or rather too busy doing other > thinks./* > > */I would be sad if all the fruitful discussions here and all the good > contributions of many industry experts should have been in vain. Even if > not all requirements can be met by Opus, a proper requirements document may > be relevant for future solutions or other SDOs./* > > */CH/* > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From trac@tools.ietf.org Mon Jan 24 15:13:13 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6F73A69A5 for ; Mon, 24 Jan 2011 15:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 oTn6-3HOqOOo for ; Mon, 24 Jan 2011 15:13:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B58363A6995 for ; Mon, 24 Jan 2011 15:13:12 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVdo-0007VU-KH; Mon, 24 Jan 2011 15:16:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:16:08 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/30#comment:1 Message-ID: <071.b681b6766fc211297c9a9f2b2a5c5f5b@tools.ietf.org> References: <062.c36de91b7a452074af754b94421f5053@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <062.c36de91b7a452074af754b94421f5053@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #30 (new): Self-awareness X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:13:13 -0000 #30: Self-awareness Comment(by gmaxwell@…): These all sound like implementation properties to me, and could be implemented (and would depend on) transport level things like the RTP timestamps. An implementation could do (or fail to do) these things completely independent of the the design of the codec working group product. I believe that we can close this issue in terms of the requirements. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:17:48 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2C03A6B39 for ; Mon, 24 Jan 2011 15:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 fcXWITQHJZPk for ; Mon, 24 Jan 2011 15:17:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9152E3A6B1F for ; Mon, 24 Jan 2011 15:17:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhViF-0003lA-7A; Mon, 24 Jan 2011 15:20:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:20:42 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/3#comment:2 Message-ID: <071.17ee98540673ecba23bdcea0ec5bfa95@tools.ietf.org> References: <062.a837f2ff7647f7cb184f0c86b7e65747@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <062.a837f2ff7647f7cb184f0c86b7e65747@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #3 (new): 2.2. Conferencing: Support of binaural audio? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:17:48 -0000 #3: 2.2. Conferencing: Support of binaural audio? Comment(by gmaxwell@…): Stereo support is address in 5.5 of draft-ietf-codec-requirements-02.txt and the mixing language in 5.1 is stereo/mono neutral. I am not aware of any technical reason raised why stereo _mixing_ would somehow be technically distinct from any other form of mixing. More information is required if this issue is to remain open. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From mary.ietf.barnes@gmail.com Mon Jan 24 15:21:38 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2293A69BE for ; Mon, 24 Jan 2011 15:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 lyGTm3+AVBpM for ; Mon, 24 Jan 2011 15:21:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0C57D3A69B5 for ; Mon, 24 Jan 2011 15:21:35 -0800 (PST) Received: by yxt33 with SMTP id 33so1736256yxt.31 for ; Mon, 24 Jan 2011 15:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EMQ+YExgTAE4zBOM6RyUQVBofSGTczsHZQ+3/vAUJQQ=; b=nRqxnc9BL83QpJWGEq4nwXx1tl++A5LfUy3EJAsIhRcVH9TmCJQh0uLhRJq7/uA8zk fMwEBoCd4rDSw8sNvZiBoMuOxnVRDWZhScWJ+7y02Rl5t+NqJA4B+UHx/ZLdFo+pgNkg fhxfdDTMu15oD1WGeTqCSAY2zRVIqlN9z9Tjs= 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=asoh6BG99ZSG2GnaPWb8bckjONaJLLa22BTSV0kF9QieJhMCO0mucwtEShyBJGjj0Z CYkI9tCetGXtGwWI5TsYes8FoA3EB+W1roztahmhXyyPy0o43clTL+oAJjPipqSsShxT P3D3mR41zt674fMQKcuFs0M011MFTQXQ/aeFE= MIME-Version: 1.0 Received: by 10.90.25.13 with SMTP id 13mr5809004agy.33.1295911470726; Mon, 24 Jan 2011 15:24:30 -0800 (PST) Received: by 10.236.95.35 with HTTP; Mon, 24 Jan 2011 15:24:30 -0800 (PST) In-Reply-To: <4D3E0676.1040704@octasic.com> References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> Date: Mon, 24 Jan 2011 17:24:30 -0600 Message-ID: From: Mary Barnes To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=00163630f5fbdf81b4049a9fe604 Cc: codec@ietf.org, Stephen Botzko Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 23:21:39 -0000 --00163630f5fbdf81b4049a9fe604 Content-Type: text/plain; charset=ISO-8859-1 The document is currently specified as Standards Track, thus the use of RFC 2119 language is entirely appropriate. However, ISTM that the document should really just be Informational, in particular given the language in the introduction that this document defines a "suggested process", as opposed to a process that is required for codec development. Regards, Mary. On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin < jean-marc.valin@octasic.com> wrote: > Christian, > > I actually responded to the last comments you made a while ago (oct 2010). > One issue I pointed out was your use of RFC2119 keywords, which (AFAIK) > aren't appropriate for a requirements draft (the requirements aren't a > standard). So statements like "Any codec specified by the IETF MUST be well > specified", besides stating the obvious, are inappropriate. > > There were also comments that just did not belong to this draft, such as > the section on collaboration with other WGs. Collaboration is not a > characteristic of a codec. So essentially, I merged the uncontroversial > suggestion, but that's all I could do. As far as I'm aware, there's nothing > in the current draft that goes against the consensus of the WG. If there > are, please point to specific issues and to statements made by others (not > just you) asking for the change. > > Cheers, > > Jean-Marc > > > On 11-01-24 03:10 PM, Christian Hoene wrote: > >> Christian - perhaps you could post a list of the issues you see that >> haven't been addressed? >> >> */[Christian Hoene] No Stephen, these issues have been written down in >> previous emails, drafts and issues in the Trac. They can be read by >> anybody >> anytime. Thus, I do not see any benefit of repeating them again if the >> editors continue to ignore any input. Indeed, they did not improve the >> draft despite sound technical reasons. /* >> >> */Even if somebody is not fully involved in the technical details: It is >> very odd that despite many hundreds emails and many discussions since >> starting this WG the editors have not updated the draft beside minor >> changes such as the boilerplate and typos. /* >> >> */Even if the lack of any update was not intentionally, the editors missed >> to do their job because they were too lazy or rather too busy doing other >> thinks./* >> >> */I would be sad if all the fruitful discussions here and all the good >> contributions of many industry experts should have been in vain. Even if >> not all requirements can be met by Opus, a proper requirements document >> may >> be relevant for future solutions or other SDOs./* >> >> */CH/* >> >> >> >> >> _______________________________________________ >> 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 > --00163630f5fbdf81b4049a9fe604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The document is currently specified as Standards Track, thus the use of RFC= 2119 language is entirely appropriate. =A0However, ISTM that the document = should really just be Informational, in particular given the language in th= e introduction that this document defines a "suggested process", as opposed to a proces= s that is required for codec development. =A0

Regards,
Mary.
On Mon, Jan 24, 2011 at 5:08= PM, Jean-Marc Valin <jean-marc.valin@octasic.com> wrote:
Christian,

I actually responded to the last comments you made a while ago (oct 2010). = One issue I pointed out was your use of RFC2119 keywords, which (AFAIK) are= n't appropriate for a requirements draft (the requirements aren't a= standard). So statements like "Any codec specified by the IETF MUST b= e well specified", besides stating the obvious, are inappropriate.

There were also comments that just did not belong to this draft, such as th= e section on collaboration with other WGs. Collaboration is not a character= istic of a codec. So essentially, I merged the uncontroversial suggestion, = but that's all I could do. As far as I'm aware, there's nothing= in the current draft that goes against the consensus of the WG. If there a= re, please point to specific issues and to statements made by others (not j= ust you) asking for the change.

Cheers,

=A0 =A0 =A0 =A0Jean-Marc


On 11-01-24 03:10 PM, Christian Hoene wrote:
Christian - perhaps you could post a list of the issues you see that
haven't been addressed?

*/[Christian Hoene] No Stephen, these issues have been written down in
previous emails, drafts and issues in the Trac. They can be read by anybody=
anytime. Thus, I do not see any benefit of repeating them again if the
editors continue to ignore any input. Indeed, they did not improve the
draft despite sound technical reasons. /*

*/Even if somebody is not fully involved in the technical details: It is very odd that despite many hundreds emails and many discussions since
starting this WG the editors have not updated the draft beside minor
changes such as the boilerplate and typos. /*

*/Even if the lack of any update was not intentionally, the editors missed<= br> to do their job because they were too lazy or rather too busy doing other thinks./*

*/I would be sad if all the fruitful discussions here and all the good
contributions of many industry experts should have been in vain. Even if not all requirements can be met by Opus, a proper requirements document may=
be relevant for future solutions or other SDOs./*

*/CH/*




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

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

--00163630f5fbdf81b4049a9fe604-- From stpeter@stpeter.im Mon Jan 24 15:23:10 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05313A69BE for ; Mon, 24 Jan 2011 15:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 CVUy9FoKaPJ5 for ; Mon, 24 Jan 2011 15:23:08 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 19A773A69B5 for ; Mon, 24 Jan 2011 15:23:08 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 134C3400F6; Mon, 24 Jan 2011 16:42:08 -0700 (MST) Message-ID: <4D3E0A8A.5070706@stpeter.im> Date: Mon, 24 Jan 2011 16:26:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mary Barnes References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050205000605080700020806" Cc: codec@ietf.org, Stephen Botzko Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 23:23:10 -0000 This is a cryptographically signed message in MIME format. --------------ms050205000605080700020806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Mary here. On 1/24/11 4:24 PM, Mary Barnes wrote: > The document is currently specified as Standards Track, thus the use of= > RFC 2119 language is entirely appropriate. However, ISTM that the > document should really just be Informational, in particular given the > language in the introduction that this document defines a "suggested > process", as opposed to a process that is required for codec developmen= t. =20 >=20 > Regards, > Mary. >=20 > On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin > > wrot= e: >=20 > Christian, >=20 > I actually responded to the last comments you made a while ago (oct= > 2010). One issue I pointed out was your use of RFC2119 keywords, > which (AFAIK) aren't appropriate for a requirements draft (the > requirements aren't a standard). So statements like "Any codec > specified by the IETF MUST be well specified", besides stating the > obvious, are inappropriate. >=20 > There were also comments that just did not belong to this draft, > such as the section on collaboration with other WGs. Collaboration > is not a characteristic of a codec. So essentially, I merged the > uncontroversial suggestion, but that's all I could do. As far as I'= m > aware, there's nothing in the current draft that goes against the > consensus of the WG. If there are, please point to specific issues > and to statements made by others (not just you) asking for the chan= ge. >=20 > Cheers, >=20 > Jean-Marc >=20 >=20 > On 11-01-24 03:10 PM, Christian Hoene wrote: >=20 > Christian - perhaps you could post a list of the issues you see= that > haven't been addressed? >=20 > */[Christian Hoene] No Stephen, these issues have been written > down in > previous emails, drafts and issues in the Trac. They can be rea= d > by anybody > anytime. Thus, I do not see any benefit of repeating them again= > if the > editors continue to ignore any input. Indeed, they did not > improve the > draft despite sound technical reasons. /* >=20 > */Even if somebody is not fully involved in the technical > details: It is > very odd that despite many hundreds emails and many discussions= > since > starting this WG the editors have not updated the draft beside = minor > changes such as the boilerplate and typos. /* >=20 > */Even if the lack of any update was not intentionally, the > editors missed > to do their job because they were too lazy or rather too busy > doing other > thinks./* >=20 > */I would be sad if all the fruitful discussions here and all > the good > contributions of many industry experts should have been in vain= =2E > Even if > not all requirements can be met by Opus, a proper requirements > document may > be relevant for future solutions or other SDOs./* >=20 > */CH/* >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --------------ms050205000605080700020806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy NDIzMjYwMlowIwYJKoZIhvcNAQkEMRYEFGu22Hr0Yf0dlGezrOUIe+iCu3v3MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAnnsQm3Ke7W4WbBs5MiPwKdNN2yGNTtFqLma+omqVUFoOwt7Rlx64CeFga JotZv9yGsDoZc/ctwvH61zU+09kWIhFaPNHYkHfxzTQj9cp7JBmssJOFTQYKXDjYa4q7QMfa pJ0m3RlrF0MsEa+CzGzBfQmGuecCc9ahpGBwooc/JVU0roJmy57d2AAwNVkjHP6SKtlfetps lCZbkdC0GoTcMyPjBAosJ6Dkm6RoX22fQ8x8AcAyeYbWrCyTeV8NjKaVstlh+6KtFFoi0BgI 6e1lnRgcE+2CHd8hCuvhmfpI/AndHAFVKLSBZd4cPJMF2ggSvO74hKDy/1juCHLnoQ28AAAA AAAA --------------ms050205000605080700020806-- From jean-marc.valin@octasic.com Mon Jan 24 15:24:26 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED45B3A69C0 for ; Mon, 24 Jan 2011 15:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX7PoDTBEkAr for ; Mon, 24 Jan 2011 15:24:25 -0800 (PST) Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07.bellnexxia.net [207.236.237.41]) by core3.amsl.com (Postfix) with ESMTP id 413AB3A69B5 for ; Mon, 24 Jan 2011 15:24:25 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110124232720.TQGY3521.toroondcbmts07-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Mon, 24 Jan 2011 18:27:20 -0500 Received: from toip52-bus.srvr.bell.ca ([67.69.240.55]) by toip58-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 18:27:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJuRPU3PPaAN/2dsb2JhbACkbHO7TIVQBIRwiVUG Received: from mail.octasic.com ([207.61.160.13]) by toip52-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 18:27:09 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 18:27:09 -0500 Message-ID: <4D3E0ACC.8030107@octasic.com> Date: Mon, 24 Jan 2011 18:27:08 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> <4D3E0A8A.5070706@stpeter.im> In-Reply-To: <4D3E0A8A.5070706@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, Stephen Botzko Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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: Mon, 24 Jan 2011 23:24:27 -0000 Sorry, this was indeed intended to be informational (probably bad copy/paste). Let me fix that. Jean-Marc On 11-01-24 06:26 PM, Peter Saint-Andre wrote: > I agree with Mary here. > > On 1/24/11 4:24 PM, Mary Barnes wrote: >> The document is currently specified as Standards Track, thus the use of >> RFC 2119 language is entirely appropriate. However, ISTM that the >> document should really just be Informational, in particular given the >> language in the introduction that this document defines a "suggested >> process", as opposed to a process that is required for codec development. >> >> Regards, >> Mary. >> >> On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin >> > wrote: >> >> Christian, >> >> I actually responded to the last comments you made a while ago (oct >> 2010). One issue I pointed out was your use of RFC2119 keywords, >> which (AFAIK) aren't appropriate for a requirements draft (the >> requirements aren't a standard). So statements like "Any codec >> specified by the IETF MUST be well specified", besides stating the >> obvious, are inappropriate. >> >> There were also comments that just did not belong to this draft, >> such as the section on collaboration with other WGs. Collaboration >> is not a characteristic of a codec. So essentially, I merged the >> uncontroversial suggestion, but that's all I could do. As far as I'm >> aware, there's nothing in the current draft that goes against the >> consensus of the WG. If there are, please point to specific issues >> and to statements made by others (not just you) asking for the change. >> >> Cheers, >> >> Jean-Marc >> >> >> On 11-01-24 03:10 PM, Christian Hoene wrote: >> >> Christian - perhaps you could post a list of the issues you see that >> haven't been addressed? >> >> */[Christian Hoene] No Stephen, these issues have been written >> down in >> previous emails, drafts and issues in the Trac. They can be read >> by anybody >> anytime. Thus, I do not see any benefit of repeating them again >> if the >> editors continue to ignore any input. Indeed, they did not >> improve the >> draft despite sound technical reasons. /* >> >> */Even if somebody is not fully involved in the technical >> details: It is >> very odd that despite many hundreds emails and many discussions >> since >> starting this WG the editors have not updated the draft beside minor >> changes such as the boilerplate and typos. /* >> >> */Even if the lack of any update was not intentionally, the >> editors missed >> to do their job because they were too lazy or rather too busy >> doing other >> thinks./* >> >> */I would be sad if all the fruitful discussions here and all >> the good >> contributions of many industry experts should have been in vain. >> Even if >> not all requirements can be met by Opus, a proper requirements >> document may >> be relevant for future solutions or other SDOs./* >> >> */CH/* >> >> >> >> >> _______________________________________________ >> 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 trac@tools.ietf.org Mon Jan 24 15:26:03 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC523A6B1F for ; Mon, 24 Jan 2011 15:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 7BYnozOpdcTF for ; Mon, 24 Jan 2011 15:26:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2DBB63A6B3E for ; Mon, 24 Jan 2011 15:26:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVqD-0006nA-3G; Mon, 24 Jan 2011 15:28:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:28:57 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/18#comment:3 Message-ID: <071.e294ae064ab7feeae7482dac7eb5be57@tools.ietf.org> References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #18 (closed): Frame Sizes? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:26:03 -0000 #18: Frame Sizes? Changes (by gmaxwell@…): * status: new => closed * resolution: => worksforme Comment: The frame sizes are driven by the latent requirements. I don't believe that there has been any preference expressed for frame sizes independent of the latency preferences. The requirements documents discusses latency in depth: http://tools.ietf.org/id/draft-ietf-codec-requirements-02.txt Section 2.1 "The codec delay must be less than 40 ms, but no more than 25ms is desirable." Section 2.2 "For this reason, the codec delay must be less than 30 ms for this application. An optional low-delay mode with less than 10 ms delay is desirable, but not required." Section 2.5 " While for most applications a codec delay up to 30 ms is acceptable, a low-delay (<10 ms) option is highly desirable, especially for games with rapid interactions." etc. I believe the language of the current requirements draft reflects the best consensus that we were able to achieve— a fairly open _requirement_ but a strong preference for lower delay support for many applications. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: - | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:34:21 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1CE3A69B5 for ; Mon, 24 Jan 2011 15:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OiRt4SrcteIC for ; Mon, 24 Jan 2011 15:34:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 55A473A6995 for ; Mon, 24 Jan 2011 15:34:20 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhVyG-0005sX-0r; Mon, 24 Jan 2011 15:37:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:37:15 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/29#comment:2 Message-ID: <071.6802305aa0f40534e45c23f0a36082f0@tools.ietf.org> References: <062.7815381850dc9f0a504d2c451298e6bb@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <062.7815381850dc9f0a504d2c451298e6bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #29 (closed): Packet loss concealment? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:34:21 -0000 #29: Packet loss concealment? Changes (by gmaxwell@…): * status: new => closed * resolution: => fixed Comment: This is addressed in the guidelines: http://tools.ietf.org/html/draft-valin-codec-guidelines-08 4.5: "To ensure freedom of implementation, decoder-side only error concealment does not need to be specified, although the reference implementation should include the same PLC algorithm as used in the testing phase. Is it up to the working group to decide whether minimum requirements on PLC quality will be required for compliance with the specification. Obviously, any information signaled in the bitstream intended to aid PLC needs to be specified." I don't believe the working group has expressed interest in PLC performance, and I know that there is at least some opposition to requiring specific that implementers provide a particular PLC or PLC performance (e.g. I'd be opposed to requiring a particular kind of PLC). As such, Jean-Marc is adding the following parallel language to section 3 of the requirements document: "To ensure freedom of implementation, decoder-side only error concealment does not need to be specified, although a functional PLC algorithm is desirable as part of the codec reference implementation. Obviously, any information signaled in the bitstream intended to aid PLC needs to be specified." (Available at http://jmvalin.ca/misc_stuff/draft-ietf-codec- requirements.txt) -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:40:04 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A221F3A69B5 for ; Mon, 24 Jan 2011 15:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 p1lwcq0po0pp for ; Mon, 24 Jan 2011 15:40:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DE5523A69B4 for ; Mon, 24 Jan 2011 15:40:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhW3m-0006Hu-Hk; Mon, 24 Jan 2011 15:42:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:42:58 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/23#comment:2 Message-ID: <071.a65fbae337e77d58c0c3e578a0eb539d@tools.ietf.org> References: <062.b61c5855ce44adba1265c9026766b943@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <062.b61c5855ce44adba1265c9026766b943@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #23 (new): Impact of packet headers and header compression X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:40:04 -0000 #23: Impact of packet headers and header compression Comment(by gmaxwell@…): Vaguely related: http://tools.ietf.org/id/draft-ietf-codec- requirements-02.txt Section 1. "Codec bit-rates in bits per second (b/s) will be considered without counting any overhead (IP/UDP/RTP headers, padding, ...)." and Section 4.2 " When comparing the bit-rate of codecs, the overhead of IP/UDP/RTP headers should not be considered, but any additional bits required in the RTP payload format after the header (e.g. required signalling) should be considered. " Because header overhead is generally dependent on the transport, and not our activities I don't believe that we really have much to require here from the codec itself. Unless someone has some specific proposed requirement language to suggest, I propose that we close this ticket and leave any requirements related to RTP packetization to the specific RFCs describing the packetization. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:47:44 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64053A69B6 for ; Mon, 24 Jan 2011 15:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZAKMtmlx7ZKI for ; Mon, 24 Jan 2011 15:47:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DDC833A6938 for ; Mon, 24 Jan 2011 15:47:43 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWBD-0002SS-F8; Mon, 24 Jan 2011 15:50:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:50:39 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/32#comment:2 Message-ID: <071.24cc7558bd70fb6e318a0d645c5ad015@tools.ietf.org> References: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #32 (new): Playout/Dejittering Buffer X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:47:44 -0000 #32: Playout/Dejittering Buffer Comment(by gmaxwell@…): I believe the complete system requirements and detailed testing methodology is out of scope for the CODEC requirements document. I believe the requirements stipulation on real world testing is satisfied by whatever basically reasonable methodology is applied so long as it is applied uniformly and does not offend the consensus of the working group. In other words, I see no reason for our permissive testing requirement to force us to import detailed systems requirements into the codec requirement document, no more than does the mention of "quality" in the document demand that we specific a particular headphone manufacturer for listening tests in this document. Am I missing any reason why this ticket can't be closed? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:50:53 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820CC3A69B5 for ; Mon, 24 Jan 2011 15:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 tm6R2o3eT7RP for ; Mon, 24 Jan 2011 15:50:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CAF113A6938 for ; Mon, 24 Jan 2011 15:50:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWEF-0002WJ-21; Mon, 24 Jan 2011 15:53:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:53:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/27#comment:2 Message-ID: <071.c91b679a641584e3d5a3af72c17cd25b@tools.ietf.org> References: <062.5f24684b1812b35d7a153e141fffc149@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <062.5f24684b1812b35d7a153e141fffc149@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #27 (closed): Testing Impact of IP on Codec Performance X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:50:53 -0000 #27: Testing Impact of IP on Codec Performance Changes (by gmaxwell@…): * status: new => closed * resolution: => duplicate Comment: I believe that we can fold this one into #32. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:54:21 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F043A69B6 for ; Mon, 24 Jan 2011 15:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rAxd2y2IppHh for ; Mon, 24 Jan 2011 15:54:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D261E3A69B5 for ; Mon, 24 Jan 2011 15:54:20 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWHd-0002a8-45; Mon, 24 Jan 2011 15:57:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Mon, 24 Jan 2011 23:57:17 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/10#comment:1 Message-ID: <071.e51df8d21863b2af0863d79457572513@tools.ietf.org> References: <062.5924fe56212099d2fdb86d57ea18cfe0@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <062.5924fe56212099d2fdb86d57ea18cfe0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #10 (new): Multi-channel frame ordering? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:54:21 -0000 #10: Multi-channel frame ordering? Comment(by gmaxwell@…): I believe this is a primarily codec design question. E.g. How the bits are written onto the wire. The requirements draft covers our multichannel requirements in some of the applications sections (e.g. 2.3) and in Section 5.5. I believe that we can either close this ticket or convert it to a ticket regarding the Opus draft. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 15:59:09 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631273A69C0 for ; Mon, 24 Jan 2011 15:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 t0Utnxmz0aVf for ; Mon, 24 Jan 2011 15:59:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AC6183A69B8 for ; Mon, 24 Jan 2011 15:59:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWMG-0008BG-ER; Mon, 24 Jan 2011 16:02:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:02:04 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/31#comment:2 Message-ID: <071.754d514dd8c334daf86081387e0d4cd1@tools.ietf.org> References: <062.033384855453e54a2a3d58ff06d7ccb1@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <062.033384855453e54a2a3d58ff06d7ccb1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #31 (new): Requirements of high-density VoIP gateways (and low cost VoIP phone)? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:59:09 -0000 #31: Requirements of high-density VoIP gateways (and low cost VoIP phone)? Comment(by gmaxwell@…): Section 4.4 in the requirement speaks to the consensus demands for complexity, and sections 5.1 on mixing addresses conferencing. Unless someone has specific requirements language to propose covering omitted requirements, I believe that document as standing pays sufficient attention to complexity and latency that no further action is required on this point. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:03:23 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7496A3A69CC for ; Mon, 24 Jan 2011 16:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 MOOKaW+DJBWi for ; Mon, 24 Jan 2011 16:03:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 89FE73A69B8 for ; Mon, 24 Jan 2011 16:03:22 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWQM-0008Ln-MK; Mon, 24 Jan 2011 16:06:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:06:18 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/34#comment:1 Message-ID: <071.5d801be933c39f5dead78b65380587e3@tools.ietf.org> References: <062.8337dddc40b2c9c88b04caa75d6825e7@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <062.8337dddc40b2c9c88b04caa75d6825e7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #34 (new): Speech Quality Aspects in emergency calls X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:03:23 -0000 #34: Speech Quality Aspects in emergency calls Comment(by gmaxwell@…): It isn't clear to me that this subject area has any particular interaction with the codec bitstream. I don't doubt that its an important areas, but I believe that its primarily a product of the implementation and the system and not the codec bitstream. Certainly no codec specification is going to require the codec to fail to generate packets while the system is requiring it to generate packets. As we lack any proposed requirements language is there any opposition to closing this ticket? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:07:54 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947A63A69BF for ; Mon, 24 Jan 2011 16:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 aaBpgBKC4Zir for ; Mon, 24 Jan 2011 16:07:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E9BA93A69BC for ; Mon, 24 Jan 2011 16:07:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWUS-0001SZ-NH; Mon, 24 Jan 2011 16:10:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de, kpfleming@digium.com X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:10:32 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment:3 Message-ID: <071.1aa2771e64d28615db9c5845cf934d52@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de, kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:07:54 -0000 #8: Sample rates? Comment(by gmaxwell@…): I believe the requirements aspect of this has been addressed. That there is consensus that full-band operation is a requirement, and that other rates/behaviors are possibly for consideration but not required. Have I misunderstood the situation? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: jean-marc.valin@… Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:09:54 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC5A3A69C1 for ; Mon, 24 Jan 2011 16:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bYL99EDwp+cf for ; Mon, 24 Jan 2011 16:09:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D62D53A69BF for ; Mon, 24 Jan 2011 16:09:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWWg-0001Fi-3q; Mon, 24 Jan 2011 16:12:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:12:50 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/9#comment:1 Message-ID: <071.2a4a8a94d8791c52c7432fc5db3d2bd2@tools.ietf.org> References: <062.883ae48af6ccd7f3e6be6d31dd956f2a@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <062.883ae48af6ccd7f3e6be6d31dd956f2a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #9 (closed): Joint stereo/channel coding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:09:54 -0000 #9: Joint stereo/channel coding? Changes (by gmaxwell@…): * status: new => closed * resolution: => worksforme Comment: The requirements document addresses this. Efficient stereo encoding is desirable but not required. http://tools.ietf.org/id/draft-ietf-codec-requirements-02.txt 5.5. Stereo support It is highly desirable for the codec to have stereo support. At a minimum, the codec should be able to encode two channels independently without causing significant stereo image artefacts. It is also desirable for the codec to take advantage of the inter- channel redundancy in stereo audio to reduce the bitrate (for an equivalent quality) of stereo audio compared to coding channels independently. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From roman@telurix.com Mon Jan 24 16:11:18 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A117E3A69BF for ; Mon, 24 Jan 2011 16:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqoLd+M2FVW1 for ; Mon, 24 Jan 2011 16:11:17 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6277B3A69C1 for ; Mon, 24 Jan 2011 16:11:17 -0800 (PST) Received: by iwn40 with SMTP id 40so5025578iwn.31 for ; Mon, 24 Jan 2011 16:14:13 -0800 (PST) Received: by 10.42.241.194 with SMTP id lf2mr5714829icb.66.1295914452184; Mon, 24 Jan 2011 16:14:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id g4sm9334329ick.11.2011.01.24.16.14.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 16:14:11 -0800 (PST) Received: by iwn40 with SMTP id 40so5025531iwn.31 for ; Mon, 24 Jan 2011 16:14:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.36.198 with SMTP id u6mr5666231ibd.100.1295914449902; Mon, 24 Jan 2011 16:14:09 -0800 (PST) Received: by 10.231.167.132 with HTTP; Mon, 24 Jan 2011 16:14:09 -0800 (PST) In-Reply-To: <071.1aa2771e64d28615db9c5845cf934d52@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.1aa2771e64d28615db9c5845cf934d52@tools.ietf.org> Date: Mon, 24 Jan 2011 19:14:09 -0500 Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: multipart/alternative; boundary=0021cc022382721d5d049aa098c9 Cc: jean-marc.valin@usherbrooke.ca Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 25 Jan 2011 00:11:18 -0000 --0021cc022382721d5d049aa098c9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would like to see 8 and 16 KHz as required rates for the codec to insure interoperability with existing narrowband and wideband codecs. In other words we should be able to negotiate 8 or 16 Khz sample rate if audio will be transcoded for PSTN or wideband codec such as G.722 _____________ Roman Shpount On Mon, Jan 24, 2011 at 7:10 PM, codec issue tracker w= rote: > #8: Sample rates? > > > Comment(by gmaxwell@=85): > > I believe the requirements aspect of this has been addressed. That ther= e > is consensus that full-band operation is a requirement, and that other > rates/behaviors are possibly for consideration but not required. > > Have I misunderstood the situation? > > -- > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: jean-marc.valin@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0021cc022382721d5d049aa098c9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would like to see 8 and 16 KHz as required rates for the codec to insure = interoperability with existing narrowband and wideband codecs. In other wor= ds we should be able to negotiate 8 or 16 Khz sample rate if audio will be = transcoded for PSTN or wideband codec such as G.722
_____________
Roman Shpount


On Mon, Jan 24, 2011 at 7:10 PM, codec i= ssue tracker <t= rac@tools.ietf.org> wrote:
#8: Sample rates?


Comment(by gmaxwell@=85):

=A0I believe the requirements aspect of this has been addressed. =A0That th= ere
=A0is consensus that full-band operation is a requirement, and that other =A0rates/behaviors are possibly for consideration but not required.

=A0Have I misunderstood the situation?

--
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: =A0jean-marc.valin@=85
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/tic= ket/8#comment:3>
codec <http:/= /tools.ietf.org/codec/>

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

--0021cc022382721d5d049aa098c9-- From trac@tools.ietf.org Mon Jan 24 16:15:14 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4338C3A69BF for ; Mon, 24 Jan 2011 16:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2azc3JbQV0AQ for ; Mon, 24 Jan 2011 16:15:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 89CF13A69B8 for ; Mon, 24 Jan 2011 16:15:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWbo-0002D3-N1; Mon, 24 Jan 2011 16:18:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:18:08 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/28#comment:3 Message-ID: <071.f471d03f793e74c6048720699b720551@tools.ietf.org> References: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #28 (closed): Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:15:14 -0000 #28: Layered bit-stream Changes (by gmaxwell@…): * status: new => closed * resolution: => worksforme Comment: I haven't seen any recent discussion or interest in changing the current "desirable but not mandatory" language in the requirements draft. http://tools.ietf.org/id/draft-ietf-codec-requirements-02.txt 5.3. Layered bit-stream A layered codec makes it possible to transmit only a certain subset of the bits and still obtain a valid bit-stream with a quality that is equivalent to the quality that would be obtained from encoding at the corresponding rate. While this is not a necessary feature for most applications, it can be desirable for cases where a "mixing server" needs to handle a large number of streams with limited computational resources. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From jean-marc.valin@octasic.com Mon Jan 24 16:17:41 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D85C3A69BF for ; Mon, 24 Jan 2011 16:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiJA3rVsPoOG for ; Mon, 24 Jan 2011 16:17:40 -0800 (PST) Received: from toroondcbmts05-srv.bellnexxia.net (toroondcbmts05.bellnexxia.net [207.236.237.39]) by core3.amsl.com (Postfix) with ESMTP id 013763A69B8 for ; Mon, 24 Jan 2011 16:17:39 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts05-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110125002034.TYYR13003.toroondcbmts05-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Mon, 24 Jan 2011 19:20:34 -0500 Received: from toip38-bus.srvr.bell.ca ([67.69.240.39]) by toip58-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 19:20:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOOjPU3PPaAN/2dsb2JhbACkbHO7cYVQBIRwiVUG Received: from mail.octasic.com ([207.61.160.13]) by toip38-bus.srvr.bell.ca with ESMTP; 24 Jan 2011 19:20:31 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 19:20:31 -0500 Message-ID: <4D3E174E.3020109@octasic.com> Date: Mon, 24 Jan 2011 19:20:30 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roman Shpount References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.1aa2771e64d28615db9c5845cf934d52@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, jean-marc.valin@usherbrooke.ca Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 25 Jan 2011 00:17:41 -0000 I believe such requirement for narrowband/wideband is already present, but I don't mind making it even more explicit is necessary. Jean-Marc On 11-01-24 07:14 PM, Roman Shpount wrote: > I would like to see 8 and 16 KHz as required rates for the codec to insure > interoperability with existing narrowband and wideband codecs. In other > words we should be able to negotiate 8 or 16 Khz sample rate if audio will > be transcoded for PSTN or wideband codec such as G.722 > _____________ > Roman Shpount > > > On Mon, Jan 24, 2011 at 7:10 PM, codec issue tracker > wrote: > > #8: Sample rates? > > > Comment(by gmaxwell@…): > > I believe the requirements aspect of this has been addressed. That there > is consensus that full-band operation is a requirement, and that other > rates/behaviors are possibly for consideration but not required. > > Have I misunderstood the situation? > > -- > ------------------------------------+--------------------------------------- > Reporter: hoene@… | Owner: jean-marc.valin@… > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > > Ticket URL: > 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 trac@tools.ietf.org Mon Jan 24 16:19:00 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1923A69C0 for ; Mon, 24 Jan 2011 16:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 pCyJgaTdjdlS for ; Mon, 24 Jan 2011 16:19:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1620E3A69BF for ; Mon, 24 Jan 2011 16:19:00 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWfT-0003UD-AY; Mon, 24 Jan 2011 16:21:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:21:55 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:6 Message-ID: <071.65983ca30d23dd315c68da04961acb9e@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #19 (new): How large is the frame size depended delay / the serialization delay / frame size depended processing delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:19:00 -0000 #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? Comment(by gmaxwell@…): There was a large amount of interesting discussion on this subject, but I don't believe that any of it was moving in the direction of creating requirements language beyond narrowing our existing latency requirements. I believe there was ultimately no consensus to further narrow the latency requirements beyond what was established in the current requirements document and, accordingly, no further action is required on this particular ticket. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:37:46 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF1A3A6B39 for ; Mon, 24 Jan 2011 16:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 HvwoH3pXOujA for ; Mon, 24 Jan 2011 16:37:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 699FF3A6B05 for ; Mon, 24 Jan 2011 16:37:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhWxS-00028A-KY; Mon, 24 Jan 2011 16:40:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de, kpfleming@digium.com X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:40:30 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment:4 Message-ID: <071.a593fc9ae1e42af52489587fc97cf872@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jean-marc.valin@usherbrooke.ca, gmaxwell@juniper.net, hoene@uni-tuebingen.de, kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:37:46 -0000 #8: Sample rates? Comment(by gmaxwell@…): On 11-01-24 07:14 PM, Roman Shpount wrote: > I would like to see 8 and 16 KHz as required rates for the codec to insure > interoperability with existing narrowband and wideband codecs. In other > words we should be able to negotiate 8 or 16 Khz sample rate if audio will > be transcoded for PSTN or wideband codec such as G.722 Jean-Marc wrote: > I believe such requirement for narrowband/wideband is already present, but > I don't mind making it even more explicit is necessary. I believe that we since are close enough to finalizing the draft we should try to include proposed language with our issues. Otherwise there may be no clear path forward. Some of the requirements specify that compatibility with wideband/narrowband is important, but for the avoidance of doubt, I'll suggest: At the end of 4.1. Operating space: "Because interoperation with existing wideband and narrowband facilities is essential at least one method of interoperation must be provided regardless of the codec's operating mode, sample rate, or bitrate." Of course, I would be perfectly happy to leave this out entirely (as I believe the application section 2.1 already implies the requirement) or use some other language. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: jean-marc.valin@… Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:40:17 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F0B3A6B39 for ; Mon, 24 Jan 2011 16:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Rse4wVOSQtZp for ; Mon, 24 Jan 2011 16:40:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 47F9F3A6B05 for ; Mon, 24 Jan 2011 16:40:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhX04-0002Qz-CD; Mon, 24 Jan 2011 16:43:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:43:12 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/24#comment:2 Message-ID: <071.79466103d9fccf068fad63f78dbb68a5@tools.ietf.org> References: <062.6a10c93c1a05ea5f21f5afc0b48f2660@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <062.6a10c93c1a05ea5f21f5afc0b48f2660@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #24 (new): Negotiation of codec parameters? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:40:18 -0000 #24: Negotiation of codec parameters? Comment(by gmaxwell@…): Section 3. of draft-ietf-codec-requirements-02 provides: "If any codec parameters need to be negotiated between end-points, the negotiation should be as easy as possible to carry over SIP/SDP or alternatively over XMPP/Jingle." Is anything further required? -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: codec From trac@tools.ietf.org Mon Jan 24 16:42:16 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10DB3A6B3E for ; Mon, 24 Jan 2011 16:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 g3jYkXQ0IqIY for ; Mon, 24 Jan 2011 16:42:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 508B93A6B05 for ; Mon, 24 Jan 2011 16:42:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhX1z-0002dT-M9; Mon, 24 Jan 2011 16:45:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: gmaxwell@juniper.net X-Trac-Project: codec Date: Tue, 25 Jan 2011 00:45:11 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/12#comment:1 Message-ID: <071.de3a02a9da3e01eafb66a41ba319b0e6@tools.ietf.org> References: <062.8c126c3a81785b4856060d1e2a0914c8@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <062.8c126c3a81785b4856060d1e2a0914c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gmaxwell@juniper.net, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:42:16 -0000 #12: bit-exact vs. bit-compatible? Changes (by gmaxwell@…): * status: new => closed * resolution: => worksforme Comment: http://www.ietf.org/proceedings/78/minutes/codec.txt "On the topic of bit exact. Consensus was bit exactness is not required." I believe this issue is already closed. -- ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: codec From roman@telurix.com Mon Jan 24 17:05:01 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B977D3A6968 for ; Mon, 24 Jan 2011 17:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FauZVBCJqRg2 for ; Mon, 24 Jan 2011 17:05:00 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id ABD903A69DF for ; Mon, 24 Jan 2011 17:05:00 -0800 (PST) Received: by iwn40 with SMTP id 40so5064450iwn.31 for ; Mon, 24 Jan 2011 17:07:56 -0800 (PST) Received: by 10.42.170.138 with SMTP id f10mr5768588icz.269.1295917676454; Mon, 24 Jan 2011 17:07:56 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 8sm11471592iba.22.2011.01.24.17.07.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 17:07:55 -0800 (PST) Received: by iwn40 with SMTP id 40so5064425iwn.31 for ; Mon, 24 Jan 2011 17:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.35.1 with SMTP id n1mr5743812ibd.0.1295917674165; Mon, 24 Jan 2011 17:07:54 -0800 (PST) Received: by 10.231.167.132 with HTTP; Mon, 24 Jan 2011 17:07:54 -0800 (PST) In-Reply-To: <071.a593fc9ae1e42af52489587fc97cf872@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.a593fc9ae1e42af52489587fc97cf872@tools.ietf.org> Date: Mon, 24 Jan 2011 20:07:54 -0500 Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: multipart/alternative; boundary=002215046b87a0770d049aa1589f Cc: jean-marc.valin@usherbrooke.ca Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 25 Jan 2011 01:05:01 -0000 --002215046b87a0770d049aa1589f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I actually do believe that the requirement is already addressed by section 4.1 of the document. I was responding to a comment that only full band is required, which is clearly not what we agreed upon and not what's in the document. _____________ Roman Shpount On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker w= rote: > #8: Sample rates? > > > Comment(by gmaxwell@=85): > > On 11-01-24 07:14 PM, Roman Shpount wrote: > > I would like to see 8 and 16 KHz as required rates for the codec to > insure > > interoperability with existing narrowband and wideband codecs. In othe= r > > words we should be able to negotiate 8 or 16 Khz sample rate if audio > will > > be transcoded for PSTN or wideband codec such as G.722 > > Jean-Marc wrote: > > I believe such requirement for narrowband/wideband is already present, > but > > I don't mind making it even more explicit is necessary. > > > > I believe that we since are close enough to finalizing the draft we shou= ld > try to include proposed language with our issues. Otherwise there may b= e > no clear path forward. > > Some of the requirements specify that compatibility with > wideband/narrowband is important, but for the avoidance of doubt, I'll > suggest: > > At the end of 4.1. Operating space: > > "Because interoperation with existing wideband and narrowband facilities > is essential at least one method of interoperation must be provided > regardless of the codec's operating mode, sample rate, or bitrate." > > Of course, I would be perfectly happy to leave this out entirely (as I > believe the application section 2.1 already implies the requirement) or > use some other language. > > -- > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: jean-marc.valin@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --002215046b87a0770d049aa1589f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I actually do believe that the requirement is already addressed by section = 4.1 of the document. I was responding to a comment that only full band is r= equired, which is clearly not what we agreed upon and not what's in the= document.
_____________
Roman Shpount


On Mon, Jan 24, 2011 at 7:40 PM, codec i= ssue tracker <t= rac@tools.ietf.org> wrote:
#8: Sample rates?


Comment(by gmaxwell@=85):

=A0On 11-01-24 07:14 PM, Roman Shpount wrote:
=A0> I would like to see 8 and 16 KHz as required rates for the codec to=
=A0insure
=A0> interoperability with existing narrowband and wideband codecs. In o= ther
=A0> words we should be able to negotiate 8 or 16 Khz sample rate if aud= io
=A0will
=A0> be transcoded for PSTN or wideband codec such as G.722

=A0Jean-Marc wrote:
=A0> I believe such requirement for narrowband/wideband is already prese= nt,
=A0but
=A0> I don't mind making it even more explicit is necessary.



=A0I believe that we since are close enough to finalizing the draft w= e should
=A0try to include proposed language with our issues. =A0Otherwise there may= be
=A0no clear path forward.

=A0Some of the requirements specify that compatibility with
=A0wideband/narrowband is important, but for the avoidance of doubt, I'= ll
=A0suggest:

=A0At the end of 4.1. =A0Operating space:

=A0"Because interoperation with existing wideband and narrowband facil= ities
=A0is essential at least one method of interoperation must be provided
=A0regardless of the codec's operating mode, sample rate, or bitrate.&q= uot;

=A0Of course, I would be perfectly happy to leave this out entirely (as I =A0believe the application section 2.1 already implies the requirement) or<= br> =A0use some other language.

--
------------------------------------+--------------------= -------------------
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: =A0jean-marc.valin@=85
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/codec/tr= ac/ticket/8#comment:4>
codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org

--002215046b87a0770d049aa1589f-- From stewe@stewe.org Mon Jan 24 19:59:27 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5E23A6B6C for ; Mon, 24 Jan 2011 19:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 vIElawaFVyeL for ; Mon, 24 Jan 2011 19:59:26 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5CFCD3A6A16 for ; Mon, 24 Jan 2011 19:59:26 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 55441-1743317 for multiple; Tue, 25 Jan 2011 05:02:18 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 24 Jan 2011 20:02:12 -0800 From: Stephan Wenger To: , Message-ID: Thread-Topic: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? In-Reply-To: <071.de3a02a9da3e01eafb66a41ba319b0e6@tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 03:59:27 -0000 Hi all: Let me speak once more against this decision (if such a decision were really made; see the p.s.). There are currently three IPR disclosures against the codec draft and/or its predecessors. The Xiph disclosure is at this point a placeholder (Xiph folks: it's time to fix that!). However, the two other disclosures on file provide a patent grant only for necessary patent claims and only when the standard is practiced in full compliance. These terms (in various formulations) are quite common. In order to ensure one has a license (or can rely on a non-assert covenant), one has to ensure one meets the conditions set by the rightholder. On stuff such as reciprocity clauses this is simple. On compliance, it's not always easy. The traditional compliance test for a media codec is a stimulus-response test: you feed test vectors into the codec, and you get results. If the results match, you are in compliance, if not, you are not. Simple. Without bit exactness, the compliance criteria have to be defined differently. We can do so, and, indeed, I recall that this has been mentioned as one plan forward. However, I have seen zero activity in this direction, and I have also not seen any language that mentions this in the requirements draft. I think that the subject of compliance tests, at least in its most basic outline, needs to be documented in the requirements draft. The details can be taken care of elsewhere and later, but not too much later. It should be clear that a codec candidate (if there were more than one) needs to have compliance criteria defined before that codec candidate can become an RFC. Without that, the key goal of the WG, a reasonably freely practicable codec, is just not achievable in the current legal environment (which includes, in this case, the IPR disclosures on file). Of course, it would be sooooo much simpler if we would mandate a bit exact decoder... Is it really that restricting to require that? Stephan P.s.: for the IETF procedures newcomers: humms taken at meetings need to be confirmed on a mailing list, and consensus needs to be declared by the chairs. On this subject, I do recall mailing list discussions after Maastricht, but I do not recall that consensus was reached, yet alone declared. (Unfortunately, I currently don't have the time to go through the mailing list archives to verify my recollection; Sorry.) =20 On 1.24.2011 16:45 , "codec issue tracker" wrote: >#12: bit-exact vs. bit-compatible? > >Changes (by gmaxwell@=8A): > > * status: new =3D> closed > * resolution: =3D> worksforme > > >Comment: > > http://www.ietf.org/proceedings/78/minutes/codec.txt > > "On the topic of bit exact. Consensus was bit exactness is not required." > > I believe this issue is already closed. > >--=20 >------------------------------------+------------------------------------- >-- > Reporter: hoene@=8A | Owner: > Type: enhancement | Status: closed > Priority: minor | Milestone: >Component: requirements | Version: > Severity: Active WG Document | Resolution: worksforme > Keywords: | >------------------------------------+------------------------------------- >-- > >Ticket URL: >codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jmvalin@jmvalin.ca Mon Jan 24 21:01:07 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DA73A6B72 for ; Mon, 24 Jan 2011 21:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slqvO3qWs4Zf for ; Mon, 24 Jan 2011 21:01:05 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id B52E63A6A3D for ; Mon, 24 Jan 2011 21:01:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by vl-mo-mrz23.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LFK00KFGBE25NP0@vl-mo-mrz23.ip.videotron.ca> for codec@ietf.org; Tue, 25 Jan 2011 00:03:38 -0500 (EST) Message-id: <4D3E598A.3010200@jmvalin.ca> Date: Tue, 25 Jan 2011 00:03:06 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 To: Stephan Wenger References: In-reply-to: Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 05:01:07 -0000 Hi Stephan, I understand your concern and I'd be interested if you have alternative ways of handling the licensing to avoid any issue. It's not like this is a unique situation. As far as I know, most (all?) MPEG codecs have similar non-bit exact definitions. I have also heard that they also require some IPR licensing... In general the issue of bit-exactness has been discussed and so far I don't recall many arguing in favor of a bit-exact definition. Most of the concerns that have been expressed are solved by considering that non-bitexact does not mean you cannot be bit-exact with the reference encoder. It merely means that you don't *have* to. So regardless of how conformance is defined exactly, one always has the option of being bit-exact with the reference implementation, which obviously guarantees compliance. As for language mentioning compliance, I believe it belongs more to the guidelines (it's not a requirement of the codec itself), which includes the following text: 4. To reduce the risk of bias towards certain CPU/DSP architectures, ideally the decoder specification should not require "bit-exact" conformance with the reference implementation. The output of a decoder implementation should only be "close enough" to the output of the reference decoder. A comparison tool should be provided along with the codec to verify objectively that the output of a decoder is likely to be perceptually indistinguishable from that of the reference decoder. However, an implementation may still wish to produce an output that is bit-exact with the reference implementation to simplify the testing procedure. Cheers, Jean-Marc On 11-01-24 11:02 PM, Stephan Wenger wrote: > Hi all: > > Let me speak once more against this decision (if such a decision were > really made; see the p.s.). > > There are currently three IPR disclosures against the codec draft and/or > its predecessors. The Xiph disclosure is at this point a placeholder > (Xiph folks: it's time to fix that!). However, the two other disclosures > on file provide a patent grant only for necessary patent claims and only > when the standard is practiced in full compliance. These terms (in > various formulations) are quite common. > > In order to ensure one has a license (or can rely on a non-assert > covenant), one has to ensure one meets the conditions set by the > rightholder. On stuff such as reciprocity clauses this is simple. On > compliance, it's not always easy. > > The traditional compliance test for a media codec is a stimulus-response > test: you feed test vectors into the codec, and you get results. If the > results match, you are in compliance, if not, you are not. Simple. > > Without bit exactness, the compliance criteria have to be defined > differently. We can do so, and, indeed, I recall that this has been > mentioned as one plan forward. However, I have seen zero activity in this > direction, and I have also not seen any language that mentions this in the > requirements draft. I think that the subject of compliance tests, at > least in its most basic outline, needs to be documented in the > requirements draft. The details can be taken care of elsewhere and later, > but not too much later. It should be clear that a codec candidate (if > there were more than one) needs to have compliance criteria defined before > that codec candidate can become an RFC. Without that, the key goal of the > WG, a reasonably freely practicable codec, is just not achievable in the > current legal environment (which includes, in this case, the IPR > disclosures on file). > > Of course, it would be sooooo much simpler if we would mandate a bit exact > decoder... Is it really that restricting to require that? > > Stephan > > P.s.: for the IETF procedures newcomers: humms taken at meetings need to > be confirmed on a mailing list, and consensus needs to be declared by the > chairs. On this subject, I do recall mailing list discussions after > Maastricht, but I do not recall that consensus was reached, yet alone > declared. (Unfortunately, I currently don't have the time to go through > the mailing list archives to verify my recollection; Sorry.) > > > > On 1.24.2011 16:45 , "codec issue tracker" wrote: > >> #12: bit-exact vs. bit-compatible? >> >> Changes (by gmaxwell@Š): >> >> * status: new => closed >> * resolution: => worksforme >> >> >> Comment: >> >> http://www.ietf.org/proceedings/78/minutes/codec.txt >> >> "On the topic of bit exact. Consensus was bit exactness is not required." >> >> I believe this issue is already closed. >> >> -- >> ------------------------------------+------------------------------------- >> -- >> Reporter: hoene@Š | Owner: >> Type: enhancement | Status: closed >> Priority: minor | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Resolution: worksforme >> Keywords: | >> ------------------------------------+------------------------------------- >> -- >> >> Ticket URL: >> 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 john.elwell@siemens-enterprise.com Tue Jan 25 01:59:15 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFE53A69E1 for ; Tue, 25 Jan 2011 01:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ni0EYwh9H3Bm for ; Tue, 25 Jan 2011 01:59:11 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BB4E93A6990 for ; Tue, 25 Jan 2011 01:59:10 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3129979; Tue, 25 Jan 2011 11:02:06 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 2B1A91EB82AB; Tue, 25 Jan 2011 11:02:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 Jan 2011 11:02:06 +0100 From: "Elwell, John" To: Mary Barnes , Jean-Marc Valin Date: Tue, 25 Jan 2011 11:02:04 +0100 Thread-Topic: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 Thread-Index: Acu8Hd6NT2qpN+UISMOKgvHy2Cf4qgAVNxOA Message-ID: References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" , Stephen Botzko Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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, 25 Jan 2011 09:59:15 -0000 Mary, I am confused which document we are talking about. The subject indicates th= e requirements document, but your quoted text "suggested process" seems to = come from the guidelines document. The situation with the requirements document (draft-ietf-codec-requirements= -02) is that it is intended as Standards Track but contains no RFC 2119 lan= guage (as far as I can see, e.g., no "MUST" statements, and no reference to= RFC 2119). I think it should indeed be Informational, but this does not prevent us hav= ing normative statements in which the codec specification that this WG prod= uces is the subject, e.g., "The codec MUST ..." This would make it much eas= ier to pick out the actual requirements and to measure the resulting codec = specification against those requirements. Some WGs adopt the practice of nu= mbering requirements, for easy reference. John > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]=20 > On Behalf Of Mary Barnes > Sent: 24 January 2011 23:25 > To: Jean-Marc Valin > Cc: codec@ietf.org; Stephen Botzko > Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 >=20 > The document is currently specified as Standards Track, thus=20 > the use of RFC 2119 language is entirely appropriate. =20 > However, ISTM that the document should really just be=20 > Informational, in particular given the language in the=20 > introduction that this document defines a "suggested=20 > process", as opposed to a process that is required for codec=20 > development. =20 >=20 >=20 > Regards, > Mary. >=20 >=20 > On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin=20 > wrote: >=20 >=20 > Christian, > =09 > I actually responded to the last comments you made a=20 > while ago (oct 2010). One issue I pointed out was your use of=20 > RFC2119 keywords, which (AFAIK) aren't appropriate for a=20 > requirements draft (the requirements aren't a standard). So=20 > statements like "Any codec specified by the IETF MUST be well=20 > specified", besides stating the obvious, are inappropriate. > =09 > There were also comments that just did not belong to=20 > this draft, such as the section on collaboration with other=20 > WGs. Collaboration is not a characteristic of a codec. So=20 > essentially, I merged the uncontroversial suggestion, but=20 > that's all I could do. As far as I'm aware, there's nothing=20 > in the current draft that goes against the consensus of the=20 > WG. If there are, please point to specific issues and to=20 > statements made by others (not just you) asking for the change. > =09 > Cheers, > =09 > Jean-Marc=20 >=20 >=20 > On 11-01-24 03:10 PM, Christian Hoene wrote: > =09 >=20 > Christian - perhaps you could post a list of=20 > the issues you see that > haven't been addressed? > =09 > */[Christian Hoene] No Stephen, these issues=20 > have been written down in > previous emails, drafts and issues in the Trac.=20 > They can be read by anybody > anytime. Thus, I do not see any benefit of=20 > repeating them again if the > editors continue to ignore any input. Indeed,=20 > they did not improve the > draft despite sound technical reasons. /* > =09 > */Even if somebody is not fully involved in the=20 > technical details: It is > very odd that despite many hundreds emails and=20 > many discussions since > starting this WG the editors have not updated=20 > the draft beside minor > changes such as the boilerplate and typos. /* > =09 > */Even if the lack of any update was not=20 > intentionally, the editors missed > to do their job because they were too lazy or=20 > rather too busy doing other > thinks./* > =09 > */I would be sad if all the fruitful=20 > discussions here and all the good > contributions of many industry experts should=20 > have been in vain. Even if > not all requirements can be met by Opus, a=20 > proper requirements document may > be relevant for future solutions or other SDOs./* > =09 > =09 > */CH/*=20 >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =09 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =09 >=20 >=20 > = From hoene@uni-tuebingen.de Tue Jan 25 05:09:59 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E5C28C0D7 for ; Tue, 25 Jan 2011 05:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEmTXztKAiBu for ; Tue, 25 Jan 2011 05:09:58 -0800 (PST) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id F083A3A6BBA for ; Tue, 25 Jan 2011 05:09:57 -0800 (PST) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p0PDCrfM030716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jan 2011 14:12:53 +0100 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> In-Reply-To: <4D3E0676.1040704@octasic.com> Date: Tue, 25 Jan 2011 14:12:54 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <007d01cbbc91$94552940$bcff7bc0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWDjsml9J24OP+D1jOWj/YeoWjlgHEh91YAdiRriACNmo0KALda5Fakwd9JfA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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, 25 Jan 2011 13:09:59 -0000 Hi Jean-Marc Valin, you are referring to the changes in the guideline doc? Thank you for considering my comments from October last year. I have to admit that I have not read the latest version of the guidelines document so far. I will give you updated comments (with any) well before the next deadline. With best regards, Christian > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Tuesday, January 25, 2011 12:09 AM > To: Christian Hoene > Cc: 'Stephen Botzko'; codec@ietf.org > Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 > > Christian, > > I actually responded to the last comments you made a while ago (oct 2010). > One issue I pointed out was your use of RFC2119 keywords, which (AFAIK) > aren't appropriate for a requirements draft (the requirements aren't a > standard). So statements like "Any codec specified by the IETF MUST be well > specified", besides stating the obvious, are inappropriate. > > There were also comments that just did not belong to this draft, such as the > section on collaboration with other WGs. Collaboration is not a characteristic > of a codec. So essentially, I merged the uncontroversial suggestion, but that's > all I could do. As far as I'm aware, there's nothing in the current draft that > goes against the consensus of the WG. If there are, please point to specific > issues and to statements made by others (not just you) asking for the > change. > > Cheers, > > Jean-Marc > > On 11-01-24 03:10 PM, Christian Hoene wrote: > > Christian - perhaps you could post a list of the issues you see that > > haven't been addressed? > > > > */[Christian Hoene] No Stephen, these issues have been written down in > > previous emails, drafts and issues in the Trac. They can be read by > > anybody anytime. Thus, I do not see any benefit of repeating them > > again if the editors continue to ignore any input. Indeed, they did > > not improve the draft despite sound technical reasons. /* > > > > */Even if somebody is not fully involved in the technical details: It > > is very odd that despite many hundreds emails and many discussions > > since starting this WG the editors have not updated the draft beside > > minor changes such as the boilerplate and typos. /* > > > > */Even if the lack of any update was not intentionally, the editors > > missed to do their job because they were too lazy or rather too busy > > doing other > > thinks./* > > > > */I would be sad if all the fruitful discussions here and all the good > > contributions of many industry experts should have been in vain. Even > > if not all requirements can be met by Opus, a proper requirements > > document may be relevant for future solutions or other SDOs./* > > > > */CH/* > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec From roman@telurix.com Tue Jan 25 06:31:37 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD213A67E5 for ; Tue, 25 Jan 2011 06:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5hQgjLKH-9k for ; Tue, 25 Jan 2011 06:31:36 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C68F13A67E3 for ; Tue, 25 Jan 2011 06:31:35 -0800 (PST) Received: by iwn40 with SMTP id 40so5725175iwn.31 for ; Tue, 25 Jan 2011 06:34:33 -0800 (PST) Received: by 10.231.17.4 with SMTP id q4mr6643530iba.13.1295966073205; Tue, 25 Jan 2011 06:34:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z4sm12023335ibg.7.2011.01.25.06.34.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 06:34:32 -0800 (PST) Received: by iyi42 with SMTP id 42so5712394iyi.31 for ; Tue, 25 Jan 2011 06:34:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.199.19 with SMTP id eq19mr6651319ibb.175.1295966070969; Tue, 25 Jan 2011 06:34:30 -0800 (PST) Received: by 10.231.167.132 with HTTP; Tue, 25 Jan 2011 06:34:30 -0800 (PST) In-Reply-To: <4D3E598A.3010200@jmvalin.ca> References: <4D3E598A.3010200@jmvalin.ca> Date: Tue, 25 Jan 2011 09:34:30 -0500 Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=90e6ba53a6ae4d190e049aac9d25 Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 14:31:37 -0000 --90e6ba53a6ae4d190e049aac9d25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One more concern that I have related to bit exactness is codec regression testing. One can produce a non-bit-exact encoder that produces reasonable results for a reference decoder, but if paired with a modified, non-bit-exact decoder will produce significant audio artifacts. Since neither decoder or encoder are bit exact we will need to have a test procedure that will validate that both encoder or decoder will not break an= y standard compliant and non-bit-exact encoders or decoders. Not really sure how this can be done. I might be wrong, but I think MPEG decoders are bit exact and encoders are not. _____________ Roman Shpount On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin wrote= : > Hi Stephan, > > I understand your concern and I'd be interested if you have alternative > ways of handling the licensing to avoid any issue. It's not like this is = a > unique situation. As far as I know, most (all?) MPEG codecs have similar > non-bit exact definitions. I have also heard that they also require some = IPR > licensing... > > In general the issue of bit-exactness has been discussed and so far I don= 't > recall many arguing in favor of a bit-exact definition. Most of the conce= rns > that have been expressed are solved by considering that non-bitexact does > not mean you cannot be bit-exact with the reference encoder. It merely me= ans > that you don't *have* to. So regardless of how conformance is defined > exactly, one always has the option of being bit-exact with the reference > implementation, which obviously guarantees compliance. > > As for language mentioning compliance, I believe it belongs more to the > guidelines (it's not a requirement of the codec itself), which includes t= he > following text: > > 4. To reduce the risk of bias towards certain CPU/DSP architectures, > ideally the decoder specification should not require "bit-exact" > conformance with the reference implementation. The output of a > decoder implementation should only be "close enough" to the > output of the reference decoder. A comparison tool should be > provided along with the codec to verify objectively that the > output of a decoder is likely to be perceptually > indistinguishable from that of the reference decoder. However, > an implementation may still wish to produce an output that is > bit-exact with the reference implementation to simplify the > testing procedure. > > > > Cheers, > > Jean-Marc > > > On 11-01-24 11:02 PM, Stephan Wenger wrote: > >> Hi all: >> >> Let me speak once more against this decision (if such a decision were >> really made; see the p.s.). >> >> There are currently three IPR disclosures against the codec draft and/or >> its predecessors. The Xiph disclosure is at this point a placeholder >> (Xiph folks: it's time to fix that!). However, the two other disclosure= s >> on file provide a patent grant only for necessary patent claims and only >> when the standard is practiced in full compliance. These terms (in >> various formulations) are quite common. >> >> In order to ensure one has a license (or can rely on a non-assert >> covenant), one has to ensure one meets the conditions set by the >> rightholder. On stuff such as reciprocity clauses this is simple. On >> compliance, it's not always easy. >> >> The traditional compliance test for a media codec is a stimulus-response >> test: you feed test vectors into the codec, and you get results. If the >> results match, you are in compliance, if not, you are not. Simple. >> >> Without bit exactness, the compliance criteria have to be defined >> differently. We can do so, and, indeed, I recall that this has been >> mentioned as one plan forward. However, I have seen zero activity in th= is >> direction, and I have also not seen any language that mentions this in t= he >> requirements draft. I think that the subject of compliance tests, at >> least in its most basic outline, needs to be documented in the >> requirements draft. The details can be taken care of elsewhere and late= r, >> but not too much later. It should be clear that a codec candidate (if >> there were more than one) needs to have compliance criteria defined befo= re >> that codec candidate can become an RFC. Without that, the key goal of t= he >> WG, a reasonably freely practicable codec, is just not achievable in the >> current legal environment (which includes, in this case, the IPR >> disclosures on file). >> >> Of course, it would be sooooo much simpler if we would mandate a bit exa= ct >> decoder... Is it really that restricting to require that? >> >> Stephan >> >> P.s.: for the IETF procedures newcomers: humms taken at meetings need to >> be confirmed on a mailing list, and consensus needs to be declared by th= e >> chairs. On this subject, I do recall mailing list discussions after >> Maastricht, but I do not recall that consensus was reached, yet alone >> declared. (Unfortunately, I currently don't have the time to go through >> the mailing list archives to verify my recollection; Sorry.) >> >> >> >> On 1.24.2011 16:45 , "codec issue tracker" wrote: >> >> #12: bit-exact vs. bit-compatible? >>> >>> Changes (by gmaxwell@=C5=A0): >>> >>> * status: new =3D> closed >>> * resolution: =3D> worksforme >>> >>> >>> Comment: >>> >>> http://www.ietf.org/proceedings/78/minutes/codec.txt >>> >>> "On the topic of bit exact. Consensus was bit exactness is not required= ." >>> >>> I believe this issue is already closed. >>> >>> -- >>> >>> ------------------------------------+----------------------------------= --- >>> -- >>> Reporter: hoene@=C5=A0 | Owner: >>> Type: enhancement | Status: closed >>> Priority: minor | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Resolution: worksforme >>> Keywords: | >>> >>> ------------------------------------+----------------------------------= --- >>> -- >>> >>> Ticket URL:>> > >>> codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --90e6ba53a6ae4d190e049aac9d25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One more concern that I have related to bit exactness is codec regression t= esting. One can produce a non-bit-exact encoder that produces reasonable re= sults for a reference decoder, but if paired with a modified, non-bit-exact= decoder will produce significant audio artifacts. Since neither decoder or= encoder are bit exact we will need to have a test procedure that will vali= date that both encoder or decoder will not break any standard compliant and= non-bit-exact encoders or decoders. Not really sure how this can be done.<= div>
I might be wrong, but I think MPEG decoders are bit exact an= d encoders are not.
_____________
Roman Shpount


On Tue, Jan 25, 2011 at 12:03 AM, Jean-M= arc Valin <jmval= in@jmvalin.ca> wrote:
Hi Stephan,

I understand your concern and I'd be interested if you have alternative= ways of handling the licensing to avoid any issue. It's not like this = is a unique situation. As far as I know, most (all?) MPEG codecs have simil= ar non-bit exact definitions. I have also heard that they also require some= IPR licensing...

In general the issue of bit-exactness has been discussed and so far I don&#= 39;t recall many arguing in favor of a bit-exact definition. Most of the co= ncerns that have been expressed are solved by considering that non-bitexact= does not mean you cannot be bit-exact with the reference encoder. It merel= y means that you don't *have* to. So regardless of how conformance is d= efined exactly, one always has the option of being bit-exact with the refer= ence implementation, which obviously guarantees compliance.

As for language mentioning compliance, I believe it belongs more to the gui= delines (it's not a requirement of the codec itself), which includes th= e following text:

=C2=A0 4. =C2=A0To reduce the risk of bias towards certain CPU/DSP archite= ctures,
=C2=A0 =C2=A0 =C2=A0 ideally the decoder specification should not require = "bit-exact"
=C2=A0 =C2=A0 =C2=A0 conformance with the reference implementation. =C2=A0= The output of a
=C2=A0 =C2=A0 =C2=A0 decoder implementation should only be "close eno= ugh" to the
=C2=A0 =C2=A0 =C2=A0 output of the reference decoder. =C2=A0A comparison t= ool should be
=C2=A0 =C2=A0 =C2=A0 provided along with the codec to verify objectively t= hat the
=C2=A0 =C2=A0 =C2=A0 output of a decoder is likely to be perceptually
=C2=A0 =C2=A0 =C2=A0 indistinguishable from that of the reference decoder.= =C2=A0However,
=C2=A0 =C2=A0 =C2=A0 an implementation may still wish to produce an output= that is
=C2=A0 =C2=A0 =C2=A0 bit-exact with the reference implementation to simpli= fy the
=C2=A0 =C2=A0 =C2=A0 testing procedure.



Cheers,

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


On 11-01-24 11:02 PM, Stephan Wenger wrote:
Hi all:

Let me speak once more against this decision (if such a decision were
really made; see the p.s.).

There are currently three IPR disclosures against the codec draft and/or its predecessors. =C2=A0The Xiph disclosure is at this point a placeholder<= br> (Xiph folks: it's time to fix that!). =C2=A0However, the two other disc= losures
on file provide a patent grant only for necessary patent claims and only when the standard is practiced in full compliance. =C2=A0These terms (in various formulations) are quite common.

In order to ensure one has a license (or can rely on a non-assert
covenant), one has to ensure one meets the conditions set by the
rightholder. =C2=A0On stuff such as reciprocity clauses this is simple. =C2= =A0On
compliance, it's not always easy.

The traditional compliance test for a media codec is a stimulus-response test: you feed test vectors into the codec, and you get results. =C2=A0If t= he
results match, you are in compliance, if not, you are not. =C2=A0Simple.
Without bit exactness, the compliance criteria have to be defined
differently. =C2=A0We can do so, and, indeed, I recall that this has been mentioned as one plan forward. =C2=A0However, I have seen zero activity in = this
direction, and I have also not seen any language that mentions this in the<= br> requirements draft. =C2=A0I think that the subject of compliance tests, at<= br> least in its most basic outline, needs to be documented in the
requirements draft. =C2=A0The details can be taken care of elsewhere and la= ter,
but not too much later. =C2=A0It should be clear that a codec candidate (if=
there were more than one) needs to have compliance criteria defined before<= br> that codec candidate can become an RFC. =C2=A0Without that, the key goal of= the
WG, a reasonably freely practicable codec, is just not achievable in the current legal environment (which includes, in this case, the IPR
disclosures on file).

Of course, it would be sooooo much simpler if we would mandate a bit exact<= br> decoder... =C2=A0Is it really that restricting to require that?

Stephan

P.s.: for the IETF procedures newcomers: humms taken at meetings need to be confirmed on a mailing list, and consensus needs to be declared by the chairs. =C2=A0On this subject, I do recall mailing list discussions after Maastricht, but I do not recall that consensus was reached, yet alone
declared. =C2=A0(Unfortunately, I currently don't have the time to go t= hrough
the mailing list archives to verify my recollection; Sorry.)



On 1.24.2011 16:45 , "codec issue tracker"<trac@tools.ietf.org> =C2=A0wro= te:

#12: bit-exact vs. bit-compatible?

Changes (by gmaxwell@=C5=A0):

=C2=A0* status: =C2=A0new =3D> =C2=A0closed
=C2=A0* resolution: =C2=A0=3D> =C2=A0worksforme


Comment:

http://www.ietf.org/proceedings/78/minutes/codec.txt

"On the topic of bit exact. Consensus was bit exactness is not require= d."

I believe this issue is already closed.

--
------------------------------------+-------------------------------------<= br> --
Reporter: =C2=A0hoene@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0Owner:
=C2=A0 =C2=A0 Type: =C2=A0enhancement =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Status: =C2=A0closed
Priority: =C2=A0minor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0Milestone:
Component: =C2=A0requirements =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0Version:
Severity: =C2=A0Active WG Document =C2=A0 =C2=A0 =C2=A0| =C2=A0 Resolution:= =C2=A0worksforme
Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
------------------------------------+-------------------------------------<= br> --

Ticket URL:<http://trac.tools.ietf.org/wg/codec/trac/tic= ket/12#comment:1>
codec<http://= tools.ietf.org/codec/>

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


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


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

--90e6ba53a6ae4d190e049aac9d25-- From stephen.botzko@gmail.com Tue Jan 25 07:39:05 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD05A3A67EA for ; Tue, 25 Jan 2011 07:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRWCUGpMe+6m for ; Tue, 25 Jan 2011 07:39:04 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 0066A3A67EC for ; Tue, 25 Jan 2011 07:39:03 -0800 (PST) Received: by qyk34 with SMTP id 34so4287841qyk.10 for ; Tue, 25 Jan 2011 07:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uqRb9xrUV8sk44PfCMp0Qwwwx+b+m4z5xzhXx7rJQNA=; b=FyyR5cMoIYCQLu1aTF08wsilAeJ5iz2ovYjXUV+ih2uOSdH78NoUjRwdsBo0MrSHI4 rpOirpF/tPuqprj27V0y6h723LeNsIKIUFymyaTqgUd5AOT+miN21glmCYqxB+eepSgx p7mb8lewmaKlwQ8ayytRwfHR9rYmkiwnj7aV8= 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=cpUIlngo+kiBEauatnw4/NSd101JH6ulq6gj0VIuDfF2V8xrWj3sE2AYpYhJF9gxoU OUThYa5Mtwenn4e/1MdwSsM5AbbHhvD5SUzADSuBGOWVqB/PUGbuYnASyuhmgYMgZCH0 AqnnoBTYc5KOKZSQfKBAsq1liaFGO8EeyQYzw= MIME-Version: 1.0 Received: by 10.224.20.4 with SMTP id d4mr5386121qab.345.1295970120141; Tue, 25 Jan 2011 07:42:00 -0800 (PST) Received: by 10.220.128.30 with HTTP; Tue, 25 Jan 2011 07:42:00 -0800 (PST) In-Reply-To: References: <4D3E598A.3010200@jmvalin.ca> Date: Tue, 25 Jan 2011 10:42:00 -0500 Message-ID: From: Stephen Botzko To: Roman Shpount Content-Type: multipart/alternative; boundary=0015175cda2ca68edd049aad8ec4 Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 15:39:06 -0000 --0015175cda2ca68edd049aad8ec4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems to me that the reference encoder and decoder will be bit exact for a given floating point format, correct? So one could specify IEEE 754-2008 when bit exactness is needed in the reference (for instance regression testing), but not require it for compliance. Folks who are modifying the reference encoder or decoder algorithms are "on their own" as far as audio quality is concerned. Though I agree with Stephan that we need to address compliance (when exactly does a ported or otherwise modified encoder/decoder become non-compliant?). Stephen Botzko On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount wrote: > One more concern that I have related to bit exactness is codec regression > testing. One can produce a non-bit-exact encoder that produces reasonable > results for a reference decoder, but if paired with a modified, > non-bit-exact decoder will produce significant audio artifacts. Since > neither decoder or encoder are bit exact we will need to have a test > procedure that will validate that both encoder or decoder will not break = any > standard compliant and non-bit-exact encoders or decoders. Not really sur= e > how this can be done. > > I might be wrong, but I think MPEG decoders are bit exact and encoders ar= e > not. > _____________ > Roman Shpount > > > > On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin wro= te: > >> Hi Stephan, >> >> I understand your concern and I'd be interested if you have alternative >> ways of handling the licensing to avoid any issue. It's not like this is= a >> unique situation. As far as I know, most (all?) MPEG codecs have similar >> non-bit exact definitions. I have also heard that they also require some= IPR >> licensing... >> >> In general the issue of bit-exactness has been discussed and so far I >> don't recall many arguing in favor of a bit-exact definition. Most of th= e >> concerns that have been expressed are solved by considering that >> non-bitexact does not mean you cannot be bit-exact with the reference >> encoder. It merely means that you don't *have* to. So regardless of how >> conformance is defined exactly, one always has the option of being bit-e= xact >> with the reference implementation, which obviously guarantees compliance= . >> >> As for language mentioning compliance, I believe it belongs more to the >> guidelines (it's not a requirement of the codec itself), which includes = the >> following text: >> >> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >> ideally the decoder specification should not require "bit-exact" >> conformance with the reference implementation. The output of a >> decoder implementation should only be "close enough" to the >> output of the reference decoder. A comparison tool should be >> provided along with the codec to verify objectively that the >> output of a decoder is likely to be perceptually >> indistinguishable from that of the reference decoder. However, >> an implementation may still wish to produce an output that is >> bit-exact with the reference implementation to simplify the >> testing procedure. >> >> >> >> Cheers, >> >> Jean-Marc >> >> >> On 11-01-24 11:02 PM, Stephan Wenger wrote: >> >>> Hi all: >>> >>> Let me speak once more against this decision (if such a decision were >>> really made; see the p.s.). >>> >>> There are currently three IPR disclosures against the codec draft and/o= r >>> its predecessors. The Xiph disclosure is at this point a placeholder >>> (Xiph folks: it's time to fix that!). However, the two other disclosur= es >>> on file provide a patent grant only for necessary patent claims and onl= y >>> when the standard is practiced in full compliance. These terms (in >>> various formulations) are quite common. >>> >>> In order to ensure one has a license (or can rely on a non-assert >>> covenant), one has to ensure one meets the conditions set by the >>> rightholder. On stuff such as reciprocity clauses this is simple. On >>> compliance, it's not always easy. >>> >>> The traditional compliance test for a media codec is a stimulus-respons= e >>> test: you feed test vectors into the codec, and you get results. If th= e >>> results match, you are in compliance, if not, you are not. Simple. >>> >>> Without bit exactness, the compliance criteria have to be defined >>> differently. We can do so, and, indeed, I recall that this has been >>> mentioned as one plan forward. However, I have seen zero activity in >>> this >>> direction, and I have also not seen any language that mentions this in >>> the >>> requirements draft. I think that the subject of compliance tests, at >>> least in its most basic outline, needs to be documented in the >>> requirements draft. The details can be taken care of elsewhere and >>> later, >>> but not too much later. It should be clear that a codec candidate (if >>> there were more than one) needs to have compliance criteria defined >>> before >>> that codec candidate can become an RFC. Without that, the key goal of >>> the >>> WG, a reasonably freely practicable codec, is just not achievable in th= e >>> current legal environment (which includes, in this case, the IPR >>> disclosures on file). >>> >>> Of course, it would be sooooo much simpler if we would mandate a bit >>> exact >>> decoder... Is it really that restricting to require that? >>> >>> Stephan >>> >>> P.s.: for the IETF procedures newcomers: humms taken at meetings need t= o >>> be confirmed on a mailing list, and consensus needs to be declared by t= he >>> chairs. On this subject, I do recall mailing list discussions after >>> Maastricht, but I do not recall that consensus was reached, yet alone >>> declared. (Unfortunately, I currently don't have the time to go throug= h >>> the mailing list archives to verify my recollection; Sorry.) >>> >>> >>> >>> On 1.24.2011 16:45 , "codec issue tracker" wrote: >>> >>> #12: bit-exact vs. bit-compatible? >>>> >>>> Changes (by gmaxwell@=C5=A0): >>>> >>>> * status: new =3D> closed >>>> * resolution: =3D> worksforme >>>> >>>> >>>> Comment: >>>> >>>> http://www.ietf.org/proceedings/78/minutes/codec.txt >>>> >>>> "On the topic of bit exact. Consensus was bit exactness is not >>>> required." >>>> >>>> I believe this issue is already closed. >>>> >>>> -- >>>> >>>> ------------------------------------+---------------------------------= ---- >>>> -- >>>> Reporter: hoene@=C5=A0 | Owner: >>>> Type: enhancement | Status: closed >>>> Priority: minor | Milestone: >>>> Component: requirements | Version: >>>> Severity: Active WG Document | Resolution: worksforme >>>> Keywords: | >>>> >>>> ------------------------------------+---------------------------------= ---- >>>> -- >>>> >>>> Ticket URL:< >>>> http://trac.tools.ietf.org/wg/codec/trac/ticket/12#comment:1> >>>> codec >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0015175cda2ca68edd049aad8ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems to me that the reference encoder and decoder will be bit exact for= a given floating point format, correct?=C2=A0 So one could specify IEEE 75= 4-2008 when bit exactness is needed in the reference (for instance regressi= on testing), but not require it for compliance.

Folks who are modifying the reference encoder or decoder algorithms are= "on their own" as far as audio quality is concerned.=C2=A0 Thoug= h I agree with Stephan that we need to address compliance (when exactly doe= s a ported or otherwise modified encoder/decoder become non-compliant?).
Stephen Botzko

On Tue, Jan 25, 2011 a= t 9:34 AM, Roman Shpount <roman@telurix.com> wrote:
One more concern that I have related to bit exactness is codec regression t= esting. One can produce a non-bit-exact encoder that produces reasonable re= sults for a reference decoder, but if paired with a modified, non-bit-exact= decoder will produce significant audio artifacts. Since neither decoder or= encoder are bit exact we will need to have a test procedure that will vali= date that both encoder or decoder will not break any standard compliant and= non-bit-exact encoders or decoders. Not really sure how this can be done.<= div>
I might be wrong, but I think MPEG decoders are bit exact an= d encoders are not.
_____________
Roman Shpount



On Tue, Jan 25, 2011 at 12:03 AM, Jean-M= arc Valin <jmvalin@jmvalin.ca> wrote:
Hi Stephan,

I understand your concern and I'd be interested if you have alternative= ways of handling the licensing to avoid any issue. It's not like this = is a unique situation. As far as I know, most (all?) MPEG codecs have simil= ar non-bit exact definitions. I have also heard that they also require some= IPR licensing...

In general the issue of bit-exactness has been discussed and so far I don&#= 39;t recall many arguing in favor of a bit-exact definition. Most of the co= ncerns that have been expressed are solved by considering that non-bitexact= does not mean you cannot be bit-exact with the reference encoder. It merel= y means that you don't *have* to. So regardless of how conformance is d= efined exactly, one always has the option of being bit-exact with the refer= ence implementation, which obviously guarantees compliance.

As for language mentioning compliance, I believe it belongs more to the gui= delines (it's not a requirement of the codec itself), which includes th= e following text:

=C2=A0 4. =C2=A0To reduce the risk of bias towards certain CPU/DSP archite= ctures,
=C2=A0 =C2=A0 =C2=A0 ideally the decoder specification should not require = "bit-exact"
=C2=A0 =C2=A0 =C2=A0 conformance with the reference implementation. =C2=A0= The output of a
=C2=A0 =C2=A0 =C2=A0 decoder implementation should only be "close eno= ugh" to the
=C2=A0 =C2=A0 =C2=A0 output of the reference decoder. =C2=A0A comparison t= ool should be
=C2=A0 =C2=A0 =C2=A0 provided along with the codec to verify objectively t= hat the
=C2=A0 =C2=A0 =C2=A0 output of a decoder is likely to be perceptually
=C2=A0 =C2=A0 =C2=A0 indistinguishable from that of the reference decoder.= =C2=A0However,
=C2=A0 =C2=A0 =C2=A0 an implementation may still wish to produce an output= that is
=C2=A0 =C2=A0 =C2=A0 bit-exact with the reference implementation to simpli= fy the
=C2=A0 =C2=A0 =C2=A0 testing procedure.



Cheers,

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


On 11-01-24 11:02 PM, Stephan Wenger wrote:
Hi all:

Let me speak once more against this decision (if such a decision were
really made; see the p.s.).

There are currently three IPR disclosures against the codec draft and/or its predecessors. =C2=A0The Xiph disclosure is at this point a placeholder<= br> (Xiph folks: it's time to fix that!). =C2=A0However, the two other disc= losures
on file provide a patent grant only for necessary patent claims and only when the standard is practiced in full compliance. =C2=A0These terms (in various formulations) are quite common.

In order to ensure one has a license (or can rely on a non-assert
covenant), one has to ensure one meets the conditions set by the
rightholder. =C2=A0On stuff such as reciprocity clauses this is simple. =C2= =A0On
compliance, it's not always easy.

The traditional compliance test for a media codec is a stimulus-response test: you feed test vectors into the codec, and you get results. =C2=A0If t= he
results match, you are in compliance, if not, you are not. =C2=A0Simple.
Without bit exactness, the compliance criteria have to be defined
differently. =C2=A0We can do so, and, indeed, I recall that this has been mentioned as one plan forward. =C2=A0However, I have seen zero activity in = this
direction, and I have also not seen any language that mentions this in the<= br> requirements draft. =C2=A0I think that the subject of compliance tests, at<= br> least in its most basic outline, needs to be documented in the
requirements draft. =C2=A0The details can be taken care of elsewhere and la= ter,
but not too much later. =C2=A0It should be clear that a codec candidate (if=
there were more than one) needs to have compliance criteria defined before<= br> that codec candidate can become an RFC. =C2=A0Without that, the key goal of= the
WG, a reasonably freely practicable codec, is just not achievable in the current legal environment (which includes, in this case, the IPR
disclosures on file).

Of course, it would be sooooo much simpler if we would mandate a bit exact<= br> decoder... =C2=A0Is it really that restricting to require that?

Stephan

P.s.: for the IETF procedures newcomers: humms taken at meetings need to be confirmed on a mailing list, and consensus needs to be declared by the chairs. =C2=A0On this subject, I do recall mailing list discussions after Maastricht, but I do not recall that consensus was reached, yet alone
declared. =C2=A0(Unfortunately, I currently don't have the time to go t= hrough
the mailing list archives to verify my recollection; Sorry.)



On 1.24.2011 16:45 , "codec issue tracker"<trac@tools.ietf.org> =C2=A0wro= te:

#12: bit-exact vs. bit-compatible?

Changes (by gmaxwell@=C5=A0):

=C2=A0* status: =C2=A0new =3D> =C2=A0closed
=C2=A0* resolution: =C2=A0=3D> =C2=A0worksforme


Comment:

http://www.ietf.org/proceedings/78/minutes/codec.txt

"On the topic of bit exact. Consensus was bit exactness is not require= d."

I believe this issue is already closed.

--
------------------------------------+-------------------------------------<= br> --
Reporter: =C2=A0hoene@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0Owner:
=C2=A0 =C2=A0 Type: =C2=A0enhancement =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Status: =C2=A0closed
Priority: =C2=A0minor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0Milestone:
Component: =C2=A0requirements =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0Version:
Severity: =C2=A0Active WG Document =C2=A0 =C2=A0 =C2=A0| =C2=A0 Resolution:= =C2=A0worksforme
Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
------------------------------------+-------------------------------------<= br> --

Ticket URL:<http://trac.tools.ietf.org/wg/codec/trac/tic= ket/12#comment:1>
codec<http://= tools.ietf.org/codec/>

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


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


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


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


--0015175cda2ca68edd049aad8ec4-- From jean-marc.valin@octasic.com Tue Jan 25 07:42:31 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB923A680F for ; Tue, 25 Jan 2011 07:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93WVec2WIe5r for ; Tue, 25 Jan 2011 07:42:30 -0800 (PST) Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07-srv.bellnexxia.net [207.236.237.41]) by core3.amsl.com (Postfix) with ESMTP id 2CA823A680D for ; Tue, 25 Jan 2011 07:42:30 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110125154527.INVJ3521.toroondcbmts07-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Tue, 25 Jan 2011 10:45:27 -0500 Received: from toip38-bus.srvr.bell.ca ([67.69.240.39]) by toip58-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 10:45:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANN2Pk3PPaAN/2dsb2JhbACkbnO9AIVPBIUXilcG Received: from mail.octasic.com ([207.61.160.13]) by toip38-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 10:45:19 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Jan 2011 10:45:19 -0500 Message-ID: <4D3EF00E.2080601@octasic.com> Date: Tue, 25 Jan 2011 10:45:18 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roman Shpount References: <4D3E598A.3010200@jmvalin.ca> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 15:42:31 -0000 As far as I know, MPEG decoders are specified, but not bit exact. With a bit-exact specification, there simply could not be any floating-point implementation of an MP3 or AAC decoder. As long as the decoder is correctly specified with a tolerance on the deviation compared to the reference decoder, I do not see how an encoder could work with one decoder and not with another. As an example of (very simple) tolerance, we could say that a decoder implementation has to be within 80 dB SNR of the reference implementation on some test vectors. In practice we can use slightly more perceptually relevant metrics. Jean-Marc On 11-01-25 09:34 AM, Roman Shpount wrote: > One more concern that I have related to bit exactness is codec regression > testing. One can produce a non-bit-exact encoder that produces reasonable > results for a reference decoder, but if paired with a modified, > non-bit-exact decoder will produce significant audio artifacts. Since > neither decoder or encoder are bit exact we will need to have a test > procedure that will validate that both encoder or decoder will not break > any standard compliant and non-bit-exact encoders or decoders. Not really > sure how this can be done. > > I might be wrong, but I think MPEG decoders are bit exact and encoders are not. > _____________ > Roman Shpount > > > On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin > wrote: > > Hi Stephan, > > I understand your concern and I'd be interested if you have alternative > ways of handling the licensing to avoid any issue. It's not like this > is a unique situation. As far as I know, most (all?) MPEG codecs have > similar non-bit exact definitions. I have also heard that they also > require some IPR licensing... > > In general the issue of bit-exactness has been discussed and so far I > don't recall many arguing in favor of a bit-exact definition. Most of > the concerns that have been expressed are solved by considering that > non-bitexact does not mean you cannot be bit-exact with the reference > encoder. It merely means that you don't *have* to. So regardless of how > conformance is defined exactly, one always has the option of being > bit-exact with the reference implementation, which obviously guarantees > compliance. > > As for language mentioning compliance, I believe it belongs more to the > guidelines (it's not a requirement of the codec itself), which includes > the following text: > > 4. To reduce the risk of bias towards certain CPU/DSP architectures, > ideally the decoder specification should not require "bit-exact" > conformance with the reference implementation. The output of a > decoder implementation should only be "close enough" to the > output of the reference decoder. A comparison tool should be > provided along with the codec to verify objectively that the > output of a decoder is likely to be perceptually > indistinguishable from that of the reference decoder. However, > an implementation may still wish to produce an output that is > bit-exact with the reference implementation to simplify the > testing procedure. > > > > Cheers, > > Jean-Marc > > > On 11-01-24 11:02 PM, Stephan Wenger wrote: > > Hi all: > > Let me speak once more against this decision (if such a decision were > really made; see the p.s.). > > There are currently three IPR disclosures against the codec draft > and/or > its predecessors. The Xiph disclosure is at this point a placeholder > (Xiph folks: it's time to fix that!). However, the two other > disclosures > on file provide a patent grant only for necessary patent claims and > only > when the standard is practiced in full compliance. These terms (in > various formulations) are quite common. > > In order to ensure one has a license (or can rely on a non-assert > covenant), one has to ensure one meets the conditions set by the > rightholder. On stuff such as reciprocity clauses this is simple. On > compliance, it's not always easy. > > The traditional compliance test for a media codec is a > stimulus-response > test: you feed test vectors into the codec, and you get results. If the > results match, you are in compliance, if not, you are not. Simple. > > Without bit exactness, the compliance criteria have to be defined > differently. We can do so, and, indeed, I recall that this has been > mentioned as one plan forward. However, I have seen zero activity > in this > direction, and I have also not seen any language that mentions this > in the > requirements draft. I think that the subject of compliance tests, at > least in its most basic outline, needs to be documented in the > requirements draft. The details can be taken care of elsewhere and > later, > but not too much later. It should be clear that a codec candidate (if > there were more than one) needs to have compliance criteria defined > before > that codec candidate can become an RFC. Without that, the key goal > of the > WG, a reasonably freely practicable codec, is just not achievable > in the > current legal environment (which includes, in this case, the IPR > disclosures on file). > > Of course, it would be sooooo much simpler if we would mandate a > bit exact > decoder... Is it really that restricting to require that? > > Stephan > > P.s.: for the IETF procedures newcomers: humms taken at meetings > need to > be confirmed on a mailing list, and consensus needs to be declared > by the > chairs. On this subject, I do recall mailing list discussions after > Maastricht, but I do not recall that consensus was reached, yet alone > declared. (Unfortunately, I currently don't have the time to go through > the mailing list archives to verify my recollection; Sorry.) > > > > On 1.24.2011 16:45 , "codec issue tracker" > wrote: > > #12: bit-exact vs. bit-compatible? > > Changes (by gmaxwell@Å ): > > * status: new => closed > * resolution: => worksforme > > > Comment: > > http://www.ietf.org/proceedings/78/minutes/codec.txt > > "On the topic of bit exact. Consensus was bit exactness is not > required." > > I believe this issue is already closed. > > -- > ------------------------------------+------------------------------------- > -- > Reporter: hoene@Å | Owner: > Type: enhancement | Status: closed > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Resolution: worksforme > Keywords: | > ------------------------------------+------------------------------------- > -- > > Ticket > URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Tue Jan 25 07:54:38 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBB13A67EC for ; Tue, 25 Jan 2011 07:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 76Pk5vtSGpxM for ; Tue, 25 Jan 2011 07:54:37 -0800 (PST) Received: from toroondcbmts05-srv.bellnexxia.net (toroondcbmts05.bellnexxia.net [207.236.237.39]) by core3.amsl.com (Postfix) with ESMTP id 576393A67EA for ; Tue, 25 Jan 2011 07:54:37 -0800 (PST) Received: from toip54-bus.srvr.bell.ca ([67.69.240.140]) by toroondcbmts05-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110125155734.IICL13003.toroondcbmts05-srv.bellnexxia.net@toip54-bus.srvr.bell.ca>; Tue, 25 Jan 2011 10:57:34 -0500 Received: from toip60-bus.srvr.bell.ca ([67.69.240.187]) by toip54-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 10:57:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK58Pk3PPaAN/2dsb2JhbACkbnO9A4VPBIUXilcG Received: from mail.octasic.com ([207.61.160.13]) by toip60-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 10:57:25 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Jan 2011 10:57:25 -0500 Message-ID: <4D3EF2E5.6080101@octasic.com> Date: Tue, 25 Jan 2011 10:57:25 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Botzko References: <4D3E598A.3010200@jmvalin.ca> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 15:54:38 -0000 Hi Stephen, The reference implementation includes both floating-point and fixed-point, so I'm not sure it's a good idea to say that one is "better" than the other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" standard either when it comes to some operations (e.g. transcendental function) and even for other operations, most compilers I know of are not strict IEEE-754 (at least by default) because of issues such as the x86 extended precision operations. Regarding MPEG bit-streams, I'm not sure where to get confirmation, but this is what Wikipedia has to say about MPEG-1 Layer 3: "Decoding, on the other hand, is carefully defined in the standard. Most decoders are "bitstream compliant", which means that the decompressed output – that they produce from a given MP3 file – will be the same, within a specified degree of rounding tolerance, as the output specified mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). Therefore, comparison of decoders is usually based on how computationally efficient they are (i.e., how much memory or CPU time they use in the decoding process)." That implies a standard based on "infinite precision", with a degree of tolerance for different implementations. Cheers, Jean-Marc On 11-01-25 10:42 AM, Stephen Botzko wrote: > It seems to me that the reference encoder and decoder will be bit exact for > a given floating point format, correct? So one could specify IEEE 754-2008 > when bit exactness is needed in the reference (for instance regression > testing), but not require it for compliance. > > Folks who are modifying the reference encoder or decoder algorithms are "on > their own" as far as audio quality is concerned. Though I agree with > Stephan that we need to address compliance (when exactly does a ported or > otherwise modified encoder/decoder become non-compliant?). > > Stephen Botzko > > On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount > wrote: > > One more concern that I have related to bit exactness is codec > regression testing. One can produce a non-bit-exact encoder that > produces reasonable results for a reference decoder, but if paired with > a modified, non-bit-exact decoder will produce significant audio > artifacts. Since neither decoder or encoder are bit exact we will need > to have a test procedure that will validate that both encoder or > decoder will not break any standard compliant and non-bit-exact > encoders or decoders. Not really sure how this can be done. > > I might be wrong, but I think MPEG decoders are bit exact and encoders > are not. > _____________ > Roman Shpount > > > > On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin > wrote: > > Hi Stephan, > > I understand your concern and I'd be interested if you have > alternative ways of handling the licensing to avoid any issue. It's > not like this is a unique situation. As far as I know, most (all?) > MPEG codecs have similar non-bit exact definitions. I have also > heard that they also require some IPR licensing... > > In general the issue of bit-exactness has been discussed and so far > I don't recall many arguing in favor of a bit-exact definition. > Most of the concerns that have been expressed are solved by > considering that non-bitexact does not mean you cannot be bit-exact > with the reference encoder. It merely means that you don't *have* > to. So regardless of how conformance is defined exactly, one always > has the option of being bit-exact with the reference > implementation, which obviously guarantees compliance. > > As for language mentioning compliance, I believe it belongs more to > the guidelines (it's not a requirement of the codec itself), which > includes the following text: > > 4. To reduce the risk of bias towards certain CPU/DSP architectures, > ideally the decoder specification should not require "bit-exact" > conformance with the reference implementation. The output of a > decoder implementation should only be "close enough" to the > output of the reference decoder. A comparison tool should be > provided along with the codec to verify objectively that the > output of a decoder is likely to be perceptually > indistinguishable from that of the reference decoder. However, > an implementation may still wish to produce an output that is > bit-exact with the reference implementation to simplify the > testing procedure. > > > > Cheers, > > Jean-Marc > > > On 11-01-24 11:02 PM, Stephan Wenger wrote: > > Hi all: > > Let me speak once more against this decision (if such a > decision were > really made; see the p.s.). > > There are currently three IPR disclosures against the codec > draft and/or > its predecessors. The Xiph disclosure is at this point a > placeholder > (Xiph folks: it's time to fix that!). However, the two other > disclosures > on file provide a patent grant only for necessary patent claims > and only > when the standard is practiced in full compliance. These terms (in > various formulations) are quite common. > > In order to ensure one has a license (or can rely on a non-assert > covenant), one has to ensure one meets the conditions set by the > rightholder. On stuff such as reciprocity clauses this is > simple. On > compliance, it's not always easy. > > The traditional compliance test for a media codec is a > stimulus-response > test: you feed test vectors into the codec, and you get > results. If the > results match, you are in compliance, if not, you are not. Simple. > > Without bit exactness, the compliance criteria have to be defined > differently. We can do so, and, indeed, I recall that this has been > mentioned as one plan forward. However, I have seen zero > activity in this > direction, and I have also not seen any language that mentions > this in the > requirements draft. I think that the subject of compliance > tests, at > least in its most basic outline, needs to be documented in the > requirements draft. The details can be taken care of elsewhere > and later, > but not too much later. It should be clear that a codec > candidate (if > there were more than one) needs to have compliance criteria > defined before > that codec candidate can become an RFC. Without that, the key > goal of the > WG, a reasonably freely practicable codec, is just not > achievable in the > current legal environment (which includes, in this case, the IPR > disclosures on file). > > Of course, it would be sooooo much simpler if we would mandate > a bit exact > decoder... Is it really that restricting to require that? > > Stephan > > P.s.: for the IETF procedures newcomers: humms taken at > meetings need to > be confirmed on a mailing list, and consensus needs to be > declared by the > chairs. On this subject, I do recall mailing list discussions after > Maastricht, but I do not recall that consensus was reached, yet > alone > declared. (Unfortunately, I currently don't have the time to go > through > the mailing list archives to verify my recollection; Sorry.) > > > > On 1.24.2011 16:45 , "codec issue tracker" > wrote: > > #12: bit-exact vs. bit-compatible? > > Changes (by gmaxwell@Å ): > > * status: new => closed > * resolution: => worksforme > > > Comment: > > http://www.ietf.org/proceedings/78/minutes/codec.txt > > "On the topic of bit exact. Consensus was bit exactness is > not required." > > I believe this issue is already closed. > > -- > ------------------------------------+------------------------------------- > -- > Reporter: hoene@Å | Owner: > Type: enhancement | Status: closed > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Resolution: worksforme > Keywords: | > ------------------------------------+------------------------------------- > -- > > Ticket > URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Tue Jan 25 08:26:36 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653483A681A for ; Tue, 25 Jan 2011 08:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdyqGrdbMPjy for ; Tue, 25 Jan 2011 08:26:33 -0800 (PST) Received: from toroondcbmts04-srv.bellnexxia.net (toroondcbmts04-srv.bellnexxia.net [207.236.237.38]) by core3.amsl.com (Postfix) with ESMTP id 4FDEF3A67F0 for ; Tue, 25 Jan 2011 08:26:33 -0800 (PST) Received: from toip56-bus.srvr.bell.ca ([67.69.240.142]) by toroondcbmts04-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110125162930.IMDQ13791.toroondcbmts04-srv.bellnexxia.net@toip56-bus.srvr.bell.ca>; Tue, 25 Jan 2011 11:29:30 -0500 Received: from toip36-bus.srvr.bell.ca ([67.69.240.37]) by toip56-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 11:29:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+DPk3PPaAN/2dsb2JhbACkb3O9EoVPBIUXilcG Received: from mail.octasic.com ([207.61.160.13]) by toip36-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 11:29:25 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Jan 2011 11:29:25 -0500 Message-ID: <4D3EFA65.7000800@octasic.com> Date: Tue, 25 Jan 2011 11:29:25 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Botzko References: <4D3E598A.3010200@jmvalin.ca> <4D3EF2E5.6080101@octasic.com> In-Reply-To: <4D3EF2E5.6080101@octasic.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 16:26:36 -0000 Just to give an idea of what I'm talking about in terms of compliance test, here's a tool I just wrote that could be used for testing. There may need to be a bit of refining and playing with the thresholds, but the main idea is there: http://jmvalin.ca/misc_stuff/compare.m It works with Octave, and is likely very easy to get to work with Matlab. Any comments? Jean-Marc On 11-01-25 10:57 AM, Jean-Marc Valin wrote: > Hi Stephen, > > The reference implementation includes both floating-point and fixed-point, > so I'm not sure it's a good idea to say that one is "better" than the > other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" > standard either when it comes to some operations (e.g. transcendental > function) and even for other operations, most compilers I know of are not > strict IEEE-754 (at least by default) because of issues such as the x86 > extended precision operations. > > Regarding MPEG bit-streams, I'm not sure where to get confirmation, but > this is what Wikipedia has to say about MPEG-1 Layer 3: > > > "Decoding, on the other hand, is carefully defined in the standard. Most > decoders are "bitstream compliant", which means that the decompressed > output – that they produce from a given MP3 file – will be the same, within > a specified degree of rounding tolerance, as the output specified > mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). > Therefore, comparison of decoders is usually based on how computationally > efficient they are (i.e., how much memory or CPU time they use in the > decoding process)." > > > That implies a standard based on "infinite precision", with a degree of > tolerance for different implementations. > > Cheers, > > Jean-Marc > > On 11-01-25 10:42 AM, Stephen Botzko wrote: >> It seems to me that the reference encoder and decoder will be bit exact for >> a given floating point format, correct? So one could specify IEEE 754-2008 >> when bit exactness is needed in the reference (for instance regression >> testing), but not require it for compliance. >> >> Folks who are modifying the reference encoder or decoder algorithms are "on >> their own" as far as audio quality is concerned. Though I agree with >> Stephan that we need to address compliance (when exactly does a ported or >> otherwise modified encoder/decoder become non-compliant?). >> >> Stephen Botzko >> >> On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount > > wrote: >> >> One more concern that I have related to bit exactness is codec >> regression testing. One can produce a non-bit-exact encoder that >> produces reasonable results for a reference decoder, but if paired with >> a modified, non-bit-exact decoder will produce significant audio >> artifacts. Since neither decoder or encoder are bit exact we will need >> to have a test procedure that will validate that both encoder or >> decoder will not break any standard compliant and non-bit-exact >> encoders or decoders. Not really sure how this can be done. >> >> I might be wrong, but I think MPEG decoders are bit exact and encoders >> are not. >> _____________ >> Roman Shpount >> >> >> >> On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin > > wrote: >> >> Hi Stephan, >> >> I understand your concern and I'd be interested if you have >> alternative ways of handling the licensing to avoid any issue. It's >> not like this is a unique situation. As far as I know, most (all?) >> MPEG codecs have similar non-bit exact definitions. I have also >> heard that they also require some IPR licensing... >> >> In general the issue of bit-exactness has been discussed and so far >> I don't recall many arguing in favor of a bit-exact definition. >> Most of the concerns that have been expressed are solved by >> considering that non-bitexact does not mean you cannot be bit-exact >> with the reference encoder. It merely means that you don't *have* >> to. So regardless of how conformance is defined exactly, one always >> has the option of being bit-exact with the reference >> implementation, which obviously guarantees compliance. >> >> As for language mentioning compliance, I believe it belongs more to >> the guidelines (it's not a requirement of the codec itself), which >> includes the following text: >> >> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >> ideally the decoder specification should not require "bit-exact" >> conformance with the reference implementation. The output of a >> decoder implementation should only be "close enough" to the >> output of the reference decoder. A comparison tool should be >> provided along with the codec to verify objectively that the >> output of a decoder is likely to be perceptually >> indistinguishable from that of the reference decoder. However, >> an implementation may still wish to produce an output that is >> bit-exact with the reference implementation to simplify the >> testing procedure. >> >> >> >> Cheers, >> >> Jean-Marc >> >> >> On 11-01-24 11:02 PM, Stephan Wenger wrote: >> >> Hi all: >> >> Let me speak once more against this decision (if such a >> decision were >> really made; see the p.s.). >> >> There are currently three IPR disclosures against the codec >> draft and/or >> its predecessors. The Xiph disclosure is at this point a >> placeholder >> (Xiph folks: it's time to fix that!). However, the two other >> disclosures >> on file provide a patent grant only for necessary patent claims >> and only >> when the standard is practiced in full compliance. These terms (in >> various formulations) are quite common. >> >> In order to ensure one has a license (or can rely on a non-assert >> covenant), one has to ensure one meets the conditions set by the >> rightholder. On stuff such as reciprocity clauses this is >> simple. On >> compliance, it's not always easy. >> >> The traditional compliance test for a media codec is a >> stimulus-response >> test: you feed test vectors into the codec, and you get >> results. If the >> results match, you are in compliance, if not, you are not. Simple. >> >> Without bit exactness, the compliance criteria have to be defined >> differently. We can do so, and, indeed, I recall that this has been >> mentioned as one plan forward. However, I have seen zero >> activity in this >> direction, and I have also not seen any language that mentions >> this in the >> requirements draft. I think that the subject of compliance >> tests, at >> least in its most basic outline, needs to be documented in the >> requirements draft. The details can be taken care of elsewhere >> and later, >> but not too much later. It should be clear that a codec >> candidate (if >> there were more than one) needs to have compliance criteria >> defined before >> that codec candidate can become an RFC. Without that, the key >> goal of the >> WG, a reasonably freely practicable codec, is just not >> achievable in the >> current legal environment (which includes, in this case, the IPR >> disclosures on file). >> >> Of course, it would be sooooo much simpler if we would mandate >> a bit exact >> decoder... Is it really that restricting to require that? >> >> Stephan >> >> P.s.: for the IETF procedures newcomers: humms taken at >> meetings need to >> be confirmed on a mailing list, and consensus needs to be >> declared by the >> chairs. On this subject, I do recall mailing list discussions after >> Maastricht, but I do not recall that consensus was reached, yet >> alone >> declared. (Unfortunately, I currently don't have the time to go >> through >> the mailing list archives to verify my recollection; Sorry.) >> >> >> >> On 1.24.2011 16:45 , "codec issue tracker"> > wrote: >> >> #12: bit-exact vs. bit-compatible? >> >> Changes (by gmaxwell@Å ): >> >> * status: new => closed >> * resolution: => worksforme >> >> >> Comment: >> >> http://www.ietf.org/proceedings/78/minutes/codec.txt >> >> "On the topic of bit exact. Consensus was bit exactness is >> not required." >> >> I believe this issue is already closed. >> >> -- >> ------------------------------------+------------------------------------- >> -- >> Reporter: hoene@Å | Owner: >> Type: enhancement | Status: closed >> Priority: minor | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Resolution: worksforme >> Keywords: | >> ------------------------------------+------------------------------------- >> -- >> >> Ticket >> URL: >> codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Jan 25 12:34:32 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE5C3A6890 for ; Tue, 25 Jan 2011 12:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 0y0OCE4gp9qO for ; Tue, 25 Jan 2011 12:34:30 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 5A39F3A685C for ; Tue, 25 Jan 2011 12:34:30 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 65D7416F3; Tue, 25 Jan 2011 21:37:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=k42CW4+vkruI0a66mpeHtSpBJA4= ; b=jSEfzE3QZOw80ZyNHfYYuQ3xNNHU9SLzX3gF1HZZE7blA0ZRZWTPjowJ//lo /UBH9LK9fz0J+kK9oT/aTCREizNBnB/L6Lg3paF/TnmiaurTa2Zt9piBF8kf0khe Yi8YbsE0K1Y74BtgVn4UWrjgp8HflTDZbSj+2ADR6UgHxPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=DlVsoBAahH/idGopl7lmze BRpzQgTfvfmZS1orJLjPAGAQjL/mHk8aXBSwC2AgUGiGEpfNVaYeWBQBxYSfW2cD WPo9SN48Gdtt1xR1ZyDhKKmiB0Goqj9NTQv4PCx6X99jWDmUnIqlNx05WZ3qyBuJ b9lFAqfURCSt/Js2Q4Nhg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 642377F6; Tue, 25 Jan 2011 21:37:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 3A6863507B5D; Tue, 25 Jan 2011 21:37:27 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88pgeTFP2n0w; Tue, 25 Jan 2011 21:37:24 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 3978F3507B51; Tue, 25 Jan 2011 21:37:24 +0100 (CET) Date: Tue, 25 Jan 2011 21:37:24 +0100 (CET) From: Koen Vos To: Jean-Marc Valin Message-ID: <1972683647.1368315.1295987844034.JavaMail.root@lu2-zimbra> In-Reply-To: <4D3EFA65.7000800@octasic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org, Stephen Botzko Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 20:34:32 -0000 A similar tool is in the code in silk\test\signalCompare.c. It's based on = LPC, and measures the SNR in a partially-whitened domain. For music the cr= itical-band approach of Jean-Marc's tool may work better, not sure. One question is about what implementation should be the reference for compl= iance testing: floating-point or fixed-point? A fixed-point reference allows for bit-exact implementations, which is nice= . And fixed-point reference implementations are the norm in speech coding. However, CELT's floating-point implementation has a larger dynamic range th= an the fixed-point version, and is thus arguable better. A fixed-point ref= erence could not test this extra dynamic range. Any suggestions? koen. ----- Original Message ----- From: "Jean-Marc Valin" To: "Stephen Botzko" Cc: codec@ietf.org Sent: Tuesday, January 25, 2011 8:29:25 AM Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatibl= e? Just to give an idea of what I'm talking about in terms of compliance test,= =20 here's a tool I just wrote that could be used for testing. There may need= =20 to be a bit of refining and playing with the thresholds, but the main idea= =20 is there: http://jmvalin.ca/misc_stuff/compare.m It works with Octave, and is likely very easy to get to work with Matlab.= =20 Any comments? =09Jean-Marc On 11-01-25 10:57 AM, Jean-Marc Valin wrote: > Hi Stephen, > > The reference implementation includes both floating-point and fixed-point= , > so I'm not sure it's a good idea to say that one is "better" than the > other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" > standard either when it comes to some operations (e.g. transcendental > function) and even for other operations, most compilers I know of are not > strict IEEE-754 (at least by default) because of issues such as the x86 > extended precision operations. > > Regarding MPEG bit-streams, I'm not sure where to get confirmation, but > this is what Wikipedia has to say about MPEG-1 Layer 3: > > > "Decoding, on the other hand, is carefully defined in the standard. Most > decoders are "bitstream compliant", which means that the decompressed > output =E2=80=93 that they produce from a given MP3 file =E2=80=93 will b= e the same, within > a specified degree of rounding tolerance, as the output specified > mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). > Therefore, comparison of decoders is usually based on how computationally > efficient they are (i.e., how much memory or CPU time they use in the > decoding process)." > > > That implies a standard based on "infinite precision", with a degree of > tolerance for different implementations. > > Cheers, > > Jean-Marc > > On 11-01-25 10:42 AM, Stephen Botzko wrote: >> It seems to me that the reference encoder and decoder will be bit exact = for >> a given floating point format, correct? So one could specify IEEE 754-20= 08 >> when bit exactness is needed in the reference (for instance regression >> testing), but not require it for compliance. >> >> Folks who are modifying the reference encoder or decoder algorithms are = "on >> their own" as far as audio quality is concerned. Though I agree with >> Stephan that we need to address compliance (when exactly does a ported o= r >> otherwise modified encoder/decoder become non-compliant?). >> >> Stephen Botzko >> >> On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount > > wrote: >> >> One more concern that I have related to bit exactness is codec >> regression testing. One can produce a non-bit-exact encoder that >> produces reasonable results for a reference decoder, but if paired with >> a modified, non-bit-exact decoder will produce significant audio >> artifacts. Since neither decoder or encoder are bit exact we will need >> to have a test procedure that will validate that both encoder or >> decoder will not break any standard compliant and non-bit-exact >> encoders or decoders. Not really sure how this can be done. >> >> I might be wrong, but I think MPEG decoders are bit exact and encoders >> are not. >> _____________ >> Roman Shpount >> >> >> >> On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin > > wrote: >> >> Hi Stephan, >> >> I understand your concern and I'd be interested if you have >> alternative ways of handling the licensing to avoid any issue. It's >> not like this is a unique situation. As far as I know, most (all?) >> MPEG codecs have similar non-bit exact definitions. I have also >> heard that they also require some IPR licensing... >> >> In general the issue of bit-exactness has been discussed and so far >> I don't recall many arguing in favor of a bit-exact definition. >> Most of the concerns that have been expressed are solved by >> considering that non-bitexact does not mean you cannot be bit-exact >> with the reference encoder. It merely means that you don't *have* >> to. So regardless of how conformance is defined exactly, one always >> has the option of being bit-exact with the reference >> implementation, which obviously guarantees compliance. >> >> As for language mentioning compliance, I believe it belongs more to >> the guidelines (it's not a requirement of the codec itself), which >> includes the following text: >> >> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >> ideally the decoder specification should not require "bit-exact" >> conformance with the reference implementation. The output of a >> decoder implementation should only be "close enough" to the >> output of the reference decoder. A comparison tool should be >> provided along with the codec to verify objectively that the >> output of a decoder is likely to be perceptually >> indistinguishable from that of the reference decoder. However, >> an implementation may still wish to produce an output that is >> bit-exact with the reference implementation to simplify the >> testing procedure. >> >> >> >> Cheers, >> >> Jean-Marc >> >> >> On 11-01-24 11:02 PM, Stephan Wenger wrote: >> >> Hi all: >> >> Let me speak once more against this decision (if such a >> decision were >> really made; see the p.s.). >> >> There are currently three IPR disclosures against the codec >> draft and/or >> its predecessors. The Xiph disclosure is at this point a >> placeholder >> (Xiph folks: it's time to fix that!). However, the two other >> disclosures >> on file provide a patent grant only for necessary patent claims >> and only >> when the standard is practiced in full compliance. These terms (in >> various formulations) are quite common. >> >> In order to ensure one has a license (or can rely on a non-assert >> covenant), one has to ensure one meets the conditions set by the >> rightholder. On stuff such as reciprocity clauses this is >> simple. On >> compliance, it's not always easy. >> >> The traditional compliance test for a media codec is a >> stimulus-response >> test: you feed test vectors into the codec, and you get >> results. If the >> results match, you are in compliance, if not, you are not. Simple. >> >> Without bit exactness, the compliance criteria have to be defined >> differently. We can do so, and, indeed, I recall that this has been >> mentioned as one plan forward. However, I have seen zero >> activity in this >> direction, and I have also not seen any language that mentions >> this in the >> requirements draft. I think that the subject of compliance >> tests, at >> least in its most basic outline, needs to be documented in the >> requirements draft. The details can be taken care of elsewhere >> and later, >> but not too much later. It should be clear that a codec >> candidate (if >> there were more than one) needs to have compliance criteria >> defined before >> that codec candidate can become an RFC. Without that, the key >> goal of the >> WG, a reasonably freely practicable codec, is just not >> achievable in the >> current legal environment (which includes, in this case, the IPR >> disclosures on file). >> >> Of course, it would be sooooo much simpler if we would mandate >> a bit exact >> decoder... Is it really that restricting to require that? >> >> Stephan >> >> P.s.: for the IETF procedures newcomers: humms taken at >> meetings need to >> be confirmed on a mailing list, and consensus needs to be >> declared by the >> chairs. On this subject, I do recall mailing list discussions after >> Maastricht, but I do not recall that consensus was reached, yet >> alone >> declared. (Unfortunately, I currently don't have the time to go >> through >> the mailing list archives to verify my recollection; Sorry.) >> >> >> >> On 1.24.2011 16:45 , "codec issue tracker"> > wrote: >> >> #12: bit-exact vs. bit-compatible? >> >> Changes (by gmaxwell@=C3=85 ): >> >> * status: new =3D> closed >> * resolution: =3D> worksforme >> >> >> Comment: >> >> http://www.ietf.org/proceedings/78/minutes/codec.txt >> >> "On the topic of bit exact. Consensus was bit exactness is >> not required." >> >> I believe this issue is already closed. >> >> -- >> ------------------------------------+-----------------------------------= -- >> -- >> Reporter: hoene@=C3=85 | Owner: >> Type: enhancement | Status: closed >> Priority: minor | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Resolution: worksforme >> Keywords: | >> ------------------------------------+-----------------------------------= -- >> -- >> >> Ticket >> URL: >> codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > 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 Jan 25 12:55:19 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9040C3A689A for ; Tue, 25 Jan 2011 12:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-1.050, 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 gUXunq-apufK for ; Tue, 25 Jan 2011 12:55:18 -0800 (PST) Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07.bellnexxia.net [207.236.237.41]) by core3.amsl.com (Postfix) with ESMTP id 7D68E3A6838 for ; Tue, 25 Jan 2011 12:55:16 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110125205813.UPBP3521.toroondcbmts07-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Tue, 25 Jan 2011 15:58:13 -0500 Received: from toip38-bus.srvr.bell.ca ([67.69.240.39]) by toip58-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 15:58:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACK9Pk3PPaAN/2dsb2JhbACkcXO9CoVPBIUXilcGgxA Received: from mail.octasic.com ([207.61.160.13]) by toip38-bus.srvr.bell.ca with ESMTP; 25 Jan 2011 15:58:05 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Jan 2011 15:58:04 -0500 Message-ID: <4D3F395C.7000005@octasic.com> Date: Tue, 25 Jan 2011 15:58:04 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Koen Vos References: <1972683647.1368315.1295987844034.JavaMail.root@lu2-zimbra> In-Reply-To: <1972683647.1368315.1295987844034.JavaMail.root@lu2-zimbra> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, Stephen Botzko Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 25 Jan 2011 20:55:19 -0000 My preference actually goes with using both fixed-point and floating point. That way, implementers of floating-point decoder can compare with the float version and implementers of the fixed-point decoder can compare with the fixed-point version. This is not unheard of either, if you look at the reference implementation of the 3GPP(2?) EVRC codec, the distribution includes two sets of output vectors. One is for a fixed-point implementation that uses 31-bit precision in the multiplications and the other one is for 32-bit precision. You just choose whatever is more efficient for your DSP and use the appropriate testvectors for testing. Jean-Marc On 11-01-25 03:37 PM, Koen Vos wrote: > A similar tool is in the code in silk\test\signalCompare.c. It's based on LPC, and measures the SNR in a partially-whitened domain. For music the critical-band approach of Jean-Marc's tool may work better, not sure. > > One question is about what implementation should be the reference for compliance testing: floating-point or fixed-point? > > A fixed-point reference allows for bit-exact implementations, which is nice. And fixed-point reference implementations are the norm in speech coding. > However, CELT's floating-point implementation has a larger dynamic range than the fixed-point version, and is thus arguable better. A fixed-point reference could not test this extra dynamic range. > > Any suggestions? > koen. > > > ----- Original Message ----- > From: "Jean-Marc Valin" > To: "Stephen Botzko" > Cc: codec@ietf.org > Sent: Tuesday, January 25, 2011 8:29:25 AM > Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? > > Just to give an idea of what I'm talking about in terms of compliance test, > here's a tool I just wrote that could be used for testing. There may need > to be a bit of refining and playing with the thresholds, but the main idea > is there: > > http://jmvalin.ca/misc_stuff/compare.m > > It works with Octave, and is likely very easy to get to work with Matlab. > Any comments? > > Jean-Marc > > On 11-01-25 10:57 AM, Jean-Marc Valin wrote: >> Hi Stephen, >> >> The reference implementation includes both floating-point and fixed-point, >> so I'm not sure it's a good idea to say that one is "better" than the >> other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" >> standard either when it comes to some operations (e.g. transcendental >> function) and even for other operations, most compilers I know of are not >> strict IEEE-754 (at least by default) because of issues such as the x86 >> extended precision operations. >> >> Regarding MPEG bit-streams, I'm not sure where to get confirmation, but >> this is what Wikipedia has to say about MPEG-1 Layer 3: >> >> >> "Decoding, on the other hand, is carefully defined in the standard. Most >> decoders are "bitstream compliant", which means that the decompressed >> output – that they produce from a given MP3 file – will be the same, within >> a specified degree of rounding tolerance, as the output specified >> mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). >> Therefore, comparison of decoders is usually based on how computationally >> efficient they are (i.e., how much memory or CPU time they use in the >> decoding process)." >> >> >> That implies a standard based on "infinite precision", with a degree of >> tolerance for different implementations. >> >> Cheers, >> >> Jean-Marc >> >> On 11-01-25 10:42 AM, Stephen Botzko wrote: >>> It seems to me that the reference encoder and decoder will be bit exact for >>> a given floating point format, correct? So one could specify IEEE 754-2008 >>> when bit exactness is needed in the reference (for instance regression >>> testing), but not require it for compliance. >>> >>> Folks who are modifying the reference encoder or decoder algorithms are "on >>> their own" as far as audio quality is concerned. Though I agree with >>> Stephan that we need to address compliance (when exactly does a ported or >>> otherwise modified encoder/decoder become non-compliant?). >>> >>> Stephen Botzko >>> >>> On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount>> > wrote: >>> >>> One more concern that I have related to bit exactness is codec >>> regression testing. One can produce a non-bit-exact encoder that >>> produces reasonable results for a reference decoder, but if paired with >>> a modified, non-bit-exact decoder will produce significant audio >>> artifacts. Since neither decoder or encoder are bit exact we will need >>> to have a test procedure that will validate that both encoder or >>> decoder will not break any standard compliant and non-bit-exact >>> encoders or decoders. Not really sure how this can be done. >>> >>> I might be wrong, but I think MPEG decoders are bit exact and encoders >>> are not. >>> _____________ >>> Roman Shpount >>> >>> >>> >>> On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin>> > wrote: >>> >>> Hi Stephan, >>> >>> I understand your concern and I'd be interested if you have >>> alternative ways of handling the licensing to avoid any issue. It's >>> not like this is a unique situation. As far as I know, most (all?) >>> MPEG codecs have similar non-bit exact definitions. I have also >>> heard that they also require some IPR licensing... >>> >>> In general the issue of bit-exactness has been discussed and so far >>> I don't recall many arguing in favor of a bit-exact definition. >>> Most of the concerns that have been expressed are solved by >>> considering that non-bitexact does not mean you cannot be bit-exact >>> with the reference encoder. It merely means that you don't *have* >>> to. So regardless of how conformance is defined exactly, one always >>> has the option of being bit-exact with the reference >>> implementation, which obviously guarantees compliance. >>> >>> As for language mentioning compliance, I believe it belongs more to >>> the guidelines (it's not a requirement of the codec itself), which >>> includes the following text: >>> >>> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >>> ideally the decoder specification should not require "bit-exact" >>> conformance with the reference implementation. The output of a >>> decoder implementation should only be "close enough" to the >>> output of the reference decoder. A comparison tool should be >>> provided along with the codec to verify objectively that the >>> output of a decoder is likely to be perceptually >>> indistinguishable from that of the reference decoder. However, >>> an implementation may still wish to produce an output that is >>> bit-exact with the reference implementation to simplify the >>> testing procedure. >>> >>> >>> >>> Cheers, >>> >>> Jean-Marc >>> >>> >>> On 11-01-24 11:02 PM, Stephan Wenger wrote: >>> >>> Hi all: >>> >>> Let me speak once more against this decision (if such a >>> decision were >>> really made; see the p.s.). >>> >>> There are currently three IPR disclosures against the codec >>> draft and/or >>> its predecessors. The Xiph disclosure is at this point a >>> placeholder >>> (Xiph folks: it's time to fix that!). However, the two other >>> disclosures >>> on file provide a patent grant only for necessary patent claims >>> and only >>> when the standard is practiced in full compliance. These terms (in >>> various formulations) are quite common. >>> >>> In order to ensure one has a license (or can rely on a non-assert >>> covenant), one has to ensure one meets the conditions set by the >>> rightholder. On stuff such as reciprocity clauses this is >>> simple. On >>> compliance, it's not always easy. >>> >>> The traditional compliance test for a media codec is a >>> stimulus-response >>> test: you feed test vectors into the codec, and you get >>> results. If the >>> results match, you are in compliance, if not, you are not. Simple. >>> >>> Without bit exactness, the compliance criteria have to be defined >>> differently. We can do so, and, indeed, I recall that this has been >>> mentioned as one plan forward. However, I have seen zero >>> activity in this >>> direction, and I have also not seen any language that mentions >>> this in the >>> requirements draft. I think that the subject of compliance >>> tests, at >>> least in its most basic outline, needs to be documented in the >>> requirements draft. The details can be taken care of elsewhere >>> and later, >>> but not too much later. It should be clear that a codec >>> candidate (if >>> there were more than one) needs to have compliance criteria >>> defined before >>> that codec candidate can become an RFC. Without that, the key >>> goal of the >>> WG, a reasonably freely practicable codec, is just not >>> achievable in the >>> current legal environment (which includes, in this case, the IPR >>> disclosures on file). >>> >>> Of course, it would be sooooo much simpler if we would mandate >>> a bit exact >>> decoder... Is it really that restricting to require that? >>> >>> Stephan >>> >>> P.s.: for the IETF procedures newcomers: humms taken at >>> meetings need to >>> be confirmed on a mailing list, and consensus needs to be >>> declared by the >>> chairs. On this subject, I do recall mailing list discussions after >>> Maastricht, but I do not recall that consensus was reached, yet >>> alone >>> declared. (Unfortunately, I currently don't have the time to go >>> through >>> the mailing list archives to verify my recollection; Sorry.) >>> >>> >>> >>> On 1.24.2011 16:45 , "codec issue tracker">> > wrote: >>> >>> #12: bit-exact vs. bit-compatible? >>> >>> Changes (by gmaxwell@Ã… ): >>> >>> * status: new => closed >>> * resolution: => worksforme >>> >>> >>> Comment: >>> >>> http://www.ietf.org/proceedings/78/minutes/codec.txt >>> >>> "On the topic of bit exact. Consensus was bit exactness is >>> not required." >>> >>> I believe this issue is already closed. >>> >>> -- >>> ------------------------------------+------------------------------------- >>> -- >>> Reporter: hoene@Ã… | Owner: >>> Type: enhancement | Status: closed >>> Priority: minor | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Resolution: worksforme >>> Keywords: | >>> ------------------------------------+------------------------------------- >>> -- >>> >>> Ticket >>> URL: >>> codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Tue Jan 25 13:01:58 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB613A689F for ; Tue, 25 Jan 2011 13:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyPsTanZd29N for ; Tue, 25 Jan 2011 13:01:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A81A53A689E for ; Tue, 25 Jan 2011 13:01:57 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFPJPk2rR7H+/2dsb2JhbACkcXOhWZs7hU8EhReHEYNG Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2011 21:04:56 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0PL4thK006379; Tue, 25 Jan 2011 21:04:55 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> Date: Tue, 25 Jan 2011 14:06:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1562DB-979F-495F-933F-7B18B6D379FB@cisco.com> References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> To: Christian Hoene X-Mailer: Apple Mail (2.1082) Cc: codec@ietf.org Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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, 25 Jan 2011 21:01:58 -0000 I followed up with Christian on a separate thread and I hope we will = sort out whatever is needed to fix this document.=20 I just want to say the chairs certainly want this document to reflect = rough consensus of the WG. Please, help us get there - review this = document and provide suggested text for any technical changes that you = think need to be made to the draft.=20 Thanks, Cullen On Jan 23, 2011, at 1:19 AM, Christian Hoene wrote: >> The authors believe that the requirements document is complete.=20 >=20 > [Christian Hoene] Which authors? So far this document has only two = selected > editors. >=20 >> The chairs >> would like to now issue a 3 week working group last call for > draft-ietf-codec- >> requirements-02. At the end of 3 weeks, if no comments have been >> received, we will pass the document to the IESG for approval. >=20 > [Christian Hoene] Despite hundreds of emails, what were exchanged on = this > mailing list on issues regarding requirements, the editors have been > reluctant to update the requirements document according to the = consensus > process on this mailing list.=20 >=20 > If I compare draft-ietf-codec-requirement-02 with > draft-valin-codec-requirements-02, I only see editorial changes. > = https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-codec-requirements-02&dif= ftyp > e=3D--html&submit=3DGo!&url2=3Ddraft-valin-codec-requirements-02 >=20 > Sorry guys, if I see this I become very cynical on the standardization > process at the IETF. The editors have not done their job and the = chairs do > not care. At the end, it all looks like rubberstamping with a little = bit of > theater. >=20 > Christian >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From gmaxwell@juniper.net Tue Jan 25 15:49:49 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666413A68F2 for ; Tue, 25 Jan 2011 15:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ive+Ao0sZT9 for ; Tue, 25 Jan 2011 15:49:42 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id C8DD53A68EF for ; Tue, 25 Jan 2011 15:49:42 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTT9iSQRFxrzni0Gu5c3fzihJc2+eggf3@postini.com; Tue, 25 Jan 2011 15:52:42 PST Received: from EMBX01-HQ.jnpr.net ([fe80::99ad:1ca:2a64:e987]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 25 Jan 2011 15:47:25 -0800 From: Gregory Maxwell To: "codec@ietf.org" Date: Tue, 25 Jan 2011 15:45:34 -0800 Thread-Topic: CELT development update (01/2011) Thread-Index: AQHLvN6STXShUcKvC0WUFt5lI6wAAA== 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] CELT development update (01/2011) 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, 25 Jan 2011 23:49:49 -0000 I wanted to send a quick update about the recent technical progress from the CELT development team since the 0.10 software release and our last public update about a month ago. (http://people.xiph.org/~xiphmont/demo/celt/demo.html) Each point is referenced to commits in our public GIT repository. (http://git.xiph.org/?p=3Dcelt.git;a=3Dshortlog) =3D=3DAnti-collapse=3D=3D (87efe1df, 21af73eb, 5da938b2d, 01fa3389, etc.) In CELT, transient frames use multiple smaller MDCT transforms rather than a single large transform in order to provide better temporal control of quantization noise. These sub-frames are grouped and coded together. A previously outstanding issue for transient frames with the larger (480, 960) frame sizes was that the codec was able to starve some quiet sub-frames, particularly at low bitrates. This starvation resulted in short collapse=97 falling to zero energy=97 for a whole subframe per-band, and often for that subframe in all bands. This was not prevented by our previously existing sparseness prevention mechanisms which were primarily targeted at whole band starvation. The effect is most strikingly demonstrated with spectograms on castanet samples: https://people.xiph.org/~tterribe/notes/celt/spec-anti-collapse-off.png -vs- https://people.xiph.org/~tterribe/notes/celt/spec-anti-collapse-on.png (It's not as audible as the images suggest, due to forwards/backwards temporal masking). The allocation decision logic is correct in so far as the bits were best allocated to the louder sub-frames, but the short collapse produces artifacts of its own. In order to avoid this issue we implemented decoder-side logic which tracks where collapse is possible and refills it using noise scaled using the band energy from prior frames. This resolves the issue but there is still ongoing fine tuning of the specifics. =3D=3DPrevent 'busting' at low rates=3D=3D (76469c64) One of the core designs of the CELT bitstream is the lack of a fixed sized/fixed position structure. The encoder and decoder dynamically and continuously adapt to the remaining space in a frame without signaling according to behavior patterns hardcoded into the bitstream specification. Code/Bitstream simplifications last year reduced the ability of the codec to deactivate some signaling elements as the available space approached zero. This is reflected in the 'non-simple' block diagram by signaling elements with a minimum rate greater than zero bits: https://people.xiph.org/~greg/celt/full_block_diagram.png (now outdated by these changes) When running out of bits the encoder would simply stop coding and the decoder would be left to pick up the pieces. It turns out that sanely handling these cases while maintaining synchronization between the encoder and decoder was at least of comparable complexity to not permitting this situation in the bitstream at all. With these changes all the signaling elements can reach zero bits per frame. As a side effect some nonsensical bit-streams are no longer possible. For example, it was previous possible for a stupid encoder to spend all of the remaining bits in a frame signaling that a band should get more bits, but then not have any bits left to actually give to it. It's no longer possible to code sequences like this, which should make implementation QA somewhat simpler and the elimination of redundancy (unreasonable signaling combinations) has resulted in some small quality improvements. The encoder can now happily encode down to one byte per frame. The ability to completely eliminate signaling parameters also provided some quality improvement at ridiculously low rates, and we can give (barely) intelligible speech with a couple bytes per-frame. Intelligible speech at zero bytes per frame remains elusive. =3D=3DPre/Postfilter tap-sets=3D=3D (dfa847a2, 8d367029, 2ce5c63d, d121260f) One of the recommendations from Raymond Chen and team was that the bitstream should allow the selection of multiple filter-tap configurations for the pitch filters in order to better adapt to signals with different harmonic shapes. Spot testing early in the implementation of the pre/post filter didn't show much improvement from additional tapsets, but now that the PF implementation is basically complete we reevaluated this. Using an automated noise to masking ratio test we scanned the complete range of reasonable 3-tap filters, and many 5-tap filters, for hundreds of sound clips. Some of the results are visible here: https://people.xiph.org/~greg/celt/tests/20110116/sqam-taps-256/results.htm= l While the differences were generally small, there were classes of samples which worked better with configurations on one end of the spectrum or another. In many cases the difference between a single 'general' value and a specialized one were easily large enough to justify some increased signaling overhead. We ultimately adopted three configurations, a 5-tap filter at {0.12954,0.21701,0.30690,0.21701,0.12954} with a ~13kHz rolloff which is now our default, our prior 3-tap filter {0.26795,0.46410,0.26795}, and a much flatter 3-tap filter {0.1,0.8,0.1}. The default takes one bit to signal, and the other two options require two bits (per frame). We implemented some very basic automatic selection logic in the encoder, but it isn't yet adequate. Fortunately the selection logic doesn't have bitstream impact and can be refined for years to come. These testing results show the three options and the automatic selection compared to no filtering for a variety of samples and bitrates: https://people.xiph.org/~greg/celt/tests/20110118/tap-diff/results.html =3D=3DNumerous small improvements=3D=3D * The encoder inter/intraframe decision now checks to make sure that it doesn't prefer a choice which encodes the energy less precisely due to running out of bits. (2293e461) * The encoder could get stuck in an infinite loop while coding an extremely loud or quiet difference from the predicted energy. =20 (68b8d72e) * Range coder simplifications were made which reduced the number of calls to the entropy coder, which is good for performance, and increases the amount of code shared with Silk. (845dfa19, 1aaa50d1, 30df6cf3) * Corrected an encoder bug which caused a mismatch with the decoder for quiet signals, some other encoder signal processing improvements, and changes to the energy clamping behavior mean that our floating point implementation can provide consistent performance for signals attenuated by more than 138dB without harming compatibility with fixed point implementations. (8f02c482, 495114b7) * The reference implementation now provides a simple comfort noise generator for discontinuous operation. (eafd8a7f) * Miscellaneous stereo quality improvements. (235c64b9, a387ebfc, 051e044d, fa7215fdb, 79d76a2e3, 620e716b) * Corrections to the design of the Time-frequency tradeoff filters for various corner cases. (dc6d69e64, 2b13401f, ecefde3d) ...Plus many other small improvements, as documented in our version control system. We've also been maintaining a short term working todo list on the Xiph.Org wiki: https://wiki.xiph.org/CELT_TODO As usual, our realtime technical development discussion takes place in the IRC channel, #celt on irc.freenode.net. Our development collaboration is almost exclusively public and we welcome more participation. From mary.ietf.barnes@gmail.com Tue Jan 25 16:08:07 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A663A68E7 for ; Tue, 25 Jan 2011 16:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.322 X-Spam-Level: X-Spam-Status: No, score=-103.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Syt-b03cG80U for ; Tue, 25 Jan 2011 16:08:05 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 967413A68AB for ; Tue, 25 Jan 2011 16:08:05 -0800 (PST) Received: by gxk27 with SMTP id 27so2279238gxk.31 for ; Tue, 25 Jan 2011 16:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j9xbJug9F8DJgxAR6XHsTNEs1F84IlyilssWDaNh8ho=; b=l5uecBJgjNMZ8RQDRpkXIzEnNf1BdOBouX8XCuhjgYFQkn8+JJb3tGkE+dcoBPByIQ 7nHbYAzq3RV6f22t/6YuZCw/CChm5IqXZKpkDrxYExy58dxMYq+v+67ML/5QJ6s2rAd9 SViiocfcFKt5ieZawE+sk3lJTe7oM9XnSUX1A= 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=qDPM5tzpDXZoGnuSt21H9tOODsVhIM76RZTQWInqVuQzNx0bqQOG5hHS4vRhZ8tjsT AU35NK6p6C8gRhOhGUY/RFpHfVevl0dDip1u6btJ6KKw1j8CEttn6jlUZTcdhRjce9na EwFNKr5DPM1NZIWUO6bw7oIsNZOs2YWHVCGj8= MIME-Version: 1.0 Received: by 10.236.95.143 with SMTP id p15mr889600yhf.9.1296000664052; Tue, 25 Jan 2011 16:11:04 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 25 Jan 2011 16:11:03 -0800 (PST) In-Reply-To: References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> Date: Tue, 25 Jan 2011 18:11:03 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c895b35a3aa049ab4ab34 Cc: "codec@ietf.org" , Stephen Botzko Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 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, 26 Jan 2011 00:08:07 -0000 --0023547c895b35a3aa049ab4ab34 Content-Type: text/plain; charset=ISO-8859-1 John, Sorry for the confusion - yes the one document I noted was the guidelines. (There was no link to the doc in the Last call announcement, so I went to WG page and was looking at the other documents as well). However, the same comment does apply to the requirements - i.e., it should be informational. There is a perenniel debate as to whether RFC 2119 language applies to informational documents - the RFC 2119 abstract references only standards track documents and notes that the language (i.e., the words in CAPS) should be used sparingly as required for interoperability or to limit behavior that has the potential to cause problems. I interpret that to mean that it does not apply to requirements. I agree with you that clearly enumerating requirements is a good idea and should be standard practice. Thanks, Mary. On Tue, Jan 25, 2011 at 4:02 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > I am confused which document we are talking about. The subject indicates > the requirements document, but your quoted text "suggested process" seems to > come from the guidelines document. > > The situation with the requirements document > (draft-ietf-codec-requirements-02) is that it is intended as Standards Track > but contains no RFC 2119 language (as far as I can see, e.g., no "MUST" > statements, and no reference to RFC 2119). > > I think it should indeed be Informational, but this does not prevent us > having normative statements in which the codec specification that this WG > produces is the subject, e.g., "The codec MUST ..." This would make it much > easier to pick out the actual requirements and to measure the resulting > codec specification against those requirements. Some WGs adopt the practice > of numbering requirements, for easy reference. > > John > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] > > On Behalf Of Mary Barnes > > Sent: 24 January 2011 23:25 > > To: Jean-Marc Valin > > Cc: codec@ietf.org; Stephen Botzko > > Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 > > > > The document is currently specified as Standards Track, thus > > the use of RFC 2119 language is entirely appropriate. > > However, ISTM that the document should really just be > > Informational, in particular given the language in the > > introduction that this document defines a "suggested > > process", as opposed to a process that is required for codec > > development. > > > > > > Regards, > > Mary. > > > > > > On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin > > wrote: > > > > > > Christian, > > > > I actually responded to the last comments you made a > > while ago (oct 2010). One issue I pointed out was your use of > > RFC2119 keywords, which (AFAIK) aren't appropriate for a > > requirements draft (the requirements aren't a standard). So > > statements like "Any codec specified by the IETF MUST be well > > specified", besides stating the obvious, are inappropriate. > > > > There were also comments that just did not belong to > > this draft, such as the section on collaboration with other > > WGs. Collaboration is not a characteristic of a codec. So > > essentially, I merged the uncontroversial suggestion, but > > that's all I could do. As far as I'm aware, there's nothing > > in the current draft that goes against the consensus of the > > WG. If there are, please point to specific issues and to > > statements made by others (not just you) asking for the change. > > > > Cheers, > > > > Jean-Marc > > > > > > On 11-01-24 03:10 PM, Christian Hoene wrote: > > > > > > Christian - perhaps you could post a list of > > the issues you see that > > haven't been addressed? > > > > */[Christian Hoene] No Stephen, these issues > > have been written down in > > previous emails, drafts and issues in the Trac. > > They can be read by anybody > > anytime. Thus, I do not see any benefit of > > repeating them again if the > > editors continue to ignore any input. Indeed, > > they did not improve the > > draft despite sound technical reasons. /* > > > > */Even if somebody is not fully involved in the > > technical details: It is > > very odd that despite many hundreds emails and > > many discussions since > > starting this WG the editors have not updated > > the draft beside minor > > changes such as the boilerplate and typos. /* > > > > */Even if the lack of any update was not > > intentionally, the editors missed > > to do their job because they were too lazy or > > rather too busy doing other > > thinks./* > > > > */I would be sad if all the fruitful > > discussions here and all the good > > contributions of many industry experts should > > have been in vain. Even if > > not all requirements can be met by Opus, a > > proper requirements document may > > be relevant for future solutions or other SDOs./* > > > > > > */CH/* > > > > > > > > > > _______________________________________________ > > 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 > > > > > > > > > --0023547c895b35a3aa049ab4ab34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

Sorry for the confusion - yes the one document I n= oted was the guidelines. (There was no link to the doc in the Last call ann= ouncement, so I went to WG page and was looking at the other documents as w= ell).

However, the same comment does apply to the requirement= s - i.e., it should be informational. There is a perenniel debate as to whe= ther RFC 2119 language applies to informational documents - the RFC 2119 ab= stract references only standards track documents and notes that the languag= e (i.e., the words in CAPS) should be used sparingly as required for intero= perability or to limit behavior that has the potential to cause problems. = =A0I interpret that to mean that it does not apply to requirements.

I agree with you that clearly enumerating requirements = is a good idea and should be standard practice.=A0

Thanks,
Mary.=A0

On Tue= , Jan 25, 2011 at 4:02 AM, Elwell, John <john.elwell@siemens-enterprise.com= > wrote:
Mary,

I am confused which document we are talking about. The subject indicates th= e requirements document, but your quoted text "suggested process"= seems to come from the guidelines document.

The situation with the requirements document (draft-ietf-codec-requirements= -02) is that it is intended as Standards Track but contains no RFC 2119 lan= guage (as far as I can see, e.g., no "MUST" statements, and no re= ference to RFC 2119).

I think it should indeed be Informational, but this does not prevent us hav= ing normative statements in which the codec specification that this WG prod= uces is the subject, e.g., "The codec MUST ..." This would make i= t much easier to pick out the actual requirements and to measure the result= ing codec specification against those requirements. Some WGs adopt the prac= tice of numbering requirements, for easy reference.

John

> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg]
> On Behalf Of Mary Barnes
> Sent: 24 January 2011 23:25
> To: Jean-Marc Valin
> Cc: codec@ietf.org; Stephen Botz= ko
> Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02 >
> The document is currently specified as Standards Track, thus
> the use of RFC 2119 language is entirely appropriate.
> However, ISTM that the document should really just be
> Informational, in particular given the language in the
> introduction that this document defines a "suggested
> process", as opposed to a process that is required for codec
> development.
>
>
> Regards,
> Mary.
>
>
> On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin
> <jean-marc.valin@oct= asic.com> wrote:
>
>
> =A0 =A0 =A0 Christian,
>
> =A0 =A0 =A0 I actually responded to the last comments you made a
> while ago (oct 2010). One issue I pointed out was your use of
> RFC2119 keywords, which (AFAIK) aren't appropriate for a
> requirements draft (the requirements aren't a standard). So
> statements like "Any codec specified by the IETF MUST be well
> specified", besides stating the obvious, are inappropriate.
>
> =A0 =A0 =A0 There were also comments that just did not belong to
> this draft, such as the section on collaboration with other
> WGs. Collaboration is not a characteristic of a codec. So
> essentially, I merged the uncontroversial suggestion, but
> that's all I could do. As far as I'm aware, there's nothin= g
> in the current draft that goes against the consensus of the
> WG. If there are, please point to specific issues and to
> statements made by others (not just you) asking for the change.
>
> =A0 =A0 =A0 Cheers,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Jean-Marc
>
>
> =A0 =A0 =A0 On 11-01-24 03:10 PM, Christian Hoene wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christian - perhaps you could post a list = of
> the issues you see that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 haven't been addressed?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 */[Christian Hoene] No Stephen, these issu= es
> have been written down in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 previous emails, drafts and issues in the = Trac.
> They can be read by anybody
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 anytime. Thus, I do not see any benefit of=
> repeating them again if the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 editors continue to ignore any input. Inde= ed,
> they did not improve the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft despite sound technical reasons. /*<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 */Even if somebody is not fully involved i= n the
> technical details: It is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 very odd that despite many hundreds emails= and
> many discussions since
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 starting this WG the editors have not upda= ted
> the draft beside minor
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 changes such as the boilerplate and typos.= /*
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 */Even if the lack of any update was not > intentionally, the editors missed
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 to do their job because they were too lazy= or
> rather too busy doing other
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 thinks./*
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 */I would be sad if all the fruitful
> discussions here and all the good
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 contributions of many industry experts sho= uld
> have been in vain. Even if
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 not all requirements can be met by Opus, a=
> proper requirements document may
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 be relevant for future solutions or other = SDOs./*
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 */CH/*
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 __________________________________________= _____
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 codec mailing list
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 codec@ie= tf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/codec=
>
>
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 codec mailing list
> =A0 =A0 =A0 codec@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/codec
>
>
>
>

--0023547c895b35a3aa049ab4ab34-- From rchen@broadcom.com Tue Jan 25 16:51:04 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D9E3A68E8 for ; Tue, 25 Jan 2011 16:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjoskYpWhhAm for ; Tue, 25 Jan 2011 16:50:56 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 08AD83A68B8 for ; Tue, 25 Jan 2011 16:50:55 -0800 (PST) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 25 Jan 2011 16:55:07 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 25 Jan 2011 16:53:39 -0800 From: "Raymond (Juin-Hwey) Chen" To: "codec@ietf.org" Date: Tue, 25 Jan 2011 16:53:38 -0800 Thread-Topic: [codec] requirements #8 (new): Sample rates? Thread-Index: Acu8LF3oxga0qTIoQc+VKvvp1QHLQgAwtSiw Message-ID: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.a593fc9ae1e42af52489587fc97cf872@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6121AF613H08164811-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C75F44516D66IRVEXCHCCR01c_ Cc: "jean-marc.valin@usherbrooke.ca" Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 00:51:04 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C75F44516D66IRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree that supporting sampling rates of 48, 16, and 8 kHz all makes sense= , but I also think it would be highly desirable to support another common sampling rate used by music CDs: 44.1 kHz. For music streaming applications, a large percentage of the music sources w= ill have this 44.1 kHz sampling rate. I know it is possible to up-sample them to 48 kHz first and then pass them through the 4= 8 kHz version of Opus. However, doing such up- sampling requires additional processing power and additional latency, and i= f the sampling rate conversion is not done with a high-quality method (which usually requires higher complexity and higher de= lay), audio quality degradation may be introduced in the process. For these reasons, many people prefer not to do the 44.1 k= Hz to 48 kHz sampling rate conversion and prefer to encode the 44.1 kHz music directly instead. Therefore, it is highly desira= ble for Opus to support this 44.1 kHz sampling rate. I understand that it may be inconvenient for the SILK mode or the SILK+CELT= hybrid mode to support 44.1 kHz. However, for the CELT-only mode, my understanding is that the current CELT C code already su= pports the 44.1 kHz sampling rate. Since the CELT- only mode is also the most suitable mode to encode music, it would then mak= e perfect sense for the CELT-only mode to also support this 44.1 kHz in addition to 48 kHz. Furthermore, currently the CELT mode at 48 kHz supports frame sizes of 2.5,= 5., 10, and 20 ms to be consistent with the frame sizes of the SILK mode and SILK+CELT hybrid mode, and this results in frame= sizes and FFT window sizes that are not powers of 2, which reduces the implementation efficiency. If the CELT mode supports the= 44.1 kHz sampling rate, then since it is no longer possible to support exactly 2.5, 5, 10, and 20 ms at this sampling rate any= way, I think we might as well choose the FFT window sizes to be powers of 2 to allow more efficient implementation. Again, suc= h power of 2 FFT sizes at 44.1 kHz is already supported in the current C code for CELT, so no new development is needed. In summary, I propose that we allow the CELT-only mode of the Opus codec to= officially support the 44.1 kHz sampling rate using power of 2 FFT window sizes to avoid sampling rate conversion and to allow = the most efficient implementation. Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oman Shpount Sent: Monday, January 24, 2011 5:08 PM To: codec@ietf.org Cc: jean-marc.valin@usherbrooke.ca Subject: Re: [codec] requirements #8 (new): Sample rates? I actually do believe that the requirement is already addressed by section = 4.1 of the document. I was responding to a comment that only full band is r= equired, which is clearly not what we agreed upon and not what's in the doc= ument. _____________ Roman Shpount On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker > wrote: #8: Sample rates? Comment(by gmaxwell@...): On 11-01-24 07:14 PM, Roman Shpount wrote: > I would like to see 8 and 16 KHz as required rates for the codec to insure > interoperability with existing narrowband and wideband codecs. In other > words we should be able to negotiate 8 or 16 Khz sample rate if audio will > be transcoded for PSTN or wideband codec such as G.722 Jean-Marc wrote: > I believe such requirement for narrowband/wideband is already present, but > I don't mind making it even more explicit is necessary. I believe that we since are close enough to finalizing the draft we should try to include proposed language with our issues. Otherwise there may be no clear path forward. Some of the requirements specify that compatibility with wideband/narrowband is important, but for the avoidance of doubt, I'll suggest: At the end of 4.1. Operating space: "Because interoperation with existing wideband and narrowband facilities is essential at least one method of interoperation must be provided regardless of the codec's operating mode, sample rate, or bitrate." Of course, I would be perfectly happy to leave this out entirely (as I believe the application section 2.1 already implies the requirement) or use some other language. -- ------------------------------------+--------------------------------------= - Reporter: hoene@... | Owner: jean-marc.valin@... Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------= - Ticket URL: codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C75F44516D66IRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

I agree that supporting sampling rates of 48, 16, and 8 kHz = all makes sense, but I also think it would be highly desirable to support =

another common sampling rate used by music CDs: 44.1 kHz.&nb= sp;

 

For music streaming applications, a large percentage of the = music sources will have this 44.1 kHz sampling rate.  I know it is

possible to up-sample them to 48 kHz first and then pass the= m through the 48 kHz version of Opus.  However, doing such up-=

sampling requires additional processing power and additional latency, and if the sampling rate conversion is not done with a =

high-quality method (which usually requires higher complexit= y and higher delay), audio quality degradation may be introduced <= /span>

in the process.  For these reasons, many people prefer = not to do the 44.1 kHz to 48 kHz sampling rate conversion and prefer to

encode the 44.1 kHz music directly instead.  Therefore,= it is highly desirable for Opus to support this 44.1 kHz sampling rate.

 

I understand that it may be inconvenient for the SILK mode o= r the SILK+CELT hybrid mode to support 44.1 kHz.  However, for the

CELT-only mode, my understanding is that the current CELT C = code already supports the 44.1 kHz sampling rate.  Since the CELT-

only mode is also the most suitable mode to encode music, it would then make perfect sense for the CELT-only mode to also

support this 44.1 kHz in addition to 48 kHz. 

 

Furthermore, currently the CELT mode at 48 kHz supports fram= e sizes of 2.5, 5., 10, and 20 ms to be consistent with the frame =

sizes of the SILK mode and SILK+CELT hybrid mode, and this results in frame sizes and FFT window sizes that are not powers of 2, =

which reduces the implementation efficiency.  If the CE= LT mode supports the 44.1 kHz sampling rate, then since it is no longer <= /o:p>

possible to support exactly 2.5, 5, 10, and 20 ms at this sampling rate anyway, I think we might as well choose the FFT window <= /o:p>

sizes to be powers of 2 to allow more efficient implementation.  Again, such power of 2 FFT sizes at 44.1 kHz is alrea= dy supported

in the current C code for CELT, so no new development is nee= ded.

 

In summary, I propose that we allow the CELT-only mode of th= e Opus codec to officially support the 44.1 kHz sampling rate using

power of 2 FFT window sizes to avoid sampling rate conversio= n and to allow the most efficient implementation.

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Monday, January 24, 2011 5:08 PM
To: codec@ietf.org
Cc: jean-marc.valin@usherbrooke.ca
Subject: Re: [codec] requirements #8 (new): Sample rates?=

 

I actually do believe t= hat the requirement is already addressed by section 4.1 of the document. I was responding to a comment that only full band is required, which is clearly n= ot what we agreed upon and not what's in the document.
_____________
Roman Shpount

On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker &= lt;trac@tools.ietf.org> wrote:=

#8: Sample rates?


Comment(by gmaxwell@…):

 On 11-01-24 07:14= PM, Roman Shpount wrote:
 > I would like to see 8 and 16 KHz as required rates for the codec= to
 insure
 > interoperability with existing narrowband and wideband codecs. I= n other
 > words we should be able to negotiate 8 or 16 Khz sample rate if audio
 will
 > be transcoded for PSTN or wideband codec such as G.722

 Jean-Marc wrote:<= br>  > I believe such requirement for narrowband/wideband is already present,
 but
 > I don't mind making it even more explicit is necessary.


 I believe that we since are close enough to fina= lizing the draft we should
 try to include proposed language with our issues.  Otherwise the= re may be
 no clear path forward.

 Some of the requirements specify that compatibility with
 wideband/narrowband is important, but for the avoidance of doubt, I'l= l
 suggest:

 At the end of 4.1.  Operating space:

 "Because interoperation with existing wideband and narrowband facilities
 is essential at least one method of interoperation must be provided  regardless of the codec's operating mode, sample rate, or bitrate.&qu= ot;

 Of course, I would be perfectly happy to leave this out entirely (as = I
 believe the application section 2.1 already implies the requirement) = or
 use some other language.

--

-----------------------= -------------+---------------------------------------
 Reporter:  hoene@…           &nbs= p;     |       Owner:  jean-marc.valin@…     Type:  enhancement           &n= bsp; |      Status:  new
 Priority:  minor              = ;     |   Milestone:
Component:  requirements            | &n= bsp;   Version:
 Severity:  Active WG Document      |    Keywords:
------------------------------------+--------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment= :4>

codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C75F44516D66IRVEXCHCCR01c_-- From rchen@broadcom.com Tue Jan 25 18:22:25 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF7C3A68FD for ; Tue, 25 Jan 2011 18:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh3ezERePmlC for ; Tue, 25 Jan 2011 18:22:22 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 4F47F3A68E7 for ; Tue, 25 Jan 2011 18:22:22 -0800 (PST) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 25 Jan 2011 18:26:30 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 25 Jan 2011 18:25:01 -0800 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" , "Koen Vos" Date: Tue, 25 Jan 2011 18:24:50 -0800 Thread-Topic: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? Thread-Index: Acu80qeVb2O2YQVbQFKp89PqtLOm4wAIOeVw Message-ID: References: <1972683647.1368315.1295987844034.JavaMail.root@lu2-zimbra> <4D3F395C.7000005@octasic.com> In-Reply-To: <4D3F395C.7000005@octasic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: GVIw Gj8M JCNJ Kacr LLxy QxYL Uvzi coG4 dPCm jcA9 kmUo lOhX nl63 tWH4 ubMr vDn5; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAagBlAGEAbgAtAG0AYQByAGMALgB2AGEAbABpAG4AQABvAGMAdABhAHMAaQBjAC4AYwBvAG0AOwBrAG8AZQBuAC4AdgBvAHMAQABzAGsAeQBwAGUALgBuAGUAdAA7AHMAdABlAHAAaABlAG4ALgBiAG8AdAB6AGsAbwBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {E224A981-EBE1-4348-9F62-F08D8343F59C}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Wed, 26 Jan 2011 02:24:50 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIAAjADEAMgAgACgAYwBsAG8AcwBlAGQAKQA6ACAAYgBpAHQALQBlAHgAYQBjAHQAIAB2AHMALgAgAGIAaQB0AC0AYwBvAG0AcABhAHQAaQBiAGwAZQA/AA== x-cr-puzzleid: {E224A981-EBE1-4348-9F62-F08D8343F59C} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 612159DC1VG12409874-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "codec@ietf.org" , Stephen Botzko Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 26 Jan 2011 02:22:25 -0000 TXkgb3BpbmlvbiBpcyB0aGF0IHdlIHNob3VsZCBub3QgcmVxdWlyZSBiaXQtZXhhY3RuZXNzLiAg VGhlcmUgYXJlIG1hbnkgZXhhbXBsZXMgb2YgcHJldmlvdXMgY29kZWMNCnN0YW5kYXJkcyB0aGF0 IGRpZCBub3QgcmVxdWlyZSBiaXQtZXhhY3RuZXNzLCBpbmNsdWRpbmcgYm90aCByb3lhbHR5LWJl YXJpbmcgY29kZWNzIChzdWNoIGFzIE1QRUcpDQphbmQgcm95YWx0eS1mcmVlIGNvZGVjcyAoc3Vj aCBhcyBvdXIgQnJvYWRWb2ljZS9CVjE2L0JWMzIpLCBzbyBJIGRvbid0IHNlZSBhbnkgcmVhbCBy ZWFzb24gd2h5IHdlDQpjYW4ndCBmb2xsb3cgdGhhdCBzYW1lIHJvdXRlLg0KDQpJIGNhbiBzZWUg YXQgbGVhc3QgdHdvIGltcG9ydGFudCBhZHZhbnRhZ2VzIGZvciBub3QgcmVxdWlyaW5nIGJpdC1l eGFjdG5lc3M6DQooMSkgaXQgYWxsb3dzIGZ1dHVyZSBpbm5vdmF0aW9ucyB0byBpbXByb3ZlIHRo ZSBwZXJmb3JtYW5jZSBvZiB0aGUgY29kZWMgd2l0aG91dCBicmVha2luZyB0aGUgYml0LQ0Kc3Ry ZWFtIGNvbXBhdGliaWxpdHksIGFuZA0KKDIpIGl0IGFsbG93cyB0aGUgY29kZWMgaW1wbGVtZW50 ZXJzIHRoZSBncmVhdGVzdCBmbGV4aWJpbGl0eSBpbiBpbXBsZW1lbnRpbmcgdGhlIGNvZGVjcyBp biB3YXlzDQp0aGF0IGFyZSBtb3N0IGVmZmljaWVudCBmb3IgdGhlIHBhcnRpY3VsYXIgaGFyZHdh cmUgb3IgcHJvY2Vzc29yIGFyY2hpdGVjdHVyZSB0aGV5IGhhdmUuDQpIYXZpbmcgYSBiaXQtZXhh Y3Qgc3RhbmRhcmQgd2lsbCBraWxsIGJvdGguDQoNClRoZSBtYWluIGRyYXdiYWNrIG9mIGEgbm9u LWJpdC1leGFjdCBzdGFuZGFyZCBpcyB0aGF0IHRoZSB2ZXJpZmljYXRpb24gb2YgdGhlIGNvbmZv cm1hbmNlIG9mIGNvZGVjDQppbXBsZW1lbnRhdGlvbnMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2Fy ZCBhcyB3aXRoIGEgYml0LWV4YWN0IHN0YW5kYXJkLiAgSG93ZXZlciwgSSBkb24ndCB0aGluaw0K dGhhdCBpcyBhIHNob3cgc3RvcHBlciBvciBldmVuIGEgZGlmZmljdWx0IHByb2JsZW0uICBUaGVy ZSBhcmUgbWFueSBwb3NzaWJsZSB3YXlzIHRvIGRvIHNvZnR3YXJlLQ0KYmFzZWQgb2JqZWN0aXZl IG1lYXN1cmVtZW50cyB0byB2ZXJpZnkgdGhhdCBhIGNhbmRpZGF0ZSBjb2RlYyBpbXBsZW1lbnRh dGlvbiBpcyBsaWtlbHkgdG8gc291bmQNCmVzc2VudGlhbGx5IGluZGlzdGluZ3Vpc2hhYmxlIGZy b20gdGhlIG91dHB1dCBvZiB0aGUgcmVmZXJlbmNlIGNvZGVjLiAgV2UgaGFkIHByZXZpb3VzbHkg bWVhc3VyZWQNCnRoZSBTTlJzIGFuZCBQRVNRIHNjb3JlcyBvZiBhIGxhcmdlIG51bWJlciBvZiB0 ZXN0IGZpbGVzIHVzaW5nIHRoZSByZWZlcmVuY2UgY29kZWMgYW5kIGNhbmRpZGF0ZQ0KY29kZWMg YW5kIGV4YW1pbmVkIHRoZSBzdGF0aXN0aWNhbCBkaXN0cmlidXRpb24gb2YgdGhlIGRpZmZlcmVu Y2VzIGluIHRoZSBzY29yZXMuICBKZWFuLU1hcmMganVzdA0KcG9zdGVkIGEgbmljZSBsaXR0bGUg TWF0bGFiIGNvZGUgdGhhdCBidWlsdCB1cG9uIHBzeWNob2Fjb3VzdGljIG1vZGVsaW5nLCBOTVIs IGF2ZXJhZ2VzLCBvdXRsaWVycw0KY2hlY2tpbmcsIGV0Yy4gIEtvZW4gYWxzbyBtZW50aW9uZWQg YW5vdGhlciB0b29sLiAgRXZlbiBpZiB0aGVzZSB0b29scyBhbmQgbWV0aG9kb2xvZ2llcyBhcmUg bm90DQpwZXJmZWN0IHlldCwgd2l0aCBzb21lIGFkZGl0aW9uYWwgdHVuaW5nIG9mIHRoZWlyIGFs Z29yaXRobXMgYW5kIHBhcmFtZXRlcnMsIGl0IGlzIHJlYWxseSBub3QgdGhhdA0KZGlmZmljdWx0 IHRvIGNvbWUgdXAgd2l0aCBvYmplY3RpdmUsIHNvZnR3YXJlLWJhc2VkIHZlcmlmaWNhdGlvbiBt ZXRob2RzIHRoYXQgd2lsbCBnaXZlIHlvdSBhIGhpZ2gNCmxldmVsIG9mIGNvbmZpZGVuY2Ugd2hl dGhlciBhIGNhbmRpZGF0ZSBjb2RlYyB3aWxsIHNvdW5kIGF0IGxlYXN0IGFzIGdvb2QgYXMgdGhl IHJlZmVyZW5jZSBjb2RlYw0KKG9yIHBlcmhhcHMgYmV0dGVyIGlmIGltcHJvdmVtZW50cyBhcmUg bWFkZSkuDQoNCkkgbGlrZSBKZWFuLU1hcmMncyBpZGVhIG9mIGhhdmluZyBib3RoIGEgZmxvYXRp bmctcG9pbnQgcmVmZXJlbmNlIGNvZGVjIGFuZCBhIGZpeGVkLXBvaW50DQpyZWZlcmVuY2UgY29k ZWMuIEZvciBwZW9wbGUgd2hvIGRvbid0IHdhbnQgdG8gcnVuIHRoZSByaXNrIG9mIGRlZ3JhZGlu ZyBhdWRpbyBxdWFsaXR5IHRocm91Z2gNCnRoZWlyIG93biBmaXhlZC1wb2ludCBhbGdvcml0aG0g Y29udmVyc2lvbiwgdGhleSBjYW4ganVzdCBpbXBsZW1lbnQgdGhlIGZpeGVkLXBvaW50IHJlZmVy ZW5jZQ0KY29kZWMgaW4gYSBiaXQtZXhhY3QgbWFubmVyLiAgRm9yIHBlb3BsZSB3aG8gd2FudCB0 byBpbXBsZW1lbnQgdGhlIGNvZGVjIGluIGZsb2F0aW5nLXBvaW50IChlLmcuDQpvbiBjb21wdXRl cnMpLCB0aGUgZWFzaWVzdCB3YXkgaXMganVzdCB0byB1c2UgdGhlIGZsb2F0aW5nLXBvaW50IHJl ZmVyZW5jZSBjb2RlIGFzIGlzLiAgSW4gYm90aA0KY2FzZXMsIHRoZSBjb25mb3JtYW5jZSB2ZXJp ZmljYXRpb24gd2lsbCBiZSBxdWl0ZSBlYXN5Lg0KDQpSYXltb25kDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBjb2RlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29kZWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplYW4tTWFyYyBWYWxpbg0KU2VudDogVHVl c2RheSwgSmFudWFyeSAyNSwgMjAxMSAxMjo1OCBQTQ0KVG86IEtvZW4gVm9zDQpDYzogY29kZWNA aWV0Zi5vcmc7IFN0ZXBoZW4gQm90emtvDQpTdWJqZWN0OiBSZTogW2NvZGVjXSByZXF1aXJlbWVu dHMgIzEyIChjbG9zZWQpOiBiaXQtZXhhY3QgdnMuIGJpdC1jb21wYXRpYmxlPw0KDQpNeSBwcmVm ZXJlbmNlIGFjdHVhbGx5IGdvZXMgd2l0aCB1c2luZyBib3RoIGZpeGVkLXBvaW50IGFuZCBmbG9h dGluZyBwb2ludC4NClRoYXQgd2F5LCBpbXBsZW1lbnRlcnMgb2YgZmxvYXRpbmctcG9pbnQgZGVj b2RlciBjYW4gY29tcGFyZSB3aXRoIHRoZSBmbG9hdA0KdmVyc2lvbiBhbmQgaW1wbGVtZW50ZXJz IG9mIHRoZSBmaXhlZC1wb2ludCBkZWNvZGVyIGNhbiBjb21wYXJlIHdpdGggdGhlDQpmaXhlZC1w b2ludCB2ZXJzaW9uLg0KDQpUaGlzIGlzIG5vdCB1bmhlYXJkIG9mIGVpdGhlciwgaWYgeW91IGxv b2sgYXQgdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbg0Kb2YgdGhlIDNHUFAoMj8pIEVWUkMg Y29kZWMsIHRoZSBkaXN0cmlidXRpb24gaW5jbHVkZXMgdHdvIHNldHMgb2Ygb3V0cHV0DQp2ZWN0 b3JzLiBPbmUgaXMgZm9yIGEgZml4ZWQtcG9pbnQgaW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIDMx LWJpdCBwcmVjaXNpb24NCmluIHRoZSBtdWx0aXBsaWNhdGlvbnMgYW5kIHRoZSBvdGhlciBvbmUg aXMgZm9yIDMyLWJpdCBwcmVjaXNpb24uIFlvdSBqdXN0DQpjaG9vc2Ugd2hhdGV2ZXIgaXMgbW9y ZSBlZmZpY2llbnQgZm9yIHlvdXIgRFNQIGFuZCB1c2UgdGhlIGFwcHJvcHJpYXRlDQp0ZXN0dmVj dG9ycyBmb3IgdGVzdGluZy4NCg0KICAgICAgICBKZWFuLU1hcmMNCg0KT24gMTEtMDEtMjUgMDM6 MzcgUE0sIEtvZW4gVm9zIHdyb3RlOg0KPiBBIHNpbWlsYXIgdG9vbCBpcyBpbiB0aGUgY29kZSBp biBzaWxrXHRlc3Rcc2lnbmFsQ29tcGFyZS5jLiAgSXQncyBiYXNlZCBvbiBMUEMsIGFuZCBtZWFz dXJlcyB0aGUgU05SIGluIGEgcGFydGlhbGx5LXdoaXRlbmVkIGRvbWFpbi4gIEZvciBtdXNpYyB0 aGUgY3JpdGljYWwtYmFuZCBhcHByb2FjaCBvZiBKZWFuLU1hcmMncyB0b29sIG1heSB3b3JrIGJl dHRlciwgbm90IHN1cmUuDQo+DQo+IE9uZSBxdWVzdGlvbiBpcyBhYm91dCB3aGF0IGltcGxlbWVu dGF0aW9uIHNob3VsZCBiZSB0aGUgcmVmZXJlbmNlIGZvciBjb21wbGlhbmNlIHRlc3Rpbmc6IGZs b2F0aW5nLXBvaW50IG9yIGZpeGVkLXBvaW50Pw0KPg0KPiBBIGZpeGVkLXBvaW50IHJlZmVyZW5j ZSBhbGxvd3MgZm9yIGJpdC1leGFjdCBpbXBsZW1lbnRhdGlvbnMsIHdoaWNoIGlzIG5pY2UuICBB bmQgZml4ZWQtcG9pbnQgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9ucyBhcmUgdGhlIG5vcm0gaW4g c3BlZWNoIGNvZGluZy4NCj4gSG93ZXZlciwgQ0VMVCdzIGZsb2F0aW5nLXBvaW50IGltcGxlbWVu dGF0aW9uIGhhcyBhIGxhcmdlciBkeW5hbWljIHJhbmdlIHRoYW4gdGhlIGZpeGVkLXBvaW50IHZl cnNpb24sIGFuZCBpcyB0aHVzIGFyZ3VhYmxlIGJldHRlci4gIEEgZml4ZWQtcG9pbnQgcmVmZXJl bmNlIGNvdWxkIG5vdCB0ZXN0IHRoaXMgZXh0cmEgZHluYW1pYyByYW5nZS4NCj4NCj4gQW55IHN1 Z2dlc3Rpb25zPw0KPiBrb2VuLg0KPg0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQo+IEZyb206ICJKZWFuLU1hcmMgVmFsaW4iPGplYW4tbWFyYy52YWxpbkBvY3Rhc2ljLmNvbT4N Cj4gVG86ICJTdGVwaGVuIEJvdHprbyI8c3RlcGhlbi5ib3R6a29AZ21haWwuY29tPg0KPiBDYzog Y29kZWNAaWV0Zi5vcmcNCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwgMjAxMSA4OjI5OjI1 IEFNDQo+IFN1YmplY3Q6IFJlOiBbY29kZWNdIHJlcXVpcmVtZW50cyAjMTIgKGNsb3NlZCk6IGJp dC1leGFjdCB2cy4gYml0LWNvbXBhdGlibGU/DQo+DQo+IEp1c3QgdG8gZ2l2ZSBhbiBpZGVhIG9m IHdoYXQgSSdtIHRhbGtpbmcgYWJvdXQgaW4gdGVybXMgb2YgY29tcGxpYW5jZSB0ZXN0LA0KPiBo ZXJlJ3MgYSB0b29sIEkganVzdCB3cm90ZSB0aGF0IGNvdWxkIGJlIHVzZWQgZm9yIHRlc3Rpbmcu IFRoZXJlIG1heSBuZWVkDQo+IHRvIGJlIGEgYml0IG9mIHJlZmluaW5nIGFuZCBwbGF5aW5nIHdp dGggdGhlIHRocmVzaG9sZHMsIGJ1dCB0aGUgbWFpbiBpZGVhDQo+IGlzIHRoZXJlOg0KPg0KPiBo dHRwOi8vam12YWxpbi5jYS9taXNjX3N0dWZmL2NvbXBhcmUubQ0KPg0KPiBJdCB3b3JrcyB3aXRo IE9jdGF2ZSwgYW5kIGlzIGxpa2VseSB2ZXJ5IGVhc3kgdG8gZ2V0IHRvIHdvcmsgd2l0aCBNYXRs YWIuDQo+IEFueSBjb21tZW50cz8NCj4NCj4gICAgICAgSmVhbi1NYXJjDQo+DQo+IE9uIDExLTAx LTI1IDEwOjU3IEFNLCBKZWFuLU1hcmMgVmFsaW4gd3JvdGU6DQo+PiBIaSBTdGVwaGVuLA0KPj4N Cj4+IFRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gaW5jbHVkZXMgYm90aCBmbG9hdGluZy1w b2ludCBhbmQgZml4ZWQtcG9pbnQsDQo+PiBzbyBJJ20gbm90IHN1cmUgaXQncyBhIGdvb2QgaWRl YSB0byBzYXkgdGhhdCBvbmUgaXMgImJldHRlciIgdGhhbiB0aGUNCj4+IG90aGVyLiBBcyBmb3Ig SUVFRSA3NTQtMjAwOCwgYXMgZmFyIGFzIEkga25vdyBpdCBpcyBub3QgYSAiYml0LWV4YWN0Ig0K Pj4gc3RhbmRhcmQgZWl0aGVyIHdoZW4gaXQgY29tZXMgdG8gc29tZSBvcGVyYXRpb25zIChlLmcu IHRyYW5zY2VuZGVudGFsDQo+PiBmdW5jdGlvbikgYW5kIGV2ZW4gZm9yIG90aGVyIG9wZXJhdGlv bnMsIG1vc3QgY29tcGlsZXJzIEkga25vdyBvZiBhcmUgbm90DQo+PiBzdHJpY3QgSUVFRS03NTQg KGF0IGxlYXN0IGJ5IGRlZmF1bHQpIGJlY2F1c2Ugb2YgaXNzdWVzIHN1Y2ggYXMgdGhlIHg4Ng0K Pj4gZXh0ZW5kZWQgcHJlY2lzaW9uIG9wZXJhdGlvbnMuDQo+Pg0KPj4gUmVnYXJkaW5nIE1QRUcg Yml0LXN0cmVhbXMsIEknbSBub3Qgc3VyZSB3aGVyZSB0byBnZXQgY29uZmlybWF0aW9uLCBidXQN Cj4+IHRoaXMgaXMgd2hhdCBXaWtpcGVkaWEgaGFzIHRvIHNheSBhYm91dCBNUEVHLTEgTGF5ZXIg MzoNCj4+DQo+Pg0KPj4gIkRlY29kaW5nLCBvbiB0aGUgb3RoZXIgaGFuZCwgaXMgY2FyZWZ1bGx5 IGRlZmluZWQgaW4gdGhlIHN0YW5kYXJkLiBNb3N0DQo+PiBkZWNvZGVycyBhcmUgImJpdHN0cmVh bSBjb21wbGlhbnQiLCB3aGljaCBtZWFucyB0aGF0IHRoZSBkZWNvbXByZXNzZWQNCj4+IG91dHB1 dCDDouKCrOKAnCB0aGF0IHRoZXkgcHJvZHVjZSBmcm9tIGEgZ2l2ZW4gTVAzIGZpbGUgw6Ligqzi gJwgd2lsbCBiZSB0aGUgc2FtZSwgd2l0aGluDQo+PiBhIHNwZWNpZmllZCBkZWdyZWUgb2Ygcm91 bmRpbmcgdG9sZXJhbmNlLCBhcyB0aGUgb3V0cHV0IHNwZWNpZmllZA0KPj4gbWF0aGVtYXRpY2Fs bHkgaW4gdGhlIElTTy9JRUMgc3RhbmRhcmQgZG9jdW1lbnQgKElTTy9JRUMgMTExNzItMykuDQo+ PiBUaGVyZWZvcmUsIGNvbXBhcmlzb24gb2YgZGVjb2RlcnMgaXMgdXN1YWxseSBiYXNlZCBvbiBo b3cgY29tcHV0YXRpb25hbGx5DQo+PiBlZmZpY2llbnQgdGhleSBhcmUgKGkuZS4sIGhvdyBtdWNo IG1lbW9yeSBvciBDUFUgdGltZSB0aGV5IHVzZSBpbiB0aGUNCj4+IGRlY29kaW5nIHByb2Nlc3Mp LiINCj4+DQo+Pg0KPj4gVGhhdCBpbXBsaWVzIGEgc3RhbmRhcmQgYmFzZWQgb24gImluZmluaXRl IHByZWNpc2lvbiIsIHdpdGggYSBkZWdyZWUgb2YNCj4+IHRvbGVyYW5jZSBmb3IgZGlmZmVyZW50 IGltcGxlbWVudGF0aW9ucy4NCj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4gSmVhbi1NYXJjDQo+Pg0K Pj4gT24gMTEtMDEtMjUgMTA6NDIgQU0sIFN0ZXBoZW4gQm90emtvIHdyb3RlOg0KPj4+IEl0IHNl ZW1zIHRvIG1lIHRoYXQgdGhlIHJlZmVyZW5jZSBlbmNvZGVyIGFuZCBkZWNvZGVyIHdpbGwgYmUg Yml0IGV4YWN0IGZvcg0KPj4+IGEgZ2l2ZW4gZmxvYXRpbmcgcG9pbnQgZm9ybWF0LCBjb3JyZWN0 PyBTbyBvbmUgY291bGQgc3BlY2lmeSBJRUVFIDc1NC0yMDA4DQo+Pj4gd2hlbiBiaXQgZXhhY3Ru ZXNzIGlzIG5lZWRlZCBpbiB0aGUgcmVmZXJlbmNlIChmb3IgaW5zdGFuY2UgcmVncmVzc2lvbg0K Pj4+IHRlc3RpbmcpLCBidXQgbm90IHJlcXVpcmUgaXQgZm9yIGNvbXBsaWFuY2UuDQo+Pj4NCj4+ PiBGb2xrcyB3aG8gYXJlIG1vZGlmeWluZyB0aGUgcmVmZXJlbmNlIGVuY29kZXIgb3IgZGVjb2Rl ciBhbGdvcml0aG1zIGFyZSAib24NCj4+PiB0aGVpciBvd24iIGFzIGZhciBhcyBhdWRpbyBxdWFs aXR5IGlzIGNvbmNlcm5lZC4gVGhvdWdoIEkgYWdyZWUgd2l0aA0KPj4+IFN0ZXBoYW4gdGhhdCB3 ZSBuZWVkIHRvIGFkZHJlc3MgY29tcGxpYW5jZSAod2hlbiBleGFjdGx5IGRvZXMgYSBwb3J0ZWQg b3INCj4+PiBvdGhlcndpc2UgbW9kaWZpZWQgZW5jb2Rlci9kZWNvZGVyIGJlY29tZSBub24tY29t cGxpYW50PykuDQo+Pj4NCj4+PiBTdGVwaGVuIEJvdHprbw0KPj4+DQo+Pj4gT24gVHVlLCBKYW4g MjUsIDIwMTEgYXQgOTozNCBBTSwgUm9tYW4gU2hwb3VudDxyb21hbkB0ZWx1cml4LmNvbQ0KPj4+ IDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiAgd3JvdGU6DQo+Pj4NCj4+PiBPbmUgbW9yZSBj b25jZXJuIHRoYXQgSSBoYXZlIHJlbGF0ZWQgdG8gYml0IGV4YWN0bmVzcyBpcyBjb2RlYw0KPj4+ IHJlZ3Jlc3Npb24gdGVzdGluZy4gT25lIGNhbiBwcm9kdWNlIGEgbm9uLWJpdC1leGFjdCBlbmNv ZGVyIHRoYXQNCj4+PiBwcm9kdWNlcyByZWFzb25hYmxlIHJlc3VsdHMgZm9yIGEgcmVmZXJlbmNl IGRlY29kZXIsIGJ1dCBpZiBwYWlyZWQgd2l0aA0KPj4+IGEgbW9kaWZpZWQsIG5vbi1iaXQtZXhh Y3QgZGVjb2RlciB3aWxsIHByb2R1Y2Ugc2lnbmlmaWNhbnQgYXVkaW8NCj4+PiBhcnRpZmFjdHMu IFNpbmNlIG5laXRoZXIgZGVjb2RlciBvciBlbmNvZGVyIGFyZSBiaXQgZXhhY3Qgd2Ugd2lsbCBu ZWVkDQo+Pj4gdG8gaGF2ZSBhIHRlc3QgcHJvY2VkdXJlIHRoYXQgd2lsbCB2YWxpZGF0ZSB0aGF0 IGJvdGggZW5jb2RlciBvcg0KPj4+IGRlY29kZXIgd2lsbCBub3QgYnJlYWsgYW55IHN0YW5kYXJk IGNvbXBsaWFudCBhbmQgbm9uLWJpdC1leGFjdA0KPj4+IGVuY29kZXJzIG9yIGRlY29kZXJzLiBO b3QgcmVhbGx5IHN1cmUgaG93IHRoaXMgY2FuIGJlIGRvbmUuDQo+Pj4NCj4+PiBJIG1pZ2h0IGJl IHdyb25nLCBidXQgSSB0aGluayBNUEVHIGRlY29kZXJzIGFyZSBiaXQgZXhhY3QgYW5kIGVuY29k ZXJzDQo+Pj4gYXJlIG5vdC4NCj4+PiBfX19fX19fX19fX19fDQo+Pj4gUm9tYW4gU2hwb3VudA0K Pj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIFR1ZSwgSmFuIDI1LCAyMDExIGF0IDEyOjAzIEFNLCBKZWFu LU1hcmMgVmFsaW48am12YWxpbkBqbXZhbGluLmNhDQo+Pj4gPG1haWx0bzpqbXZhbGluQGptdmFs aW4uY2E+PiAgd3JvdGU6DQo+Pj4NCj4+PiBIaSBTdGVwaGFuLA0KPj4+DQo+Pj4gSSB1bmRlcnN0 YW5kIHlvdXIgY29uY2VybiBhbmQgSSdkIGJlIGludGVyZXN0ZWQgaWYgeW91IGhhdmUNCj4+PiBh bHRlcm5hdGl2ZSB3YXlzIG9mIGhhbmRsaW5nIHRoZSBsaWNlbnNpbmcgdG8gYXZvaWQgYW55IGlz c3VlLiBJdCdzDQo+Pj4gbm90IGxpa2UgdGhpcyBpcyBhIHVuaXF1ZSBzaXR1YXRpb24uIEFzIGZh ciBhcyBJIGtub3csIG1vc3QgKGFsbD8pDQo+Pj4gTVBFRyBjb2RlY3MgaGF2ZSBzaW1pbGFyIG5v bi1iaXQgZXhhY3QgZGVmaW5pdGlvbnMuIEkgaGF2ZSBhbHNvDQo+Pj4gaGVhcmQgdGhhdCB0aGV5 IGFsc28gcmVxdWlyZSBzb21lIElQUiBsaWNlbnNpbmcuLi4NCj4+Pg0KPj4+IEluIGdlbmVyYWwg dGhlIGlzc3VlIG9mIGJpdC1leGFjdG5lc3MgaGFzIGJlZW4gZGlzY3Vzc2VkIGFuZCBzbyBmYXIN Cj4+PiBJIGRvbid0IHJlY2FsbCBtYW55IGFyZ3VpbmcgaW4gZmF2b3Igb2YgYSBiaXQtZXhhY3Qg ZGVmaW5pdGlvbi4NCj4+PiBNb3N0IG9mIHRoZSBjb25jZXJucyB0aGF0IGhhdmUgYmVlbiBleHBy ZXNzZWQgYXJlIHNvbHZlZCBieQ0KPj4+IGNvbnNpZGVyaW5nIHRoYXQgbm9uLWJpdGV4YWN0IGRv ZXMgbm90IG1lYW4geW91IGNhbm5vdCBiZSBiaXQtZXhhY3QNCj4+PiB3aXRoIHRoZSByZWZlcmVu Y2UgZW5jb2Rlci4gSXQgbWVyZWx5IG1lYW5zIHRoYXQgeW91IGRvbid0ICpoYXZlKg0KPj4+IHRv LiBTbyByZWdhcmRsZXNzIG9mIGhvdyBjb25mb3JtYW5jZSBpcyBkZWZpbmVkIGV4YWN0bHksIG9u ZSBhbHdheXMNCj4+PiBoYXMgdGhlIG9wdGlvbiBvZiBiZWluZyBiaXQtZXhhY3Qgd2l0aCB0aGUg cmVmZXJlbmNlDQo+Pj4gaW1wbGVtZW50YXRpb24sIHdoaWNoIG9idmlvdXNseSBndWFyYW50ZWVz IGNvbXBsaWFuY2UuDQo+Pj4NCj4+PiBBcyBmb3IgbGFuZ3VhZ2UgbWVudGlvbmluZyBjb21wbGlh bmNlLCBJIGJlbGlldmUgaXQgYmVsb25ncyBtb3JlIHRvDQo+Pj4gdGhlIGd1aWRlbGluZXMgKGl0 J3Mgbm90IGEgcmVxdWlyZW1lbnQgb2YgdGhlIGNvZGVjIGl0c2VsZiksIHdoaWNoDQo+Pj4gaW5j bHVkZXMgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPj4+DQo+Pj4gNC4gVG8gcmVkdWNlIHRoZSByaXNr IG9mIGJpYXMgdG93YXJkcyBjZXJ0YWluIENQVS9EU1AgYXJjaGl0ZWN0dXJlcywNCj4+PiBpZGVh bGx5IHRoZSBkZWNvZGVyIHNwZWNpZmljYXRpb24gc2hvdWxkIG5vdCByZXF1aXJlICJiaXQtZXhh Y3QiDQo+Pj4gY29uZm9ybWFuY2Ugd2l0aCB0aGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLiBU aGUgb3V0cHV0IG9mIGENCj4+PiBkZWNvZGVyIGltcGxlbWVudGF0aW9uIHNob3VsZCBvbmx5IGJl ICJjbG9zZSBlbm91Z2giIHRvIHRoZQ0KPj4+IG91dHB1dCBvZiB0aGUgcmVmZXJlbmNlIGRlY29k ZXIuIEEgY29tcGFyaXNvbiB0b29sIHNob3VsZCBiZQ0KPj4+IHByb3ZpZGVkIGFsb25nIHdpdGgg dGhlIGNvZGVjIHRvIHZlcmlmeSBvYmplY3RpdmVseSB0aGF0IHRoZQ0KPj4+IG91dHB1dCBvZiBh IGRlY29kZXIgaXMgbGlrZWx5IHRvIGJlIHBlcmNlcHR1YWxseQ0KPj4+IGluZGlzdGluZ3Vpc2hh YmxlIGZyb20gdGhhdCBvZiB0aGUgcmVmZXJlbmNlIGRlY29kZXIuIEhvd2V2ZXIsDQo+Pj4gYW4g aW1wbGVtZW50YXRpb24gbWF5IHN0aWxsIHdpc2ggdG8gcHJvZHVjZSBhbiBvdXRwdXQgdGhhdCBp cw0KPj4+IGJpdC1leGFjdCB3aXRoIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gdG8gc2lt cGxpZnkgdGhlDQo+Pj4gdGVzdGluZyBwcm9jZWR1cmUuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gQ2hl ZXJzLA0KPj4+DQo+Pj4gSmVhbi1NYXJjDQo+Pj4NCj4+Pg0KPj4+IE9uIDExLTAxLTI0IDExOjAy IFBNLCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4+Pg0KPj4+IEhpIGFsbDoNCj4+Pg0KPj4+IExl dCBtZSBzcGVhayBvbmNlIG1vcmUgYWdhaW5zdCB0aGlzIGRlY2lzaW9uIChpZiBzdWNoIGENCj4+ PiBkZWNpc2lvbiB3ZXJlDQo+Pj4gcmVhbGx5IG1hZGU7IHNlZSB0aGUgcC5zLikuDQo+Pj4NCj4+ PiBUaGVyZSBhcmUgY3VycmVudGx5IHRocmVlIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoZSBj b2RlYw0KPj4+IGRyYWZ0IGFuZC9vcg0KPj4+IGl0cyBwcmVkZWNlc3NvcnMuIFRoZSBYaXBoIGRp c2Nsb3N1cmUgaXMgYXQgdGhpcyBwb2ludCBhDQo+Pj4gcGxhY2Vob2xkZXINCj4+PiAoWGlwaCBm b2xrczogaXQncyB0aW1lIHRvIGZpeCB0aGF0ISkuIEhvd2V2ZXIsIHRoZSB0d28gb3RoZXINCj4+ PiBkaXNjbG9zdXJlcw0KPj4+IG9uIGZpbGUgcHJvdmlkZSBhIHBhdGVudCBncmFudCBvbmx5IGZv ciBuZWNlc3NhcnkgcGF0ZW50IGNsYWltcw0KPj4+IGFuZCBvbmx5DQo+Pj4gd2hlbiB0aGUgc3Rh bmRhcmQgaXMgcHJhY3RpY2VkIGluIGZ1bGwgY29tcGxpYW5jZS4gVGhlc2UgdGVybXMgKGluDQo+ Pj4gdmFyaW91cyBmb3JtdWxhdGlvbnMpIGFyZSBxdWl0ZSBjb21tb24uDQo+Pj4NCj4+PiBJbiBv cmRlciB0byBlbnN1cmUgb25lIGhhcyBhIGxpY2Vuc2UgKG9yIGNhbiByZWx5IG9uIGEgbm9uLWFz c2VydA0KPj4+IGNvdmVuYW50KSwgb25lIGhhcyB0byBlbnN1cmUgb25lIG1lZXRzIHRoZSBjb25k aXRpb25zIHNldCBieSB0aGUNCj4+PiByaWdodGhvbGRlci4gT24gc3R1ZmYgc3VjaCBhcyByZWNp cHJvY2l0eSBjbGF1c2VzIHRoaXMgaXMNCj4+PiBzaW1wbGUuIE9uDQo+Pj4gY29tcGxpYW5jZSwg aXQncyBub3QgYWx3YXlzIGVhc3kuDQo+Pj4NCj4+PiBUaGUgdHJhZGl0aW9uYWwgY29tcGxpYW5j ZSB0ZXN0IGZvciBhIG1lZGlhIGNvZGVjIGlzIGENCj4+PiBzdGltdWx1cy1yZXNwb25zZQ0KPj4+ IHRlc3Q6IHlvdSBmZWVkIHRlc3QgdmVjdG9ycyBpbnRvIHRoZSBjb2RlYywgYW5kIHlvdSBnZXQN Cj4+PiByZXN1bHRzLiBJZiB0aGUNCj4+PiByZXN1bHRzIG1hdGNoLCB5b3UgYXJlIGluIGNvbXBs aWFuY2UsIGlmIG5vdCwgeW91IGFyZSBub3QuIFNpbXBsZS4NCj4+Pg0KPj4+IFdpdGhvdXQgYml0 IGV4YWN0bmVzcywgdGhlIGNvbXBsaWFuY2UgY3JpdGVyaWEgaGF2ZSB0byBiZSBkZWZpbmVkDQo+ Pj4gZGlmZmVyZW50bHkuIFdlIGNhbiBkbyBzbywgYW5kLCBpbmRlZWQsIEkgcmVjYWxsIHRoYXQg dGhpcyBoYXMgYmVlbg0KPj4+IG1lbnRpb25lZCBhcyBvbmUgcGxhbiBmb3J3YXJkLiBIb3dldmVy LCBJIGhhdmUgc2VlbiB6ZXJvDQo+Pj4gYWN0aXZpdHkgaW4gdGhpcw0KPj4+IGRpcmVjdGlvbiwg YW5kIEkgaGF2ZSBhbHNvIG5vdCBzZWVuIGFueSBsYW5ndWFnZSB0aGF0IG1lbnRpb25zDQo+Pj4g dGhpcyBpbiB0aGUNCj4+PiByZXF1aXJlbWVudHMgZHJhZnQuIEkgdGhpbmsgdGhhdCB0aGUgc3Vi amVjdCBvZiBjb21wbGlhbmNlDQo+Pj4gdGVzdHMsIGF0DQo+Pj4gbGVhc3QgaW4gaXRzIG1vc3Qg YmFzaWMgb3V0bGluZSwgbmVlZHMgdG8gYmUgZG9jdW1lbnRlZCBpbiB0aGUNCj4+PiByZXF1aXJl bWVudHMgZHJhZnQuIFRoZSBkZXRhaWxzIGNhbiBiZSB0YWtlbiBjYXJlIG9mIGVsc2V3aGVyZQ0K Pj4+IGFuZCBsYXRlciwNCj4+PiBidXQgbm90IHRvbyBtdWNoIGxhdGVyLiBJdCBzaG91bGQgYmUg Y2xlYXIgdGhhdCBhIGNvZGVjDQo+Pj4gY2FuZGlkYXRlIChpZg0KPj4+IHRoZXJlIHdlcmUgbW9y ZSB0aGFuIG9uZSkgbmVlZHMgdG8gaGF2ZSBjb21wbGlhbmNlIGNyaXRlcmlhDQo+Pj4gZGVmaW5l ZCBiZWZvcmUNCj4+PiB0aGF0IGNvZGVjIGNhbmRpZGF0ZSBjYW4gYmVjb21lIGFuIFJGQy4gV2l0 aG91dCB0aGF0LCB0aGUga2V5DQo+Pj4gZ29hbCBvZiB0aGUNCj4+PiBXRywgYSByZWFzb25hYmx5 IGZyZWVseSBwcmFjdGljYWJsZSBjb2RlYywgaXMganVzdCBub3QNCj4+PiBhY2hpZXZhYmxlIGlu IHRoZQ0KPj4+IGN1cnJlbnQgbGVnYWwgZW52aXJvbm1lbnQgKHdoaWNoIGluY2x1ZGVzLCBpbiB0 aGlzIGNhc2UsIHRoZSBJUFINCj4+PiBkaXNjbG9zdXJlcyBvbiBmaWxlKS4NCj4+Pg0KPj4+IE9m IGNvdXJzZSwgaXQgd291bGQgYmUgc29vb29vIG11Y2ggc2ltcGxlciBpZiB3ZSB3b3VsZCBtYW5k YXRlDQo+Pj4gYSBiaXQgZXhhY3QNCj4+PiBkZWNvZGVyLi4uIElzIGl0IHJlYWxseSB0aGF0IHJl c3RyaWN0aW5nIHRvIHJlcXVpcmUgdGhhdD8NCj4+Pg0KPj4+IFN0ZXBoYW4NCj4+Pg0KPj4+IFAu cy46IGZvciB0aGUgSUVURiBwcm9jZWR1cmVzIG5ld2NvbWVyczogaHVtbXMgdGFrZW4gYXQNCj4+ PiBtZWV0aW5ncyBuZWVkIHRvDQo+Pj4gYmUgY29uZmlybWVkIG9uIGEgbWFpbGluZyBsaXN0LCBh bmQgY29uc2Vuc3VzIG5lZWRzIHRvIGJlDQo+Pj4gZGVjbGFyZWQgYnkgdGhlDQo+Pj4gY2hhaXJz LiBPbiB0aGlzIHN1YmplY3QsIEkgZG8gcmVjYWxsIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9ucyBh ZnRlcg0KPj4+IE1hYXN0cmljaHQsIGJ1dCBJIGRvIG5vdCByZWNhbGwgdGhhdCBjb25zZW5zdXMg d2FzIHJlYWNoZWQsIHlldA0KPj4+IGFsb25lDQo+Pj4gZGVjbGFyZWQuIChVbmZvcnR1bmF0ZWx5 LCBJIGN1cnJlbnRseSBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIGdvDQo+Pj4gdGhyb3VnaA0KPj4+ IHRoZSBtYWlsaW5nIGxpc3QgYXJjaGl2ZXMgdG8gdmVyaWZ5IG15IHJlY29sbGVjdGlvbjsgU29y cnkuKQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDEuMjQuMjAxMSAxNjo0NSAsICJjb2RlYyBpc3N1 ZSB0cmFja2VyIjx0cmFjQHRvb2xzLmlldGYub3JnDQo+Pj4gPG1haWx0bzp0cmFjQHRvb2xzLmll dGYub3JnPj4gIHdyb3RlOg0KPj4+DQo+Pj4gIzEyOiBiaXQtZXhhY3QgdnMuIGJpdC1jb21wYXRp YmxlPw0KPj4+DQo+Pj4gQ2hhbmdlcyAoYnkgZ21heHdlbGxAw4PigKYgKToNCj4+Pg0KPj4+ICog c3RhdHVzOiBuZXcgPT4gIGNsb3NlZA0KPj4+ICogcmVzb2x1dGlvbjogPT4gIHdvcmtzZm9ybWUN Cj4+Pg0KPj4+DQo+Pj4gQ29tbWVudDoNCj4+Pg0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvNzgvbWludXRlcy9jb2RlYy50eHQNCj4+Pg0KPj4+ICJPbiB0aGUgdG9waWMgb2Yg Yml0IGV4YWN0LiBDb25zZW5zdXMgd2FzIGJpdCBleGFjdG5lc3MgaXMNCj4+PiBub3QgcmVxdWly ZWQuIg0KPj4+DQo+Pj4gSSBiZWxpZXZlIHRoaXMgaXNzdWUgaXMgYWxyZWFkeSBjbG9zZWQuDQo+ Pj4NCj4+PiAtLQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gLS0NCj4+PiBSZXBvcnRlcjog aG9lbmVAw4PigKYgfCBPd25lcjoNCj4+PiBUeXBlOiBlbmhhbmNlbWVudCB8IFN0YXR1czogY2xv c2VkDQo+Pj4gUHJpb3JpdHk6IG1pbm9yIHwgTWlsZXN0b25lOg0KPj4+IENvbXBvbmVudDogcmVx dWlyZW1lbnRzIHwgVmVyc2lvbjoNCj4+PiBTZXZlcml0eTogQWN0aXZlIFdHIERvY3VtZW50IHwg UmVzb2x1dGlvbjogd29ya3Nmb3JtZQ0KPj4+IEtleXdvcmRzOiB8DQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+PiAtLQ0KPj4+DQo+Pj4gVGlja2V0DQo+Pj4gVVJMOjxodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy93Zy9jb2RlYy90cmFjL3RpY2tldC8xMiNjb21tZW50OjE+DQo+Pj4gY29kZWM8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2NvZGVjLz4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gY29kZWMgbWFpbGluZyBsaXN0DQo+ Pj4gY29kZWNAaWV0Zi5vcmc8bWFpbHRvOmNvZGVjQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29kZWMNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGNvZGVjIG1h aWxpbmcgbGlzdA0KPj4+IGNvZGVjQGlldGYub3JnPG1haWx0bzpjb2RlY0BpZXRmLm9yZz4NCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjDQo+Pj4NCj4+Pg0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g Y29kZWMgbWFpbGluZyBsaXN0DQo+Pj4gY29kZWNAaWV0Zi5vcmc8bWFpbHRvOmNvZGVjQGlldGYu b3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29kZWMNCj4+ Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IGNvZGVjIG1haWxpbmcgbGlzdA0KPj4+IGNvZGVjQGlldGYub3JnPG1haWx0 bzpjb2RlY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvZGVjDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGNvZGVjIG1haWxpbmcgbGlzdA0KPj4+IGNv ZGVjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b2RlYw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBjb2RlYyBtYWlsaW5nIGxpc3QNCj4+IGNvZGVjQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvZGVjIG1haWxpbmcgbGlzdA0K PiBjb2RlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvZGVjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpjb2RlYyBtYWlsaW5nIGxpc3QNCmNvZGVjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjDQoNCg== From stewe@stewe.org Tue Jan 25 19:57:16 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8BD3A689B for ; Tue, 25 Jan 2011 19:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 6FyXGQQxjk2b for ; Tue, 25 Jan 2011 19:57:14 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id E03033A691A for ; Tue, 25 Jan 2011 19:57:10 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 56060-1743317 for multiple; Wed, 26 Jan 2011 05:00:05 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 25 Jan 2011 19:59:58 -0800 From: Stephan Wenger To: "Raymond (Juin-Hwey) Chen" , Jean-Marc Valin , Koen Vos Message-ID: Thread-Topic: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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" , Stephen Botzko Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 26 Jan 2011 03:57:16 -0000 So I see I'm outgunned on the bit-exact issue. Fine. But please add language in the requirement doc to the extent that there MUST be a conformance spec for each candidate codec that allows to automatically determine the conformance of a codec implementation. Absent this spec, the IPR statements received are meaningless. My preference would be to have that conformance spec in the same document as the codec, so to make citations in IPR statements easy and to avoid a charter-update. =20 Stephan On 1.25.2011 18:24 , "Raymond (Juin-Hwey) Chen" wrote: >My opinion is that we should not require bit-exactness. There are many >examples of previous codec >standards that did not require bit-exactness, including both >royalty-bearing codecs (such as MPEG) >and royalty-free codecs (such as our BroadVoice/BV16/BV32), so I don't >see any real reason why we >can't follow that same route. > >I can see at least two important advantages for not requiring >bit-exactness: >(1) it allows future innovations to improve the performance of the codec >without breaking the bit- >stream compatibility, and >(2) it allows the codec implementers the greatest flexibility in >implementing the codecs in ways >that are most efficient for the particular hardware or processor >architecture they have. >Having a bit-exact standard will kill both. > >The main drawback of a non-bit-exact standard is that the verification of >the conformance of codec >implementations is not as straightforward as with a bit-exact standard. >However, I don't think >that is a show stopper or even a difficult problem. There are many >possible ways to do software- >based objective measurements to verify that a candidate codec >implementation is likely to sound >essentially indistinguishable from the output of the reference codec. We >had previously measured >the SNRs and PESQ scores of a large number of test files using the >reference codec and candidate >codec and examined the statistical distribution of the differences in the >scores. Jean-Marc just >posted a nice little Matlab code that built upon psychoacoustic modeling, >NMR, averages, outliers >checking, etc. Koen also mentioned another tool. Even if these tools >and methodologies are not >perfect yet, with some additional tuning of their algorithms and >parameters, it is really not that >difficult to come up with objective, software-based verification methods >that will give you a high >level of confidence whether a candidate codec will sound at least as good >as the reference codec >(or perhaps better if improvements are made). > >I like Jean-Marc's idea of having both a floating-point reference codec >and a fixed-point >reference codec. For people who don't want to run the risk of degrading >audio quality through >their own fixed-point algorithm conversion, they can just implement the >fixed-point reference >codec in a bit-exact manner. For people who want to implement the codec >in floating-point (e.g. >on computers), the easiest way is just to use the floating-point >reference code as is. In both >cases, the conformance verification will be quite easy. > >Raymond > >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of >Jean-Marc Valin >Sent: Tuesday, January 25, 2011 12:58 PM >To: Koen Vos >Cc: codec@ietf.org; Stephen Botzko >Subject: Re: [codec] requirements #12 (closed): bit-exact vs. >bit-compatible? > >My preference actually goes with using both fixed-point and floating >point. >That way, implementers of floating-point decoder can compare with the >float >version and implementers of the fixed-point decoder can compare with the >fixed-point version. > >This is not unheard of either, if you look at the reference implementation >of the 3GPP(2?) EVRC codec, the distribution includes two sets of output >vectors. One is for a fixed-point implementation that uses 31-bit >precision >in the multiplications and the other one is for 32-bit precision. You just >choose whatever is more efficient for your DSP and use the appropriate >testvectors for testing. > > Jean-Marc > >On 11-01-25 03:37 PM, Koen Vos wrote: >> A similar tool is in the code in silk\test\signalCompare.c. It's based >>on LPC, and measures the SNR in a partially-whitened domain. For music >>the critical-band approach of Jean-Marc's tool may work better, not sure. >> >> One question is about what implementation should be the reference for >>compliance testing: floating-point or fixed-point? >> >> A fixed-point reference allows for bit-exact implementations, which is >>nice. And fixed-point reference implementations are the norm in speech >>coding. >> However, CELT's floating-point implementation has a larger dynamic >>range than the fixed-point version, and is thus arguable better. A >>fixed-point reference could not test this extra dynamic range. >> >> Any suggestions? >> koen. >> >> >> ----- Original Message ----- >> From: "Jean-Marc Valin" >> To: "Stephen Botzko" >> Cc: codec@ietf.org >> Sent: Tuesday, January 25, 2011 8:29:25 AM >> Subject: Re: [codec] requirements #12 (closed): bit-exact vs. >>bit-compatible? >> >> Just to give an idea of what I'm talking about in terms of compliance >>test, >> here's a tool I just wrote that could be used for testing. There may >>need >> to be a bit of refining and playing with the thresholds, but the main >>idea >> is there: >> >> http://jmvalin.ca/misc_stuff/compare.m >> >> It works with Octave, and is likely very easy to get to work with >>Matlab. >> Any comments? >> >> Jean-Marc >> >> On 11-01-25 10:57 AM, Jean-Marc Valin wrote: >>> Hi Stephen, >>> >>> The reference implementation includes both floating-point and >>>fixed-point, >>> so I'm not sure it's a good idea to say that one is "better" than the >>> other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" >>> standard either when it comes to some operations (e.g. transcendental >>> function) and even for other operations, most compilers I know of are >>>not >>> strict IEEE-754 (at least by default) because of issues such as the x86 >>> extended precision operations. >>> >>> Regarding MPEG bit-streams, I'm not sure where to get confirmation, but >>> this is what Wikipedia has to say about MPEG-1 Layer 3: >>> >>> >>> "Decoding, on the other hand, is carefully defined in the standard. >>>Most >>> decoders are "bitstream compliant", which means that the decompressed >>> output =C3=A2=E2=82=AC=E2=80=9C that they produce from a given MP3 file =C3=A2=E2=82=AC=E2=80=9C will b= e the >>>same, within >>> a specified degree of rounding tolerance, as the output specified >>> mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). >>> Therefore, comparison of decoders is usually based on how >>>computationally >>> efficient they are (i.e., how much memory or CPU time they use in the >>> decoding process)." >>> >>> >>> That implies a standard based on "infinite precision", with a degree of >>> tolerance for different implementations. >>> >>> Cheers, >>> >>> Jean-Marc >>> >>> On 11-01-25 10:42 AM, Stephen Botzko wrote: >>>> It seems to me that the reference encoder and decoder will be bit >>>>exact for >>>> a given floating point format, correct? So one could specify IEEE >>>>754-2008 >>>> when bit exactness is needed in the reference (for instance regression >>>> testing), but not require it for compliance. >>>> >>>> Folks who are modifying the reference encoder or decoder algorithms >>>>are "on >>>> their own" as far as audio quality is concerned. Though I agree with >>>> Stephan that we need to address compliance (when exactly does a >>>>ported or >>>> otherwise modified encoder/decoder become non-compliant?). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount>>> > wrote: >>>> >>>> One more concern that I have related to bit exactness is codec >>>> regression testing. One can produce a non-bit-exact encoder that >>>> produces reasonable results for a reference decoder, but if paired >>>>with >>>> a modified, non-bit-exact decoder will produce significant audio >>>> artifacts. Since neither decoder or encoder are bit exact we will need >>>> to have a test procedure that will validate that both encoder or >>>> decoder will not break any standard compliant and non-bit-exact >>>> encoders or decoders. Not really sure how this can be done. >>>> >>>> I might be wrong, but I think MPEG decoders are bit exact and encoders >>>> are not. >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> >>>> On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin>>> > wrote: >>>> >>>> Hi Stephan, >>>> >>>> I understand your concern and I'd be interested if you have >>>> alternative ways of handling the licensing to avoid any issue. It's >>>> not like this is a unique situation. As far as I know, most (all?) >>>> MPEG codecs have similar non-bit exact definitions. I have also >>>> heard that they also require some IPR licensing... >>>> >>>> In general the issue of bit-exactness has been discussed and so far >>>> I don't recall many arguing in favor of a bit-exact definition. >>>> Most of the concerns that have been expressed are solved by >>>> considering that non-bitexact does not mean you cannot be bit-exact >>>> with the reference encoder. It merely means that you don't *have* >>>> to. So regardless of how conformance is defined exactly, one always >>>> has the option of being bit-exact with the reference >>>> implementation, which obviously guarantees compliance. >>>> >>>> As for language mentioning compliance, I believe it belongs more to >>>> the guidelines (it's not a requirement of the codec itself), which >>>> includes the following text: >>>> >>>> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >>>> ideally the decoder specification should not require "bit-exact" >>>> conformance with the reference implementation. The output of a >>>> decoder implementation should only be "close enough" to the >>>> output of the reference decoder. A comparison tool should be >>>> provided along with the codec to verify objectively that the >>>> output of a decoder is likely to be perceptually >>>> indistinguishable from that of the reference decoder. However, >>>> an implementation may still wish to produce an output that is >>>> bit-exact with the reference implementation to simplify the >>>> testing procedure. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Jean-Marc >>>> >>>> >>>> On 11-01-24 11:02 PM, Stephan Wenger wrote: >>>> >>>> Hi all: >>>> >>>> Let me speak once more against this decision (if such a >>>> decision were >>>> really made; see the p.s.). >>>> >>>> There are currently three IPR disclosures against the codec >>>> draft and/or >>>> its predecessors. The Xiph disclosure is at this point a >>>> placeholder >>>> (Xiph folks: it's time to fix that!). However, the two other >>>> disclosures >>>> on file provide a patent grant only for necessary patent claims >>>> and only >>>> when the standard is practiced in full compliance. These terms (in >>>> various formulations) are quite common. >>>> >>>> In order to ensure one has a license (or can rely on a non-assert >>>> covenant), one has to ensure one meets the conditions set by the >>>> rightholder. On stuff such as reciprocity clauses this is >>>> simple. On >>>> compliance, it's not always easy. >>>> >>>> The traditional compliance test for a media codec is a >>>> stimulus-response >>>> test: you feed test vectors into the codec, and you get >>>> results. If the >>>> results match, you are in compliance, if not, you are not. Simple. >>>> >>>> Without bit exactness, the compliance criteria have to be defined >>>> differently. We can do so, and, indeed, I recall that this has been >>>> mentioned as one plan forward. However, I have seen zero >>>> activity in this >>>> direction, and I have also not seen any language that mentions >>>> this in the >>>> requirements draft. I think that the subject of compliance >>>> tests, at >>>> least in its most basic outline, needs to be documented in the >>>> requirements draft. The details can be taken care of elsewhere >>>> and later, >>>> but not too much later. It should be clear that a codec >>>> candidate (if >>>> there were more than one) needs to have compliance criteria >>>> defined before >>>> that codec candidate can become an RFC. Without that, the key >>>> goal of the >>>> WG, a reasonably freely practicable codec, is just not >>>> achievable in the >>>> current legal environment (which includes, in this case, the IPR >>>> disclosures on file). >>>> >>>> Of course, it would be sooooo much simpler if we would mandate >>>> a bit exact >>>> decoder... Is it really that restricting to require that? >>>> >>>> Stephan >>>> >>>> P.s.: for the IETF procedures newcomers: humms taken at >>>> meetings need to >>>> be confirmed on a mailing list, and consensus needs to be >>>> declared by the >>>> chairs. On this subject, I do recall mailing list discussions after >>>> Maastricht, but I do not recall that consensus was reached, yet >>>> alone >>>> declared. (Unfortunately, I currently don't have the time to go >>>> through >>>> the mailing list archives to verify my recollection; Sorry.) >>>> >>>> >>>> >>>> On 1.24.2011 16:45 , "codec issue tracker">>> > wrote: >>>> >>>> #12: bit-exact vs. bit-compatible? >>>> >>>> Changes (by gmaxwell@=C3=83=E2=80=A6 ): >>>> >>>> * status: new =3D> closed >>>> * resolution: =3D> worksforme >>>> >>>> >>>> Comment: >>>> >>>> http://www.ietf.org/proceedings/78/minutes/codec.txt >>>> >>>> "On the topic of bit exact. Consensus was bit exactness is >>>> not required." >>>> >>>> I believe this issue is already closed. >>>> >>>> -- >>>>=20 >>>>------------------------------------+---------------------------------- >>>>--- >>>> -- >>>> Reporter: hoene@=C3=83=E2=80=A6 | Owner: >>>> Type: enhancement | Status: closed >>>> Priority: minor | Milestone: >>>> Component: requirements | Version: >>>> Severity: Active WG Document | Resolution: worksforme >>>> Keywords: | >>>>=20 >>>>------------------------------------+---------------------------------- >>>>--- >>>> -- >>>> >>>> Ticket >>>> URL: >>>> codec >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Tue Jan 25 20:54:25 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238943A689B for ; Tue, 25 Jan 2011 20:54:25 -0800 (PST) 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 7J-DoLoAyyJO for ; Tue, 25 Jan 2011 20:54:23 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 20D163A68FD for ; Tue, 25 Jan 2011 20:54:22 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by vl-mo-mrz24.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LFM00CMY5QYJQ40@vl-mo-mrz24.ip.videotron.ca> for codec@ietf.org; Tue, 25 Jan 2011 23:56:59 -0500 (EST) Message-id: <4D3FA971.4010902@octasic.com> Date: Tue, 25 Jan 2011 23:56:17 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 To: Stephan Wenger References: In-reply-to: Cc: "codec@ietf.org" , Stephen Botzko Subject: Re: [codec] requirements #12 (closed): bit-exact vs. bit-compatible? 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, 26 Jan 2011 04:54:25 -0000 On 11-01-25 10:59 PM, Stephan Wenger wrote: > But please add language in the requirement doc to the extent that there > MUST be a conformance spec for each candidate codec that allows to > automatically determine the conformance of a codec implementation. Absent > this spec, the IPR statements received are meaningless. IIRC, the guidelines already say that we need a conformance test. > My preference would be to have that conformance spec in the same document > as the codec, so to make citations in IPR statements easy and to avoid a > charter-update. Agreed. We really want the conformance tool in the same document as the codec itself. Cheers, Jean-Marc > Stephan > > > On 1.25.2011 18:24 , "Raymond (Juin-Hwey) Chen" wrote: > >> My opinion is that we should not require bit-exactness. There are many >> examples of previous codec >> standards that did not require bit-exactness, including both >> royalty-bearing codecs (such as MPEG) >> and royalty-free codecs (such as our BroadVoice/BV16/BV32), so I don't >> see any real reason why we >> can't follow that same route. >> >> I can see at least two important advantages for not requiring >> bit-exactness: >> (1) it allows future innovations to improve the performance of the codec >> without breaking the bit- >> stream compatibility, and >> (2) it allows the codec implementers the greatest flexibility in >> implementing the codecs in ways >> that are most efficient for the particular hardware or processor >> architecture they have. >> Having a bit-exact standard will kill both. >> >> The main drawback of a non-bit-exact standard is that the verification of >> the conformance of codec >> implementations is not as straightforward as with a bit-exact standard. >> However, I don't think >> that is a show stopper or even a difficult problem. There are many >> possible ways to do software- >> based objective measurements to verify that a candidate codec >> implementation is likely to sound >> essentially indistinguishable from the output of the reference codec. We >> had previously measured >> the SNRs and PESQ scores of a large number of test files using the >> reference codec and candidate >> codec and examined the statistical distribution of the differences in the >> scores. Jean-Marc just >> posted a nice little Matlab code that built upon psychoacoustic modeling, >> NMR, averages, outliers >> checking, etc. Koen also mentioned another tool. Even if these tools >> and methodologies are not >> perfect yet, with some additional tuning of their algorithms and >> parameters, it is really not that >> difficult to come up with objective, software-based verification methods >> that will give you a high >> level of confidence whether a candidate codec will sound at least as good >> as the reference codec >> (or perhaps better if improvements are made). >> >> I like Jean-Marc's idea of having both a floating-point reference codec >> and a fixed-point >> reference codec. For people who don't want to run the risk of degrading >> audio quality through >> their own fixed-point algorithm conversion, they can just implement the >> fixed-point reference >> codec in a bit-exact manner. For people who want to implement the codec >> in floating-point (e.g. >> on computers), the easiest way is just to use the floating-point >> reference code as is. In both >> cases, the conformance verification will be quite easy. >> >> Raymond >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of >> Jean-Marc Valin >> Sent: Tuesday, January 25, 2011 12:58 PM >> To: Koen Vos >> Cc: codec@ietf.org; Stephen Botzko >> Subject: Re: [codec] requirements #12 (closed): bit-exact vs. >> bit-compatible? >> >> My preference actually goes with using both fixed-point and floating >> point. >> That way, implementers of floating-point decoder can compare with the >> float >> version and implementers of the fixed-point decoder can compare with the >> fixed-point version. >> >> This is not unheard of either, if you look at the reference implementation >> of the 3GPP(2?) EVRC codec, the distribution includes two sets of output >> vectors. One is for a fixed-point implementation that uses 31-bit >> precision >> in the multiplications and the other one is for 32-bit precision. You just >> choose whatever is more efficient for your DSP and use the appropriate >> testvectors for testing. >> >> Jean-Marc >> >> On 11-01-25 03:37 PM, Koen Vos wrote: >>> A similar tool is in the code in silk\test\signalCompare.c. It's based >>> on LPC, and measures the SNR in a partially-whitened domain. For music >>> the critical-band approach of Jean-Marc's tool may work better, not sure. >>> >>> One question is about what implementation should be the reference for >>> compliance testing: floating-point or fixed-point? >>> >>> A fixed-point reference allows for bit-exact implementations, which is >>> nice. And fixed-point reference implementations are the norm in speech >>> coding. >>> However, CELT's floating-point implementation has a larger dynamic >>> range than the fixed-point version, and is thus arguable better. A >>> fixed-point reference could not test this extra dynamic range. >>> >>> Any suggestions? >>> koen. >>> >>> >>> ----- Original Message ----- >>> From: "Jean-Marc Valin" >>> To: "Stephen Botzko" >>> Cc: codec@ietf.org >>> Sent: Tuesday, January 25, 2011 8:29:25 AM >>> Subject: Re: [codec] requirements #12 (closed): bit-exact vs. >>> bit-compatible? >>> >>> Just to give an idea of what I'm talking about in terms of compliance >>> test, >>> here's a tool I just wrote that could be used for testing. There may >>> need >>> to be a bit of refining and playing with the thresholds, but the main >>> idea >>> is there: >>> >>> http://jmvalin.ca/misc_stuff/compare.m >>> >>> It works with Octave, and is likely very easy to get to work with >>> Matlab. >>> Any comments? >>> >>> Jean-Marc >>> >>> On 11-01-25 10:57 AM, Jean-Marc Valin wrote: >>>> Hi Stephen, >>>> >>>> The reference implementation includes both floating-point and >>>> fixed-point, >>>> so I'm not sure it's a good idea to say that one is "better" than the >>>> other. As for IEEE 754-2008, as far as I know it is not a "bit-exact" >>>> standard either when it comes to some operations (e.g. transcendental >>>> function) and even for other operations, most compilers I know of are >>>> not >>>> strict IEEE-754 (at least by default) because of issues such as the x86 >>>> extended precision operations. >>>> >>>> Regarding MPEG bit-streams, I'm not sure where to get confirmation, but >>>> this is what Wikipedia has to say about MPEG-1 Layer 3: >>>> >>>> >>>> "Decoding, on the other hand, is carefully defined in the standard. >>>> Most >>>> decoders are "bitstream compliant", which means that the decompressed >>>> output – that they produce from a given MP3 file – will be the >>>> same, within >>>> a specified degree of rounding tolerance, as the output specified >>>> mathematically in the ISO/IEC standard document (ISO/IEC 11172-3). >>>> Therefore, comparison of decoders is usually based on how >>>> computationally >>>> efficient they are (i.e., how much memory or CPU time they use in the >>>> decoding process)." >>>> >>>> >>>> That implies a standard based on "infinite precision", with a degree of >>>> tolerance for different implementations. >>>> >>>> Cheers, >>>> >>>> Jean-Marc >>>> >>>> On 11-01-25 10:42 AM, Stephen Botzko wrote: >>>>> It seems to me that the reference encoder and decoder will be bit >>>>> exact for >>>>> a given floating point format, correct? So one could specify IEEE >>>>> 754-2008 >>>>> when bit exactness is needed in the reference (for instance regression >>>>> testing), but not require it for compliance. >>>>> >>>>> Folks who are modifying the reference encoder or decoder algorithms >>>>> are "on >>>>> their own" as far as audio quality is concerned. Though I agree with >>>>> Stephan that we need to address compliance (when exactly does a >>>>> ported or >>>>> otherwise modified encoder/decoder become non-compliant?). >>>>> >>>>> Stephen Botzko >>>>> >>>>> On Tue, Jan 25, 2011 at 9:34 AM, Roman Shpount>>>> > wrote: >>>>> >>>>> One more concern that I have related to bit exactness is codec >>>>> regression testing. One can produce a non-bit-exact encoder that >>>>> produces reasonable results for a reference decoder, but if paired >>>>> with >>>>> a modified, non-bit-exact decoder will produce significant audio >>>>> artifacts. Since neither decoder or encoder are bit exact we will need >>>>> to have a test procedure that will validate that both encoder or >>>>> decoder will not break any standard compliant and non-bit-exact >>>>> encoders or decoders. Not really sure how this can be done. >>>>> >>>>> I might be wrong, but I think MPEG decoders are bit exact and encoders >>>>> are not. >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>>> >>>>> On Tue, Jan 25, 2011 at 12:03 AM, Jean-Marc Valin>>>> > wrote: >>>>> >>>>> Hi Stephan, >>>>> >>>>> I understand your concern and I'd be interested if you have >>>>> alternative ways of handling the licensing to avoid any issue. It's >>>>> not like this is a unique situation. As far as I know, most (all?) >>>>> MPEG codecs have similar non-bit exact definitions. I have also >>>>> heard that they also require some IPR licensing... >>>>> >>>>> In general the issue of bit-exactness has been discussed and so far >>>>> I don't recall many arguing in favor of a bit-exact definition. >>>>> Most of the concerns that have been expressed are solved by >>>>> considering that non-bitexact does not mean you cannot be bit-exact >>>>> with the reference encoder. It merely means that you don't *have* >>>>> to. So regardless of how conformance is defined exactly, one always >>>>> has the option of being bit-exact with the reference >>>>> implementation, which obviously guarantees compliance. >>>>> >>>>> As for language mentioning compliance, I believe it belongs more to >>>>> the guidelines (it's not a requirement of the codec itself), which >>>>> includes the following text: >>>>> >>>>> 4. To reduce the risk of bias towards certain CPU/DSP architectures, >>>>> ideally the decoder specification should not require "bit-exact" >>>>> conformance with the reference implementation. The output of a >>>>> decoder implementation should only be "close enough" to the >>>>> output of the reference decoder. A comparison tool should be >>>>> provided along with the codec to verify objectively that the >>>>> output of a decoder is likely to be perceptually >>>>> indistinguishable from that of the reference decoder. However, >>>>> an implementation may still wish to produce an output that is >>>>> bit-exact with the reference implementation to simplify the >>>>> testing procedure. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Jean-Marc >>>>> >>>>> >>>>> On 11-01-24 11:02 PM, Stephan Wenger wrote: >>>>> >>>>> Hi all: >>>>> >>>>> Let me speak once more against this decision (if such a >>>>> decision were >>>>> really made; see the p.s.). >>>>> >>>>> There are currently three IPR disclosures against the codec >>>>> draft and/or >>>>> its predecessors. The Xiph disclosure is at this point a >>>>> placeholder >>>>> (Xiph folks: it's time to fix that!). However, the two other >>>>> disclosures >>>>> on file provide a patent grant only for necessary patent claims >>>>> and only >>>>> when the standard is practiced in full compliance. These terms (in >>>>> various formulations) are quite common. >>>>> >>>>> In order to ensure one has a license (or can rely on a non-assert >>>>> covenant), one has to ensure one meets the conditions set by the >>>>> rightholder. On stuff such as reciprocity clauses this is >>>>> simple. On >>>>> compliance, it's not always easy. >>>>> >>>>> The traditional compliance test for a media codec is a >>>>> stimulus-response >>>>> test: you feed test vectors into the codec, and you get >>>>> results. If the >>>>> results match, you are in compliance, if not, you are not. Simple. >>>>> >>>>> Without bit exactness, the compliance criteria have to be defined >>>>> differently. We can do so, and, indeed, I recall that this has been >>>>> mentioned as one plan forward. However, I have seen zero >>>>> activity in this >>>>> direction, and I have also not seen any language that mentions >>>>> this in the >>>>> requirements draft. I think that the subject of compliance >>>>> tests, at >>>>> least in its most basic outline, needs to be documented in the >>>>> requirements draft. The details can be taken care of elsewhere >>>>> and later, >>>>> but not too much later. It should be clear that a codec >>>>> candidate (if >>>>> there were more than one) needs to have compliance criteria >>>>> defined before >>>>> that codec candidate can become an RFC. Without that, the key >>>>> goal of the >>>>> WG, a reasonably freely practicable codec, is just not >>>>> achievable in the >>>>> current legal environment (which includes, in this case, the IPR >>>>> disclosures on file). >>>>> >>>>> Of course, it would be sooooo much simpler if we would mandate >>>>> a bit exact >>>>> decoder... Is it really that restricting to require that? >>>>> >>>>> Stephan >>>>> >>>>> P.s.: for the IETF procedures newcomers: humms taken at >>>>> meetings need to >>>>> be confirmed on a mailing list, and consensus needs to be >>>>> declared by the >>>>> chairs. On this subject, I do recall mailing list discussions after >>>>> Maastricht, but I do not recall that consensus was reached, yet >>>>> alone >>>>> declared. (Unfortunately, I currently don't have the time to go >>>>> through >>>>> the mailing list archives to verify my recollection; Sorry.) >>>>> >>>>> >>>>> >>>>> On 1.24.2011 16:45 , "codec issue tracker">>>> > wrote: >>>>> >>>>> #12: bit-exact vs. bit-compatible? >>>>> >>>>> Changes (by gmaxwell@Å ): >>>>> >>>>> * status: new => closed >>>>> * resolution: => worksforme >>>>> >>>>> >>>>> Comment: >>>>> >>>>> http://www.ietf.org/proceedings/78/minutes/codec.txt >>>>> >>>>> "On the topic of bit exact. Consensus was bit exactness is >>>>> not required." >>>>> >>>>> I believe this issue is already closed. >>>>> >>>>> -- >>>>> >>>>> ------------------------------------+---------------------------------- >>>>> --- >>>>> -- >>>>> Reporter: hoene@Å | Owner: >>>>> Type: enhancement | Status: closed >>>>> Priority: minor | Milestone: >>>>> Component: requirements | Version: >>>>> Severity: Active WG Document | Resolution: worksforme >>>>> Keywords: | >>>>> >>>>> ------------------------------------+---------------------------------- >>>>> --- >>>>> -- >>>>> >>>>> Ticket >>>>> URL: >>>>> codec >>>>> >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>> >>>>> >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Jan 25 21:56:40 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996E23A692E for ; Tue, 25 Jan 2011 21:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqpkh6aOSimd for ; Tue, 25 Jan 2011 21:56:38 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 45EE23A6843 for ; Tue, 25 Jan 2011 21:56:37 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8F28016FC; Wed, 26 Jan 2011 06:59:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type; s= mx; bh=lFVj/xzP5+3mLIm9+4BFl5SGSgo=; b=XycALisTspV6lZ6/6WxtSDX2U Wl9OfcMZA/qVRAqxACvuBNWA195pyClFBJFBFlt3PZY5GMTMEKcRpwogkcALFcdB 4NUJvQfz7/JppZD7fmTEoatF7kF/Q2ZFpzOSovCVt/oS2qEFQyCL+0rFhzdy+SDy Y/Qc5TDQV+6NetgUpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type; q=dns ; s=mx; b=llkSm35VBh3z7uPqfj2eHXysyrCb1XGiBP59wBSzM978TwratY3qNU Ey2j+HkzmXKif0Fea3pB02toQyT2S2oT0VY9TO5DNEsnxUE3gfYd7rQoveVsunaL m8DZjzOGVkVPJtcgKvT5HEKZmyj3APJW2AaYIapINWQtiXRiq9Oik= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8D53F7F6; Wed, 26 Jan 2011 06:59:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7422B35074FF; Wed, 26 Jan 2011 06:59:36 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NzOCBQ0awkQ; Wed, 26 Jan 2011 06:59:23 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 4D1673507487; Wed, 26 Jan 2011 06:59:23 +0100 (CET) Date: Wed, 26 Jan 2011 06:59:23 +0100 (CET) From: Koen Vos To: "Raymond (Juin-Hwey) Chen" Message-ID: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1374992_461071571.1296021563187" X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 05:56:40 -0000 ------=_Part_1374992_461071571.1296021563187 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Raymond,=20 Streaming of CD music was not an anticipated use case or requirement. That = said, 44.1 kHz support at the API is certainly nice to have.=20 My understanding of how CELT works is that a *native* 44.1 kHz mode with a = power-of-2 frame size would break the flexibility to seamlessly switch API = sampling rates or coded audio bandwidth on the fly. (Jean-Marc can shine mo= re light on this.) This feature makes it easy for applications to switch du= ring a call between sources or streams that have different sampling rates.= =20 I'm also not as negative about resampling as you are: modern hybrid-FIR/IIR= designs are very efficient, and I'm convinced a 44.1<->48 kHz resampler wi= th transparent quality can be built with 10~20 MACs per sample. And resampl= ing happens everywhere anyway: most hardware ADCs and DACs resample interna= lly, and even Opus internally resamples in many of its modes already.=20 So if desired we could support 44.1 kHz at the API level, without losing th= e nice flexibility properties we've so painstakingly built into the design.= (Agree we have to think about how to handle 2.5 and 5 ms frames at 44.1 kH= z, but I'm sure we'll find a solution.)=20 best,=20 koen.=20 ----- Original Message ----- From: "Raymond (Juin-Hwey) Chen" =20 To: codec@ietf.org=20 Cc: "jean-marc valin" =20 Sent: Tuesday, January 25, 2011 4:53:38 PM=20 Subject: Re: [codec] requirements #8 (new): Sample rates?=20 I agree that supporting sampling rates of 48, 16, and 8 kHz all makes sense= , but I also think it would be highly desirable to support=20 another common sampling rate used by music CDs: 44.1 kHz.=20 For music streaming applications, a large percentage of the music sources w= ill have this 44.1 kHz sampling rate. I know it is=20 possible to up-sample them to 48 kHz first and then pass them through the 4= 8 kHz version of Opus. However, doing such up-=20 sampling requires additional processing power and additional latency, and i= f the sampling rate conversion is not done with a=20 high-quality method (which usually requires higher complexity and higher de= lay), audio quality degradation may be introduced=20 in the process. For these reasons, many people prefer not to do the 44.1 kH= z to 48 kHz sampling rate conversion and prefer to=20 encode the 44.1 kHz music directly instead. Therefore, it is highly desirab= le for Opus to support this 44.1 kHz sampling rate.=20 I understand that it may be inconvenient for the SILK mode or the SILK+CELT= hybrid mode to support 44.1 kHz. However, for the=20 CELT-only mode, my understanding is that the current CELT C code already su= pports the 44.1 kHz sampling rate. Since the CELT-=20 only mode is also the most suitable mode to encode music, it would then mak= e perfect sense for the CELT-only mode to also=20 support this 44.1 kHz in addition to 48 kHz.=20 Furthermore, currently the CELT mode at 48 kHz supports frame sizes of 2.5,= 5., 10, and 20 ms to be consistent with the frame=20 sizes of the SILK mode and SILK+CELT hybrid mode, and this results in frame= sizes and FFT window sizes that are not powers of 2,=20 which reduces the implementation efficiency. If the CELT mode supports the = 44.1 kHz sampling rate, then since it is no longer=20 possible to support exactly 2.5, 5, 10, and 20 ms at this sampling rate any= way, I think we might as well choose the FFT window=20 sizes to be powers of 2 to allow more efficient implementation. Again, such= power of 2 FFT sizes at 44.1 kHz is already supported=20 in the current C code for CELT, so no new development is needed.=20 In summary, I propose that we allow the CELT-only mode of the Opus codec to= officially support the 44.1 kHz sampling rate using=20 power of 2 FFT window sizes to avoid sampling rate conversion and to allow = the most efficient implementation.=20 Raymond=20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oman Shpount=20 Sent: Monday, January 24, 2011 5:08 PM=20 To: codec@ietf.org=20 Cc: jean-marc.valin@usherbrooke.ca=20 Subject: Re: [codec] requirements #8 (new): Sample rates?=20 I actually do believe that the requirement is already addressed by section = 4.1 of the document. I was responding to a comment that only full band is r= equired, which is clearly not what we agreed upon and not what's in the doc= ument.=20 _____________=20 Roman Shpount=20 On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker < trac@tools.ietf.org = > wrote:=20 #8: Sample rates?=20 Comment(by gmaxwell@=E2=80=A6):=20 On 11-01-24 07:14 PM, Roman Shpount wrote:=20 > I would like to see 8 and 16 KHz as required rates for the codec to=20 insure=20 > interoperability with existing narrowband and wideband codecs. In other= =20 > words we should be able to negotiate 8 or 16 Khz sample rate if audio=20 will=20 > be transcoded for PSTN or wideband codec such as G.722=20 Jean-Marc wrote:=20 > I believe such requirement for narrowband/wideband is already present,=20 but=20 > I don't mind making it even more explicit is necessary.=20 I believe that we since are close enough to finalizing the draft we should= =20 try to include proposed language with our issues. Otherwise there may be=20 no clear path forward.=20 Some of the requirements specify that compatibility with=20 wideband/narrowband is important, but for the avoidance of doubt, I'll=20 suggest:=20 At the end of 4.1. Operating space:=20 "Because interoperation with existing wideband and narrowband facilities=20 is essential at least one method of interoperation must be provided=20 regardless of the codec's operating mode, sample rate, or bitrate."=20 Of course, I would be perfectly happy to leave this out entirely (as I=20 believe the application section 2.1 already implies the requirement) or=20 use some other language.=20 --=20 ------------------------------------+--------------------------------------= -=20 Reporter: hoene@=E2=80=A6 | Owner: jean-marc.valin@=E2=80=A6=20 Type: enhancement | Status: new=20 Priority: minor | Milestone:=20 Component: requirements | Version:=20 Severity: Active WG Document | Keywords:=20 ------------------------------------+--------------------------------------= -=20 Ticket URL: < http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment:4 >= =20 codec < http://tools.ietf.org/codec/ >=20 _______________________________________________=20 codec mailing list=20 codec@ietf.org=20 https://www.ietf.org/mailman/listinfo/codec=20 _______________________________________________=20 codec mailing list=20 codec@ietf.org=20 https://www.ietf.org/mailman/listinfo/codec=20 ------=_Part_1374992_461071571.1296021563187 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >Hi Raymond,

Streaming of CD music was not an anticipated use case o= r requirement.  That said, 44.1 kHz support at the API is certainly ni= ce to have.

My understanding of how CELT works is that a *native* 44= .1 kHz mode with a power-of-2 frame size would break the flexibility to sea= mlessly switch API sampling rates or coded audio bandwidth on the fly. = ; (Jean-Marc can shine more light on this.) This feature makes it easy for = applications to switch during a call between sources or streams that have d= ifferent sampling rates.

I'm also not as negative about resampling a= s you are: modern hybrid-FIR/IIR designs are very efficient, and I'm convin= ced a 44.1<->48 kHz resampler with transparent quality can be built w= ith 10~20 MACs per sample.  And resampling happens everywhere anyway: = most hardware ADCs and DACs resample internally, and even Opus internally r= esamples in many of its modes already. 

So if desired we could= support 44.1 kHz at the API level, without losing the nice flexibility properties we've so painstakingly built into the=20 design.  (Agree we have to think about how to handle 2.5 and 5 ms fram= es at 44.1 kHz, but I'm sure we'll find a solution.)

best,
koen.<= br>

From: "Raymond (Juin-Hwey) Chen" <rch= en@broadcom.com>
To: codec@ietf.org
Cc: "jean-marc v= alin" <jean-marc.valin@usherbrooke.ca>
Sent: Tuesday, Janua= ry 25, 2011 4:53:38 PM
Subject: Re: [codec] requirements #8 (new)= : Sample rates?

I agree that= supporting sampling rates of 48, 16, and 8 kHz all makes sense, but I also think it would be highly desirable to support

another comm= on sampling rate used by music CDs: 44.1 kHz. 

 

For music st= reaming applications, a large percentage of the music sources will have this 44.1 kHz sampling rate.  I know it is

possible to = up-sample them to 48 kHz first and then pass them through the 48 kHz version of Opus.  However, doing such up-

sampling req= uires additional processing power and additional latency, and if the sampling rate conversion is not done with a

high-quality= method (which usually requires higher complexity and higher delay), audio quality degradation may be introduced

in the proce= ss.  For these reasons, many people prefer not to do the 44.1 kHz to 48 kHz sampling rate conversion and prefer to =

encode the 4= 4.1 kHz music directly instead.  Therefore, it is highly desirable for Opus to support this 44.1 kHz sampling rate.=

 

I understand= that it may be inconvenient for the SILK mode or the SILK+CELT hybrid mode to support 44.1 kHz.  However, for the

CELT-only mo= de, my understanding is that the current CELT C code already supports the 44.1 kHz sampling rate.  Since the CELT-

only mode is= also the most suitable mode to encode music, it would then make perfect sense for the CELT-only mode to also

support this= 44.1 kHz in addition to 48 kHz. 

 

Furthermore,= currently the CELT mode at 48 kHz supports frame sizes of 2.5, 5., 10, and 20 ms to be consistent with the frame

sizes of the= SILK mode and SILK+CELT hybrid mode, and this results in frame sizes and FFT window sizes that are not powers of 2,

which reduce= s the implementation efficiency.  If the CELT mode supports the 44.1 kHz sampling rate, then since it is no longer

possible to = support exactly 2.5, 5, 10, and 20 ms at this sampling rate anyway, I think we might as well choose the FFT window

sizes to be = powers of 2 to allow more efficient implementation.  Again, such power of 2 FFT sizes at 44.1 kHz is alrea= dy supported

in the curre= nt C code for CELT, so no new development is needed.

 

In summary, = I propose that we allow the CELT-only mode of the Opus codec to officially support the 44.1 kHz sampling rate using

power of 2 F= FT window sizes to avoid sampling rate conversion and to allow the most efficient implementation.

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Monday, January 24, 2011 5:08 PM
To: codec@ietf.org
Cc: jean-marc.valin@usherbrooke.ca
Subject: Re: [codec] requirements #8 (new): Sample rates?

 

I actually do believe= that the requirement is already addressed by section 4.1 of the document. I was responding to a comment that only full band is required, which is clearly n= ot what we agreed upon and not what's in the document.
_____________
Roman Shpount

On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker= <trac@tools.ie= tf.org> wrote:

#8: Sample rates?


Comment(by gmaxwell@=E2=80=A6):

 On 11-01-24 07:= 14 PM, Roman Shpount wrote:
 > I would like to see 8 and 16 KHz as required rates for the codec= to
 insure
 > interoperability with existing narrowband and wideband codecs. I= n other
 > words we should be able to negotiate 8 or 16 Khz sample rate if audio
 will
 > be transcoded for PSTN or wideband codec such as G.722

 Jean-Marc wrote= :
 > I believe such requirement for narrowband/wideband is already present,
 but
 > I don't mind making it even more explicit is necessary.


 I believe that we since are close enough to fi= nalizing the draft we should
 try to include proposed language with our issues.  Otherwise the= re may be
 no clear path forward.

 Some of the requirements specify that compatibility with
 wideband/narrowband is important, but for the avoidance of doubt, I'l= l
 suggest:

 At the end of 4.1.  Operating space:

 "Because interoperation with existing wideband and narrowband facilities
 is essential at least one method of interoperation must be provided  regardless of the codec's operating mode, sample rate, or bitrate."
 Of course, I would be perfectly happy to leave this out entirely (as = I
 believe the application section 2.1 already implies the requirement) = or
 use some other language.

--

---------------------= ---------------+---------------------------------------
 Reporter:  hoene@=E2=80=A6           &n= bsp;     |       Owner:  jean-marc.valin@=E2=80=A6=
    Type:  enhancement           &n= bsp; |      Status:  new
 Priority:  minor              = ;     |   Milestone:
Component:  requirements            | &n= bsp;   Version:
 Severity:  Active WG Document      |    Keywords:
------------------------------------+--------------------------------------= -

Ticket URL: <http://trac.tools.iet= f.org/wg/codec/trac/ticket/8#comment:4>

codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org

 


_______________________________________________
codec mailing listcodec@ietf.org
https://www.ietf.org/mailman/listinfo/codec
------=_Part_1374992_461071571.1296021563187-- From jean-marc.valin@octasic.com Wed Jan 26 05:48:30 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F5F3A6980 for ; Wed, 26 Jan 2011 05:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+RuAY2zRJHh for ; Wed, 26 Jan 2011 05:48:28 -0800 (PST) Received: from toroondcbmts06-srv.bellnexxia.net (toroondcbmts06-srv.bellnexxia.net [207.236.237.40]) by core3.amsl.com (Postfix) with ESMTP id 8EE723A69B8 for ; Wed, 26 Jan 2011 05:48:28 -0800 (PST) Received: from toip55-bus.srvr.bell.ca ([67.69.240.141]) by toroondcbmts06-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110126135128.TGOG19743.toroondcbmts06-srv.bellnexxia.net@toip55-bus.srvr.bell.ca>; Wed, 26 Jan 2011 08:51:28 -0500 Received: from toip36-bus.srvr.bell.ca ([67.69.240.37]) by toip55-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 08:51:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEOrP03PPaAN/2dsb2JhbACkdnO8KIVPBIUXilgG Received: from mail.octasic.com ([207.61.160.13]) by toip36-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 08:51:16 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL2.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 26 Jan 2011 08:51:16 -0500 Message-ID: <4D4026D4.6010404@octasic.com> Date: Wed, 26 Jan 2011 08:51:16 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Koen Vos References: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> In-Reply-To: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 13:48:30 -0000 Hi, I think it goes beyond just having native support for 44.1 kHz. There are several existing applications that are currently using CELT in modes that are do not have a 2.5/5/10/20 ms frame size. There are different reasons for this depending on the application. Some of these are: 1) Some implementers choose frames that are powers of two so that they can use their platform's highly-optimized FFT 2) For ultra low delay applications, such as "jamming over the network" remote music performances, one can reduce latency by choosing a frame size that matches the soundcard's buffer size (which is almost always a power of two). 3) There are even users that consider 2.5 ms to be too high of a delay for their applications and use frames of 1.33 ms (64 samples at 48 kHz). 4) In some cases, transport or protocol issues impose some constraints on the frame size. For example, the DAB digital radio standard requires frames of 24 ms, which CELT can also handle. I agree that the use cases I listed above may not be part of our "core use cases". However, CELT already handles all these cases with no change required in the code. Considering that people will keep using CELT for these "special" applications, the only question is how we want it to happen. I can see essentially two possible approaches: 1) Defining "custom modes" that handle the use cases above and that operate differently from the "main modes" that we have defined (e.g. no bandwidth switching on the fly). 2) We can exclude these modes from Opus and have these people using "CELT" as a non-standard codec. I don't have a strong opinion on the subject, but I tend to lean towards 1) mainly because we would avoid having Opus and CELT as two "competing" standards. Also, it would mean that the IETF would have change control over all the operating modes instead of "splitting" change control in two. OTOH, I do agree that we would need a way to avoid causing compatibility issues (perhaps by using a different labelling for these "custom modes"). Cheers, Jean-Marc On 11-01-26 12:59 AM, Koen Vos wrote: > Hi Raymond, > > Streaming of CD music was not an anticipated use case or requirement. That > said, 44.1 kHz support at the API is certainly nice to have. > > My understanding of how CELT works is that a *native* 44.1 kHz mode with a > power-of-2 frame size would break the flexibility to seamlessly switch API > sampling rates or coded audio bandwidth on the fly. (Jean-Marc can shine > more light on this.) This feature makes it easy for applications to switch > during a call between sources or streams that have different sampling rates. > > I'm also not as negative about resampling as you are: modern hybrid-FIR/IIR > designs are very efficient, and I'm convinced a 44.1<->48 kHz resampler > with transparent quality can be built with 10~20 MACs per sample. And > resampling happens everywhere anyway: most hardware ADCs and DACs resample > internally, and even Opus internally resamples in many of its modes already. > > So if desired we could support 44.1 kHz at the API level, without losing > the nice flexibility properties we've so painstakingly built into the > design. (Agree we have to think about how to handle 2.5 and 5 ms frames at > 44.1 kHz, but I'm sure we'll find a solution.) > > best, > koen. > > > --------------------------------------------------------------------------- > *From: *"Raymond (Juin-Hwey) Chen" > *To: *codec@ietf.org > *Cc: *"jean-marc valin" > *Sent: *Tuesday, January 25, 2011 4:53:38 PM > *Subject: *Re: [codec] requirements #8 (new): Sample rates? > > I agree that supporting sampling rates of 48, 16, and 8 kHz all makes > sense, but I also think it would be highly desirable to support > > another common sampling rate used by music CDs: 44.1 kHz. > > For music streaming applications, a large percentage of the music sources > will have this 44.1 kHz sampling rate. I know it is > > possible to up-sample them to 48 kHz first and then pass them through the > 48 kHz version of Opus. However, doing such up- > > sampling requires additional processing power and additional latency, and > if the sampling rate conversion is not done with a > > high-quality method (which usually requires higher complexity and higher > delay), audio quality degradation may be introduced > > in the process. For these reasons, many people prefer not to do the 44.1 > kHz to 48 kHz sampling rate conversion and prefer to > > encode the 44.1 kHz music directly instead. Therefore, it is highly > desirable for Opus to support this 44.1 kHz sampling rate. > > I understand that it may be inconvenient for the SILK mode or the SILK+CELT > hybrid mode to support 44.1 kHz. However, for the > > CELT-only mode, my understanding is that the current CELT C code already > supports the 44.1 kHz sampling rate. Since the CELT- > > only mode is also the most suitable mode to encode music, it would then > make perfect sense for the CELT-only mode to also > > support this 44.1 kHz in addition to 48 kHz. > > Furthermore, currently the CELT mode at 48 kHz supports frame sizes of 2.5, > 5., 10, and 20 ms to be consistent with the frame > > sizes of the SILK mode and SILK+CELT hybrid mode, and this results in frame > sizes and FFT window sizes that are not powers of 2, > > which reduces the implementation efficiency. If the CELT mode supports the > 44.1 kHz sampling rate, then since it is no longer > > possible to support exactly 2.5, 5, 10, and 20 ms at this sampling rate > anyway, I think we might as well choose the FFT window > > sizes to be powers of 2 to allow more efficient implementation. Again, such > power of 2 FFT sizes at 44.1 kHz is already supported > > in the current C code for CELT, so no new development is needed. > > In summary, I propose that we allow the CELT-only mode of the Opus codec to > officially support the 44.1 kHz sampling rate using > > power of 2 FFT window sizes to avoid sampling rate conversion and to allow > the most efficient implementation. > > Raymond > > *From:*codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf Of > *Roman Shpount > *Sent:* Monday, January 24, 2011 5:08 PM > *To:* codec@ietf.org > *Cc:* jean-marc.valin@usherbrooke.ca > *Subject:* Re: [codec] requirements #8 (new): Sample rates? > > I actually do believe that the requirement is already addressed by section > 4.1 of the document. I was responding to a comment that only full band is > required, which is clearly not what we agreed upon and not what's in the > document. > _____________ > Roman Shpount > > On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker > wrote: > > #8: Sample rates? > > > Comment(by gmaxwell@…): > > On 11-01-24 07:14 PM, Roman Shpount wrote: > > I would like to see 8 and 16 KHz as required rates for the codec to > insure > > interoperability with existing narrowband and wideband codecs. In other > > words we should be able to negotiate 8 or 16 Khz sample rate if audio > will > > be transcoded for PSTN or wideband codec such as G.722 > > Jean-Marc wrote: > > I believe such requirement for narrowband/wideband is already present, > but > > I don't mind making it even more explicit is necessary. > > > I believe that we since are close enough to finalizing the draft we should > try to include proposed language with our issues. Otherwise there may be > no clear path forward. > > Some of the requirements specify that compatibility with > wideband/narrowband is important, but for the avoidance of doubt, I'll > suggest: > > At the end of 4.1. Operating space: > > "Because interoperation with existing wideband and narrowband facilities > is essential at least one method of interoperation must be provided > regardless of the codec's operating mode, sample rate, or bitrate." > > Of course, I would be perfectly happy to leave this out entirely (as I > believe the application section 2.1 already implies the requirement) or > use some other language. > > -- > > ------------------------------------+--------------------------------------- > Reporter: hoene@… | Owner: jean-marc.valin@… > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > > Ticket URL: > > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Pochol@WebfootGames.com Wed Jan 26 10:02:41 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA0A3A681E for ; Wed, 26 Jan 2011 10:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpuR6m2APRpn for ; Wed, 26 Jan 2011 10:02:41 -0800 (PST) Received: from mail.webfootgames.com (mail.webfootgames.com [68.248.244.61]) by core3.amsl.com (Postfix) with ESMTP id DA87E3A6818 for ; Wed, 26 Jan 2011 10:02:38 -0800 (PST) Received: from mail.WebfootGames.com (softdnserr [::ffff:127.0.0.1]) (AUTH: LOGIN pochol) by mail.webfootgames.com with esmtp; Wed, 26 Jan 2011 12:06:14 -0600 id 000010A0.4D40629C.00000575 Message-ID: <66fba6b23cc5d59c627824ef0a32ef37@WebfootGames.com> Date: Wed, 26 Jan 2011 12:06:20 -0600 From: "Pascal Pochol" To: Jean-Marc Valin In-Reply-To: <4D4026D4.6010404@octasic.com> References: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> <4D4026D4.6010404@octasic.com> X-Mailer: Webfoot's WebMail 1.6-CVS x-priority: 3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mime-Autoconverted: from 8bit to 7bit by courier 0.64 Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Pochol@WebfootGames.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:02:42 -0000 Hello, I just wanted to give in my 2 cents about 44.1Khz native support. 99% of all the audio we use celt and eventually opus for are encoded at 44.1Khz. They are provided to us that way. Which means that without 44.1khz support we'll have to up-sample 99% of our audio most likely in a preprocess build making us maintain 2 sets of audibly identical files. We had to do it before with speex where we converted from 44.1 down to 32khz to use its native ultrawideband but it really wasn't the easiest. We had thousands of files duplicated and every now and then a few of these getting updated from the source, forcing us to redo massive conversions each time to make sure we didn't miss one somewhere. Also about upsampling not costing much, I beg to differ. We had to work with hardware that could decode speex ultrawideband 32Khz just fine but the decoding alone was eating up all our CPU leaving not much else to do the real work that we needed to do. We had to use 16khz instead to make it all work. 48Khz, 44.1khz might not look like a big difference when working on a desktop but when you're counting bytes to see how you can reduce you memory consumption it could mean the world. So strickly from a user of the codec's view, native 44.1Khz would certainly make working with celt/opus a lot easier. I'm guessing that I'm not the only one in that case based on this thread. Easier would also lead to faster adoption. Sorry I didn't intend to write that much. In short 44.1Khz: great if you can do it, if not we'll just have to work around it. -Pascal From gmaxwell@juniper.net Wed Jan 26 11:38:23 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664C53A6842 for ; Wed, 26 Jan 2011 11:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 DRM+AnEIuRSr for ; Wed, 26 Jan 2011 11:38:22 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 354BD3A6822 for ; Wed, 26 Jan 2011 11:38:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTUB44Y9tm8RrsulYYt66gAxtSqinA3gl@postini.com; Wed, 26 Jan 2011 11:41:23 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 26 Jan 2011 11:33:53 -0800 From: Gregory Maxwell To: "Pochol@WebfootGames.com" , Jean-Marc Valin Date: Wed, 26 Jan 2011 11:32:01 -0800 Thread-Topic: [codec] requirements #8 (new): Sample rates? Thread-Index: Acu9g2UmGUQK7gRTQOKGiV/6kHCi5QAAar3g Message-ID: References: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> <4D4026D4.6010404@octasic.com>, <66fba6b23cc5d59c627824ef0a32ef37@WebfootGames.com> In-Reply-To: <66fba6b23cc5d59c627824ef0a32ef37@WebfootGames.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 19:38:23 -0000 I'm very concerned that some people may believe that 44.1k is just another = checkbox that can be added without cost or much consideration. This isn't the case. I think it's essen= tial that we delineate realtime VoIP style usage from other applications. I support Jean Marc's option (1), which I think allows us to have our cake = and eat it too. It's the closest thing to a=20 "cost free" option that I think we're going to get. This option basically s= eparates the codec into two profiles, one which imposes sampling rate restrictions in exchange for many important= advantages, and one which does not, but misses the advantages. =20 JM's option (2) would also work. But I don't like the idea of the market co= nfusion created by a totally separate codec which has significant overlap with Opus, but isn't Opus. Ba= sically, I think it's silly for part of the working group's output to compete with itself. I'd prefer = to just have "Opus" and "Opus-custom" or whatever. There are several reasons that supporting 44.1kHz in the primary Opus profi= le would be bad: One reason for this is that quite a bit of hardware (even on desktops) can = only do 48kHz (or closely related rates) and even when the hardware can do multiple rates it can only ever do= one rate at a time so if=20 its even possible that multiple applications may play sound at once then th= e only way to avoid resampling is if they are all running at a common rate. For the 48kHz related rates we can do very computationally cheap handling o= f different rates purely inside the codec. If their hardware supports any mode out of the 48kHz fami= ly, then they'll need no costly resampling at all. And if they do need run at 44.1k they can resample in a= nd out of the codec without imposing on (or negotiating with) the far end. Another one is that Opus (as described in the draft, without 44.1kHz) can s= witch between any of its supported modes, all on the fly, without creating any surprising imposi= tions on the clients. This is possible only because of the closely related nature of the supporte= d rates, and 44.1kHz can't be accommodated in this scheme. The on the fly switching and lack of requirement to negotiate, also means t= hat two opus devices can communicate without transcoding, even if they were spliced long after nego= tiation. (e.g. as part of a conference gateway). On the other end of the spectrum=97 the current CELT library and bitstream = is extremely flexible. It supports a great many frame sizes and sample rates and I've personally a= rgued against every limitation we've imposed on it, because I like the idea that CELT can= fit into every niche requirement (like the DAB frame sizes). But this flexibility has a serious price for interoperable implementations:= They must carry substantially more code (the limited rates/sample sizes means that a simple table can rep= lace several hundred lines of tricky bit-exact initialization code), cope with increased peak CP= U usage (e.g. if some device only speaks 64 sample frames, 96KHz you might need 10x the CPU power to spe= ak to it compared=20 to your preferred mode), and undertake more complicated negotiation and tes= ting (CELT can support far more unique mixtures of sample rate, frame-size, and channel count then= there are RTP payload types).=20 So basically, I support fully supporting oddball configurations as a well s= pecified standardized mode, but I oppose subjecting the general VoIP/RTP users to the increase complexi= ty and limitations of the more rate/framesize agile configurations. I expect that most users which care about the 'custom' modes are doing othe= r specialized things and won't be expected to ever interop with a random Opus phone except (mayb= e) via a gateway, and that most of them won't even speak RTP=97 so the separation shouldn't e= ven make=20 much difference to them at all. Thoughts? ________________________________________ From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal P= ochol [Pochol@WebfootGames.com] Sent: Wednesday, January 26, 2011 6:06 PM To: Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? Hello, I just wanted to give in my 2 cents about 44.1Khz native support. 99% of all the audio we use celt and eventually opus for are encoded at 44.1Khz. They are provided to us that way. Which means that without 44.1khz support we'll have to up-sample 99% of our audio most likely in a preprocess build making us maintain 2 sets of audibly identical files. We had to do it before with speex where we converted from 44.1 down to 32khz to use its native ultrawideband but it really wasn't the easiest. We had thousands of files duplicated and every now and then a few of these getting updated from the source, forcing us to redo massive conversions each time to make sure we didn't miss one somewhere. Also about upsampling not costing much, I beg to differ. We had to work with hardware that could decode speex ultrawideband 32Khz just fine but the decoding alone was eating up all our CPU leaving not much else to do the real work that we needed to do. We had to use 16khz instead to make it all work. 48Khz, 44.1khz might not look like a big difference when working on a desktop but when you're counting bytes to see how you can reduce you memory consumption it could mean the world. So strickly from a user of the codec's view, native 44.1Khz would certainly make working with celt/opus a lot easier. I'm guessing that I'm not the only one in that case based on this thread. Easier would also lead to faster adoption. Sorry I didn't intend to write that much. In short 44.1Khz: great if you can do it, if not we'll just have to work around it. -Pascal _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From Pochol@WebfootGames.com Wed Jan 26 12:50:53 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03A33A69C9 for ; Wed, 26 Jan 2011 12:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4HOmX+2hIsn for ; Wed, 26 Jan 2011 12:50:52 -0800 (PST) Received: from mail.webfootgames.com (mail.webfootgames.com [68.248.244.61]) by core3.amsl.com (Postfix) with ESMTP id 4B72C3A69C3 for ; Wed, 26 Jan 2011 12:50:47 -0800 (PST) Received: from mail.WebfootGames.com (softdnserr [::ffff:127.0.0.1]) (AUTH: LOGIN pochol) by mail.webfootgames.com with esmtp; Wed, 26 Jan 2011 14:54:19 -0600 id 000010A0.4D408A04.00002043 Message-ID: <9c344e04600914558499e61db9cb8093@WebfootGames.com> Date: Wed, 26 Jan 2011 14:54:29 -0600 From: "Pascal Pochol" To: Gregory Maxwell In-Reply-To: References: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra> <4D4026D4.6010404@octasic.com>, <66fba6b23cc5d59c627824ef0a32ef37@WebfootGames.com> X-Mailer: Webfoot's WebMail 1.6-CVS x-priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Pochol@WebfootGames.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:50:53 -0000 Gregory, > I'm very concerned that some people may believe that 44.1k is just > another checkbox that can be added without cost or much consideration. I don't think that's the case. We all know that if it was easy to handle every sample rate imaginable that it would have been done already. Again talking about our personal case which has nothing to do with VOIP we have a lot of audio data handed to us in 44.1Khz and 22.5Khz. Other popular rates for us are 16Khz and 8Khz which are already handled if I'm not mistaken by opus? Easily derived from 48khz. Before using speex last year I had never encountered anything at 32khz. It'll probably a few more years before we're allowed to use cpus powerful enough and enough ram to handle even 32khz. For now we'll most likely still down sample everything to 16khz. The artists don't like programmers massaging their data but they understand technical limitations so for now we're in luck. > I support Jean Marc's option (1), which I think allows us to have our > cake and eat it too. It's the closest thing to a "cost free" option > that I think we're going to get. This option basically separates the > codec into two profiles, one which imposes sampling rate restrictions > in exchange for many important advantages, and one which does not, but > misses the advantages. Out of curiosity, what would be the advantages that we miss in such case? > JM's option (2) would also work. But I don't like the idea of the > market confusion created by a totally separate codec which has > significant overlap with Opus, but isn't Opus. Basically, I think it's > silly for part of the working group's output to compete with itself. > I'd prefer to just have "Opus" and "Opus-custom" or whatever. I totally agree. > I expect that most users which care about the 'custom' modes are doing > other specialized things and won't be expected to ever interop with a > random Opus phone except (maybe) via a gateway, and that most of them > won't even speak RTP— so the separation shouldn't even make much > difference to them at all. Absolutely right In our case we'd be using for things that wouldn't need to interact with any other devices actually. We use it as a very efficient way to decode stored pre-encoded music/speech streams. -Pascal From koen.vos@skype.net Wed Jan 26 13:05:54 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B643A69C8 for ; Wed, 26 Jan 2011 13:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 PvT-j-WclIKf for ; Wed, 26 Jan 2011 13:05:52 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 79EF73A6895 for ; Wed, 26 Jan 2011 13:05:52 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D428F170D; Wed, 26 Jan 2011 22:08:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=jhQ2godkCQ/V3HjNBIzxAawhewo= ; b=Xz75MX3Ky5wtiogW/qFelEAMjFjfcnJoHmvu4dKt9t5Dmy4CSOork95n6jkw F/t+ZEIXVpEoshzgInqwSJY2/zpYXn9XvmnkqhnC7mr1Vf+MogUUGCHU/VYrB0gz +MT/SGJFa2Ec/Ry6R28SyZUuVzps2DH33KYT4pHOKPQQPT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=CSIXrpMLZVDsIyMjcUuOVl K0CkDix7w08Z6APuzb2uVRluRRSDFEvED++RcLHbFTNYwtnI4abrZsJgWmf8Wew6 sSm+OtqzFifDsXV0N78OK5S5ldBzhr4K3YHOA8xmmKFakrJmJDg7vQ2EATQ4IDwS +faLaVlBZnaaJu7UIRNus= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id D22207F6; Wed, 26 Jan 2011 22:08:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AF6C7350774B; Wed, 26 Jan 2011 22:08:52 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTq0qfg6Rnco; Wed, 26 Jan 2011 22:08:51 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 419B53506DE2; Wed, 26 Jan 2011 22:08:51 +0100 (CET) Date: Wed, 26 Jan 2011 22:08:51 +0100 (CET) From: Koen Vos To: Gregory Maxwell Message-ID: <731662711.1415662.1296076131142.JavaMail.root@lu2-zimbra> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: Pochol@WebfootGames.com, codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 21:05:54 -0000 So what needs to be decided is: 1. How to call these custom modes (for instance in the SDP descriptor). As= long as we agree that it is not "Opus", then we prevent compatibility issu= es and we keep our on-the-fly switching flexibility within the standard Opu= s format. I'm fine with "Opus-custom". 2. How to enable the custom modes in the code. I think there must be a sma= ll barrier so that users don't unintentionally start using them. Maybe a w= ell-commented #define somewhere, plus an API control flag to put the codec = in custom mode? 3. Should there be a set of "official" custom modes, to aid interop even wi= th Opus-custom? Users could still pick and choose any modes they want, but= having the list could make users gravitate towards a few common choices. koen. ----- Original Message ----- From: "Gregory Maxwell" To: Pochol@WebfootGames.com, "Jean-Marc Valin" Cc: codec@ietf.org Sent: Wednesday, January 26, 2011 11:32:01 AM Subject: Re: [codec] requirements #8 (new): Sample rates? I'm very concerned that some people may believe that 44.1k is just another = checkbox that can be added without cost or much consideration. This isn't the case. I think it's essen= tial that we delineate realtime VoIP style usage from other applications. I support Jean Marc's option (1), which I think allows us to have our cake = and eat it too. It's the closest thing to a=20 "cost free" option that I think we're going to get. This option basically s= eparates the codec into two profiles, one which imposes sampling rate restrictions in exchange for many important= advantages, and one which does not, but misses the advantages. =20 JM's option (2) would also work. But I don't like the idea of the market co= nfusion created by a totally separate codec which has significant overlap with Opus, but isn't Opus. Ba= sically, I think it's silly for part of the working group's output to compete with itself. I'd prefer = to just have "Opus" and "Opus-custom" or whatever. There are several reasons that supporting 44.1kHz in the primary Opus profi= le would be bad: One reason for this is that quite a bit of hardware (even on desktops) can = only do 48kHz (or closely related rates) and even when the hardware can do multiple rates it can only ever do= one rate at a time so if=20 its even possible that multiple applications may play sound at once then th= e only way to avoid resampling is if they are all running at a common rate. For the 48kHz related rates we can do very computationally cheap handling o= f different rates purely inside the codec. If their hardware supports any mode out of the 48kHz fami= ly, then they'll need no costly resampling at all. And if they do need run at 44.1k they can resample in a= nd out of the codec without imposing on (or negotiating with) the far end. Another one is that Opus (as described in the draft, without 44.1kHz) can s= witch between any of its supported modes, all on the fly, without creating any surprising imposi= tions on the clients. This is possible only because of the closely related nature of the supporte= d rates, and 44.1kHz can't be accommodated in this scheme. The on the fly switching and lack of requirement to negotiate, also means t= hat two opus devices can communicate without transcoding, even if they were spliced long after nego= tiation. (e.g. as part of a conference gateway). On the other end of the spectrum=E2=80=94 the current CELT library and bits= tream is extremely flexible. It supports a great many frame sizes and sample rates and I've personally a= rgued against every limitation we've imposed on it, because I like the idea that CELT can= fit into every niche requirement (like the DAB frame sizes). But this flexibility has a serious price for interoperable implementations:= They must carry substantially more code (the limited rates/sample sizes means that a simple table can rep= lace several hundred lines of tricky bit-exact initialization code), cope with increased peak CP= U usage (e.g. if some device only speaks 64 sample frames, 96KHz you might need 10x the CPU power to spe= ak to it compared=20 to your preferred mode), and undertake more complicated negotiation and tes= ting (CELT can support far more unique mixtures of sample rate, frame-size, and channel count then= there are RTP payload types).=20 So basically, I support fully supporting oddball configurations as a well s= pecified standardized mode, but I oppose subjecting the general VoIP/RTP users to the increase complexi= ty and limitations of the more rate/framesize agile configurations. I expect that most users which care about the 'custom' modes are doing othe= r specialized things and won't be expected to ever interop with a random Opus phone except (mayb= e) via a gateway, and that most of them won't even speak RTP=E2=80=94 so the separation shoul= dn't even make=20 much difference to them at all. Thoughts? ________________________________________ From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal P= ochol [Pochol@WebfootGames.com] Sent: Wednesday, January 26, 2011 6:06 PM To: Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? Hello, I just wanted to give in my 2 cents about 44.1Khz native support. 99% of all the audio we use celt and eventually opus for are encoded at 44.1Khz. They are provided to us that way. Which means that without 44.1khz support we'll have to up-sample 99% of our audio most likely in a preprocess build making us maintain 2 sets of audibly identical files. We had to do it before with speex where we converted from 44.1 down to 32khz to use its native ultrawideband but it really wasn't the easiest. We had thousands of files duplicated and every now and then a few of these getting updated from the source, forcing us to redo massive conversions each time to make sure we didn't miss one somewhere. Also about upsampling not costing much, I beg to differ. We had to work with hardware that could decode speex ultrawideband 32Khz just fine but the decoding alone was eating up all our CPU leaving not much else to do the real work that we needed to do. We had to use 16khz instead to make it all work. 48Khz, 44.1khz might not look like a big difference when working on a desktop but when you're counting bytes to see how you can reduce you memory consumption it could mean the world. So strickly from a user of the codec's view, native 44.1Khz would certainly make working with celt/opus a lot easier. I'm guessing that I'm not the only one in that case based on this thread. Easier would also lead to faster adoption. Sorry I didn't intend to write that much. In short 44.1Khz: great if you can do it, if not we'll just have to work around it. -Pascal _______________________________________________ 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 koen.vos@skype.net Wed Jan 26 13:15:58 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE3B3A6893 for ; Wed, 26 Jan 2011 13:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mzo0W5wwDyf for ; Wed, 26 Jan 2011 13:15:56 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 6CDCF3A69DA for ; Wed, 26 Jan 2011 13:15:56 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 927D1170D; Wed, 26 Jan 2011 22:18:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=+wrnYyJ+AFWuq9ULPsxE5N/QwNY= ; b=lp7EjXys9/jHRXQ3Udw22ar4asacRQErZmldXGasZoClHh0esLwzGMQ+623d TcMaeuZpppLxexc3CWpTJhB7i7Z3FOcnKg3QnfM37Yra20hkROT6CmVEswBRBOHq aFhHnhUOGoFDx8x0AC7WTe+sH+DGOpNqsxXXcUGPETQU8s4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=BrngEGrlsaSk04mUfKKtVl 65yL4a+d+6cYmxuM1odTWUE2A6vFehKWqjvYnlkADObhsnUsCk9Dvz48sNhVBB26 PndsY2FoFh2FoXdITyhVB0SFqgb3sdv9ZAgyEvk5PECfnK/G5w1PLpnO/eftiNQh dAno0GNuVTvb94IqmUbTk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 911E77F6; Wed, 26 Jan 2011 22:18:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 6D9123507B79; Wed, 26 Jan 2011 22:18:57 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTLEMR5KoQsx; Wed, 26 Jan 2011 22:18:56 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 3C6803507B73; Wed, 26 Jan 2011 22:18:56 +0100 (CET) Date: Wed, 26 Jan 2011 22:18:56 +0100 (CET) From: Koen Vos To: Gregory Maxwell Message-ID: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> In-Reply-To: <731662711.1415662.1296076131142.JavaMail.root@lu2-zimbra> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org, Pochol@WebfootGames.com Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 21:15:58 -0000 And of course: How to signal the custom modes within the packet? ----- Original Message ----- From: "Koen Vos" To: "Gregory Maxwell" Cc: Pochol@WebfootGames.com, codec@ietf.org Sent: Wednesday, January 26, 2011 1:08:51 PM Subject: Re: [codec] requirements #8 (new): Sample rates? So what needs to be decided is: 1. How to call these custom modes (for instance in the SDP descriptor). As= long as we agree that it is not "Opus", then we prevent compatibility issu= es and we keep our on-the-fly switching flexibility within the standard Opu= s format. I'm fine with "Opus-custom". 2. How to enable the custom modes in the code. I think there must be a sma= ll barrier so that users don't unintentionally start using them. Maybe a w= ell-commented #define somewhere, plus an API control flag to put the codec = in custom mode? 3. Should there be a set of "official" custom modes, to aid interop even wi= th Opus-custom? Users could still pick and choose any modes they want, but= having the list could make users gravitate towards a few common choices. koen. ----- Original Message ----- From: "Gregory Maxwell" To: Pochol@WebfootGames.com, "Jean-Marc Valin" Cc: codec@ietf.org Sent: Wednesday, January 26, 2011 11:32:01 AM Subject: Re: [codec] requirements #8 (new): Sample rates? I'm very concerned that some people may believe that 44.1k is just another = checkbox that can be added without cost or much consideration. This isn't the case. I think it's essen= tial that we delineate realtime VoIP style usage from other applications. I support Jean Marc's option (1), which I think allows us to have our cake = and eat it too. It's the closest thing to a=20 "cost free" option that I think we're going to get. This option basically s= eparates the codec into two profiles, one which imposes sampling rate restrictions in exchange for many important= advantages, and one which does not, but misses the advantages. =20 JM's option (2) would also work. But I don't like the idea of the market co= nfusion created by a totally separate codec which has significant overlap with Opus, but isn't Opus. Ba= sically, I think it's silly for part of the working group's output to compete with itself. I'd prefer = to just have "Opus" and "Opus-custom" or whatever. There are several reasons that supporting 44.1kHz in the primary Opus profi= le would be bad: One reason for this is that quite a bit of hardware (even on desktops) can = only do 48kHz (or closely related rates) and even when the hardware can do multiple rates it can only ever do= one rate at a time so if=20 its even possible that multiple applications may play sound at once then th= e only way to avoid resampling is if they are all running at a common rate. For the 48kHz related rates we can do very computationally cheap handling o= f different rates purely inside the codec. If their hardware supports any mode out of the 48kHz fami= ly, then they'll need no costly resampling at all. And if they do need run at 44.1k they can resample in a= nd out of the codec without imposing on (or negotiating with) the far end. Another one is that Opus (as described in the draft, without 44.1kHz) can s= witch between any of its supported modes, all on the fly, without creating any surprising imposi= tions on the clients. This is possible only because of the closely related nature of the supporte= d rates, and 44.1kHz can't be accommodated in this scheme. The on the fly switching and lack of requirement to negotiate, also means t= hat two opus devices can communicate without transcoding, even if they were spliced long after nego= tiation. (e.g. as part of a conference gateway). On the other end of the spectrum=E2=80=94 the current CELT library and bits= tream is extremely flexible. It supports a great many frame sizes and sample rates and I've personally a= rgued against every limitation we've imposed on it, because I like the idea that CELT can= fit into every niche requirement (like the DAB frame sizes). But this flexibility has a serious price for interoperable implementations:= They must carry substantially more code (the limited rates/sample sizes means that a simple table can rep= lace several hundred lines of tricky bit-exact initialization code), cope with increased peak CP= U usage (e.g. if some device only speaks 64 sample frames, 96KHz you might need 10x the CPU power to spe= ak to it compared=20 to your preferred mode), and undertake more complicated negotiation and tes= ting (CELT can support far more unique mixtures of sample rate, frame-size, and channel count then= there are RTP payload types).=20 So basically, I support fully supporting oddball configurations as a well s= pecified standardized mode, but I oppose subjecting the general VoIP/RTP users to the increase complexi= ty and limitations of the more rate/framesize agile configurations. I expect that most users which care about the 'custom' modes are doing othe= r specialized things and won't be expected to ever interop with a random Opus phone except (mayb= e) via a gateway, and that most of them won't even speak RTP=E2=80=94 so the separation shoul= dn't even make=20 much difference to them at all. Thoughts? ________________________________________ From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal P= ochol [Pochol@WebfootGames.com] Sent: Wednesday, January 26, 2011 6:06 PM To: Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? Hello, I just wanted to give in my 2 cents about 44.1Khz native support. 99% of all the audio we use celt and eventually opus for are encoded at 44.1Khz. They are provided to us that way. Which means that without 44.1khz support we'll have to up-sample 99% of our audio most likely in a preprocess build making us maintain 2 sets of audibly identical files. We had to do it before with speex where we converted from 44.1 down to 32khz to use its native ultrawideband but it really wasn't the easiest. We had thousands of files duplicated and every now and then a few of these getting updated from the source, forcing us to redo massive conversions each time to make sure we didn't miss one somewhere. Also about upsampling not costing much, I beg to differ. We had to work with hardware that could decode speex ultrawideband 32Khz just fine but the decoding alone was eating up all our CPU leaving not much else to do the real work that we needed to do. We had to use 16khz instead to make it all work. 48Khz, 44.1khz might not look like a big difference when working on a desktop but when you're counting bytes to see how you can reduce you memory consumption it could mean the world. So strickly from a user of the codec's view, native 44.1Khz would certainly make working with celt/opus a lot easier. I'm guessing that I'm not the only one in that case based on this thread. Easier would also lead to faster adoption. Sorry I didn't intend to write that much. In short 44.1Khz: great if you can do it, if not we'll just have to work around it. -Pascal _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Wed Jan 26 13:22:00 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49D13A69E1 for ; Wed, 26 Jan 2011 13:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-dHApIymevj for ; Wed, 26 Jan 2011 13:21:59 -0800 (PST) Received: from toroondcbmts06-srv.bellnexxia.net (toroondcbmts06.bellnexxia.net [207.236.237.40]) by core3.amsl.com (Postfix) with ESMTP id F0B3A3A69DF for ; Wed, 26 Jan 2011 13:21:58 -0800 (PST) Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts06-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110126212457.KXQN19743.toroondcbmts06-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Wed, 26 Jan 2011 16:24:57 -0500 Received: from toip41-bus.srvr.bell.ca ([67.69.240.42]) by toip58-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 16:24:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHsYQE3PPaAN/2dsb2JhbACkeHO9IYMRgj4EhReKWAY Received: from mail.octasic.com ([207.61.160.13]) by toip41-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 16:24:46 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL1.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 26 Jan 2011 16:22:37 -0500 Message-ID: <4D40909D.10503@octasic.com> Date: Wed, 26 Jan 2011 16:22:37 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Koen Vos References: <731662711.1415662.1296076131142.JavaMail.root@lu2-zimbra> In-Reply-To: <731662711.1415662.1296076131142.JavaMail.root@lu2-zimbra> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, Pochol@WebfootGames.com Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 21:22:00 -0000 On 11-01-26 04:08 PM, Koen Vos wrote: > 1. How to call these custom modes (for instance in the SDP descriptor). > As long as we agree that it is not "Opus", then we prevent compatibility > issues and we keep our on-the-fly switching flexibility within the > standard Opus format. I'm fine with "Opus-custom". OK, unless there's objections I think we can go with "Opus-custom". > 2. How to enable the custom modes in the code. I think there must be a > small barrier so that users don't unintentionally start using them. > Maybe a well-commented #define somewhere, plus an API control flag to > put the codec in custom mode? Agreed. The API will *have* to be different because in the normal mode there won't even be a need to specify things like frame size. As for a #define it also makes sense in terms of saving code size by default. > 3. Should there be a set of "official" custom modes, to aid interop even > with Opus-custom? Users could still pick and choose any modes they > want, but having the list could make users gravitate towards a few > common choices. I think the following modes are main custom modes we want to recommend: 1) 48 kHz, frame sizes 128, 256, 512, 1024 (switchable) 2) 44.1 kHz, frame sizes 128, 256, 512, 1024 (switchable) 3) 48 kHz, frame size 64 4) 44.1 kHz frame size 64 though the other modes will still be available. Cheers, Jean-Marc > koen. > > > > ----- Original Message ----- From: "Gregory > Maxwell" To: Pochol@WebfootGames.com, "Jean-Marc > Valin" Cc: codec@ietf.org Sent: Wednesday, > January 26, 2011 11:32:01 AM Subject: Re: [codec] requirements #8 (new): > Sample rates? > > > > I'm very concerned that some people may believe that 44.1k is just > another checkbox that can be added without cost or much consideration. > This isn't the case. I think it's essential that we delineate realtime > VoIP style usage from other applications. > > I support Jean Marc's option (1), which I think allows us to have our > cake and eat it too. It's the closest thing to a "cost free" option that > I think we're going to get. This option basically separates the codec > into two profiles, one which imposes sampling rate restrictions in > exchange for many important advantages, and one which does not, but > misses the advantages. > > JM's option (2) would also work. But I don't like the idea of the market > confusion created by a totally separate codec which has significant > overlap with Opus, but isn't Opus. Basically, I think it's silly for > part of the working group's output to compete with itself. I'd prefer > to just have "Opus" and "Opus-custom" or whatever. > > > There are several reasons that supporting 44.1kHz in the primary Opus > profile would be bad: > > One reason for this is that quite a bit of hardware (even on desktops) > can only do 48kHz (or closely related rates) and even when the hardware > can do multiple rates it can only ever do one rate at a time so if its > even possible that multiple applications may play sound at once then the > only way to avoid resampling is if they are all running at a common > rate. > > For the 48kHz related rates we can do very computationally cheap > handling of different rates purely inside the codec. If their hardware > supports any mode out of the 48kHz family, then they'll need no costly > resampling at all. And if they do need run at 44.1k they can resample > in and out of the codec without imposing on (or negotiating with) the > far end. > > Another one is that Opus (as described in the draft, without 44.1kHz) > can switch between any of its supported modes, all on the fly, without > creating any surprising impositions on the clients. This is possible > only because of the closely related nature of the supported rates, and > 44.1kHz can't be accommodated in this scheme. > > The on the fly switching and lack of requirement to negotiate, also > means that two opus devices can communicate without transcoding, even if > they were spliced long after negotiation. (e.g. as part of a conference > gateway). > > > On the other end of the spectrum— the current CELT library and > bitstream is extremely flexible. It supports a great many frame sizes > and sample rates and I've personally argued against every limitation > we've imposed on it, because I like the idea that CELT can fit into > every niche requirement (like the DAB frame sizes). > > But this flexibility has a serious price for interoperable > implementations: They must carry substantially more code (the limited > rates/sample sizes means that a simple table can replace several > hundred lines of tricky bit-exact initialization code), cope with > increased peak CPU usage (e.g. if some device only speaks 64 sample > frames, 96KHz you might need 10x the CPU power to speak to it compared > to your preferred mode), and undertake more complicated negotiation and > testing (CELT can support far more unique mixtures of sample rate, > frame-size, and channel count then there are RTP payload types). > > So basically, I support fully supporting oddball configurations as a > well specified standardized mode, but I oppose subjecting the general > VoIP/RTP users to the increase complexity and limitations of the more > rate/framesize agile configurations. > > I expect that most users which care about the 'custom' modes are doing > other specialized things and won't be expected to ever interop with a > random Opus phone except (maybe) via a gateway, and that most of them > won't even speak RTP— so the separation shouldn't even make much > difference to them at all. > > > Thoughts? > > > > > ________________________________________ From: codec-bounces@ietf.org > [codec-bounces@ietf.org] On Behalf Of Pascal Pochol > [Pochol@WebfootGames.com] Sent: Wednesday, January 26, 2011 6:06 PM To: > Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] requirements #8 > (new): Sample rates? > > Hello, > > I just wanted to give in my 2 cents about 44.1Khz native support. > > 99% of all the audio we use celt and eventually opus for are encoded at > 44.1Khz. They are provided to us that way. Which means that without > 44.1khz support we'll have to up-sample 99% of our audio most likely in > a preprocess build making us maintain 2 sets of audibly identical files. > We had to do it before with speex where we converted from 44.1 down to > 32khz to use its native ultrawideband but it really wasn't the easiest. > We had thousands of files duplicated and every now and then a few of > these getting updated from the source, forcing us to redo massive > conversions each time to make sure we didn't miss one somewhere. > > Also about upsampling not costing much, I beg to differ. We had to work > with hardware that could decode speex ultrawideband 32Khz just fine but > the decoding alone was eating up all our CPU leaving not much else to do > the real work that we needed to do. We had to use 16khz instead to make > it all work. 48Khz, 44.1khz might not look like a big difference when > working on a desktop but when you're counting bytes to see how you can > reduce you memory consumption it could mean the world. > > So strickly from a user of the codec's view, native 44.1Khz would > certainly make working with celt/opus a lot easier. I'm guessing that > I'm not the only one in that case based on this thread. Easier would > also lead to faster adoption. > > Sorry I didn't intend to write that much. In short 44.1Khz: great if > you can do it, if not we'll just have to work around it. > > -Pascal > > _______________________________________________ codec mailing list > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ codec mailing list > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Wed Jan 26 13:27:56 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DB33A69E3 for ; Wed, 26 Jan 2011 13:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 0-fh5hGWRjM1 for ; Wed, 26 Jan 2011 13:27:55 -0800 (PST) Received: from toroondcbmts08-srv.bellnexxia.net (toroondcbmts08.bellnexxia.net [207.236.237.42]) by core3.amsl.com (Postfix) with ESMTP id D71833A69DC for ; Wed, 26 Jan 2011 13:27:54 -0800 (PST) Received: from toip55-bus.srvr.bell.ca ([67.69.240.141]) by toroondcbmts08-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110126213055.KDVL19220.toroondcbmts08-srv.bellnexxia.net@toip55-bus.srvr.bell.ca>; Wed, 26 Jan 2011 16:30:55 -0500 Received: from toip34-bus.srvr.bell.ca ([67.69.240.35]) by toip55-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 16:30:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGYdQE3PPaAN/2dsb2JhbACkeHO8fYVPBIUXilgG Received: from mail.octasic.com ([207.61.160.13]) by toip34-bus.srvr.bell.ca with ESMTP; 26 Jan 2011 16:30:47 -0500 Received: from [10.100.60.27] (10.100.60.27) by MAIL1.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 26 Jan 2011 16:27:02 -0500 Message-ID: <4D4091A5.40604@octasic.com> Date: Wed, 26 Jan 2011 16:27:01 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Koen Vos References: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> In-Reply-To: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.100.60.27] Cc: codec@ietf.org, Pochol@WebfootGames.com Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 26 Jan 2011 21:27:56 -0000 On 11-01-26 04:18 PM, Koen Vos wrote: > And of course: How to signal the custom modes within the packet? The custom modes will have to be negotiated at the SDP level. Unlike "Opus" packets, you will just not be able to decode an "Opus-custom" packet without knowing what was negotiated. Jean-Marc > > ----- Original Message ----- > From: "Koen Vos" > To: "Gregory Maxwell" > Cc: Pochol@WebfootGames.com, codec@ietf.org > Sent: Wednesday, January 26, 2011 1:08:51 PM > Subject: Re: [codec] requirements #8 (new): Sample rates? > > So what needs to be decided is: > > 1. How to call these custom modes (for instance in the SDP descriptor). As long as we agree that it is not "Opus", then we prevent compatibility issues and we keep our on-the-fly switching flexibility within the standard Opus format. I'm fine with "Opus-custom". > > 2. How to enable the custom modes in the code. I think there must be a small barrier so that users don't unintentionally start using them. Maybe a well-commented #define somewhere, plus an API control flag to put the codec in custom mode? > > 3. Should there be a set of "official" custom modes, to aid interop even with Opus-custom? Users could still pick and choose any modes they want, but having the list could make users gravitate towards a few common choices. > > koen. > > > > ----- Original Message ----- > From: "Gregory Maxwell" > To: Pochol@WebfootGames.com, "Jean-Marc Valin" > Cc: codec@ietf.org > Sent: Wednesday, January 26, 2011 11:32:01 AM > Subject: Re: [codec] requirements #8 (new): Sample rates? > > > > I'm very concerned that some people may believe that 44.1k is just another checkbox that can be added > without cost or much consideration. This isn't the case. I think it's essential that we delineate realtime VoIP > style usage from other applications. > > I support Jean Marc's option (1), which I think allows us to have our cake and eat it too. It's the closest thing to a > "cost free" option that I think we're going to get. This option basically separates the codec into two profiles, > one which imposes sampling rate restrictions in exchange for many important advantages, and one which > does not, but misses the advantages. > > JM's option (2) would also work. But I don't like the idea of the market confusion created by a totally > separate codec which has significant overlap with Opus, but isn't Opus. Basically, I think it's silly > for part of the working group's output to compete with itself. I'd prefer to just have "Opus" and > "Opus-custom" or whatever. > > > There are several reasons that supporting 44.1kHz in the primary Opus profile would be bad: > > One reason for this is that quite a bit of hardware (even on desktops) can only do 48kHz (or closely related > rates) and even when the hardware can do multiple rates it can only ever do one rate at a time so if > its even possible that multiple applications may play sound at once then the only way to avoid resampling > is if they are all running at a common rate. > > For the 48kHz related rates we can do very computationally cheap handling of different rates purely > inside the codec. If their hardware supports any mode out of the 48kHz family, then they'll need no costly > resampling at all. And if they do need run at 44.1k they can resample in and out of the codec without imposing on (or > negotiating with) the far end. > > Another one is that Opus (as described in the draft, without 44.1kHz) can switch between any of > its supported modes, all on the fly, without creating any surprising impositions on the clients. > This is possible only because of the closely related nature of the supported rates, and 44.1kHz > can't be accommodated in this scheme. > > The on the fly switching and lack of requirement to negotiate, also means that two opus devices can > communicate without transcoding, even if they were spliced long after negotiation. (e.g. as part > of a conference gateway). > > > On the other end of the spectrum— the current CELT library and bitstream is extremely flexible. > It supports a great many frame sizes and sample rates and I've personally argued against > every limitation we've imposed on it, because I like the idea that CELT can fit into every > niche requirement (like the DAB frame sizes). > > But this flexibility has a serious price for interoperable implementations: They must carry substantially > more code (the limited rates/sample sizes means that a simple table can replace several hundred > lines of tricky bit-exact initialization code), cope with increased peak CPU usage (e.g. if some device > only speaks 64 sample frames, 96KHz you might need 10x the CPU power to speak to it compared > to your preferred mode), and undertake more complicated negotiation and testing (CELT can support > far more unique mixtures of sample rate, frame-size, and channel count then there are RTP payload > types). > > So basically, I support fully supporting oddball configurations as a well specified standardized mode, > but I oppose subjecting the general VoIP/RTP users to the increase complexity and limitations of > the more rate/framesize agile configurations. > > I expect that most users which care about the 'custom' modes are doing other specialized things > and won't be expected to ever interop with a random Opus phone except (maybe) via a gateway, > and that most of them won't even speak RTP— so the separation shouldn't even make > much difference to them at all. > > > Thoughts? > > > > > ________________________________________ > From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal Pochol [Pochol@WebfootGames.com] > Sent: Wednesday, January 26, 2011 6:06 PM > To: Jean-Marc Valin > Cc: codec@ietf.org > Subject: Re: [codec] requirements #8 (new): Sample rates? > > Hello, > > I just wanted to give in my 2 cents about 44.1Khz native support. > > 99% of all the audio we use celt and eventually opus for are encoded at > 44.1Khz. They are provided to us that way. Which means that without 44.1khz > support we'll have to up-sample 99% of our audio most likely in a > preprocess build making us maintain 2 sets of audibly identical files. We > had to do it before with speex where we converted from 44.1 down to 32khz > to use its native ultrawideband but it really wasn't the easiest. We had > thousands of files duplicated and every now and then a few of these getting > updated from the source, forcing us to redo massive conversions each time > to make sure we didn't miss one somewhere. > > Also about upsampling not costing much, I beg to differ. We had to work > with hardware that could decode speex ultrawideband 32Khz just fine but the > decoding alone was eating up all our CPU leaving not much else to do the > real work that we needed to do. We had to use 16khz instead to make it all > work. 48Khz, 44.1khz might not look like a big difference when working on a > desktop but when you're counting bytes to see how you can reduce you memory > consumption it could mean the world. > > So strickly from a user of the codec's view, native 44.1Khz would certainly > make working with celt/opus a lot easier. I'm guessing that I'm not the > only one in that case based on this thread. Easier would also lead to > faster adoption. > > Sorry I didn't intend to write that much. In short 44.1Khz: great if you > can do it, if not we'll just have to work around it. > > -Pascal > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Wed Jan 26 16:04:16 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BE53A6A0E for ; Wed, 26 Jan 2011 16:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-iq53k+RjS7 for ; Wed, 26 Jan 2011 16:04:15 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id B2A293A6899 for ; Wed, 26 Jan 2011 16:04:14 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6CBB316F6; Thu, 27 Jan 2011 01:07:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=+OiRQLt0qEJXtGk5SIUN9K4Siuw= ; b=D50u1O2K7t1QrOvMeNG2/BVT3MDIyYAJBea9y1ocKJ2d5RlCgwyidv0LCBtM +nRwyWo0ERAwIRXNNOVB4RIdHmDWef4sGlGpUycEmy9el0RNPVXlw0+JbAcEqVFT cTLIV1X2SNkaaYE4e+xYust3h/fnBmPjCIaecU405HHUEZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=vEgt2sRoFALecbFb05NvKA SJrYqqrXtX6i8nsncbvgiN/mveqXFfBen/bV7ASGO+LJypuZdBTEEblOxR2c7tyz tASQvO7MtvyjRwYtqPLNPug3g5t/RenevdwYPWS2UgIpSxG6Pne+kydjOH7qV+wH 76fNBFJ5FGd3ZTS5Ed08k= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 6A2827F3; Thu, 27 Jan 2011 01:07:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 3F50F3506FBC; Thu, 27 Jan 2011 01:07:15 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLb3ZozMtBxe; Thu, 27 Jan 2011 01:07:13 +0100 (CET) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 8FD463507030; Thu, 27 Jan 2011 01:07:13 +0100 (CET) Date: Thu, 27 Jan 2011 01:07:13 +0100 (CET) From: Koen Vos To: Jean-Marc Valin Message-ID: <1995914071.1419511.1296086833495.JavaMail.root@lu2-zimbra> In-Reply-To: <4D4091A5.40604@octasic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: codec@ietf.org, Pochol@WebfootGames.com Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 27 Jan 2011 00:04:16 -0000 In your previous email you mentioned two custom modes with switchable frame= sizes. For those modes at least the frame size will have to be signaled i= n each packet, no? I could see a benefit in making all recommended custom modes "instantly" de= codable (meaning without prior knowledge). Although it does add another la= yer of "standard custom" vs "custom custom" which may confuse people. I'm fine either way. koen. ----- Original Message ----- From: "Jean-Marc Valin" To: "Koen Vos" Cc: "Gregory Maxwell" , codec@ietf.org, Pochol@Webfoo= tGames.com Sent: Wednesday, January 26, 2011 1:27:01 PM Subject: Re: [codec] requirements #8 (new): Sample rates? On 11-01-26 04:18 PM, Koen Vos wrote: > And of course: How to signal the custom modes within the packet? The custom modes will have to be negotiated at the SDP level. Unlike "Opus"= =20 packets, you will just not be able to decode an "Opus-custom" packet=20 without knowing what was negotiated. Jean-Marc > > ----- Original Message ----- > From: "Koen Vos" > To: "Gregory Maxwell" > Cc: Pochol@WebfootGames.com, codec@ietf.org > Sent: Wednesday, January 26, 2011 1:08:51 PM > Subject: Re: [codec] requirements #8 (new): Sample rates? > > So what needs to be decided is: > > 1. How to call these custom modes (for instance in the SDP descriptor). = As long as we agree that it is not "Opus", then we prevent compatibility is= sues and we keep our on-the-fly switching flexibility within the standard O= pus format. I'm fine with "Opus-custom". > > 2. How to enable the custom modes in the code. I think there must be a s= mall barrier so that users don't unintentionally start using them. Maybe a= well-commented #define somewhere, plus an API control flag to put the code= c in custom mode? > > 3. Should there be a set of "official" custom modes, to aid interop even = with Opus-custom? Users could still pick and choose any modes they want, b= ut having the list could make users gravitate towards a few common choices. > > koen. > > > > ----- Original Message ----- > From: "Gregory Maxwell" > To: Pochol@WebfootGames.com, "Jean-Marc Valin" > Cc: codec@ietf.org > Sent: Wednesday, January 26, 2011 11:32:01 AM > Subject: Re: [codec] requirements #8 (new): Sample rates? > > > > I'm very concerned that some people may believe that 44.1k is just anothe= r checkbox that can be added > without cost or much consideration. This isn't the case. I think it's ess= ential that we delineate realtime VoIP > style usage from other applications. > > I support Jean Marc's option (1), which I think allows us to have our cak= e and eat it too. It's the closest thing to a > "cost free" option that I think we're going to get. This option basically= separates the codec into two profiles, > one which imposes sampling rate restrictions in exchange for many importa= nt advantages, and one which > does not, but misses the advantages. > > JM's option (2) would also work. But I don't like the idea of the market = confusion created by a totally > separate codec which has significant overlap with Opus, but isn't Opus. = Basically, I think it's silly > for part of the working group's output to compete with itself. I'd prefe= r to just have "Opus" and > "Opus-custom" or whatever. > > > There are several reasons that supporting 44.1kHz in the primary Opus pro= file would be bad: > > One reason for this is that quite a bit of hardware (even on desktops) ca= n only do 48kHz (or closely related > rates) and even when the hardware can do multiple rates it can only ever = do one rate at a time so if > its even possible that multiple applications may play sound at once then = the only way to avoid resampling > is if they are all running at a common rate. > > For the 48kHz related rates we can do very computationally cheap handling= of different rates purely > inside the codec. If their hardware supports any mode out of the 48kHz fa= mily, then they'll need no costly > resampling at all. And if they do need run at 44.1k they can resample in= and out of the codec without imposing on (or > negotiating with) the far end. > > Another one is that Opus (as described in the draft, without 44.1kHz) can= switch between any of > its supported modes, all on the fly, without creating any surprising impo= sitions on the clients. > This is possible only because of the closely related nature of the suppor= ted rates, and 44.1kHz > can't be accommodated in this scheme. > > The on the fly switching and lack of requirement to negotiate, also means= that two opus devices can > communicate without transcoding, even if they were spliced long after n= egotiation. (e.g. as part > of a conference gateway). > > > On the other end of the spectrum=C3=A2=E2=82=AC=E2=80=9D the current CELT= library and bitstream is extremely flexible. > It supports a great many frame sizes and sample rates and I've personally= argued against > every limitation we've imposed on it, because I like the idea that CELT c= an fit into every > niche requirement (like the DAB frame sizes). > > But this flexibility has a serious price for interoperable implementation= s: They must carry substantially > more code (the limited rates/sample sizes means that a simple table can r= eplace several hundred > lines of tricky bit-exact initialization code), cope with increased peak = CPU usage (e.g. if some device > only speaks 64 sample frames, 96KHz you might need 10x the CPU power to s= peak to it compared > to your preferred mode), and undertake more complicated negotiation and t= esting (CELT can support > far more unique mixtures of sample rate, frame-size, and channel count th= en there are RTP payload > types). > > So basically, I support fully supporting oddball configurations as a well= specified standardized mode, > but I oppose subjecting the general VoIP/RTP users to the increase comple= xity and limitations of > the more rate/framesize agile configurations. > > I expect that most users which care about the 'custom' modes are doing ot= her specialized things > and won't be expected to ever interop with a random Opus phone except (ma= ybe) via a gateway, > and that most of them won't even speak RTP=C3=A2=E2=82=AC=E2=80=9D so the= separation shouldn't even make > much difference to them at all. > > > Thoughts? > > > > > ________________________________________ > From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal= Pochol [Pochol@WebfootGames.com] > Sent: Wednesday, January 26, 2011 6:06 PM > To: Jean-Marc Valin > Cc: codec@ietf.org > Subject: Re: [codec] requirements #8 (new): Sample rates? > > Hello, > > I just wanted to give in my 2 cents about 44.1Khz native support. > > 99% of all the audio we use celt and eventually opus for are encoded at > 44.1Khz. They are provided to us that way. Which means that without 44.1k= hz > support we'll have to up-sample 99% of our audio most likely in a > preprocess build making us maintain 2 sets of audibly identical files. We > had to do it before with speex where we converted from 44.1 down to 32khz > to use its native ultrawideband but it really wasn't the easiest. We had > thousands of files duplicated and every now and then a few of these getti= ng > updated from the source, forcing us to redo massive conversions each time > to make sure we didn't miss one somewhere. > > Also about upsampling not costing much, I beg to differ. We had to work > with hardware that could decode speex ultrawideband 32Khz just fine but t= he > decoding alone was eating up all our CPU leaving not much else to do the > real work that we needed to do. We had to use 16khz instead to make it al= l > work. 48Khz, 44.1khz might not look like a big difference when working on= a > desktop but when you're counting bytes to see how you can reduce you memo= ry > consumption it could mean the world. > > So strickly from a user of the codec's view, native 44.1Khz would certain= ly > make working with celt/opus a lot easier. I'm guessing that I'm not the > only one in that case based on this thread. Easier would also lead to > faster adoption. > > Sorry I didn't intend to write that much. In short 44.1Khz: great if you > can do it, if not we'll just have to work around it. > > -Pascal > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Wed Jan 26 17:12:06 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA633A68F6 for ; Wed, 26 Jan 2011 17:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 vxNBl5HXdutb for ; Wed, 26 Jan 2011 17:12:04 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id BC22A3A68F8 for ; Wed, 26 Jan 2011 17:12:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; 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 <0LFN002DIQ554YB0@VL-MR-MRZ22.ip.videotron.ca> for codec@ietf.org; Wed, 26 Jan 2011 20:15:05 -0500 (EST) Message-id: <4D40C70F.4010200@octasic.com> Date: Wed, 26 Jan 2011 20:14:55 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 To: Koen Vos References: <1995914071.1419511.1296086833495.JavaMail.root@lu2-zimbra> In-reply-to: <1995914071.1419511.1296086833495.JavaMail.root@lu2-zimbra> Cc: Pochol@WebfootGames.com, codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 27 Jan 2011 01:12:06 -0000 What I meant in my previous email was that these modes are potentially switchable. How exactly (or whether) we want to handle that is still an open question. It even something we could handle in the RTP payload format. Overall, I don't have a strong opinion on switching of custom modes. Jean-Marc On 11-01-26 07:07 PM, Koen Vos wrote: > In your previous email you mentioned two custom modes with switchable frame sizes. For those modes at least the frame size will have to be signaled in each packet, no? > > I could see a benefit in making all recommended custom modes "instantly" decodable (meaning without prior knowledge). Although it does add another layer of "standard custom" vs "custom custom" which may confuse people. > > I'm fine either way. > koen. > > > ----- Original Message ----- > From: "Jean-Marc Valin" > To: "Koen Vos" > Cc: "Gregory Maxwell", codec@ietf.org, Pochol@WebfootGames.com > Sent: Wednesday, January 26, 2011 1:27:01 PM > Subject: Re: [codec] requirements #8 (new): Sample rates? > > On 11-01-26 04:18 PM, Koen Vos wrote: >> And of course: How to signal the custom modes within the packet? > > The custom modes will have to be negotiated at the SDP level. Unlike "Opus" > packets, you will just not be able to decode an "Opus-custom" packet > without knowing what was negotiated. > > Jean-Marc > >> >> ----- Original Message ----- >> From: "Koen Vos" >> To: "Gregory Maxwell" >> Cc: Pochol@WebfootGames.com, codec@ietf.org >> Sent: Wednesday, January 26, 2011 1:08:51 PM >> Subject: Re: [codec] requirements #8 (new): Sample rates? >> >> So what needs to be decided is: >> >> 1. How to call these custom modes (for instance in the SDP descriptor). As long as we agree that it is not "Opus", then we prevent compatibility issues and we keep our on-the-fly switching flexibility within the standard Opus format. I'm fine with "Opus-custom". >> >> 2. How to enable the custom modes in the code. I think there must be a small barrier so that users don't unintentionally start using them. Maybe a well-commented #define somewhere, plus an API control flag to put the codec in custom mode? >> >> 3. Should there be a set of "official" custom modes, to aid interop even with Opus-custom? Users could still pick and choose any modes they want, but having the list could make users gravitate towards a few common choices. >> >> koen. >> >> >> >> ----- Original Message ----- >> From: "Gregory Maxwell" >> To: Pochol@WebfootGames.com, "Jean-Marc Valin" >> Cc: codec@ietf.org >> Sent: Wednesday, January 26, 2011 11:32:01 AM >> Subject: Re: [codec] requirements #8 (new): Sample rates? >> >> >> >> I'm very concerned that some people may believe that 44.1k is just another checkbox that can be added >> without cost or much consideration. This isn't the case. I think it's essential that we delineate realtime VoIP >> style usage from other applications. >> >> I support Jean Marc's option (1), which I think allows us to have our cake and eat it too. It's the closest thing to a >> "cost free" option that I think we're going to get. This option basically separates the codec into two profiles, >> one which imposes sampling rate restrictions in exchange for many important advantages, and one which >> does not, but misses the advantages. >> >> JM's option (2) would also work. But I don't like the idea of the market confusion created by a totally >> separate codec which has significant overlap with Opus, but isn't Opus. Basically, I think it's silly >> for part of the working group's output to compete with itself. I'd prefer to just have "Opus" and >> "Opus-custom" or whatever. >> >> >> There are several reasons that supporting 44.1kHz in the primary Opus profile would be bad: >> >> One reason for this is that quite a bit of hardware (even on desktops) can only do 48kHz (or closely related >> rates) and even when the hardware can do multiple rates it can only ever do one rate at a time so if >> its even possible that multiple applications may play sound at once then the only way to avoid resampling >> is if they are all running at a common rate. >> >> For the 48kHz related rates we can do very computationally cheap handling of different rates purely >> inside the codec. If their hardware supports any mode out of the 48kHz family, then they'll need no costly >> resampling at all. And if they do need run at 44.1k they can resample in and out of the codec without imposing on (or >> negotiating with) the far end. >> >> Another one is that Opus (as described in the draft, without 44.1kHz) can switch between any of >> its supported modes, all on the fly, without creating any surprising impositions on the clients. >> This is possible only because of the closely related nature of the supported rates, and 44.1kHz >> can't be accommodated in this scheme. >> >> The on the fly switching and lack of requirement to negotiate, also means that two opus devices can >> communicate without transcoding, even if they were spliced long after negotiation. (e.g. as part >> of a conference gateway). >> >> >> On the other end of the spectrum— the current CELT library and bitstream is extremely flexible. >> It supports a great many frame sizes and sample rates and I've personally argued against >> every limitation we've imposed on it, because I like the idea that CELT can fit into every >> niche requirement (like the DAB frame sizes). >> >> But this flexibility has a serious price for interoperable implementations: They must carry substantially >> more code (the limited rates/sample sizes means that a simple table can replace several hundred >> lines of tricky bit-exact initialization code), cope with increased peak CPU usage (e.g. if some device >> only speaks 64 sample frames, 96KHz you might need 10x the CPU power to speak to it compared >> to your preferred mode), and undertake more complicated negotiation and testing (CELT can support >> far more unique mixtures of sample rate, frame-size, and channel count then there are RTP payload >> types). >> >> So basically, I support fully supporting oddball configurations as a well specified standardized mode, >> but I oppose subjecting the general VoIP/RTP users to the increase complexity and limitations of >> the more rate/framesize agile configurations. >> >> I expect that most users which care about the 'custom' modes are doing other specialized things >> and won't be expected to ever interop with a random Opus phone except (maybe) via a gateway, >> and that most of them won't even speak RTP— so the separation shouldn't even make >> much difference to them at all. >> >> >> Thoughts? >> >> >> >> >> ________________________________________ >> From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Pascal Pochol [Pochol@WebfootGames.com] >> Sent: Wednesday, January 26, 2011 6:06 PM >> To: Jean-Marc Valin >> Cc: codec@ietf.org >> Subject: Re: [codec] requirements #8 (new): Sample rates? >> >> Hello, >> >> I just wanted to give in my 2 cents about 44.1Khz native support. >> >> 99% of all the audio we use celt and eventually opus for are encoded at >> 44.1Khz. They are provided to us that way. Which means that without 44.1khz >> support we'll have to up-sample 99% of our audio most likely in a >> preprocess build making us maintain 2 sets of audibly identical files. We >> had to do it before with speex where we converted from 44.1 down to 32khz >> to use its native ultrawideband but it really wasn't the easiest. We had >> thousands of files duplicated and every now and then a few of these getting >> updated from the source, forcing us to redo massive conversions each time >> to make sure we didn't miss one somewhere. >> >> Also about upsampling not costing much, I beg to differ. We had to work >> with hardware that could decode speex ultrawideband 32Khz just fine but the >> decoding alone was eating up all our CPU leaving not much else to do the >> real work that we needed to do. We had to use 16khz instead to make it all >> work. 48Khz, 44.1khz might not look like a big difference when working on a >> desktop but when you're counting bytes to see how you can reduce you memory >> consumption it could mean the world. >> >> So strickly from a user of the codec's view, native 44.1Khz would certainly >> make working with celt/opus a lot easier. I'm guessing that I'm not the >> only one in that case based on this thread. Easier would also lead to >> faster adoption. >> >> Sorry I didn't intend to write that much. In short 44.1Khz: great if you >> can do it, if not we'll just have to work around it. >> >> -Pascal >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Pochol@WebfootGames.com Wed Jan 26 19:08:25 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E059A28C0FF for ; Wed, 26 Jan 2011 19:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cKP9AoQnT8Q for ; Wed, 26 Jan 2011 19:08:21 -0800 (PST) Received: from mail.webfootgames.com (mail.webfootgames.com [68.248.244.61]) by core3.amsl.com (Postfix) with ESMTP id D49C528C100 for ; Wed, 26 Jan 2011 19:08:20 -0800 (PST) Received: from mail.WebfootGames.com (softdnserr [::ffff:127.0.0.1]) (AUTH: LOGIN pochol) by mail.webfootgames.com with esmtp; Wed, 26 Jan 2011 21:12:07 -0600 id 0000109F.4D40E288.00002233 Message-ID: <088d003d65f78906dd3464e0fde1e22d@WebfootGames.com> Date: Wed, 26 Jan 2011 21:12:08 -0600 From: "Pascal Pochol" To: Jean-Marc Valin In-Reply-To: <4D4091A5.40604@octasic.com> References: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> <4D4091A5.40604@octasic.com> X-Mailer: Webfoot's WebMail 1.6-CVS x-priority: 3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mime-Autoconverted: from 8bit to 7bit by courier 0.64 Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Pochol@WebfootGames.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 03:08:26 -0000 Jean-Marc, > > And of course: How to signal the custom modes within the packet? > > The custom modes will have to be negotiated at the SDP level. Unlike > "Opus" packets, you will just not be able to decode an "Opus-custom" > packet without knowing what was negotiated. in our case I don't even think that we need a per packet signal to tell the decoder. Unless the Opus-custom encoder does something that varies per packet we usually set the parameters up front and never change them when encoding a stream. We could have a little header packet to set things up or since we're in total control simply set the parameter in the initialization of the decoder with a few api calls. Not sure if that would work for others but in our case I think it would without adding extra information to the packets. -Pascal From butrus.butrus@gmail.com Thu Jan 27 08:01:48 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021083A682A for ; Thu, 27 Jan 2011 08:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt1hiyoTDKmA for ; Thu, 27 Jan 2011 08:01:47 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id EAEBD3A67F4 for ; Thu, 27 Jan 2011 08:01:46 -0800 (PST) Received: by wyf23 with SMTP id 23so2276521wyf.31 for ; Thu, 27 Jan 2011 08:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ph+Jbsex9fvlbDCJoZZ/Z2dICjMp13TY8/Yb8p4ielg=; b=sDyf1Mv5RUEhtO7Ry1ltS+zXnt9biWZyAEmdzHsRvTRAi/3FoglMGb4J5th6pnQEfT hxGPlZiOzQp4uT7vneSmvO6crFHPc37VhKI/uh2bzCJOnz55zAtFPu6NfKwd3IXRfqfc lo3aagHimmW+BEu0yPFwoiew4gzMUX72ptg4I= 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=QVOXnJ1jfdpXWQAmcVPm3SuUOnB+gHvJeH4xiCK8edjOtfZxIqzmXn6xG0TI1PSkvT 90Xr2hpUcthI81EbZ/4JX/V/QzHxHLTaU7JDX73I0zrKMrw+QXy4QGw6SMg4FfnDpkZi 6kBKaEfEvuK0jnKTS9NT1BtzEUiOCXDNt7ZQ0= MIME-Version: 1.0 Received: by 10.216.176.142 with SMTP id b14mr1979443wem.32.1296144290153; Thu, 27 Jan 2011 08:04:50 -0800 (PST) Received: by 10.216.121.69 with HTTP; Thu, 27 Jan 2011 08:04:49 -0800 (PST) In-Reply-To: <088d003d65f78906dd3464e0fde1e22d@WebfootGames.com> References: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> <4D4091A5.40604@octasic.com> <088d003d65f78906dd3464e0fde1e22d@WebfootGames.com> Date: Thu, 27 Jan 2011 17:04:49 +0100 Message-ID: From: Butrus Damaskus To: Pochol@webfootgames.com Content-Type: text/plain; charset=UTF-8 Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 27 Jan 2011 16:01:48 -0000 On Thu, Jan 27, 2011 at 4:12 AM, Pascal Pochol wrote: > Jean-Marc, > >> > And of course: How to signal the custom modes within the packet? >> >> The custom modes will have to be negotiated at the SDP level. Unlike >> "Opus" packets, you will just not be able to decode an "Opus-custom" >> packet without knowing what was negotiated. > > in our case I don't even think that we need a per packet signal to tell the > decoder. Unless the Opus-custom encoder does something that varies per > packet we usually set the parameters up front and never change them when > encoding a stream. We could have a little header packet to set things up or > since we're in total control simply set the parameter in the initialization > of the decoder with a few api calls. Not sure if that would work for others > but in our case I think it would without adding extra information to the > packets. > Well, but you probably need at least one bit to signal header/data packets, no? From Pochol@WebfootGames.com Thu Jan 27 10:14:49 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653AF3A65A5 for ; Thu, 27 Jan 2011 10:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52UFaMO60gtL for ; Thu, 27 Jan 2011 10:14:48 -0800 (PST) Received: from mail.webfootgames.com (mail.webfootgames.com [68.248.244.61]) by core3.amsl.com (Postfix) with ESMTP id 025023A681F for ; Thu, 27 Jan 2011 10:14:46 -0800 (PST) Received: from mail.WebfootGames.com (softdnserr [::ffff:127.0.0.1]) (AUTH: LOGIN pochol) by mail.webfootgames.com with esmtp; Thu, 27 Jan 2011 12:18:34 -0600 id 000010A0.4D41B6FB.00000822 Message-ID: <2194e1f874a6ac4cc576cb63e010b1be@WebfootGames.com> Date: Thu, 27 Jan 2011 12:18:35 -0600 From: "Pascal Pochol" To: Butrus Damaskus In-Reply-To: References: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> <4D4091A5.40604@octasic.com> <088d003d65f78906dd3464e0fde1e22d@WebfootGames.com> X-Mailer: Webfoot's WebMail 1.6-CVS x-priority: 3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mime-Autoconverted: from 8bit to 7bit by courier 0.64 Cc: codec@ietf.org Subject: Re: [codec] requirements #8 (new): Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Pochol@WebfootGames.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:14:49 -0000 Brutus, > Well, but you probably need at least one bit to signal header/data > packets, no? for what we do, no. We open a stream we can easily assume the header is at the beginning and everything after that is data packets. We don't have anything that can join in midstream or change the format midstream or anything like that. Again this is very specific to what we do it might not fit others needs. I wouldn't even have a problem if we simply had to call a few api functions before encoding to set everything up and call a few api functions before decoding with the same type of parameters to let the decoder know what it's about to receive and not even use a header. Since we write both encoder and decoder programs to fit our needs and nobody else reads our encoded data. when we used speex we started with the standard speexenc/speexdec format encapsulated into an ogg. But that was too complex so we dropped the ogg container and used samplexenc.c and sampledec.c instead. We made our version of sampleenc.c spit out a tiny header at the beginning that would give us some basic information that we needed in order to decode everything. I don't remember off hand what it contained one was the original number of samples I think. And we loaded that in our decoder and that was it. the rest of the files were all the smallest speex packets we could make. We noticed that the first byte was a constant size of the frame so we dropped that out as well and moved it into the header. That saved a few hundreds to a few thousands bytes for each file (a few thousands of files total) for a huge saving. For us a byte is still a full 8 bits which can be used to store a lot of information, so I perfectly understand and appreciate this group's concern about adding a few bits to each packets. My personal vote for opus-custom would be to use api calls and not store any more data than absolutely necessary in the stream. Since using the custom mode mean using custom code on both ends it's not a problem for us. -Pascal From gmaxwell@juniper.net Thu Jan 27 10:27:33 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5DE3A67BD for ; Thu, 27 Jan 2011 10:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 inZ-mc3iAV-D for ; Thu, 27 Jan 2011 10:27:32 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id C4C283A65A5 for ; Thu, 27 Jan 2011 10:27:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTUG5ySUzyDb/144+Igr/zzVWal1iS9K4@postini.com; Thu, 27 Jan 2011 10:30:37 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 27 Jan 2011 10:23:00 -0800 From: Gregory Maxwell To: Butrus Damaskus , "Pochol@webfootgames.com" Date: Thu, 27 Jan 2011 10:21:06 -0800 Thread-Topic: [codec] requirements #8 (new): Sample rates? Thread-Index: Acu+O6xOBW/LehO+QNGn+yYjaaqUQwAESTbV Message-ID: References: <1485847861.1415843.1296076736111.JavaMail.root@lu2-zimbra> <4D4091A5.40604@octasic.com> <088d003d65f78906dd3464e0fde1e22d@WebfootGames.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] requirements #8 (new): Sample rates? 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, 27 Jan 2011 18:27:33 -0000 Butrus Damaskus [butrus.butrus@gmail.com] wrote: > On Thu, Jan 27, 2011 at 4:12 AM, Pascal Pochol = wrote: >> in our case I don't even think that we need a per packet signal to tell = the >> decoder. Unless the Opus-custom encoder does something that varies per >> packet we usually set the parameters up front and never change them when >> encoding a stream. We could have a little header packet to set things up= or >> since we're in total control simply set the parameter in the initializat= ion >> of the decoder with a few api calls. Not sure if that would work for oth= ers >> but in our case I think it would without adding extra information to the >> packets. > >Well, but you probably need at least one bit to signal header/data packets= , no? No=97 the codec itself doesn't carry quite a bit of information which is im= portant to applications already. E.g. it doesn't carry timing. These things are le= ft to upper level protocols to handle. The same can, and should, be done for configuration negotiation. The reason= for this is that the transport can be well adapted to the environment. If the= re were a 'header packet' that the codec generated only once and sent as part of the bitstream, if that packet were lost the all the rest of the audio would= be undecodable. So the only real options are: send it every packet or leave = it for another mechanism to handle. Even if you wanted to reinvent a whole two way negotiation machine inside t= he codec=97 you couldn't really, because you can't depend on the usage being duplex. For modes which can be reasonably switched on the fly sending it in every packet provides some value. For ones which can't be=97 sending it in every packet is overhead, and worse=97 a possible opening for a malicious transmitter to trigger poorly tested corner-cases. A complete selection of modes that CELT can operate in (when restrictions t= o simplify implementation are not imposed) takes about 4 bytes, more if you=20 want to add some length coding in order to support packing multiple codec frames in one packet. Thats a pretty high overhead for a 64 sample/frame= =20 mode which is sending 700pps, especially in the case of a lossless transport for which the configuration would only ever have to be sent once. So, I think that in packet signaling should generally be limited only to signalling switches that the codec can actually do on the fly, and I think for the opus-custom modes it's probably better to not signal in the packets at all. If an application needs switching for opus-custom, it could define a new encapsulation for its transport which provides for it= . From hoene@uni-tuebingen.de Fri Jan 28 02:32:18 2011 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBCC3A6359 for ; Fri, 28 Jan 2011 02:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9DEc6nKON-n for ; Fri, 28 Jan 2011 02:32:16 -0800 (PST) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 217003A635F for ; Fri, 28 Jan 2011 02:32:15 -0800 (PST) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p0SAZGjt026831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jan 2011 11:35:17 +0100 From: "Christian Hoene" To: Date: Fri, 28 Jan 2011 11:35:19 +0100 Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?= Message-ID: <000d01cbbed7$0fbb72a0$2f3257e0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acu+1gK1N+bwwH1iSPy5sCE+WzsfgA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx06) Cc: catherine.quinquis@orange-ftgroup.com, Paolo.Usai@etsi.org Subject: [codec] Handbook of subjective testing practical procedures 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, 28 Jan 2011 10:32:18 -0000 Hi, for those how are interested in codec testing, I would like to bring the attention to newly finished standard draft TD 477 of ITU-T study group = 12: http://www.itu.int/md/T09-SG12-110118-TD-GEN-0477/en . It will be a = standard in about three months' time and then available to the public. Currently, only people with TIES account can access it. Thanks to Paolo Usai and Catherine Quinquis, who have written this = excellent handbook. With best regards, Christian Hoene --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), Universit=E4t T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/