I have media-libs/x264-0.0.20080819 installed. # USE=x264 emerge mplayer [...] x86_64-pc-linux-gnu-gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -I/usr/include/dirac -I/usr/include/schroedinger-1.0 -I/usr/include/liboil-0.3 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -c -o libx264.o libx264.c libx264.c: In function 'X264_init': libx264.c:165: error: 'x264_param_t' has no member named 'i_bframe_adaptive' make[1]: *** [libx264.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/mplayer-1.0_rc2_p27725/work/mplayer-1.0_rc2_p27725/libavcodec' make: *** [libavcodec/libavcodec.a] Error 2 * * ERROR: media-video/mplayer-1.0_rc2_p27725 failed. Previously, mplayer-1.0_rc2_p27458 had compiled correctly.
Created attachment 167513 [details] mplayer-libx264.patch Simple patch that fixes the problem
Tom, thanks for the patch Assigning to maintainers
This needs some #if X264_VERSION < $number checks; or a new x264 snapshot which I'm planning to add soon but that will break other packages, so better patch it to allow both old and new x264.
This could help to get the code right: http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=65c64485d415dd90c18cae8e8ed9e09227bdefca note that i_bframe_adaptive is an int and b_bframe_adaptive is a bool.
Created attachment 167515 [details, diff] better patch On September 15, x264 devs renamed b_bframe_adaptive to i_bframe_adaptive; mplayer devs made the corresponding change to libx264.c. Unfortunately, the latest version of x264 in portage is 20080819. Attaching a patch that does the right thing for both current and 20080819 versions of x264, to make sure that mplayer will still compile when new versions of x264 hit the tree.
Thanks. This one should be good to go. I'm adding a new masked x264 snapshot right now to ease migration/testing. Steve, please include it ;) ( by the way, have you read my mail to media-video@ ? :p )
*** Bug 240353 has been marked as a duplicate of this bug. ***
Created attachment 167526 [details] modified ebuild including mplayer-1.0_rc2_p27725-libx264.patch modified ebuild including mplayer-1.0_rc2_p27725-libx264.patch thans for the patch!
(In reply to comment #6) > Thanks. This one should be good to go. I'm adding a new masked x264 snapshot > right now to ease migration/testing. > > Steve, please include it ;) ( by the way, have you read my mail to media-video@ > ? :p ) > Yah, sorry, I had an older version of x264 that I was testing against, and didn't realize til now. Thanks for the patch, added in -r1.
*** Bug 240396 has been marked as a duplicate of this bug. ***
*** Bug 240404 has been marked as a duplicate of this bug. ***
That is not the only thing changed since Gentoo's old version of x264 was checked out; bidir_refine and b_rdo were also removed from the file, as x264 no longer supports those options. If you want to try to patch things rather than just doing the obvious and updating x264 to a newer, more stable version, you're going to have to cover all recent changes.
(In reply to comment #12) > That is not the only thing changed since Gentoo's old version of x264 was > checked out; bidir_refine and b_rdo were also removed from the file, as x264 no > longer supports those options. Thank you for pointing this out. I should have been more careful in checking the ffmpeg svn history. > updating x264 to a newer, more stable version, It looks like x264 changes its public API and soname *several times a month*. IMHO, calling some version of x264 "stable" is a funny joke.
Created attachment 168706 [details, diff] improved patch Updated the patch. Fixes the error pointed out by darkshikari.
"Stable" has nothing to do with API, it has everything to do with fixed bugs. If I fix a bug, x264 is now more stable. If you refuse to update to the new, more stable version, you're using an older, unstable version, simple logic. Also, the x264 API has only changed a couple times in the past year, almost all of which fell within the same one or two months of changes.
*** Bug 246535 has been marked as a duplicate of this bug. ***
It seems to me that we should get more recent x264 in stable and force it in the ebuild.. aballier?
+*mplayer-1.0_rc2_p20090731-r1 (04 Aug 2009) + + 04 Aug 2009; Samuli Suominen <ssuominen@gentoo.org> + +mplayer-1.0_rc2_p20090731-r1.ebuild, metadata.xml: + Raise x264 depend wrt #240347. Fix automagic opencore-amr depend wrt + #279995.
