Staxrip: Frage zum crf-Wert

Eigentlich ist der CRF-Modus nur für eine Konvertierung mit einem Durchlauf gedacht. Ich wüsste jetzt nicht sicher, was in StaxRip bei "qualitätsbasierter 2-pass-Konvertierung" genau passiert, aber entweder es wird im zweiten Durchlauf der CRF-Wert verwendet (dann wäre ein zweiten Durchlauf aber überhaupt überflüssig), oder es wird eine prozentuale Zielgröße erreicht, basierend auf einem Wert aus dem ersten Durchlauf. Das einzig sinnvolle Vorgehen, bei dem beide Werte tatsächlich benutzt werden, wäre also: Der zweite Durchlauf erreicht eine prozentuale Größe des ersten Durchlaufes mit dem vorgegebenen CRF-Wert. Tja. Aber wozu? Dann könnte man eigentlich auch gleich einen größeren CRF-Wert nehmen und nur einen Durchlauf machen.

Was die Bitratenverteilung angeht: Soweit ich mich erinnere, wird wohl im zweiten Durchlauf eine CRF-Encodierung durchgeführt, für die der notwendige CRF-Wert aus der Statistik des ersten Durchlaufes und der gewünschten Zielgröße berechnet wird. Wenn also bei zwei Versuchen etwa gleiche Dateigrößen entstehen, dann sollte die Bitratenverteilung auch in beiden Versuchen sehr ähnlich gewesen sein.

Für diese Aussagen biete ich keine Garantie. Vielleicht wissen andere besser, was da passiert.

Es ist schon so wie LigH gesagt hat. Es wird ein --pass 1 mit --CRF 20 durchgeführt, dann ein --pass 2 mit der prozentualen Bitrate des ersten Durchgangs. (Dein Beispiel: 1184 =~ 1977*60% )

Der Bitratenunterschied zwischen CRF20 "single-pass" und CRF20 "first-pass" kommt daher, dass bei --pass 1 viele Turbo-Einstellungen verwendet werden. Deswegen ist das --pass1 Encoding weniger effizient in der Komprimierung bei gleichem CRF, und deswegen 1977<-->1695.
_____

P.S.: Ich kann das mit großer Überzeugung sagen, weil ich StaxRip noch niemals verwendet habe.

Klingt zumindest absolut logisch und nachvollziehbar! :daumen:

Dennoch bleibt der Zweifel am Sinn: Unterscheiden sich "60% von Turbo-CRF 20" und "CRF 20+x" überhaupt wesentlich in der Bitratenverteilung, wenn am Ende eine etwa gleich große Datei herauskommt?

Ich glaube eher nicht. Und dann spare ich mir auch den zusätzlichen ersten Durchlauf. Selbst wenn er "Turbo" ist.

Keine Ahnung. Ich versteh nur Bahnhof.

Ist doch Wurst ?
2-Pass wird normalerweise benutzt um ein eine bestimmte gösse zu erreichen und CRF für eine bestimmte Qualität.
Je nach Encodierungseinstellungen und Quellmaterial können die Ergebnisse in der erzielten Dateigröße abweichen ab einem bestimmten Punkt zumindest bei XviD ist auch irgendwann die Sättigungsgrenze erreicht, kann man eigentlich auch einstellen.

Bei 2-Pass wird im ersten Durchlauf eigentlich nur die benötigte Bitratenverteilung für den zweiten Durchlauf ermittelt.
Wenn man für den ersten Pass qualitativ bessere Einstellungen benutzt ist die Bitratenverteilung für den zweiten Pass vermutlich etwas genauer ob das irgendwelche sichtbaren Verbesserungen zur Folge hat weiß ich nicht.
Sicherlich sind die Einstellungen in StaxRip schon sehr gut gewählt.

Ich nutze StaxRip nicht aber der Compressiontest soll sicherlich das abschätzen ob man für den Film nur eine CD oder besser zwei benutzt um eine ordentliche Qualität zu erreichen erleichtern.
Ich mache das lieber per Hand oder bessergesagt per Auge

Geringe Abweichungen zwischen CRF <> 2-Pass liegen sicherlich in der Natur der Sache bei ungefähr gleicher Bitrate werden sich die erstellten Videos sicherlich kaum voneinander unterscheiden.

Sicherlich kannst du noch Monate testen und wirst dich dann immernoch wundern

Also gut. StaxRip gestartet und mal das GUI erforscht. (Während dessen ich mich wieder erinnert habe, warum ich's nie verwendet habe....)

Es wird ein CompTest mit CRF XX gemäß Configure Codec > Register'StaxRip' und YY% Abdeckung gemäß Options > Advanced > Misc > 'Percentage...' durchgeführt. Aus der Größe des CompTest-Files wird über Configure Codec > Register'StaxRip' > Aimed Quality die Bitrate abgeleitet, die dann nachfolgend in einem normalen 2-Pass-Szenario als Zielbitrate verwendet wird.

Das heißt also dass

Zitat

Wenn ich mit crf 19 und 50% Qualität auf die gleiche Bitrate komme wie mit crf 21 und 65%

vollkommen wurscht ist, und die Sache mit Slow-First-Pass auch keinen Einfluss auf die Endgröße haben kann.

Es geht nur um den automatisierten Weg, aus CompTest mit CRF XX und Abdeckung YY einen Wert für --bitrate ZZZZ im nachfolgendenen 2-Pass-Ablauf auszuknobeln. That's all. (Ging das nicht bereits letztes Jahrhundert ganz ähnlich, mit GordianKnot und XviD?)
Der 100%-Zielwert aus dem CompTest liegt i.d.R. immer höher als bei einem vergleichbaren CRF-SinglePass, weil der CompTest durch die Prozent-Schnipselei viel mehr Keyframes verwenden muss. Mehr Keyframes==> größeres Ergebnis.

Wie "genau" oder "verlässlich" die Methode ist, sieht man ja an

Zitat

crf20, q100, 2-pass : 667MB (1977 kbit/s) (Compressibility Check 10% der Frames)
crf20, q100, 2-pass : 642MB (1896 kbit/s) (Compressibility Check 20% der Frames)
zum Vergleich: crf20, single pass: 592MB (1695 kbit/s)

==> Wenn man das oft genug verwendet hat, dann wird man mit der Zeit vermutlich ein Gefühl dafür entwickeln, unter welchen Umständen und in welchem Maß die Ungenauigkeiten sich gegeneinander aufheben oder auch nicht. :ninja:

Ich muss jetzt gleich mal irgendwas mit Hybrid encoden. Einfach nur zur Erholung. :santa:

@ Didée:

Ich finde deine Bemerkungen zu StaxRip ehrlich gesagt etwas peinlich; ja, gut – DU als Profi brauchst es nicht. Das ist aber noch lange kein Grund, es anderen madig zu machen, denn für Einsteiger ist es immer noch die vielleicht leistungsfähigste und flexibelste Konvertier-Software auf AviSynth-Basis. Es gibt ansonsten eigentlich nur stärker eingeschränkte (AutoGK), weniger zugängliche (MeGUI) oder technisch veraltete (GK / AGKP) Software, oder eben welche ohne AviSynth-Basis (Hybrid, Avidemux). Ich persönlich finde, dass sich StaxRip in dem Vergleich gar nicht so schlecht präsentiert. Selbst wenn ich persönlich auch gar keine Verwendung dafür habe...

Ich bin aber gar kein Profi.

Ein GUI soll doch die Arbeit vereinfachen, oder nicht? Wenn nun ein "Experte" daherkommt, das erste Mal StaxRip startet, und dann stundenlang erforschen muss, was man wo und wie und warum einstellen muss, um das anstehende zwei-Minuten-Video zu encodieren, dann ist das ...... gewöhnungsbedürftig.

(Ich hab auch nie gesagt das StaxRip "schlecht" wäre. Nur verschiedentlich angedeutet dass *ich* damit nicht zurechtkomme -- zu viel von-hinten-durch-die-Brust-ins-Herz -- und ich mir ein "straight-forward"-GUI anders vorstelle.)

Gerade die neueste Version auf'm Bürorechner gezogen. Erstmal einige Zeit suchen müssen wo man gleich nochmal die DGDecodeNV-Geschichte abstellen kann.
(Ich wollte nur ein AVI öffnen, ging aber nicht weil die fehlende DGDecodeNV.dll angemahnt wurde, die zum Öffnen eines AVIs aber gar nicht gebraucht wird.)

Ein Standard-Script von StaxRip erstellen lassen. Ganz nach Vorgabe, weil "ich nix wissen".

LoadCPlugin("C:\Anwendungen\_VIDEO\StaxRip_1.1.7.0_beta\Applications\AviSynth plugins\Yadif\yadif.dll")
AVISource("D:\_samples\sample_[COLOR='darkred']YUY2[/COLOR].avi", audio=false)
Crop(0,0, -Width % 8,-Height % 8)
[COLOR='red']ConvertToYV12()[/COLOR]
[COLOR='darkred']Yadif()[/COLOR]
Crop(16,72,-16,-72)

:eek:HARRRR:eek:

Das ConvertToYV12() wird automatisch eingefügt, und somit das interlacte YUY2-Video gleich mal still und heimlich kaputt gemacht. Ganz offensichtlich ein Rohrkrepierer.
(Sag doch mal einer dem Stax dass, wenn "interlacing" angehakt wird, dann zumindest das "interlaced=true" flag in ConvertToYV12 gesetzt werden muss...)

Sicher, sicher .... man kann das alles in den Griff kriegen. Aber "Einsteiger-freundlich" ist das nicht wirklich. Eher ein Expertensystem, in das man ziemlich tief eintauchen muss, um sich damit auszukennen und Schiffbruch zu vermeiden.

Nun, stax0711 ist zum Glück hier registriert.

Leider aber überbeschäftigt und (vermutlich) unterbezahlt...

YV12 ist ein FourCC (4-Zeichen-Code), der im "Video for Windows"-System eine bestimmte Variante YUV-Video beschreibt, welches die Farbigkeitskomponenten U und V sowohl senkrecht als auch waagerecht nur mit halber Auflösung speichert, im Vergleich zur Helligkeit Y. Das wird als "Chroma-Subsampling 4:2:0" bezeichnet.

Vorteil ist die effiziente Speicherung (der Betrachter nimmt es eh nicht genauer wahr, also kann Platz gespart werden); Nachteil ist, dass eine zeilenweise Speicherung (im Gegensatz zu RGB mit Chroma-Subsampling 4:4:4 oder YUY2 mit Chroma-Subsampling 4:2:2) nicht möglich ist, wenn zwei Zeilen übereinander sich (aller 2×2 Pixel) die Farbigkeitsinformationen teilen. Die Komponenten (Helligkeit Y, Farbdifferenzen U und V) werden also flächenweise (planar) behandelt. Das unterstützt aber die Bildspeicherung von Windows (DIB) eigentlich gar nicht...

Zwischen progressiver und interlaceter Encodierung unterscheidet sich dann auch noch, welche zwei Zeilen sich die Farbigkeiten teilen: Bei progressiv die nächste, bei interlaced die übernächste (also die nächste jeweils pro Halbbild). Bei der Konvertierung zwischen pixelweiser Speicherung (RGB oder YUY2) und flächenweisere Speicherung = ConvertToYV12() muss AviSynth bekannt sein, ob ein Frame progressiv behandelt werden soll oder interlaced (als zwei ineinander verzahnte Halbbilder).

Wenn das in der Art falsch durchgeführt wird, dass man die progressive Konvertierung auf interlacete Inhalte anwendet, dann wird dort, wo Bewegungen zum Combing (im Standbild sichtbaren Kamm-Mustern) führen, eine Mischfarbe zwischen den beiden Halbbildern berechnet. Am typischen akademischen Beispiel "Roter Ball fliegt vor blauem Himmel" hätte man im Ergebnis des Standardwertes "ConvertToYV12(interlaced=false)" einen lila Matschfleck, der danach nicht mehr zu reparieren ist. Mit der expliziten Angabe "ConvertToYV12(interlaced=true)" dagegen werden je zwei übernächste Zeilen betrachtet, die je zu einem Halbbild gehören, und schon bleibt der rote Ball rot und der blaue Himmel blau - auch dort, wo sie sich aneinander vorbei bewegen.

Nach möglichkeit ändere ich so wenig wie möglich, jede Änderung am Farbraum Auflösung was auch immer kostet meiner Meinung Qualität.
Natürlich muß man Kompromisse eingehen damit das Video möglichst sparsam gespeichert werden kann.

Für DVB-Aufnahmen baut man sich am besten einen VDR den kann man nach belieben mit Platten erweitern oder auf Wechselmedien Speichen

Staxrip mag anfänglich viele Ecken und Kanten haben, aber der Zeitersparnisfaktor im Vergleich zu Software die auf Einzelprojekte ausgelegt ist kann ganz enorm sein. Ich investiere gerne anfänglich Zeit, wenn ich sie danach umso öfter einsparen kann.

Zitat

...bei DVB-Ausgangsmaterial (YUV) nicht relevant...

DVB Material (MPEG2 und H.264) ist bereits YV12

Zitat von Lowlander

@ LigH: vielen Dank für die ausführliche Erklärung, ich glaube sogar alles verstanden zu haben! Ich habe mal meine Staxrip-Skripts im Arbeitsverzeichnis gecheckt, und keines davon enthält bisher ConvertToYV12(). Gehe mal davon aus, dass der Filter bei DVB-Ausgangsmaterial (YUV) nicht relevant ist und von Staxrip nur (wenn auch ggf. falsch) gesetzt wird, wenn der Farbraum für x264 nicht passt. Oder passiert die Konvertierung schon beim ersten Durchgang demuxen/indizieren beim Öffnen des Videos?

Stax hat in jedem Source Aufruf das hier drinstehen

%newline%Crop(0,0, -Width % 8,-Height % 8)%newline%ConvertToYV12()

Da ich das nie benötige, ist das das erste was ich rauswerfe. Finde es auch so versteckt nicht OK, gehört in eine eigene abschaltbare Zeile.

Wenn man mit Stax richtig viel arbeitet, merkt man schnell, was man alles entfernen kann, weil es für irgendwelche Spezialfälle gedacht ist.