FS#16736 - [mplayer] Recent update to mplayer/mencoder doesn't encode x264 anymore

Attached to Project: Arch Linux
Opened by Karthik Periagaram (karthikp) - Monday, 19 October 2009, 07:35 GMT
Last edited by Ionut Biru (wonder) - Monday, 08 February 2010, 00:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No

Details

Description:

The recent update to mplayer (29776) seems to break the x264 encoder. It doesn't encode to x264 anymore, even if the x264 package is installed.

Additional info:
mplayer-29776-1-x86_64

Steps to reproduce:
1) Update to above version of mplayer.
2) mencoder (...) -ovc x264 -x264encopts (...)
3) An error is thrown saying, "-x264encopts is not an MEncoder option"
This task depends upon

Closed by  Ionut Biru (wonder)
Monday, 08 February 2010, 00:22 GMT
Reason for closing:  Fixed
Comment by Benjamin Tayehanpour (konaya) - Tuesday, 20 October 2009, 00:11 GMT
Confirmed. Downgrading to 29411 returns x264 funcionality.
Comment by Hugo Doria (hdoria) - Tuesday, 20 October 2009, 19:15 GMT
This happens on i686 too?
Comment by Karthik Periagaram (karthikp) - Tuesday, 20 October 2009, 19:45 GMT
Confirmed on i686. Same error (-x264encopts is not an MEncoder option) is thrown.
Comment by xduugu (xduugu) - Wednesday, 21 October 2009, 14:56 GMT
There were several so bumps in x264 and newer mplayer checkouts need libx264.so.76.
Comment by YP (knedlyk) - Thursday, 22 October 2009, 20:21 GMT
Confirmed on i686. Proposition: add --enable-x264 to the configure options in PKGBUILD.
Comment by Hugo Doria (hdoria) - Sunday, 25 October 2009, 12:18 GMT
x264 is failing to build on mplayer. Has anyone found a patch?
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 12:42 GMT
Which version of x264 did you use? 20091024 works fine with latest mplayer (29796).
Comment by Hugo Doria (hdoria) - Sunday, 25 October 2009, 13:20 GMT
I have:

x264 20091024
mplayer 29796

The problem:

libavcodec/libavcodec.a(libx264.o): In function `X264_frame':
libx264.c:(.text+0x1d0): undefined reference to `x264_encoder_encode'
libavcodec/libavcodec.a(libx264.o): In function `X264_close':
libx264.c:(.text.unlikely+0x35): undefined reference to `x264_encoder_close'
libavcodec/libavcodec.a(libx264.o): In function `X264_init':
libx264.c:(.text.unlikely+0x5d): undefined reference to `x264_param_default'
libx264.c:(.text.unlikely+0x43d): undefined reference to `x264_encoder_open_78'
libx264.c:(.text.unlikely+0x47e): undefined reference to `x264_encoder_headers'
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1

I tried some other combinations of mplayer/x264 too. I trying to figure out what's the problem. What's your gcc version?
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 13:29 GMT
My gcc version is 4.4.2 (testing). I just setup a chroot without testing enabled and will try to build x264 and mplayer there.
Comment by Hugo Doria (hdoria) - Sunday, 25 October 2009, 13:35 GMT
Please, do so. I am using gcc 4.4.1.
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 14:00 GMT
Builds without a problem (on i686)

$ pacman -Q gcc x264 mplayer
gcc 4.4.1-1
x264 20090416-1
mplayer 29776-1
$ ldd /usr/bin/mplayer | grep x264
$ ldd /usr/bin/mencoder | grep x264

---------------

$ pacman -Q gcc x264 mplayer
gcc 4.4.1-1
x264 20091024-1
mplayer 29796-1
$ ldd /usr/bin/mplayer | grep x264
libx264.so.78 => /usr/lib/libx264.so.78 (0xb6b78000)
$ ldd /usr/bin/mencoder | grep x264
libx264.so.78 => /usr/lib/libx264.so.78 (0xb6ecf000)
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 14:13 GMT
By the way, we also have to switch back to svn for ffmpeg (or disable x264 for this package...):

ERROR: libx264 not found
If you think configure made a mistake, make sure you are using the latest
version from SVN. If the latest version fails, report the problem to the
ffmpeg-user@mplayerhq.hu mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.err" produced by configure as this will help
solving the problem.
Comment by Benjamin Tayehanpour (konaya) - Sunday, 25 October 2009, 14:22 GMT
Are there any drawbacks switching ffmpeg back to svn?
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 14:33 GMT
I don't think so, but it would have the advantage to fix several vulnerabilities[1].

[1] http://secunia.com/advisories/36805/
Comment by Benjamin Tayehanpour (konaya) - Sunday, 25 October 2009, 14:36 GMT
I think we could live with that! :)
Comment by Hugo Doria (hdoria) - Sunday, 25 October 2009, 14:36 GMT
IMHO it's fine to use the svn version of ffmpeg. I just added Eric (ffmpeg maintainer) here.

Does someone know what could be messing my build?
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 16:17 GMT
Do you build your packages in a (clean) chroot? If so, I have no clue why it does not work for you.

Probably, my build logs can help you to find the issue.
   mplayer-29796-1-i686-build.log (868.5 KiB)
   mplayer-29796-1-x86_64-build.... (835 KiB)
Comment by Hugo Doria (hdoria) - Sunday, 25 October 2009, 16:19 GMT
Yep. I am building in a clean chroot. Chould this be a problem with fakeroot? I saw something about nvidia and fakeroot some time ago.
Comment by xduugu (xduugu) - Sunday, 25 October 2009, 17:09 GMT
Yippee, finally was able to reproduce this. (did not build in a chroot though)
When I add --enable-x264 to the PKGBUILD, I get the same error like you. For my builds, I just changed the package version and the versioned dependency for x264.

Hopefully, you added this flag to to configure line. :)
Comment by Eric Belanger (Snowman) - Sunday, 25 October 2009, 23:09 GMT
Just added Aaron (the real maintainer). Does the update of ffmpeg and x264 includes a soname bump? In my experience, they have frequent API changes.
Comment by xduugu (xduugu) - Monday, 26 October 2009, 00:07 GMT
Yes, for x264 .67 -> .78 and for ffmpeg libavutil.so.49.15.0 -> /usr/lib/libavutil.so.50.3.0

Comment by Hugo Doria (hdoria) - Tuesday, 27 October 2009, 13:00 GMT
We need to update x264 and gstreamer0.10-ugly-plugins. I am adding Jan to this.
Comment by Skottish (skottish) - Saturday, 31 October 2009, 00:44 GMT
There was a major change in x264's API around so.76 or so. FFmpeg and Mplayer were adapted on that day to the new changes:

http://forum.doom9.org/showthread.php?t=149593&highlight=x264+api
Comment by (N/A) (wantilles) - Saturday, 31 October 2009, 08:47 GMT
Skottish is right.

Also, having in extra an ffmpeg svn build newer than 0.5, will solve other problems as well.

For example, audacity later than 1.3.7 (we are at 1.3.9 now) needs an ffmpeg later than 0.5 to be able to import files from it.

IMHO, it is time to move to a more recent build of ffmpeg.
Comment by Benjamin Tayehanpour (konaya) - Thursday, 05 November 2009, 08:13 GMT
I agree. Who do we bug for it to happen?
Comment by Eric Belanger (Snowman) - Thursday, 05 November 2009, 09:00 GMT
FYI, Hugo will update ffmpeg/x264 soon. We're just organizing ourselves as many packages will need to be rebuilt: http://mailman.archlinux.org/pipermail/arch-dev-public/2009-October/014153.html
Comment by xduugu (xduugu) - Wednesday, 18 November 2009, 01:08 GMT
Is there already any news on this?
Comment by Per Wigren (Tuxie) - Friday, 27 November 2009, 14:08 GMT
Can't mplayer be statically linked with a recent x264? Considering the rapid development of x264, the mplayer build should really fetch a recent revision of x264 as part of the build, and compile and link it statically if possible.
Comment by xduugu (xduugu) - Wednesday, 02 December 2009, 05:27 GMT
Perhaps it is also an option to remove the direct codec dependencies and link against system's ffmpeg instead. I do not know how often ffmpeg bumps its so versions though.
Comment by Per Wigren (Tuxie) - Wednesday, 16 December 2009, 16:46 GMT
As this seems to be such a hard problem to solve (judging by how long it takes), can't you just revert mencoder to the last working version in the meantime? H.264 encoding is a very important feature for a lot of users and currently it's broken.
Comment by Julien (ganymede) - Thursday, 17 December 2009, 13:41 GMT
For information : recompiling the current svn version of mplayer (version 30051, 17 december 2009) with '--enable-x264' and the latest available snapshot of x264 (20091216) still fails on my x86_64 system.
Comment by Julien (ganymede) - Thursday, 17 December 2009, 13:57 GMT
(Sequel to the previous comment) I just recompiled mplayer-30051 with x264-20091216 but without '--enable-x264'... and I now have x264 encoding support in mencoder !
Comment by Julien (ganymede) - Sunday, 27 December 2009, 18:30 GMT
A little info about packages that had to be recompiled after upgrading x264 :
- mplayer (svn version 30051), ffmpeg (svn version 20889), xine-lib, mlt and vlc compile and run fine with x264 support.
- avidemux 2.5.1 (current stable version for Arch) didn't compile, but the recently released version 2.5.2 compiles and runs fine with x264 support.
- libquicktime and cinelerra-cv don't compile anymore ; cinelerra crashes and openmovieeditor (which depends on libquicktime) still imports mpeg1-2 videos but not mpeg4 nor mjpeg.
So reintroducing x264 support in mencoder breaks at least libquicktime and cinelerra, for the moment (I didn't try the development version of libquicktime yet).
Comment by Julien (ganymede) - Sunday, 27 December 2009, 22:21 GMT
(Sequel to the previous comment - Sorry :) libquicktime and cinelerra-cv could both be rebuilt :
- libquicktime without x264 support (option '--without-x264' passed to configure)
- cinelerra-cv with internal ffmpeg libs (by removing '--with-external-ffmpeg'in the PKGBUILD) AND by removing 10 or 12 files that conflicted with installed ffmpeg files. These files can be removed by rm commands inside the PKGBUILD, and cinelerra seems to work properly without them (more precisely, with the external ffmpeg ones).
So, here's an option to consider : upgrade x264, ffmpeg, mplayer, etc., at the price of removing x264 support from libquicktime and applying a little hack to cinelerra-cv.
Comment by Julien (ganymede) - Wednesday, 06 January 2010, 22:35 GMT
The CVS version of libquicktime (which is the release candidate for libquicktime-1.1.4) was recently upgraded for newer x264 versions. It compiles with x264-20091216, and openmovieeditor also compiles and runs with this version of libquicktime.
Comment by Ionut Biru (wonder) - Tuesday, 12 January 2010, 13:12 GMT
please test mplayer-30286-1 from testing and report back
Comment by Julien (ganymede) - Thursday, 14 January 2010, 18:16 GMT
mplayer-30286-1 is now in 'extra' and all x264-related packages have been updated. Everything works fine for me, with all expected features. A big thanks to the packagers !
I think this bug can now be closed.
Comment by Albin Kauffmann (sigstop) - Sunday, 07 February 2010, 21:17 GMT
The exact same problem seems to occur in in last update of mplayer (30519).

Additional info:
mplayer-30519-1-x86_64
Comment by Ionut Biru (wonder) - Sunday, 07 February 2010, 21:19 GMT
i think it needs new x264 but this wont happen to soon as i'm to busy now to do all rebuilding. i'll do it after kde hits extra
Comment by Ionut Biru (wonder) - Sunday, 07 February 2010, 21:31 GMT
from now i'll downgrade to the working version, as somebody in the forum has problem with it too

Loading...