Test: Auswirkung von Nicht-Mod16-Auflösungen auf die Encodereffizienz

  • Guten Morgen!

    Ich habe endlich wieder Zeit zum Testen! Und was ich schon länger genauer klären will, ist die Sache mit der Mod16-Regel. Beim anamorphen Encoding ist man ja öfter in der Situation, dass mod16 nicht wirklich hinhaut. Aber was nehmen? Mod8, mod4? Ganz was anderes? Darum dreht sich dieser Test. Als Encoder war Xvid im Einsatz. Ich würde schätzen, dass sich DivX und die anderen ausgereiften ASP-Encoder zumindest grob ähnlich verhalten. Schließlich arbeiten sie alle nach dem selben Standard.


    == Setup ==

    Allgemeines
    Ich habe zwei Samples in sechs verschiedenen Auflösungen getestet:
    Mod16, mod8, mod4+, mod4–, mod2+, mod2–
    Mod16 und mod8 sollten selbsterklärend sein. Dazu kamen mod4 und mod2 in jeweils zwei Varianten. Mod4+ bezeichnet eine Auflösung, die um 4 Pixelreihen größer ist als mod16, d.h. der Encoder muss intern 12 Pixelreihen dranpappen. Umgekehrt steht Mod4– für eine Auflösung, die um 4 Pixel kleiner ist als mod16, d.h. der Encoder muss intern 4 Pixelreihen dranpappen. Für mod2 gilt das gleiche analog.
    Die Überlegung hinter dieser Aufteilung war, dass der Effizienzverlust nicht unwesentlich davon abhängig sein dürfte, wie viele Pixel intern ergänzt werden müssen. Und dann lassen sich die je zwei Varianten von mod4 und mod2 nicht mehr über einen Kamm scheren. Die Zwischenvarianten mod16+6 und mod16–6 habe ich weggelassen, um den Test nicht ganz ausufern zu lassen.

    Das größte Problem bei einem solchen Test sind die notwendigerweise unterschiedlichen Auflösungen, was direkte Vergleiche trickreich werden lässt. Mehr dazu bei den Ergebnissen weiter unten. Um von Anfang an die Unterschiede klein zu halten, habe ich nur die vertikale Auflösung verändert. Horizontal war es immer mod16. Außerdem wäre anders der Mod2-Test problematisch geworden, weil YV12 horizontal mod4 benötigt.

    Ok, genug Gelaber. Kommen wir zu den harten Fakten.

    Sample 1
    10.000 Frames einer progressiven PAL-DVD, DAR 2,35:1, hauptsächlich Dialog, statische Hintergründe, einige langsame Kameraschwenks, etwa halbe-halbe bei hellem Tageslicht und in Räumen mit künstlicher Beleuchtung.

    Sample 2
    10.000 Frames einer anderen progressiven PAL-DVD, DAR 2,35:1, schnelle Actionszene, Feuergefecht, teils unter Wasser, hauptsächlich mit diffusem Tageslicht beleuchtete Innenräume.

    AviSynth-Skripte
    Sample 1

    Code
    [size=8]LoadPlugin("C:\Encoding\DGMPGDec\dgdecode.dll")MPEG2Source("E:\Video\Sample1.d2v")#natürlich jeweils nur eine Crop-ZeileCrop(8,80,-8,-80)   #704x416, mod 16Crop(8,76,-8,-76)   #704x424, mod 8Crop(8,78,-8,-78)   #704x420, mod 4+Crop(8,82,-8,-82)   #704x412, mod 4–Crop(8,78,-8,-80)   #704x418, mod 2+Crop(8,82,-8,-80)   #704x414, mod 2–[/size]


    Sample 2

    Code
    [size=8]
    LoadPlugin("C:\Encoding\DGMPGDec\dgdecode.dll")
    MPEG2Source("E:\Video\Sample2.d2v")
    #natürlich auch hier jeweils nur eine Crop-Zeile
    Crop(0,80,-0,-80)   #720x416, mod 16
    Crop(0,76,-0,-76)   #720x424, mod 8
    Crop(0,78,-0,-78)   #720x420, mod 4+
    Crop(0,82,-0,-82)   #720x412, mod 4–
    Crop(0,78,-0,-80)   #720x418, mod 2+
    Crop(0,82,-0,-80)   #720x414, mod 2–[/size]

    Encoder
    Xvid 1.1.2 Koepi und Xvid_Encraw 2007-02-03
    Konfiguriert nach Teegedecks HQ-58%-Preset, angepasst für CQ 3.

    Zitat

    xvid_encraw -i "Sample 1 Mod 16.avs" -avi "Sample 1 Mod 16.avi" -cq 3 -qtype 1 -qmatrix C:\Encoding\Matrizen\SixOfNine.xcm -qpel -bquant_ratio 162 -bquant_offset 0 -zones 0,w,1,O -vhqmode 4 -bvhq -progress 25 > "Sample 1 Mod 16.stats"


    == Ergebnisse ==

    Hier erstmal die Verteilung der Frametypen für beide Samples. Unterschiede wegen der verschiedenen Auflösungen waren zwar vorhanden, aber nicht der Rede wert.

    Sample 1
    I-Frames ~1 %
    P-Frames ~35 %
    B-Frames ~64 %

    Sample 2
    I-Frames ~3 %
    P-Frames ~49 %
    B-Frames ~48 %

    Und hier sind die richtig interessanten Zahlen (Grafiken sind auch nochmal ans Posting angehängt, damit sie nicht verloren gehen):

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample1.png]

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample2.png]

    Das Mod16-Encoding dient als Referenz. Alle Abweichungen beziehen sich darauf.
    Abw. A ist die reine Abweichung in der Dateigröße.
    Abw. B versucht, die Verzerrung wegen der unterschiedlichen Auflösungen zu kompensieren, indem die Flächenabweichung von der Dateigrößen-Abweichung abgezogen wird, d.h. Abw. B = Abw. A – Abw. Px. Mehr dazu gleich.
    Rang ist die Rangfolge der Nicht-Mod16-Auflösungen von niedrigem zu hohem Effizienzverlust, ermittelt anhand Abw. B.


    == Diskussion ==

    Erstmal fallen die deutlich unterschiedlichen Zahlen zwischen den beiden Samples auf. Aus den deutlich kleineren Abweichungen bei Sample 2 könnte man vermuten, dass Actionszenen besser mit nicht-mod16 zurechtkommen. Es wäre zwar sehr gewagt, das aus einem einzigen Test so zu verallgemeinern, aber man sollte das für zukünftige Tests mal im Hinterkopf behalten.

    Auch interessant: Die Rangfolge ist trotz der zahlenmäßigen Unterschiede die gleiche. Mod4– und mod2– schneiden am besten ab, mod8 liegt mitten drin und mod4+ und mod2+ bilden das Schlusslicht. Das bestätigt die Vermutung vom Anfang, nämlich dass der wichtigste Einflussfaktor auf den Effizienzverlust tatsächlich die Anzahl der Pixelreihen ist, die intern ergänzt werden müssen. Es widerspricht der landläufigen Meinung, dass mod16 perfekt wäre, mod8 noch akzeptabel und alles andere zu schlecht. Und das heißt, dass ich wohl demnächst das Encodingwissen anpassen muss.

    Die Rangfolge führt uns direkt zur Aussagekraft von Abw. B. Deren Berechnung unterstellt einen linearen Zusammenhang zwischen Bildfläche und Bitrate, d.h. 1% mehr Fläche = 1% mehr Bitrate, was so an und für sich erstmal Unsinn ist. Die Komplexität in einem Videobild ist ja alles andere als gleichverteilt. Gerade am Rand sollte man erwarten, dass wenig los ist und dementsprechend der Bitratenanstieg unterproportional ausfällt. D.h. meine lineare Rechnung ist eher ein Best-Case-Szenario. Deswegen solltet ihr auch nicht zu viel auf die exakten Zahlen geben – incl. der seltsamen Tatsache, dass manche Varianten sogar relativ kleiner sind als das »perfekte« mod16. Wichtig ist die Rangfolge der Mod-Varianten, was auch dem eigentlichen Sinn des Tests entspricht. In den Zahlen mag zwar ein Fehler drin sein, aber zumindest ist das ein systematischer, der die Rangfolge nicht wesentlich beeinflussen sollte. Vielleicht fällt ja jemandem auch noch eine bessere Möglichkeit ein, den Auflösungsunterschied zu kompensieren.


    == Fazit ==

    Der Test bietet einen ersten Eindruck, welches mod »günstig« ist, wenn mod16 mal nicht möglich ist. Mir reicht die Aussagekraft schon, um die Empfehlung »Mod16 oder alternativ mod8« umzuschmeißen. Worüber der Test nichts oder nur extrem bedingt etwas aussagt, ist die Höhe des Effizienzverlusts. Ich mag mich nur zu der Pi-mal-Daumen-Schätzung hinreißen lassen, dass zumindest bei hochqualitativen Encodings mit niedrigem Quantizer das mod der Auflösung nur eine sehr untergeordnete Rolle für die schlussendliche Qualität spielt.

    Soweit erstmal von mir. Kommentare? Ideen? Vorschläge?
    (Btw: Ein solcher Test mit x264 schwebt mir schon vor.)

  • Was mir so durch den Kopf schwebt beim Lesen des Beitrags:
    (-> ist eine Gedankliche, keine Logische Reihenfolge der Punkte ;))

    Zitat

    Ein solcher Test mit x264 schwebt mir schon vor.


    Nice, dabei solltest Du dann als weiteren Hinweis die PSNR&SSIM-Berechnungen an lassen. Ist zwar beides nur bedingt Aussagekräftig hilft aber vielleicht etwas um Schlussfolgerungen zu finden.

    Als einzigen 'Kritikpunkt' kommt mir spontan in den Sinn, dass ich nicht auf Mod-xy (!= mod16) resizen würde, wenn ich dadurch nicht auch mehr Pixel erhalte. Immer den Hintergedanken, dass mehr Pixel mehr Daten zur Interpolation bei größeren Flächen bieten. ;)
    Lässt man die modXY- - Fälle weg ist die allgemeine Empfehlung mod16, dann mod8, dann mod4, dann mod2 mit der erhaltenen Rangeinteilung übereinstimmend. (Rang 3-4)

    Was vielleicht interessant wäre als kleine Hintergrund Information wäre inwieweit die Anzahl der Pixel sich in Korrelation zur Dateigröße bei der Quelle verhält. D.H. wenn man die Auflösung einfach viertelt, viertelt sich dann auch die Dateigröße. Je nach dem wie stark hier die Schwankung ist, kann man vielleicht auch Vermutungen anstellen in wieweit die gezeigten Abweichungen vielleicht ganz alleine auf der Anzahl der Pixel und nicht auch irgendwelchen ModXY Variationen liegt. ;) (Den Punkt hast Du in Deiner Diskussion ja auch schon angeschnitten.)

    An sich fände ich es auch ich es auch interessanter, wenn keine Custom-Matrix benutzt wird, weil diese meist langsamere oder schnellere Szenen stärker begünstigen als die "Standardmatrizen".

    Falls Du das später bei Dir auf ne Seite packen willst, sollte man noch anmerken woher die Überlegungen stammen, dass man modXY nehmen soll den Stammen. (Stichworte: Hardwaresupport, Makroblockgröße, Makroblockaufteilungen.)

    An sich wäre es vielleicht interessant gewesen die Auflösung kleiner zu wählen als das Quellmaterial, dies hätte die Möglichkeit geboten zu testen wie sich modX im Vergleich zu modY in der Horizontalen/Vertikalen bei gleicher Pixelanzahl auf das Ergebnis auswirken. (Also auch Kombinationen wie horizontal mod8, vertikal mod16 oder Horizontal mod4 vertikal mod2.)
    Sicher ist dies ein künstlicher Fall, da man i.d.R. ja mehr Pixel durch modXY erhalten will, jedoch liefert es vielleicht einen weiteren brauchbaren Hinweis ob es eine verlässliche Empfehlung gibt.

    Interessant wäre vielleicht auch die Anamorphen-Optionen im MeGui-AvisynthScriptCreator zu vergleichen.

    Cu Selur

  • Zitat von Selur

    Als einzigen 'Kritikpunkt' kommt mir spontan in den Sinn, dass ich nicht auf Mod-xy (!= mod16) resizen würde, wenn ich dadurch nicht auch mehr Pixel erhalte.


    Resizing? Du meinst Cropping, oder? Im Test war ja nirgendwo ein Resizer dabei. Denn dann kann ich ja auch auf die nächste mod16 skalieren. Mir geht es oft so, dass ich auf mod16 croppe und dann noch ~2-4 Pixelreihen schwarz stehenbleiben. Das wäre genau der Einsatzzweck für die Minus-Mods. Wenn du es anders herum siehst – also von der nächstkleineren mod16, die ja zum vollständigen Entfernen der Balken nötig wäre, nach oben gerechnet – dann hast du auch bei den Minus-Mods mehr Pixel als bei mod16. Dann ist es halt nicht mehr mod16–2 und mod16–4, sondern mod16+14 und mod16+12.

    Zitat von Selur

    An sich fände ich es auch ich es auch interessanter, wenn keine Custom-Matrix benutzt wird


    Werd ich mal gegentesten.

    Zitat von Selur

    dies hätte die Möglichkeit geboten zu testen wie sich modX im Vergleich zu modY in der Horizontalen/Vertikalen bei gleicher Pixelanzahl auf das Ergebnis auswirken.


    Mir fällt keine Lösung ein, wie man ohne Resizing die Pixelanzahl genau gleich hält. Wo sind die Mathematiker? Geht sowas? Außerdem möchte ich lieber so nah wie möglich an einer realen Encodingsituation dranbleiben. Sonst taucht sofort die Frage nach der Übertragbarkeit auf. Ich hab auch was ausgebrütet. ;)

    Idee

    • Man nehme zwei benachbarte Mod16-Auflösungen und encodiere die (z.B. 704×416 und 704×432).
    • Annahme: Die Differenz in der Dateigröße steckt in den 16 zusätzlichen Pixelzeilen.
    • Teilt man die Differenz durch 16, weiß man, wie viele Bytes eine Zeile verbrät. Ok, »wissen« vielleicht nicht, aber man hat einen brauchbaren Anhaltspunkt.
    • Man encodiert dann alle Nicht-Mod16s so, dass sie eine Auflösung zwischen den beiden Mod16s haben.
    • Anhand der in den Nicht-Mod16s zusätzlich enthaltenen Zeilen kann man eine erwartete Dateigröße ausrechnen.


    Vorteil des ganzen: Man nimmt nicht mehr unsinnigerweise einen linearen Zusammenhang zwischen Bitrate und Fläche über das gesamte Bild hinweg an, sondern a) macht das nur noch für den schmalen 16er-Rand und b) hat einen realen Größenunterschied als Grundlage. Das sollte imo zu einigermaßen aussagekräftigen Zahlen führen.

    Ergebnis
    Selbes Encodingsetup wie im ersten Posting. Nur die Auflösungen von mod4– und mod2– musste ich anpassen. Das sieht dann so aus:

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample1_B.png]

    Legende:
    Abw. Byte: Wie oben der reine, unkorrigierte Unterschied in der Dateigröße im Vergleich zur kleinen mod16.
    Abw. Zl.: Abweichung der Bildzeilen-Anzahl (vert. Auflösung) zur kleinen mod16.
    erwartet Byte: Rechnerischer Erwartungswert der Dateigröße ausgehend von den errechneten Byte pro Zeile.
    EW = Bytegröße_mod16_klein + (abw_zeilen * byte_pro_zeile)
    erw. %: Prozentuale Abweichung der Erwartungswerte zur kleinen Mod16-Dateigröße.
    real %:Prozentuale Abweichung der tatsächlichen Dateigrößen zur kleinen Mod16-Dateigröße.
    Eff.verlust: Effizienzverlust in Prozentpunkten als Differenz zwischen real% und erw.%.

    Das Gesamtbild der ersten einfachen Rechnung bestätigt sich. Fehlen noch ein paar zusätzliche Samples, um eine größere Datenbasis zu bekommen.

    Sample 2 war ungeeignet für die Methode, weil die schwarzen Balken bei 428 vert. Pixeln vollständig verschwunden waren, d.h. ich hätte 400 als kleine und 416 als große mod16 nehmen müssen. Da aber 28 abgeschnittene aktive Pixel immerhin schon 6,5% sind, war mir die Gefahr zu groß, dass dadurch der 16er-Rand gar keinen Randcharakter mehr hat, sondern schon zu weit mitten drin im Bild liegt.

  • Ich hoffe sehr, du hast auch vor, das im englischen Forum anzusprechen... :daumen:

    Wirklich sehr interessant. Vielleicht läßt sich ja aus der Arbeitsweise eine Schlussfolgerung ziehen:

    Soweit mir bekannt ist, werden außerhalb der Bildfläche liegende Bereiche bis auf nächste Vielfache einer Makroblockgröße mit gespiegeltem Bildinhalt gefüllt. Bei der Encodierung kommt die DCT zur Anwendung, eine endliche Variante der Fourier-Transformation. Spiegelt man einen Luminanzblock (8x8 Bildpunkte) bei 4 Zeilen, bekommt der Inhalt eine exakte Spiegelsymmetrie. Das hilft der DCT ganz offensichtlich, effizient zu komprimierende Frequenzparameter zu erzeugen.

    Eigentlich sollten dann aber -mod4 und +mod4 gleich gute Ergebnisse bringen. Dass das offensichtlich gar nicht der Fall ist, muss Gründe haben, die wohl nur ein XviD-Entwickler erklären könnte.

  • Zitat

    Resizing? Du meinst Cropping, oder?


    Yo :)

    Zitat

    Mir fällt keine Lösung ein, wie man ohne Resizing die Pixelanzahl genau gleich hält. Wo sind die Mathematiker? Geht sowas?


    Nein, Resizing muss sein. ;)


    -> Idee ist sicher interessant :)

    Zitat

    Soweit mir bekannt ist, werden außerhalb der Bildfläche liegende Bereiche bis auf nächste Vielfache einer Makroblockgröße mit gespiegeltem Bildinhalt gefüllt.


    Soweit ich mich entsinne wird wiederholt und nicht gespiegelt. :)

    Cu Selur

  • Mahlzeit!

    Selur, für dich erstmal zum Vergleich Sample 1 mit H.263-»Matrix«
    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_sample1_h263.png]

    Im Moment läuft noch das Encoding mit einigen anderen Samples. Mein Rechner ist leider nicht mehr der allerschnellste. Vielleicht klappts bis heute Abend.

    In Sachen Auffüllen war ich bisher auch immer der Meinung, dass nur die letzte Zeile vervielfältigt und nicht gespiegelt wird. Die kompletten Ergebnisse stell ich jedenfalls dann auch ins englische Forum. Vielleicht sagt ja einer der Entwickler was dazu.

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

  • Und hier kommt die volle Breitseite. Setup wie oben, nur mit (bis auf Sample 1) VHQ 2, damit es nicht gar so ewig dauert.

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_s1.png]

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_s3.png]

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_s4.png]

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_s5.png]

    [Blockierte Grafik: http://brother-john.net/files/mod-test_xvid_s6.png]

    Das bestätigt das bisherige Bild. Denk ich ... Ich brauche erstmal ein bisschen Abstand von den ganzen Zahlen, ich sehe hier nur noch Bäume und keinen Wald. Vielleicht übernimmt ja jemand anderes noch ein bisschen die Interpretation.

    Hab auch nen Thread auf Doom9.org aufgemacht: http://forum.doom9.org/showthread.php?t=125772

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

  • Zitat von Brother John:

    Mir fällt keine Lösung ein, wie man ohne Resizing die Pixelanzahl genau gleich hält. Wo sind die Mathematiker? Geht sowas?

    Mir fällt dazu nur

    Zitat

    FillMargins

    Sometimes a video clip has black borders or garbage at the four edges. This looks ugly and does not compress well but possibly you don't want to crop because you have to keep the diminsions as a multiple of 16 or some other number. FillMargins is a simple Avisynth filter that fills the four margins of a video clip with the outer pixels of the unfilled portion. It takes integer 4 parms specifying the size of the left, top, right, and bottom margins. These may be any value and do not have to be any particular multiple.


    ein. Im Prinzip macht der Filter ja das was sonst der Encoder intern machen würde... Wenn ich das richtig sehe.
    Aber ich bin ja auch kein Mathmatiker. :lol:

    Noch einege Vorschläge zum testen:

    im Prinzip "Rechnen" wir ja ja im Moment mit 2 unbekannten:
    - Welchen einflus hat ein nicht mod16 auf die Makroblocks, d.h. auf die Bewegungscompensation
    und
    - Welchen Einfluss hat eine nicht mod8 auf die DCT-Blöcke das heist auf die DCT-Quantisitrung

    Das Sinnvollste wäre jetzt meiner Meinung nach, einen Einflusfaktor auszschliesen und die Tests nochmal zumachen. Die DCT-Quantisitrung können wir nicht ausschliesen, aber wenn wir einen nur I-Frame encode machen dann sollte der mod 16 faktor keine rolle spielen und wir haben den reinen Einfluss des Non-Mod 8 auf die DCT-Quantisitrung.

    Aus dem Vergleich der beiden Werte kann man dann den Einfluss eines nicht mod16 auf die Bewegungskompensation abschätzen.

    ...

    Hoffe ich.

  • Redfox, kannst du dieses Auseinanderklamüsern noch ein bisschen genauer erklären? Ich sehe gerade nicht, was uns das am Ende fürs a) Ranking der Varianten und b) eine einigermaßen brauchbare Angabe über die Höhe des Verlusts bringen könnte.

    Was mir spontan dazu durch den Kopf gegangen ist:
    – Woher wissen wir, dass der DCT-Effekt bei I- und P-Frames den gleichen Anteil hat? Immerhin wird bei einem I-Frame tatsächlicher Bildinhalt und bei P-Frames nur ein Differenzbild transformiert. D.h. bei I-Encoding und normalen I/P-Encoding arbeitet die DCT mit völlig unterschiedlichen Daten. Wie können wir dann aber so einfach die I-Ergebnisse auf die P-Situation übertragen?
    – Die DCT sollte über aufgefüllte Kanten gar nicht so unglücklich sein. Damit bekommt sie durch das Vervielfältigen der letzten Bildzeile einen relativ gleichförmigen Block vorgesestzt, der sich doch recht gut nullen lassen sollte.

    Noch ein Gedanke:
    Aus Sicht des Encoders betrachtet läuft das Encoding intern in jedem Fall mit mod16 ab, nur mit veränderten Blockinhalten der äußersten Reihe im Vergleich zur großen mod16. Die Frage, auf die alles letztendlich hinausläuft, ist dann: erzeugt die Pixelvervielfältigung einen günstigeren Block als er in der großen mod16 vorhanden ist oder nicht.
    Hm, da kommt mir gerade, dass es genau genommen unrealistisch war, beide mod16 vollständig zu croppen. Denn in der Realtität hat man ja eben nicht diese Situation, sondern die Wahl zwischen vollständig gecroppter kleiner mod16 und großer mod16 mit einem Rest Balken incl. scharfer Kante. Das heißt, die großen Mod16-Dateigrößen sind tendenziell zu klein. Und das wiederum heißt, dass auf diesen Faktor bezogen der Effizienzverlust überschätzt wird.

    akupenguin hat im engl. Thread Bedenken geäußert, weil konstanter Quant nicht unbedingt konstante Qualität heißt. Irgendwelche Meinungen dazu? Ich finde das nicht tragisch, denn schließlich wird Effizienz gemessen und nicht Qualität. Wie die beiden zusammenhängen, ist wieder eine andere Frage.

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

  • Ich versuche gerade, nachträglich SSIM und PSNR zu berechnen, nur hab ich das noch nie gemacht. Wie sieht denn dieses Script aus?


    Ich habe gelesen, dass man bei Xvid mit B-Frames von der encodierten Version das erste Frame wegschneiden soll. Wenn ich das mache und mit einem StackVertical(source,encoded) prüfe, kommen allerdings verschiedene Frames heraus. Ohne Trimming passts.

    Das Script lade ich in VDubMod und spiele es ab, um die Statistiken zu kriegen. Passt das vom Vorgehen her? Die Statistikdateien werden jedenfalls vollständig erstellt, auch wenns ewig dauert. Nicht mal Echtzeit! *grummel*

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

  • Oh, bei den Vergleichsmessfunktionen gibt es Fallstricke: AviSynth muss glauben, dass alle Zwischenergebnisse für die Videoausgabe notwendig sind...

    Meine damalige Lösung mit Anzeige des Unterschiedes als Differenzbild

    "Abspielen in VirtualDub" geht, "Scan for errors" sollte auch klappen. Einmal muss er durch; am Ende musst du das Script schließen! (Wenn du Batch magst, verwende AVS2AVI.)

    Erstes Frame abschneiden ist bei B-Frame-XviD nur bei einer der beiden Packed-Bitstream-Werte nötig.

  • LigH
    Mit Stackhorizontal() hat es auch geklappt, dass beide berücksichtigt werden. Das Frame abschneiden gilt dann offenbar nur für Streams ohne packed B-Frames. Thx für den Tipp mit AV2AVI. Hätte ich auch drauf kommen können.

    Selur
    Unglücklicherweise haben wir unterschiedlich große Dateien, für die nicht mal gleiche Qualität garantiert ist, schon gar nicht metrische Qualität.

    Ich habs trotzdem angetestet.

    Zitat

    Sample 5
    Mod 16 klein PSNR: Min 41.2644 Avg 45.7297 Max 55.8637
    Mod 2–       PSNR: Min 41.2612 Avg 45.8342 Max 56.0442

    Mod 16 klein Average SSIM= 88.79663328
    Mod 2–       Average SSIM= 89.02446853


    So. Da! *kopfkratz* Sagt uns das jetzt irgend etwas brauchbares? So unüberlegt steht da, mod2– hat die bessere Qualität als die kleine mod16. Aber kann man diesen Vergleich überhaupt ziehen? Ich kenne mich halt mit den Metriken kaum aus, weil ich ihnen grundsätzlich nicht über den Weg traue.

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

  • mod16 704x400Pixel;232.125.158 Byte
    mod2- 704x414Pixel;239.832.090 Byte
    ->mod2 ist 3,3%größer und hat fast keinen Qualitätsgewinn.
    (PSNR und SSIM ist um 0.3% besser)

    Aus den Ergebnissen würde ich wenn schließen, dass sich mod2 nicht lohnt und mod16 zu bevorzugen ist. :D
    Ist aber eher spekulativ als wirklich aussagekräftig, u.a. weil PSNR nicht linear skaliert; SSIM schon, aber auch da ist der Qualitätszuwachs nur 1/10 des Größenzuwachses. (Da die Qualität des Clips aber schon recht gut ist, wäre ein 1:1 Verhältnis utopisch, aber ist 1/10 ausreichend? ;))

    Cu Selur

  • Zitat von Selur

    ->mod2 ist 3,3%größer und hat fast keinen Qualitätsgewinn.


    Mod2– hat aber auch eine um 3,5% größere Bildfläche... Ich habe das Gefühl, SSIM und PSNR bringen in dem Fall überhaupt nichts.

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

  • Mod2– hat aber auch eine um 3,5% größere Bildfläche... Ich habe das Gefühl, SSIM und PSNR bringen in dem Fall überhaupt nichts.


    Jau, das ist ziemlich richig.

    Bei vielen Tests von mir, die ich hier schon gestartet hatte haben PSNR und SSIM mehr verwirrt als fuer Aufklaerung gesorgt. Teilweise driften beide Werte sogar auseinander und widerlegen sich.
    Wobei soweit ich weis SSIM mehr das persoenliche Empfinden wiedergibt.


    Wenn Mod2- eine um 3.5% groessere Bildflaeche hat, der SSIM minimal groesser ist und die Dateigroesse selbst nur 3.3% groesser ist, wuerde das nach den Zahlen bedeuten, dass Mod2 effizienter als Mod16 klein ist.

    Mehr Bildflaeche bei weniger Speicher und besserer Qualitaet...


    Das Fazit waere: Wenn croppen, dann auf Mod2.
    Allerdings muss spaetestens wenn so ein Fazit eintritt, dass alles andere bisher widerlegt noch ein Subjektiver Test gestartet werden.

  • Nachtrag: Wie beim x264-Mod-Test habe ich noch die Effizienzspannen ausgerechnet, d.h. die Spanne zwischen bestem und schlechtestem Clip eines Samples in Prozentpunkten:

    Sample 1: 2,66
    Sample 3: 2,53
    Sample 4: 1,74
    Sample 5: 2,95
    Sample 6: 1,98
    Durchschnitt: 2,37

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!