Re: [codec] comparitive quality testing

Roman Shpount <> Wed, 20 April 2011 01:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2CCAE081D for <>; Tue, 19 Apr 2011 18:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id avkkz8QBIdkd for <>; Tue, 19 Apr 2011 18:30:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46C87E0720 for <>; Tue, 19 Apr 2011 18:30:01 -0700 (PDT)
Received: by eye13 with SMTP id 13so89471eye.31 for <>; Tue, 19 Apr 2011 18:30:00 -0700 (PDT)
Received: by with SMTP id y49mr2343160eeb.22.1303263000542; Tue, 19 Apr 2011 18:30:00 -0700 (PDT)
Received: from ( []) by with ESMTPS id k51sm296477eei.24.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 18:29:59 -0700 (PDT)
Received: by eye13 with SMTP id 13so89469eye.31 for <>; Tue, 19 Apr 2011 18:29:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id g1mr56172eba.93.1303262999090; Tue, 19 Apr 2011 18:29:59 -0700 (PDT)
Received: by with HTTP; Tue, 19 Apr 2011 18:29:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 19 Apr 2011 21:29:59 -0400
Message-ID: <>
From: Roman Shpount <>
To: Steve Underwood <>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [codec] comparitive quality testing
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, 20 Apr 2011 01:30:02 -0000


I've seen your version of this and other codec. Great work!

I have actually done the optimization of iLBC for Intel platform and
can testify that you can get about 10x performance boost. I guess the
ironic part is that I actually support couple of sizable projects that
use iLBC. This being said, I would love to have something better
quality, less CPU intensive to replace iLBC.

As far as patents are concerned, I guess we are not suppose to discuss
them here, but I have some concerns about iLBC that I would be happy
to discuss offline.
Roman Shpount

On Tue, Apr 19, 2011 at 9:12 PM, Steve Underwood <> wrote:
> On 04/20/2011 07:08 AM, Roman Shpount wrote:
>> [...]
>> Where iLBC seemed to thrive is in soft-phones and various types of desktop
>> based software VoIP products. In such products the benefits of not having a
>> per instance license are probably the greatest. iLBC is also universally
>> supported by open source projects such as Asterisk, Freeswitch, PJ-SIP,
>> OpenH323 descendents, and so on. iLBC is also present in Android and iOS.
>> What is interesting about all of those products (and I did check pretty much
>> all the open source projects I can find) that the iLBC implementation in
>> these products are essentially the reference code from the RFC. This code is
>> extremely inefficient. What I mean by this it consumes more then 10 times
>> the CPU resources of Voiceage or IPP optimized G.729A. With Freeswitch or
>> Asterisk you cannot get more the 50-100 channels of iLBC per modern dual CPU
>> server. On the other hand running over 500 channels of G.729A is fairly
>> normal. What was interesting for me that no one spent any time optimizing
>> any of the open source versions of the codec even though this is fairly
>> trivial. On the other hand, such high CPU requirements on server and mobile
>> platforms make iLBC almost unusable. If anyone on this list knows the open
>> source optimized or fixed point implementation, please point it out to me.
> As someone who adapted the iLBC reference code into a packaged library that
> it easy to use, I can comment on this. I produced a library with a nice
> clean API, consistent with other codecs I have implemented, as a first step.
> This went into projects like FreeSwitch, and I waited for the demand for a
> faster version for servers, and a fixed point version for embedded users.
> The call has yet to come. I have no idea how much faster you can make iLBC.
> I haven't even been pushed to do that analysis. There are certainly people
> using iLBC with the various open source projects, but its mostly small scale
> users. Most big users either go for G.711 where they have sufficient
> bandwidth, or G.729A where they don't. Because of the points below, I am
> somewhat happy about this.
>> There is also a question of ILBC Freeware license. Based on IETF rules,
>> all the code released as a part of IETF RFC should be covered by BSD
>> license. The reasoning and applicability of iLBC Freeware license in this
>> context is unclear.
> Correct. The copyright situation for the floating point reference code is
> vague. The right to adapt that code to highly optimised floating point,
> fixed point code, or other implementations is vaguer. Nobody appears
> interested in clarifying things. The development of RFC3951 seems quite
> unlike most IETF work.
>> IPR disclosure for iLBC RFC was not updated when RFC was finalized and
>> only has provisional patent applications, not the final granted patent
>> numbers.
> Correct. We have little idea which GIPS patents might apply, and nobody ever
> seems to have seriously considered who else might have relevant patents.
> iLBC isn't a great codec, but it didn't have to be. Pretty good and
> unencumbered is clearly a winning combination these days - look at how much
> wideband VoIP is G.722 vs anything more modern, more advanced, and more
> encumbered. With a clear legal position it might have been a winner, but
> today its an also ran.
> Steve
> _______________________________________________
> codec mailing list