Voodooalert+x264 Logo
US+UK Flagge DE+AT Flagge
Sprache wechseln:
 

x264 Benchmark Installationsanleitung für FreeDOS 1.1

FreeDOS Logo

Systemvoraussetzungen

Die Inhalte dieser Anleitung sind möglicherweise auch auf andere DOS Systeme anwendbar. Getestet wurde das Verfahren jedoch ausschließlich auf FreeDOS 1.1, die Funktion auf anderen Systemen kann nicht garantiert werden.

Um den x264 Benchmark auf FreeDOS erfolgreich laufen lassen zu können, müssen mehrere Voraussetzungen erfüllt sein.

1.) Der XMS Speichermanager

Die erste stellt der verwendete Speichermanager dar. FreeDOS 1.1 wird mit drei Speichermanagern ausgeliefert:

Sowohl JEMMEX wie auch EMM386 bieten x264 mit ihrer XMS Speicherverwaltung keinen guten Nährboden. Bei Einsatz eines dieser beiden Speichermanager wird x264 abstürzen, weil die Speicherallokierung beim Aufruf der malloc() Funktion fehlschlägt, so als ob nicht genügend RAM verfügbar wäre. Das geschieht auch dann, wenn mit 1GB oder mehr genügend Speicher zur Verfügung steht. Nur XMGR ist in der Lage, den stabilen Betrieb von x264 sicherzustellen. FreeDOS 1.1 ist also mit XMGR als Speichermanager zu starten, welchen man im Bootmenü auswählen kann.

2.) Beseitigung der Inkompatibilität zwischen XMGR, UIDE und LFNs

x264 benötigt zudem im vom Benchmark genutzten 2-Pass Modus lange Dateinamen, auch bekannt als LFNs (Long File Names). Prinzipiell bietet FreeDOS hier mit DOSLFN bereits eine entsprechende Schnittstelle an, die ein per DJGPP gebautes x264 nutzen kann und die standardmäßig geladen wird. Leider gibt es ein massives Datenintegritätsproblem, sofern XMGR, LFNs und der standardgemäß geladene UIDE.SYS Puffertreiber zusammenkommen. Dabei kommt es zu Schäden am FAT Dateisystem, und der Benchmark kann nicht sauber arbeiten. Um diesem Fehlverhalten entgegenzuwirken, deaktivieren wir UIDE.SYS in der Startdatei C:\AUTOEXEC.BAT, z.B. mit dem DOS Texteditor: EDIT.COM C:\AUTOEXEC.BAT.

Die folgende oder ähnliche Zeile wäre zu finden:

Ein einfaches Voranstellen von REM kommentiert diese Zeile aus:
Danach wären die Datei zu speichern und der Rechner neu zu starten.

3.) Benötigte Zusatzsoftware und deren Probleme

Der Betrieb des Benchmarks erfordert noch das Tool RUNTIME.COM von Tim Hall unter Maintenance von Eric Auer ([Link]), welches zur Zeitmessung erforderlich ist. Das Tool muß nicht extra heruntergeladen werden, da es in den Benchmarktools weiter unten integriert ist.

RUNTIME.COM weiß allerdings mit einem hinterhältigen Bug aufzuwarten: Mißt das Tool die Laufzeit eines Programms, so setzt sich die gemessene Zeit alle 24 Stunden auf 0 zurück! Da DOS nur einen logischen Prozessorkern unterstüzt, und x264 der Einsatz von SSE Einheiten aufgrund von Compilerproblemen unter DOS nicht möglich ist, kann es sehr schnell zu Laufzeiten über 24 Stunden kommen.

Es ist also unbedingt darauf zu achten, die exakte Startzeit zu notieren, im Speziellen den Starttag. Startet man den Test also z.B. am Dienstag um 13:00, und schließt er am Donnerstag um 14:30 mit einem Resultat von 01:30:00.00 ab, so kann die Laufzeit natürlich niemals nur eine Stunde und dreißig Minuten betragen haben. Die fehlenden Tage sind also zu addieren! In unserem Fall sind 24 Stunden von Dienstag 13:00 bis Mittwoch 13:00 vergangen, dann nochmals 24 Stunden von Mittwoch 13:00 bis Donnerstag 13:00, und dann noch 01:30 Stunden Restzeit am Donnerstag von 13:00 bis 14:30. Die finale Laufzeit beträgt für dieses Beispiel also 49:30:00.00.

Dieses Fehlverhalten scheint vom Entwickler beabsichtig zu sein, wie der Quellcode veranschaulicht:
runtime.asm (Zeilen 66:73):
cmp dx,24 jb oktime ; more than ca 24 hours: implausible, wrap? neg ax neg dx cmp dx,24 jb oktime xor ax,ax ; if still not okay, show 00:00.00 xor dx,dx

Obendrein gibt es noch einen Fehler: Da DOS Ticks nur exakt 18.206481934 Mal pro Sekunde passieren, beträgt die kleinste meßbare Zeiteinheit exakt 54.925493219ms. Das resultiert darin, daß sinnvolle Zeitmessungen mit einem DOS Kernel nur in Zentisekundengenauigkeit, nicht aber in der sonst üblichen Millisekundengenauigkeit möglich sind. Zusätzlich dazu nimmt RUNTIME.COM einfach runde 18.2 Ticks pro Sekunde an (54.945054945ms), womit sich für jeden Tick ein Meßfehler von −0.019561726ms ergibt. Hochgerechnet auf eine volle Stunde wären dies dann −1.282140759661 volle Sekunden, in einem Tag bereits −30.771378231864 Sekunden, also in etwa eine halbe Minute. Prozentuell ist dieser Anteil vernachlässigbar, da er wohl kleiner als diverse Meßungenauigkeiten sein dürfte. Will man aber penibel vorgehen, wäre dieser Fehler rechnerisch aus dem erzielten Ergebnis herauszukorrigieren!

Die Ursache für die Ungenauigkeit läßt sich wieder dem Quellcode entnehmen:
runtime.asm (Zeile 84):
mov cx,182 ; 18.2 ticks per second...

Die Benchmarksoftware selbst

x264 hat neben den bereits gezeigten Problemen mit einer weiteren Limitierung zu kämpfen, und zwar der maximalen Länge von Befehlen unter DOS Kommandozeileninterpretern: 125 Zeichen. Die beiden Befehle aus denen der x264 Benchmark besteht überschreiten dies aber in jedem Fall deutlich. Aus diesem Grund bedienen wir uns einen Tricks, mit dessen Hilfe die Parameter der Befehle aus einer Datei direkt an x264 übergeben werden, ohne dabei über COMMAND.COM zu stolpern.

x264 selbst liegt für DOS in einem mit [DJGPP kompilierten Build] von RayeR vor, den wir für den Benchmark heranziehen. Dieser Build unterstützt wie auch DOS selbst nur Single Thread Betrieb, es kann also nur ein logischer Prozessor genutzt werden. Außerdem müssen wir auf Assembleroptimierungen für Befehlssatzerweiterungen wie SSE/SSE2/SSE4.1/SSE4a und dergleichen verzichten, da ein vom Compiler generiertes Alignmentproblem die Ausführung derartigen Codes verhindert. Die Downloads &fuuml;r den Benchmark:

Es empfiehlt sich, alle Daten des Benchmarks in einen separaten Ordner zu platzieren. Wir nehmen der Einfachheit den Ordner C:\X264B\ an. Bevor man beginnen kann, wäre das Benchmarkvideo elephantsdream_source.h264 dann noch auf PHANT.264 umzubenennen. Die Datei muß genau so heißen, damit der Test funktionieren kann. Die Benchmarktools sind im selben Ordner wie das Benchmarkvideo zu entpacken. Um diese Prozesse zu vereinfachen, kann es empfehlenswert sein, die Dateien in einem anderen Betriebssystem herunterzuladen und aufzubereiten, wie z.B. in einem von CD bootfähigen Linux, wie etwa Knoppix.

Danach kann man den Benchmark ausführen, wenn man alles in den oben genannten Ordner platziert hat, indem man folgende Kommandos ausführt:

C:
cd \X264B\
BENCH.BAT

Nach Ablauf des Tests ist das Ergebnis nicht wie sonst gewohnt aus der Datei RESULTS.txt zu holen, sondern direkt von der Konsole abzulesen. Der Zeitwert wird als letzte Ausgabezeile nach Abschluß des Benchmarks ausgegeben. Zusätzlich kann man auch noch ein paar Zeilen weiter oben prüfen, wieviele Frames tatsächlich kodiert worden sind. Damit ein gültiges Resultat angenommen werden kann, müssen hier exakt 15691 Frames ausgewiesen sein, es muß also eine Zeile wie encoded 15691 frames, x.xx fps, xxxxx.xx kb/s zu sehen sein!

Im Betrieb würde der laufende Test das dann zum Beispiel so aussehen:

FreeDOS Screenshot

Je nach Maschine kann das jetzt durchwegs mehrere Tage, Wochen oder Monate dauern. Bei Problemen mit dieser Anleitung oder weiteren Fragen zum x264 Benchmark auf FreeDOS bitte einfach im [entsprechenden Forumsthread] nachfragen.

[Zurück zur x264 Benchmark Ergebnisliste]

[Anleitung kommentieren]