?
Nach dem - ich denke man kann das so hinstellen? - lokalen Erfolg des [x264 Benchmarks] sind im Verlaufe der Jahre auch einige Probleme mit der x264 Version mit der alles angefangen hat aufgetaucht.
Einige Nutzer merken langsam, daß die Skalierbarkeit auf "Manycore" Systemen (16 Threads+ sag ich jetzt Mal) deutlich abnimmt. Umgehbar ist das nur durch Austausch der EXE und damit durch Invalidierung des Resultats.
Jetzt experimentiere ich schon länger an einer künftigen Version des Konzepts, aktuell auf Basis von x265 (aber auch x264 ist nach wie vor nicht ausgeschlossen, frisst halt NOCH mehr Speicher, s.u.). Um die Parallelisierbarkeit zu erhöhen kommt aber nicht nur neue Software zum Einsatz, sondern auch völlig neuer Content - in 21:9 cinemascope 8K Auflösung (7680×3720, ein non-anamorphic Crop von normalem 8K, 7680×4320). Echtes cinemascope 8K wie für Kinos verabschiedet (10240×4320) kann aktuell kein freier Encoder.
Folgendes würde sich daraus ergeben:
- 64-Bit CPUs und Betriebssystem würden zum Minimum erhoben!
- Windows XP x64 und Server 2003 x64 würden die ältestmöglichen Windows Plattformen darstellen (getestet!).
- 16GB RAM wären absolutes Minimum (aktuell frißt der Encoder 15.5GB im Test, der Decoder 430MB, mit etwas Tweaking wär das knapp unter 16GB zu drücken)!
- CPU Threading ist noch ungetestet, könnte aber gut bis 128 Kerne und höher gehen (Testplattformen könnten in einigen Monaten bereitstehen, nicht früher von meiner Seite).
Das Projekt wäre theoretisch ähnlich angesetzt wie bisher, nur mit ein paar kleinen Veränderungen, die ich planen würde:
- Der Bench sollte mit Quellcode kommen. Gültige Resultate wären nicht an irgendeine schwindelige EXE gebunden, sondern an die Versionsnummer des Benchmarks. So ließe sich die Software auf allen Zielplattformen bauen, und man könnte auch von Linux, UNIX usw. "gültige" Ergebnisse für Direktvergleiche einsenden. Minimale Schwankungen durch Compilerversionen würde ich planen hinzunehmen, solange der Nutzer die Compilerflags nicht manuell anpasst!
- Es sollten (für Windows) Tools dabei sein, für Linux zumindest die Steuerskripte, mit denen man aus dem Ergebnis des Benchmarks einen funktionierenden Film zusammenbauen kann (MKV Datei), und zwar mit nur einem Klick! So kann jeder den eben kodierten Film händisch testen. Per VLC oder MPC-HC oder wie auch immer. Ich mein, flüssig spielt sowas eh keine Maschine ab, aber jo.
- Evtl. eine etwas bessere Abbruchbehandlung für Crashes, sodaß der Nutzer eine Warnung (und kein Resultat!) bekommt, falls der Test abstürzt.
Das ganze hat natürlich offensichtliche Nachteile, gerade für eine Community wie diese hier. Und die dürften auch einleuchten, wenn man sich die Systemanforderungen anschaut. Das ist auch noch lanczos-upscaled 8K aktuell (Film: Sintel: Quelle: 21:9 cinemascope 4K), wenn ich die Quelldaten hole und den nativ auf 8K mit Blender selbst rausrendere (sofern meine HW das überhaupt in endlicher Zeit schafft und ich ned zu dumm dafür bin), dann könnten die Anforderungen sogar noch steigen.
Daher die klaren Nachteile:
- Die Laufzeit würde steigen. Allerdings so brutal, daß der Benchmark für "gemeines Volk" (=Leute mit weniger als 64 Kernen) unausführbar wird. Das ließe sich noch regeln, nimmt man halt nicht 14min Quellvideo, sondern nur 1min und passt wieder. Aaaaber...
- ...Retrosysteme wären kategorisch ausgeschlossen, einfach aufgrund des 32-Bit Adressraums. Und damit auch alte Betriebssysteme. Diese lustigen Windows Me/9x und Windows NT/2000 Resultate auf guten alten Pentiums, Athlons, K6, usw. würden damit der Vergangenheit angehören.
- ...Freakplattformen wie Raspberry Pi oder diverse ARM Development Boards für Android wären ebenfalls weg vom Fenster (auch aus dem Bereich gibt es einige User hier). Diverse MIPS und die meisten PowerPC Systeme wären genauso dahin, zumindest solange sie nicht genug RAM mitbringen können.
Jetzt ist VA natürlich eine Retro Community. Und hat schon einen CPU Benchmark, der sehr viel abdeckt, der aber eben mit sehr fetten Boxen mit sehr vielen Kernen nicht mehr so gut kann. Er schafft's mit der alten x264 Version und der "niedrigen" Quellauflösung von 1920×1080 halt nicht mehr, 32 Threads auszulasten, zum. nicht in Pass 1.
Daher stelle ich die Frage:
Macht so etwas auf VA überhaupt Sinn? Wollen wir so etwas? Oder pfeifen wir drauf und lassen alles wie es ist - so schlecht funktioniert es ja nicht. Beide Projekte würden ohnehin parallel weiter laufen.
Aber: Macht so etwas auf VA überhaupt Sinn?
Alternativfrage: Man könnte 1080p auch lassen, das "Quellcodeversion = Referenzergebnis" Konzept aus der 8K Idee auskoppeln und auf den x264bench anwenden. Alle aktuellen Resultate würden bleiben und rot markiert werden. Alle neuen sind dann weiß, so sie aus Referenz kommen. Durch Übernahme einer neuen x264 Version als Referenz würden wir auch bei 1080p einiges an Skalierbarkeit hinzugewinnen, nur halt nicht GANZ so weit in die Zukunft wie bei der 8K Idee. Sollte man das machen? Die Zukunftssicherheit zugunsten alter Plattformen einschränken?
Oder sollte man einfach gar nichts tun?
Edit:
Auf Anfrage von SK1 hier eine kleine Zusammenfassung des aktuellen Status' des Projekts.
Aktive Entwicklungsphase: Beta 2 (Windows, unreleased) und Alpha 17+ (UNIX, unreleased)
Solange sich das Projekt in der Alphaphase befindet, ist keine Feature Completeness erreicht. Ergebnisse aus der Alpha können und sollen bitte gerne gepostet werden, aber ich möchte darauf hinweisen, daß das eine frühe Testphase ist, d.h. diese Ergebnisse werden nie in irgendeiner Liste landen. Ein erstes Erfassen der Resultate kann frühestens in der Betaphase beginnen!
Bisherig verfügbare Versionen (Open Alpha / Open Beta):
-
Windows 64-bit x86:
- [Pre-Alpha 1] (2017-02-06, erste lauffähige Version)
- [Pre-Alpha 2] (2017-02-07, erste Version mit Prüfsummenchecks)
- [Pre-Alpha 3] (2017-02-17, Wechsel auf ffmpeg, neuer Compiler, viele Fixes)
- [Alpha 1] (2017-02-18, MediaInfo hinzugefügt, Framecountprüfung implementiert, viele kleine Optimierungen)
- [Alpha 2] (2017-02-22, NUMA Weiche mit zwei x265 Binaries, CPU-Z hinzugefügt, UAC implementiert, Rechteprüfungen auf NT5.2 implementiert, optionaler 8K Support. 8K Videofile: [input8K.h265], Anweisungen zur Nutzung [hier].)
- [Alpha 4] (2017-02-24, Kommadozeilenparameter implementiert, Screenbuffer wird gesetzt, Ordnerstruktur in Anlehnung an POSIX komplett aufgeräumt, umfangreiche Bugfixes und Codekonsolidierung)
- [Alpha 5] (2017-03-10, 8K ist nun Standard, Inputvideowechsel von 12-bit YUV 4:4:4 auf 10-bit YUV 4:2:0 um Decoder-RAM zu sparen, Encoding Chroma Subsampling aktiv, YUV 4:2:0 um Encoder-RAM zu sparen, Reduktion der B-Frames von 16 auf 4 um Encoder-RAM zu sparen, Vergrößerung des 8K Videos von 500-600 auf 800 Frames um schnellere Laufzeiten zu kompensieren, Virtuelle Speicherprüfung eingeführt um RAM und Gesamtspeicher RAM+Swap korrekt zu behandeln, RAM Limit jetzt bei 16GB mit Warnung bei Unterschreiten, virtuelles Speicherlimit bei 16GB mit Fehler bei Unterschreiten, duale Prüfsummen eingeführt, womit das System auch geänderte Dateien erkennen und vermerken kann. Dateien deren Änderung durch den Benutzer nicht zulässig ist lösen einen Fehler aus sobald sie modifiziert wurden. Das alte 720p Video wird derweil noch optional mit ausgeliefert, alles in einem Archiv. Diskanforderung aktualisiert: 512MiB.)
- [Win64 Beta 1] (2017-04-06, Deutsche README.txt hinzugefügt, Quelltextänderungen dokumentiert, kosmetische Anpassungen der Checks um die Windows und UNIX Versionen aneinander anzugleichen.)
- [Win64 Beta 5] (2017-11-10, Neue x265 Version 2.5+48, zahlreiche Verbesserungen im Bereich Robustheit des Launchers und der Prüfsummenverifikationen, Bugfixes in seltener aufgerufenen Teilen des Skripts, kosmetische Verbesserungen, Cleanup der Ordnerstruktur.)
- [
Win64 Beta 6 / RC1] (2017-11-15, VC++ Redistributables konsolidiert, VC++2010 x86 in VC++2017 x64 migriert bzw. colorecho.exe mit VC++2017 x64 neu kompiliert, dadurch nur mehr eine Redistributable nötig. Launcher angepaßt/konsolidiert, VC++2010 x86 Abfrage entfernt. Bug in der Betriebssystemweiche des Deutschen Hardwarereportingzweigs gefixed. NT5.2 Systeme erzeugen jetzt bei Einsatz eine Warnung statt nur einer Notiz, da die Leistung beeinträchtig wird - XP x64 & Server 2003 x64, Ergebnisse bleiben aber gültig. CPU-Z zur Unterstützung neuerer Plattformen von 1.78.3 -> 1.81.1 aktualisiert, Hardwarereporting im Launcher an die neue Version angepaßt. Einbau eines Benutzer-Prompts auf NT5.2 Systemen, wenn KB932370 fehlt, damit der Nutzer interaktiv entscheiden kann, ob er in diesem Zustand fortfahren oder vorerst abbrechen will. Microsofts' choice.exe dafür durch eine Freewareversion ersetzt. README*.txt Dateien aktualisiert. LINK DEAKTIVIERT, BLOCKER BUG GEFUNDEN!) - [Win64 Beta 6 / RC2] (Blocker Bug gefixed: Fehlendes Klammer-Escaping in einem ECHO Befehl des Softwarereportings, der fieserweise erst nach dem Encodingdurchlauf schlagend wird, und den kompletten Benchmark zunichte macht.)
-
UNIX, Linux und HaikuOS 64-bit x86:
- [UNIX Alpha 16] (2017-04-06, Bootstrapping und Betrieb erstmals öffentlich möglich, siehe Anforderungen unten.)
- [UNIX Beta 5] (2017-11-10, Neue x265 Version 2.5+48, zahlreiche Verbesserungen im Bereich Robustheit des Launchers sowie Bootstrappers und der Prüfsummenverifikationen, Bugfixes in seltener aufgerufenen Teilen des Skripts, kosmetische Verbesserungen, Cleanup der Ordnerstruktur.)
- [UNIX Beta 6 / RC1] (2017-11-15, HAL deprecated unter Linux & FreeBSD UNIX, bessere Detektion und Behandlung des "time" Befehls als Reserved Shell Keyword wie Binärprogramm, neue Deutsche README-GER.txt, Verbesserungen der Debian Versionserkennung, Bugfixes und kosmetische Fixes am Launcher. README*.txt Dateien aktualisiert.)
Aktuelle Systemanforderungen (Windows):
- Windows XP Professional x64 Edition / Windows Server 2003 x64 oder neuer (Vista, 7, 8.x, 10), ausschließlich in x86_64!
- 64-Bit x86 Prozessor (Ab Intel Prescott oder AMD Athlon64)
- 16GiB RAM
- 1.2GiB Diskspace
Aktuelle Systemanforderungen (UNIX / Linux / Haiku OS):
- Ein POSIX-kompatibles 64-bit Betriebssystem (UNIX, Linux, Haiku OS)
- 64-Bit x86, PowerPC, ARM oder Itanium Prozessor (RISC und VLIW Architekturen noch ungetestet)
- 16GiB RAM
- 1.5GiB Diskspace
- Für spezifischere Softwareanforderungen siehe README/README.txt oder die Ausgaben von $ ./bootstrap.sh
Unterstützte UNIX Betriebssysteme:
- Apple MacOS X, Versionen 10.9.4, 10.9.5
- DragonFly BSD UNIX, Version 4.8.0-RELEASE
- FreeBSD UNIX, Version 10.3-RELEASE, 11.0-RELEASE
- NetBSD UNIX, Version 7.1
- OpenBSD UNIX, Version 6.0
- Sun/Oracle Solaris, Version 11.3
- TrueOS UNIX, Version FreeBSD 12.0-CURRENT
Unterstützte Linux Distributionen (andere können natürlich gut und gern auch funktionieren, hier gibt es keine distributionsspezifischen Abfragen, das ist einfach eine Liste getesteter Systeme):
- CentOS Linux, Versionen 6.8, 7.3.1611
- gNewSense Linux, Version 5 (benötigt neueren yasm, der von Hand kompiliert werden muß)
- Linux Mint, Version 18.1
- openSUSE Leap Linux, Version 42.2 (lspci muß manuell zum Suchpfad hinzugefügt werden)
- Sabayon Linux, Version 16.11
- Slackware Linux, Version 14.2
- Ubuntu Linux, Version 16.10
Unterstützte BeOS Betriebssysteme:
- Haiku OS, Version hrev51051 (Sauberes Multithreading erst ab UNIX Alpha 17!)
Ausführung unter unixoiden Systemen mittels `$ ./bootstrap.sh`, danach Befolgen der Anweisungen auf dem Terminal.
Die Reduktion des 8K Speicherverbrauchs auf <= 16GiB RAM ist mit Beta 1 auf Windows und Alpha 16 auf UNIX abgeschlossen.
Aktuellstes Struktogramm: [Kurz vor Alpha 5] (PNG)
Weitere Struktogramme und Detailinformationen zu den Releases sind bitte dem Gesamtverlauf des Threads zu entnehmen!