Voodooalert+x264 Logo
US+UK flag DE+AT flag
Change language:
 

x264 benchmark compilation & installation guide for GNU/Hurd, Debian distribution

GNU/Hurd logo

System prerequisites

For the purpose of this guide, we shall assume that the [Debian distribution] of GNU/Hurd is being used, since it's currently the most complete and usable GNU/Hurd system in existence. Commands shown in this guide can contain one of two prefixes; Commands that start with a ~ can be run as a normal user. Commands that start with a # have to be run with superuser privileges, or in other words: As user root. Files and directories are shown in green. Placeholders to be filled by the user are shown within angle brackets: <>. In addition to the software that Debian GNU/Hurd ships with, we will also need the following:


The source code of yasm can be obtained [here]. After the download, please unpack the archive file like so: ~ tar -xjvf <filename.tar.gz>. Please change into the newly created yasm subfolder, and build the code: ~ ./configure && make. For the final installation step, you will need root privileges: # make install.

Die benchmark software itself

To be able to use x264 we will need the decoding filters of libavcodec (in short: libav) and the x264 encoder itself, which will be linked against libav during the building process. On top of that we will also need the benchmark input video, download mirrors for that can be found at the bottom of the [benchmark results list]. You may also use ffmpeg/ffms as a replacement for libav if you like.

For simplicities sake we shall assume that the files are now located in /home/user/x264src/. Let's enter that directory and start with libav. Unpack its archive like so: ~ tar -xzvf <filename.tar.gz>, after which a new libav subfolder will be created. Enter that subfolder, and run the following commands in succession. Note that the options regarding opus/libopus relate to an audio en-/decoder, which currently breaks the linking process of x264, which is why we have to disable it. This may change with newer versions of libav/x264 of course, whereby the options --disable-decoder=opus,libopus --disable-encoder=opus --disable-parser=opus may no longer be needed in the future. For the x264 benchmark alone our libav doesn't have to understand opus audio, so we can safely disable it.

Now we have libav installed on the system and we can proceed with building and linking x264. Please unpack the x264 source code: ~ tar -xjvf last_x264.tar.bz2. Enter the newly created x264 subfolder and run the following commands:

Now you can verify the functionality by running ~ x264 --version. If that works, and the binary shows that it's been linked against libswscale and libavformat, then everything went smoothly. If you indeed have a system where no assembler code paths exist for, e.g. a DEC Alpha or a very old Intel x86 like a Pentium MMX, you may need to specify --disable-asm as an option for both configure scripts. Installing yasm is entirely unnecessary in such a case. Now you can download the benchmarking script launchbenchmark.sh here:

Move the file launchbenchmark.sh into a subfolder dedicated to the benchmark. Create one, if you don't have one already: ~ mkdir -p /home/user/x264benchmark. You'll also need to put the benchmark input video elephantsdream_source.264 in that folder.

Now you can basically just run the test, enter the following commands or equivalents of it:

When running, it should look somewhat like this:

GNU/Hurd Screenshot

After this, just read the "Real" value from the terminal to obtain your result. You'd also want to look a few lines above the result and check whether the full amount of frames has been encoded. That'd be 15691 frames. If the number is lower, then either your input video is damaged or your computer unstable, making the result invalid.

Depending on the machine this may take hours, in extreme cases days or even weeks or months, especially since GNU/Hurd and its Mach kernel only support one CPU core on many modern platforms. If you're doing this remotely via SSH or something similar, you may want to think about using a screen session, that can be safely pushed to the background, so you don't have to keep an open interactive login shell all the time. Before using screen, please read the documentation first: ~ man screen.

[Back to the x264 benchmark results list]

[Comment on this guide]