Beiträge von Koto99

Du kannst ja mal Avisynth MT probieren. Vielleicht bringt es bei dir was.

Man kann es ja kombinieren.

ben_sisko

Aber Geld ausgeben nur fürs Öffnen?
Wobei meine Test oben
http://board.serienjunkies.org…php?p=476184&postcount=36

ja nix ergeben wie man das erklären will.

Probiere morgen mal Build 2040. Wobei ich nicht glaube das, da viel rauskommt bei.

Edit: Wie ich dachte genauso wirklungslos die Build 2040. Das einzige was hilft ist MT

Tom
Das problem ist das Script muss man verstehen um zu wissen welche DLLs man braucht. Das kann man aber auch nur nachvollziehen wenn man nicht zu den Experten gehört.

@Ben_Siko

Danke das wusste ich nicht. Guter Tipp.

Ich habe nun mal etwas Probiert.

Schau mal.
Nochmal als vergleich

x264 Present Slow, Tune Film, CRF 18

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")
DGSource("C:\iND-nordsee.1080p.dgi",deinterlace=0,resize_w=720,resize_h=576)

25 FPS
----------------------------------------------
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")
BicubicResize(720,576)

25 FPS
----------------------------------------------
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
SetMTmode(5,6)
SetMemoryMax(512)
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")

mt("BicubicResize(720,last.height)")
mt("BicubicResize(last.width,576)",splitvertical=true)

34 FPS
----------------------------------------------
HC Enkoder
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")
DGSource("C:\iND-nordsee.1080p.dgi",deinterlace=0,resize_w=720,resize_h=576)

AVG FPS 80
----------------------------------------------

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")
BicubicResize(720,576)

AVG FPS 80
----------------------------------------------

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
SetMTmode(5,6)
SetMemoryMax(512)
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")

mt("BicubicResize(720,last.height)")
mt("BicubicResize(last.width,576)",splitvertical=true)

AVG FPS 110

Gerundet die Werte. Bis 0.5 abgerundet ab 0.5 auf.

In anbetracht das Avisynth MT ja umsonst zu haben ist ne klare Sache.
Gforce 550M Dell XPS 17 2 Generation. 8 Gig Ram.

Zitat

Gerade habe ich übrigens wieder feststellen müssen, dass DGDecNV zumindest einen Vorteil gegenüber FFMS2 hat: es arbeitet fehlerfreier. FFMS2 hat scheinbar immernoch Probleme mit (M2)TS-Dateien... bei der gerade getesteten MKV-Datei lag die Gesamtframeanzahl um 18 Frames daneben... und hin und her springen in einem geladenen Script sollte man sowieso nicht. Ich dachte zuerst, dass es an einer zu alten Version läge - aber es ist tatsächlich die aktuellste verfügbare r683 . Dafür bietet FFMS2 eine deutlich breitere Formatunterstützung...

Ich muss zugeben ich nehme nur VOBs oder MKVs als Source. Ob Frames fehlen, kann ich nicht sagen. Ich habe es nicht gemerkt. Wenn es am ende ist, wäre es ja egal.

Normal müssten man 18 Frames ja irgendwie merken oder es ist bei MKV als Source nicht so?
Man kann es ja ummuxen.

Zitat

Ich weiß aber mit Sicherheit, dass DGDecNV bei meinem letzten HD2DVD-Encode deutlich schneller als FFMS2 lief.

Bei meiner letzen HD2DVD habe ich gemerkt das Resize kam nicht hinterher. Die CPU hatte sich gelangweilt. Da half dann Avisynth MT. Ok, DGDecNV hätte ich da mal versuchen können das stimmt. Vielleicht teste ich das mal aus.

Bin mal gespannt ob DGDecNV mehr bringt als MT Resize. Das DGDecNV kostet ja immerhin Geld. Finde schon das muss sich in der Praxis bewähren wenn man Geld will.

Wobei Stacrip DGDecNV auch nicht nimmt. Habe das nie hinbekommen. Findet er auch nie. Habe nie eine Hinweis gefunden in welchem Path das liegen soll das er das Automatisch verwendet. Bei DGScource bekommt ich nur keine Funktion DGSource. Den Path angeben halt nix.

Zitat

Und ich bin dafür, dass jemand auch weiß, WARUM er genau WAS machen soll - sonst kommen Leute nämlich gerne wieder direkt zu einem angerannt und fragen nach, wenn sich irgendwas mal "falsch" verhält (und dafür bin ich zu faul). Sowas passiert einfach seltener, wenn auch die Bedeutung und Funktion von Script-Befehlen und Kommandozeilenparametern bekannt ist...

Damit verschreckt man aber auch viele. Ok, dann hast Du deine Ruhe das stimmt.

Zitat

Und auch Restore24 oder SRestore sind nicht so schwer zu bedienen

90% bekommen das Script nicht mal ans Laufen. Weil keiner aber auch keiner angibt, welche DLLs dazugehören. Alle Avisynth Scripter sind chronisch betriebsblind.

Und ich finde es dann übertrieben immer in die Foren zu gehen. Auf dauer ist das nix.

Übrigens. Never Change a Running System.

Beispiel:
Ich habe einen Patriot Box Office Mediaplayer mit Firmware v2. Der kann das Forced Flag bei MKV Streams auslesen. Was die Realtek Player mit neuen Firmware nicht mehr können.

Mein Fazit Never Change a Running System.

Beispiel 2
Das Lustige ist, das geht auch nur bis MKVMerge 3.4.0 mit neueren MKVMerge zeigt der Player gar keine Untertitel mehr.

Die Frage ist nun, warum brauche ich eine neue Firmware, die Funktionen weniger hat und neue MKVMerge die eigentlich nix besser machen?

Klar Bugfixes aber keines der Bugs habe ich je bemerkt, während die neuen Versionen nix als ärger machen. Fazit: Never Change a Running System.
Das ist wie die Header Kompression. Die zu nix weiter nütze ist als das die Files inkompatibel werden. Fazit Never Change a Running System.

Übrigens habe mich wohl geirrt. Die neue x264.exe wirft im Log doch eine Fehlermeldung aus. Es scheint zwar MBAFF zu sein aber, da bin ich unsicher. Bin ich wieder auf meine alte aber erprobte x264.exe.

Never Change a Running System.

Oder anders. Wenn ein System stabil läuft, ist es veraltet. Jo dann ist das eben so.

Zitat

Und StaxRip besteht zu einem Großteil auf die mitgelieferten Versionen seiner benötigten Tools - das hat mich beim ersten Ausprobieren am meisten daran gestört, weshalb ich's wieder gelöscht hatte.

Hm, das viel mir noch nicht auf. Die x264..exe zb hatte ich ohne Probleme tauschen können. Wobei ich auch jemand bin „Never Chance a Running System“

Super uarg. Schon die Webseite und die ganze Adware. NEIN DANKE. Wobei ich nicht mal weiß, ob das auf Avisynth basiert. Das Teil war schon beim Runterladen ein NO GO

Zitat

Bei einem Vergleich womit(?) und mit was für einer CPU-Auslastung in beiden Fällen?? Denn wie gesagt: wenn der Flaschenhals woanders liegt, macht der Decoder auch keinen Unterschied.

Beispiel:
LoadPlugin("D:\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")

FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv")
#DGSource("C:\iND-nordsee.1080p.dgi", resize_w=1024, resize_h=576)

Macht keinen Unterschied. 99-95% CPU last auf der x264 exe jeweils. Present Slow.

Natürlich habe ich bei FFVideoSource Stax auch so Resizen lassen.

Nun sagst Du bestimmt CPU zu schwach da schon bei 95%. Nur wenn ich das Resize DGDecNV überlasse also der GPU, wird die CPU nicht entlastet. Welche CPU soll man den da haben für eine Wirkung?

Wobei ich das eh nicht verstehe. Nun sagen wir mal das Resize von 1080p auf 1024x576 kostet 10% CPU Power. Dann müsste ich ja eine Wirkung haben. Wenn auch klein.

Existiert den eine CPU, die das bringt?
Habe einen Intel I7 2630 QM CPU Generation 2.

Es ist ja dann auch sinnfrei, wenn ich einen I9 64 Core und 20 HT brauche.

Und Flaschenhals. Das ändert ja am Ergebnis nix. Wenn man das in der Praxis quasi nie zum Vorteil bekommt, weil man immer einen Flaschenhals hat, dann bekommt man einen Hals. Und hat Geld umsonst ausgegeben.

Von Theoretischen vorteilen hat keiner was.

Zitat

Eigentlich ist --interlaced eher schlecht. X264 sollte nämlich zwingend die Field-Order mitgeteilt werden. Wird die falsch angegeben, stimmt nämlich die Bildreihenfolge nach dem Deinterlacing nicht mehr - die Wiedergabe ist dadurch zuckend.

Keine Ahnung, wie das x264 bei --interlaced gehandhabt hat - wahrscheinlich hat es einfach die Field-Order übernommen, die AviSynth geliefert hat. Aber AviSynth kann damit auch falsch liegen (wenn z.B. beim Quellmaterial die Field-Order schon falsch ist... oder man aus Unwissenheit eine falsche manuelle Angabe dazu im Script macht). Deshalb macht die Unterteilung in --tff und --bff durchaus mehr Sinn als --interlaced.

Das ist das klassische Beispiel für etwas zu Wissenschaft machen.:-)
Man hat eine Quelle die läuft sauber. Also –interlaced. Also so lassen, wie sie ist.

Für TTF muss ich die Field Order ermitteln. Es wäre nur falsch, wenn die Source schon ruckelt.

Deine Methode führt nur zu mehr Arbeit.

Wobei ich nun nicht genau weiß, wie Stax es ermittelt. Ich weiß nur der verhaut es nicht. Da sind schon einige Serien durchgelaufen.

Ich habe das probiert, offenbar ist die –interlaced Option nicht raus. Es geht wohl beides. Field Order angeben oder eben nicht. Ich würde auch lieber die alte EXE nehmen als erst anfangen Field Orders zu ermitteln

Ich bin ein Freund von Same als Source. Zumindest wenn man keine Wissenschaft draus machen will. Defaktor ist das so, das man dann für 1% der Sourcen immer alles ermittelt.

Ok, eine einschränkung. Kommt auf das Material an. Wenn man natürlich oft Material nimmt das jemand schon mal Enkodiert hat, mag das was anderes sein. Wobei man mit One Click Tools auch selten die Field verhaut.:-)

Und ich weiß Du bis Perfektionist.
Bei dem Aufwand würde ich aber schnell Irre.

Beispiel: Star Trek TNG DVDs.

Übles Normgewandel.
Beim Deinterlacen hat man Geisterbilder und Ruckeln. Da einen Deinterlacer zu finden bzw diese Normwandlung rückgängig zu machen ist sehr viel Arbeit. Erst mal ein Script finden.

--Interlaced und sie sehen so aus wie auf DVD.

Klar Du sagts sind übel, aber ich will dann eben nicht ewig rummachen. Die DVDs sind auszuhalten.

Das meine ich auch mit Aufwand. Man kann das wirklich bis zum exzess treiben. Lieber mache ich nun davon BD zu SD MKV.

Ich nehme auch an, der Thread ersteller will es erst mal einfach. Man kann dann ja immer noch tiefer in die Materie einsteigen. Am anfang ist das sonst nur verwirrend. Wer nicht weiß was TFF & BFF ist muss es erst mal auch nicht wissen.

--interlaced und gibt es stress melden.

Wobei wir nun auch Offtoppic sind

Zitat

Es gilt nämlich grundsätzlich immernoch: manchmal wird progressiv gedrehtes Quellmaterial unnötigerweise bei der PAL-Wandlung zu interlaced Video verwurstet und dann so ausgestrahlt.

Überlässt man diverses "exotisches Interlacing-Material" dem Deinterlacer vom Fernseher, erzeugt der üblicherweise Blendings - also regelmäßig erscheinende Mischbilder aus ursprünglich progressiven Vollbildern (und somit ein leichtes Ruckeln). Solche eingebauten Deinterlacer sind nämlich nicht besonders clever, sondern haben nur ein Ziel: halbwegs brauchbare Vollbilder ausspucken.

Ja, aber Du vergisst da was. Du solltes dann für jede Source einen anderen Deinterlacer nehmen. Willst Du das richtig machen. Das ist kaum praktikabel. Ok vielleicht für Didde von Gleitz.
Normwandlungen rückgängig machen ist nicht simpel. Das geht über simples Deinterlacen hinaus.

Zitat

Ich rate auch nicht zu MeGUI - trotzdem übertreibst du. MeGUI bietet ja eine Reihe an Presets an, sowie eine GUI für die x264-Konfigurationen - und das, damit man eben nicht die Kommandozeile komplett eintippen muss.

Ich finde die GUI Furchbar. Nicht die Funktionen die sonden die Anordnung und Gliederung. Dann lieber Selurs Hybrid. Wobei das einfach zu verbuggt ist.

Zitat

Aber darum geht es auch weniger, sondern vielmehr darum, die CPU für Filter-Aufgaben und das Encoding "frei zu halten"! Wenn die CPU nämlich schon zu 30%, 50% oder mehr von der Software-Decodierung beansprucht wird, ist ja klar, dass weniger Reserven für Filterung und Encodierung zur Verfügung stehen.

Also mit einer GF 550 ist die Wirkung = Null mit einem Intel I7 Sandy Bride.

Das Decodieren also der Aufwand wird da vollkommen überschätzt. Zumindest ist da nix zu merken. Hatte das natürlich ausprobiert.

Zitat

Welche alte x264-Version benutzt StaxRip denn ? Den Kommandozeilenparameter --interlaced gibt's doch meines Wissens gar nicht mehr - nur noch --bff und --tff...

Ähm gute frage.
Das höre ich auch zum ersten mal. Habe mal geguckt

x264 core:119 r2106 steht da, wobei ich nun nicht weiß, wie alt die sein mag.

mal geguckt aktuell ist 2208. Also wohl doch ne weile her wenn ich ins Changelog gucke.
Danke für die Hinweis.:-)

Wobe das entfallen von --interlaced steht nicht im Changelog oder ich habs übersehen.

Aber ich lerne natürlich gerne dazu wenn dem so ist. Wobei das –interlaced gut ist. Man muss ja da nicht erst wissen ob TFF oder BFF vorliegt.

Zitat

Wofür braucht man denn 25i? Das sind doch dann 25 Halbbilder je Sekunde verpackt in 12,5fps? Weißt du, was du da machst

Das bezieht sich auf Pal Kompatibilität. Wobei das eh nur Theoretisch ist.

Also ich muss hier mal was einwerfen. Klar kann Staxrip TS Files nehmen. Gar kein Problem. Wobei es ja auch einfach möglich wäre, TS zu MKV zu muxen.

Und das zu h264 machen ist auch kein Problem. Das was Tom sagt mag so richtig sein, aber er macht auch eine Wissenschaft draus. Ich würde mich da nicht irre machen lassen. Mein das nicht böse aber eine gewisse Fachblindheit haben die Experten gerne mal

Ich würde Interlaced immer Interlaced lassen. Gerade bei Quellen von DVD ist es oft kein Interlaced, sondern Normgewandeltes. Und nicht jeder Deinterlacer taugt was. Das kann man dem TV überlassen.

In Staxrip kommt man unter Config Codec / Commandline

--interlaced

an und es wird Interlaced (MBaff)

Um aus 50p 25p zu machen
selecteven()

Bei Interlaced 50I ist es
Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()

für 25I

Und ich rate nicht zu MeGui. Zumindest nicht, wenn man keine Wissenschaft draus machen will. Viel zu kompliziert. Da kann ich ja gleich mit der Commandline anfangen.

Zumindest meine Meinung.

DGIndexNV kann man vergessen. Das bringt in der Praxis nämlich gar nix. Also vom Speed her gesehen. Ist auch gar nicht nötig sondern überflüssig. Keine Funktion von Stax setzt das vorraus.

Wenn man es beschleunigen will dann wohl mit Avisynth MT. Also Multicore Optimiert. Zb ein Multicore Resize von 1080 zu SD kann man damit deutlich beschleunigen. Avisynth ist leider nur Singel Core. Kann dazu gerne helfen.

Und ich habe wohl mehr BD zu MKV gemacht als so mancher hier.

Zitat

ffmpegsource2 versagt auf ganzer Linie bei 1080i Aufnahmen von HD+.

Dazu würde ich auch mehr als nur diesen Satz lesen wollen. Das ist mir zu Pauschal simpel dahingesagt.

ben_sisko

Ich finde es irgendwie schon lustig, das Du sagst "klar sind die aus den Netz".

Das Uploader was kaufen muss heute wirklich Exotisch sein.

Irgendeiner muss sie ja mal erwerben zum rippen.:-)

Spricht Du saugst die auch aus dem netz

Die DVDs waren stellenweise sogar deutlich ansycron. Daher glaube ich ja es ist ein DVD Dubb Ton.

Die BDs von John passen ja.

John
Wann gehts weiter

Ich weiß nicht was Du immer mit dem Compressions Check hast.

Ist klar das sich deine Filegröße nicht ändert.
Da muss Du gar nix einstellen.

man setzt CRF eben hier.

nochmal 7. Compressibility Check

Zitat

This step will run the compressibility check to give us some indication of what resolution and/or file size we should be setting in the next step, and to give us an estimation of the output quality. Click on the "Run Compressibility Check" option (just below the "Codec Configuration above") to start the compressibility check. This will start x264 and it will encode a portion of the video - you can have a look at the encoding framerate to give you an indication of how long the total encoding will take.

Das hat bei CRF null Relevanz. Damit kannst Du bei 2 Pass ermitteln, wie gut eine Source komparierbar ist. Mehr auch nicht.

Du kannst bei Compressibility Check einstellen was Du magst wird vom Programm bei CRF Ignoriert.

Zu anderen. Da gibt es keine Liste. Das sind Grundlangen von Avisynth.
Einer der großen Vorteile von Staxrip ist, das man Avisynth nutzen kann. Und auch Einbauen kann zur einfachen verwendung.

Wer damit umgehen kann, kann sogar Filme restaurieren. Zb Denoiser oder bei alten Filmen Staub & Kratzer entfernen. Alte Zeichentrick Filme aufpolieren

Zb will man Interlacec Resitzen sollte man
TDeint(mode=1)
BicubicResize(%target_width%,%target_height%,0,0.5)
separatefields().selectevery(4,0,3).weave()

Setzen.

Mit Sharpen könnte man nachschärfen mit tweak Farben korrigieren usw.

Avisynth ist ein mächtiges Werkzeug.
http://avisynth.org/mediawiki/Main_Page/de

Und hier sind die Experten, die Erstaunliches möglich machen.
http://forum.gleitz.info/forum.php

Ich selber verstehe zwar vieles auch nicht, aber ich kann es anwenden.

MR Download

Wenn ich mich richtig erinner
selecteven() ohne AssumeFPS(25, 1, true).

Die Lauflänge soll sich ja nicht ändern sonst passt der Ton nicht. Es werden nur die Doppelten Bild Frames verworfen bei Progressiv.

Das geht auch sehr gut habe ich schon öfters gemacht.

Bei Interlaced 50I ist es
Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()

Zitat

Keinerlei Respekt oder Dankbarkeit.

Zur Dankbarkeit.
Das ist natürlich immer so eine Sache. Die Macher von so was sind keine Samariter. Die machen das auch nicht umsonst. Daran ist auch nix Verwerfliches. Ich gönne dehnen das auch. Wer das Risiko hat, soll auch was davon haben.

Aber meine Dankbarkeit für eine Seite hält sich da dennoch in Grenzen. Gäbe es kein JS, gäbe es tausend andere Seiten und Quellen. Von Leuten, die ebenfalls was verdienen wollen. Die machen das ja nicht für uns, die machen das für sich. Die Nutzer sind nur mittel zum Zweck der Kohle.

Das wird gerne wortstark abgestritten gerne mal mit einer Beleidigung aber glauben tut es dennoch keiner.

Das ist auch wie die Uploader. Die Vergütungen sind nicht dolle aber die Profi Uploader machen das auch nicht umsonst.

In der Warez Szene werden knallhart Interessen ausgenutzt und bedient. Das mag früher mal anders gewesen sein vor dem Internet. Aber heute ist Warez ein Geschäft.

Ich denke das viele das erkannt haben. Ob man das nun wahrhaben will oder nicht.

Zum Respekt.
Das es mittlerweile zum allgemeinen Ton gehört zu Beleidigen und bashen zu Dissen, das ist wohl so. Quasi, jeder ist ein Idiot dessen Meinung ich nicht teil. Und vor allem Dingen, teile ich die Meinung nicht. Muss ich natürlich dissen. Und gedeckt ist das durch Meinungsfreiheit.

Natürlich macht man das im Real leben nicht. Keiner geht in die Kneipe. Hey Du Gesichtsruine gibt mir mal ein Bier. Was 2 Euro für diese warme Pisse, Du bist wohl mit der Nachgeburt verwechselt worden.

Wäre ja auch Meinungsfreiheit.

Sorry offtoppic.:-)

Füge in Stax selecteven() ein. Ergibt ein Sauberes Pal.

Denke 2 Pass. Der Mensch ist ein Gewohnheitstier. Außerdem sind viele das auch so gewohnt von xvid.

Und damit man die Größe steuern kann. Viele wollen die Filme ja brennen. Also DVD5 / DVD9 Größen einhalten.

Ich selber habe mir die Frage gestellt, warum ich deutlich länger Encodieren soll. Größe war mir egal. Habe meine Filme & Serien eh auf Festplatten.

Im zweifelsfalle würde ich beide mal Enkodieren und selber gucken ob sich die längerer Enkoding Zeit bei 2 Pass wirklich für dich lohnt.

Ja klar. Nicht mehr drum kümmern sollte das heißen

Und Auflösung spielt immer eine Rolle das ist klar.

Ein Profi weiß aus der Erfahrung irgendwann auch, welche Bitrate sinnvoll ist. CRF ist ein einfach Modus.

Du kannst das nicht steuern mit CRF. Du setzt ja mit CRF eine Mindesquali. Der rest macht der Enkoder. Der Film wird so groß wie der Enkoder meint, für deine Mindesquali zu brauchen.

Das heißt, ein Film kann 800mb bekommen ein anderer 2000. Nicht jeder ist ja gleich gut komprimierbar.

Du kommst also zb mit einer Alien DVD nicht auf dieselbe Größe, wie eine Alien 1080 Source auf DVD skaliert. Praktisches Beispiel. DVD hat mehr Grain wird also größer, weil CRF mehr Bitrate zuweist um auf die selbe Quali zu kommen wie die geresitze 1080er Source mit weniger Grain.

Der Vorteil ist klar man muss sich nicht mehr drum kümmern, wie viel Bitrate ein Film braucht um gut auszusehen. Man stellt eine Quali ein und encodiert los. Ist die Größe wichtig, geht CRF nicht wirklich.

Du kannst auch Interlaced, interlaced lassen.
Warum soll man Deinterlacen das macht den TV ja selber. Ich würde es so lassen wie es ist. Hat die beste Quali.

Es gibt einiges für Quali.
Ein mal der Speed.

Medium bzw Slow sind sehr gute Werte.
Bei CRF ist 20 schon ein sehr guter Wert. Nehmen viele. Ich selber nehme aber auch 18. Damit Filme die viel nebel haben besser werden.

So muss man auch nicht immer eine Probe Enkodierung machen. Sei den Filegröße spielt eine Rolle. Bei CRF ist die Endgröße nicht berechenbar.

Serien mache ich wie Filme. Das nimmt sich nix. Wobei ich bei DVD immer drauf achte das ich alles Interlaced lasse. Ist ja bei Serien auf DVD sehr oft. Und Deinterlacen versagt einfach sehr oft.

18
Slow
Film

Sind gut. Dazu noch Mode auf Quality.

2 Pass hat eigentlich keinen vorteil. Wenn man vergleicht ist das eher eine Idologie Frage. Aber damit kann man die Endgröße besser festlegen das geht mit CRF nicht. Eine DVD kann mit CRF 700 oder 2.5 Gig bekommen je nachdem.

Audio wird nach Sprache genommen.

Beispiel:
Stellst Du bei Edit Language 1 German und 2 Englisch ein und speicherst das als Profil. Dann werden die Audio Spuren automatisch so aus der Source in die Felder reingeladen.

Also Position 1 German, 2 Englisch.

Zum CRF 20
Files werden bei CRF 18 nicht automatisch größer. Man stellt eine Mindesquali ein. Die eingehalten wird. Braucht der Enkoder nicht so viel Bitrate um diese Quali einzuhalten, nimmt er eben auch nicht mehr Bitrate.

Die Files werden nur größer, wenn der Bedarf da ist. Also die Source zb schwierig ist. Zum testen einfach mal einen Film mit viel nebel oder Rauschen nehmen.

Das ist der vorteil von CRF es wird immer nur so viel genommen wie gebraucht wird.

Yafiff braucht man quasi bei HD nie. Es gibt nur wenig HD Interlaced Material. 50 FPS sind meistes TV Aufnahmen. Die bekommt man einfach mit selecteven() zu 25 Pal.

Wenn man guckt HD TV 50 sind meistens einfach Doppel Progressiv Frames. ZB ARD & ZDF HD.

Wobei ich nicht deinterlaced würde das ruckelt. Streiten viele zwar ab, weil sie es nicht sehen. Ist aber so. Gerade bei DVD Quellen die meistens nicht Interlaced sondern schlecht Normgewandelt sind. Ich würde dann lieber in Interlaced MBAFF Enkodieren.

Dazu unter Codec / Commandline / die Option --interlaced setzen.

Der Compressible Check

Zitat

7. Compressibility Check

This step will run the compressibility check to give us some indication of what resolution and/or file size we should be setting in the next step, and to give us an estimation of the output quality. Click on the "Run Compressibility Check" option (just below the "Codec Configuration above") to start the compressibility check. This will start x264 and it will encode a portion of the video - you can have a look at the encoding framerate to give you an indication of how long the total encoding will take.

CRF ist beser. Es ist besser immer nur die Bitrate zu nehmen die für eine bestimmte Quali ausreicht.

Der größen unterschied ist ja schon beachtlich.