[MEncoder-users] picking up x264 library

Matyas mplayer.list at sustik.com
Sun Jul 26 23:48:52 CEST 2009


Grozdan wrote:
>> hoping that the x264 from /usr/local/lib will be used, but still no joy.
>>
>> I used --enable-shared for x264 but since it still puts stuff in
>> /usr/local/lib  I added links to the .so from /usr/lib/.  That at least is
>> producing something different:
> 
> I don't quite understand what you're doing here. You built the new
> x264 as shared library, installed it in /usr/local and then linked the
> libs of the older x264 to /usr/local, yes?

I have libx264.so.65 in /usr/lib.  I need that because some packages (mythtv
for example) depends on that version.

The x264 compile from git (and make install) put a libx264.so.68 into
/usr/local/lib.  So I created a link:
ln -s /usr/local/lib/libx264.so.68 /usr/lib/libx264.so.68
then also:
ln -s /usr/lib/libx264.so.68 /usr/lib/libx264.so

With this hand-holding the mencoder build picked up the newly compiled x264.
(I got around the dpkg-shlibdeps error by editing out the call in debian/rules.)

I guess the issue is that x264 sources do not provide debian packaging and
the mplayer/mencoder debian/rules file is not prepared to look in
/usr/local/bin for newer versions of libx264.so.  Nobody is really at fault.

However, am I the only one who builds debian mplayer packages from the latest
sources (with up-to-date x264)?

Now I am rerunning the experiments which failed due to the truncated passlog
file.  A small test (3 min video) indicated that with the current x264 the
error does not occur.  The whole movie encoding will finish in 90 minutes or
so...

Thanks for your help and comments.
Matyas
-
Every hardware eventually breaks.  Every software eventually works.


More information about the MEncoder-users mailing list