krunal09 / sample

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

iLBC Codec #42

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Although G729 is more common, it's unlikely to practical in a free product due 
to its licensing 
constraints.  

iLBC offers better packet loss concealment and is widely supported.  Although 
royalty free, I hear 
that the only available integer code is sold under licence - (I hope I heard 
wrong).  The freely 
distributed code is therefore floating point only, which is not ideal for 
phones.  (Maybe Nexus and 
Droid are fast enough anyway?)

Thoughts?

Original issue reported on code.google.com by kro...@gmail.com on 29 May 2010 at 9:10

GoogleCodeExporter commented 9 years ago
For iLBC it was integrated in the first versions of CSipSimple (I use pjsip :
http://www.pjsip.org/ as native sip stack which i ported to android).

But after a lot of searches, I conclude that ilbc is not well designed for 
mobile
phone, so I removed it from my builds to make the lib size less important.

What i planned for this point is to provide multiple sources for the native 
library
that will enable me (or other providers) to distribute differents versions of 
the
native library (with or without codecs).

So for now, iLBC is postponed, but when this mechanism will be implemented i'll
provide libs with more codecs implemented.
If you want a build with ilbc activated, I can provide it to you (I've just one 
line
to uncomment in the toolchain and click on build ;) ).

For the issue with G729 that is absolutely not clear for me. 
I know that there is licensed implementation (the one already included in pjsip 
-the
IPP intel one- is under license i think), but there is also opensource
implementations (one has been done by the developer of Siphon - pjsip ported on
iphone). I'll ask him how he solve this codec license issue for siphon and g729.

If necessary for G729 i'll provide an different update source with the lib 
compiled
with g729 and users will have to pay the license fee (either by their own means 
or
-in the worst case- i can imagine to retail license if it's more practical for 
users)

Original comment by r3gis...@gmail.com on 29 May 2010 at 10:04

GoogleCodeExporter commented 9 years ago
Either ilbc or g729 would provide a serious point of difference over other 
solutions. 

Original comment by kro...@gmail.com on 1 Jun 2010 at 11:04

GoogleCodeExporter commented 9 years ago
Since this has been added to the latest release.  Should this be marked as 
solved?

Original comment by kro...@gmail.com on 5 Jul 2010 at 10:01

GoogleCodeExporter commented 9 years ago
Yes now, it's pushed on the android market.

I mark issues as fixed only when on the market in order to avoid duplicates.

Original comment by r3gis...@gmail.com on 10 Jul 2010 at 2:37

GoogleCodeExporter commented 9 years ago
I can't get ilbc to work.  Phone keeps choosing GSM even though ilbc is at top 
of codec list.  (Presuming the info saying GSM is correct.)  Provider (2talk) 
lists iLBC as "MUST be 30ms/13.33kbps variant".  Is that what csip uses?

Thanks.

Original comment by kro...@gmail.com on 18 Jul 2010 at 12:00

GoogleCodeExporter commented 9 years ago
According to the pjsip documentation, 30ms variant is supported.
Are you sure your remote contact support and has ilbc set as the preferred 
codec?
Even if both endpoint support ilbc, sdp negociation can lead to the choose of 
GSM codec if it is prefered by your remote contact.

What I should implement to allow you to really force the use of ilbc is the 
option to disable a codec.

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 1:13

GoogleCodeExporter commented 9 years ago
Hi, using the latest csip release, I disabled all codecs but iLBC, but still in 
the stats it says I'm connecting using GSM.  Not sure if that's possible...?

Original comment by kro...@gmail.com on 19 Jul 2010 at 2:24

GoogleCodeExporter commented 9 years ago
Disabled all other codecs at provider end.  iLBC then worked, so thats a win.  
But it means that the codec preferred order/disable doesn't work?

Cheers.

Original comment by kro...@gmail.com on 19 Jul 2010 at 6:55

GoogleCodeExporter commented 9 years ago
Ok, there is probably a mistake on my side. 
I didn't really tested the feature yet. So I'll do it and find where is the 
problem.

About ilbc, is the sound quality / latency good?

Original comment by r3gis...@gmail.com on 19 Jul 2010 at 7:11

GoogleCodeExporter commented 9 years ago
Whenever, using iLBC, the sound coming through is all garblely.  r618.  Other 
end hears me fine.  It's not a recent regression, I've been using GSM and then 
729 instead.  But I thought I would follow this up.

Original comment by kro...@gmail.com on 14 Feb 2011 at 7:35