GNOME Bugzilla – Bug 596006
h264 cannot be initialised with recent libx264
Last modified: 2011-09-07 16:14:23 UTC
Although opal-3.6.4 and ekiga-3.2.5 can be compiled using recent libx264 (x264-snapshot-20090921-2245), the codec cannot be initialized by ekiga due to an API change. Error message: h264pipe_unix.cxx(301) H264 IPC PP: Found GPL process executable in /usr/lib/opal-3.6.4/codecs/video/h264_video_pwplugin_helper x264loader_unix.cxx(114) H264 DYNA Trying to open x264 library libx264.so.75 x264loader_unix.cxx(131) H264 DYNA Successfully loaded libx264.so.75 x264loader_unix.cxx(57) H264 DYNA Failed to load x264_encoder_open h264helper_unix.cxx(h264pipe_unix.cxx(113) H264 IPC PP: GPL Process returned failure on initialization - plugin disabled
Hi, On our mailing list, someone reported: ".so version 67 (svn 20090627) seems to work."
Created attachment 147381 [details] [review] Fix API breakage with x264 >= 20090923 I've made a crude patch to compile opal-3.6.6 with libx264 > 0.76 It build but tested
Thanks, Luc. Should we commit it or not?
Hi Luc! Welcome back :) Well, I plan to work on packaging our trunk soon for Ubuntu (maybe this week-end), I'll give it a try. IMHO we should test it first ;) Best regards, Yannick
Please see bug 603436 for some additional and related information. Is there a version yet with the fix for this issue?
Luc, should we commit this patch or not? Will it work with versions of ffmpeg older tha 0.76 (20090923)?
The problem with loading x264_encoder_open is that the actual symbol is now x264_encoder_open_##version where ##version is the X264_BUILD (e.g. x264_encoder_open_83 for x264 build 83). There are a bunch of #define macros to substitute x264_encoder_open_##version. Anyways you would need to change: opal/plugins/video/H.264/gpl/x264loader_unix.cxx to try and look up x264_encoder_open_##version using dlsym instead of just x264_encoder_open Best regards, Bijan
I saw that too. http://git.videolan.org/?p=x264.git;a=blob;f=x264.h;h=1223df78961d4e833b91a3fe62772c513d5e2a28;hb=HEAD#l468 gives more information. The problem is that after changing this (and using the patch in comment #2), during a call the video freezes at the first image and when closing the call ekiga crashes. I conclude that the API has indeed changed and someone with more H264 API knowledge is needed. By the way, the patch in comment #2 is mandatory and seems good to me, as shown at http://mailman.videolan.org/pipermail/x264-devel/2009-September/006337.html
Hmm that is odd, I fixed this and applied the patch and made a SIP call using made a successful call using H.264. This was using: ekiga-3.2.5 opal-3.6.4 ptlib-2.6.4 x264 git (BUILD 83) ffmpeg git (major 52, minor 47) However I still can't get it to work with H.323. I can check if I have made any other modifications to opal.
I have just tested with ekiga 3.2.6 and, with the patch and with _83, it works inside gdb, but not when executed normally. Very strange... Could you test it several times and tell if it works reliably?
Guys, so what is the status here. Is it safe to use patch attached here?
For me even with the patch it still does not work. Please help if you can.
Created attachment 166519 [details] [review] patch for the symbol lookup issue in opal lib Patch that implements what comment #7 is talking about. Note that every time the x264 library is changed you must recompile opal so that it loads correct version of x264. This kind of sucks because libraries are supposed to be somewhat API-compatible.
Does x264 work for you with these patches?
Well I just tried it a couple of times. The codec shows up the connection is established but the picture transmitted by the patched ekiga for Linux is very bad quality - very blocky (even the moving logo) so there must still be some problem with the way the new x264 is used. (I compared it with the ekiga for Windows where x264 still works flawlessly - transmits crispy image.) Maybe you could take a look on how the x264 encoder or ffmpeg handled the API change and try to reuse it?
I will try to do it sometimes soon (I am working on regressions right now), but if you can help your help would be really appreciated.
I can confirm that this bug is still here making usage of H.264 hard on a modern system with recent version of x264 installed. I was forced to download sources for so-called ".so version 67 (svn 20090627)" version of x264, compile it and create packages for my system and then recompile opal against this version of x264 in order to get H.264 working reasonably well.
Review of attachment 166519 [details] [review]: The fix here is somewhat unreliable since it relies on intimate knowledge of how X264 munges the x264_encoder_open symbol name. I have an alternate version of this patch that is less error-prone.
Created attachment 178005 [details] [review] better patch for the x264 symbol lookup issue
Howard, does h264 works on your machine with your patch and the first one in this bug?
OK, I disabled the other codecs so I was able to test this against 500@ekiga.net. I got nothing without the first patch. With the first patch applied, there is some video but it's extremely blurry / blocky / low quality, and the V bitrate indicator stays around the 0.5 range. As an aside, the H.263 codec seems to work fine though.
As it had been already reported here, problems with interoperability of the Ekiga with recent versions of x264 are not only in the simple change of the x264_encoder_open function name. Looks like that something had actually changed in the x264 API and it is required to change something in the OPAL to be compatible with the new x264 API. Unfortunately I don't know enough to tell what is the difference so my solution was to stick with an older version of x264 library (so-called ".so version 67 (svn 20090627)") which gives perfect quality of the video picture encoded with H.264 codec and don't require any patch to be applied to the OPAL sources to work correctly.
The second/third patch is now committed in trunk and stable branch. Hence, H264 compiles now.
Created attachment 180038 [details] [review] Patch to fix H.264 blocking problem and delay I have two specific problems with the H.264 codec. One is the blocking problem mentioned in comment 22 and the other is a huge delay (around ten seconds) between the video and the audio. The blocking problem is fixed by using the correct values for 1_qp_max. Apparently some time after .67 the API was altered to have a fixed maxiumum value instead of a variable one. I fixed the delay empirically by closing down the lookahead and setting the NAL hrd to CBR ... it's possible there's a better way to do this but given the minute amount of documentation for x264, it's about the best I could come up with. These have been tested on openSUSE 11.3 with libx264-112
"it's possible there's a better way to do this but given the minute amount of documentation for x264, it's about the best I could come up with." You probably already know this but I will mention it anyway. To decrease latency as much as possible, one should use a matching configuration to the zerolatency tune in x264 cli: - zerolatency: --bframes 0 --force-cfr --no-mbtree --sync-lookahead 0 --sliced-threads --rc-lookahead 0 Other details like using intra-refresh are mentioned here: http://x264dev.multimedia.cx/archives/249
As of revision 26277 (http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=revision&revision=26277), H264 (using current build, libx264-116) is back again, kudos to Robert J.!
*** Bug 646466 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > "it's possible there's a better way to do this but given the minute amount of > documentation for x264, it's about the best I could come up with." > > You probably already know this but I will mention it anyway. > > To decrease latency as much as possible, one should use a matching > configuration to the zerolatency tune in x264 cli: > > > - zerolatency: > --bframes 0 --force-cfr --no-mbtree > --sync-lookahead 0 --sliced-threads > --rc-lookahead 0 > > Other details like using intra-refresh are mentioned here: > http://x264dev.multimedia.cx/archives/249 Nezmer, is your information above still useful with ekiga 3.3.2, where h264 works? If yes, I will put it on the wiki.