Frage Umgang mit Staxrip..noch unklar

Ich kenne mich mit Staxrip zwar überhaupt nicht aus, aber ein paar Sachen sind mir beim Lesen aufgefallen:

supersonik schrieb:

es wird in zwei durchgängen encoded um qualitativ ein besseres ergebnis zu erreichen

Zum Vergrößern anklicken....

Jain. Heutzutage gilt das hauptsächlich für libvpx, also VP8 / VP9 Encodes. Bei x264 / x265 ist bei gleicher Bitrate die Qualität visuell gleich. Two-Pass wird hier nur verwendet, um eine genaue Dateigröße zu treffen (wenn man den Encode auf eine DVD brennt, warum 200MB frei lassen?). Ist aber wahrscheinlich nicht dein Ziel, CRF ist da das Mittel der Wahl. Eine immer noch gute Webseite, wenn auch nicht mehr ganz auf der Höhe der Zeit, ist encodingwissen.de, z.B. hier für CRF (1-pass) vs. 2-pass.

supersonik schrieb:

hab nach ratschlag nvenc auf latest version updated für staxrip

Zum Vergrößern anklicken....

Zumindest für H.265 unterstützt nvenc kein CRF und gibt daher deutlich sichtbar schlechtere Qualität als Encoding auf der CPU. Ist schade, weil das wirklich brachial schnell ist. Vielleicht geht es ja bei H.264?

Und naja, bei -tune animation spalten sich halt die Geister wie du schon sagst, diese Diskussion wird hier nicht beendet werden. Für Material ohne Grain hab ich ich bei x265 mit -tune animation gute Erfahrungen gemacht, bei x264 keine Ahnung. Bei Material mit Grain ist -tune grain allerdings "Pflicht". Aber du wirst wohl nicht drum herum kommen, dir eine eigene Meinung zu bilden.

Auch wenn ich hier vielleicht nicht auf die Frage antworte, sondern ein bisschen shilling betreibe:
Bleib bei ffmpeg. Hier sind Performance, Features und Aktualität der En-/Decoder meist an der Speerspitze. Um dir eine kleine ideale Werkstatt aufzubauen, eine kleine Liste der Schritte, die ich damals mir mit ach und krach selbst erarbeiten musste:

1. Bau dir ffmpeg von der Quelle. Dies ist eig. der eklige Teil, aber der lohnenswerteste. Gleich aber vorab: Wenn man noch nicht viel mit Linux und dessen Distros (Varianten) zu tun hatte, ist das noch mal eine Wissenschaft für sich. Daher kann ich dir ffmpeg in 8bit und 10bit gerne zukommen lassen. Für mich wäre es sowieso mal wieder in der Zeit, meine vor gut einem Jahr gebauten Binaries - also die .exe-Dateien - zu aktualisieren. Ansonsten kann man sich sehr einfach Virtual Box installieren und eine Linux Distribution installieren. Für Anfänger empfehle ich tatsächlich Lubuntu, weil man noch eine grafische Oberfläche hat und trotzdem das Terminal benutzen kann. Für den Rest gibt es eine Handvoll Build-Scripts. Später kann man von da aus die kompilierten Binaries einfach irgendwo hochladen und dann auf dem Windows-PC runterladen, ohne irgendwelche Ordnerfreigabewissenschaften zu machen.
2. Wisse, wohin du willst. Wenn du sicher weißt, dass du BDRips in mkv bzw. mp4 umwandeln willst, ist das schon mal ein guter weg. Tatsächlich hab ich vor einigen Jahren hier mal einen Thread gepostet, in dem ich fast schon eine wissenschaftliche Studie zur 8 vs 10 bit und den unterschiedlichen CRF-Stufen mit dem Original verglichen habe. Spoiler: CRF 16 mit 10 bit hatte im Verhältnis das beste Ergebnis. Preset -fast war beim Encode auch immer merkwürdigerweise das beste von Qualität und Größe. Aber wie gesagt, das ist Jahre her. Den Thread gibt's hier auch noch, aber die ganzen Bilder werden down sein.
3. Alles einfach mit Batch-Dateien. Auch hier kann ich dir wieder eine Vorlage zukommen lassen, mit welcher man per Drag and Drop die gewünschten Dateien auf die .bat-Datei zieht und ffmpeg bzw. Windows diese Dateien emsig mit den vorher festgelegten Parametern durcharbeitet.

Diverses:
Weil hier das Thema Hardwarebeschleunigung erwähnt wurde: Ja, geht, aber so lala. Zumindest ist mein Stand, dass man mit NVENC nicht viel einstellen kann. Daher fliegt das meiste auf die CPU. Je mehr Kerne, umso besser.
Die -tune Parameter habe ich selbst ein paar mal Benutzt, aber nie sagenhafte Unterschiede festgestellt, außer in der Größe. Teilweise werden zwar die -tune Parameter geparst, aber gar nicht umgesetzt, weil die Encoding-Library diese "tunes" zwar hat, aber mit gewissen Filtern nicht einsetzt. Man muss oft gucken, was ffmpeg vor Ausführung des Encodes sagt. Teilweise kommt einiges falsch an. Ach, und das mit -grain kann ich auch bestätigen.
Bei der Frage, ob 8 bit gegen 10, habe ich immer mit 10 bit bessere Erfahrungen gemacht. Encodingzeit ist in etwa gleich, Größe mal etwas kleiner bzw. größer, aber Qualität immer besser. Besonders Banding wird vermieden (sofern es bei der Quelldatei nicht vorhanden war natürlich). Aber bei meiner "Studie" von damals hat sich ergeben, dass 10 bit bei Encodes schärfere "Konturen" bei gleichem CRF-Wert zeichnet. Wo bei 8 bit an Kanten die Pixel eher "verstreut" waren, haben sie sich bei 10 bit an den Kanten gebündelt. Argh, wieso hab ich die Bilder nicht mehr. Jedenfalls: 10 bit, immer vorziehen, zumal wir 2020 haben und das so ziemlich wirklich jedes Handy, TV und sowieso jeder Software-Videoplayer kann - zumindest Softwareseitig.
Bei Codec bin ich auch ein Fan von x265. Es dauert zwar länger im Encode, hat aber mehr Qualität bzw. spart mehr Platz. Es gibt abgesehen von dem Kompatibilitätsargument nichts für x264. Und nach x265 stehen ja nun auch schon wieder einige nagelneue Codecs in den Startlöchern. Aber eben x265 ist schon so lange da draußen, dass es so ziemlich jeder Fernseher, Browser, Softwareplayer, etc. kann.

Hui, das ist lang geworden. :)

Zum Abschluss noch mal der simple aufbaue meiner ffmpeg-batch-dateien:

if [%1]==[] goto :eof
:loop
call "%~dp0/ffmpeg.exe" -i "%~1" HIER KOMMEN DIE PARAMETER HIN "%~dpn1.mkv"
shift
if not [%1]==[] goto loop

Das mkv kann natürlich mit jedem beliebigen Container getauscht werden. %0 und %1 sind sogenannte Placeholder bei batch. %1 würde z.B. den Pfad der Datei übernehmen, die du auf die .bat gezogen hast. %0 sucht in dem Ordner, in dem die .bat-Datei liegt, nach der ffmpeg-Datei. Man kann damit natürlich noch ausgeklügeltere Sachen bauen, aber ein Experte bin ich darin nicht.

elkeZ schrieb:

Teilweise werden zwar die -tune Parameter geparst, aber gar nicht umgesetzt, weil die Encoding-Library diese "tunes" zwar hat, aber mit gewissen Filtern nicht einsetzt.

Zum Vergrößern anklicken....

Das klingt skurril, hast du da ein konkretes Beispiel? Die Filter sollten angewendet werden, bevor dann der gefilterte Videostream in den Encoder geht. Der Encoder sollte also eigentlich gar nicht wissen, ob er gefiltertes oder ungefiltertes Material bekommt.

Die einzigen mir bekannten Ausnahme sind das In-Loop Deblocking und SAO, aber zumindest bei x265 kann das keine Tunes abschalten. Eher umgekehrt setzen einige Tunes die Deblock-Parameter oder schalten SAO an/aus, siehe Preset Options — x265 documentation.