Hab mal nen kleinen Test mit crf21 und vergleich zwischen Mod16 mit Balken (2 Pixel groß) und Mod4 ohne Balken gemacht: Die Mod16 Version war ungefähr 5% größer, abgerundet.
Wäre es nicht sinniger gewesen jeweils mod4 und mod 16 ohne schwarze Ränder zu vergleichen, nachdem festgestellt wurde, dass Schwarze Ränder 'böse' sind?
Cu Selur
Wäre es nicht sinniger gewesen jeweils mod4 und mod 16 ohne schwarze Ränder zu vergleichen, nachdem festgestellt wurde, dass Schwarze Ränder 'böse' sind?
Also für mich war's interessant zu wissen, ob mod16 (mit schwarzen Rändern) mehr Gewicht hat als mod4 (ohne schwarze Ränder).
Ein neuer Test mit mod16 und mod4 (beides ohne Ränder) wäre natürlich auch interessant. 
Wäre es nicht sinniger gewesen jeweils mod4 und mod 16 ohne schwarze Ränder zu vergleichen, nachdem festgestellt wurde, dass Schwarze Ränder 'böse' sind?
Cu Selur
Nein, in dem speziellen Fall wäre das nicht sinnvoll gewesen.
Ich kann aber mal schnell Elephants Dream durchlaufen lassen.
Edit: Testergebniss
--crf 20 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 7 --analyse all --8x8dct --vbv-maxrate 25000 --me esa --threads 2 --thread-input --progress --output "F:\x264test\ed.mp4" "F:\x264test\ed.avs"
DirectShowSource("F:\x264test\ED 720x400 uncompressed.mp4",fps=25,audio=false)
[crop( 0, 0, -2, -2)]
avis [info]: 1024x576 @ 25.00 fps (16345 frames)
x264 [warning]: threads are not yet compatible with ESA
x264 [info]: using SAR=16/11
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [warning]: VBV maxrate specified, but no bufsize.
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:157 Avg QP:16.91 size: 53250 PSNR Mean Y:53.06 U:58.30 V:57.98 Avg:53.85 Global:50.55
x264 [info]: slice P:10447 Avg QP:19.02 size: 17678 PSNR Mean Y:47.94 U:54.86 V:54.65 Avg:49.00 Global:46.19
x264 [info]: slice B:5741 Avg QP:20.72 size: 4777 PSNR Mean Y:47.29 U:53.58 V:53.36 Avg:48.34 Global:45.66
x264 [info]: mb I I16..4: 35.0% 52.3% 12.6%
x264 [info]: mb P I16..4: 6.8% 7.2% 1.3% P16..4: 33.2% 10.9% 5.2% 0.6% 0.3% skip:34.6%
x264 [info]: mb B I16..4: 0.3% 0.7% 0.3% B16..8: 18.7% 1.4% 2.9% direct: 2.4% skip:73.4%
x264 [info]: 8x8 transform intra:47.8% inter:57.5%
x264 [info]: direct mvs spatial:90.1% temporal:9.9%
x264 [info]: ref P 73.1% 16.0% 5.8% 5.1%
x264 [info]: ref B 82.9% 10.2% 4.3% 2.6%
x264 [info]: SSIM Mean Y:0.9893569
x264 [info]: PSNR Mean Y:47.764 U:54.442 V:54.227 Avg:48.816 Global:46.023 kb/s:2697.63encoded 16345 frames, 8.84 fps, 2697.77 kb/s
desired video bitrate of this job: 20 kbit/s - obtained video bitrate (approximate): 2699 kbit/s
avis [info]: 1020x572 @ 25.00 fps (16345 frames)
x264 [warning]: threads are not yet compatible with ESA
x264 [warning]: width or height not divisible by 16 (1020x572), compression will suffer.
x264 [info]: using SAR=16/11
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [warning]: VBV maxrate specified, but no bufsize.
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:163 Avg QP:17.69 size: 48473 PSNR Mean Y:51.06 U:55.64 V:55.31 Avg:51.70 Global:48.50
x264 [info]: slice P:8242 Avg QP:19.67 size: 18163 PSNR Mean Y:47.20 U:54.29 V:54.15 Avg:48.28 Global:45.42
x264 [info]: slice B:7940 Avg QP:21.32 size: 4755 PSNR Mean Y:46.40 U:52.39 V:52.13 Avg:47.42 Global:45.00
x264 [info]: mb I I16..4: 33.3% 44.9% 21.9%
x264 [info]: mb P I16..4: 7.6% 9.4% 2.2% P16..4: 30.6% 10.5% 5.2% 0.6% 0.3% skip:33.7%
x264 [info]: mb B I16..4: 0.3% 0.8% 0.4% B16..8: 17.4% 1.5% 3.1% direct: 2.4% skip:74.1%
x264 [info]: 8x8 transform intra:49.1% inter:46.0%
x264 [info]: direct mvs spatial:92.3% temporal:7.7%
x264 [info]: ref P 66.3% 19.2% 7.7% 6.8%
x264 [info]: ref B 84.6% 8.9% 4.0% 2.6%
x264 [info]: SSIM Mean Y:0.9874897
x264 [info]: PSNR Mean Y:46.850 U:53.378 V:53.181 Avg:47.894 Global:45.233 kb/s:2390.43encoded 16345 frames, 8.90 fps, 2390.57 kb/s
desired video bitrate of this job: 20 kbit/s - obtained video bitrate (approximate): 2392 kbit/s
Tja, das Ergebnis verwirrt mich. Mod4 ergibt ne wesentlich kleinere Datei, fast die gleiche (rechnerische) Qualität, was ja allerdings nicht sein sollte.
Was auch ein Problem ist: Elephants Dream ist von Haus aus mit schwarzen Rändern versehen: Ich habe daher einmal diese komplett weggecroppt und auf 720x400 rezised und mit x264lossless komprimiert. Das wollte ich dann für einen weitern Test nehmen, um auch sicher zu gehen dass keinerlei schwarzen Ränder vorhanden sind.
Allerdings ist genau das der Fall und zwar an der exakt selben Stelle wie bei dem Ausgangsmaterial. Der Fehler liegt nicht in scripten sondern in irgendeinem Filter.
Strange.
...um auch sicher zu gehen dass keinerlei schwarzen Ränder vorhanden sind.
Allerdings ist genau das der Fall und zwar an der exakt selben Stelle wie bei dem Ausgangsmaterial. Der Fehler liegt nicht in scripten sondern in irgendeinem Filter.
Strange.
Wie darf ich das verstehen?
Du hast trotzdem schwarze Ränder im Bild, obwohl du sie zuvor weggecroppt hast? :hm:
greets
LTJ
Wie darf ich das verstehen?
Du hast trotzdem schwarze Ränder im Bild, obwohl du sie zuvor weggecroppt hast? :hm:greets
LTJ
Ganz recht, ja. Ich hatte an allen Rändern 4 Pixel weggecroppt und anschließend auf 720x400 resized.
Plötzlich hatte ich wie im Ausgangsmaterial wieder diese ganz kleine schwarze Pixelreihe Rechts und Unten, allerhöchstens nen halben Pixel groß. Keine Ahnung was das ist.
Edit: Auch bei dem Test oben, das gecroppte .avi script: Wenn ich das nochmal bei Meguiavsscriptcreator reinlade und Autocrop mache, sind die Schwarzen Ränder vorhanden. Die sieht man auch, sind extrem klein aber vorhanden.
Ganz recht, ja. Ich hatte an allen Rändern 4 Pixel weggecroppt und anschließend auf 720x400 resized.
Plötzlich hatte ich wie im Ausgangsmaterial wieder diese ganz kleine schwarze Pixelreihe Rechts und Unten, allerhöchstens nen halben Pixel groß. Keine Ahnung was das ist.
Edit: Auch bei dem Test oben, das gecroppte .avi script: Wenn ich das nochmal bei Meguiavsscriptcreator reinlade und Autocrop mache, sind die Schwarzen Ränder vorhanden. Die sieht man auch, sind extrem klein aber vorhanden.
Hab mir jetzt auch mal das ED_1024.AVI zur Brust genommen.
l,r,o,u jeweils 4 Pixel gecroppt und einmal auf 720x400 und einmal wieder zurück auf 1024 x 576 resized.
Ich kann da nix erkennen, was nach nem schwarzen Balken aussieht.
Wenn du im Script fps=25 eingestellt hast, slide im MeGUI Previewfenster mal auf Frame 1300, da sind die Ränder bei mir schneeweiß, wie es soll.
-----------------
Ich werde in den nächsten Tagen auch mal einen Test machen.
Folgendes schwebt mir da vor:
Ich möchte MOD 4/8 und 16 jeweils mit 2 Pixel breiten schwarzen Balken nur oben und unten, sowie das gleiche ohne Balken per --crf miteinander vergleichen.
Es liegen am Ende also 6 Ergebnisse vor.
Dabei stellt sich die Frage, wie man denn das Quellmaterial sinnvoll vorbereiten kann/sollte. Bei den ersten drei Encodings müsste man die Quelle jedesmal neu anpassen um die Balken zu berücksichtigen, wobei man bei den drei Testdurchläufen ohne Balken einfach auf die entsprechen MOD-Auflösung croppen kann.
Wie weit wäre das also am Ende vergleichbar?
greets
LTJ
per --crf miteinander vergleichen.
Vergleiche entweder mit konstantem Quantizer um die Auswirkungen auf die Größe zu sehen oder mit 2pass um die Auswirkungen auf die Qualität zu sehen.
Cu Selur
Interessant wären v.a. diese vier Kombinationen:
mod4, -A none
mod16, -A none
mod4, -A all -8
mod16, -A all -8
Genau genommen müssten beide Auflösungen auch die selbe Pixelzahl haben, nur dürfte das schwierig werden, das exakt hinzukriegen. Wenn ich heute Abend Zeit finde, teste ich das mal mit DVD-Auflösung.
Naja, wie gesagt: Ich kanns ja testen, allerdings äußert sich hier niemand zu dem Test oben und meinem Problem mit den schwarzen Rändern. Interessierts niemanden, dann muss ich meine Maschine auch net anwerfen.
Rechenleistung liegt bei mir mehr als genug brach.
... mit konstantem Quantizer um die Auswirkungen auf die Größe zu sehen ...
Das habe ich jetzt mit der DVD-Version von ED gemacht in jeweils MOD 4/8/16
Balken gecroppt und zurück auf DVD-Auflösung resized, also reines Bild als Quelle.
----------------------------------
--crf 20 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\Schwarze Balken Test - Ergebnisse\mod4.mkv" "C:\Schwarze Balken Test - Ergebnisse\mod4.avs"
----------------------------------
MOD 16 -> 720x576 -> 131.379.200 Byte
MOD 8 -> 712x568 -> 130.330.624 Byte
MOD 4 -> 716x572 -> 131.310.593 Byte
Die Unterschiede sind überhaupt nicht nenneswert.
greets
LTJ
Dass Mod4 kleiner ist, könnte daran liegen, dass 4000 Pixel weniger encoded werden müssen. Genaugenommen müssen sie zwar schon encoded werden, aber nur als edge extension, und das nimmt mit Intra Prediction und CABAC praktisch keinen Platz weg.
Es ist zwar schon ein sehr deutlicher Unterschied in der Dateigröße, aber 0.9 db PSNR Unterschied ist auch gewaltig. Als Faustregel geht man davon aus, dass eine Einstellung, die 0.1 db Gewinn bringt, auch sichtbare Auswirkungen auf die Qualität hat.
Hast du mal mit Auge verglichen?
So, ich hab jetzt nochmal einen Test gestartet, gerized auf 720x576, mit x264 lossles encodiert und anschließend von dort aus anschließend gecroppt encodiert mit QP 20.
--qp 20 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 7 --analyse all --8x8dct --me umh --threads 2 --thread-input --progress --no-psnr --no-ssim --output "F:\x264test\ED Mod4.mkv" "F:\x264test\ED Mod4.avs"
Ergebnis:
Mod4: 716x572 -> 164.430KB
Mod8: 712x568 -> 163.832KB
Mod16: 720x576 -> 163.687KB
Mod16 crop: 708x564 -> 157.687KB
Die Mod16 crop hab ich mal dazugenommen um zu veranschaulichen, wie stark die größe auch von der Anzahl der Pixel abhängig ist.
Außerdem gibt es einen Anhaltspunkt dafür, ob man bei möglicher Mod8 Auflösung nicht direkt weiter zu Mod16 croppen sollte. Das lohnt sich nämlich schon eher.
Ein Test mit addborders Material läuft jetzt an bei mir.
Zitat von Brother JohnInteressant wären v.a. diese vier Kombinationen:
mod4, -A none
mod16, -A none
mod4, -A all -8
mod16, -A all -8
Genau genommen müssten beide Auflösungen auch die selbe Pixelzahl haben, nur dürfte das schwierig werden, das exakt hinzukriegen. Wenn ich heute Abend Zeit finde, teste ich das mal mit DVD-Auflösung.
Wenn du jetzt noch ausführst, was du mit den Paramtern dahinter meinst?
Das Ganze in Prozent ausgedrückt:
Pixel Abweichung Abweichung
Pixel Größe
mod16 414720 0,00% 0,00%
mod8 404416 -2,48% +0,09%
mod4 409552 -1,25% +0,45%
Einfach linear gegenrechnen kann man Auflösung und Dateigröße sicher nicht. Aus den Zahlen schließe ich jedenfalls für den Fall "-A all -8": Mod4/8 haben einen Nachteil, allerdings fällt der gering aus, so dass sichtbar kaum eine Veränderung rauskommen dürfte. Da mod4/8 sowieso v.a. dann interessant ist, wenn mit hoher Zielgröße und relativ geringer Kompression arbeitet, relativiert sich das Ergebnis noch einmal.
Bumsfalara, wenn du Zeit hast wäre es interessant, das Gleiche nochmal mit "--analyse none" zu machen.
/edit:
Wenn du jetzt noch ausführst, was du mit den Paramtern dahinter meinst?
-A und -8 sind die Kurzformen von --analyse und --8x8dct.
Jau, ich kümmer mich morgen den Tag über drum.
Hab grad auch nochmal eine Datei mit 720x576 bei jeweils 4 Pixeln schwarzem Rand mit oben genannter Kommandozeile encodet.
Mod16 Borders: 720x576 -> 163.543
Wenn man das jetzt mal mit dem 712x568 Mod8 vergleicht (selbe Anzahl an Pixeln mit sinnvoller Bildinformation), stellt sich mir jetzt schon die Frage inwieweit die Aussage, man solle bei x264 alles croppen richtig sei.
Mir scheint es eher so, dass es bei x264 einfach total egal ist, was man macht.
Wenn ihr das mit schwarzem Rand ja/nein und wirklich austesten wollt macht am besten folgendes:
1. aus dem Inputsample (möglichst nicht total dunkler Film) in Avisynth einen Bildbereich ausschneiden der mod 16 entspricht
Dies liefert die Quelle für Mod16 ohne Rand.
2. mit addborders Ränder hinzufügen um Mod16 mit Rand zu erhalten.
3. aus dem Inputsample (möglichst nicht total dunkler Film) in Avisynth einen Bildbereich ausschneiden der mod 8 entspricht
Dies liefert die Quelle für Mod8 ohne Rand.
4. mit addborders Ränder hinzufügen um Mod8 mit Rand zu erhalten.
5. aus dem Inputsample (möglichst nicht total dunkler Film) in Avisynth einen Bildbereich ausschneiden der mod 4 entspricht
Dies liefert die Quelle für Mod4 ohne Rand.
6. mit addborders Ränder hinzufügen um Mod4 mit Rand zu erhalten.
=> hieraus sollte mit konstanten Quantizer Encodes ersichtlich werden ob es bei den einzelnen Mod xy Auflösungen etwas ausmacht ob man croppt oder nicht.
Cu Selur
Bumsfalara, wenn du Zeit hast wäre es interessant, das Gleiche nochmal mit "--analyse none" zu machen.
/edit:
-A und -8 sind die Kurzformen von --analyse und --8x8dct.
Gut, die Ergebnisse mit -analyse none
Nochmal schnell die Kommandozeile zu Kontrolle:
--qp 20 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 7 --analyse none --me umh --threads 2 --thread-input --progress --no-psnr --no-ssim --output "F:\x264test\ED Mod8.mkv" "F:\x264test\ED Mod8.avs"
Ergebnisse
Pixel Größe Abweichung Abweichung
Pixel Größe
-------------------------------------------------------------------------
Mod16 414720 179.540KB 0,00% 0,00%
-------------------------------------------------------------------------
Mod8 404416 180.599KB -2,48% 0,59%
-------------------------------------------------------------------------
Mod4 409552 180.473KB -1,25% 0,52%
-------------------------------------------------------------------------
Mod16 399312 172.954KB -3,72% -3,67%
-------------------------------------------------------------------------
Mod16 414720 181.150KB 0,00% 0,90%
(4 Pixel
Rand)
--------------------------------------------------------------------------Thx, Bumsfalara, damit wäre also wenig überraschenderweise geklärt, dass Partitionierung den Nachteil der krummen Auflösung auszugleichen hilft.
Wenn wir es ganz pedantisch genau nehmen wollten, könnten wir noch viel mehr Fälle testen:
- horizontale Auflösung: mod16, mod8, mod16+4px (mod4), mod16-4px (mod4)
- vertikale Auflösung: dito, in sämtlichen möglichen Kombinationen mit der hor. Auflösung
- Das alles in sämtlichen Kombinationen mit und ohne Balken
Zweimal mod4 deswegen, weil je nachdem entweder 4 oder 12 Pixel bis zur nächsten Makroblockgrenze übrig bleiben.
Ist es das wert? Ich glaube nicht. Sobald Resizing ins Spiel kommt, ist mod16 eh kein Problem. Also reden wir über Zielgrößen jenseits der 2CD oder gar 1Pass. Und das mit Abweichungen, die sich über den Daumen gepeilt bei 1-2 Prozent bewegen. Wobei wir die schlechteren Fälle angeschaut haben, bei denen beide Dimensionen nicht mehr mod16 sind. Dass sich unter diesen Vorrausetzungen irgend etwas an der sichtbaren Qualität ändert, wage ich schwer zu bezweifeln.
Ob das Ergebnis mit Xvid anders aussieht, hat mich interessiert.
Quelle: Elephants Dream DVD-Version (PAL, 16:9)
Encoder: Xvid 1.1.2
xvid_encraw.exe -i "E:\Video\ed Tests\script mod16.avs" -type 2 -cq 2 -mkv "E:\Video\ed Tests\mod16.mkv" -framerate 25.0 -progress 100 -bquant_ratio 163 -bquant_offset 0 -bvhq -qtype 1 -qmatrix "C:\Encoding\Matrizen\EQM V3HR.xcm" -qpel -vhqmode 4 -zones 0,w,1,O
Ergebnis:
Aufl. Fläche Abw. Größe (KB) Abw. Größe
mod16 720x576 414.720 0,00% 268.515 0,00%
mod8 712x568 404.416 -2,48% 275.087 +2,45%
mod4 716x572 409.552 -1,25% 282.123 +5,07%
Das bestätigt, was Kopernikus weiter oben sagt, dass mod16 für ASP wichtiger ist als für AVC.
Insgesamt macht das Ganze also wie erwartet nicht wirklich viel aus,...
Die Frage ist was für Schlussfolgerungen kann man sonst noch ziehen?
Insgesamt macht das Ganze also wie erwartet nicht wirklich viel aus,...
Die Frage ist was für Schlussfolgerungen kann man sonst noch ziehen?
Nicht wirklich viele in meinen Augen.
Schwarze Ränder sind böse, sollten man auf jeden Fall raushauen.
x264 oder allgemein avc ist soweit, dass die Auslösung zum Encoden nicht mehr wirklich eine Rolle spielt, nur noch eine äußert kleine, die allerdings zu vernachlässigen ist.
Ich für meinen Teil kann nach all den Tests, die ich für das Forum hier mittlerweile gemacht habe nur sagen, dass ich meine persönliche Traumeinstellung oder eher perfekte Einstellung für x264 entdeckt habe.
Was mich allerdings etwas sehr nachdenklich stimmt sind die zum Teil kontroversen Ergebnisse zu den Profilen von Sharktooth.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!