Log in

View Full Version : Compiling x264 for Mac OS X 10.7


BigPines
4th March 2013, 09:50
I have a fairly old version of x264 on my Mac so I decided to update it. I was unable to find any recent binaries for OS X so I decided to compile my own.

1) I grabbed the latest source from git:

git clone git://git.videolan.org/x264.git

2) I changed to the newly downloaded x264 dir:

cd x264

3) I ran the configure script. I found an example enabling pic and shared. I really don't understand what these options do or if I need them but I used them anyway because it was one of the only examples I could find. I tried to look for documentation explaining them but was unable to find anything:

./configure --enable-pic --enable-shared

4) I then ran make:

make

5) After the make finished, I checked the version of the newly compiled x264 and this is where I got surprised.

x264 --version

"x264 0.98.x
built on May 26 2011, gcc: 4.2.1 (Apple Inc. build 5666) (dot 3)"

0.98.x? The "old" version I am running is 0.116.2057+600 which it says was built on Aug 11, 2011!

So what is going on here? Why is my old version of x264, newer than the one I just pulled from git? The only difference I can see is it looks like the old version is 8+ MB where the new one is ~1 MB. The old one looks like it has other libraries compiled into it somehow (libswscale, libavformat & ffmpegsource). I honestly don't remember where I got the old one.

Anyone feel like helping out a noob? Any help is appreciated.

Mike

Dark Shikari
4th March 2013, 13:42
"x264 --version" will run the x264 in your PATH, not the x264 you just compiled. Do you mean "./x264 --version"?

LoRd_MuldeR
4th March 2013, 14:51
Just a side note:

The command "which (http://en.wikipedia.org/wiki/Which_%28Unix%29) foobar" will tell you which executable is being used when you type the command "foobar" without a path, so "which x264" would tell you which x264 binary is used.

Furthermore: Normally you would run "make install" after successful compilation, so your newly compiled binary gets copied to the location (e.g. "/user/bin") where it will be used by default.

(Note that the "make install" may need a "sudo ...", but I'm not so sure about Mac OS X^^)

BigPines
4th March 2013, 17:29
"x264 --version" will run the x264 in your PATH, not the x264 you just compiled. Do you mean "./x264 --version"?

Thanks! That was my problem alright. I told you I was a noob! :)

I ended up finding three different versions of x264 on my system:

/bin/x264
/opt/local/bin/x264
/usr/local/bin/x264

"sudo make install" puts x264 in /usr/local/bin/ but the system seems to want to use /opt/local/bin/ by default for some reason and if the binary isn't present there, it says "no such file or directory". As long as I manually copy x264 into /opt/local/bin/ everything seems to work. Any idea why this is happening? I believe I previously copied x264 in /bin/ trying to make it work but for now I removed it.

Just a side note:

The command "which (http://en.wikipedia.org/wiki/Which_%28Unix%29) foobar" will tell you which executable is being used when you type the command "foobar" without a path, so "which x264" would tell you which x264 binary is used.

Furthermore: Normally you would run "make install" after successful compilation, so your newly compiled binary gets copied to the location (e.g. "/user/bin") where it will be used by default.

(Note that the "make install" may need a "sudo ...", but I'm not so sure about Mac OS X^^)

Thank you for this. It was instrumental in me figuring out what I had done wrong.

I intentionally hadn't used "sudo make install" because I was just trying to figure out what I had created before I installed anything. I also figured (maybe mistakenly) I could just copy the binary where I wanted to without having to run install. Is this not the case?

BTW, make install does require the sudo (on my version of OS X anyway).

Thank you both again for your help. It is very educational and much appreciated. I wish I understood this stuff better.

Mike

BigPines
4th March 2013, 17:58
Well, I guess I didn't compile it correctly. When I run the following:

x264 --crf 1 --preset superfast --level 4.1 --tune film --fps 24000/1001 --keyint 24 --weightp 2 --bframes 3 --b-pyramid normal --slices 4 --sar 1:1 -o output.h264 video.vc1

I get the following errors:

avs [error]: failed to load avisynth
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `video.vc1' via any method!

I didn't have any errors on my previous version of x264. I'll dig around on Google but I currently don't even know where to start to resolve these. Any advice is appreciate.

Mike

LoRd_MuldeR
4th March 2013, 18:21
Well, you compiled it without support for FFMS2/Libavf, it seems. Without these extra libraries, the x264 command-line encoder cannot read/decode your input format (VC-1). Only "raw" (uncompressed) data can be read.

You can either re-compile x264 with the required libraries enabled, which of course requires that you compile these libraries first, or you use something like FFmpeg to pipe the "raw" data into x264.

For example:
ffmpeg -i your_input_here.foo -f yuv4mpegpipe - | x264 -o output.264 -

xooyoozoo
4th March 2013, 21:28
Thanks! That was my problem alright. I told you I was a noob! :)

I ended up finding three different versions of x264 on my system:

/bin/x264
/opt/local/bin/x264
/usr/local/bin/x264

"sudo make install" puts x264 in /usr/local/bin/ but the system seems to want to use /opt/local/bin/ by default for some reason and if the binary isn't present there, it says "no such file or directory". As long as I manually copy x264 into /opt/local/bin/ everything seems to work. Any idea why this is happening? I believe I previously copied x264 in /bin/ trying to make it work but for now I removed it.

You can create a .bash_profile file to change which paths Bash will look in first. Google can help you on this.

I also can't think of many reasons to have multiple versions of x264 binaries (and presumably libraries) opaquely placed throughout your system, so it's probably a good idea to tidy things up too. :)

BigPines
5th March 2013, 00:08
Well, you compiled it without support for FFMS2/Libavf, it seems. Without these extra libraries, the x264 command-line encoder cannot read/decode your input format (VC-1). Only "raw" (uncompressed) data can be read.

You can either re-compile x264 with the required libraries enabled, which of course requires that you compile these libraries first, or you use something like FFmpeg to pipe the "raw" data into x264.

For example:
ffmpeg -i your_input_here.foo -f yuv4mpegpipe - | x264 -o output.264 -

I would like to compile x264 with the required libraries if possible. I have honestly searched around and have been unable to figure out how to do this. I am surprised how little information there seems to be about doing this. If you could please point me in the right direction, it would be very appreciated.

Thanks in advance.

Mike

LoRd_MuldeR
5th March 2013, 00:19
If you run ./configure from the x264 source directory, it will enable support for "gpac", "libav" or "ffms2" automatically, if those libraries are present on your system - in the correct version.

The text output will show you which libraries have been enabled, and which not. If anything is missing (that you expected to be there), you can see "config.log" for details.

Note that, in order to enable those libraries, you will need to have the library files (.a) in your LIB path and you will also need to have the corresponding header files (.h) in your INCLUDE path.

You can also do: ./configure --extra-cflags="-I/home/user_name/path_to_header_files" --extra-ldflags="-L/home/user_name/path_to_lib_files"

xooyoozoo
5th March 2013, 03:18
I would like to compile x264 with the required libraries if possible. I have honestly searched around and have been unable to figure out how to do this. I am surprised how little information there seems to be about doing this. If you could please point me in the right direction, it would be very appreciated.

Thanks in advance.

Mike

Just curious, are you doing this just to learn how things work, or did you just want binaries compiled for your own system?

If it's the latter, Homebrew (http://mxcl.github.com/homebrew/) is a great midpoint between depending on others' precompiled binaries and micromanaging everything yourself.

BigPines
5th March 2013, 07:50
Just curious, are you doing this just to learn how things work, or did you just want binaries compiled for your own system?

If it's the latter, Homebrew (http://mxcl.github.com/homebrew/) is a great midpoint between depending on others' precompiled binaries and micromanaging everything yourself.

Thanks! Actually, I really just want to use x264. I had heard of Homebrew before but never really needed it - tonight I gave it a shot. It is much easier than fighting with this stuff on my own but there is one major problem. There seems to be no formula for ffms2 which is the whole problem I am having. I have to get that library compiled and installed so I can compile x264 with it.:(

Mike

BigPines
5th March 2013, 08:04
Maybe Homebrew will work somehow! I installed ffmpeg and it's dependencies via Homebrew and then x264. It looks like it reads my vc1 file despite me never compiling ffms2! It looks like I may be in business. Any reason why I shouldn't let my guard down yet? :)

Mike

MilSF
10th March 2013, 02:53
The /opt/local/bin path is the favored path of MacPorts, so that's where that might have come from. If you aren't enamored of Homebrew, you can give them a try. The ffmpeg-devel port is about a month back, but not too bad. Include +gpl2+gpl3+nonfree and you will get all sorts of goodies including x264 (currently snapshot 2245)