Re: [codec] comparitive quality testing
Alan Duric <Alan.Duric@telio.no> Sat, 16 April 2011 10:07 UTC
Return-Path: <Alan.Duric@telio.no>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C0D5AE06B9 for <codec@ietfc.amsl.com>; Sat, 16 Apr 2011 03:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW1Ug5+epb80 for <codec@ietfc.amsl.com>; Sat, 16 Apr 2011 03:07:36 -0700 (PDT)
Received: from hq-smtp-01.telio.no (smtp.telio.no [85.119.141.11]) by ietfc.amsl.com (Postfix) with SMTP id A11A1E0686 for <codec@ietf.org>; Sat, 16 Apr 2011 03:07:35 -0700 (PDT)
Received: from hq.telio.no (unknown [192.168.1.253]) by hq-smtp-01.telio.no (Postfix) with ESMTP id DFD49194A1D; Sat, 16 Apr 2011 12:07:32 +0200 (CEST)
Received: from hq-mail-01.HQ.TELIO.NO ([fe80::602e:2bc1:3a41:64e]) by hq-mail-01.HQ.TELIO.NO ([fe80::602e:2bc1:3a41:64e%10]) with mapi; Sat, 16 Apr 2011 12:07:33 +0200
From: Alan Duric <Alan.Duric@telio.no>
To: Roman Shpount <roman@telurix.com>
Date: Sat, 16 Apr 2011 12:07:30 +0200
Thread-Topic: [codec] comparitive quality testing
Thread-Index: Acv8Hhl3Rg1QdwBaSMCbTU08D4pJGw==
Message-ID: <6261291B-0CB8-4719-910E-2ED7A7767D82@telio.no>
References: <BCB3F026FAC4C145A4A3330806FEFDA93BA8B64643@EMBX01-HQ.jnpr.net> <BANLkTimE6EzGY76Lm+-wtWtRTQgOjqhAEw@mail.gmail.com> <DB4DD197-97D2-492C-B896-A720347D3533@cisco.com> <BANLkTin53-nu9XzNi76KRV6npcWHUx4ptA@mail.gmail.com>
In-Reply-To: <BANLkTin53-nu9XzNi76KRV6npcWHUx4ptA@mail.gmail.com>
Accept-Language: en-US, nb-NO
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, nb-NO
x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18076.002
x-tm-as-result: No--42.740600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_6261291B0CB84719910E2ED7A7767D82teliono_"
MIME-Version: 1.0
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] comparitive quality testing
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 10:07:37 -0000
Dear Roman, despite the fact that I was not able to follow work of the group for quite some time, I was informed about Your post form colleagues and I needed to react, since there is quite a number of disinformations that You are placing (though not sure if by purpose or just by not knowing better)! Comments are inline On Apr 15, 2011, at 3:20 AM, Roman Shpount wrote: I know that iLBC was picked by PacketCable and is supported by quite a few gateways. On the other hand, iLBC standard itself looks as if the codec was contributed by one company with almost nobody investing any time in its actual standardization. A number of people that were involved in the verification were and are unarguably among the authorites in the speech coding world and have been heavily involved in the previous standardization efforts by number of standardization bodies. Their reputation is a way to big to endorse something what they do not fully stand behind. In the past a number of standards brought up by ITU, ETSI and TIA have been primarily or solely contributed by one company and it does not make those standards less valuable. Quality comparisons and resource requirements seemed to be coming from the same company and accepted on their say so. Please see above.As well, Dynastat (at that point of time one of the best independent labs) have done assessment of the codec in comparison to other existing standards. Results are available through IETF archive. Most of the deployed versions of iLBC are a floating point reference implementation, which is coded in a manner as inefficient as a codec implementation can possible be. Where do You get this information??? This is prime example of "say so"! Information like this are confusing those that are following mailing list and I find it: either malicious or - You do not know much of VOIP deployments in general and thus should not be raising Your voice in front of this many people! CalbeLabs and Skype are terminating with iLBC more minutes towards PSTN then with any other codec combined. My company also happens to terminate billions of voice minutes traffic since 2004 and through very close cooperation with voice (or media) gateway manufacturers and by being advisor to a number of major carriers, I trust I have pretty good insight on implementations of various codecs and minutes that are carried with them. There are no open source fixed-point implementations, even though creating one is trivial. Reference vectors consist of a single audio file recorded by a single voice. Encoder, despite being a bit exact reference, produces different results based on optimization options or compiler. To summarize, I assumed that there is no interest in this code since there are a lot of problems with it that would have been easy to fix if anybody bothered. It looks like a proof of concept and not a finished product. Finally, amount of voice traffic carried by iLBC is only a small fraction of G.729. Please do not post stuff like this to the mailing list before doing any due diligence in advance, since people may not take seriously Your other comments that are valuable. G.729 is not much deployed at all, I suppose You are referring to G.729A implementations, which by the number of carried VoIP minutes is dwarfed by iLBC at this point of time. My company carries over 60 pct of all residential international traffic from Norway and cooperates with world leading carriers and we all know the issues of terminating G.729A carried calls on GSM based systems. That is the reason why You will find "premium" quality minutes from number of carriers conveyed by iLBC, but never with G.729A! Let's rather use (deployment) facts then "say so" when bringing something as important to communications world as OPUS is! Best regards, Alan Alan Duric CTO and Cofounder Telio Holding ASA | Oslo exchange: TELIO twitter: alanduric linkedin.com/in/alanduric<http://linkedin.com/in/alanduric> On Thu, Apr 14, 2011 at 8:55 PM, Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote: On Apr 14, 2011, at 12:21 PM, Roman Shpount wrote: > I think part of the confusion comes from the fact that there are two purposes for the comparative testing. One is to validate that the codec meets the WG requirements. Another is to show how new codec compares to the industry dominant codecs. For me, the second goal is more important then the first one. I think if we care about the adoption of Opus, we should consider making the comparative test results a deliverable for the working group. It is very hard for a real company in the open market to justify doing something, like adapting a new codec without a compelling reason. Knowing how this codec compares to other existing codecs is a big part of providing such a reason. If we look at the tests from this point of view, we need to see how Opus compares to G.729 and AMR in narrow band, and AMR-WB and G.722 in wideband, Since there are no existing deployments of a meaningful size (apart from a closed proprietary systems, like Skype) for UWB and FB, we can compare Opus with industry leaders, such as G.719. > > One can argue that we should also compare Opus with patent free codecs, which adds iLBC and Speex to the list, but I personally see this as less of a requirement. iLBC never managed to get market traction outside of the open source world, Sort of curios how you came to that conclusion about iLBC's market traction? <ATT00001..txt>
- [codec] comparitive quality testing Gregory Maxwell
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing David Virette
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Steve Underwood
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Alan Duric
- Re: [codec] comparitive quality testing Anisse Taleb
- Re: [codec] comparitive quality testing Monty Montgomery
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Stephan Wenger
- Re: [codec] comparitive quality testing Steve Underwood
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Alan Duric
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Roman Shpount
- [codec] iLBC deployment statistics (Re: compariti… Harald Alvestrand
- [codec] Deployment of iLBC Re: comparitive qualit… Cullen Jennings
- Re: [codec] comparitive quality testing: vote to … Jean-Francois Mule
- Re: [codec] comparitive quality testing: vote to … Roman Shpount