Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Support zu Fansubs
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

In einem benachbarten Thread haben max2k und ich darüber diskutiert, inwiefern bei einem Video im Seitenformat 16:9 die Wahl der exakten Seitenlängen von 704*396px (exaktes 16:9) bzw. 704*400 (Seiten-Teilbarkeit durch 16) eine Auswirkung bezüglich der Komprimierbarkeit haben könnte.

max2k hat angekündigt, dazu eine Testreihe durchzuführen; ich habe vor, das auch mal auszuprobieren. Ausgangsmaterial sollen dabei jeweils ISO-DVDs sein, um die Ergebnisse nicht durch schlechte Qualität von vornherein zu verzerren. Ich bin mir noch nicht hundertprozentig sicher, wie ein solcher Vergleichstest exakt aussehen müsste, versuche aber mal, meine Vorstellung hier zu skizzieren:

1. ISO-DVD mit DGIndex analysieren. (Eine Unterteilung der Episoden halte ich für nicht notwendig, aber Menus, Trailer, Addons etc. natürlich ausblenden - nur reines Release-Material soll gemessen werden).

2. AVS-Skript zur Erzeugung einer deinterlaceten Version des Videos (TIVTC-Paket für tfm/tdecimate):

Code: Select all

DGDecode_Mpeg2Source("DVD.d2v")
tfm (slow=2)
tdecimate (mode=1)
crop (?,?,-?,-?) # der jeweiligen Episodengruppe anpassen, so wie man auch für ein Release subjektiv entscheiden würde
Keinerlei Filter, der das Ergebnis ebenfalls verzerren könnte. Diese Videos dann HuffYUF-encoded (RGB-Variante "fastest") als AVI speichern.

3.a)-d). Vier AVS-Skripte mit Resize-Anweisungen nach LanczosResize (704,396), BicubicResize (704,396,0,0.750) und beides auch mit 400 statt 396.
Bei der praktischen Umsetzung schwebt mir vor, diesen Schritt mit Schritt 2 zu verbinden, also vier verlustfreie Encodings zu machen. Der Vorteil dabei wäre, dass ich dabei exakter croppen könnte: Wenn ich das Zwischenergebnis der Verarbeitung vor dem Resize abspeichern muss, dann müssen die Seitenlängen zu diesem Zeitpunkt durch 4 teilbar sein; nehme ich jedoch das Resizen in das Skript mit hinein und erzeuge direkt das Zielformat (welches automatisch durch 4 teilbar ist), dann kann ich das Maximum an nicht "verschmutzter" Bildfläche von der DVD verwenden, was mir irgendwie sympathischer ist als erst mehr wegzuschneiden und dann weniger zu stauchen.

4.a)-d) Die Ausgabe eines jeden dieser Skripte in XviD 1-pass mit Qualität 9999 encoden (wobei ich persönlich P-Frames mit einem Quant von 1 verbieten würde, dann kommt genau das heraus, was ich auch releasen würde).

5. Die Größen der entstandenen Dateien vergleichen, um festzustellen, ob bei der Verwendung von 400 statt 396 Bildzeilen die Datei kleiner wird.

Ich bitte um Hinweise, ob in diesem Testverfahren irgend ein systematischer Fehler enthalten ist.
User avatar
jabba
Neko-chan
Neko-chan
Posts: 29
Joined: 29.12.2007 14:49
Gruppe: Winnie Poe

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by jabba »

Vielleicht sind der Thread / Post hilfreich bei eurer Problemfindung:
http://forums.animesuki.com/showthread. ... d16&page=2 (auch wenn es im Verlauf des Threads mehr um Aspect-Ration geht) bzw.
http://forums.animesuki.com/showpost.ph ... stcount=11
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Es ist ja nicht so, dass wir ein Problem hätten. Ich möchte nur gerne selber testen, ob es wirklich Dateigröße einspart (und falls ja, wieviel), wenn man das Bildformat absichtlich größer macht als das exakte 16:9-Verhältnis, indem man von 704*396px auf 704*400px geht, um die Teilbarkeit durch 16 zu gewährleisten. Und dabei möchte ich mein Testergebnis nicht durch einen Denkfehler im Aufbau meines Testszenario versehentlich verfälschen.
Mich persönlich interessiert die Sache deshalb, weil mein Abspielgerät ein 16:9-Fernseher ist (und kein PC-Bildschirm mit schwarzen Balken oben und unten bei 16:9-Videos) - denn bei 4:3-AspectRatio existiert das beschriebene "Problem" gar nicht (640*480px ist bereits mod 16 und etwas Größeres kann ich nicht mehr abspielen).

Der erste angegebene Link ist insofern interessant, als dort ein Encoder meint, er würde 720*480px anamorph-Material zuallererst auf 696*480px (!) croppen (links und rechts jeweils 12px weg) und erst danach resizen, weil "ohnehin nur 702 bzw. 711.85px in der Breite zum tatsächlichen Bildmaterial zählen" (ich habe die Erklärung dafür nur teilweise verstanden, weil ich nicht weiß, welche der vielen "DVD"-Zeilen in diesem Dokument das beschreibt, was ich als "japanische ISO-DVD" bezeichnen würde), das sei so aber die minimale Verzerrung des Verhältnisses zwischen Breite und Höhe... hm, ich habe bisher versucht, so wenig wie möglich wegzucroppen, solange die Pixel nicht deutlich verfärbt waren, und damit gar nicht wirklich das exakte 16:9-Seitenverhältnis des Ausgangsmaterials erhalten.
Die tatsächliche Verzerrung durch eine Abweichung von 4px in der Höhe liegt aber offensichtlich deutlich unterhalb der Bemerkbarkeitsgrenze, sodass wir wieder zu unserem Ausgangspunkt zurückkehren können: "Wird eine XviD-Datei bei gleicher Qualität kleiner, wenn man die Bildfläche vergrößert, um die Teilbarkeit der Seitenlängen durch 16 zu gewährleisten?" Denn das behauptet die mod16-Theorie ja - und die will ich an ein paar praktischen Beispielen überprüfen.

Die Durchführung des beschriebenen Tests dauert bei mir eine Nacht pro DVD, ich könnte ihn also in den nächsten Tagen für eine ganze Reihe meiner DVDs durchlaufen lassen - Arbeit ist das nicht, ich muss eigentlich nur die VirtualDubMod-Tasks schedulen und warten, bis sie fertig sind.
Für die erste DVD habe ich nach dem skizzierten Verfahren Ergebnisse vorliegen - und die mod16-Variante ist tatsächlich kleiner. So richtig spürbar scheint die Einsparung durch die Erweiterung auf 704*400px allerdings nicht zu sein: Bei LanczosResize sind es 0.532% (940 statt 945 kb/s), bei BicubicResize gar nur 0.097% (928 statt 929 kb/s)... hm.
Dass XviD bei mod16 tatsächlich besser komprimiert, ist also offensichtlich (die HuffYUF-Varianten der 704*400px-Versionen sind natürlich jeweils größer als die 704*396px-Versionen, und zwar 0.904% bei LanczosResize und 0.920% bei BicubicResize), aber die Einsparung ist anscheinend nur unwesentlich höher als die zuvor erforderliche Investition.

jabba, magst Du mal die Argumentation für das mechanische Wegcroppen von 8 bzw. 12 pix auf beiden Seiten so auf Deutsch zusammenfassen, dass sie für einen angehenden Encoder verständlich wäre? (Das alleine könnte ein interessanter Fansub-Wiki-Artikel werden.)
User avatar
max2k
Kámi-sama
Kámi-sama
Posts: 631
Joined: 30.12.2007 03:35
Gruppe: BadApple

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by max2k »

Also ich übersetze es nicht, sondern versuch es lieber zu erklären , auch wen mein deutsch wohlmöglich schwerer für dich zu verstehen ist als das englisch ;) .

8 Pixel bei einer NTSC DVD(auch iso von dieser), weil innerhalb dieser pixel gar keine Bilddarstelung stadtfindet, sondern ein Kopierschutz versetckt ist, damit brauchen wir unseren bitstream nun wirklich nicht belasten.

12 Pixel: Eben die 8 Kopierschutz px im nicht sehbaren Beriech. Jetzt wären wir bei 704*396, würden wir jetzt auf 704*400 resizen hätten wir 1% Anarmophitet (was woll auch niemanden aufallen würde). Aber da wie ja möglichs wenig AR Abweichung haben wollen, cropen wir in der Wagerechten noch mal das dopelte an pixeln (16:9 ist mathematisch serh nahe an 2:1) weg was wir in der Senkrechten später reszisen: 4 px :2 Seiten (oben/unten)= 2px * 2 (16/9) = 4px (auf jeder Seite). Also cropen wir links und rechts noch mal 4 px was uns auf 696*396 bringt. Wen wir dieses jetzt auf 704*400 resizen hätten wir einen AR Fehler von ca. 0,2%. (dieser liegt daran das 16:9 eben nicht exakt 2:1 ist ;)) Wer jetzt noch behauptet er würde beim 704*400 Anarmophitet sieht, redet sich was ein. Wie gesagt weren schon der 1% eigentlich nicht wahrnehmbar... Wer aber so "Anal" über mod16 in Xvid geht, kann den auch gleich AR mit einbeziehen.

Bei einer TV Raw im format z.b. 704*396 crope ich auch Standartmäßig 4 Pixel an jeder Seite wagerrechten Seite, um die AR möglichs gleichmäßig zu halten wen ich auf 704*400 gehe. Vorausgestz natürlich ich habe keine wietere bordernoise an den senkrechten Seiten, oder bildfehler die über das cropen in der Wagrechten hinausgehen. Den würde ich anders Cropen und hier bei auch überlegen wie ich die AR möglichsniedrig halte, also auch die anderen Seiten dem entsprechen Cropen. Noch mal zum Thema Anarmophitet von 704*400, ich möchte nicht wissen wie viele 704*396 encodes herumfliegen wo einfach nur die bordernoise gecropt wurde, danach resized, ohne sich gedanken über das AR zu machen. Aber es scheint niemanden aufzufallen :evil:.
Last edited by max2k on 16.02.2008 19:08, edited 4 times in total.
"While at present we have no plans for the franchise [on next-gen consoles]..."

Image
User avatar
Kaoru_Battlemuffin
Senpai
Senpai
Posts: 143
Joined: 29.12.2007 21:35
Gruppe: Gruppe Kampfkuchen

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Kaoru_Battlemuffin »

Wenn du vernünftig cropst und resizest musst du dir keine Gedanken um dir AR machen ;)
Ich crop meist aus prinzip an allen seiten was und resize so das ch den AR beibehalte
Image
Image

Use CCCP9+9, Codename "NEIN NEIN NEIN"
User avatar
max2k
Kámi-sama
Kámi-sama
Posts: 631
Joined: 30.12.2007 03:35
Gruppe: BadApple

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by max2k »

So ich hab Gestern einfach mal von Drei Losslessencodes (alles normale Serien Folgen von Verschieden Animes die ich encode um die 24 minuten länge))die auf meinen HDs herumfliegen Tests gemacht. Alle Drei haben bereits das Format 704*400. Anders als ich, schlaftrunken, im anderen Thread schrieb, hab ich nicht rezised, sondern für die /04*396 Tests ein Avisynthscript erstellt was an den senkrechten Seiten je 2 Pixel cropt. Ich hoffe das diese diese fehlenden Pixel den Test nicht zu sehr verfälscht haben, die Anarmophitet die meine 396 Probanden theoretisch theoretisch haben, solle uns nicht störren, diese werden ja niemals einen 2pass oder gar release sehen.

Test1:

704*400: MVS: 314 Mb ABR: 1400kbps

704*396: MVS: 314Mb ABR: 1400kbs

(seltsam beim am schwierigsten zu komprimirenden Encode ist überhaupt kein Unterschied zu sehen, theoretisch sollte er die stärkste Unterschied zeigen.)

Test2:

704*400: MVS: 183MB ABR: 999kbps

704*396: MVS: 184MB ABR: 1003kbps

( Der Encode der die wenigste Bitrate braucht zeigt den größten Unterschied, auch wen dieser zugegeben sehr gering ist.)

Test3:

704*400: MVS: 242mb ABR: 1318kbps

704*396: MVS: 242mb ABR: 1319kbps

(der mittlere zeigt Grade mal eine Schwankungen von 1 kbps im durschnit der maximalen Bitrate des Encodes)

Encodes warren alle 1pass mit den Selben eintselungen. MVS= Ist die maximale größe des Videostreams die mir beim auslesen des statsfiles mit dem Xvid StatsReader angezeigt wurden. ABR ist die averagebitrate des encodes wie man sie am ende des 1pass ausgegeben kriegt.

Also der Unterschied von der erforderlichen Bitrate her ist sehr gering bis nicht messbar, aber die behauptung das encodes knapp unter mod16 besser zu komprimiren sind, die du im anderen Thread aus dem Doom9 Forum zitiert hast, scheint woll wiederlegt und ich geh davon aus das er auch schon dort deswegen gebasht wurde :evil: . Wen auch sehr geringe, scheint genaues mod16 noch die Vorteile zu haben. Ich werde auf anisuki später noch mal diese Tests posten und fragen ob mod16 nicht nur etwas mit der bitrate zu tun hat, was ich meinte theoretisch verstanden zu haben, sondern vieleicht auch einen anderen Vorteil, z.B. das komprimierungs Artefakt weniger häufig oder aufällig auftreten. Mag auch sein das mein Test durch das einfach croping auf 396 leicht verfälscht wurden, wen ich wieder etwas mehr zeit habe werde ich 2 LL von der selben Raw mit den einstelungen in beiden Auflösung machen und nochmal Testen.


edit:
Kaoru_Battlemuffin wrote:Wenn du vernünftig cropst und resizest musst du dir keine Gedanken um dir AR machen ;)
Ich crop meist aus prinzip an allen seiten was und resize so das ch den AR beibehalte
Zwei Stühle eine Meinung? Genau das selbe behaupte ich ja auch. Das untere war nur ein Argument gegen die Behauptung von 704*396 Encodern: "704*400 wer Anamorph."
"While at present we have no plans for the franchise [on next-gen consoles]..."

Image
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

max2k wrote:Noch mal zum Thema Anarmophitet von 704*400, ich möchte nicht wissen wie viele 704*396 encodes herumfliegen wo einfach nur die bordernoise gecropt wurde, danach resized, ohne sich gedanken über das AR zu machen. Aber es scheint niemanden aufzufallen :evil:.
Ich bekenne mich schuldig. :oops: Immerhin habe ich darauf geachtet, nicht grob asymmetrisch zu croppen, ich hatte aber auch noch nie einen Fall, der mir in dieser Hinsicht Anlass zur Sorge gegeben hätte.
In dem AnimeSuki-Thread wird zudem u. a. erwähnt, dass in manchen Fällen den Leechern nicht mal eine Verzerrung von 10% auffällt (die wohl dann auftritt, wenn ein als anamorph in einem MKV-Container gespeichertes Video aufgrund von Einstellungen oder Eigenheiten des lokalen Abspielprogramms nicht entsprechend gezerrt wird), insofern sind die 0.x% bei den hier diskutierten Varianten weit unterhalb der Schmerzgrenze.

Was ich durch diese Diskussion auf jeden Fall gelernt habe, das ist, beim nächsten Encoding aggressiver zu croppen - denn das, was Du als Kopierschutzinformation bezeichnest, sieht einfach wie normale Bildinformation aus, Bildfehler am Rand sind nach meiner Erfahrung deutlich schmaler als 8 px und die verzerrte AR ist wie gesagt nicht wahrnehmbar.
Hinzu kommt, dass auf meinem Fernseher die von meinem Standalone-Player angezeigten Videos (vermutlich wegen Overscan-Effekten?) an den Rändern nochmal deutlich beschnitten werden (seitlich etwa um etwa 35px, dabei lustigerweise links ein paar Pixel mehr als rechts, und unten um etwa 20px, was ich alles bei der Positionierung meiner Untertitel berücksichtige), deshalb wollte ich im Video selbst lieber zu wenig wegschneiden als zuviel, damit nicht am Ende auf dem Fernseher wesentliche Teile der tatsächlichen Bildinformation fehlen (bei Haibane Renmei gibt es am Ende von Episode 11 eine Szene, wo Reki einen Topf mit Farbe in der Hand hält, auf dem in Roumaji "Paint" steht; dieser Topf ist ganz rechts am Bildrand zu sehen, und wenn man dieses Video zu aggressiv cropped, dann wird daraus "Pain", aua...).

Das mit dem "besser komprimieren als mod16" hatte der besagte Thread übrigens nicht einfach nur behauptet, sondern durch eine umfangreiche Messreihe (mit allen mod-4-Restklassen) zu belegen versucht, die mich ja überhaupt erst auf die Idee gebracht hat, dasselbe auch mal zu probieren.
Für die zweite DVD habe ich das XVID-Encoding heute durchlaufen lassen (diesmal ist die 704*400px-Variante bei LanczosResize um 0.407%, bei BicubicResize um 0.466% kleiner als die 704x396px-Variante, bei 766 statt 769 bzw. 758 statt 762 kbps), für die dritte DVD starte ich den Encoding-Lauf gerade.

Ach ja, wenn wir schon dabei sind: Womit resized man denn eigentlich sinnvollerweise? Ich habe mal irgendwo gelesen, LanczosResize schärft dünne Linien und sei für Animes deshalb gut geeignet, deshalb habe ich es bisher immer benutzt; BicubicResize (x,y,0,0.75) habe ich in einem AVS-Skript entdeckt, das mir mal "zugelaufen ist". Bei meinen aktuellen Tests erzeugt BicubicResize bisher immer etwas kleinere Dateien als LanczosResize, was an der Schärfung von Lanczos liegen könnte...?
User avatar
max2k
Kámi-sama
Kámi-sama
Posts: 631
Joined: 30.12.2007 03:35
Gruppe: BadApple

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by max2k »

Ich glaub bei dem Beispiel mit den 10% ging es um einen encode in einem AVI container, deswegen ja auch die krase Behauptung das den meisten nicht mal das auffällt.

Ja um so schärfer dein Ausgangsmaterial um so schewiriger zu komprimiren ist es, und da Lancoz bekantlich besser schärft als BicubicResize, ist das woll nicht verwunderlich. Ich hab auch schon mit unschärfe einen bestimmten Encode kompimierbarer gemacht, weil die raw schon geschärt war und in einen 240 mb h264 videostream hatte, ich aber auf einen 160 mb xvid stream musste. Ich dachte mir lieber etwas unschärfer als nen Artefaktfest... Leider in den ersten Folgen der Serie nicht ganz stark, weswegen hier noch Artefakte vorhanden sein sollten.

Ich hab aber neulich gelesen Lancoz4Resize, als neben efekt Ringing mit bringt, weswegen man in nur nutzen sollte wen man einen deutlichen upscale macht... Wollte das aber selber auch noch näher testen..
"While at present we have no plans for the franchise [on next-gen consoles]..."

Image
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Testergebnisse (Binbou Shimai Monogatari DVD1-5, jeweils 2 Anime-Episoden gemeinsam encoded)

Deutung:
  • 704*400px spart 0.1-0.5% gegenüber 704*396px, wenn beide durch Resizing entstehen (Spalte "Gewinn").
  • BicubicResize (x,y,0,0.75) produziert konstant ca. 0.4% kleinere Dateien als das leicht "schärfende" LanczosResize (x,y), basierend auf den HuffYUF-Dateigrößen.
User avatar
eXtreme
Anime Gucker
Anime Gucker
Posts: 94
Joined: 29.12.2007 14:41
Gruppe: GAX, GK, Megami(engl), moo-shi(engl)

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by eXtreme »

Devil Doll wrote:Testergebnisse (Binbou Shimai Monogatari DVD1-5, jeweils 2 Anime-Episoden gemeinsam encoded)

Deutung:
  • 704*400px spart 0.1-0.5% gegenüber 704*396px, wenn beide durch Resizing entstehen (Spalte "Gewinn").
  • BicubicResize (x,y,0,0.75) produziert konstant ca. 0.4% kleinere Dateien als das leicht "schärfende" LanczosResize (x,y), basierend auf den HuffYUF-Dateigrößen.
folgender denkfehler:
Auch wenn beide Videos die selben Quants haben heißt das nicht das die Qualität gleich ist. Um das etwas verständlicher zu erklären:

Die Bildqualität kann z.B. um 20% gefallen sein und die Komprimierbarkeit des Frames (Größe) ist dabei gleich geblieben. Selbiges wurde auch im d9 thread angeprangert.

Das heißt du müsste die Dateien auch noch nach PSNR oder noch besser SSIM abgleichen um ein halbwegs guten vergleich zu bekommen.
Those willing to sacrifice liberty for illusory security deserve neither and will lose both. - Benjamin Franklin 1706-1790
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Devil Doll wrote:"Diese Videos dann HuffYUF-encoded (RGB-Variante "fastest") als AVI speichern."
Dieser Umwandlungsschritt verzerrt die Videoqualität und führt zu keinem aussagefähigen Ergebnis. MPEG-2 wird im YV2-Farbraum gespeichert. Durch die Umwandlung nach RGB geht der gesamte Sinn der "mod16-Theorie" verloren. Mod16 existiert nur, weil es Macroblöcke gibt. Man versucht, genau auf der Macroblockgrenze croppen. RGB hat keine Macroblöcke, ergo, kein mod16-Problem.
Devil Doll wrote:"Es ist ja nicht so, dass wir ein Problem hätten. Ich möchte nur gerne selber testen, ob es wirklich Dateigröße einspart (und falls ja, wieviel), wenn man das Bildformat absichtlich größer macht als das exakte 16:9-Verhältnis, indem man von 704*396px auf 704*400px geht, um die Teilbarkeit durch 16 zu gewährleisten."
Man kann definitiv keine Bitrate "einsparen", wenn man den Informationsinhalt vermehrt. Mehr Informationen = mehr Daten die benötigt werden, um diese Informationen abzubilden. Was passieren kann ist, das XviD durch das mod16 effizienter arbeiten kann, als mit nicht-mod16. Das wiederum hat mit der Effizienz der Implementierung bestimmter Algorithmen für aktivierte Optionen und den Macroblockgrenzen zu tun.

:!: Siehe dazu auch eine Test von Brother John.
Devil Doll wrote:"Wird eine XviD-Datei bei gleicher Qualität kleiner, wenn man die Bildfläche vergrößert, um die Teilbarkeit der Seitenlängen durch 16 zu gewährleisten?" Denn das behauptet die mod16-Theorie ja - und die will ich an ein paar praktischen Beispielen überprüfen."
Meiner Meinung nach ist dies nicht die Aussage von mod16. Mod16 bedeutet nur: Höhe/Breite muss glatt durch 16 teilbar sein. (Macroblockgrenzen)
max2k wrote:"8 Pixel bei einer NTSC DVD(auch iso von dieser), weil innerhalb dieser Pixel gar keine Bilddarstellung stattfindet, sondern ein Kopierschutz versteckt ist, damit brauchen wir unseren Bitstream nun wirklich nicht belasten.
Ich weiß das bei PAL Informationen (bspw. Video-Text) auf der PAL-plus / WSS-line übertragen werden. Kopierschutz ist mir neun. Link? Falls wirklich Informationen in diesen 8px übertragen werden, dann nehme ich an, das dieser Bereich "schwarz" ist, und daher eh des croppings bedarf. BTW: Werden diese Informationen bei Denoising zerstört?
max2k wrote:"die behauptung das encodes knapp unter mod16 besser zu komprimiren sind, die du im anderen Thread aus dem Doom9 Forum zitiert hast, scheint woll wiederlegt."
BrotherJohn's Test sage etwas anderes. (beachte mod2- & mod4-) Das Problem hier ist, das eine Resizing durchgeführt wurde, und kein reines Cropping.

:!: Problematisch ist für mich (neben der RGB-Umwandlung), dass Cropping mit Resizing verglichen wird. Cropping reduziert den Informationsinhalt, was (richtig gecroppt) zu geringerem Bitratenbedarf führt. Resizing (auch downsizing) kann zwar auch den Informationsinhalt (sprich Bildfläche) verringern, jedoch entsteht bei jedem resizing temporales noise das sich negativ auf die Komprimierbarkeit auswirken kann. Desweiteren wird hier das Problem der Macroblockgrezen sprichwörtlich "verschoben".
___

BTW: Welche Einstellungen hab Ihr in XviD vorgenommen?
___

:?: Womit ich überhaupt nicht hinterherkomme ist das Resizing/PAR/DAR-Problem. Könntet ihr bitte ein Testschnipsel (~30sec oder mehr, ohne Ton) hochladen? Für mich ist PAL kein Problem. Aber bei NTSC komm ich nicht mehr hinterher. Desweiteren verstehe ich nicht, wie ihr beim reszing die non-square-Problematik außer acht lassen könnt. Soll denn nach dem Resizing kein PAR 1:1 herauskommen (was ich unlogisch fände) oder versteh ich hier etwas falsch?
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

eXtreme wrote:Das heißt du müsste die Dateien auch noch nach PSNR oder noch besser SSIM abgleichen um ein halbwegs guten vergleich zu bekommen.
Womit müsste ich das tun? (Ich habe die XviD-Encodings noch auf der Festplatte.)
Aikousha wrote:
Devil Doll wrote:"Diese Videos dann HuffYUF-encoded (RGB-Variante "fastest") als AVI speichern."
Dieser Umwandlungsschritt verzerrt die Videoqualität und führt zu keinem aussagefähigen Ergebnis. MPEG-2 wird im YV2-Farbraum gespeichert. Durch die Umwandlung nach RGB geht der gesamte Sinn der "mod16-Theorie" verloren.
Hm, was hätte ich denn sonst tun sollen? (Gar nicht HuffYUF, sondern direkt XviD? Ist HuffYUF in diesem Sinne also niemals "lossless"?)
Ich habe innerhalb der XuffYUF-Parameter im Dropdown-Menü auf der rechten Seite ausdrücklich nicht "convert to YUV2" genommen, weil dort steht: "Convert to YUV2 compresses slightly better than any other RGB option; however, this conversion is slightly lossy - the original RGB data cannot be recovered exactly (not that it usually matters)". Da es in meinem Fall aber gerade doch "matters", habe ich auf diese Möglichkeit verzichtet. Ich habe auch "fast recompress" genommen (sowohl für die HuffYUV- als auch für die nachfolgende XviD-Komprimierung), um eben gerade jegliche überflüssige Farbraum-Konvertierung zu vermeiden.
Ah, das ist genau der Thread, den ich in meinen vorherigen Postings meinte.
Aikousha wrote:
Devil Doll wrote:"Wird eine XviD-Datei bei gleicher Qualität kleiner, wenn man die Bildfläche vergrößert, um die Teilbarkeit der Seitenlängen durch 16 zu gewährleisten?" Denn das behauptet die mod16-Theorie ja - und die will ich an ein paar praktischen Beispielen überprüfen."
Meiner Meinung nach ist dies nicht die Aussage von mod16. Mod16 bedeutet nur: Höhe/Breite muss glatt durch 16 teilbar sein. (Macroblockgrenzen)
...um was zu erreichen? So wie von Dir formuliert ist das ja überhaupt keine Aussage - zumindest keine korrekte. Denn müsste die Höhe/Breite generell durch 16 teilbar sein, dann müsste es ja unmöglich sein, einen Videostream mit 704*396px überhaupt zu erzeugen.
Mir geht es nicht um die (triviale) Bedeutung der Formulierung "mod 16", sondern um die Ergebnisse von Brother Johns Test, der - so, wie ich seine Ergebnisse interpretiere - die Theorie stützt, dass Komprimierung eines Videostreams mit mod16-Seitengrenzen effizienter sei als Komprimierung eines 704*396px-Videos mit exaktem 16:9. max2k ging nun darüber hinaus soweit, zu empfehlen, generell nicht 704*396px, sondern gleich 704*400px zu encoden, um kleinere Dateien zu erzeugen - was ich an einem praktischen Beispiel überprüfen wollte. Dabei würde ich selbst ungern von 704*396px abweichen wollen, wenn es dafür nicht massive Gründe gibt - und bei Brother John zeigen die Ergebnisse ja zwar eine höhere Effizienz, aber keine so große Einsparung, dass dadurch die Vergrößerung der Fläche überkompensiert würde. Meine eigenen Mess-Ergebnisse deuten nun allerdings überraschenderweise das Gegenteil an - was mich entsprechend verwirrt.
Aikousha wrote:Falls wirklich Informationen in diesen 8px übertragen werden, dann nehme ich an, das dieser Bereich "schwarz" ist, und daher eh des croppings bedarf.
Solche Bereiche habe ich dann auf noch keiner einzigen ISO-DVD gesehen: Wegcroppen schwarzer bzw. verfärbter Randbereiche war bei mir noch nie schlimmer als 6px auf einer einzelnen Seite, im Schnitt 2-4px pro Rand.
Aikousha wrote:BTW: Welche Einstellungen hab Ihr in XviD vorgenommen?
H.263-Matrix, QPel, NVOP, max. 4 aufeinanderfolgende BVOPs, Single Pass 9999 kb/s, Chroma Optimizer an, Trellis Quantization, Quants [I:1-31, P:2-31, B:2-31], Motion Search Precision 6, VHQ mode 4, VHQ for B-Frames too, Chroma motion; der Rest müssten die XviD-Defaultwerte sein IIRC. ("mod16.vcf" liegt diesem Posting bei.)
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Für SSIM gibt es ein AviSynth-Plugin.

Um eine Farbraum-Konvertierung wird man nicht umhin kommen. Auch AviSynth arbeitet intern mit einem anderen Farbraum, als MPEG-2. Das ist allerdings nicht gerade mein Spezialgebiet. Ich habe mich wahrscheinlich auch etwas unverständlich ausgedrückt, Entschuldigung. Was ich meinte ist, das eine Umwandlung von YV2 -> RGB in meinen Augen eher ein unnötiger Schritt ist, der zusätzlich das Ergebnis verzerren kann, nicht muss! Persönlich würde ich diesen Schritt weglassen und direkt AVS -> XviD (v.a. da hier kein 2pass möglich ist). Über das Thema lossless könnte man jetzt Seitenweise diskutieren. Mann sollte sich hier v.a. vor Augen halten, das MPEG-2 schon selbst nicht verlustlos ist. Dies ist beabsichtigt und auch verständlich, da sonst nicht stundenweise Film auf eine DVD passen würde.
Devil Doll wrote:So wie von Dir formuliert ist das ja überhaupt keine Aussage - zumindest keine korrekte. Denn müsste die Höhe/Breite generell durch 16 teilbar sein, dann müsste es ja unmöglich sein, einen Videostream mit 704*396px überhaupt zu erzeugen.
Mir persönlich ist wichtig, die Aussage von mod16 (durch 16 teilbar) und das warum (die Hintergründe) zu trennen. Falls meine Aussage so aufgefasst wurde, das alles andere als mod16 unmöglich ist, wäre dies natürlich falsch. Für uns ist interessant, warum mod16, anderen ist das zu hoch. Diese sollten einfach Wissen: Mein Videobild sollte möglichst durch 16 teilbar sein, nicht mehr.
Devil Doll wrote:Mir geht es nicht um die (triviale) Bedeutung der Formulierung "mod 16", sondern um die Ergebnisse von Brother Johns Test, der - so, wie ich seine Ergebnisse interpretiere - die Theorie stützt, dass Komprimierung eines Videostreams mit mod16-Seitengrenzen effizienter sei als Komprimierung eines 704*396px-Videos mit exaktem 16:9. max2k ging nun darüber hinaus soweit, zu empfehlen, generell nicht 704*396px, sondern gleich 704*400px zu encoden, um kleinere Dateien zu erzeugen - was ich an einem praktischen Beispiel überprüfen wollte. Dabei würde ich selbst ungern von 704*396px abweichen wollen, wenn es dafür nicht massive Gründe gibt - und bei Brother John zeigen die Ergebnisse ja zwar eine höhere Effizienz, aber keine so große Einsparung, dass dadurch die Vergrößerung der Fläche überkompensiert würde. Meine eigenen Mess-Ergebnisse deuten nun allerdings überraschenderweise das Gegenteil an - was mich entsprechend verwirrt.
Das ein Komprimierung mit mod16 effizienter ist, als eine Komprimierung mit nicht-mod16 hat Brother John ja bewiesen. Ich denke dies sollte unstrittig sein. In Brother Johns Test ging es nicht um eine Vergrößerung der Bildfläche, sondern um den Effizienzverlust bei der Abweichung von mod16. Es ist richtig, das eine geringeres cropping, mehr Bildinformationen übrig lässt und demzufolge dann auch mehr Bitrate erfordert (mod16+x aka mod2+ oder mod4+). Warum mod2- und mod4- sogar besser sein können, als mod16 hat Brother John dort auch hinreichend erklärt. (Sein können, bei seinen Samples, es kann auch ein Effizienzverlust wie bei modx+ oder mod8 auftreten. Vgl. auch dazu die x264-Tests).
Brother John: Test: Auswirkung von Nicht-Mod16-Auflösungen auf die Encodereffizienz (XviD) wrote:"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."
Ums es nochmals deutlich zu sagen: Die "Einsparung" die bei Brother Johns Test herausgekommen ist, tritt bei seinem Test bei den Sampels auf, wo der Bildinhalt um 2 (mod16-2) bzw. 4 (mod16-4) Pixelreihen reduziert wurde. Diese Einsparung kann passieren, muss aber nicht. Für mich deutet es eher darauf hin, das bei seinen Samples die interne Berechnung zur Ergänzung der Pixelreihen auf mod16 den Effizienzverlust durch nicht-mod16 überkompensiert hat. (XviD rechnet intern mit mod16) Ich sag es gern nochmal. Soetwas kann passieren, ist aber nicht die Regel.

Die Tests, die du und max2k gemacht haben, sind nicht mit denen von Brother John vergleichbar! Getestet wird, ob eine Resizing auf mod16 (704*400) effizienter ist, als auf mod16-2 (704*396p). Und dies scheint der Fall zu sein (wenn auch, wie auch in Brother Johns Test, in einer Größenordnung die vernachlässigbar sein kann).
Meine Anmerkung bezügliche der Macroblock-Problematik (der Ursache, warum mod16 empfohlen wird) und Resizing hatte ich schon erläutert.
___

Ich Entschuldige mich, falls meine Post etwas klugscheißerisch klingen. Ich weiß einfach nicht, wie ich es besser Ausdrücken könnte und lasse mich gerne korrigieren.
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
User avatar
eXtreme
Anime Gucker
Anime Gucker
Posts: 94
Joined: 29.12.2007 14:41
Gruppe: GAX, GK, Megami(engl), moo-shi(engl)

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by eXtreme »

Devil Doll wrote:Womit müsste ich das tun? (Ich habe die XviD-Encodings noch auf der Festplatte.)
Avisynth besitzt eine Compare() Funktion die 2 clips Input hat und eine Datei.log als Textdatei ausgibt. (kann PSNR obs auch SSIM kann ka)
Dafür gibts wie auch schon gesagt nen plugin..

Genaue benutzung kannst entweder im avisynth manual oder du fragst mich einfach. ;)
Das funktioniert allerdings nur mit 2 Videos gleicher Auflösung, du müsstest als immer die lossless mit den xvids vergleichen.
Devil Doll wrote: Hm, was hätte ich denn sonst tun sollen? (Gar nicht HuffYUF, sondern direkt XviD? Ist HuffYUF in diesem Sinne also niemals "lossless"?)
Ich habe innerhalb der XuffYUF-Parameter im Dropdown-Menü auf der rechten Seite ausdrücklich nicht "convert to YUV2" genommen, weil dort steht: "Convert to YUV2 compresses slightly better than any other RGB option; however, this conversion is slightly lossy - the original RGB data cannot be recovered exactly (not that it usually matters)". Da es in meinem Fall aber gerade doch "matters", habe ich auf diese Möglichkeit verzichtet. Ich habe auch "fast recompress" genommen (sowohl für die HuffYUV- als auch für die nachfolgende XviD-Komprimierung), um eben gerade jegliche überflüssige Farbraum-Konvertierung zu vermeiden.
Im Prinzip hat Aikousha recht, allerdings ist das Video auf der DVD in yuv2(4:2:2) moderne Codecs arbeiten atm ausschließlich mit YV12 (4:2:0). (Obwohl für x.264 im High profile auch bald in 4:2:2 und 4:4:4 arbeiten soll) na wer macht nen patch? :mrgreen:
Also verliert man auf jeden fall Chroma informationen wenn mal dvd-->mpeg4 macht. Allerdings ist YV12 auch einer der kleinsten farbräume sodass er sehr gut komprimierbar ist.

Also ich fasse zusammen DVD(yuv2)-->RGB 32 ist nicht lossless auch wenn der Farbraum RGB32 "größer" ist als yuv2. Qualität sollte man aber eher nicht verlieren... außer man hört das Gras wachsen ;).
Die Variante DVD-->RGB32->YV12 ist die schlechteste Variante.
Was auch nich lossless ist, ist DVD-->ffvh (labavcodecs yv12 huffy mit adaptiven huffman tables)
DVD-->Lagarith yv12

Aber das würde eine Version werden die gut mit den jeweiligen XVid encodes vergleichen kann. Man kann natürlich auch auch fach nen avs script mit dem xvid vergleichen und sich den lossless step sparen.

Aikousha wrote: Mir geht es nicht um die (triviale) Bedeutung der Formulierung "mod 16", sondern um die Ergebnisse von Brother Johns Test, der - so, wie ich seine Ergebnisse interpretiere - die Theorie stützt, dass Komprimierung eines Videostreams mit mod16-Seitengrenzen effizienter sei als Komprimierung eines 704*396px-Videos mit exaktem 16:9. max2k ging nun darüber hinaus soweit, zu empfehlen, generell nicht 704*396px, sondern gleich 704*400px zu encoden, um kleinere Dateien zu erzeugen - was ich an einem praktischen Beispiel überprüfen wollte. Dabei würde ich selbst ungern von 704*396px abweichen wollen, wenn es dafür nicht massive Gründe gibt - und bei Brother John zeigen die Ergebnisse ja zwar eine höhere Effizienz, aber keine so große Einsparung, dass dadurch die Vergrößerung der Fläche überkompensiert würde. Meine eigenen Mess-Ergebnisse deuten nun allerdings überraschenderweise das Gegenteil an - was mich entsprechend verwirrt.
Wie gesagt es könnte sein das die 704x400 datei jetzt aber 20% bessere bildqualität hat aber nur 2%größer ist.... Mir fehlt die Variable Bildqualität in beiden Tests.
Aikousha wrote:Falls wirklich Informationen in diesen 8px übertragen werden, dann nehme ich an, das dieser Bereich "schwarz" ist, und daher eh des croppings bedarf.
"Aktuelle" RC2 dvds muss man oft nicht mal mehr croppen :) Und das im schwarzen Rand der Kopierschutz ist btw schwachsinn.
Last edited by eXtreme on 24.02.2008 00:34, edited 1 time in total.
Those willing to sacrifice liberty for illusory security deserve neither and will lose both. - Benjamin Franklin 1706-1790
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Aikousha wrote:Für uns ist interessant, warum mod16, anderen ist das zu hoch. Diese sollten einfach Wissen: Mein Videobild sollte möglichst durch 16 teilbar sein, nicht mehr.
Aber bevor ich das in einen Fansub-Wiki-Artikel schreibe, will ich wissen, warum. Vielleicht überzeugen mich die möglichen Vorteile ja nicht.
Aikousha wrote:Das ein Komprimierung mit mod16 effizienter ist, als eine Komprimierung mit nicht-mod16 hat Brother John ja bewiesen. Ich denke dies sollte unstrittig sein.
Brother John zeigt (durch Vergleich von Zeile 1 mit Zeile 4 seiner Tabellen), dass mod16 besser ist als mod16+4 (das in allen fünf Beispielen größere Dateien erzeugt).
Aber der für mein Szenario relevante Vergleich ist doch derjenige zwischen mod16+0 (und zwar Zeile 2 mit der größeren Fläche, das entspricht 704*400px) und mod16-4 (Zeile 5, das entspricht 704*396px). Und hier ist das Testergebnis keineswegs eindeutig: Bei den Samples 1-4 liefert die Variante mod16-4 die kleinere Datei, bei den Samples 5 und 6 die größere.
Es ist also IMHO keineswegs bewiesen, dass sich die Erhöhung der Auflösung um 4px, um dadurch mod16-0 zu werden, lohnt - Brother John zeigt nur, dass es sich nicht lohnt, von exaktem mod16-0 nach oben abzuweichen. Ich will aber nach unten abweichen (und zwar um 4px)... weil ich eben von vornherein gar kein exaktes mod16 habe, sondern dieses nur durch Bildvergrößerung erreichen könnte.
Und genau weil die Ergebnisse von Brother John in dieser Hinsicht nicht eindeutig sind, finde ich eigene Tests (und die Diskussion hier) spannend.
Aikousha wrote:Ich Entschuldige mich, falls meine Post etwas klugscheißerisch klingen.
Überhaupt nicht. Ich empfinde diesen Thread als Unterricht und sauge gierig alles auf, was ich daraus lernen kann.

Was die "Nachmessung" meiner DVDs angeht, so muss ich erst mal mit der empfohlenen Software umgehen lernen. "compare" hilft mir vermutlich nicht, meine unterschiedlich formatierten XviDs gegeneinander abzugleichen; das SSIM-Plugin installiere ich gleich noch (urgh... das ZIP-Archiv enthält nur die DLL, kein README, und die angegebene französische Homepage existiert nicht mehr... hm, Doom9-Thread lesen...). Ich wäre allerdings überrascht, wenn die Qualität der Encodings signifikant streuen würde, denn XviD hatte ja angesichts von "Single Pass 9999 kb/s" doch eigentlich keinen Grund, weniger als "die bestmögliche Qualität zu erzielen"... oder?

EDIT: Auch SSIM kann Videos unterschiedlicher Auflösung nicht vergleichen. Was nun? Ich könnte mit SSIM vergleichen, ob XviD besser oder schlechter komprimieren würde als DivX; ich könnte damit 1-pass mit 2-pass vergleichen oder die Wirkung einer Zonen-Definition messen. Aber für meine Fragestellung scheint es mir nichts zu nützen.
eXtreme wrote:Das funktioniert allerdings nur mit 2 Videos gleicher Auflösung, du müsstest als immer die lossless mit den xvids vergleichen.
Das kann ich aber gar nicht tun. Ich habe ein Original-Video (egal ob in MPEG2 oder in irgend einem lossless-Format), welches genau eine exakte Auflösung hat; dieses kann ich anscheinend nur mit einem Video derselben Auflösung vergleichen. Ich müsste also zuallererst mal zwei verschieden "resizete" Lossless-Encodings anfertigen (damit der Vergleichsoperator überhaupt anwendbar ist). Damit habe ich aber doch bereits Einfluss auf die Qualität genommen... ich sehe ja, dass beispielsweise LanczosResize und BicubicResize unterschiedlich große Lossless-Ausgaben erzeugen.
Mich interessiert nur, ob am Ende die 704*396px-Version besser oder schlechter ist als die 704*400px-Version. Ein Referenz-Video, welches sowohl 704*396px als auch 704*400px hat, kann es aber nicht geben. Habe ich hier irgend ein Verständnisproblem?
eXtreme wrote:Also verliert man auf jeden fall Chroma informationen wenn mal dvd-->mpeg4 macht.
Ja, aber was hat das mit meinem Szenario zu tun? Am Ende encode ich in beiden Fällen nach XviD (das ist ja das an die Leecher auszuliefernde Zielformat und steht in meinem Szenario nicht zur Diskussion).
Die Frage ist IMHO nur, ob der Zwischenschritt nach HuffYUF das Ergebnis verfälscht oder nicht (und falls ja, ob das an meinen HuffYUF-Parametern lag und mit anderen Parameterwerten vermeidbar wäre).
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Devil Doll wrote:Aber bevor ich das in einen Fansub-Wiki-Artikel schreibe, will ich wissen, warum. Vielleicht überzeugen mich die möglichen Vorteile ja nicht.
Hmm, ok. Ich hab dich bei "uns" mit eingeschlossen und bin davon ausgegangen, dass du weißt, warum man mod16 verwendet. Falls dies noch unklar sein sollte, bitte ich darauf hinzuweisen. Über die möglichen Vorteile (oder auch Nachteile) diskutieren wir ja gerade anhand ein bestimmtes Szenarios.
Devil Doll wrote:Das kann ich aber gar nicht tun. Ich habe ein Original-Video (egal ob in MPEG2 oder in irgend einem lossless-Format), welches genau eine exakte Auflösung hat; dieses kann ich anscheinend nur mit einem Video derselben Auflösung vergleichen. Ich müsste also zuallererst mal zwei verschieden "resizete" Lossless-Encodings anfertigen (damit der Vergleichsoperator überhaupt anwendbar ist). Damit habe ich aber doch bereits Einfluss auf die Qualität genommen... ich sehe ja, dass beispielsweise LanczosResize und BicubicResize unterschiedlich große Lossless-Ausgaben erzeugen.
Das ist ein wirkliches Problem. Aus der Quelle ein vorgefertigten und passenden lossless-resize zu erstellen halte ich eher für den verkehrten Weg. Dann doch lieber über die Dateigröße urteilen, mit CQ (Constant Quantizer) sollte das gehen. Allerdings kenne ich mich mit XviD überhaupt nicht mehr aus, seit dem x264 dreistellige Build-Nummern hat, eXtreme kann dazu bestimmt mehr sagen.
Devil Doll wrote:Die Frage ist IMHO nur, ob der Zwischenschritt nach HuffYUF das Ergebnis verfälscht oder nicht (und falls ja, ob das an meinen HuffYUF-Parametern lag und mit anderen Parameterwerten vermeidbar wäre).
Ob der Zwischenschritt nach HuffYUV wirklich das Ergebnis verfälschen kann, müsste man extra Testen (bspw. mit SSIM). Wobei das auch wiederum fraglich ist, da die Quelle ja schon selbst nicht lossless ist, und auch AviSynth intern eine Farbraumkonvertierung durchführt, die wiederum das Ergebnis verfälschen kann (wenn man den bspw. eine AviSynth-Plugin nutzt). Zu reinen Testzwecken würde ich alles weglassen, was irgendwie ungewollt das Ergebnis beeinflussen kann. In der praktischen Anwendung kann eine lossless-Encode durchaus sinnvoll sein, dabei wird aber meist vorher sowieso soviel gefiltert (und damit Pixel "durcheinandergeworfen") das die Farbraumkonvertierung kaum ins Gewicht fällt.
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Aikousha wrote:Ob der Zwischenschritt nach HuffYUV wirklich das Ergebnis verfälschen kann, müsste man extra Testen (bspw. mit SSIM).
Ich habe gerade DVD1 in 704*396px Lanczos nochmal encoded, diesmal direkt nach XviD ohne Zwischenschritt mit HuffYUF. Ergebnis: Die Datei ist exakt genauso groß wie mit dem Zwischenschritt. Das scheint die "lossless"-Eigenschaft von HuffYUF wieder zu stützen - zumindest, solange dort nicht von RGB nach YUY2 umcodiert wird (wovor der Codec ja auch warnt).
Diese letztgenannte Variante werde ich mal als nächste durchlaufen lassen, um zu sehen, ob sich dann vielleicht etwas ändert (denn im praktischen Einsatz würde ich gerne die bestmögliche verlustfreie Komprimierung verwenden, die keinen negativen Einfluss auf das spätere Encoding-Ergebnis hat).
EDIT: Auch die Verwendung von HuffYUF mit Umcodierung nach YUY2 führt bei anschließendem XviD-encoden mit 1-pass 9999 kb/s wieder zu einer AVI-Datei mit exakt gleicher Größe wie bei beiden vorherigen Versuchen (und zu SSIM-Werten von konstant 1.0000 beim paarweisen Vergleich dieser drei Encodings untereinander). Seltsamerweise ist allerdings auch die Größe der HuffYUF-Datei konstant geblieben, obwohl ich die HuffYUF-Encoding-Parameter geändert habe...!?
Aikousha wrote:Wobei das auch wiederum fraglich ist, da die Quelle ja schon selbst nicht lossless ist
Spielt das eine Rolle? Es geht um eine Transformation relativ zu einer konstanten Ausgangsposition - wie diese entstanden ist, muss doch egal sein. Dass die Quelle in MPEG2, also verlustbehaftet ist, gilt für alle DVD-ISOs und kann deshalb kein Argument für oder gegen eine Entscheidung zwischen 704*396px und 704*400px sein (welches ich aber gerade suche).
Aikousha wrote:und auch AviSynth intern eine Farbraumkonvertierung durchführt, die wiederum das Ergebnis verfälschen kann
Spielt das eine Rolle, wenn in allen Varianten immer dieselbe Farbraumtransformation durchgeführt wird, ausgehend von einem identischen MPEG2-Material? Sofern die Farbraumtransformation vor dem Resize stattfindet (also schon beim Zugriff auf die MPEG2-Source), müsste bis zum Moment des Resizing noch ein identischer Videostream vorliegen. Erst dem Resize beginnen die Wege, sich zu trennen.
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Devil Doll wrote:
Aikousha wrote:Wobei das auch wiederum fraglich ist, da die Quelle ja schon selbst nicht lossless ist
Spielt das eine Rolle? Es geht um eine Transformation relativ zu einer konstanten Ausgangsposition - wie diese entstanden ist, muss doch egal sein. Dass die Quelle in MPEG2, also verlustbehaftet ist, gilt für alle DVD-ISOs und kann deshalb kein Argument für oder gegen eine Entscheidung zwischen 704*396px und 704*400px sein (welches ich aber gerade suche).
Nein, es spielt keine Rolle.
Devil Doll wrote:
Aikousha wrote:und auch AviSynth intern eine Farbraumkonvertierung durchführt, die wiederum das Ergebnis verfälschen kann
Spielt das eine Rolle, wenn in allen Varianten immer dieselbe Farbraumtransformation durchgeführt wird, ausgehend von einem identischen MPEG2-Material? Sofern die Farbraumtransformation vor dem Resize stattfindet (also schon beim Zugriff auf die MPEG2-Source), müsste bis zum Moment des Resizing noch ein identischer Videostream vorliegen. Erst dem Resize beginnen die Wege, sich zu trennen.
Nein, es spielt keine Rolle. Da bei allen Tests AviSynth verwendet wird, ist das "Problem" bei allen Samples gleich vorhanden; ergo kann es getrost vernachlässigt werden.
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
User avatar
eXtreme
Anime Gucker
Anime Gucker
Posts: 94
Joined: 29.12.2007 14:41
Gruppe: GAX, GK, Megami(engl), moo-shi(engl)

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by eXtreme »

eins vorweg meine zeit ist atm knapp ^^'

Also ich dachte ich hätte das vorher schon gesagt aber egal.
Kein Program kann unterschiedliche Auflösungen vergleichen, aber das brauchen wir auch gar nicht.
Wir können auch so zu einem aussagekräftigen Ergebnis kommen. Und zwar:
Wir haben unser ursprungsvideo (704x396)
das Encoden wir zu xvid, dieses vergleichen wir denn mit unserem ursprungsvideo.

Jetzt kriegen wir das ergebnis das die SSIM auf 0.85 gefallen ist (1.0 wäre lossless).

Danach machen wir ein lanzcosresize 704x400 (beispiel) und encoden wieder zu xvid.
Wir vergleichen jetzt das AVS script (das ja wie die xvid datei die auflösung 704x400 hat) mit dem encodeten file.

Nehmen wir einmal an das Resultat wäre 0.86 SSIM. Das würde bedeuten das in der Tat der Verlust beim komprimieren bei einer mod 16 Auflösung geringer ist. oder halt auch nicht... We will see...

Nebenbei der der umweg über huffy ist einfarbraum wechsel und prinzipiell auch lossy allerdings(!) lassen sich alle yv12 werte auch in RGB32 darstellen und wenn man das ganze wieder in YV12 packt kommen logischerweise die selben Werte wie vor dem wechsel raus. Allerdings verliert man arg geschwindigkeit bei dem hin und hergerechne... Desweiteren siehe ich mit den heuteigen alternative wie ffdshow's yv12 huff und dem noch besseren lagarith keinen grund mehr noch auf huffy zu setzen.
Wer decoding speed will nimmt ffdshow und wer maximale kompression will lags.
Those willing to sacrifice liberty for illusory security deserve neither and will lose both. - Benjamin Franklin 1706-1790
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

eXtreme wrote:Desweiteren siehe ich mit den heuteigen alternative wie ffdshow's yv12 huff und dem noch besseren lagarith keinen grund mehr noch auf huffy zu setzen.
Wenn Lagarith 1.3.13. auf meinem PC nicht permanent in eine Endlosschleife laufen würde, dann würde ich es ja durchaus verwenden wollen.
HuffYUF 2.2. hat übrigens dieselbe Macke, deshalb musste ich auf die vorherige Version 2.1.1. downgraden, die als einzige bei mir zuverlässig funktioniert.
eXtreme wrote:Wir haben unser ursprungsvideo (704x396)
Nein, genau das haben wir eben nicht. Wir haben eine DVD-ISO mit 720*480px anamorph, und wohin wir das sinnvollerweise resizen, das ist ja genau das Problem, welches hier untersucht werden soll.

Ich kann aber zwei unterschiedlich resizete Video-Streams erzeugen (notfalls auch unkomprimiert, falls das Ergebnis dadurch exakter wird, was ich inzwischen allerdings bezweifle, denn ganz ohne AVS werde ich nicht resizen können - die jeweils knapp 30 GB Dateigröße kriege ich temporär auf meiner Festplatte unter) und dieses dann jeweils mit der zugehörigen XviD-Version vergleichen... ich hoffe, so meintest Du das?

Und welcher SSIM-Wert ist denn der aussagefähige - meinst Du den "Average SSIM", der vom Plugin in die Textdatei geschrieben wird? Und wie kriege ich SSIM sinnvollerweise dazu, das komplette Video zu vergleichen - Abspielen im Zoomplayer? (Derzeit verwende ich VirtualDubMod in "Output Playback", aber das dauert ungefähr Realzeit, also eine gute halbe Stunde pro DVD, und damit länger als das unkomprimierte Encoden und Resizen selbst...)

Angenommen, ich habe hierbei richtig geraten, dann habe ich jetzt Vergleichswerte für die erste DVD und das BicubicResize-Verfahren anzubieten:
Image
Woraus ich spontan schließen würde, dass die 0.345% Einsparung bei der Dateigröße mit 0.005% Verlust beim SSIM relativ preisgünstig bezahlt wurden... richtig?

Der SSIM-Wert scheint zudem erfreulich hoch auszufallen (bei 892 kb/s Video-Stream), relativ zu Deiner Schätzung von 85%... gibt es in dieser Hinsicht Erfahrungswerte für DVD-ISOs?
Post Reply

Who is online

Users browsing this forum: No registered users and 23 guests