Re: [codec] comparitive quality testing

[Steve Underwood <[e-mail]>]

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