Bei seinem zweiten Beitrag hat er es ja nun auch auf 1500 kbit/s runtergesetzt.
Die 1500 mit dem "Uaah"-Ergebnis waren aber gar nicht die Spezial-Settings von Genesis. Das war Preset Medium, wie der Dateiname nahelegt. Quantizer-Level 19.9 mit 29.5 vergleichen. - Also, so als Gute-Nacht-Witz war das schon ganz gut.
Ah, hast Recht. Ich dachte, beim zweiten Beitrag hätte er es noch mal korrigiert.
Hast Du es wirklich nicht verstanden? Oder tust Du nur so?
Nöö ... spontane Affekthandlung 
Codeffvideosource("wolverine-tlr1_h1080p.mov")trim(150, 1149)
Ok ... dann liegt vermutlich hier dran:
LoadPlugin("C:\Tools\Windows\DGDecNV\DGDecodeNV.dll")DGSource("wolverine-tlr1_h1080p.dgi")trim(150, 1149)Wir sollten gleiche Rahmenbedingungen schaffen.
Bei H.264 ist das Deblocking kein frei wählbarer Post-Filter sondern "inloop" und absolut zwingend vorgeschrieben.
Das nehm ich dir jetzt einfach mal so ab.
Bei diesem Quellmaterial fördert das 2pass encoden mit 5100 kbit übrigens nur maginale Unterschiede zu Tage:
encoded 2771 frames, 15.98 fps, 5120.39 kb/s
00:15:19 - 00:19:07 = 3min 48sek
wolverine-tlr1_h1080p_medium.mp4 = 70.969.284 bytesEinziger visueller Unterschied ist nur ersichtlich beim direkten übereinanderblenden von stills ... dort produziert der --preset medium minimale Blocking-Artefakte bei hohem Detailgrad (zwischen dem Regen kann man eine Flächenbildung beobachten, die etwas heller ist, als die Umgebung) ... witzig, obwohl "mein preset" den loop unterbunden hat, sind die dort kaum zu verzeichnen.
Ich denke wir bräuchten anderes Quellmaterial.
Ich denke aber mal, um meinen Punkt klarzumachen, daß irgendein sinnloses Drehen an Parametern ohne die richtige Methodik dahinter schnell zu Unsinn führt, hat es schon mal gereicht.
Falscher Ansatz ... deiner ist nämlich immernoch nicht der meinige ... was würde mir das bringen, wenn wir dabei festellen, das ein niedrigerer Platzverbrauch weniger Artefakte mit den Standardparametern produziert?
Das würde meine Priorität nach Qualität ad absurdum führen, denn mich interessiert eher weniger, wie klein das Ding wird, aber um so mehr, wie nah das nachher am Original ist.
Übrigens ... bist du Anwalt? ... weil:
Den Widerspruch brauch ich nicht weiter ausführen, oder?
... das von dir völlig aus dem Zusammenhang gerissen und neu interpretiert wurde... nur weil ich unnötige Wartezeiten als ätzend empfinde, heißt das nicht, das ich sie nicht in kauf nehme ... hab ich übrigens auch genauso geschrieben.
Aber wegen der Neugier hab ich einen Vorschlag ... ich bekomme nächsten Montag das Quellmaterial für meine HD-Tests (hab ich mir gestern ausversehen gelöscht) ... lass uns das doch mal mit Presets und Tunes gegen die Drähte aus meiner Liste vergleichen.
Was meinst du?
Gruß
Thom
Sinn macht so ein Vergleich nur, wenn wir das mit CRF vergleichen, weil ich die Bandbreite aus Qualitätgründen nicht künstlich auf 5000 oder ähnliches limitieren will.
Unsinn! Wie crf agiert ist stark abhängig von den Einstellungen,.... crf X mit Einstellungen Y erzeugt nicht das gleiche optische Ergebnis wie crf X mit Einstellungen Z,...
die preset Geschichte gewinnt mit einer kürzeren Encodingzeit und niedrigeren Bitrate.
was leider gar nichts sagt
bei CRF18 wird der Codec komplett "gesättigt" und ich erhalte immer maximale Qualität
Wo kommt denn diese Ansicht her? Ich würde eher sagen, dass das Ergebnis ist, dass Du bei so hohen Datenraten und dem Material einfach keinen Unterschied mehr siehst.
Cu Selur
dass Du bei so hohen Datenraten und dem Material einfach keinen Unterschied mehr siehst.
Genau, das hatte ich ja auch schon geschrieben. Nun bin ich hier allerdings etwas "entsetzt" über die Bitrate, die Genesis bei diesem CRF18 - Test 'rausbekommen hat. Rund 40 Mbps bei CRF18 ist schon recht gewaltig! Ich mach' keine Game-Captures ... ist das normal bei solchem Material wie Skyrim? Oder, (mein Verdacht), war da noch immer das Avisynth-Script mit dem "Sharpen(1)" in Verwendung? Das würde die sehr hohe Bitrate nämlich gut erklären ... grundsätzlich treibt ja jeder Schärfe-Filter die Bitrate in die Höhe, aber Sharpen() ist besonders schlimm, und erst recht mit voller Stärke (1.0), weil das Ding wegen Rechen- bzw. Rundungs-Ungenauigkeiten auch noch 'ne ganze Menge Pixelrauschen hinzufügt. Und sowohl Luma als auch Chroma (!) schärft, wogegen viele andere Schärfer ja nur in Luma agieren.
40 Megabit bei CRF18. Hei-ei-eieiei .... 
Sintel-Trailer ... eine AVC-Kopie mit CRF 6
MediaFire (168 MB, MKV inkl. FLAC)
Falscher Ansatz ... deiner ist nämlich immernoch nicht der meinige ... was würde mir das bringen, wenn wir dabei festellen, das ein niedrigerer Platzverbrauch weniger Artefakte mit den Standardparametern produziert?
Das würde meine Priorität nach Qualität ad absurdum führen, denn mich interessiert eher weniger, wie klein das Ding wird, aber um so mehr, wie nah das nachher am Original ist.
Ja, und in meinem Test waren die Standardeinstellungen näher am Original als Deine. Man könnte jetzt noch testen, ob sich das bei höheren Bitraten umkehrt.
Habe mal den Sinteltrailer mit Deinen Einstellungen (--crf 18) kodiert, Ergebnis 3011 kbit/s. Also noch mal beide Einstellungen bei 3011 kbit/s 2pass rübergejagt, aber bei dieser Bitrate und diesem Material ließ sich kein eindeutiger Sieger mehr feststellen.
Aber wegen der Neugier hab ich einen Vorschlag ... ich bekomme nächsten Montag das Quellmaterial für meine HD-Tests (hab ich mir gestern ausversehen gelöscht) ... lass uns das doch mal mit Presets und Tunes gegen die Drähte aus meiner Liste vergleichen.
Was meinst du?
Ich habe eigentlich nicht vor, daß hier noch ewig weiterzuführen, da ich meine, meinen Standpunkt klargemacht zu haben. Letztendlich sind viele Sachen auch subjektiv, aber ich sehe halt zu häufig, daß eigene Einstellungen durch falsche Schlußfolgerungen zustande kommen. Wenn hier noch was kommt, werde ich aber sicher reinschauen.
Was ich zeigen wollte:
- die presets sind einfach zu nutzen; kompliziertere, eigene Einstellungen sind häufig unterlegen, weil durch fragwürdige Schlußfolgerungen oder abschreiben zustande gekommen
- langsamer bedeutet nicht besser
Wichtig ist beim Vergleichen die richtige Methodik, d.h. zwei Einstellungen bei gleicher Bitrate zu vergleichen. Schlecht sind voreilige Schlußfolgerungen, insbesondere in der Richtung, daß psy, mbtree und ähnliches weiter entfernt vom Original seien. Außerdem das von Selur noch mal angesprochene Problem, daß --crf keine konstante Qualität über verschiedene Einstellungen garantiert.
/edit:
mit --tune film meine ich noch einen kleinen Vorsprung für die presets in der Schneesequenz am Anfang erkennen zu können, aber im Rest des Trailers macht es ansonsten keinen wirklichen Unterschied. Beim normalen Anschauen wird man selbst den Unterschied nicht sehen.
nebenbei: wäre vermutlich interessant mal zu gucken was für Komplexitätsmaße für Videos es so gibt und ob man nicht anhand eines solchen Maßes sagen kann, dass Feature X hilft oder nicht,...
Ich glaube kaum, dass man da besonders viel Auswahl an zuverlässigen Algorithmen hat. Unabhängig vom Inhalt ist bppf schon mal ein grober Anhaltspunkt, aber für bessere Einschätzungen müsste man wohl den Inhalt mit analysieren. Und da bezweifle ich, dass ein Algorithmus zuverlässig Quantisierungsartefakte von Bilddetails unterscheiden kann (z.B. ob es "Stilmittel Filmgries" oder "hochskaliertes DVB-T" ist).
Vermute eigentlich das 'allein' die Entropy schon ein brauchbares Maß wäre, denn denn der Codec unterscheidet ja auch nicht zwischen Details, Rauschen und existierenden Artefakten, für ihn sind alles Details.
bpf (= bits per frame) ist meiner Ansicht nach nicht wirklich brauchbar, da es gerade 0 über den Inhalt aussagt und indirekt voraus setzt, dass eine konstante Datenrate vorliegt.
Und wie bestimmt man die "Entropie" eines Videos?
Wenn ich ne clevere Idee hätte, die auch schnell ist hätte ich vermutlich schon was geschrieben um es zu testen.
Da das Decodieren des kompletten Inputstreams i.d.R. zu viel Aufwand sein wird, müsste man wie der CropDetection sich am besten nur einen Teil des Inputs angucken, auch wenn dadurch Aussagekraft verloren geht, d.h. man würde wohl nur ein paar GOPs des Inputmaterials betrachten.
Manche Leute machen ja etwas ähnliches über einen Kompressiontest, die Frage ist nur, könnte man z.B. aus dem Unterschied zwischen '--preset medium --crf 16' und '--preset medium --crf 6' hilfreiche Rückschlüsse über die Komplexität des Materials schließen. (alternativ könnte man das Material auch einfach etwas glätten im zweiten Durchlauf und nochmals mit den gleichen Setting reencoden)
...
-> viele kleine Ideen, aber keine Zeit in die Richtung ernsthaft etwas zu machen
(eventuell müsste man nicht mal nicht mal reencoden, sondern würde in Avisynth gefiltert gegenüber ungefiltert betrachten,..)
So wirklich beantwortet das die Frage nicht; aber es führt in eine interessante Richtung: Bestimmt man die Komplexität bzw. Entropie aus dem Originalvideo, oder nur aus dem encodierten Video allein, oder aus dem Vergleich zwischen beiden...?
Wenn man von den klassischen Begriffen der Shannonschen Informationstheorie ausgeht, dann wäre die verlustlose Komprimierbarkeit ein Resultat der Entropie. Aber ob die sich auch auf psychologisch optimierte verlustbehaftete Verfahren erweitern lässt, da bin ich überfragt, das soll ein theoretischer Informatiker klären.
So wirklich beantwortet das die Frage nicht;
Natürlich nicht, dachte mein erster Satz würde direkt klären, dass da keine Lösung folgt,..
Bestimmt man die Komplexität bzw. Entropie aus dem Originalvideo, oder nur aus dem encodierten Video allein, oder aus dem Vergleich zwischen beiden...?
Idealerweise aus dem Originalvideo, wirklich machbar wird es aber vermutlich nur möglich sein, aus dem Vergleich zwischen beiden.
soll ein theoretischer Informatiker klären.
Hätte es eher einem Mathematiker, einem aus der Photogrammetrie oder einem aus der Signalverarbeitung untergeschoben. 
Cu Selur
Unsinn! Wie crf agiert ist stark abhängig von den Einstellungen...
Ok.
Wo kommt denn diese Ansicht her? Ich würde eher sagen, dass das Ergebnis ist, dass Du bei so hohen Datenraten und dem Material einfach keinen Unterschied mehr siehst.
Ja, brauchst garnicht zu grinsen ... mir ist das grinsen beim letzten Test nämlich vergangen
Denn:
Nun bin ich hier allerdings etwas "entsetzt" über die Bitrate, die Genesis bei diesem CRF18 - Test 'rausbekommen hat.
Ich nämlich auch ... hatte (genau wie du jetzt) angenommen, die hohe Bitrate würde aus dem Sharpen resultieren ... der encode war pure-source ... kein Filter ... nur das Ausgangsmaterial.
Auf den zweiten Blick ist das aber auch logisch ... wenn man sich die Frames so anguckt dann haben die ungefilterten "Gameszenen" im Vergleich zu einem "normalen Film" schon verdammt Scharfe Details ... unnatürlich, aber eben Digital "gezeichnet".
Ja, und in meinem Test waren die Standardeinstellungen näher am Original als Deine.
Mann ... kannste mal damit aufhören ... kannst du, oder willst du nicht verstehen, das ich nicht auf biegen und brechen mit 1500 encoden will, nur um meinen Diskspace zu schonen?
Wenn wir/ich hier eine Einstellung finden, bei der man/ich (nahezu) keinen Unterschied zu den Ergebnissen mit "meinen" hohen Bitraten, dann würde ich das natürlich begrüßen. Trotzdem sind solch niedrige Bitraten (wie z.B. 1500), so sehr sie auch besser aussehen als ein Schneemann in Sibierien, ungeeignet, um meinem persönlichen Qualitätsempfinden zu genügen ... sonst müßte x264 Zaubern können ... und das kann er definitiv nicht.
nebenbei: wäre vermutlich interessant mal zu gucken was für Komplexitätsmaße für Videos es so gibt und ob man nicht anhand eines solchen Maßes sagen kann, dass Feature X hilft oder nicht,...
Ich krieg am Montag nochmal das Original von "Troja" ... da sind ein paar echt gemeine Sachen drin ... und dann probier ich's nochmal mit ein paar Varianten durch ... mal gucken was dabei raus kommt.
Aber wenn ich mir die Bitraten bei den Gamecapture so ansehe, wäre das wohl das ultimative Testmaterial ... allerdings ist das wohl eher in die Kategorie "Spezialanwendung" ein zu ordnen ... mhmmm ...
Increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate.
Nebenbei, die Aussage kommt vermutlich von:
A total of 52 values of Qstep are supported by the standard and these are indexed by a Quantization Parameter, QP. The values of Qstep corresponding to each QP are shown in Table 2-1. Note that Qstep doubles in size for every increment of 6 in QP; Qstep increases by 12.5% for each increment of 1 in QP. The wide range of quantizer step sizes makes it possible for an encoder to accurately and flexibly control the trade-off between bit rate and quality.
Quelle: http://lassaadjemai.unblog.fr/files/2010/05/h264transform1.pdf
Cu Selur
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
