Beiträge von Kopernikus

  • PSNR/SSIM/VQM wie gut soll Video sein?

    Ich hab auch schon Videos erzeugt mit SSIM von 0.97 die furchtbar aussahen.

    VQM ist als Metrik sehr schlecht.

    SSIM und PSNR sind auch nur als relative Werte geeignet. Wenn deinn Quellmaterial schon schlecht aussieht, dann sieht es auch bei einem SSIM von 1 nicht besser aus.

    Ich glaube nicht, dass man da Absolutwerte angeben kann.

  • min/max Quant und Quant Delta in x264

    Das ist auch nicht weiter überraschend. Der Average Quant liegt bei ungefähr 33, und wegen der logarithmischen Skala sind die Abweichungen auch nicht soo groß, dass wir in die Gebiete von Q10 (das ist besser als MPEG4 ASP Q 2 oder sogar als Q 1) kommen würden.

    Was war das für Material mit dem du getestet hast?

    Einen Sprung von 16 im Quantizer zwischen 2 Frames ist echt krass, selbst 4 entspricht fast einer Verdopplung oder Halbierung der Quantisierung, außer Krassen Szenenwechseln kann ich mir keine Szenarien Vorstellen, für die das Relevant ist.

    Falls du noch weitere Tests machst, wäre evtl. eine Quantisierungskurve interessant, damit man die Auswirkungen der Einstellungen sehen kann. Dazu müsste man vermutlich die verbose Ausgabe in eine Datei umleiten und dann ein Skript schreiben, dass die Quants rausliest.

  • Mod16 -> Komprimierbarkeit

    Wenn ich das soweit richtig verstanden habe, dann ist es kein Problem. Das Bild wird intern aufgefüllt auf mod 16 und dann beim decoden wieder ausgeschnitten. Sollte also standardkonform sein. Und Xvid scheint das auf den ersten Blick auch so zu machen.

  • Transcoder versus Encoder – SSIM-Analyse sinnvoll?

    Es gibt nicht bestimmte Bildschirmregionen, die das Auge mehr oder weniger gut erfasst, das kommt darauf an, worauf man schaut. Wenn man darauf achtet wie sich sein Augapfel bewegt, dann kann man selbst feststellen, wie er sich dauernd bewegt.

    Kurzbleiche in Physiologie: Das Auge hat im wesentlichen einen Punkt auf der Netzhaut, mit dem es scharf sehen kann, der sog. gelbe Punkt oder auch Fovea genannt. Das Auge wird immer so gedreht, dass die interessanten Bildteile in der Fovea liegen.

    Ausserhalb der Fovea sind relativ wenig sehzellen, so dass man nicht sehr hochaufgelöst sieht. Experiment: Versuche die Enter Taste auf deiner Tastatur zu fixieren und dann die anderen Tastenbeschriftungen zu lesen, ohne die Fixation zu verlieren.

    Eine sinnvolle psychovisuelle Optimierung wäre also, den Fixationspunkt mit höherer Qualität zu encoden und Bitrate in den peripheren Bereichen zu sparen (z.B. hat der SSIM Entwickler auf diesem Gebiet mal gearbeitet).

    Um SSIM zu verbessern, könnte man auch noch in Betracht ziehen, ob der Bereich fixiert wird oder nicht.

    Fixationspunktbestimmung ist eine interessante und hochgradig nichttriviale Aufgabe. Menschliche gesichter sind z.B. sehr wahrscheinliche Fixationspunkte. Bewegungen und auffällige Farben ebenso.
    Das Fixationsverhalten ordentlich zu modellieren und nachzubilden halte ich für sehr sehr schwierig, da dabei auch sehr "hohe" Funktionen der Wahrnehmung mitwirken. Da kann man beliebig viel Aufwand treiben.

    Archimedes: In welcher Programmiersprache hast du denn dein SSIM Implementiert?

    Denn falls du mit C Code was anfangen kannst, hätte ich hier einige Routinen, die versuchen die Fixation zu modellieren. Dann könnte man versuchen SSIM ein bisschen zu "tunen".

  • Unklarheiten bezüglich neueren x264CLI Optionen

    Trellis 2 ist eine Sonderform von Trellis 1, bei der jeder Encodiermodus, der in Betracht gezogen wird "trellisiert" wird, bei Trellis 1 nur die, die schlussendlich ausgewählt wurden.

    Dass Trellis 1 nicht wesentlich schlechter ist, zeigt, dass die Auswahlheuristiken gut sind, und sich durch Trellis nicht wesentlich durcheinanderbringen lassen.

    Trellis 2 sollte man genau wie -me esa und -qpfile als Option sehen, die für Experimente interessant, aber im Alltag nicht nötig sind.

  • Transcoder versus Encoder – SSIM-Analyse sinnvoll?

    SSIM ist mit Vorsicht zu genießen. Es ist zwar besser als PSNR, aber trotzdem beruht es auf einem recht einfachen Prinzip, nämlich dass unsere Wahrnehmung erhaltene Struktur (im Sinne eines R^64 Skalarprodukts) als gute Qualität ansieht, mit einigen Lumi- und Contrastmaskingeffekten angereichert.

    Das stimmt nur bedingt und es gibt einen Haufen Wahrnehmungseffekte, die nicht berücksichtigt werden (Colour (Cross) Masking, Motion Masking, Foveating Effekte, Saccadic Masking, Einbeziehung des Fixationspunkts, von den ganzen komplizierteren Strukturerkennenden Effekten mal ganz abgesehen, die sind größtenteils nicht mal ansatzweise verstanden).

    Die verwendete SSIM Implementierung folgt nicht dem Paper (kein 11x11 Gauss-Gewichtungsfenster, Lumimasking weiß ich nicht), somit sind die Ergebnisse nur mit Vorsicht übertragbar (zumindest die zweite Nachkommastelle ist fragwürdig). Die Vielzahl an wissenschaftlichen Tests beschränkt sich meines Wissens auf ein oder zwei Versuchsreihen mit ein paar Dutzend Versuchspersonen und einer JPEG Bildergalerie bzw. MPEG Video (also kein recodiertes bzw. transcodiertes Material).

    Ausserdem lässt sich SSIM leicht täuschen (Viele gute und wenig schlechte Fenster sehen schlecht aus, haben aber guten SSIM, das typische schwarzer Fleck Beispiel), räumliche oder zeitliche verschiebungen des Bilds führen zu katastrophalen SSIM Werten und wie gesagt, es wird nur die Y Komponente beachtet, UV kann Kopfstand machen.

    Natürlich sind das Horrorszenarien, und in der Praxis wird die verwendete Methode (ich vermute das Avisynth Plugin) meistens Ergebnisse liefern, die ordentlich bis gut übereinstimmen, aber eine Visuelle Kontrolle ist wichtig, da unterschiedliche Artefaktarten von SSIM unterschiedlich stark bewertet werden.

    Als Beispiel habe ich neulich mit einer qualitätsbasierten Rate Control für XviD experimentiert, die versucht einen konstanten SSIM Wert zu halten, und die Ergebnisse sahen z.T. furchtbar aus, weil wenige Blocks sehr schlecht waren, obwohl die SSIM Werte relativ hoch lagen.

  • Unklarheiten bezüglich neueren x264CLI Optionen

    Wie wäre es mit allen Kombinationen von dct-decimate, trellis (1,2) und no-fast-p-skip. Das sollten 12 sein. Das noch mit 1 bis 3 verschiedenen Materialien (anime, DVD, DVB oder so), dabei SSIM PSNR und fps und eine kurze visuelle Begutachtung bei 2 oder 3 verschiedenen Bitraten. Das sind zwischen 24 und 108 Encodes. Vielleicht mal mit einem Clip und einer Bitrate anfangen und falls sich spannende Dinge finden, kann man da ja weitertesten.

  • motion estimation

    Ok, ich versuche mal zu erklären, und ich versuche es so zu machen, dass man das dann zusammen mit den Bilder von akapuma gut in die Wiki übernehmen kann (Zaunpfahl! :)) Vielleicht könnte man da sogar schöne Skizzen dazu malen als ersatz für die ASCIIs (Zaun!! :))

    Die erkannte Bewegung wird verwendet, um aus bereits decodierten Frames bereits das nächste Bild möglichst gut anzunähern, so dass nur noch die Unterschiede gespeichert werden muss. Diesen Vorgang bezeichnet man als Motion Compensation.

    Dabei gibt es verschiedene Ansätze (von komplex zu einfach geordnet):

    Mesh-Based Motion: Das Frame wird in ein Gitter geteilt, und die Unterschiede werden als Verzerrung dieses Netzes modelliert. Kann auch komplexe Bewegungsmuster gut modellieren. Sowohl Estimation als auch Compensation sind sehr rechenintensiv. Mesh Based Motion wird in keinem populären Format wirklich verwendet, jedoch sind in MPEG4 Specifikationen dazu vorhanden.

    Global Motion

    Bewegung wird als affine Transformation beschrieben, D.h. als eine Mischung aus Zoom, Schwenk, Drehung und perspektivischer Verzerrung. Man benötigt nur sehr wenige Parameter dafür (platzsparend), jedoch ist nur sehr einfache Bewegung effektiv vorherzusagen. Estimation/Compensation sind rechenintensiv. Wird verwendet in MPEG4 ASP (z.B. XviD GMC), Dirac.

    Overlapped Block Motion (OBMC/E)
    Ähnlich der Block Motion (siehe unten), nur dass sich überlappende Blöcke verwendet werden. Im Überlappbereich wird eine Mischung aus den verschiedenen Blöcken als Vorhersage verwendet. Das ermöglicht bessere Vorhersagen und verringert Blockartefakte in der Vorhersage, was die Subjektive Qualität verbessert.
    OBMC wird in Snow und Dirac verwendet, MPEG4 hat Spezifikationen dazu, wird aber in der Praxis nicht verwendet.

    Block Motion:

    Das Bild wird in sich Blöcke eingeteilt, und für jeden Block wird ein Bewegungsvektor bestimmt, der beschreibt, wie sich dieser Block im Vergleich zum Referenzframe verschoben hat.

    Graphisches 1-dim Beispiel (| sind nur Markierungen):
    Referenz:
    aaaa|bbbb|cccc|dddd
    Vorherzusagendes Frame
    bbbb|aabc|cccc|ccca
    Bewegungsvektoren
    -4 | 2 | 0 | 4
    Vorhersage
    bbbb|aabb|cccc|cccc

    Estimation und Compensation sind relativ einfach und schnell. Jedoch sind komplizierte Bewegung schlecht modellierbar und Vorhersage weist Blockartefakte auf.
    Um effektiv kompliziertere Bewegungen modellieren zu können, müssen kleine Blöcke verwendet werden, was aber viele Bewegungsdaten erfordert. Moderne Formate erlauben daher unterschiedliche Blockgrößen in einem Frame (z.B. Blockgrößen von 16x16 bis 4x4 in bestimmten Anordnungen bei H.264). Block Motion findet in allen MPEG und den H.26x Formaten, sowie in sehr sehr vielen anderen Formaten Verwendung.

    Man kann auch noch die Referenz "zoomen" also Pixel zwischen den eigentlichen dazuerfinden, in der Hoffnung, dass man dann bessere Vorhersagen bekommt. MPEG4 ASP und AVC unterstützen Bewegungsvektoren bis auf 0.25 Pixel (QPEL), Dirac bis 0.125 Pixel genau.

    Hier jetzt eine kurze Besprechung der populärsten Suchverfahren (die aus x264 und Xvid) für Block Motion Estimation. Diese lassen sich mit kleinen Änderungen auch für OBME verwenden.

    Man beginnt mit einer Abschätzung des Bewegungsvektors für den aktuellen Block. Die Abschätzung kann z.B. der bereits gefundene Bewegungsvektor des vorherigen Blocks sein, da die Bewegung von benachbarten Blöcken mit großer Wahrscheinlichkeit ähnlich ist.

    Ein Bewegungsvektor zeigt auf einen Block im Referenzbild. Es ist also das gleiche, wenn man von Bewegungsvektoren oder Bildblöcken im Referenzbild spricht.

    Um "gute" Bewegungsvektoren von "schlechten" Bewegungsvektoren unterscheiden zu können, muss man die Unterschiede zwischen dem Block im Referenzbild und dem Block, den man vorhersagen will (hier ab jetzt Zielbild genannt) messen können. Dazu gibt es verschiedene Metriken (es handelt sich sogar streng mathematisch um Metriken):

    SAD (Sum Absolute Differences, Summe der Absoluten Differenzen):
    Für jedes Pixel im Block wird der Absolutbetrag der Differenz des Pixelwerts im Referenzbild und im Zielbild berechnet und die Summe daraus gebildet. Sehr schnell.

    SSD (Sum of Squared Differences, Summe der quadrierten Differenzen):
    Für jedes Pixel im Block wird das Quadrat der Differenz des Pixelwerts im Referenzbild und im Zielbild berechnet und die Summe daraus gebildet. Große Differenzen werden so stärker gewichtet.

    SATD (Sum of Hadamard Transformed Differences, Summe der Hadamardtransformierten Differenzen)
    Es wird für jeden Pixel die Differenz zwischen Referenzframe und Zielframe berechnet und der Differenzblock Hadamardtransformiert. Die Hadamardtransformation ist eine mathematische Operation, die der DCT sehr ähnlich ist. SATD sagt nun also ungefähr etwas darüber aus, wie viel Speicherplatz die entstehenden Differenzen nach einer DCT benötigen. Relativ langsam, aber für manche Zwecke aussagekräftiger. Z.B. verwendet x264 zur Schätzung der Komplexität eines Frames im crf Modus SATD.

    Um einen guten Bewegungsvektor zu finden gibt es verschiedene Strategien:

    Diamond (a) /Hex (b) Search:

    1) Man beginnt mit einer Schätzung des Bewegungsvektors.

    2a) Jetzt misst man die Unterschiede der vier direkt benachbarten Bewegungsvektoren/Bildblöcke (also bei Ganzpixelsuche die, die ein Pixel nach oben, unten, links und rechts verschoben sind).

    Code
    1[COLOR='Red']2[/COLOR]3[COLOR='Red']4[/COLOR][COLOR='Blue']5[/COLOR][COLOR='Red']6[/COLOR]7[COLOR='Red']8[/COLOR]9

    Bei Zentrum 5 werden die Orte 2, 4, 6 und 8 geprüft.
    2b) Jetzt misst man die Unterschiede der sechs in einem Hexagon um das Zentrum angeordeten benachbarten Bewegungsvektoren/Bildblöcke.

    Code
    a[COLOR='Red']b[/COLOR]c[COLOR='Red']d[/COLOR]efghij[COLOR='Red']k[/COLOR]l[COLOR='Blue']m[/COLOR]n[COLOR='Red']o[/COLOR]pqrstu[COLOR='Red']v[/COLOR]w[COLOR='Red']x[/COLOR]y


    3) Dann nimmt man die Position als neues Zentrum, die die geringsten Unterschiede aufweist.
    4) Man bricht ab, wenn sich das Zentrum in zwei aufeinanderfolgenden Schritten nicht ändert, d.h. keine der umliegenden Positionen besser ist als das Zentrum.

    Exhaustive Search:

    Es werden alle Positionen in einem gewissen Fenster abgesucht. Sehr sehr langsam.

    Uneven Cross Multihexagon:

    Diese Methode funktioniert ungefähr so:

    Zuerst werden einige Positionen in Kreuzform um die Vorhersage abgesucht, der horizontale Balken des Kreuzes ist länger, da horizontale Bewegungen häufiger sind als vertikale):


    Code
    a
   b
cdefghi
   j
   k

    Um die beste Position davon wird eine exhaustive Search mit kleinem Fenster durchgeführt, und ausserdem ein Hexagonsuche mit einem doppelten Hexagon (zwei Hexagons mit unterschiedlichen Radius um das selbe Zentrum). Ausserdem werden sehr komplizierte Kriterien verwendet, um die Suche abzubrechen, wenn schon früh im Suchvorgang "gute" Bewegungsvektoren gefunden wurden.


    akapuma:
    nach dieser etwas länglichen Erklärung sind die Antworten auf deine Fragen ganz kurz:

    Es werden Bewegungsvektoren gesucht. Radius 1 und Radius 2 bedeuten, dass bei Dia Search der Diamant einen Radius von 1 hat, das Hexagon einen Radius von 2.

    Merange ist ungefähr die maximale Länge des Bewegungsvektors. Bei Dia und Hex terminiert die Suche meistens früher, deshalb kein großer Effekt. Bei Esa wird die Suche sehr viel langsamer, und bei umhex beeinflusst es die größe des Kreuzes, und die maximale Anzahl der MHex Schritte.

  • cpu=? Frage

    Diese Option beeinflusst, wie was der Decoder ausspuckt. Je nach dem was du machen willst bzw. wie dein , kann es sinnvoll sein, deblocking ein oder auszuschalten.

    Verschiedene IDCTs machen vermutlich wenig unterschied, aber wenn ich mich recht erinnere hat LigH da mal ausführlich getestet

  • Unklarheiten bezüglich neueren x264CLI Optionen

    Würde ich vermuten. Damit wird bei der Entscheidung, ob ein Block geskippt (also der entsprechende Block aus dem vorherigen Frame verwendet wird) oder nicht eine frühzeitige Entscheidung verhindert. Diese spart einige Vergleiche und ist deshalb schneller, aber anscheinend haut sie manchmal daneben und verursacht Blöcke.

    Wie gesagt, ich habs nicht getestet, und Video Codecs sind sehr komplex, so dass scheinbar nicht zusammenhängende Dinge unerwartete Auswirkungen haben können. Sieh meine Aussagen deshalb eher als "educated guess" als als absolute Wahrheiten.

  • Cropping - Sinnvoll oder nicht?

    Als Faustregel würde ich vorschlagen:
    -wenn der Codec nicht-mod 16 unterstützt, dann pixelgenau croppen, der Codec wird das dann intern besser regeln als man es von Hand könnte
    -wenn der Codec nur mod 16 versteht, dann halt die paar Pixel mehr wegcroppen.
    -keine schwarzen Ränder lassen