Optimale Endodier-Einstellungen x264

[Tyler]

Hallöle!

Wollte mal fragen wie lange bei euch das encoden für 'ne ansehnliche Qualität so dauert und was ihr für Einstellungen vornehmt!

Brother John's Encodingwissen ist bekannt und verinnerlicht :wink:
Hab einen Remux eines Films encodet und dafür 29:26:52 Stunden gebraucht.
Die Bildqualität weist keinerlei Verschlechterung zur Source auf und die Videospur hat 6 GiB weniger.

Encodet mit StaxRip 1.1.7.0 (x264 r1724) mit 1 Pass.

Encodiereinstellungen:

Spoiler

x264.exe" --preset slower --tune grain --crf 18 --keyint 240 --min-keyint 24 --ref 5 --output [...]
MKV Container
Kein Resize, Crop, Noise oder sonst was
Audio Just Mux

Kurzform:
Video: variabel 23,0 Mbps (max. 40,0 Mbps) => konstant 18,2 Mbps
Audio: Just Mux von DL nach nur Deutsch
Größe: 32,1 GiB => 24,1 GiB


Hier mein System (nicht wundern, dass komplett - ist aus anderem Forum rauskopiert):

Spoiler

Prozessor
i7 860 + Noctua NH-U9B SE2
Mainboard
GA-H57M-USB3
Arbeitsspeicher
4x 2GB G.Skill 1600MHz CL7 ECO
Festplatten
2x SSD Crucial m4 128GB
SpinPoint F3 HD103SJ 1 TB
WD Caviar Black 2TB
Grafikkarte
Sapphire HD5870 Rev2.0
Sound
Onboard + Hercules XPS 510 Active 5.1
Netzteil
Seasonic X-650 (semi-passiv)
Gehäuse
LIAN LI PC-V351B black
Optisches Laufwerk
LG Electronics BH10LS30 Blu-Ray SATA schwarz
Lüftersteuerung
Scythe Kaze Server KS01-BK
Betriebssystem
Windows 7 x64 SP1
Monitore
Samsung SyncMaster P2450H
Samsung UE55C6700

Source File:

Spoiler

Allgemein
Vollständiger Name : F:\BLABLABLA1080.mkv
Format : Matroska
Dateigröße : 32,1 GiB
Dauer : 2h 58min
Gesamte Bitrate : 25,8 Mbps
Kodierungs-Datum : UTC 2010-11-13 14:47:16
Kodierendes Programm : mkvmerge v4.0.0 ('The Stars were mine') gebaut am Jun 6 2010 16:18:42
verwendete Encoder-Bibliothek : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4.1
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 2 frames
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 2h 58min
Bitraten-Modus : variabel
Bitrate : 23,0 Mbps
maximale Bitrate : 40,0 Mbps
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.463
Stream-Größe : 28,7 GiB (89%)

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec-ID : A_DTS
Dauer : 2h 58min
Bitraten-Modus : konstant
Bitrate : 755 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
BitDepth/String : 24 bits
Video Verzögerung : 6ms
Stream-Größe : 961 MiB (3%)
Sprache : Deutsch

Audio #2
ID : 3
Format : DTS
Format/Info : Digital Theater Systems
Codec-ID : A_DTS
Dauer : 2h 58min
Bitraten-Modus : konstant
Bitrate : 1 510 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
BitDepth/String : 24 bits
Stream-Größe : 1,88 GiB (6%)
Sprache : Englisch

Text #1
ID : 4
Format : UTF-8
Codec-ID : S_TEXT/UTF8
Codec-ID/Info : UTF-8 Plain Text
Sprache : Deutsch

Text #2
ID : 5
Format : UTF-8
Codec-ID : S_TEXT/UTF8
Codec-ID/Info : UTF-8 Plain Text
Titel : forced
Sprache : Deutsch

Was dabei heraus kam:

Spoiler

Allgemein
Vollständiger Name : D:\BLABLABLA1080_new.mkv
Format : Matroska
Dateigröße : 24,1 GiB
Dauer : 2h 58min
Gesamte Bitrate : 19,3 Mbps
Kodierungs-Datum : UTC 2011-09-11 19:53:04
Kodierendes Programm : mkvmerge v4.3.0 ('Escape from the Island') built on Sep 5 2010 10:30:51
verwendete Encoder-Bibliothek : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L5.0
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 5 frames
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 2h 58min
Bitrate : 18,2 Mbps
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.366
Stream-Größe : 22,7 GiB (94%)
verwendete Encoder-Bibliothek : x264 core 105 r1724 b02df7b
Kodierungseinstellungen : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.10 / aq=1:0.50

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec-ID : A_DTS
Dauer : 2h 58min
Bitraten-Modus : konstant
Bitrate : 755 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
BitDepth/String : 24 bits
Video Verzögerung : 12ms
Stream-Größe : 961 MiB (4%)
Sprache : Deutsch

Text
ID : 3
Format : UTF-8
Codec-ID : S_TEXT/UTF8
Codec-ID/Info : UTF-8 Plain Text
Sprache : Deutsch

Hab derletzt den Remux eines anderen Films mit den gleichen Einstellungen encodet.
Nur --crf hatte ich nicht auf 18 sonder 20 und --ref nicht auf 5 sondern 4.
Und das hat gerademal 11:32:10 gedauert. Dabei kamen 8419 Kbps und 8,18 GiB heraus. Auch hier war die Qualität annähernd gleich zur Source.
OK, Sieben läuft anstatt 3 h auch nur 2 h.

Warum frag ich? Weil 5 mal den gleichen Film mit unterschiedlichen Einstellungen zu encoden, um zu sehen, wie lange es dauert und wie die Qualität ist, echt laaaaaaaaaaaaaaaaaange dauern würde.

 

[OctoCore]

Ich kodiere eigentlich immer 2pass... die Einstellungen mache ich in Mediacoder - falls -ref "Predicted Frames" bedeutet, da nehme ich nur 2. Die Min- und Max-Frames sind ja ziemlich Geschmackssache. Min mache ich vom Quellmaterial abhängig - 25 z.B. bei "normalen" TV-Aufzeichnungen. Max nur bis höchstens 300 - mehr macht keinen Sinn. Presets wie "slow" nutze ich nicht - alles separat.
Tipp: wenn du mal einen mit x264 encodeten Film in guter Qualität findest: die Kodiereinstellungen sind im MKV mit gespeichert - und zumindest im Mediaplayer Classic Homecinema auch auslesbar. Dadurch kann man die Einstellungen gut mit den eigenen bevorzugten Parametern vergleichen.

 

[Tyler]

Ich kodiere eigentlich immer 2pass... die Einstellungen mache ich in Mediacoder - falls -ref "Predicted Frames" bedeutet, da nehme ich nur 2. Die Min- und Max-Frames sind ja ziemlich Geschmackssache. Min mache ich vom Quellmaterial abhängig - 25 z.B. bei "normalen" TV-Aufzeichnungen. Max nur bis höchstens 300 - mehr macht keinen Sinn. Presets wie "slow" nutze ich nicht - alles separat.
Tipp: wenn du mal einen mit x264 encodeten Film in guter Qualität findest: die Kodiereinstellungen sind im MKV mit gespeichert - und zumindest im Mediaplayer Classic Homecinema auch auslesbar. Dadurch kann man die Einstellungen gut mit den eigenen bevorzugten Parametern vergleichen.

--ref ist die Anzahl der erlaubten Referenzframes. x264 erlaubt maximal 16 Stück; sinnvoll sind 4 bis 5. Mehr steigert hauptsächlich die Codierzeit, nicht mehr die Qualität. Lediglich Zeichentrick profitiert oft von deutlich höheren Werten. Bei lediglich 2 ReFrames macht eine höhere Bitrate Sinn.

Die Bitrate ist Geschmacksache oder auch individuell nach der Fähigkeit der Augen zu wählen

Wow... also 2Pass nehme ich eigentlich ungern, außer ich bin mal über's WE nicht am Rechner...
Braucht ja nunmal das 1,5 fache und 2 fache an Zeit.

Wenn du die Presets nicht nutzt musst du aber schon sehr genau wissen, was mach von den zig Parametern Einstellen kann. Ich weiß zumindest, welche Parameter bei welchen Presets auf welchen Wert geändert werden. Wenn man das weiß, kann man das Preset erstmal nehmen und die Einstellungen dann manuell nochmal abändern.

Wenn das Ausgangsmaterial viele Details und kontrastreiche und auch langsam bewegte Bilder enthält, benötigt man mehr Bitrate pro Makroblock um Details aufrecht zu erhalten. Dafür gibt's ja crf (Constant Rate Factor). Mir geht's hauptsächlich um 1080p Material.

Die Informationen der Kodierungseinstellungen kann man mit MediaInfo auslesen, gleich nach der verwendeten Encoder-Bibliothek (zB: x264 core 105 r1724 b02df7b). Bei einigen wird diese Information aber leider einfach nicht im MediaInfo aufgeführt; ich habe bis jetzt nicht herausgefunden warum das bei manchen so ist. Da ist nach der Streamgröße Schluss mit Info.

Mich interessiert nur mal, wie lange andere so für's Encoden auf sich nehmen und was für Einstellungen sie dabei bevorzugen, bzw. welche Qualität dabei für's Auge noch wahrnehmbar ist.

 

[OctoCore]

Zweipass dauert ja nicht die doppelte Zeit und verbessert das Bild enorm, grade in dem Fall:

Wenn das Ausgangsmaterial viele Details und kontrastreiche und auch langsam bewegte Bilder enthält, benötigt man mehr Bitrate pro Makroblock um Details aufrecht zu erhalten. Dafür gibt's ja crf (Constant Rate Factor). Mir geht's hauptsächlich um 1080p Material.

Dazu kommt natürlich, das es hilft vorgegeben Größen exakt einzuhalten. Frameref von 2 erscheint wenig, war aber bis jetzt immer okay. Ich weiß nicht mehr warum ich ausgerechnet 2 nehme - aber ich hatte wohl meine Gründe.
Wichtiger und stark die Geschwindigkeit beeinflussend ist der motion Estimation Mode. Normalerweise nehm' ich da Uneven Multi Hexagon. Alles darüber nur in Ausnahmefällen - bremst sonst auch zu stark.

 

[Tyler]

2Pass ist nicht langsamer als 1Pass? Ich denke, es sind zwei komplette Durchgänge bei 2Pass und bei 1Pass nur einer?
Also wenn's die Qualität enorm verbessert und nicht länger dauert, dann werde ich das nochmal probieren.
Nur muss man sich dann hier auch für eine feste Bitrate entscheiden!

Momentane Kodierungseinstellungen:
cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.10 / aq=1:0.50

Hier mal ganz grob (alles untouched Bitraten als Quelle):
Film x264 (178min) crf 18, ref 5 nach encoden: 18,2 Mbps 29:26:52 = 2,4 fps
Film x264 (155min) crf 19, ref 4 nach encoden: 16,1 Mbps 24:45:39 = 2,5 fps
Film x264 (155min) crf 20, ref 4 nach encoden: läuft noch ca. 25:46:48 = 2,4 fps
Film VC-1 (126min) crf 20, ref 4 nach encoden: 8,4 Mbps 11:32:10 = 4,4 fps

Sieht das nicht komisch aus?
Kann es sein, dass VC-1 schneller encodet wird, als AVC x264?
Oder vielleicht helleres Bild = länger Encodier-Zeit?
Was nimmst du denn bei "me_range"?
Vielleicht mal "subme" auf 7 anstatt 9?

 

[OctoCore]

VC1 ist h264/AVC zum Teil sehr ähnlich, aber nicht ganz so aufwändig.
Ich würde ja behaupten, das bei subme Werte über 7 nicht mehr viel bringen. Meistens reicht auch 6 - aber mit 7 ist man auf der sicheren Seite. Ich schalte aber dct_decimate und fast_pskip aus.
Motion Estimation Range lasse ich normal auf 16 - ist meist auch Vorgabe. Zusammen mit Uneven Multihexagon.

Du kannst noch 10 - 15% mehr Leistung rauskitzeln, wenn du auf den 64Bit-Encoder umsteigst. Aber das ist mit der verwendeten GUI nicht einfach möglich, weil da noch Avisynth mit reinspielt und das ist wohl in der 32Bit-Variante installiert.

Was 2-Pass angeht - natürlich dauert es länger, aber nicht doppelt so lange. Aber eine Gesamtzeit von 150% deiner üblichen Zeiten würde ich realistischerweise mal annehmen.

 

[Tyler]

Ja, subme 9 ist glaub ich Standard vom Preset "Slower". Mit subme 7 läuft's jetzt auf jeden Fall wesentlich schneller. Ungefähr die Hälfte der Zeit (4,7 fps) im Vergleich zu 9.

Fast-pskip zu deaktivieren wird eigentlich überall als nicht notwendig bezeichnet. Hmm... Was den Einfluss auf die Geschwindigkeit bei fast-pskip angeht finde ich momentan nichts.

Manchmal ist nach dem Muxen des neu encodeten Materials der Ton nach dem Vorspulen (bzw. Vor-Klicken auf der Zeitleiste) weg. Woran liegen solche seek-Probleme?

Die Bildschärfe ist jedenfalls mit den derzeitigen Einstellungen nahezu unverändert zur Quelle. Nur, dass schon Verblockung bei Flächen auftauchen. Die bekommt man wahrscheinlich nur mit höheren Bitraten weg. Oder kennst du noch eine bessere Möglicheit?

Ich werde mir mal den 2Pass angucken und mit ca. 13 Mbps encoden, was ich persönlich eigentlich für recht ausreichend und ausgewogen empfinde. Das Anderthalbfache der Encodierzeit wäre gerade noch so verkraftbar; vielleicht immer nur für langsame und kontrastreiche Bilder bei 1080p Material bevorzugen, wie du gesagt hast?

Ansonsten fährt man wohl mit den Voreinstellungen Quality: High + Preset: Slower + Tune: Grain + kleine Änderungen (crf=19.5 ref=4 me=umh subme=7 keyint=240 keyint_min=24) ganz gut. Dabei kamen auch ca. 13 Mbps heraus bei 4,7 fps.

 

[OctoCore]

Ob man jetzt grain braucht, sei mal dahin gestellt. Sollte bei modernem Digitalmaterial oder digital aufgefrischten Altfilmen eigentlich nicht nötig sein. Oder hast du körnige/verrauschte Vorlagen - okay, es gibt auch moderne Filme, da wird das extra als cooler effekt draufgelegt - aber dann darf man grain erst recht nicht nehmen, das würde ja weggebügelt.
fast-pskip macht das Ergebnis nicht schöner. Im Zweifelsfall unterschlägt es aber Bildinformation. Von der Geschwindigkeit weiß ich nicht, was es ausmacht.
2 Pass bringt durch die Analyse den Encoder in die Lage, wirklich zu wissen, wo man jetzt die Bitrate erhöhen kann und wo eine hohe Bitrate nicht so wichtig ist bzw. bei einer festen Zielgröße die Bits optimal zu verteilen. Bei 1Pass geht das einfach nicht.

 

[Tyler]

Also entweder hab ich dich falsch verstanden oder... :
Grain bügelt das Grain weg? Nee, genau umgekehrt. Tune Grain behält das eigene Film-Rauschen. Dieses leichte Grieseln/Gekörnte wird übernommen. Wenn ein Film im Original so eine Körnung aufweist (auch sehr viele neuere), hat x264 die Eigenschaft das Banding und Blocking bei nicht extrem hohen Qualitätseinstellungen des Encodings zu erhöhen. Das Bild vermatscht dabei ein wenig. Also wird Grain gewählt, um das "Grain" des Filmes einheitlich zu erhalten. Hier benötigt man pro Makroblock aber mehr Informationen. Die Bitrate fällt also im Ergebnis automatisch entsprechend höher aus.

Der DivX Player 7 hatte eine Funktion bei den Voreinstellungen, die hieß "Filmeffekt". Die hat ein künstliches Bildrauschen hinzugefügt, um die Compression Artifacts zu minimieren und das daraus resultierende Blocking weniger wahrnehmbar zu machen.

So wie ich das mit den 1Pass / 2Pass verstanden habe, verteilt crf mit 1Pass auf die Frames, die eine erhöhte Bitrate/Qualität benötigen mehr Bit, als unwichtigere Frames. Und zwar soviele Bit, wie für den eingestellten Qualitäts-Faktor benötigt werden. Zwei unterschiedlich aussehende Filme können also bei gleicher Laufzeit und gleichem crf um ein Vielfaches unterschiedlich groß ausfallen.

Passiert diese Aufteilung bei 2Pass auch?

 

[OctoCore]

Kannste mal sehen - ich schrieb ja schon, dass ich die Presets nicht nutze - ganz einfach, weil es die früher nicht gab. Dafür habe ich ungefähr 40 vorgefertigte Profile nur aus den Einzelanweisungen.
Es gibt für Avisynth ein Plugin, das grain entfernt - das hatte ich wohl im Kopf.

Mit 1Pass kann ja nichts "verteilt" werden, weil der Encoder nicht weiß, was auf ihn zukommt.
Da gehst du praktisch entweder nach Qualität oder Bitrate.
Bei Qualität weiß man nie, wie groß das Teil wird.
Bei Bitrate will der Encoder die gegebene Bandbreite einhalten, weiß aber nicht, was auf ihn zukommt - so bekommen Szenen, die auch mit weniger Bandbreite auskommen würden, zuviel als nötig und aufwändige Szenen eben manchmal zu wenig. die werden praktisch mit dem Durchschnitt abgespeist.

Bei 2-Pass weiß der Encoder dank der Analyse, wo er Bandbreite sparen kann, die schlägt er dann bei den bedürftigen Stellen drauf. Optimale Resourcenverteilung.

Sinn macht das natürlich nur, wenn eine vorgegebene Größe bzw. Bitrate strikt eingehalten werden soll. Wobei eine vorgegebene Größe natürlich eine entsprechende Bitrate nach sich zieht.
Sowas macht man eben, wenn man eine bestimmte Anzahl an Filmen oder TV-Folgen auf eine DVD bringen will, um den vorhandenen Platz möglichst gut zu nutzen. Für HD ersetze DVD einfach durch BD.

Lange Rede, kurzer Sinn: Wenn du nur Quality nimmst, kannst du dir 2-Pass schenken. Da kriegt jeder Frame, was er braucht und ansonsten wird auf die Endgröße gepfiffen.

 

[Tyler]

Mit 1Pass kann ja nichts "verteilt" werden, weil der Encoder nicht weiß, was auf ihn zukommt.

Ich denke, das ist ein Irrglaube.
Siehe:

Constant Ratefactor. Während qp auf einen bestimmten Quantisierer abzielt und Bitrate auf eine bestimmte Dateigröße abzielt, zielt crf auf eine bestimmt "Qualität" ab. Die Idee bei crf ist, die gleiche Wahrnehmungs-Qualität wie qp zu liefern, nur innerhalb bei geringerem Speicherbedarf. Die willkürliche Maßeinheit für crf-Werte ist der "ratefactor".

CRF erreicht dies durch eine Verringerung der Qualität der "weniger wichtigen" Frames. In diesem Zusammenhang bedeutet "weniger wichtig", Frames in komplexen Szenen oder Szenen mit viel Bewegung, wo die Qualität entweder teurer (in Bezug auf die Bit) oder weniger sichtbar ist, und deren Quantisierer erhöht wird. Die Bits, die in solchen Frames gespeichert werden, werden zu den Bildern umverteilt, bei denen sie effektiver sein werden.

CRF nimmt weniger Zeit in Anspruch, als ein 2pass-Bitrate-Encode, weil der "first pass" übersprungen wird. Auf der anderen Seite ist es unmöglich genau vorherzusagen, welche Bitrate ein CRF-Encode haben wird. Es liegt an Ihnen zu entscheiden, welcher Rate-Control-Modus für Ihre Umstände besser ist.
Quelle

 

[Tyler]

2 Pass bringt durch die Analyse den Encoder in die Lage, wirklich zu wissen, wo man jetzt die Bitrate erhöhen kann und wo eine hohe Bitrate nicht so wichtig ist bzw. bei einer festen Zielgröße die Bits optimal zu verteilen. Bei 1Pass geht das einfach nicht.

Habe auch dazu noch folgendes nachgelesen:

Seit einiger Zeit gibt es bei x264 keine Unterscheidung mehr in der Art wie 2Pass und CRF funktionieren.
Der erste Durchlauf (first pass) der 2Pass-Methode dient lediglich dazu den gewünschten CRF-Wert zu ermitteln mit dem dann im zweiten Durchlauf (second pass) encodet wird.
Kleines Beispiel:
Du möchtest 1 h Filmmaterial mit 1000 kbit/s im 2Pass encodet haben damit du auf genau 439,45 Mb kommst.
Der erste Durchgang ermittelt dir einen CRF von beispielsweise 21.32154.
Der zweite Durchgang encodet dann mit dem gefundenen CRF und du bekommst deine 440 MB große Datei.
Die hättest du aber auch gekriegt, wenn du gleich mit 1Pass --crf 21.23154 encodet hättest.
2Pass ist also nur noch sinnvoll, wenn man eine bestimmte Größe erreichen will.
(Quelle)

 

[OctoCore]

Mit crf behandelt man alle gleich... das ist der Nachteil, also auch die Stellen, dies es nicht nötig haben- das führt aber auch dazu, das das die Enddatei größer ist als nötig.
Das ist ja nicht gedacht dafür, eine konstante Datenrate zu haben, sondern konstante Qualität.
Das 2Pass für den CRF ist eine ganz andere Baustelle. Damit wird dir die Testerei für den CRF erspart. Nix Irrglaube - der ermittelte CRF wird ja am Ende über alles gebügelt, richtig? Also nicht individuell.
So sehe ich das... ich bin da aber durch keine praktische Sachkenntnis belastet, weil ich grundsätzlich 2Pass nehme.
Also hau mir ruhig gnadenlos was rein, wenn ich falsch liege, meinem Wissen kanns nur gut tun.
Das "richtige" 2-Pass-Verfahren kannst du, wenn du die CRF-Brille aufbehalten willst, so sehen, das der CRF dynamisch (das hinkt aber - weia - constant dynamisch) nach dem Bedarf einer Bildsequenz angepasst wird. Wobei da natürlich Grenzen gesetzt sind - eben durch die Datenrate bzw. Größe.
Wenn nicht genug Sequenzen vorhanden sind, die wenig Qualität brauchen, kann der Encoder ja nicht den Stellen, die nach vielen Bits gieren, die auch spendieren, ohne die Endgröße zu überschreiten.
Soooo und was du oben zitierst ist das gleiche, was ich grade von mir gegeben habe - wie passt das bei CRF, wo man eine Wert von 18 oder 22,463 angibt, der global wirkt?
Aber ich sehe schon den unterschied - Wenn das Material einigermaßen ausgeglichen ist, dann hast du bei 2Pass bestmöglche Qualität, ohne dir einen Kopf machen zu müssen UND eine feste Größe. Das wäre dann der Optimalfall.
Dazu kommt bestimmt auch, das bei CRF das Material irgendwie auch analysiert werden muss- das bekommt man bestimmt nicht geschenkt. Das müsste schon etwas langsamer sein, als ein 1 Pass ohne CRF.

Der Gedanke beim CRF ist ja eigentlich, auf 2Pass verzichten zu können - aber wenn man vorher trotzdem einen Analyselauf macht (dafür gibt es wohl AVS-Scripte), um den optimalen Faktor zu ermitteln, finde ich das irgendwie kontraproduktiv. Außer es geht extrem schnell. Aber ich bin da auch nicht der große Theoretiker und Qualitätsnerd. Ich gehe immer nach Augenmaß. Wo bekommt man ohne Analyse den CRF her? Durch raten. Oder Ausprobieren. Oder einfach immer denselben draufknallen.

Das Hauptproblem bei der ganzen Sache ist das HD-Material. Du bekommst eine normale DVD-Vorlage (oder Standard-TV) ja ganz lässig klein, ohne groß die Qualität zu beeinträchtigen. HD ist oft genung schon in h264/AVC. Das noch weiter zu destillieren wird schwierig - zumindest ohne Kompromisse. Und langwierig - leider taugt das CUDA-Zeugs nicht für HD.
Eigentlich müssen sich nur die Leute einen Kopf über den ganzen krempel machen, die aus dem Originalmaterial des Films BluRays für den Handel machen müssen, oder eben diejenigen, die noch MPG2-Material von DVD oder TV schrumpfen wollen.
Warum sich eigentlich sonst noch die Mühe machen?
Wer sich aus den dunkleren Ecken des Netzes die Filme holt, hat sie schon klein - naja, relativ.
Der Heimcineast wird sich seine BDs grundsätzlich rippen, wegen Investitionssicherung und um dumme Einschränkungen zu umgehen - aber weiter komprimieren wird er sie kaum. Vielleicht um zwei Filme auf einen BluRay-Rohling zu bekommen, um den zum nächsten Filmmarathon beim Kumpel mitzunehmen.

 

[Tyler]

Also hau mir ruhig gnadenlos was rein, wenn ich falsch liege, meinem Wissen kanns nur gut tun.

Dann fange ich mal an...

Mit crf behandelt man alle gleich... das ist der Nachteil, also auch die Stellen, dies es nicht nötig haben- das führt aber auch dazu, das das die Enddatei größer ist als nötig.

Was du hier beschreibst ist der CQP-Mode (auch: qp). Du wiedersprichst dir, wenn du einerseits sagst, dass CRF alle gleich behandelt, und andererseits, dass CRF für kostante Qualität anstatt konstanter Datenrate gedacht ist. Was du mit deinem "alle gleich behandelt" beschreibst, ist der qp-Mode. Hab ich schon mal geschrieben: CRF verringert die Qualität der weniger wichtigen Frames und verringert hier die Bitrate. Behandelt also NICHT alle gleich. Das ist in jedem x264-Wiki nachzulesen, ob englisch oder deutsch. Der 2. Durchgang beim 2Pass ist ein Durchgang mit einem bestimmten Qualitätsfaktor, der benötigt wird, um die vorher festgelegte Bitrate oder Filesize zu erreichen.

Das ist ja nicht gedacht dafür, eine konstante Datenrate zu haben, sondern konstante Qualität.

Ja, konstante wahrnehmbare Qualität bei geringerer Filesize (im Vergleich zum qp-Mode), durch für einzelne Frames verteilte Bit in einem Makroblock.

Damit wird dir die Testerei für den CRF erspart. Nix Irrglaube - der ermittelte CRF wird ja am Ende über alles gebügelt, richtig? Also nicht individuell.

Stopp Stopp Stopp Stopp... Ganz langsam.
Der crf beschreibt keine Bitrate, sondern einen Faktor. Der Faktor (NICHT DIE BITRATE !!!!) wird über alle Frames gebügelt. Den Qualitätsfaktor erreicht dieses Verfahren (wie schon ein paar mal gesagt) durch den erhöhten Quantisierer bei "unwichtigen" Frames. Jedes Frame erhält eine andere Größe, besteht also aus einer unterschiedlichen Anzahl an Bit pro Makroblock. Genau DIESE Dynamic geschieht nicht ausschließlich in der 2Pass-Methode. Diese Dynamic ist eine Eigenschaft der CRF-Methode. Und diese wird auch im 2. Durchgang bei der 2Pass-Methode angewendet. Die Testerei bleibt dir in keinster Weise erspart, ganz im Gegenteil. Wenn man im 2Pass eine bestimmte Bitrate oder Größe festlegt, muss man die dabei entstandene Qualität, zumindest die, welche sich schon mal aus der Bitrate ergibt, überprüfen. Sie wird für das gewählte Material, also die Bewegungen, Kontraste, Makroblock-Abmessung etc., entweder zu hoch oder zu niedrig sein. Deswegen prüft ja der CRF, ob die Bitrate beim entsprechenden Frame nötig ist oder für ein anderes Frame aufgehoben werden kann. Sie wird also verteilt.

Wenn nicht genug Sequenzen vorhanden sind, die wenig Qualität brauchen, kann der Encoder ja nicht den Stellen, die nach vielen Bits gieren, die auch spendieren, ohne die Endgröße zu überschreiten

Genau das ist das gerade schon erwähnte Problem bei der 2Pass-Methode.

Dazu kommt bestimmt auch, das bei CRF das Material irgendwie auch analysiert werden muss- das bekommt man bestimmt nicht geschenkt. Das müsste schon etwas langsamer sein, als ein 1 Pass ohne CRF.

Aber das passiert eben auch im zweiten Durchgang beim 2Pass! Verstehe doch mal! Und der erste Durchgang analysiert, welcher CRF-Wert für die angegebene Bitrate oder größe im zweiten Durchgang gesetzt werden muss! Wenn du mal die die 2Pass-Brille absetzt!

Wer sich aus den dunkleren Ecken des Netzes die Filme holt, hat sie schon klein - naja, relativ.

Diese Encodes sind aber eben nicht immer mit den x264-Konfigurationseinstellungen encodiert wurden, die man für zweclmäßig hält. Also nimmt man möglichst einen reinen Remux und encodiert ihn selbst. Ich habe Robin Hood (2010) von 27 GB auf 15 GB gedrückt und die Qualitätseinbußen sind nicht wahrnehmbar. Außer beim direkten Framevergleich 10 cm vor dem Bildschirm.

 

[OctoCore]

Die Sache muss ich erstmal auseinanderdividieren...

Was du hier beschreibst ist der CQP-Mode (auch: qp). Du wiedersprichst dir, wenn du einerseits sagst, dass CRF alle gleich behandelt, und andererseits, dass CRF für kostante Qualität anstatt konstanter Datenrate gedacht ist.

Tue ich das? Gemeint ist der Faktor... der bleibt ja

Was du mit deinem "alle gleich behandelt" beschreibst, ist der qp-Mode. Hab ich schon mal geschrieben: CRF verringert die Qualität der weniger wichtigen Frames und verringert hier die Bitrate. Behandelt also NICHT alle gleich. Das ist in jedem x264-Wiki nachzulesen, ob englisch oder deutsch. Der 2. Durchgang beim 2Pass ist ein Durchgang mit einem bestimmten Qualitätsfaktor, der benötigt wird, um die vorher festgelegte Bitrate oder Filesize zu erreichen.

Damals stand sowas in Wikis und sonstigen Tuts fürs normale 2Pass. Damals = 3 Jahre? Ich weiß nicht mehr genau - definitiv auf jeden Fall vor der Einführung von irgendwelchen Presets im Encoder.
Jetzt wird es etwas durcheinander. CRF ist doch ein 1Pass-Verfahren - irgendwann hat mal einer ein Avisynthscript geschrieben, das man übers Video jagte, um den einigermaßen passenden Faktor zu finden, weil das wohl eine der Hauptfragen ist: Was nehme ich denn da am Besten? (Zumindest habe ich das mal so am Rande aufgenommen) Das wäre dann der erste Durchgang - wenn man ihn überhaupt so bezeichnen kann, weil er offiziell nicht existiert.

Der crf beschreibt keine Bitrate, sondern einen Faktor. Der Faktor (NICHT DIE BITRATE !!!!) wird über alle Frames gebügelt.

Das ist klar. Ich habe auch nichts anderes behauptet - oder gemeint. Siehe oben. Wennn das missverständlich rüberkam, ist es klar meine Schuld.

Den Qualitätsfaktor erreicht dieses Verfahren (wie schon ein paar mal gesagt) durch den erhöhten Quantisierer bei "unwichtigen" Frames. Jedes Frame erhält eine andere Größe, besteht also aus einer unterschiedlichen Anzahl an Bit pro Makroblock. Genau DIESE Dynamic geschieht nicht ausschließlich in der 2Pass-Methode. Diese Dynamic ist eine Eigenschaft der CRF-Methode.

Okay. Nicht ausschließlich in 2Pass. Halten wir das fest. CRF macht praktisch das Gleiche wie 2Pass - dynamische Anpassung.

Und diese wird auch im 2. Durchgang bei der 2Pass-Methode angewendet.

Richtig... die (und ich rede hier von der klassischen 2Passmethode, um keine Missverständnisse aufkommen zu lassen) weiß durch die Analyse, welche Quantisierung sie nutzen muss/kann - aus dem festgelegten Bereich.

Die Testerei bleibt dir in keinster Weise erspart, ganz im Gegenteil. Wenn man im 2Pass eine bestimmte Bitrate oder Größe festlegt, muss man die dabei entstandene Qualität, zumindest die, welche sich schon mal aus der Bitrate ergibt, überprüfen. Sie wird für das gewählte Material, also die Bewegungen, Kontraste, Makroblock-Abmessung etc., entweder zu hoch oder zu niedrig sein.

Nicht zwingend, manchmal kommt das ganz gut hin. Aber egal erstmal.
Aber genau das ist der entscheidende Unterschied. Ich gebe eine bestimmte Größe vor, weil ich das Teil passend auf den Stick oder sonstwas kriegen will. Daraus ergibt sich zwangsweise die Bitrate, klar. Meine Erfahrung sagt mir dann (Überprüfung kann man sich nach ein paar Jahren schenken - das WEISS man dann einfach), ob die Bitrate genügend Qualität für die Auflösung liefert - oder nicht. Dann senkt man entweder die Auflösung, weil das oft weniger schlimm ist, als bessere Auflösung mit Artefakten oder besorgt sich was Größeres.
Aber weiter...

Deswegen prüft ja der CRF, ob die Bitrate beim entsprechenden Frame nötig ist oder für ein anderes Frame aufgehoben werden kann. Sie wird also verteilt.

Jaaaa, jetzt kommen wir zum Punkt, wo der Elefant ins Wasser springt. DAS ist der Unterschied - das Verteilen. CRF kann aus dem Vollen schöpfen - es kann den Bedürftigen aus vollen Händen geben, also zum Beispiel um in actionreichen Szenen gute Qualität zu liefern, und bei Szenen mit maximalpigmentierten Darstellern im dunklen Tunnel nur das, was mindest nötig ist, damit die Zieldatei nicht zu sehr aufgebläht wird. Was früher ein Problem mit Constant Rate/Constant Quality war. Die waren einfach nicht dynamisch genug.

Genau das ist das gerade schon erwähnte Problem bei der 2Pass-Methode.

Das ist kein Problem - das ist ein Feature. Da muss der Encoder haushalten. Er kann nur das verteilen, was er z.B. der Tunnelszene wegnimmt - nur das kann er der anspruchsvollen Actionszene geben.
Wobei die Qualität nicht zwingend schlechter sein muss, im Vergleich zu CRF. Es kommt eben darauf an, wie es grade passt. Wenn es mit der Größe hinhaut, dann muss es nicht schlechter sein als CRF. Zwei Dateien vom gleichen Quellmaterial, die zufällig die gleiche Größe aufweisen, einmal mit CRF und einmal mit 2Pass encodet, haben mit Sicherheit die gleiche Qualität. Nur das 2Pass eben länger gedauert hat.

Aber das passiert eben auch im zweiten Durchgang beim 2Pass! Verstehe doch mal!

Tue ich doch. Das Problem war wohl nur, das klassische 2Pass vom CRF-2Pass zu trennen. Da liegt wohl die Verwirrung.
Ich habe extra die ganze Zeit NICHT im Netz nach Erklärungen gesucht - jetzt mache ich das mal ganz kurz.
Zum Bits verteilen:
The bits saved in frames like these are redistributed to frames where they will be more effective.
Okay, das hätten wir durch. Ich habs aber auch nicht angezweifelt - das Problem bei der Beschreibung ist, was nicht da steht: Nämlich das die gesparte Bandbreite zwar den Frames gegeben wird, die mehr gebrauchen können, aber es kann ja sein, dass die nicht reichen, also gibt es soviel dazu, wie im Rahmen des Qualitätsfaktors erlaubt ist.

Und der erste Durchgang analysiert, welcher CRF-Wert für die angegebene Bitrate oder größe im zweiten Durchgang gesetzt werden muss!

Sind wir jetzt wieder beim nicht existierenden CRF-2Pass?
Der ist nämlich an den Missverständnissen schuld. Wobei ich mich frage, wie lange diese Analyse im Vergleich zur eigentlichen Kodierung dauert.
CRF will take less time than a 2pass bitrate encode, because the 'first pass' from a 2pass encode was skipped. On the other hand, it's impossible to predict the bitrate a CRF encode will come out to. It's up to you to decide which rate-control mode is better for your circumstances.
Aber danke erstmal an dich, dass du die Mühe auf dich genommen hast, mir die Sache zweimal zu erklären. Du hast dir bestimmt die Haare gerauft.

Wenn du mal die die 2Pass-Brille absetzt!

Ich hab' nix gegen CRF, jetzt, wo ich es kenne, ich kanns nur meist nicht wirklich gebrauchen, weil ich feste Dateigrößen brauche. Natürlich kann man alles auf Festplatten speichern und ins Regal legen, die sind billiger als Rohlinge - egal ob DVD oder (erst recht) BD. Da ist die Größe praktisch egal. Ich habe auch zwei Platten mit Material, die im Regal liegen. Aber die sind mechanisch empfindlich und von Magnetfeldern muss man sie auch schützen. Optische Datenträger sind da viel robuster.
Aber mal zurück zu CRF n - wobei n der Wert ist, den ich zum Codieren angebe. Wo bekomme ich den her (ohne Analyselauf - die Möglichkeit gabs ja auch nicht immer) - wähle ich falsch, ist die Quialität im eimer oder die datei ist groß. Wahrscheinlich auch über den Daumen peilen und Erfahrung.

So, jetzt bin ich auf der Suche nach Ersatz für meinen betagten Mediacoder. Das Programm, das du benutzt, funktioniert zwar, aber es ist ziemlich lahmarschig und reizt die 64bit nicht aus.
Der aktuelle Mediacoder (x64), gestern frisch runtergeladen und normal installiert, spuckt mir eine Fehlermeldung ins Gesicht, obwohl ich dem einfach nur mit Defaulteinstellungen gesagt habe, kodier mir die Datei. Hrrrmmmpffff...
Der alte Mediacoder geht aber schon ganz gut ab, im Vergleich zum Einsatz auf meinem alten Q6600 mit 3,333GHz.
Mehr als doppelt so schnell, immerhin kennt der dazugehörige x264 SSE4.2, das sorgt schon für Schub. Aber die aktuellen Modelle sind noch besser an die Sandys angepasst. Und die kennen auch den CRF-Modus, von dem die alte Version noch nie gehört hat.