X-QuaSaT - x264 settings quality/speed/bitrate analysation tool

  • Hallo allerseits,


    habe ein kleines Tool entwickelt, mit welchem man eine Speed/Qualitäts-Analyse für x264 settings durchführen kann.
    Es verändert die Parameter der settings vollautomatisch innerhalb der Grenzen, die definiert werden und kombiniert alle möglichen Parameter
    miteinander:


    ---- >>> X-QuaSaT <<< ----
    [x264 Quality and Speed analyse Tool]


    Man verwendet ein paar Video-Clips, die man testen möchte und packt sie ins "VIDEOFILES" Verzeichnis des tools.
    X-QuaSaT soll einem jetzt dabei helfen, die optimalen persönlichen Einstellungen zu finden, das beste Speed/Quality-Verhältnis herauszufinden und die CPU optimal auszulasten.
    Dazu werden Key-Features wie:


    - quantization
    - reference-frames
    - b-frames
    - motion estimation
    - Psy-rate distortion/trellis


    in Schleifen autom. Schritt für Schritt erhöht, und mit allen anderen Parametern, die man festlegt kombiniert.
    Es lässt sich festlegen, in welchem Bereich das/die settings getestet werden sollen und in welchen Schritten der Parameter erhöht werden soll.


    Es wird dann ein statistic-file erzeugt, welches die getesteten setting-kombinationen und folgende ergebnisse festhält:
    - CPULOAD
    - AvgPSNR
    - SSIM
    - FPS
    - BR (Bitrate)
    - Durchschnittl. Anzahl verwendete B-frames (BF_USED)
    -
    Durchschnittl. Anzahl verwendete of P-frames (PF_USED)
    -
    Durchschnittl. Anzahl verwendete of I-frames (IF_USED)
    (es wird jeweils immer der Durchschnittswert aus allen verwendeten Test-Clips ermittelt und in einer Zeile des statistic-files festgehalten)


    Bei Bedarf können die temporär erzeugten video-clips erhalten werden, falls man nach einem Blick ins statistic-file sich diese genauer anschauen möchte.


    Weitere einstellbare Parameter sind:
    - Pixel motion
    - Pixel search range
    - Trellis quantization
    - Encodingmode
    - Adaptive quantization mode
    - Adaptive quantization strength


    SCREENSHOT MAIN MENUE:


    DOWNLOAD / WEBSITE HIER (ENGLISCHER MAIN-THREAD):
    http://forum.selur.de/topic193…e-tool-download-here.html


    freue mich über Feedback


    mogobime

  • Changelog 1.06.07 (19.07.2012):


    - Durchschnittl. Anzahl verwendeter P+I-frames werden nun im Statistik-file angezeigt
    - Startzeit im Recover-Mode wird jetzt korrekt angezeigt
    - Diverse Code-Optimierungen

  • :welcome:
    und :daumen: erstmal ... bisher war es ja nur eine PN wegen der Freischaltung.


    Ich hoffe sehr, dass ein paar unserer erfahreneren Mitglieder (z.B. Brother_John und v.a. Selur) etwas Zeit finden, dieses Projekt zu begutachten. Allerdings sieht es erst mal danach aus, dass es nicht gerade besonders stromsparend ist... ;)

  • Zitat

    Allerdings sieht es erst mal danach aus, dass es nicht gerade besonders stromsparend ist...


    Die letzte große Analyse, die ich jetzt geuppt habe (REF_5-11;BF_3-9;QUANT_19-21;SUBME_7-9;ME_auto;MERANGE_auto.CSV) hatte eine Berechnungszeit von knapp 72h bei 6x4,1Ghz
    Sind allerdings auch 441 Analyse-Ergebnisse im csv-file, die mit fünf Testclips (XViD/x264 in SD/720p/1080p) erstellt wurden.


    Zitat

    Ich hoffe sehr, dass ein paar unserer erfahreneren Mitglieder (z.B. Brother_John und v.a. Selur) etwas Zeit finden, dieses Projekt zu begutachten.


    Selur hat mir während der Entwicklung wertvolle Anregungen gegeben und als Beta-Tester fungiert, wofür ich ihm sehr dankbar bin :ja:

  • Habe noch einen Download-Link zu netload hinzugefügt, da ein user gemeldet hatte, dass er den ftp-link nicht nutzen kann.
    Der FTP-link sollte aber trotzdem funktionieren, und ist auch schneller.

  • Ich habe auch Probleme, diese Datei per FTP herunterzuladen. Ich bekomme 1,5 KB, dann ist Ende; mit einem FTP-Client sehe ich nur ein leeres Verzeichnis. Bei Selur müsste ich angemeldet sein, um den Anhang laden zu dürfen. Und bei netload muss ich warten, und dann noch mal warten, und dann noch eine angebliche MKV-Datei umbenennen ...


    Vorschlag: Ich richte auf meinem Webspace einen FTP-Zugang mit Passwort ein, wo du Dateien hochladen kannst, die dann öffentlich per HTTP herunterzuladen sind (www.ligh.de/software/X-QuaSaT/...).
    __


    P.S.: Problem -- deine Batchdatei erkennt nicht, ob x264.exe korrekt ausgeführt wird. Sie rattert auf meinem Windows 7 32-bit durch, ohne zu bemerken, dass deine mitgelieferte x264.exe 64-bit darauf gar nicht läuft.

  • Die download-Probleme sollten jetzt beseitigt sein.
    Werde auf dein Angebot zurückkommen, vielen Dank :)


    Werde mir jetzt mal Gedanken machen, wie ich das mit dem 32Bit-Support mache, ob es zwei Versionen geben wird, oder ob ich x264 2x beipacke...

  • Vergiss nicht, den Titel im Mirror-Index auch anzupassen. ;)


    Ich hab mal das Skript ohne Änderungen am Sintel-Trailer durchlaufen lassen. Was mir noch nicht ganz klar ist: Welche der Änderungen an den Parameterbereichen könnten dich oder wen-auch-immer interessieren?


    Ich stelle gerade fest: Vielleicht hätte ich auf CSV-Ausgabe umschalten sollen. Die LOG-Ausgabe sieht nicht so aus, als ließe sie sich einfach weiterverarbeiten.

  • Hab ich übersehen, werd die Versionsnummer morgen mal anpassen, bin gerade nicht bei mir am Rechner.


    Verstehst du das mit den STEP-settings? Mir ist schon klar, dass das Tool nicht so leicht auf Anhieb zu durchschauen ist, also frag ruhig.


    Setzt man die Parameter 0, 2, 4, 6 und A auf "STEP", kann man bei den jeweils direkt darunter liegenden ...LOOP-Parametern den Bereich von...bis einstellen, der getestet werden soll.
    Es werden dann alle erdenklichen Kombinationen durchgetestet. -> man sollte immer einen Blick auf die anzeige im Menü werfen, welche die Anzahl der notwendige Analysevorgänge pro file anzeigt.
    Wenn mann z.B. eh immer Quantizer "20" und SUBME "9" verwenden will, sollten diese natürlich nicht auf "step" sondern eben auf "20" bzw. "9" stehen.


    Des weiteren habe ich bei ME, MERANGE + TRELLIS eine Automatik-Funktion eingebaut, welche aktiv wird wenn bframes>refframes ist und die CPU-Auslastung niedrig ist. Sie schaltet dann:
    1. ME von umh -> esa
    2. MERANGE von 24 -> 32
    3. TRELLIS von 0 -> 2
    und zwar genau in dieser Reihenfolge, und versucht so die CPU besser auszulasten.
    Man bekommt also in der Regel einen Qualitätsgewinn und verliert dabei keine Geschwindigkeit.


    Die CPU-Auslastung kann zum Teil erheblich einbrechen, wenn BFRAMES>REFFRAMES eingestellt sind, und deshalb macht das imho nur Sinn, wenn man mindestens ME+MERANGE erhöht und zwar genau in dieser Reihenfolge.
    ME+MERANGE zu erhöhen steigert nämlich im Falle niedriger CPU-Auslastung i.d.R. die Qualität, ohne die Filesize anwachsen zu lassen oder die Encodinggeschwindigkeit großartig zu senken, da einfach "brachliegende" CPU-Kapazität genutzt wird.


    Bei Trellis sieht es etwas anders aus: Es lässt die Filesize immer etwas ansteigen, weswegen ich es in der Regel auf 0 stelle und meine eigene Automatik-Funktion nicht verwende.


    Das sind meine Erkenntnisse, die ich beim bauen+Testen des tools gewonnen habe und ich erhebe keinerlei Anspruch auf Allgemeingültigkeit.
    Da muss jeder der Spaß dran hat und eine starke CPU sein eigen nennt ;) selber rausfinden, was für ihn das richtig ist.
    Was wen interessiert kann ich natürlich auch nur schwer sagen...

  • Wie man Einstellungen anpassen kann, wird schon rauszukriegen sein.


    Mir geht es eher darum, welche Parameter-Änderungen wohl interessanter sein könnten als andere. Wenn alle variabel sind, wird der Variablenraum zu multidimensional, um die Ergebnisse noch nützlich darstellen und vergleichen zu können.


    Mit den Standardeinstellungen dürfte der Nutzen des Programms also eher eingeschränkt sein. Und letztendlich muss man sich auch noch eine Interpretation für die Ergebnisse überlegen. Vielleicht gibt es ja unterschiedliche Ansichten darüber, welche Beziehung zwischen Dateigröße und Framerate optimal ist.

  • Zitat

    Wie man Einstellungen anpassen kann, wird schon rauszukriegen sein.


    Schreibe das hier auch ein bisschen für alle ;)

    Zitat

    Vielleicht gibt es ja unterschiedliche Ansichten darüber, welche Beziehung zwischen Dateigröße und Framerate optimal ist.


    Na klar. Interessant sind natürlich immer einstellungen, die bei gleichbleibendem/höheren Encoding-Speed am Ende einen hohen SSIM bei niedriger filesize ergeben, eierlegende Wollmilchsäue halt ;)

    Zitat

    Wenn alle variabel sind, wird der Variablenraum zu multidimensional, um die Ergebnisse noch nützlich darstellen und vergleichen zu können.


    Aus den Daten/Teilen der Daten ein paar excel/ods-Diagramme zu basteln, die die Parameter SSIM/BITRATE/FPS veranschaulichen wäre sicher hilfreich, leider bin ich da nicht so der Held drin...


    Habe gerade wieder 2 umfangreiche Statistiken, welche einmal bei SUBME 9 und einmal bei SUBME 7 die Auswirkungen verschiedener Parameter + Auto- me/merange/trellis zeigen.
    Meine Tests habe ich bisher so angelegt, dass ich 5 Testsamples in x264 + XViD in verschiedenen Auflösungen von 720p-1080p gemischt hatte um möglichst allgemeingültige (jetzt sag ichs ja doch :ani_lol:) Ergebnisse zu bekommen.
    Interessant wäre aber vielleicht auch mal ein Vergleich unterschiedlicher Input-Codecs, um z.B. festzustellen, ob sich bei XViD-Input Trellis=2 eher lohnt als bei x264 oder AQ-Mode=1 bei x264 bessere Ergebnisse liefert als bei XViD, oder bei XViD die CPU-Ausnutzung bei hohen B-frames Einstellungen mit niedrigen Ref-Frames besser ist, oder... (waren jetzt zum Teil erfundene Hypothesen...)


    Auch das Kosten/Nutzen-Verhältnis von Trellis (ohne psy-trellis) im crf-Mode bei verschiedenen settings kann man zumindest hinterfragen.
    Meiner Meinung nach kann man Trellis=1 im Grunde vergessen, da kann man auch gleich den Quantization-faktor senken.
    Statt Trellis=2 neige ich eher dazu B/Ref-frames etwas anzuheben.
    Aber ich habe natürlich da längst nicht genug Tests durchgeführt, um das wirklich zu belegen (falls so etwas überhaupt möglich ist).


    Zur Standardeinstellung: Die Standardeinstellung ist eigentl. eher dazu da, die Einstell-Möglichkeiten besser zu verdeutlichen. Hatte auch schon überlegt den Quantizer per default fest auf 20 einzustellen.


    Mehr fällt mir gerade auch nicht ein... Ist nicht ganz so einfach.:rolleyes_:
    Die meisten dürfte interessieren, wie sie in kurzer Zeit akzeptable Ergebnisse bekommen. Einige dürften wissen wollen, wie sie bestmögliche Qualität bekommen, ohne völlig unsinnig langsame settings zu verwenden.

  • Na klar. Interessant sind natürlich immer einstellungen, die bei gleichbleibendem/höheren Encoding-Speed am Ende einen hohen SSIM bei niedriger filesize ergeben


    Jein.


    SSIM ist zwar eine relativ gute Metrik zur Bestimmung eines Qualitätsverlustes. Aber es ist noch längst nicht die perfekte.


    Es wurde bereits relativ ausführlich darauf hingewiesen, dass man x264 zwar tunen kann, um möglichst optimale PSNR- oder SSIM-Werte zu erreichen. Aber x264 verwendet darüber hinaus auch noch psychovisuelle Bildoptimierungen, die zwar schlechtere PSNR- oder SSIM-Werte erzeugen, aber dennoch für den Betrachter angenehmer wirken können.
    __


    Die meisten dürfte interessieren, wie sie in kurzer Zeit akzeptable Ergebnisse bekommen. Einige dürften wissen wollen, wie sie bestmögliche Qualität bekommen, ohne völlig unsinnig langsame settings zu verwenden.


    Dann sollten sie als Einsteiger auch erst mal nur die Parameter "--preset" und "--tuning" verwenden. Alles darüber hinaus ist im Grunde nur für Fortgeschrittene, die wirklich verstehen, wie H.264 funktioniert.

  • Zitat

    Aber x264 verwendet darüber hinaus auch noch psychovisuelle Bildoptimierungen, die zwar schlechtere PSNR- oder SSIM-Werte erzeugen, aber dennoch für den Betrachter angenehmer wirken können.


    Es macht natürlich keinen großen Sinn eine Statistik, in der psychovisuelle Optimierungen verwendet wurden, mit einer in der diese nicht verwendet wurden zu vergleichen.
    Wohl aber kann man imho gewisse Tendenzen erkennen, wenn man beispielsweise psy-trellis anschaltet und andere Parameter per "step" ansteigen lässt.


    Aber genau aus den genannten Gründen gibt es auch die Möglichkeit, die erzeugten tmp-videos numeriert zu erhalten, damit man sie hinterher den Parametern im Statistic-file zuordnen und kritisch beäugen kann, wenn man Zweifel an den Aussagen über die Qualität hat.


    Zitat

    Alles darüber hinaus ist im Grunde nur für Fortgeschrittene, die wirklich verstehen, wie H.264 funktioniert.


    Muss ich dir größtenteils recht geben, die Halbfortgeschrittenen lernen vielleicht durchs rumtesten mit X-QuaSat und lesen in der eingebauten help-Funktion was dazu...

  • NEWS 02.11.2012:


    Puh, das war ein hartes Stück arbeit für mich und meinen Rechner.
    Auf jeden Fall ist jetzt der große Trellis-Vergleich mit html-Tabellen+Diagrammen, die auf X-QuaSat-Statistiken beruhen, endlich fertig auf meiner Website!
    Die Diagramme+Tabellen beziehen sich auf Quantizer 19+20 mit Trellis 0-2 (jeweils mit Reference-Frames 5-9 und B-Frames 3-11).
    Dabei habe ich nach einer Bewertungsmatrix mindestens die besten 3 Kandidaten nach Qualität, Speed und Bitrate sortiert markiert.
    Zusätzlich gibt es Balkendiagramme zu Qualität / Speed / Bitrate die sich auf alle ausgewerteten Kombinationen beziehen (Außreißer, die z.B. hohe Qualität durch überdurchschnittlich hohe Bitrate erzeugten wurden nicht berücksichtigt, Werte sind in Tabelle ausgegraut).


    Hoffe dass der ein oder andere was damit anfangen kann.


    Cu


    mogobime

  • Läuft bei vernüntiger Kühlung auf nem Asus M5A99X EVO (100€) und ein paar Anpassungen bei Vcore und VddnB locker mit 4,1 Ghz und dass mit 4x4GB Ram@1800Mhz :D
    Weiss nicht was ich für die Leistung bei Intel für Board+Prozessor gezahlt hätte...
    Benchmarks wurden aber alle @default erstellt.


    Die Website erstrahlt jetzt übrigens in neuem Glanz mit Return-Buttons überall...


    EDIT:
    Hab übrigens festgestellt, dass x264 spürbar von niedrigen RAM-Latenzen profitiert, also lieber den RAM bei 1T/unganged und einer CL-Stufe niedriger betreiben, als mit maximal hohem Takt.