Warum man nicht überall croppen sollte

  • Ist diese Untersuchung interessant? 18

    1. Ja. (11) 61%
    2. Ich habe keine Anwendung dafür. (1) 6%
    3. Ist doch ein alter Hut. (5) 28%
    4. Nein. (1) 6%

    Diese kleine Untersuchung hat eine Vorgeschichte: Ich wollte ein Backup einer DVD als XviD erstellen, die 16:9-Format mit "schwarzen Balken" (Letterbox) hatte. Also habe ich die Balken oben und unten abgeschnitten und das ganze als XviD encodiert. Für dieses Backup wollte ich die bestmögliche Qualität, daher habe ich z.B. keine Skalierung gemacht, sondern das XviD wie das Original anamorph (Seitenverhältnis der Bildpunkte nicht 1:1) gespeichert.

    Dann fiel mir aber ein, dass die Balken, die ich abgeschnitten hatte keine durch 16 teilbare Höhe hatten, nämlich 72. Nach allem, was ich über Codecs weiß, benutzen fast alle irgendwo diskrete Cosinustransformation, die auf Blöcken von Bildpunkten arbeitet, meistens 16 x 16 (glaube ich). Es wäre also zu erwarten, dass die Qualität besser wird, wenn die erste Zeile von meinem ausgeschnittenen Video einer durch 16 teilbaren Zeile des Originalvideos entspricht. Mich hat interessiert, ob man diesen Qualitätsunterschied messen kann und wenn ja wie groß er etwa ist.

    Ich ging hin und nahm einen 22 Sekunden langen Ausschnitt aus dem Film mit viel Bewegung und relativ guten Kontrasten. Dann machte ich 16 XviDs, beginnend bei Zeile 80 (durch 16 teilbar) des Originalvideos bis Zeile 95. Jedes dieser Videos hat dieselbe Bildhöhe (wenn auch einen etwas anderen Ausschnitt) und 4000 kBit/s (2-pass).

    Dann verglich ich die XviDs mit dem Original, und zwar immer einen Ausschnitt, den alle XviDs enthielten (oben und unten ein wenig abgeschnitten). Dazu verwendete ich die Funktion SSIM (AviSynth Plugin von Lefungus). Das Ergebnis befindet sich im Anhang.

    Das war in etwa das Ergebnis, das ich erwartet hatte. Ohne Verschiebung ist die Qualität am besten, bei einer Verschiebung um 8 Zeilen ist sie wieder relativ gut, möglicherweise weil XviD (zumindest teilweise) 8 x 8-Blöcke verwendet. Aber was ist dieser SSIM-Wert und wie groß ist der Qualitätsverlust? Dazu probierte ich ein wenig herum, welche Bitrate ich wählen muss, um mit Verschiebung etwa denselben SSIM-Wert zu bekommen wie bei 4000 kBit/s ohne Verschiebung. Das Ergebnis hat mich überrascht. Der Wert lag etwas über 5000 kBit/s.

    Das bedeutet, dass man für das Schneiden an einer ungeeigneten Stelle einen hohen Preis bezahlt. Um auf dieselbe Qualität zu kommen wie beim Schneiden an einer 16-Pixel-Grenze braucht man 25 % mehr Platz!

    Natürlich ist diese kurze Messreihe nur ein Beispiel. Bei anderem Material kann es anders aussehen. Zum Beispiel dürfte es weniger ausmachen wenn das Material bearbeitet wird z.B. durch Weichzeichnen, denn dann kommt man sowieso lange nicht auf so hohe SSIM-Werte. Wenn das Video skaliert wird, wird dieser Effekt wahrscheinlich überhaupt nicht mehr auftreten. Schlimmer dürfte es allerdings bei niedrigeren Bitraten (ohne Skalierung) sein, denn gerade da wird bei der DCT viel "weggeworfen" und wenn die Blöcke sich nicht mit den ursprünglichen Blöcken decken, wird das noch deutlichere Unterschiede ergeben. Was für Zeilen gilt, gilt sicher auch für Spalten. Waagerecht würde ich sicherheitshalber nur auf Vielfachen von 32 schneiden.

  • Zitat

    Aber was ist dieser SSIM-Wert ..


    SSIM ist ein Versuch über die Strukturelle Ähnlichkeit von Bildern ein objektives Qualitätsmaß zu bestimmen. :)
    Siehe: http://www.cns.nyu.edu/~lcv/ssim/

    Zitat

    ... und wie groß ist der Qualitätsverlust?


    Kommt auf deinen Maßstab an, den Unteschied in SSIM kannste ja ablesen. :)

    Könntest Du auch mal Posten was für Settings Du in Xvid verwendet hast?
    (GMC? AQ? ... )

    Cu Selur

    Ps.: Das obejktivste Qualitätsmaß erhält man nur durch druafgucken. ;)

  • Zitat von Selur

    SSIM ist ein Versuch über die Strukturelle Ähnlichkeit von Bildern ein objektives Qualitätsmaß zu bestimmen. :)
    Siehe: http://www.cns.nyu.edu/~lcv/ssim/


    Ähm klar, deshalb hab ich's ja genommen ;).

    Zitat

    Könntest Du auch mal Posten was für Settings Du in Xvid verwendet hast?
    (GMC? AQ? ... )


    Quantisierung: MPEG
    Kein Adaptive Quantization
    Kein Quarter Pixel
    Kein Global Motion Compensation
    Max. consecutive BVOPs: 1
    I-frame boost: 10 %
    Chroma Optimizer
    Motion Search Precision: 6 - Ultra High
    VHQ Mode: 4 - Wide Search
    Use Chroma Motion
    Kein Turbo
    Maximum I-Frame Inteval: 100
    Trellis Quantization

    Wollte mir wenigstens die theoretische Möglichkeit offenhalten, das auf nem DVD-Player wiederzugeben.

    Zitat

    Ps.: Das obejktivste Qualitätsmaß erhält man nur durch druafgucken. ;)


    Sorry, aber den Unterschied zwischen 4000 kBit/s und 4200 kBit/s seh ich nicht. Ich nehme eigentlich immer Qualität, die weit jenseits dessen ist, wo ich Artefakte erkennen kann.

  • Wenn mans genau macht, sollte man immer die "non-movie"-Area Croppen, da man die weiss, was da im "schwarz" für ein feiner Müll drin ist.
    Aber um Mod8 oder 16 zu erlangen kann man skalieren (=interpolation) oder man lässts bei der originalen aktiven Movie-Area-Größe und padde't einfach schwarz dran, dadurch gibts keinen Schärfeverlust.

  • Zitat von incredible

    Aber um Mod8 oder 16 zu erlangen kann man skalieren (=interpolation)


    Das ist qualitätsmäßig sehr "teuer".

    Zitat

    oder man lässts bei der originalen aktiven Movie-Area-Größe und padde't einfach schwarz dran, dadurch gibts keinen Schärfeverlust.


    Irgendwie find ich's doof, schwarze Balken mitzucodieren. Da schnibbel ich lieber ein paar Pixel vom Bild ab.

  • Zitat von Sweeeet

    Dann fiel mir aber ein, dass die Balken, die ich abgeschnitten hatte keine durch 16 teilbare Höhe hatten, nämlich 72.

    Scherzkeks, es waren aber nicht jeweils 72 Pixel oder (72*2=144, 144 mod 16 = 0)?

    Zitat von Sweeeet

    Irgendwie find ich's doof, schwarze Balken mitzucodieren. Da schnibbel ich lieber ein paar Pixel vom Bild ab.

    Seh ich auch so, aber es kommt immer drauf an. Grad bei alten Filmen, wo man nichtmal 2 Pixel abschneiden muss (eher 1,5, da am Rand verschwommen (interpoliert?)).

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Zitat von nexustheoriginal

    Scherzkeks, es waren aber nicht jeweils 72 Pixel oder (72*2=144, 144 mod 16 = 0)?


    Wieso Scherzkeks? Ich hab oben und unten jeweils 72 Zeilen abgeschnitten. Damit fängt der XviD-Encoder mit Blöcken an, die sich nicht mit den originalen MPEG2-Blöcken decken.

    Wie hoch der abgeschnittene Teil insgesamt, der verbleibende Teil, und ob deren Höhe durch 16 teilbar ist, ist ja nochmal ein anderes Thema. (Ersteres ist egal, die letzten beiden Sachen sind für's Encodieren günstig, haben aber nichts speziell mit Transcodieren zu tun.) Aber der Verlust auf 8-Pixel-Grenzen ist nicht so schlimm, dass ich jetzt 6 DVDs neu encodiere :).

    Das mit den verwaschenen Rändern ist auch ein Phänomen. Ich hab bei einigen DVDs einen Rand, quasi 4 Pixel oben, unten, rechts und links "Ausblenden" zu schwarz, offensichtlich absichtlich reingerechnet. Wird das gemacht, damit analoge Fernseher besser mit dem Bild klarkommen?

  • Zitat von Sweeeet

    Wie hoch der abgeschnittene Teil insgesamt, der verbleibende Teil, und ob deren Höhe durch 16 teilbar ist, ist ja nochmal ein anderes Thema. (Ersteres ist egal, die letzten beiden Sachen sind für's Encodieren günstig, haben aber nichts speziell mit Transcodieren zu tun.)

    Ersteres ist nicht egal!
    DVD : 576mod16=0 Wenn das was insgesamt abgeschnitten wird auch durch 16 teilbar ist, ist der Rest, der encodet wird auch durch 16 teilbar. Und schließlich geht es um diesen Rest.

    Bsp.: Wenn du oben 13 Pixel abschneidest und unten 3 ist es auch ok. (576-13-3)mod16=0

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Zitat von nexustheoriginal

    Ersteres ist nicht egal!
    DVD : 576mod16=0 Wenn das was insgesamt abgeschnitten wird auch durch 16 teilbar ist, ist der Rest, der encodet wird auch durch 16 teilbar. Und schließlich geht es um diesen Rest.

    Nein, da hast Du mich falsch verstanden. Encoder arbeiten mit Blöcken, also ist Verschnitt unten ungünstig. Aber darum ging es mir nicht, sondern um den Qualitätsverlust, der dadurch entsteht, dass Blöcke encodiert werden, die nicht mit (MPEG2-)Blöcken des Originals zusammenfallen.

    Bei meiner Testreihe hatten alle 16 encodierten Clips eine durch 16 teilbare Höhe, trotzdem war ihre Qualität durch o.g. Effekt stark unterschiedlich.

  • Zitat von Sweeeet

    sondern um den Qualitätsverlust, der dadurch entsteht, dass Blöcke encodiert werden, die nicht mit (MPEG2-)Blöcken des Originals zusammenfallen.

    Ok, dann hab ich dich tatsächlich falsch verstanden.

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Zitat von nexustheoriginal

    Ok, dann hab ich dich tatsächlich falsch verstanden.


    Ok, und wie bekommst Du jetzt das Kreuzchen bei der Umfrage "Alter Hut" wieder weg? ;) :D
    Hm, stand eigentlich auch schon genau so im Ursprungsposting.

    Zitat von Sweeeet

    Jedes dieser Videos hat dieselbe Bildhöhe

  • Zitat von nexustheoriginal

    Bsp.: Wenn du oben 13 Pixel abschneidest und unten 3 ist es auch ok. (576-13-3)mod16=0


    Nein. Sweeet hat hier grundsätzlich schon recht. Im Hinblick auf "Coding efficiency":

    Wenn man x & y nur MOD-16 Werte croppt, ist das das theoretische Optimum für direkt-encoding ohne irgendwelche Filterung.

    Cropping von nicht-MOD16, aber MOD-8 Werten ist minimal schlechter, aber eigentlich kaum nennenswert.

    Cropping von nicht-MOD8 Werten ist ungünstig, auch wenn der gecroppte Bereich MOD8 oder gar MOD16 ist.


    Es geht einzig um das "Block alignment" der Blockstrukturen in Quelle und XviD's Motion Engine.

    In der DVD-Quelle hat der Mpeg2-Encoder natürlich alles in 8x8-Blöcken quantisiert, aber nur eine Motion engine verwendet, die 16x16-Blöcke kompensiert.
    Solange also zumindest MOD8-Ränder gecroppt werden, kann XviD auf "sauberen" DCT-Böcken arbeiten. Wenn nicht MOD8 gecroppt wird, muss XviD Blöcke codieren, die in der Quelle vorhandene Block-Übergange quasi als "scharfes Detail" enthalten.

    Croppen von MOD16-Werten ist noch idealer, weil XviD dann öfter auf inter4v (4 Bewegungsvektoren pro 16x16 Block) verzichten kann, welches im MOD8-Fall vermehrt benötigt wird.
    *

  • Zitat von Sweeeet

    Hm, stand eigentlich auch schon genau so im Ursprungsposting.

    Ergo: Weniger schreiben, mehr zusammenfassen. ;)

    Also ist "Sprengen" der (16x16)Ursprungsmakroblöcke schlimmer als das Beibehalten von einigen Zeilen schwarzer Pixel?

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Danke für die Erklärung, Didée. Mein Wissen beschränkt sich im Wesentlichen auf JPEG. Zu Motion werd ich mir noch ein wenig anlesen.

    Zitat von nexustheoriginal

    Ergo: Weniger schreiben, mehr zusammenfassen. ;)


    Hehe, hab ich ja versucht :).

    Zitat

    Also ist "Sprengen" der (16x16)Ursprungsmakroblöcke schlimmer als das Beibehalten von einigen Zeilen schwarzer Pixel?


    Genau das würde ich als Resumée sehen. Aber auch Mod8 scheint echt ok zu sein und das hatte ich ja zufällig getroffen.

  • Das 8 Pixel Versatz relativ ok sind, liegt daran, dass die Helligkeitskomponente bie MPEG4 in 8x8 Blöcken bearbeitet wird, die Farbkomponenten in subgesampelten 8x8 Blöcken (also ein Farbblock umfasst 8x8 Farbsamples, die sich aber auf den gleichen bereich verteilen wie 4x8x8 Helligkeitssamples)

    Da SSIM nur die Helligkeitskomponente betrachtet , ist der Verlust durch einen halb verschobenen Chromablock nicht so groß. (Im Originalpaper wird auf jeden Fall nur Y betrachtet, im Plugin glaubich auch, da bin ich mir aber nicht 100% sicher).

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Okay, eventuell bring ich hier jetzt was durcheinander, aber wenn ich eine DVD mit Avisynth behandle und später nach Xvid umwandle, sollten etwaige Ursprungsmakroblöcke doch egal sein wenn ich nicht resize sondern nur croppe, oder? (das Resizen/Interpolieren Einbußen bringt ist klar)

    Cu Selur

  • Zitat von Selur

    wenn ich eine DVD mit Avisynth behandle und später nach Xvid umwandle, sollten etwaige Ursprungsmakroblöcke doch egal sein

    Nein, sie sind nicht egal. Jedes Bild des MPEG2-Stroms wird ja in Blöcken gespeichert. Der Inhalt dieser Blöcke wird dabei nicht 1:1 sondern vergröbert gespeichert (DCT). Wenn Du ein solches Video mit AviSynth öffnest, enthält der AviSynth-Clip Bilder, die aus diesen Blöcken rekonstruiert werden.

    Wenn Du nun XviD auf diese Blöcke loslässt, wird XviD die Blöcke auf ähnliche Art komprimieren und würde dabei ähnliche Anteile unter den Tisch fallen lassen, die MPEG2 bereits unter den Tisch hat fallen lassen. Dieser Effekt sorgt dafür, dass XviD weniger Platz braucht.

    Wenn XviD nun nicht auf die MPEG2-Blöcke ausgerichtet ist, zerhackt XviD die Bilder in Blöcke, die aus unterschiedlichen MPEG2-Blöcken bestehen. Im schlimmsten (und allgemeinen) Fall muss XviD also eine Repräsentation eines Blocks finden, der aus Teilen von 4 verschiedenen MPEG2-Blöcken besteht und in denen MPEG2 jeweils andere Anteile weggelassen hat. Solche Blöcke zu finden ist schwerer, weil die "wichtigen" Anteile von 4 Blöcken zu einem neuen Block codiert werden müssen. Dazu muss man vielleicht wissen, dass die Blöcke sehr unterschiedlich zu ihren Nachbarblöcken gespeichert werden. Es ist also nicht einfach, mehrere unter einen Hut zu bringen.

    Diesen Effekt kann man sogar in meiner Messung erkennen (wo maximal 2 MPEG2-Blöcke in einem XviD-Block codiert werden): Eine Verschiebung um 1 oder 15 Zeilen ist weniger schlimm als eine um 4 oder 12. Bei einer Verschiebung um eine Zeile fällt die eine Zeile nicht so ins Gewicht.

  • wow, finde das Thema nach dem 2. Lesen sehr interessant - bei deinem Eröffnungspost hab ich dich aber (wie Nexus) auch nicht gleich verstanden :)

    Bei sehr vielen DVDs liegt es ja nahe 72Pixel oben wie unten abzuschneiden; daß die aber eben nicht mod16 sind - darüber habe ich mir noch nie Gedanken gemacht ...

    Andereseits schneidet man mit 80 Pixel (um mod16 zu croppen) 8 Zeilen mehr vom Bild ab - die Frage ist, ob sich das lohnt...

    Pioneer PDP-427 XA | Popcorn Hour NMT C-200 | Sony STR-DB 840 QS | Canton Ergo 91 DC

  • Zitat von kurt

    Andereseits schneidet man mit 80 Pixel (um mod16 zu croppen) 8 Zeilen mehr vom Bild ab - die Frage ist, ob sich das lohnt...

    Dazu könnte man noch ein paar Messungen machen. Mein Tip wäre:
    Wenn Du 72 Pixel willst (eher weniger), dann nimm 72.
    Wenn Du etwas mehr als 72 willst, nimm direkt 80.
    Und nimm in keinem Fall irgendetwas dazwischen.
    Sobald Du vertikale Skalierung machst, ist alles egal :-).

    P.S.: Der untere Rand ist für den beschriebenen Effekt egal. Aus anderen Überlegungen heraus ist es natürlich gut, wenn er so ist, dass das verbleibende Bild Mod16 ist.

  • Zitat

    Dazu könnte man noch ein paar Messungen machen


    der Unterschied zwischen Mod8 (72 Zeilen) und Mod16 (80 Zeilen) wäre sicher interessant :ja:

    Zitat

    Sobald Du vertikale Skalierung machst, ist alles egal :)


    nene, schon anamorph :)

    Pioneer PDP-427 XA | Popcorn Hour NMT C-200 | Sony STR-DB 840 QS | Canton Ergo 91 DC

Jetzt mitmachen!

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