AVC-Encoding-Qualität testen

  • Ich bin noch unschlüssig, ob ich meine AVCHD-Aufnahmen schon bearbeiten und damit alles komplett neu kodieren soll oder ob ich auf eine funktionierende Smart-Rendering-Lösung warte. Wenn ich allerdings denke, wie lange das schon bei MPEG-2 gedauert hat, bis es was gegeben hat... :(

    Entscheide ich mich also doch, jetzt loszulegen, will ich natürlich den besten und nicht den schnellsten Encoder verwenden, da ja AVCHD in den Camcordern (auch meinem Canon HF100) doch bereits arg am Limit arbeitet. Einen aktuelleren AVC-Codec-Vergleichstest gibt es derzeit nicht, und in der aktuellen c´t geht es wohl mehr um Geschwindigkeit - demnach hätte der x264, dort nur mit Single-Pass als Referenz-Codec verwendet, zu den schlechtesten Encodern gehört.

    Jetzt komme ich allerdings beim AVISynth-Script zum Vergleichen von AVC-Encodern arg in´s Schleudern - einerseits wegen der Farbräume, andererseits wegen des AVC-Decoders.

    So sieht mein Script derzeit aus:

    Code
    V1=ImageSource("D:\Elephants Dream\%05d.png", start=620, end=5114, fps=25.000)
    V1=ConvertToYV12(V1)
    V1=ConvertToYUY2(V1)
    V2=DirectShowSource("D:\Elephants Dream\Elephants Dream - 1080p25_8000.264")
    V2=ConvertToYUY2(V2)
    R=Compare(V1,V2)
    return R

    Wie zu erkennen, verwende ich die Original-Einzelbilder von "Elephants Dream". Diese wurden vor der Codierung mit x264 (bzw. MeGUI) in YV12 verwandelt, weshalb ich das auch hier mache, bevor ich es wie den eigentlichen AVC-Film der Einheitlichkeit wegen in YUY2 wandle.
    Der Film wird schließlich per DirectShowSource dekodiert - hier sorgt wohl ein irgendwann (mit-)installierter MainConcept-"Consumer"-Codec für die Dekompression in YV12 (oder ist es etwa der von DivX 7?).

    Die Overall PSNR liegt mit rund 43 db in den ersten 20 Sekunden im c´t-Rahmen, was mir das Gefühl gibt, richtig zu liegen, aber dennoch bin ich damit noch nicht ganz 100%ig zufrieden, v.a. wegen des MainConcept-Codecs - mir wäre eine Alternative lieber.
    FFVideoSource öffnet das File anscheinend nicht korrekt (startet nicht zu Beginn der Videosequenz, sondern erst fast am Schluss), DGAVCDec scheint grundsätzlich eine YUV-RGB-Konvertierung durchzuführen - ersetze ich oben ConvertYUY2 gegen ConvertRGB32 sind die PSNR-Werte schlechter.

    Habt Ihr irgendwelche Tipps?

  • DGAVCDec konvertiert mit Sicherheit nicht zu RGB, sondern gibt YV12 aus, weil MPEG4-AVC-Video im Main-Profile und meist auch in High-Profile sowieso YUV mit Chroma-Subsampling 4:2:0 speichert. Das Hin-und-her-Konvertieren des PNG-Videos ist insofern etwas daneben.

    Dass du schlechtere Werte bekommst, kann daran liegen, dass eine Beschränkung des Wertebereiches im YUV-Farbraum nicht beachtet wird (PC/TV-Scale = 0-255/16-235, Parameter "coring" bei einigen Funktionen).

    PSNR ist davon abgesehen auch eine Metrik, die nicht besonders nah am menschlichen Empfinden ist. SSIM ist hier etwas geeigneter.

    Aber letztendlich kann so etwas subjektives wie die "Qualität" eigentlich nur zuverlässig in ABX-Tests mit hunderten Teilnehmern beurteilt werden.

  • Ums kurz zu machen: nimm x264. Damit hast du sicherlich den aktuell mit Abstand besten freien H.264-Encoder und insgesamt einen, der zumindest ganz oben in der Spitzengruppe mitmischt.

    Keine Ahnung, was die c’t da getestet hat. Online steht das nicht zufällig?

    Brother John
    ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
    DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!

  • Getestet wurden ausdrücklich "Schnelle H.264-Encoder" (1-pass, möglichst unter Nutzung von Beschleunigerfunktionen, evtl. CUDA/Stream, PS3-Cell o.ä.).

    Es wurde dort zwar erwähnt, dass x264 als Referenz zum Vergleich verwendet wurde; mehr Details dazu habe ich beim kurzen Überfliegen aber nicht finden können. Insbesondere der Hinweis "siehe Tabelle" führt bei mir zur Verwirrung, denn bei den Endergebnissen taucht x264 nicht in der Tabelle auf.

  • In dem c't-Test wurde auf 2- oder n-Pass-Kodierung verzichtet.
    Das Testmaterial (Full-HD-Film) wurde für den Referenzwert mit x264 (ohne Hardware-Beschleunigung) kodiert.
    Die Ergebnisse der Testkandidaten wurde mit dem x264 verglichen.

    Jetzt mal eine blöde Frage.
    Ich benutze seit Jahren TMPGEnc zum Konvertieren von Videomaterial und habe immer die 2-Pass-VBR-Kodierung eingestellt. Und war bisher auch der Meinung, dass diese Einstellung sichtbar besser ist, als die 1-Pass-CBR-Kodierung.
    Lohnt sich dieser Zeitaufwand ?
    Nach dem c't-Test anscheinend nicht.

    JP

    Edited once, last by LigH: x264: Kleines 'x'! (September 16, 2009 at 8:37 AM).

  • Kommt drauf an.

    Bei reichlich Bitrate (wenn der Durchschnitt schon bei >70% des Maximums laut Spezifikation liegt, also auch bei VBR nur noch geringe Schwankungen möglich wären) spielt es keine große Rolle.

    Interessant wird es, wenn die Bitrate knapp wird, insbesondere wenn eine eher geringe Zielgröße erreicht werden muss. Dann ist eine Anpassung an die Komplexität des Videoinhaltes unbedingt zu empfehlen.

    Aber insbesondere wenn die Zielgröße keine erhebliche Rolle spielt, gibt es heute schon 1-pass-VBR-Lösungen, die 1-pass-CBR überlegen sind - gerade weil sie sich an Qualität statt an Bitraten orientieren.

  • Getestet wurden ausdrücklich "Schnelle H.264-Encoder" (1-pass, möglichst unter Nutzung von Beschleunigerfunktionen, evtl. CUDA/Stream, PS3-Cell o.ä.).

    Es wurde dort zwar erwähnt, dass x264 als Referenz zum Vergleich verwendet wurde; mehr Details dazu habe ich beim kurzen Überfliegen aber nicht finden können. Insbesondere der Hinweis "siehe Tabelle" führt bei mir zur Verwirrung, denn bei den Endergebnissen taucht x264 nicht in der Tabelle auf.

    Ja, ich war auch sehr verwirrt über den Test, gerade weil x264 erwähnt aber nirgendwo weiter aufgetaucht ist. Irgendwie komisch.
    Schade, denn mich hätte gerade das vergleichen mit x264 mit den anderen Encodern sehr interessiert...

    bzw. bin mal gespannt ob aus https://sites.google.com/site/x264cuda/Home mal was wird...

  • Quote

    Ja, ich war auch sehr verwirrt über den Test, gerade weil x264 erwähnt aber nirgendwo weiter aufgetaucht ist. Irgendwie komisch.

    In der Tabelle unter Bildqualität Film 1080p gibts PSNR und SSIM Werte des Encoders.
    Zum Vergleich gibts als Fussnote 2 die PSNR/SSIM Werte des x264 Encodings:
    PSNR 43,84 dB; SSIM 82,27

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!