Re: [codec] comparitive quality testing

[Roman Shpount <[e-mail]>]

Steve,

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>