From mjordan@digium.com Mon Jul 1 09:19:49 2013 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 6C04E11E8108 for ; Mon, 1 Jul 2013 09:19:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iP-azTjugrX for ; Mon, 1 Jul 2013 09:19:42 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0EB11E80E2 for ; Mon, 1 Jul 2013 09:19:41 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so2547328lbh.21 for ; Mon, 01 Jul 2013 09:19:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RtWkGds93Q8U9rs42slkqv0OaXIK5sGKh8KT48oRCe8=; b=TLhLMURvyNW3wMBCO9YxjRx538jwY7jVH7CEZMUlkVOav7E3lY6/vqd2AJAUJpQ8mu gP1ErTGfoPtmexidCkPJOFHngqqCAF2Ea/Wa9Xth4NN2LXKWREJrb4iqef5y5oVXDqZ/ ht4nEk5MKT4Di7E0e5lx+0WRyY7PMhujil55Y4MEsy37piFirg/FAopbGX4QB7LJPAnK Eh3KJ8nAhRzcnMtOtB3EzKpdFYs0HZ+1kElt4K0HK2T43xXI8GJWVC5eorRTFlFtylFy jlsNwliYSRkg+FxOO7PruurtrObXjG2CAGqfP5PV+Aav3Y40A8lGgFZnxnPIjEE1Z1r2 N/SA== MIME-Version: 1.0 X-Received: by 10.152.9.69 with SMTP id x5mr12260992laa.57.1372695580197; Mon, 01 Jul 2013 09:19:40 -0700 (PDT) Received: by 10.112.50.205 with HTTP; Mon, 1 Jul 2013 09:19:40 -0700 (PDT) In-Reply-To: <00a501ce74c2$c41f0dd0$4c5d2970$@mstvp.com> References: <51A64F3E.5040002@digium.com> <8E24D629-1D4C-431A-B466-4DD5F0273F9A@edvina.net> <00a501ce74c2$c41f0dd0$4c5d2970$@mstvp.com> Date: Mon, 1 Jul 2013 11:19:40 -0500 Message-ID: From: Matthew Jordan To: Michael Graves Content-Type: multipart/alternative; boundary=089e0158b4de7164b204e07598ea X-Gm-Message-State: ALoCoQmOraem7fakluot7VkzEpEuwFHawPlYOujSwhI409BlMeAfbS15vKi60MJqopZYTynhZ9Ix Cc: "Cullen Jennings \(fluffy\)" , codec@ietf.org Subject: Re: [codec] [asterisk-dev] Opus and VP8 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:19:49 -0000 --089e0158b4de7164b204e07598ea Content-Type: text/plain; charset=ISO-8859-1 Hi there! A little context might be helpful for the e-mail Olle forwarded over. Lorenzo Miniero is currently working on an implementation of the Opus codecfor Asterisk and was discussing it on the asterisk- dev mailing list (which is entirely appropriate, as that is what the mailing list is there for!) Since we are quickly coming up on a feature freeze deadline for the next major version of Asterisk, I wanted to make sure that Lorenzo knew Digium's position regarding inclusion of a GPLv2 compliant Opus codec in Asterisk at this moment in time. That means the e-mail was targeted towards a discussion of: * A module that does transcoding of the Opus codec * A module that is licensed under the GPLv2 and distributed with Asterisk * A module that is included in the next major version of Asterisk My statements were made specifically to that scenario, and do not affect possible future support of Opus in Asterisk, pass-through support, or a module produced under a different licensing scheme. I probably could have clarified that a bit better in my original e-mail. I'll also admit I may have pulled out the soap box on that e-mail. What can I say - my loathing and disdain for entities that produce no tangible product, benefit society in no meaningful way, and use intellectual property as a means to stifle, suppress, and kill innovation rather than protect it knows no bounds. I'll try to address the individual statements in this e-mail chain below. On Sat, Jun 29, 2013 at 7:18 AM, Michael Graves wrote: > Earlier this week Mr Duffet & Mr Sokol performed a demo at WebRTC Expo in > Atlanta. It involved Asterisk on a Raspberry Pi interacting with Chrome via > WebRTC. > > The implication is that Asterisk now or will soon handle Opus, web > sockets, etc.**** > > ** ** > > Michael Graves **** > > ** > Asterisk 11 already contains support SIP over WebSockets, DTLS-SRTP, and ICE/STUN/TURN. Everything in the demo that was Asterisk related has been released for almost a year now. Asterisk 11 does not contain support for Opus, nor will it - although that's simply the case of our release policy not allowing for new features in an LTS release branch, and has nothing to do with license models or IPRs. *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Anthony Minessale > *Sent:* Friday, June 28, 2013 7:04 PM > *To:* Cullen Jennings (fluffy) > *Cc:* codec@ietf.org > *Subject:* Re: [codec] [asterisk-dev] Opus and VP8**** > > ** ** > > I think everything you can iterate about VoIP / Internet / Security in > general leads to some patent claim or another.**** > > ** ** > > We've had a working Opus module in FreeSWITCH for over a year now and our > new WebRTC beta utilizes it. https://webrtc.freeswitch.org**** > > We're in a similar boat with video and have to do some work if we wanted > to achieve transcoding.**** > > ** ** > > Asterisk already has Silk and CELT anyway so aren't they already opening > that can of worms? > Xiph has made public a statement that an external council has determined that Opus can be implemented without violating the existing IPRs. However, while that statement is publicly available, the analysis that led to that conclusion does not appear to be - and even if it were, IANAL (much less one that specializes in codec patents). I will say that knowledge of at least one external council determining that there are no licensing impacts is certainly nice and a good starting point. However, every project has to make their own determination as to what goes in it and what doesn't. If a project evaluates a technology and determines that there are no licensing issues with including that technology, that's certainly great. But that doesn't change the fact that the burden of the decision rests with each project individually. Obvious rejoinder: "Have you evaluated the IPRs for Opus"? Short answer: it's a month to feature freeze for Asterisk 12 and we have a single in-house council. Neither she nor I are lacking for things to do. As far as Asterisk and Silk/CELT are concerned, Asterisk does not include a GPLv2 module of the Silk or CELT codec in its distribution. Digium has, however, produced Silk and CELT codec modules, in the same way that we produce a G.729 codec module. > ** > > On Fri, Jun 28, 2013 at 5:28 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote:**** > > > Well, Asterisk does SIP and that has way more IPR on it than Opus, so uh, > I guess you will need to decide if you think some random claim on IETF web > site is a valid concern or not. Good luck. Note that blocking all forward > progress on asterisk by filing claims on an IETF web page is also a risk to > the project. > > (Oh, and TLS has lots of IPR too) > > PS - every effort possible has been made to ensure that Opus is GPL > compatible.**** > > > > You're right: SIP/TLS has more IPR than Opus. As do many other technologies in our industry, some of which are in Asterisk. We try to make licensing evaluations on all patches that go into Asterisk. If a technology that has IPRs filed against it is implemented in Asterisk it is because we evaluated those claims and made a determination that the technology's inclusion in Asterisk was warranted, the claims didn't exist at the time the patch was written, or the claims weren't known about when the patch went in. In this particular case, at this moment in time, we haven't had the opportunity to evaluate Opus to the extent that I'd feel comfortable with Lorenzo's patch going into Asterisk. We try very hard not to make uninformed decisions regarding licensing of features going into the project. Does this slow us down sometimes? Yes. Does it limit some things that go in Asterisk? Yes. Not to pull out the soap box again, but it's better to be prudent and careful than end up as another casualty of the American patent system. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org --089e0158b4de7164b204e07598ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi there!

A little cont= ext might be helpful for the e-mail Olle forw= arded over. Lorenzo Miniero is currently work= ing on an implementation of the Opus codec fo= r Asterisk and was discussing it on the asterisk-dev= mailing list (which is entirely appropriate, as that is what the ma= iling list is there for!) Since we are quickly coming up on a feature freez= e deadline for the next major version of Asterisk, I wanted to make sure th= at Lorenzo knew Digium's position regardi= ng inclusion of a GPLv2 compliant Opus codec = in Asterisk at this moment in time.

That means the e-mail was targeted towards a discussion= of:
* A module that does transcoding of the Opus codec
* A module tha= t is licensed under the GPLv2 and distributed with Asterisk
* A module that is included in the next major version of Asterisk

My statements were made specifically to that scenario,= and do not affect possible future support of Opus in Asterisk, pass-throug= h support, or a module produced under a different licensing scheme. I proba= bly could have clarified that a bit better in my original e-mail.

I'll also admit I may have pulled out the soap box = on that e-mail. What can I say - my loathing and disdain for entities that = produce no tangible product, benefit society in no meaningful way, and use = intellectual property as a means to stifle, suppress, and kill innovation r= ather than protect it knows no bounds.

I'll try to address the individual statements in th= is e-mail chain below.

On Sat, Jun 29, 2013 at 7:= 18 AM, Michael Graves <mgraves@mstvp.com> wrote:

Earlier this week Mr Duffet & Mr Sokol performed = a demo at WebRTC Expo in Atlanta. It involved Asterisk on a Raspberry Pi in= teracting with Chrome via WebRTC.

=A0<snip>
=A0

The implication is that Asterisk no= w or will soon handle Opus, web sockets, etc.

=A0

Michael Graves

=A0

As= terisk 11 already contains support SIP over WebSocke= ts, DTLS-SRTP, and ICE/STUN/TURN. Everything in the demo=A0that was Asterisk relate= d has been released for almost a year now.

Asterisk 11 does not contain support for Op= us, nor will it - although that's simply the case of our release policy= not allowing for new features in an LTS rele= ase branch, and has nothing to do with license models or IPRs.

From: codec-b= ounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Anthony Miness= ale
Sent: Friday, June 28, 2013 7:04 PM
To: Cullen Jennings (f= luffy)
Cc: co= dec@ietf.org
Subject: Re: [codec] [asterisk-dev] Opus and VP8=

=A0

I think everything you can iterate about VoIP / Internet / Security = in general leads to some patent claim or another.

=A0

We've had a working Opus = module in FreeSWITCH for over a year now and our new WebRTC beta utilizes i= t. =A0https://w= ebrtc.freeswitch.org

We're in a similar boat with video and have to= do some work if we wanted to achieve transcoding.

<= div>

=A0

Asterisk al= ready has Silk and CELT anyway so aren't they already opening that can = of worms?


Xiph has made public a statement that an external counci= l has determined that Opus can be implemented without violating the existin= g IPRs. However, while that statement is publ= icly available, the analysis that led to that conclusion does not appear to= be - and even if it were, IANAL (much less one that= specializes in codec patents). I will say that knowledge of at leas= t one external council determining that there are no licensing impacts is c= ertainly nice and a good starting point. However, every project has to make= their own determination as to what goes in it and what doesn't. If a p= roject evaluates a technology and determines that there are no licensing is= sues with including that technology, that's certainly great. But that d= oesn't change the fact that the burden of the decision rests with each = project individually.

Obvious rejoinder: "Have you evaluated the IPRs for Opus"?

S= hort answer: it's a month to feature freeze for Asterisk 12 and we have= a single in-house council. Neither she nor I are lacking for things to do.=

As far as Asterisk and Silk/CELT are concer= ned,=A0Asterisk does not include a GPLv2 module of the Silk or CELT codec in its distribution. Di= gium has, however, produced Silk and CELT cod= ec modules, in the same way that we produce a G.729 codec module.


On Fri, Jun 28, 2013 at 5:28= PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:


Well, Asterisk does SIP and that ha= s way more IPR on it than Opus, so uh, I guess you will need to decide if y= ou think some random claim on IETF web site is a valid concern or not. Good= luck. Note that blocking all forward progress on asterisk by filing claims= on an IETF web page is also a risk to the project.

(Oh, and TLS has lots of IPR too)

PS - every effort possible has= been made to ensure that Opus is GPL compatible.



You're right: SIP/TLS has more IPR than Opus. As do many other = technologies in our industry, some of which are in Asterisk. We try to make= licensing evaluations on all patches that go into Asterisk. If a technolog= y that has IPRs filed against it is implement= ed in Asterisk it is because we evaluated those claims and made a determina= tion that the technology's inclusion in Asterisk was warranted, the cla= ims didn't exist at the time the patch was written, or the claims weren= 't known about when the patch went in.

In this particular case, at this moment in time, we hav= en't had the opportunity to evaluate Opus to the extent that I'd fe= el comfortable with Lorenzo's patch going into Asterisk.

We try very hard not to make uninformed decisions regarding = licensing of features going into the project. Does this slow us down someti= mes? Yes. Does it limit some things that go in Asterisk? Yes. Not to pull o= ut the soap box again, but it's better to be prudent and careful than e= nd up as another casualty of the American patent system.

Matt

--
Matthew Jordan
Dig= ium, Inc. | Engineering Manager
445 Jan Davis Drive NW - H= untsville, AL 35806 - USA
--089e0158b4de7164b204e07598ea-- From tterribe@xiph.org Fri Jul 5 12:34:45 2013 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 8C90721F99F4 for ; Fri, 5 Jul 2013 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z09v5QlWLis0 for ; Fri, 5 Jul 2013 12:34:40 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E985521F9A3D for ; Fri, 5 Jul 2013 12:34:40 -0700 (PDT) Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3AD21F213B; Fri, 5 Jul 2013 12:34:39 -0700 (PDT) Message-ID: <51D71FCE.5040207@xiph.org> Date: Fri, 05 Jul 2013 12:34:38 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: Discussion about the current and future development of Matroska References: <51AD158F.7040302@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] [Matroska-devel] Opus in Matroksa Cont. 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, 05 Jul 2013 19:34:45 -0000 Cross-posting to codec: N.B. that applies to replies there. Moritz Bunkus wrote: > an audio packet corresponds to a video packet with timestamp 0. It also > seems not so say what Opus needs it to say: that a number of samples > have to be dropped because they're simply invalid. Quoting from the first paragraph of Section 4.1: "Therefore, the first few samples produced by the decoder do not correspond to real input audio, but are instead composed of padding inserted by the encoder to compensate for this latency." What do you think the text should say to make it clearer that "a number of samples have to be dropped because they're simply invalid"? From tterribe@xiph.org Mon Jul 8 11:26:40 2013 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 422B421F9C85 for ; Mon, 8 Jul 2013 11:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss1Y3qqqr7C2 for ; Mon, 8 Jul 2013 11:26:19 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6007C21F9BFB for ; Mon, 8 Jul 2013 11:26:19 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 577FFF217D; Mon, 8 Jul 2013 11:26:14 -0700 (PDT) Message-ID: <51DB0446.2080807@xiph.org> Date: Mon, 08 Jul 2013 11:26:14 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: Discussion about the current and future development of Matroska References: <51AD158F.7040302@mozilla.com> <51D71FCE.5040207@xiph.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] [Matroska-devel] Opus in Matroksa Cont. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:26:40 -0000 Moritz Bunkus wrote: > I think you misunderstood me. I did not mean to say that the Opus > specs (any of them) should be changed. I only meant the wording in the > _Matroska_ specs for the newly-introduced "CodecDelay" element[1] > which, at the moment, reads as follows: > >> CodecDelay is the delay in nanoseconds to add to each Block timestamp. >> The value should be small so the muxing of tracks with the same actual >> timestamp are in the same Cluster. > > I think this wording is extremely misleading and does not really allow > the use of this element to hold Opus' pre-skip value -- though it has > been our intention to store just that in it. > > This is purely a matter internal to the Matroska team and specs and > has nothing to do with any of the Opus RFCs and drafts. Ah! Sorry for the noise, I did indeed confuse the antecedent. If you do find things that are unclear or that could be improved in the IETF drafts, please don't hesitate to let us know. More review is always appreciated. > Kind regards, > mosu > > [1] http://www.matroska.org/technical/specs/index.html From jmvalin@mozilla.com Fri Jul 12 09:46:53 2013 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 63DC021F9E45 for ; Fri, 12 Jul 2013 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6-xf7f5yxGr for ; Fri, 12 Jul 2013 09:46:48 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB321F933B for ; Fri, 12 Jul 2013 09:46:48 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E187EF2344; Fri, 12 Jul 2013 09:46:46 -0700 (PDT) Message-ID: <51E032F6.40908@mozilla.com> Date: Fri, 12 Jul 2013 12:46:46 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opus@xiph.org" , "codec@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [codec] Opus 1.1-beta, a demo, and version 1.0.3 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, 12 Jul 2013 16:46:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We just released Opus 1.1-beta and Monty wrote a nice demo showing off all the new features, including many improvements over the alpha release: http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml As usual, the code can be downloaded from: http://opus-codec.org/downloads/ In addition to 1.1-beta, we also released 1.0.3, which includes a backport of the new 1.1 surround API, as well as several bug fixes. Of course, both of these new releases are fully compatible with the Opus specification in RFC 6716. Please report any problems you encounter, either on the mailing list or by joining the #opus channel on irc.freenode.net. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4DL1AAoJEJ6/8sItn9q9gUwIALDoovQ8VPBfOqAI6CiavA2z itpN+BbBA7sCa08OLs3+EERxmpIavVhIpqG4gfhxXo3H1pr4888l2kgBi6tL2tav 5RILmKjrITeZtQQS5giHqXki9hOkqz7KkYK9ly9Svqm8STKcNIpFPqEyu6bMqOHn easV897AjJ4JDJOnBQ/ro2rCNjP9TZuxF2AWfSyqGSPBsuMF2f/Dot4iK+Hqo61u yu0kP9jbtTS7zPlb4KyRUtAq89V4+9ulSXbVRRGkt0CfJ7bLlufSfIb6fU0PZWt1 Io7EXySnsyoVgeDeZtfHGxvPS9pj5pf/Qu64nEnQCMRDc5Lxxz3qXahxuxMvSQo= =3FCu -----END PGP SIGNATURE----- From jmvalin@jmvalin.ca Fri Jul 12 19:39:36 2013 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 3A23621E8063 for ; Fri, 12 Jul 2013 19:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwPUIJPV-1Ae for ; Fri, 12 Jul 2013 19:39:31 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA811E8162 for ; Fri, 12 Jul 2013 19:39:31 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id A7F28F2072 for ; Fri, 12 Jul 2013 19:39:30 -0700 (PDT) Message-ID: <51E0BDE1.9020901@jmvalin.ca> Date: Fri, 12 Jul 2013 22:39:29 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "codec@ietf.org" References: <20130712222833.13138.87216.idtracker@ietfa.amsl.com> In-Reply-To: <20130712222833.13138.87216.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130712222833.13138.87216.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] Fwd: New Version Notification for draft-valin-codec-opus-update-00.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: Sat, 13 Jul 2013 02:39:36 -0000 Hi, See these proposed fixes to the Opus RFC. These are minor changes to the normative part of the reference implementation. Cheers, Jean-Marc -------- Original Message -------- Subject: New Version Notification for draft-valin-codec-opus-update-00.txt Date: Fri, 12 Jul 2013 15:28:33 -0700 From: internet-drafts@ietf.org To: Jean-Marc Valin , Koen Vos , Tim Terriberry , "Timothy B. Terriberry" A new version of I-D, draft-valin-codec-opus-update-00.txt has been successfully submitted by Jean-Marc Valin and posted to the IETF repository. Filename: draft-valin-codec-opus-update Revision: 00 Title: Updates to the Opus Audio Codec Creation date: 2013-07-12 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-valin-codec-opus-update-00.txt Status: http://datatracker.ietf.org/doc/draft-valin-codec-opus-update Htmlized: http://tools.ietf.org/html/draft-valin-codec-opus-update-00 Abstract: This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716]. The IETF Secretariat From christian.hoene@symonics.com Mon Jul 22 13:35:47 2013 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 BDE5711E813A for ; Mon, 22 Jul 2013 13:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_19=0.6] 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 jc8ZOeONY93O for ; Mon, 22 Jul 2013 13:35:43 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id EA99111E8123 for ; Mon, 22 Jul 2013 13:35:42 -0700 (PDT) Received: (qmail 11483 invoked by uid 0); 22 Jul 2013 20:35:21 -0000 Received: from unknown (HELO box785.bluehost.com) (66.147.244.85) by oproxy13.unifiedlayer.com with SMTP; 22 Jul 2013 20:35:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=symonics.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=/+gXDizGQKF2tbJxJrcpqTK/Y/HFq2yzd5KOdDhvVjM=; b=iQetxrZjTImucx2CWSWZLFQGCkMEc6rGPTyViHOB6owyDmnldy4e1q1kNbXsZqXRvkadGOy9+eG9DZiEBolE/fGFo74VxTdm9am4Kvouiy/dx1bumadOJ/y6OCqcpARG; Received: from [109.192.195.32] (port=50298 helo=samsung7PC) by box785.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1V1MpF-0008Qp-4q for codec@ietf.org; Mon, 22 Jul 2013 14:35:21 -0600 From: "Christian Hoene" To: References: <20130722201523.30015.75397.idtracker@ietfa.amsl.com> <51ED9480.8000704@uni-tuebingen.de> In-Reply-To: <51ED9480.8000704@uni-tuebingen.de> Date: Mon, 22 Jul 2013 22:35:22 +0200 Message-ID: <005901ce871a$fe569670$fb03c350$@symonics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01CE872B.C1E5F620" X-Mailer: Microsoft Outlook 14.0 thread-index: AQGDWZZoVivfV8W0ZMjljpwueGLImQFtquHEmfwVbaA= Content-Language: de X-Identified-User: {1573:box785.bluehost.com:soniconb:symonics.com} {sentby:smtp auth 109.192.195.32 authed with christian.hoene@symonics.com} Subject: [codec] WG: [87all] IETF 87 Technical Plenary Experiment X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:35:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01CE872B.C1E5F620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -------- Original-Nachricht -------- Betreff: [87all] IETF 87 Technical Plenary Experiment Datum: Mon, 22 Jul 2013 13:15:23 -0700 Von: IAB Chair Antwort an: ietf@ietf.org An: 87all@ietf.org The OPUS codec, defined in RFC 6716, can scale from low bit-rate narrowband speech to very high quality stereo music, making it suitable for a wide range of audio applications. The IETF 87 Technical Plenary session will cover the past and future of Opus as well as the lessons learned from the standardization process that could apply to future IETF work. To provide additional materials relating to the plenary topic, the IAB has created a wiki. If you have material relevant to the plenary topic (such as papers or test data relating to OPUS), please contribute it to the wiki, either by editing it yourself, or sending it to the IAB . Also, during the IETF 87 Technical Plenary, the MeetEcho team will be running an experiment to enable remote participation in the Technical Plenary using the OPUS codec. Information on how to access on the Remote Participation experiment is also available on the IAB wiki page: http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87#IETF87TechnicalPlenar y:OPUSCodec On behalf of the IAB, Russ Housley IAB Chair _______________________________________________ 87all mailing list 87all@ietf.org https://www.ietf.org/mailman/listinfo/87all ------=_NextPart_000_005A_01CE872B.C1E5F620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


-------- Original-Nachricht -------- =

<= tr>

Betreff:

[87all] IETF 87 = Technical Plenary Experiment

Datum: =

Mon, 22 Jul 2013 13:15:23 = -0700

Von:

IAB Chair <iab-chair@ietf.org>

Antwort an:

ietf@ietf.org

An: =

87all@ietf.org

 

The OPUS codec, =
defined in RFC 6716, can scale from low bit-rate =

narrowband speech to very high quality stereo =
music, making it suitable 
for a wide range of =
audio applications. The IETF 87 Technical Plenary =

session will cover the past and future of Opus as =
well as the lessons 
learned from the =
standardization process that could apply to future IETF =

work.
 =

To provide additional materials relating to the =
plenary topic, the IAB 
has created a wiki. If you =
have material relevant to the plenary topic 
(such =
as papers or test data relating to OPUS), please contribute it to =

the wiki, either by editing it yourself, or =
sending it to the IAB 
<iab at =
iab.org>.
 
Also, during =
the IETF 87 Technical Plenary, the MeetEcho team will be =

running an experiment to enable remote =
participation in the Technical 
Plenary using the =
OPUS codec.  Information on how to access on the =

Remote Participation experiment is also available =
on the IAB wiki page: 
http://trac.tools.ietf.org/group/iab/trac/wiki/IE=
TF-87#IETF87TechnicalPlenary:OPUSCodec
&nbs=
p;
On behalf of the IAB,
  =
Russ Housley
  IAB =
Chair
______________________________________________=
_
87all mailing list
87all@ietf.org
https://www.ietf.org=
/mailman/listinfo/87all

 

 

------=_NextPart_000_005A_01CE872B.C1E5F620-- From christian.hoene@symonics.com Mon Jul 22 14:10:55 2013 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 7103B11E80D3 for ; Mon, 22 Jul 2013 14:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_19=0.6] 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 oJikHfWhs0G2 for ; Mon, 22 Jul 2013 14:10:50 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id E36C311E8145 for ; Mon, 22 Jul 2013 14:10:49 -0700 (PDT) Received: (qmail 31475 invoked by uid 0); 22 Jul 2013 21:10:24 -0000 Received: from unknown (HELO box785.bluehost.com) (66.147.244.85) by oproxy7.bluehost.com with SMTP; 22 Jul 2013 21:10:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=symonics.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=zkWsn+zfZUDdE2NI0EBJR4DlsDEc/28nYHb/JX7nEH8=; b=H7JodxZ22pFc2xg8CVSkdPttUvRBStJWfA4xDtJiVcX10ftMbls7GNPQhYbbdG5PM4H+G0OsQvY6j2cfT3nKTR2A8szkrz88c6VkZErK2ImerFHcxwg5nhBWLvSso6bv; Received: from [109.192.195.32] (port=49731 helo=samsung7PC) by box785.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1V1NN9-0003KG-Jj; Mon, 22 Jul 2013 15:10:24 -0600 From: "Christian Hoene" To: "'Christian Hoene'" , References: <20130722201523.30015.75397.idtracker@ietfa.amsl.com> <51ED9480.8000704@uni-tuebingen.de> <005901ce871a$fe569670$fb03c350$@symonics.com> In-Reply-To: <005901ce871a$fe569670$fb03c350$@symonics.com> Date: Mon, 22 Jul 2013 23:10:25 +0200 Message-ID: <002901ce871f$e3ee8a40$abcb9ec0$@symonics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01CE8730.A779F250" X-Mailer: Microsoft Outlook 14.0 thread-index: AQGDWZZoVivfV8W0ZMjljpwueGLImQFtquHEAqZ09C4BAejRrQ== Content-Language: de X-Identified-User: {1573:box785.bluehost.com:soniconb:symonics.com} {sentby:smtp auth 109.192.195.32 authed with christian.hoene@symonics.com} Cc: patrick.schreiner@symonics.com Subject: Re: [codec] WG: [87all] IETF 87 Technical Plenary Experiment X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:10:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002A_01CE8730.A779F250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Guys, for the technical plenary, it would be useful to present at least some of the test results made my third parties, such as Google. For course, we have also some thousands of mushra results in an excel that just wait to be added to the opus-quality-draft. We will send them to the mailing list as an input. With best regards, Christian Hoene Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag von Christian Hoene Gesendet: Montag, 22. Juli 2013 22:35 An: codec@ietf.org Betreff: [codec] WG: [87all] IETF 87 Technical Plenary Experiment -------- Original-Nachricht -------- Betreff: [87all] IETF 87 Technical Plenary Experiment Datum: Mon, 22 Jul 2013 13:15:23 -0700 Von: IAB Chair Antwort an: ietf@ietf.org An: 87all@ietf.org The OPUS codec, defined in RFC 6716, can scale from low bit-rate narrowband speech to very high quality stereo music, making it suitable for a wide range of audio applications. The IETF 87 Technical Plenary session will cover the past and future of Opus as well as the lessons learned from the standardization process that could apply to future IETF work. To provide additional materials relating to the plenary topic, the IAB has created a wiki. If you have material relevant to the plenary topic (such as papers or test data relating to OPUS), please contribute it to the wiki, either by editing it yourself, or sending it to the IAB . Also, during the IETF 87 Technical Plenary, the MeetEcho team will be running an experiment to enable remote participation in the Technical Plenary using the OPUS codec. Information on how to access on the Remote Participation experiment is also available on the IAB wiki page: http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87#IETF87TechnicalPlenar y:OPUSCodec On behalf of the IAB, Russ Housley IAB Chair _______________________________________________ 87all mailing list 87all@ietf.org https://www.ietf.org/mailman/listinfo/87all ------=_NextPart_000_002A_01CE8730.A779F250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Guys,

 

for the technical plenary, it would be useful to present at least = some of the test results made my third parties, such as = Google.

 

For course, we have also some thousands of mushra results in an excel =  that just wait to be added to the opus-quality-draft. We will send = them to the mailing list as an input.

 

With best regards,

 

Christian Hoene

 

 

 

 

 

 

Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im = Auftrag von Christian Hoene
Gesendet: Montag, 22. Juli = 2013 22:35
An: codec@ietf.org
Betreff: [codec] WG: = [87all] IETF 87 Technical Plenary = Experiment

 


-------- = Original-Nachricht --------

<= tr>

Betreff:

[87all] IETF 87 = Technical Plenary Experiment

Datum: =

Mon, 22 Jul 2013 13:15:23 = -0700

Von:

IAB Chair <iab-chair@ietf.org>

Antwort an:

ietf@ietf.org

An: =

87all@ietf.org

 

The OPUS codec, =
defined in RFC 6716, can scale from low bit-rate =

narrowband speech to very high quality stereo =
music, making it suitable 
for a wide range of =
audio applications. The IETF 87 Technical Plenary =

session will cover the past and future of Opus as =
well as the lessons 
learned from the =
standardization process that could apply to future IETF =

work.
 =

To provide additional materials relating to the =
plenary topic, the IAB 
has created a wiki. If you =
have material relevant to the plenary topic 
(such =
as papers or test data relating to OPUS), please contribute it to =

the wiki, either by editing it yourself, or =
sending it to the IAB 
<iab at =
iab.org>.
 
Also, during =
the IETF 87 Technical Plenary, the MeetEcho team will be =

running an experiment to enable remote =
participation in the Technical 
Plenary using the =
OPUS codec.  Information on how to access on the =

Remote Participation experiment is also available =
on the IAB wiki page: 
http://trac.tools.ietf.org/group/iab/trac/wiki/IE=
TF-87#IETF87TechnicalPlenary:OPUSCodec
&nbs=
p;
On behalf of the IAB,
  =
Russ Housley
  IAB =
Chair
______________________________________________=
_
87all mailing list
87all@ietf.org
https://www.ietf.org=
/mailman/listinfo/87all

 

 

------=_NextPart_000_002A_01CE8730.A779F250-- From christian.hoene@symonics.com Fri Jul 26 07:33:33 2013 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 B182121F9926 for ; Fri, 26 Jul 2013 07:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 yxOl+8vKHnmE for ; Fri, 26 Jul 2013 07:33:28 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id BD68B21F9829 for ; Fri, 26 Jul 2013 07:33:28 -0700 (PDT) Received: (qmail 7765 invoked by uid 0); 26 Jul 2013 14:33:07 -0000 Received: from unknown (HELO box785.bluehost.com) (66.147.244.85) by oproxy12.bluehost.com with SMTP; 26 Jul 2013 14:33:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=symonics.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=Tmc/ljhqEcjyDh2LhJbg2NyTK5QvuMz0ZJaELOL4M5w=; b=QBxzjEMkLlbpZUP52woQAx2IR2Q7KAyJn0LcNqgHxZeyGv1oau3oDKFFpPxAy1S5HkQO+Bcb2qbdCaoWTWpiIoaCnfZbFDINh5BmFF4/rDZfuZVvdk6P2TmaWD/5Pp3y; Received: from [134.2.173.50] (port=65247 helo=samsung7PC) by box785.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1V2j4s-0001HY-Cs; Fri, 26 Jul 2013 08:33:06 -0600 From: "Christian Hoene" To: , Date: Fri, 26 Jul 2013 16:36:36 +0200 Message-ID: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CE8A1E.4D2D27E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6KDVttQn/yLYiqRIe3cCYRopm9KQ== Content-Language: de X-Identified-User: {1573:box785.bluehost.com:soniconb:symonics.com} {sentby:smtp auth 134.2.173.50 authed with christian.hoene@symonics.com} Cc: Michael Haun , patrick.schreiner@symonics.com Subject: [codec] Some listening test results 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, 26 Jul 2013 14:33:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01CE8A1E.4D2D27E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 a first set of results can be downloaded here http://trac.tools.ietf.org/wg/codec/trac/wiki/TestingResults More will be added soon. =20 Thanks to Patrick Schreiner and Alfons Martin, who did the tests. =20 With best regards, =20 Christian Hoene =20 =20 =20 =20 Symonics GmbH Sand 13 72076 T=FCbingen Tel +49 7071 5681302 Fax +49 7071 5681309 Email: = christian.hoene@symonics.com =20 Gesch=E4ftsf=FChrer/Presidents: Michael Haun, Dr. Christian Hoene, = Patrick Schreiner Sitz der Gesellschaft/Place of Business: T=FCbingen Registereintrag/Commercial Register: Amtsgericht Stuttgart, HRB 739918 =20 ------=_NextPart_000_0061_01CE8A1E.4D2D27E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

a first set of results can be downloaded = here

http://trac.tools.ietf.org/wg/codec/trac/wiki/TestingResults=

More = will be added soon.

 

Thanks to Patrick Schreiner and Alfons Martin, who did the = tests.

 

With best regards,

 

Christian = Hoene

 

 

 

 

Symonics = GmbH

Sand = 13

72076 = T=FCbingen

Tel +49 7071 = 5681302

Fax +49 7071 = 5681309

Email: christian.hoene@symonics.com

 

<= p class=3DMsoNormal>Gesch=E4ftsf=FChrer/President= s: Michael Haun, Dr. Christian Hoene, Patrick = Schreiner

Sitz der Gesellschaft/Place = of Business: T=FCbingen

Registereintrag/Commercial = Register: Amtsgericht Stuttgart, HRB 739918

 

------=_NextPart_000_0061_01CE8A1E.4D2D27E0-- From basilgohar@librevideo.org Fri Jul 26 09:07:22 2013 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 E798B21F9ABB for ; Fri, 26 Jul 2013 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GavyvFKZVFGH for ; Fri, 26 Jul 2013 09:07:17 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 72A9F21F9AB4 for ; Fri, 26 Jul 2013 09:07:17 -0700 (PDT) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 78F0365731A for ; Fri, 26 Jul 2013 12:07:16 -0400 (EDT) Message-ID: <51F29EAD.1080809@librevideo.org> Date: Fri, 26 Jul 2013 12:07:09 -0400 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: codec@ietf.org References: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> In-Reply-To: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Some listening test results 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, 26 Jul 2013 16:07:22 -0000 On 07/26/2013 10:36 AM, Christian Hoene wrote: > Hi, > > a first set of results can be downloaded here > > http://trac.tools.ietf.org/wg/codec/trac/wiki/TestingResults > > More will be added soon. > > Thanks to Patrick Schreiner and Alfons Martin, who did the tests. > > > > With best regards, > > > > Christian Hoene Christian, Thanks for sharing these with us. Do you have any details on the specific implementations/versions of the codecs you used? I'm particularly interested in Opus because I know that it is under active development, and quality has improved significantly in recent beta releases. -- Libre Video http://librevideo.org From ron@debian.org Fri Jul 26 13:37:25 2013 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 5F88711E816E for ; Fri, 26 Jul 2013 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvPHzSQBJ+-9 for ; Fri, 26 Jul 2013 13:37:21 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28511E8176 for ; Fri, 26 Jul 2013 13:37:17 -0700 (PDT) Received: from ppp118-210-216-146.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.216.146]) by ipmail07.adl2.internode.on.net with ESMTP; 27 Jul 2013 06:07:16 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 82DA24F8F3; Sat, 27 Jul 2013 06:07:12 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RD2sFZizb6vt; Sat, 27 Jul 2013 06:06:52 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 3498C4F902; Sat, 27 Jul 2013 06:06:52 +0930 (CST) Date: Sat, 27 Jul 2013 06:06:52 +0930 From: Ron To: Christian Hoene Message-ID: <20130726203652.GM25981@audi.shelbyville.oz> References: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Michael Haun , opus@xiph.org, codec@ietf.org, patrick.schreiner@symonics.com Subject: Re: [codec] Some listening test results 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, 26 Jul 2013 20:37:25 -0000 Hi Christian, Thanks for publishing this. Do you happen to have some numbers on what the expected bit error rates are for a "typical AMR-WB usage scenario"? I'm curious about that because you note that the Opus bitstream wasn't designed to be inherently robust against a bit error at any point in the packet (and some places will obviously effect it worse than others) - however it's not quite true that it 'cannot tolerate them'. Opus requires framing for transport, and if the transport itself doesn't ensure data integrity then it's reasonably easy for the framing to do so (such as Ogg does with its CRC). In which case a bit error simply becomes a packet loss, handled by the normal Opus PLC/FEC mechanisms. So I'm curious about how the results you saw for various packet loss rates might map to expected service quality, even without taking steps to make the link itself more robust than it already is. Given the increasing importance of data over cellular links, I'd expect the current BER targets are already fairly low, though I don't seem to be able to find any numbers on current expectation. Just some papers that note "it's much lower than people think", and "approaching the rates seen on wired networks" - though of course it's much more likely to be bursty when errors do occur, and going to vary widely by locale. Cheers, Ron On Fri, Jul 26, 2013 at 04:36:36PM +0200, Christian Hoene wrote: > Hi, > > a first set of results can be downloaded here > > > http://trac.tools.ietf.org/wg/codec/trac/wiki/TestingResults > > More will be added soon. > Thanks to Patrick Schreiner and Alfons Martin, who did the tests. > > With best regards, > Christian Hoene From tterribe@xiph.org Fri Jul 26 15:51:17 2013 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 56B8321F9B94 for ; Fri, 26 Jul 2013 15:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR1o+OZOkOaI for ; Fri, 26 Jul 2013 15:51:09 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9321F9B98 for ; Fri, 26 Jul 2013 15:51:09 -0700 (PDT) Received: from [192.168.15.42] (unknown [213.23.104.157]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BA1D9F22B0; Fri, 26 Jul 2013 15:51:07 -0700 (PDT) Message-ID: <51F2FD5A.9020900@xiph.org> Date: Fri, 26 Jul 2013 15:51:06 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: Ron , Christian Hoene References: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> <20130726203652.GM25981@audi.shelbyville.oz> In-Reply-To: <20130726203652.GM25981@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, opus@xiph.org, Michael Haun , patrick.schreiner@symonics.com Subject: Re: [codec] Some listening test results 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, 26 Jul 2013 22:51:17 -0000 Ron wrote: > I'm curious about that because you note that the Opus bitstream > wasn't designed to be inherently robust against a bit error at > any point in the packet (and some places will obviously effect > it worse than others) - however it's not quite true that it > 'cannot tolerate them'. It's not quite true to say that Opus was not designed to be robust to them, either. We use "raw bits" (RFC 6716 Section 4.1.4) where possible precisely because a bit error in one of those will not desync the bitstream. We also designed things so that the bits most sensitive to errors were at the beginning of the packet (see slide 46 of for some early measurements on the CELT layer from my 2009 LCA talk). This takes advantage of the unequal error protection afforded by Trellis Coded Modulation (TCM), and in other modulation schemes a SECDED code on the first 64 bits or so of the packet should substantially cure the bulk of bit-error impairment. As Ron notes, the choice of modulation scheme or error protection scheme is best dealt with at a layer above the codec itself. We just tried to make it easy to do so. I guess you can argue whether or not that's "inherent".