Beiträge von Archimedes1

    So, jetzt wird die Sache interessant. Ich habe jetzt noch mal einen kurzen DV-Clip, einen Radfahrerverfolgungsschwenk, mit verschiedenen Encodern bei einer mittleren Bitrate von 6500 kbps in 2 Durchgängen enkodieren lassen. Die resultierenden Videos waren dann auch annähernd gleich groß.


    Bei der Ermittlung des durchschnittlichen SSIM-Wertes (über alle 169 Frames) kamen für die einzelnen enkodierten Videos folgende Ergebnisse zustande:


    Cinema Craft Encoder Basic
    Q in Y: 0,942


    HC
    Q in Y: 0,9448


    Canopus Procoder Express
    Q in Y: 0,9509


    QuEnc
    Q in Y: 0,9519


    Bei der Analyse habe ich mir diesmal alle ermittelten SSIM-Werte protokollieren lassen. Daraus ist dann diese Grafik entstanden. Mir ging es dabei nur um den Verlauf der SSIM-Werte.



    Das macht mich jetzt aber doch ein bisschen stutzig. Zwar liefert das HC-Video einen minimal besseren Durchschnittswert als das CCE-Basic-Video, jedoch fallen die Ausreißer nach unten in der Grafik schon auf (der HC gleicht das aber wieder mit anderen guten Frames aus). Bei den anderen Encodern gibt’s keine solchen extremen Ausreißer. Wie auch immer, für mich war bis dato eigentlich immer der Durchschnittswert entscheidend – den SSIM-Werten vertraue ich mittlerweile durchaus -, aber vielleicht sollte man auch den Verlauf der Kurve mit berücksichtigen. Man müsste vielleicht auch noch anderes DV-Material testen.

    Bei all den DV-Clips, die ich durch den HC gejagt habe, so richtig Negatives kann ich über ihn eigentlich nicht berichten. Im Gegenteil, der HC produzierte immer sehr gute Werte (SSIM). Die ermittelten Werte (Durchschnittswerte über alle Frames) waren stets besser als beim Cinema Craft Encoder Basic und TMPGEnc (auch im CQ-Modus). Ich gebe bei solchen Analysen auch immer Acht auf einzelne Ausreißer - HC fiel diesbezüglich nicht mehr aus dem Rahmen als andere Encoder.


    Unabhängig davon, solche Ausreißer, wie auf dem Bild zu sehen sind (die Verblockungen), habe ich beim Procoder Express an einzelnen Frames (B-Frames) auch schon gesehen, aber auch bei anderen Encodern.

    Das ist jetzt zwar nicht repräsentativ, aber ich habe vor kurzem einen einminütigen Ausschnitt aus einem mittelalterlichen Festumzug – die Kamera war dabei auf einem Stativ befestigt und die Leute gingen an der Kamera vorbei - einmal mit dem Procoder Express und einmal mit dem HC enkodieren lassen. Beide Male mit einer mittleren Bitrate von 6500 kpbs und einer maximalen Bitrate von 8500 kpbs. Enkodiert wurde in 2 Durchgängen. Die resultierenden Dateien waren auch annähernd gleich groß. Neben einer SSIM-Analyse habe ich auch den BitRate Viewer verwendet.


    Das HC-Video zeigt dabei eine auffällig hohe Quantisierungskurve. Beim Procoder Express war diese bei weitem nicht so hoch. Die SSIM-Werte dagegen – denen ich mittlerweile durchaus vertraue – waren dagegen nicht auffällig. Der HC zeigte gute Werte (Q in Y: 0,9576), der Procoder Express etwas bessere (Q in Y: 0,9606). Auch war in den 1500 untersuchten Frames im HC-Video kein einziger Ausreißer diesbezüglich dabei.


    Canopus Procoder Express


    HC

    Bei DV-Material würde ich die mittlere Bitrate auf mindestens 6500 kbps, die maximal Bitrate auf 8500 kpbs setzen. Bei DV-Material kann ich zu mindestens nicht bestätigen, dass der HC kleinere Dateien produziert – er bewegt sich diesbezüglich auf der Ebene mit dem Procoder Express und dem Cinema Craft Encoder Basic.


    Was die Qualität als solche anbelangt, kann ich nur zahlreiche Eindrücke wiedergeben, die ich beim Vergleich von verschiedenen Encodern auf der Grundlage von DV-Material gewinnen konnte. Dabei schnitt der HC z. B. definitiv besser ab als der Cinema Craft Encoder Basic. Bei dem einen oder anderen Testszenario war er häufig sogar die Nummer 2 hinter dem Procoder Express (QuEnc schnitt eigentlich besser ab, ist aber quälend langsam). Ich hatte aber mal einen Fall mit einem sehr schwierigen und stressigen Ausgangsmaterial, da ging die Qualität des HC dermaßen in den Keller, dass ich etwas, wie soll ich sagen, perplex war. Ich hab’ das aber nicht mehr weiter verfolgt, da das Ausgangsmaterial wirklich sehr unüblich war.

    Jetzt wollte ich dir schon ein kleines, schnuckeliges und für den Privatgebrauch kostenloses Backup-Programm mit dem Namen Z-Dbackup empfehlen, aber da lese ich, dass du etwas anderes suchst.


    Im "privaten Umfeld" mache ich diese Komplettsicherungen schon lange nicht mehr. Ich sichere nur noch meine eigenen Dateien, und zwar mit dem eben genannten Programm. Damit lassen sich die Sicherungen auch per FTP auf einen anderen Rechner übertragen. Im Übrigen hat eine Neuinstallation beizeiten auch was Gutes. ;-)

    Danke auch noch mal von meiner Seite für die Erläuterungen. Ich wollte jetzt zwar noch ein paar Anmerkungen zum Umgang mit Metriken aus eigener Erfahrung schreiben, aber da dies nicht mit ein paar Sätzen abgetan ist, reiche ich das evtl. ein anderes Mal nach. ;-)

    Ich muss ehrlich gestehen, dass ich die Publikation "Image Quality Assessment: From Error Visibility to Structural Similarity" von Zhou Wang nicht hundertprozentig verstanden habe – mir ging es eher um die korrekte Implementierung der SSIM-Metrik. Speziell die Erklärung zur "11 x 11 circular-symmetric Gaussian weighting function" ist mir noch nicht ganz klar. Alle mir bekannten Programme dürften allerdings mit den sog. „Sliding Windows“ arbeiten, das sind 8 x 8 große Fenster, die alle möglichen Positionen innerhalb eines Bildes einnehmen, und für jedes dieser Fenster wird der dazugehörige SSIM-Wert ermittelt. Aus der Gesamtsumme aller ermittelten SSIM-Werte wird dann der Durchschnittswert für das gesamte Bild ermittelt.


    Soweit ich das getestet habe, ist der SSIM-Wert bei Video Quality Studio (VQS) ein gewichteter Wert (nach Helligkeit). Die Ergebnisse stimmen exakt mit denen von Fritz Framalyzer überein (Q in Y). MSU Video Quality Measurement Tool verwendet keine Gewichtung bei der Berechnung des SSIM-Wertes.


    Informationen zu VIF gibt es übrgigens auch hier:
    http://live.ece.utexas.edu/research/quality/VIF.htm

    Neben der SSIM-Metrik sollte die VIF-Metrik nicht unerwähnt bleiben. VIF steht für „Visual Information Fidelity“ und soll – laut den Entwicklern – noch zuverlässigere Ergebnisse liefern, als die SSIM-Metrik.


    Eigentlich wurde die SSIM-Metrik lediglich anhand von Graustufenbilder entwickelt und ausgiebig getestet. Die Ausweitung auf Farbe liegt bis dato lediglich als Theorie vor und wurde bis jetzt noch nicht ausgiebig getestet – so teilte es mir jedenfalls der Entwickler der SSIM-Metrik, Zhou Wang, mal in einer E-Mail mit, da ich gerade mit der Implementierung der SSIM-Metrik beschäftigt war. Bei der Analyse genügt es also vollkommen, wenn man nur den Luminanzanteil betrachtet. Die SSIM-Metrik gibt’s im Übrigen auch noch in einigen Spielvarianten, z. B. mit Gewichtung nach Helligkeit (dunklere Bereiche werden weniger bzw. gar nicht bewertet) oder mit Gewichtung aufgrund von Bewegungsvektoren (Frames mit viel Bewegung erhalten weniger Gewichtung).

    Zudem halten sich auch nicht alle Mpeg-2-Encoder sklavisch an die gemachten Vorgaben. Das hängt desweiteren auch mit dem zugrunde liegenden Quellmaterial zusammen. Auch ein Procoder Express schießt diesbezüglich (max. Bitrate) schon mal über das Ziel hinaus. Entscheidend ist die Abspielbarkeit.

    Die Frage nach Alternativen zum MeGUI habe ich mir auch schon gestellt. Als ich auf meinem Notebook Microsoft Framework .NET 2 installierte, ließ sich Delphi nicht mehr starten. Habe somit die alte 1.1-Version wieder installiert. Jedoch konnte ich die neuere Framework-.NET-Version dann auf einem anderen Rechner installieren, ohne dass ein anderes Programm in Mitleidenschaft gezogen wurde, so dass ich wenigstens da in den Genuss der neueren MeGUI-Versionen komme. :-)


    Auf dem Notebook verwende ich eine Version von MeGUI, die noch unter Framework .NET 1.1 lauffähig ist.

    Jetzt muss ich den Thread hier doch noch einmal aufwärmen. Mittlerweile beherrscht Fritz Framalyzer auch AviSynth-Scripte und Batch-Verarbeitung (damit lassen sich mehrere Videos in einem Rutsch analysieren). DGMPGDec benutze ich mittlerweile auch, um Mpeg-Dateien innerhalb von AviSynth zu öffnen. Mit MPEGDecoder hatte ich mitunter so meine Schwierigkeiten. Zum Beispiel hatte ich Probleme, innerhalb von AviSynth bestimmte Frames damit anzufahren. Mit DGMPGDec gab es diese Probleme nicht mehr. :-)

    Sollte man tatsächlich in die Verlegenheit kommen, interlaced Material nach interlaced H.264/AVC zu enkodieren, so führt wohl kein Weg an Nero Recode 2 vorbei, wenn wir die wesentlich teueren Lösungen mal außen vor lassen.


    Ich habe den Clip jetzt noch mal deinterlaced (via AviSynth) den beiden Encodern angeboten. Dabei ist mir zu meiner Schande etwas aufgefallen. Ich habe hier ja immer die I-Frames (1. Frame einer neuen Szene) betrachtet – und die waren bei Nero Recode 2 in der Tat stets besser. Deswegen sind mir diese „softigen Bereiche“ im gleichen Frame beim x264-Video auch so aufgefallen. Anhand der ermittelten SSIM-Werte über alle Frames war aber schon klar, dass das gesamte x264-Video die Nase vorne hatte. Als ich dann begann, die nachfolgenden Frames einer Sichtanalyse zu unterziehen, stellte ich fest, dass auch Nero diese Bereiche „softet“. Ich habe da wohl zu viel erwartet - auch H.264/AVC kann nicht zaubern. Danke aber schon mal für die Unterstützung.


    Bleibt noch die Frage, wenn der x264-Encoder interlaced Quellen nicht unterstützt, was macht er, wenn er eine interlaced Quelle zum Verarbeiten bekommt? Deinterlacen im eigentlichen Sinn wird er wohl nicht?

    Also, zunächst einmal, wenn man bei Nero Recode 2 die Option „DVDs und Videos zu Nero Digital recodieren“ auswählt, kann man im nächsten Fenster, nachdem man ein Video importiert hat, unter „Video“ auch das Deinterlacen deaktivieren (bei interlaced Material ist die Voreinstellung immer "deinterlacen"). Ist die Quelle bereits progressiv, erkannt das Nero und deinterlacing ist automatisch deaktiviert.


    Wenn’s von Interesse ist, könnte ich natürlich auch den kompletten Clip (ca. 115 MB) hochladen. Die Datenrate hat bei Nero Recode 2 schon gestimmt – die resultierenden Dateien waren dann auch fast gleich groß.


    Zitat

    Properly dealing with adaptive interlacing in all cases takes lots of code. x264 doesn't support interlacing.


    Das erklärt natürlich so manches. ;-) Werde den Clip via geändertem AviSynth-Script nochmal durch beide Encoder jagen.

    Auch mit der aktuellsten Version („x264 core:44 svn-411“) zeigen sich diese „softigen“ Bereiche.


    Unter MeGUI x264 0.2.3.2033 habe ich das Profil „HQ-Slow“ geladen und die Bitrate auf 6500 kbps eingestellt.


    C:\Programme\x264\x264.exe --pass 2 --bitrate 6500 --stats ".stats" --ref 5 --bframes 3 --b-pyramid --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --progress --no-psnr --output "C:\Temp\video\video.mp4" "C:\Temp\video\video.avs"


    Zwar bescheinigen mir die via AviSynth ermittelten SSIM-Werte bessere Zahlen für das komplette x264-Video (das Testvideo hat eine Länge von 32 Sekunden) gegenüber dem Nero-Recode-2-Video, doch fallen diese „softigen“ Frames dann doch etwas aus der Reihe, wie ich finde. Bei den mit Nero Recode 2 enkodierten Videos sieht man sogar noch das Rauschen der Camcorder-Aufnahme! Zugegeben, das Material ist alles andere als „stressfrei“. Man muss dem x264-Encoder schon mindestens 5000 kbps Bitrate zur Verfügung stellen (hängt natürlich stark vom Quellmaterial ab), damit das resultierende Video in etwa das Niveau eines guten Mpeg-2-Videos mit 6500 kbps Bitrate (VBR, 2-pass) hat (getestet mit dem Procoder Express).


    Procoder Express, 6500 kbps

    Ich habe vor kurzem (zu Testzwecken) ein paar DV-AVI-Videos durch den x264-Encoder gejagt. Als Profil habe ich „HQ-Slow“ mit einer Bitrate von 6500 kbps verwendet. Dabei sind mir im fertigen Video ein paar „unschöne“ Stellen aufgefallen.


    Ein Ändern der Deblocking-Werte auf (-3, -3) oder (-6, -6) brachte keine nennenswerte Verbesserung. Auch ein Deaktivieren des Deplocking-Filters brachte nicht viel.


    Zum Vergleich habe ich auch das Resultat von Nero Recode 2 hier mit angefügt. Die Bildausschnitte stammen aus dem ersten Frame einer neuen Szene und sind 150 % vergrößert worden.


    Original


    X264, Profil „HQ-Slow“, 6500 kbps


    Nero Recode 2, 6,52 Mbps