Ekiga's non free codec support isn't available in multiverse

Codec plugins that can't land in multiverse for legal reasons could probably find their way into the Medibuntu repository. So first it should be clear what can go to mutliverse and what not. Then there should be some decisions on packaging, like how to split those codecs and what names, versions and so forth they should get.

This way we could seperate the medibuntu part and do a packing request on https://bugs.launchpad.net/medibuntu very early, so changes are higher for people to easily get all those codecs plugins by the release of Jaunty.

For a package name we could go for libopal3.4.2-plugins-non-free like in http://snapshots.ekiga.net/snapshots/debian/ as this would perfectly match the current naming of opal in jaunty.

For a starting point we could take http://snapshots.ekiga.net/snapshots/debian/opal-non-free_3.4.2~1.dsc and decide what plugins can't go to multiverse and what should be handled by Medibuntu.

The codecs in this source package are iLBC, h264, h263-1998, mp4v-es. But after playing around with the package and finally building it, i noticed that beside legal reasons we are currently only able to build iLBC and h264 as the other two needed something like a dev package to libavcodec-unstripped-51, what we don't have in the archives.

For naming convention we could splitt atleast the binaries in something like:
libopal3.4.2-plugins-h263-1998
libopal3.4.2-plugins-h264
libopal3.4.2-plugins-ilbc
libopal3.4.2-plugins-mp4v-es

This is a bit like what Yannick did in his PPA https://launchpad.net/~sevmek/+archive regarding the opal packages.
In case more than libopal3.4.2-plugins-h264 would go to multiverse a simple meta package like libopal3.4.2-plugins-non-free or libopal3.4.2-plugins-multiverse would be great.

OPAL has been approved to version 3.6.1 and still lacks those video codecs.

OPAL 3.6.1 add support for H263 (and still for H263-1968).

The video codecs H263, H263-1998, MP4V-ES are probably in libavcodec-unstripped-52

The video codec H264 is in libx264-65, and also need libavcodec-unstripped-52

The audio codec iLBC is also non-free, still is important for interoperability.

As said before those OPAL plugins can be split in several packages. Ekiga wil find them at run time.

This is what I did in my PPA as noticed in the comment just above.

I wonder if this would include codecs as the ones at http://www.ippcodecs.org/ (g.729 one of them)?

alright i did a package a first package in my ppa. as i think h264 has the highest chances for multiverse i started with a separate source package only for h264, it's called opal-h264. but i should be rather easy to reuse it for source packages of the other plugins as they maybe won't go to a single repo.

for the packaging i basically grabbed the orginal opal tarball and the patches from the opal ubuntu package (even if we don't need them right now for the plugins, but who knows when we will). this way it should be easy to stay in sync with opal from main. regarding the rules files i did a new one from scratch with debhelper to keep it simple and to compile only the stuff we really need. for reusing it for ilbc&co we probably only need to change 3 lines in it (i've commented them accordingly).

so far everything seems alright, as ekiga recognizes the new codec after installing the binary, which i named like discussed (libopal3.6.1-plugins-h264). but i haven't tested it with a call, so this still needs some willing testers ;)

any feedback is highly welcome :) so just grad the source and the binaries at:
https://launchpad.net/~bojo42/+archive/ppa/+sourcepub/538705/+listing-archive-extra

@Andres: they are at least very interesting, but i don't know how good the actually are and if they will work on amd too. maybe Yannick has some insight here.

Hello,

I think there is no need to use the source from upstream, the source of OPAL in jaunty contains and build the videos codecs we need but erase them in the "rules" file (in debian repository) line 142:
        #remove non-free video codecs (if any)
 -rm debian/install/usr/lib/opal-*/codecs/video/h264*
 -rm debian/install/usr/lib/opal-*/codecs/video/h263-1998*
 -rm debian/install/usr/lib/opal-*/codecs/video/mpeg4*

The source of OPAL in Jaunty lack the audio codec iLBC, same file as above line 241:
 @@rm -rf ../tarballs/opal-$(UPVERSION).tmp/opal*/plugins/audio/iLBC
Thus the ILBC directory has to be patched using the upstream source.

I guess if we add the necessary dependancies during compilation of OPAL we will have all the codecs, then we could move them is several packages e.g. for H264 (line 142):
 #h264
 mkdir -p debian/$(PACKAGE)-plugins-h264/usr/lib/opal-3.6.1/codecs/video/
 -mv debian/install/usr/lib/opal-*/codecs/video/h264* debian/$(PACKAGE)-plugins-h264/usr/lib/opal-3.6.1/codecs/video/

The control file needs to change too, with things like:
debhelper, libpt2.6.1-dev, dpatch, doxygen, autotools-dev, pkg-config, libtheora-dev, libgsm1-dev, libspeex-dev, libspeexdsp-dev, libavcodec-unstripped-52-dev, libx264-65-dev

and new sections like e.g. for H264:

Package: libopal3.6.1-plugins-h264
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, libopal3.6.1, libavcodec-unstripped-52, libx264-65
Description: H.264 video codec for Open Phone Abstraction Library - successor of OpenH323
 The OPAL project aims to create a full featured, interoperable, Open Source
 implementation of the H.323 and SIP protocols that can be used freely by
 everybody. These protocols are most used for Voice over IP (VoIP)
 conferencing.
 .
 This package contains OPAL support for the h264 video codec.
Homepage: http://www.opalvoip.org/

Well, I've no time to do this work unfortunately, in hope that helps.

Best regards,
Yannick

@Yannick: instead of the upstream we could use the one from the jaunty package if they differ. but AFAIK do we need a own source package for multiverse, but i could be wrong. and as the place of x264 is multiverse, at least the h264 plugin should go there too.

regarding the rest: of course can we use the jaunty opal source package and modify it, but i thought when we need a additional source package anyway, why to compile the whole opal stuff when we only need some plugins.

bojo42 a écrit :
> @Yannick: instead of the upstream we could use the one from the jaunty
> package if they differ. but AFAIK do we need a own source package for
> multiverse, but i could be wrong. and as the place of x264 is
> multiverse, at least the h264 plugin should go there too.
>

I think you're right, but I'n not sure either.

> regarding the rest: of course can we use the jaunty opal source package
> and modify it, but i thought when we need a additional source package
> anyway, why to compile the whole opal stuff when we only need some
> plugins.
>

indeed. I'm not an expert at packaging and I lack time to dig this
matter now. And to tell you all, this was my first idea too, still I do
not know how to do it... I'm not a coder. So go on if you can do the
same for the other plugins.

Thank you!

i just used the new multiple ppa feature of LP :) that rocks! so i created an extra PPA for ekiga and reuploaded the h264 package. this time i used the jaunty opal source tarball, so that even the md5sums match. i also changed the description in debian/control to the one you posted here, looks better now. in the next days i will convert the current package for ilbc and upload it also to the new ppa. so anyone with some time please test the stuff under:
https://launchpad.net/~bojo42/+archive/ekiga

best regards
bojo42

i uploaded the ilbc package, so please give it a test. this time i used the upstream source tarball as ilbc is stripped in jaunty's opal.

Sorry if I misunderstand; Was it decided that the h263s are included in libavcodec-unstripped-52 and therefore don't need libopal packages like Yannick made for h264?

After installing libavcodec Ekiga doesn't show h263, so it seems like the libopal package might be needed.

bojo42's fix worked! I just downloaded the keyring from https://launchpad.net/~bojo42/+archive/ekiga, enabled the repository in Software Sources, installed the libopal3.6.1-plugins-h264 and libopal3.6.1-plugins-ilbc packages in Synapic, and now Ekiga recognizes the h264 and iLBC codecs in Preferences! (See attached screenshots.)

@bojo42, could you run a build for h263?

It's needed for communicating with some installations of the telepathy clients such as the Nokia N800.

Clarification: I haven't tried these codecs with a test call. This is only confirmation that Ekiga recognizes them on my system.

@bojo42: Nice work on this! Would you please upload similar packages for h263 and/or h263-1998? I really need one of those codecs, and I can test it for you, too.

@evan&chris: i am willing to do the packages for the other codecs, but as i wrote in https://bugs.launchpad.net/ubuntu/+source/opal/+bug/316971/comments/3 the current situation due to #312898 is a bit problematic. meaning that AFAIK i first have to do and host ffmpeg unstripped development packages in the ppa or i have to learn how compile against the unstripped packages in a debian way.

so if you like to help me (as i am also rather busy in the next three weeks) you can check out, if we really need the ffmpeg unstripped stuff or what possible other solution leads to compiling those codecs. after solving this issue the packaging is easy and shouldn't cost much time, but for the moment i won't do the "ffmpeg unstripped dev packages" way since bug #312898 gains some momentum right now and this could mean duplicated work.

best regards
bojo42

@bojo42: Sounds good. I studied the Bug #312898 thread for awhile and tried a bit of tinkering (see my post there), but I have a question for you: if libavcodec-dev were installed together with libavcodec-unstripped-52, would this theoretically make the missing codecs available, or would we still need a plug-in like you did for h264 and iLBC, or is libavcodec-dev not even going to help?

@chris&evan: thank you both for helping me to understand the problem in more detail on #312898 :) as i wrote over there i successfully build the missing codecs with dpkg -i --force-depends, but the problem still persists. as i am not sure if i can do such nasty stuff in the PPA, but i will try ;)

@bojo42: My pleasure. : ) Would you mind posting the h263 and/or h263-1998 plugins, even though the dependencies issue persists? I need one of them kind of urgently, and so would be willing to use --force-depends to make it work until there's a cleaner fix. Also, would you please do a newb a favor and show me the correct syntax? I know there's something wrong with this: "sudo dpkg --force-depends -i libavcodec-dev". Thanks!

@evan: you were very close the syntax is sudo dpkg -i --force-depends libavcodec-dev* libavformat-dev* libavutil-dev* assuming you have all the packages in your current directory. regarding the building with the PPA i had no success, so anyone who knows a way to integrate something like "dpkg -i --force-depends" in the debian packaging please step up.

in the mean time i can give you the .debs i did here on my machines, but as i haven't set up pbuilder i just have i386 binaries. please give also a real testing. :)

@bojo42: Thanks for your help. I have something unexpected to report: after downloading and installing the first of your attachments (libopal3.6.1-plugins-h263-1998_3.6.1-0ubuntu1~ppa1_i386.deb), the missing codecs h263 and h263-1998 have already appeared in Ekiga with no additional work. That is, I did not use "sudo dpkg --force-depends...", and I do not have any of the -dev packages installed for libavcodec, libavformat and libavutil.

Perhaps I misunderstood, but I thought we had decided those -dev packages would be necessary for the detection of the missing codecs, even with your plugins package installed. Can you comment on this?

I will test the new codecs' functionality in a call later today.

I haven't followed the latest developments closely so I could be wrong, but, the -dev packages should never be required to run. They are only required to build the debs in the first place.

The issue with forcing is about setting up the system to be able to build the debs conveniently. Since you're not building debs but only installing the normal, pre built ones, you don't need to worry about it.

@Chris: completely correct.

I can confirm that h263 is working great between ekiga and a Nokia N800.

@bojo42&Chris: Thanks for helping me understand. I can confirm that both the h263 and h263-1998 codecs are working well between my Ekiga and an X-Lite on Vista.

Does this mean we can change the bug status?

Not yet, Evan. We have a proposed fix here and packages in a ppa, but it's up to a maintainer of some sort (in multiverse, I suppose) to actually work through the process of adding the package to the repository and thereby closing this bug.

What about CELT? I used CELT in an earlier Ekiga version from a PPA with FreeSWITCH and it worked fine. It would be great if you could create packages for the CELT codec too.

@Mikael Bjerkeland,

I opened a specific bug report for this one here:
https://bugs.launchpad.net/ubuntu/+source/opal/+bug/351590

bojo42: Thanks for all your work on this. Any chance of getting a 64 bit version of the h263 package?

@mrguitar: yes there is a chance and your timing is quite good, as i just uploaded the h263-1998 and the mp4v-es source packages to the PPA ;)

@all: many thanks go to Reinhard Tartler for helping me to understand the situation around bug #312898 better. so as said the packages are uploaded, but it will take Soyuz a few hours for finishing the build process (atleast for i386). it would be great if some of you could grab the packages at https://launchpad.net/~bojo42/+archive/ekiga once built and give the three codecs a real connection testing.

best regards
bojo42

update: the packages are already built and ready for testing ;)

Would there be any problem in making this work on Hardy?

@otakuj462: i could backports of the ekiga stuff, but for the h263, h263-1998 and mp4v-es plugins this is problematic, cause AFAIK we don't have "unstripped" packages of ffmpeg in hardy and i don't want to depend on Medibuntu for the PPA (as i want to stick to official Ubuntu dependencies, because this packages should finally get also official :)

but i think h264 and ilbc should be able to do for hardy. i could do those two plugins and the backports of the latest ptlib, opal & ekiga on the weekend as i need to take care of the intrepid packages anyway. would that help you?

@bojo42,

Hardy have necessary codecs in the ffmpeg package, it was splitted for intrepid, see this bug report:
https://bugs.launchpad.net/debian/+source/ffmpeg-debian/+bug/254201

As you can see in my PPA, I was able to built those plugins in opal-3.4 - 20081001v01hardy6:
    * libopal-3.4-plugins-h263-1998 Open Phone Abstraction Library - successor of OpenH323
    * libopal-3.4-plugins-h264 Open Phone Abstraction Library - successor of OpenH323
    * libopal-3.4-plugins-ilbc Open Phone Abstraction Library - successor of OpenH323
    * libopal-3.4-plugins-mpeg4 Open Phone Abstraction Library - successor of OpenH323

My PPA:
https://launchpad.net/~sevmek/+archive/ppa

Best regards,
Yannick

@Yannick: Thank you for that hint, so if my time permits we will see the plugins + backports on hardy after the weekend :)

@bojo42: The iLBC codec and the latest ekiga and deps are what I would like to install. The other codecs I'm not concerned about. If you could backport this to Hardy, that would be great!

Thanks,

Jake

@okakuj462: i have bad news for you, i won't do backports for hardy. sorry for that.

@all: i also stopped providing backports for intrepid with the ppa. my reasons for this decision are that i like to avoid the work of maintaining these backports and i like to concentrate my time on the plugins and this bug. therefore i cleaned the PPA from all backports and just left the plugin packages for jaunty. beside that i uploaded packages for karmic, so that we maybe can close this bug in the new development cycle. and when we will see a new release of ekiga & opal entering karmic i will update those packages if necessary. i'm also willing to provide the plugins for intrepid and hardy in case we will see an official backport of ptlib, opal & ekiga from jaunty/karmic, but i doubt this will happen.

bojo42: sorry I've been terrible about testing the codecs. I don't have a great testing environ setup. The only thing I can use Ekiga w/ is X-lite on my wife's Mac via my FreeSwitch server. Using the h263 I can see video from her cam but she can't see mine. At one point I got it to work briefly but it looked terrible (I'm sure I'm doing something wrong), and I haven't been able to make it work again. Anyway thanks for all your work on this. i think a better test would be between 2x Ubuntu PCs, but I don't have the resources right now. .....unless you want to make me some Fedora RPMs. :) (can I say those words here?)

:)

thanks,

Ekiga video using the two free codecs wasn't terribly impressive. I tried these codecs between two Ubuntu Jaunty laptops and none worked too well. H264 had terrible artifacts where the picture would update only partially each frame so my face turned into a big weird looking mess. H264-1998 seemed to crash the receiving end, while h263 didn't work well (it would either not display anything or show a static image with green lines through it). M4v worked okay, but not noticeably better than h261. I did these tests over a LAN with one side wired and one wireless, with max upload set to 512kbps and the slider towards picture quality rather than framerate. I was hoping for h264 to blow me away and work as well as Skype does, but I haven't been able to get good results...

Kevin, do you believe that to be a bug in these particular builds, or are you just griping in general? :)

Personally, I've had really good results using H263-1998 between Jaunty Ekiga and a Nokia N800 internet tablet going over wired and wifi, just like you. The N800 was using telepathy's empathy, though, and not Ekiga.

In any case, if you don't think it's a problem with these specific builds (and I doubt it is), maybe you should open a new bug to try to figure out what combinations of senders and receivers cause the problems. I'll pitch in there if you do.

I'm not sure where the problem lies - I just know that they happen specifically when using these non free codecs, and I was trying to give feedback because I didn't know how well they had actually been tested point to point, just that they show up on the list of available codecs. I didn't think that h264 should be so pixelated/unwatchable and didn't know if I was doing something wrong or if it was a bug in the package. Maybe the h263-1998 problem happened because it's Ekiga to Ekiga?

I'd be happy to help test and can provide some debugging output (is the best way ekiga -d 4?) and even file a bug but I didn't know where it was appropriate to post my experiences with these codecs. I'd like to get away from programs with proprietary protocols but just haven't seen the results I expected and wanted to figure out why - sorry if it sounds like griping, but help me focus it into something productive :)

Hi folks!

Additional information:

At the moment, OPAL do not support TCP connections for SIP. As a consequence of this, if you're using many codecs, it might happen (and I've saw several cases) OPAL is not able to built a UDP packet within all those codecs because the UDP size packet is fixed by your provider and it will be too small. The standard SIP solution for this issue is to autoswitch to TCP for the SIP negociation.

As you can see here:
http://www.opalvoip.org/wiki/index.php?n=Main.CurrentToDoList
upstream is aware of this issue and plan to fix it as a "Must do".

Until this is fixed upstream, I do not think it is a good idea to ship OPAL package including the whole codec bunch as Ekiga might silently fail.

To see if you're facing this issue you must run ekiga in debug mode ("ekiga -d 4") and check the output for "PDU is too large". Then you can workaround this by disabling some codecs in your Ekiga's preferences until the PDU is small enough for your particular configuration (which is ISP dependant). This is way too much for most Ubuntu users.

Best regards,
Yannick

Hi,

Regarding the fact Ekiga silently fails, a bug has been opened in OPAL BTS asking for OPAL to give relevant informations to allow Ekiga notice the user and help him to workaround here:
http://sourceforge.net/tracker/?func=detail&aid=2795756&group_id=204472&atid=989748

@Yannick: thanks for those informations. but i like to ask you a favor: can you take a look at this buildlog i got when trying to compile the h264 plugin on karmic. see https://launchpad.net/~bojo42/+archive/ekiga/+build/1030836/+files/buildlog_ubuntu-karmic-i386.opal-h264_3.6.1-0ubuntu1~ppa1~karmic1_FAILEDTOBUILD.txt.gz . i'm getting compile errors and wonder if karmic renewed toolchain (gcc,libc ...) is the reason for that.

the error is:
g++ -I../../../include -I.. -I../../common -I../../../ -fPIC -Os -g -O2 -c enc-ctx.cxx -o obj/enc-ctx.o
enc-ctx.cxx: In function 'void logCallbackX264(void*, int, const char*, char*)':
enc-ctx.cxx:54: error: 'sprintf' was not declared in this scope
enc-ctx.cxx:55: error: 'vsprintf' was not declared in this scope

thanks in advance
bojo42

Hi bojo42,

Please report a bug upstream. This is too much complex for me to handle that. IMHO it might be the toolchain, or a new ABI in libx264/ffmpeg...

Best regards,
Yannick

Any update on the availibilty of the nonfRee codecs in ubuntu ?

It's funny to see that a windows user can install it right from web. yannick your PPA does not contain this Meta package anymore ? the debian one could be used ?

i updated the packages in the PPA but h264 still won't compile on karmic and it seems the issue Yannick explained still persists according to http://www.opalvoip.org/wiki/index.php?n=Main.CurrentToDoList . i haven't tested the plugins in Ekiga and only did the packaging side of version 3.6.4. so happy testing:

https://launchpad.net/~bojo42/+archive/ekiga

BTW i someone finds a fix for the compile error of h264 (see the buildlog) i am willing to integrate it, but it won't spend time on it myself.

Hi bojo42,

The issue with h264:
https://bugzilla.gnome.org/show_bug.cgi?id=596006

Best regards,
Yannick