x264 benchmark installation guide for FreeDOS 1.1
This guide may be applicable to other DOS systems. The procedure has only been tested on FreeDOS 1.1 exclusively however, the functionality on other systems can not be guaranteed.
To run the x264 benchmark successfully on FreeDOS, several requirements must be met.
1.) The XMS memory manager
The first one is the memory manager. FreeDOS 1.1 ships with three different memory managers:
Neither JEMMEX nor EMM386 can provide a stable basis for x264 with their XMS memory management. When using either of them, x264 will crash with a failing memory allocation when calling the
malloc() function, just as if there wasn't enough RAM. This also happens if there is actually enough RAM with 1GB or more. Only XMGR is capable of ensuring a stable operation of x264. So you need to boot FreeDOS using the XMGR memory manager. You can select it in the boot menu.
2.) Fixing the incompatibility between XMGR, UIDE and LFNs
x264 requires LFNs (long file names) to operate in the 2-pass mode the benchmark is running in. With DOSLFN FreeDOS is offering a corresponding API, that can be used by x264 when compiled with DJGPP. On top of that, DOSLFN is already loaded by FreeDOS by default. Unfortunately this will lead to a massive data integrity problem when mixing XMGR, LFNs and the IDE buffer driver UIDE.SYS, which is also being loaded by default. When using them together, writing to files with long names will cause the FAT file system to corrupt and will keep the benchmark from working properly. To counter this undesired behavior, we will deactivate UIDE.SYS in the system file AUTOEXEC.BAT, e.g. with the DOS text editor:
You'll need to locate the following or a very similar line:
DEVLOAD /H /Q %dosdir%\BIN\UIDE.SYS /H /D:FDCD0001 /S5
Simply prepending it with
REM will comment the line out, deactivating it:
REM DEVLOAD /H /Q %dosdir%\BIN\UIDE.SYS /H /D:FDCD0001 /S5
Save the file after applying the modification and reboot the machine.
3.) Additional software and its problems
The benchmark also needs the tool RUNTIME.COM by Tim Hall, which is currently maintained by by Eric Auer ([link]), which will be used for time measurements. You don't need to download this separately, as it's already included in the benchmark tools further down.
RUNTIME.COM has it's fair share of bugs though, one being particularly nasty: When measuring the runtime of a program, the time counter will reset to 0 every 24 hours! Since DOS can only handle one logical processor and x264 cannot use SSE units due to compiler issues under DOS, runtimes of more than 24 hours are encountered quite easily.
You'll absolutely need to pay close attention and write down the exact day and time when the benchmark was started. Say you start it on Tuesday at 01:00pm, and it crosses the finishing line on Thursday at 02:30pm with a result of 01:30:00.00, it's pretty clear that one hour and thirty minutes can't be right. So you'll need to manually add the missing days! In our case, 24 hours have passed from Tuesday, 01:00pm to Wednesday, 01:00pm, and once more from Wednesday, 01:00pm to Thursday, 01:00pm. The rest of the time that we can read from the result were the 01:30 hours from Thursday, 01:00pm to 02:30pm. So the final runtime for this example is 49:30:00.00.
This bug seems to be intentional though, as the source code shows:
runtime.asm (lines 66:73):
jb oktime ; more than ca 24 hours: implausible, wrap?
xor ax,ax ; if still not okay, show 00:00.00
And that's not all, there is another small issue. Since DOS ticks happen exactly 18.206481934 times a second, the smallest measurable time span is exactly 54.925493219ms long. As a result, purposeful time measurements on DOS kernels are limited to centisecond precision instead of the usual millisecond precision. In addition to that, RUNTIME.COM simply assumes a round 18.2 ticks per second (54.945054945ms), which creates an error margin of −0.019561726ms per tick. If you sum that up to an hour of runtime, the errors would accumulate to −1.282140759661 full seconds. Summed up to a full day, that means −30.771378231864 seconds, or roughly half a minute. While the error seems negligible in comparison to the runtime - likely smaller than any regular error of measurement - you'd need to correct the error manually after the result presents itself in case you wish to be as exact as possible.
The reason for the inaccuracy can once more be found in the source code:
runtime.asm (line 84):
mov cx,182 ; 18.2 ticks per second...
The benchmark software itself
Besides what we've seen now, x264 has another problem with one of DOS' limitations, and that's the maximum command length of the DOS command line interpreter: 125 characters. The two commands the x264 benchmark consists of exceed that easily however. Due to that we'll use a trick and feed the parameters to x264 from files, without stumbling over
COMMAND.COM in the process.
x264 itself is available as a [DOS build compiled with DJGPP], ported by RayeR. This build supports only a single thread just like DOS itself does, so only a single logical processor can be used. Also, we'll need to forget about assembly optimizations making use of instruction set extensions like SSE/SSE2/SSE4.1/SSE4a and so on, as the compiler messes up during the build, creating an alignment problem that will keep the code from running. Here are the download links:
It is recommended to place all files of the benchmark in a separate folder. For simplicitys sake we shall assume the folder C:\X264B\. Before you can start, you will need to rename the file elephantsdream_source.h264 to PHANT.264. The file needs to be called that exactly, or the benchmark will not work. Unpack the benchmark tools into the same folder. To make this easy, you might wish to use another operating system for downloading and preparing everything, like maybe some Linux that can boot from CD, e.g. Knoppix.
Now you can run the benchmark if all files are ready in that folder by running the following commands:
After completion, the result cannot be obtained from RESULTS.txt as usual, but has to be read from the terminal directly. The time value will be printed as the last line of the output after everything is completed. You may also wish to look a few lines higher to verify that the benchmark has truly computed all frames. To make the result valid, it has to be 15691 frames. So there needs to be a line reading something like:
encoded 15691 frames, x.xx fps, xxxxx.xx kb/s!
When running, the test could look like this:
Depending on the machine this may take days, weeks or even months. If you have problems with this guide or if there are any additional questions about the x264 benchmark on FreeDOS, please refer to the [according forum thread] and ask there. The forum is german, but if you ask in english, you should still receive a reply.
[Back to the x264 benchmark results list]
[Comment on this guide]