From erik.norvell@ericsson.com Wed Feb 8 06:11:25 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811C21F865F for ; Wed, 8 Feb 2012 06:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMCQnFfuftcJ for ; Wed, 8 Feb 2012 06:11:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9721F859E for ; Wed, 8 Feb 2012 06:10:57 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f6-4f328270eb5e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.CF.27041.072823F4; Wed, 8 Feb 2012 15:10:56 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.55]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 8 Feb 2012 15:10:56 +0100 From: Erik Norvell To: Koen Vos , "codec@ietf.org" Date: Wed, 8 Feb 2012 15:10:54 +0100 Thread-Topic: [codec] Compare tool sensitivity Thread-Index: Acyk02iKuVbTbOU8TG6YChNseq1BbxBl6ejg Message-ID: <027A93CE4A670242BD91A44E37105AEF435EC4EBD4@ESESSCMS0351.eemea.ericsson.se> References: <20111116191814.GF765@audi.shelbyville.oz> <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> In-Reply-To: <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] Compare tool sensitivity X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 14:11:25 -0000 Hi Koen, all This issue has been silent for some time. I am wondering if there has been = any progress making an agreeable proposal for the conformance testing?=20 Best regards, Erik=20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of K= oen Vos Sent: den 17 november 2011 03:49 To: Ron Cc: codec@ietf.org Subject: [codec] Compare tool sensitivity (Changed the thread subject) Ron wrote: > There is one requirement. Good interoperability. I agree completely. All compliant future encoders and decoders should work= well together. This also prevents embrace-and-extend tactics. However, within the space of guaranteed interop, there are benefits to bein= g lenient: 1. The decoder may be improved for specific use cases, by finding a differe= nt tradeoff between quality, delay, complexity, etc. For instance in a non= -real time application it may help to have a resampler with higher quality,= at the cost of higher delay and complexity. 2. A limited decoder may be better. For instance, an Opus-to-PSTN gateway = only needs a decoder to generate 8 kHz output signals. Allowing such a dec= oder enables optimizations in terms of memory and CPU. (Of course the deco= der would still have to decode any Opus bitstream, including one with more = than NB content.) =20 3. The current test disqualifies a huge space of decoders that sound (virtu= ally) identical. Simply getting the sign wrong of the output signal should= n't make a company liable for a patent lawsuit. A non-goal for the WG, in my opinion, is to ensure that all users get the q= uality they are deemed to deserve. While nobody wants decoders that sound = like crap, few users will stick with an application that plays out a jingle= whenever an Opus bitstream is received. And we already allow crappy _enco= ders_. I prefer the market place to weed out crap over threats of litigati= on. While there's no perfect solution, I think Jean-Marc and I will come up wit= h a compare tool that provides a small -but useful- amount of freedom to ch= ange the decoder without breaking the interop guarantee. koen. ----- Original Message ----- From: "Ron" To: codec@ietf.org Sent: Thursday, November 17, 2011 3:18:14 AM Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: > Hi, >=20 > I would suggest to split two things:=20 >=20 > First, we need a notion for standard conformance because of the legal=20 > IPR requirements (can be more relaxing). > Second, we need some tests in respect to interoperability (should be=20 > more straight). >=20 > Both tests need to fulfill different requirements. I don't see these as different requirements at all. The IPR in this case is not being used to protect a revenue stream garnered= from unwitting users of the technology - it is being used to protect the i= nteroperability guarantees that can be offered to end users. Separating these two things, and watering down the protection offered by th= e IPR does not offer any benefit to users, only to implementers who might b= e tempted to compromise on interoperability. Possibly for 'practical' reasons, and possibly for 'commercial' reasons of their own - but their rea= sons don't matter, only the end effect, a degraded user experience, is the = important consideration (to avoid) here. There is one requirement. Good interoperability. IPR grant conformance is= the only binding method we have of ensuring this. As heretical as it may = seem to the FRAND profit seekers - the real profit to be made here from pat= ents is an enhanced and assured user experience. Of course, since I don't actually own any of the IPR, I can't speak for the= people who do, or for their motives - but this is what I see as their most= valuable gift to us, above and beyond the actual technology itself. > Also, I like Erik's idea to allow for algorithms to replace patented=20 > stuff in the codec - even if the quality is a bit worse. I think this is a fallacy. It was argued that this extra freedom might all= ow people to produce a 'better' decoder. That seems like nonsense to me, t= he decoder is never going to be able to recover information that simply isn= 't there - the best it can do is recover all of it with tight fidelity. Wh= ich is what the current conformance test tries to measure. It was also argued that this freedom might allow people to produce a worse = decoder. That seems like something we should strongly avoid. There seem to be only three reasons to do this: - Save cycles on underpowered systems. But the requirements already include assessing complexity guarantees are within reasonable bounds. - Sidestep the IPR to produce systems that are not fully interoperable but can still claim (some semblance of) conformance. - Provide distortive 'enhancements' that some users may assess as being pleasing on a first brief listen, but which reduce the real fidelity of the output. (eg. simulate mp3 distortion for the people who listening tests actually prove like that more than lossless original) Both those latter cases carry a danger of sounding like crap if future (real) enhancements are made to the encoder which actually does increase th= e real fidelity and information content of the encoded signal. The likelihood of such improvements being made to the encoder is high, so I= think this is a real jeopardy which we should not inflict upon end users o= r limit future encoder work by. The decoder should decode the bitstream accurately. If it cannot, then it = should not claim to decode Opus. People are always free to sidestep the IP= R and make something that sounds worse. They just shouldn't be encouraged = or allowed to then also misrepresent that as Opus and mislead the users tha= t this group set out to serve. As some of the liaisons have reminded us, w= e're here because we wanted to *raise* the bar, not to just continue Busine= ss As Usual in patented codec proliferation. So we should do just that. And make everyone happy :) IMO Ron _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jmvalin@mozilla.com Thu Feb 9 08:47:00 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB58D21F86DB for ; Thu, 9 Feb 2012 08:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvpgxylJl35M for ; Thu, 9 Feb 2012 08:46:57 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id F067321F86B6 for ; Thu, 9 Feb 2012 08:46:56 -0800 (PST) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 0AE274AEDB4; Thu, 9 Feb 2012 08:46:55 -0800 (PST) Message-ID: <4F33F87E.8090706@mozilla.com> Date: Thu, 09 Feb 2012 11:46:54 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Erik Norvell References: <20111116191814.GF765@audi.shelbyville.oz> <1430038818.152350.1321498110672.JavaMail.root@lu2-zimbra> <027A93CE4A670242BD91A44E37105AEF435EC4EBD4@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <027A93CE4A670242BD91A44E37105AEF435EC4EBD4@ESESSCMS0351.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] Compare tool sensitivity X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:47:01 -0000 Hi Erik, Sorry for taking so long to commit this change to the repository. The new tool is now in the Opus master branch. Koen and I have come up with a better comparison tool that is based on a spectral distance estimate (derived from the Itakura-Saito distance) rather than on the spectrum of the error signal. That new tool is better at throwing out irrelevant information (such as small phase mis-alignments) and is also much more permissive than the previous tool was. The tool maps the spectral distance to an (arbitrary) quality scale that goes from 0% to 100%, where 0% is the passing threshold (negative means the comparison fails). Using the last comparison tool, we had a few cases where the fixed and float were considered too far to pass. With the new tool, the worst score for any of the -10 test vectors is now 89%. The passing threshold (0%) is set to a level that's equivalent to white noise with 48 dB SNR -- about what you get from a cassette tape. I think this should allow quite a bit of freedom in decoder implementations. This was verified when both of Tim's independent re-implementations of SILK (on fixed-point, one float) passed the test. Let us know if you have any questions/issues. You can get the new tool from the master branch, or you can use this link just to see the updated file: http://git.xiph.org/?p=opus.git;a=blob;f=src/opus_compare.c Cheers, Jean-Marc On 08/02/12 09:10 AM, Erik Norvell wrote: > Hi Koen, all > > This issue has been silent for some time. I am wondering if there has been any progress making an agreeable proposal for the conformance testing? > > Best regards, > Erik > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos > Sent: den 17 november 2011 03:49 > To: Ron > Cc: codec@ietf.org > Subject: [codec] Compare tool sensitivity > > (Changed the thread subject) > > Ron wrote: >> There is one requirement. Good interoperability. > > I agree completely. All compliant future encoders and decoders should work well together. This also prevents embrace-and-extend tactics. > > However, within the space of guaranteed interop, there are benefits to being lenient: > > 1. The decoder may be improved for specific use cases, by finding a different tradeoff between quality, delay, complexity, etc. For instance in a non-real time application it may help to have a resampler with higher quality, at the cost of higher delay and complexity. > > 2. A limited decoder may be better. For instance, an Opus-to-PSTN gateway only needs a decoder to generate 8 kHz output signals. Allowing such a decoder enables optimizations in terms of memory and CPU. (Of course the decoder would still have to decode any Opus bitstream, including one with more than NB content.) > > 3. The current test disqualifies a huge space of decoders that sound (virtually) identical. Simply getting the sign wrong of the output signal shouldn't make a company liable for a patent lawsuit. > > A non-goal for the WG, in my opinion, is to ensure that all users get the quality they are deemed to deserve. While nobody wants decoders that sound like crap, few users will stick with an application that plays out a jingle whenever an Opus bitstream is received. And we already allow crappy _encoders_. I prefer the market place to weed out crap over threats of litigation. > > While there's no perfect solution, I think Jean-Marc and I will come up with a compare tool that provides a small -but useful- amount of freedom to change the decoder without breaking the interop guarantee. > > koen. > > > ----- Original Message ----- > From: "Ron" > To: codec@ietf.org > Sent: Thursday, November 17, 2011 3:18:14 AM > Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10 > > On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote: >> Hi, >> >> I would suggest to split two things: >> >> First, we need a notion for standard conformance because of the legal >> IPR requirements (can be more relaxing). >> Second, we need some tests in respect to interoperability (should be >> more straight). >> >> Both tests need to fulfill different requirements. > > I don't see these as different requirements at all. > > The IPR in this case is not being used to protect a revenue stream garnered from unwitting users of the technology - it is being used to protect the interoperability guarantees that can be offered to end users. > > Separating these two things, and watering down the protection offered by the IPR does not offer any benefit to users, only to implementers who might be tempted to compromise on interoperability. Possibly for 'practical' > reasons, and possibly for 'commercial' reasons of their own - but their reasons don't matter, only the end effect, a degraded user experience, is the important consideration (to avoid) here. > > There is one requirement. Good interoperability. IPR grant conformance is the only binding method we have of ensuring this. As heretical as it may seem to the FRAND profit seekers - the real profit to be made here from patents is an enhanced and assured user experience. > > Of course, since I don't actually own any of the IPR, I can't speak for the people who do, or for their motives - but this is what I see as their most valuable gift to us, above and beyond the actual technology itself. > > >> Also, I like Erik's idea to allow for algorithms to replace patented >> stuff in the codec - even if the quality is a bit worse. > > I think this is a fallacy. It was argued that this extra freedom might allow people to produce a 'better' decoder. That seems like nonsense to me, the decoder is never going to be able to recover information that simply isn't there - the best it can do is recover all of it with tight fidelity. Which is what the current conformance test tries to measure. > > It was also argued that this freedom might allow people to produce a worse decoder. That seems like something we should strongly avoid. > There seem to be only three reasons to do this: > > - Save cycles on underpowered systems. > But the requirements already include assessing complexity guarantees > are within reasonable bounds. > > - Sidestep the IPR to produce systems that are not fully interoperable > but can still claim (some semblance of) conformance. > > - Provide distortive 'enhancements' that some users may assess as being > pleasing on a first brief listen, but which reduce the real fidelity > of the output. (eg. simulate mp3 distortion for the people who > listening tests actually prove like that more than lossless original) > > Both those latter cases carry a danger of sounding like crap if future > (real) enhancements are made to the encoder which actually does increase the real fidelity and information content of the encoded signal. > > The likelihood of such improvements being made to the encoder is high, so I think this is a real jeopardy which we should not inflict upon end users or limit future encoder work by. > > The decoder should decode the bitstream accurately. If it cannot, then it should not claim to decode Opus. People are always free to sidestep the IPR and make something that sounds worse. They just shouldn't be encouraged or allowed to then also misrepresent that as Opus and mislead the users that this group set out to serve. As some of the liaisons have reminded us, we're here because we wanted to *raise* the bar, not to just continue Business As Usual in patented codec proliferation. > So we should do just that. And make everyone happy :) > > IMO > > Ron > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > 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 internet-drafts@ietf.org Fri Feb 17 13:25:31 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD8111E8099; Fri, 17 Feb 2012 13:25:31 -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.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUqDj4-Q49iV; Fri, 17 Feb 2012 13:25:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87411E8095; Fri, 17 Feb 2012 13:25:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120217212531.26543.25760.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 13:25:31 -0800 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:25:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working= Group of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-11.txt Pages : 324 Date : 2012-02-17 This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-codec-opus-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-opus-11.txt From jmvalin@mozilla.com Fri Feb 17 13:35:40 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3226521F85CF for ; Fri, 17 Feb 2012 13:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 290BNuIeShv5 for ; Fri, 17 Feb 2012 13:35:38 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id D704721F85CD for ; Fri, 17 Feb 2012 13:35:38 -0800 (PST) Received: from [192.168.1.15] (modemcable014.207-160-184.mc.videotron.ca [184.160.207.14]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id B5A304AEDA9 for ; Fri, 17 Feb 2012 13:35:37 -0800 (PST) Message-ID: <4F3EC828.7030208@mozilla.com> Date: Fri, 17 Feb 2012 16:35:36 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: codec@ietf.org References: <20120217212531.26543.25760.idtracker@ietfa.amsl.com> In-Reply-To: <20120217212531.26543.25760.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] I-D Action: draft-ietf-codec-opus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:35:40 -0000 Hi, We just uploaded version -11 of the draft to address the comments made during the second WGLC and during the Taipei meeting. The list of changes is below: - Fix for noise floor tracking as discussed in last meeting (see issue #1) - Limit LPC prediction gain as discussed in last meeting (see issue #2) - Fix LPC/LTP state rescaling as discussed in last meeting (see issue #3) - Resampler simplification as discussed in last meeting (see issue #4) - Making it easier for an alternate implementation to pass the conformance test as discussed in last meeting - Editorial/spelling fixes received - Minor code improvements to facilitate further testing and creation of better test vectors - Addressed some comments about variables using names reserved by POSIX (_ prefix) or some ADI compilers (bank) - Fixes for optional "self-delimited packing" On 17/02/12 04:25 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. > > Title : Definition of the Opus Audio Codec > Author(s) : Jean-Marc Valin > Koen Vos > Timothy B. Terriberry > Filename : draft-ietf-codec-opus-11.txt > Pages : 324 > Date : 2012-02-17 > > This document defines the Opus interactive speech and audio codec. > Opus is designed to handle a wide range of interactive audio > applications, including Voice over IP, videoconferencing, in-game > chat, and even live, distributed music performances. It scales from > low bitrate narrowband speech at 6 kb/s to very high quality stereo > music at 510 kb/s. Opus uses both linear prediction (LP) and the > Modified Discrete Cosine Transform (MDCT) to achieve good compression > of both speech and music. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-codec-opus-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-codec-opus-11.txt > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@iii.ca Fri Feb 24 08:05:03 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87621F8807 for ; Fri, 24 Feb 2012 08:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGq0+aSdq+JN for ; Fri, 24 Feb 2012 08:05:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6AA21F85D7 for ; Fri, 24 Feb 2012 08:04:45 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD0A922E259 for ; Fri, 24 Feb 2012 11:04:38 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 24 Feb 2012 09:04:36 -0700 References: <20120223210407.19243.96673.idtracker@ietfa.amsl.com> To: codec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [codec] Fwd: codec - Requested session has been scheduled for IETF 83 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:05:03 -0000 FYI on meeting time at IETF 83 - note this is *draft* and may change. Begin forwarded message: > codec Session 1 (1 hour) > Friday, Afternoon Session I 1120-1220 > Room Name: 252A