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>