Voukoder macht was es will! Thema ist als GELÖST markiert

[klusterdegenerierung]

Ich komme nicht drauf klar und wollt mal fragen ob einer von Euch einen Tipp für mich hat.
Ich habe erfolgreich einen 3 minütigen 4K Clip mit Voukoder h264 fast gerendert und bin auf eine Rate von 18,5Mbit gekommen womit ich gut zufrieden bin, denn das Ergebnis sieht richtig gut aus und reicht für die Zwecke.

Nun möchte ich einen weiteren, inhaltlich fasst identischen Clip mit nur 1min Länge ebenfalls so rendern und komme immer auf 250Mbit, selbst wenn ich noch mal was in den settings ändere, obwohl das eigentlich nicht nötig wäre, da im fast Profil geregelt ist, das der Wert bei ca. 17Mbit liegen soll.

Es scheint ja geradezu als wenn das Tool sein Profil nicht mehr liest.
Hat jemand einen Tipp wie ich das fixen kann und wieder an die eigentlich Bitrate komme?

Danke! :-)

[Bluboy]

Das muß ein Bug sein, denn 250 Mbit wären 250 000 kbit also 10 mal mehr als Blu Ray

[MK]

Das ist kein Bug. CRF (Constant Rate Factor) in x264/x265 sind keine Mbit.

CRF is a “constant quality” encoding mode, as opposed to constant bitrate (CBR). Typically you would achieve constant quality by compressing every frame of the same type the same amount, that is, throwing away the same (relative) amount of information.


Stelle auf Constant Bitrate um, Problem gelöst. Für größere Genauigkeit bei der Durchschnittsbitrate bei kurzen Clips gegebenenfalls auch mit mehr als einem Pass.

[klusterdegenerierung]

Das ist kein Bug. CRF (Constant Rate Factor) in x264/x265 sind keine Mbit.

CRF is a “constant quality” encoding mode, as opposed to constant bitrate (CBR). Typically you would achieve constant quality by compressing every frame of the same type the same amount, that is, throwing away the same (relative) amount of information.


Stelle auf Constant Bitrate um, Problem gelöst. Für größere Genauigkeit bei der Durchschnittsbitrate bei kurzen Clips gegebenenfalls auch mit mehr als einem Pass.

Ja steht ja groß da!
Deswegen macht es ja erstrecht keinen Sinn, denn die Rate soll kostant sein und die Mbit sind auf 17Mbit eingestellt, wenn der Inhalt wie in meinem Fall quasi identisch ist, gibt es für das Tool keinen Grund hier eine 10x höhere Rate zu wählen.

[MK]

Ja steht ja groß da!
Deswegen macht es ja erstrecht keinen Sinn, denn die Rate soll kostant sein und die Mbit sind auf 17Mbit eingestellt, wenn der Inhalt wie in meinem Fall quasi identisch ist, gibt es für das Tool keinen Grund hier eine 10x höhere Rate zu wählen.

Nein, steht nicht da, Strategie: Konstanter Ratenfaktor (CRF, Constant Rate Factor) ist keine konstante Bitrate, und die 17 sind keine Mbit sondern der Wert für den Ratenfaktor, je kleiner desto besser die konstante Bildqualität (0 = lossless).

Auch nachzulesen in der Dokumentation von x264...

Wähle bei Strategie Durchschnittliche Bitrate (ABR) aus und das Problem ist gelöst.

[klusterdegenerierung]

Ja steht ja groß da!
Deswegen macht es ja erstrecht keinen Sinn, denn die Rate soll kostant sein und die Mbit sind auf 17Mbit eingestellt, wenn der Inhalt wie in meinem Fall quasi identisch ist, gibt es für das Tool keinen Grund hier eine 10x höhere Rate zu wählen.

Nein, steht nicht da, Strategie: Konstanter Ratenfaktor (CFR, Constant Rate Factor) ist keine konstante Bitrate, und die 17 sind keine Mbit sondern der Wert für den Ratenfaktor, je kleiner desto besser die konstante Bildqualität (0 = lossless).

Auch nachzulesen in der Dokumentation von x264...

Wähle bei Strategie Durchschnittliche Bitrate (ABR) aus und das Problem ist gelöst.

Habe ich auch nie gesagt, ich habe gesagt das genau das da steht was Du gesagt hast, nur mit dem Unterschied das Du nicht verstehst, das ein CFR dafür sorgt, das die "vorhandenen" settings constant bleiben.

Übersetzt heißt das, das auch die vorgegeben Bitrate da bleibt wo sie gesetzt ist.
Wenn dem nicht so wäre, wäre das ganze ja kein Profil für gleiche Ergebnisse sondern für immer unterschiedliche und zwar nicht bei unterschiedlichen clips, sondern auch bei ein und dem selben.

Albern und lohnt nicht weiter drüber zu sprechen!

[Frank Glencairn]

Ich kenn das ja hauptsächlich von Handbrake, und da ist die Constant Quality RF Einstellung eher so eine Art globale Qualitätseinstellung, die eine Alternative zum eintippen der durchschnittlichen Bitrate bietet.

[MK]

Habe ich auch nie gesagt, ich habe gesagt das genau das da steht was Du gesagt hast, nur mit dem Unterschied das Du nicht verstehst, das ein CFR dafür sorgt, das die "vorhandenen" settings constant bleiben.

Übersetzt heißt das, das auch die vorgegeben Bitrate da bleibt wo sie gesetzt ist.
Wenn dem nicht so wäre, wäre das ganze ja kein Profil für gleiche Ergebnisse sondern für immer unterschiedliche und zwar nicht bei unterschiedlichen clips, sondern auch bei ein und dem selben.

Albern und lohnt nicht weiter drüber zu sprechen!

Lies doch bitte mal richtig! Du hast keine Bitrate eingestellt!

Der Wert für CRF ist keine Bitrate sondern der Wert für den konstanten Ratenfaktor, nicht die konstante Bitrate. Bei CRF kann man keine durchschnittliche Bitrate angeben da der CRF-Wert ein Mischindex aus Qualität und Ratenkontrolle ist. Je höher der CRF-Wert desto niedriger die Bitrate. Je niedriger der CRF-Wert desto höher die Bitrate. Je kürzer der Clip desto schlechter funktioniert das.

Warum stellst Du nicht wie bereits mehrfach geschrieben die Strategie auf ABR um damit Du die durchschnittliche Bitrate angeben kannst? Wenn die besonders genau eingehalten werden soll dann mit mindestens 2 Passes.

Es handelt sich hier um einen Bedienfehler und keinen Bug.

[MK]

Ich kenn das ja hauptsächlich von Handbrake, und da ist die Constant Quality RF Einstellung eher so eine Art globale Qualitätseinstellung, die eine Alternative zum eintippen der durchschnittlichen Bitrate bietet.

Was ich ja nun bereits mehrfach geschrieben habe, aber nicht geglaubt wird.

[cantsin]

Ich kenn das ja hauptsächlich von Handbrake, und da ist die Constant Quality RF Einstellung eher so eine Art globale Qualitätseinstellung, die eine Alternative zum eintippen der durchschnittlichen Bitrate bietet.

Was ich ja nun bereits mehrfach geschrieben habe, aber nicht geglaubt wird.

Weil's auch nicht stimmt. Constant Quality RF ist keine durchschnittliche Bitrate, sondern ein Wert, der darauf basiert, wie stark der Informationsgehalt des Originalvideos reduziert werden darf, bzw. auf welchem Niveau sich der Signal-Rauschabstand des encodierten Videos im Vergleich zum Original bewegen soll. (Oder, einfacher ausgedrückt: wie stark die Encoding-Artefakte im Zielvideo sein dürfen.)

Um ein Beispiel zu geben: Wenn Du als CRF z.B. einen guten mittleren Wert wie 20 eingibst, und Dein Quellmaterial ist ein einminütiges 1080p-Video, das nur aus einem einfachen statischen Bild (z.B. einer Klötzchengrafik) besteht, kriegst Du im Encoding ein Video mit vielleicht nur 10 Kilobit/Sekunde.

Wenn Dein Ausgangsmaterial eine durchschnittliche Dokumentar- oder Spielfilmszene ist, landest dann vielleicht bei 24 Megabit/Sekunde.

Und wenn Dein Bild aus reinem Bildrauschen besteht [aus einem algorithmischen Generator oder auch einem abgefilmten TV ohne Antennensignal], geht bei CRF 20 Deine Bitrate total in die Decke und landet vielleicht bei 300 Mbit/s, weil es probiert, alle Details des Rauschens auf dieser Qualitätsstufe abzubilden.


Klusters Erfahrung scheint mir daher durchaus nachvollziehbar, denn bei einem kurzen Video braucht man bei gleicher Qualitätsstufe eine höhere Bitrate, weil es am Anfang noch keine Reference-Frames gibt, die nur leicht abgewandelt werden müssen. Es ist durchaus normal, dass beim CRF-basierten Encoding der Encoding am Anfang auf hohe Bitraten geht und sich dann im weiteren Verlauf einpendelt.

Sowieso kann der Encoder an die Decke gehen, wenn's im Video extrem feine und zudem sich bewegende Motivdetails gibt, z.B. Starkregen, bei dem die Regentropfen scharf abgebildet sind, Bäume/Wälder, die im Wind bewegen etc.



- Hat übrigens alles nichts spezifisch mit Voukoder, Handbrake oder ffmpeg zu tun, sondern das ist einfach ein eingebautes Feature des x264-Encoders, der von allen diesen Programmen unter der Haube verwendet wird.

[MK]

Weil's auch nicht stimmt.

Lies doch einfach was ich OBEN geschrieben habe und nicht den Zitatteil von Frank nach dem Komma den ich im Eifer des Gefechts nicht abgetrennt habe, dann hättest Du Dir Deine Schlaumeierei sparen können.

[Bluboy]

Ich schätze dass man bei Wiki den unterschied und warum zwishcen Konstant ud Variabel nachlesn kann
und hirr zwei Bilder

[cantsin]

Weil's auch nicht stimmt.

Lies doch einfach was ich OBEN geschrieben habe und nicht den Zitatteil von Frank nach dem Komma den ich im Eifer des Gefechts nicht abgetrennt habe, dann hättest Du Dir Deine Schlaumeierei sparen können.

Nee, weil auch Deine Aussage "Je höher der CRF-Wert desto niedriger die Bitrate. Je niedriger der CRF-Wert desto höher die Bitrate" missverständlich war. Wie ich erklärt habe, kann ein Video mit einem niedrigen CRF-Wert sehr wohl eine niedrigere Bitrate haben als ein anderes Video mit höheren CRF-Wert...

Den "Schlaumeier" kannst Du Dir daher komplett sparen.

[Skeptiker]

@kluster:
Vielleicht hast Du das Problem schon gelöst, dann ist mein Beitrag überflüssig.
Was in jedem Fall nicht sein sollte: Wenn Dein 2. File nur kürzer ist (1 Minute) und sonst von den Video-- und Kompressionsdaten her vergleichbar, sollte sich bei gleicher CRF-Einstellung (konstanter Ratenfaktor) in Deinem Programm die Bitrate nach dem Rendern im gleichen Rahmen bewegen wie beim ersten File - sicher nicht so stark erhöht wie in Deinem Beispiel!

Ich kenne diesen RF-Faktor nur aus HandBrake (alles, was ich im Folgenden schreiben, bezieht sich nur auf dieses Programm), und es ist zunächst tatsächlich verwirrend, was der macht und wie man ihn einstellen soll.

Ich habe das "RF" für mich mit "Reduktionsfaktor" übersetzt, weiss aber nicht, ob das die offizielle Bezeichnung ist.
Aber wenn ich Reduktionsfaktor mit Kompressionsfaktor (der würde dann über die Dauer des Videos angepasst für gleichbleibende Videoqualität) übersetze, dann kann ich mir auch merken, dass kleinere Werte für RF = geringe Kompression bedeuten, also bessere Qualität und grössere Files ergeben. Vorausgesetzt das gleiche Video (oder ein vergleichbares) liegt als Quelle vor.

Als Default für RF ist (Irrtum möglich), glaube ich, in HandBrake der Wert 22 vorgegeben. Damit müsste ein bereits komprimiertes H.264-File nach dem erneuten Rendern etwa die gleiche Grösse haben wie zuvor.
Ich stelle in einem solchen Fall eher 20 ein (auch 19 oder 18 ginge natürlich), damit der Qualitätsverlust durchs Neu-Encodieren mit H.264 möglichst unsichtbar bleibt.
Audio konnte man früher auch unverändert durchreichen (meine ich), bin nicht sicher, ob das immer noch geht (ich sehe die Einstellung dazu nicht), oder ob nur bei Eintippen der gleichbleibenden kbit/Sek-Vorgabe (also z.B. 44.1 kHz/128 kbps aac im Original bleiben 44.1 kHz/128 kbps aac im neukodierten Audio) das dann automatisch ohne Neukodieren gehandhabt wird.

"Konstante Bildfrequenz" (CFR = Constant Frame Rate) kann man unabhängig vom RF-Faktor im Video-Tab auswählen (links). Das eignet sich auch zum Umrechnen von variablen Bildraten (nicht Bitraten) von Smartphone-Videos.

Verwirrend: CFR klingt fast wie CRF, der konstante Ratenfaktor in Deinem Programm (= RF in HandBrake).

RF-Alternative (wie von MK schon beschrieben): In HandBrake statt "kontante Qualität" (RF) eher "Mittlere Bitrate" auswählen und dort den Wert in kbps eingeben. Encoding in 2 Durchgängen ebenfalls auswählbar.

[MK]

Der Thread driftet gerade in die komplette Absurdität ab...

Bitte über die verschiedenen x264 Rate Control Modes informieren (alles hinreichend dokumentiert und leicht auffindbar) und bis dahin dringend die Finger von der Tastatur lassen:

ABR (Average Bitrate)
CRF (Constant Rate Factor)
CQP (Constant Quantization Parameter)

Dann noch verinnerlichen dass es bei x264/x265 keine "klassische" konstante Bitrate gibt, sondern nur durchschnittlich und maximal. Bei längeren Clips kann die Bitrate mit einem Pass einigermaßen genau über den gesamten Film im Mittel eingehalten werden, bei kurzen Clips nicht, 2-pass ist unumgänglich wenn es auf eine genaue Einhaltung der Durchschnittsbitrate für eine bestimmte Zielgröße ankommt (z.B. für das Bit Budgeting bei einer Blu-ray).

[MK]

Den "Schlaumeier" kannst Du Dir daher komplett sparen.

Nicht weinen.

[cantsin]

@kluster:
Vielleicht hast Du das Problem schon gelöst, dann ist mein Beitrag überflüssig.
Was in jedem Fall nicht sein sollte: Wenn Dein 2. File nur kürzer ist (1 Minute) und sonst von den Video-- und Kompressionsdaten her vergleichbar, sollte sich bei gleicher CRF-Einstellung (konstanter Ratenfaktor) in Deinem Programm die Bitrate nach dem Rendern im gleichen Rahmen bewegen wie beim ersten File - sicher nicht so stark erhöht wie in Deinem Beispiel!

Nee, nicht unbedingt, siehe mein Posting weiter oben.

Standardempfehlung: CRF nicht verwenden, weil man eigentlich in allen praxisnahen Videoanwendungen durchschnittliche Bitraten braucht und keine durchschnittlichen Qualitätsraten mit ggfs. unkalkulierbaren Bitraten.

Eigentlich ist CRF nur etwas für Videoarchivierung, bei der man eine bestimmte Mindestqualität festlegen will, und innerhalb dieser Qualitätsnorm die (hinsichtlich Dateigröße) optimale Bitrate erzielen.

Oder, um es noch mal deutlicher an einem Beispiel auszuführen: Eine CRF-Einstellung wie z.B. 19 sorgt dafür, dass Du auch bei einem Reißschwenk über einen Blätterwald mit Hagelschauer und Filmkorn keine Blockartefakte im mp4-Video kriegst, aber halt um den Preis, dass dann die Bitrate nötigenfalls (und temporär) z.B. auf 240 Mbit/s hochdreht...

[klusterdegenerierung]

Weil's auch nicht stimmt.

Lies doch einfach was ich OBEN geschrieben habe und nicht den Zitatteil von Frank nach dem Komma den ich im Eifer des Gefechts nicht abgetrennt habe, dann hättest Du Dir Deine Schlaumeierei sparen können.

Kannst Du/Ihr einfach mal lesen was ich geschrieben habe????
Ich habe keinerlei Bitrate eingestellt!!! Ich habe nichts verändert!!!! Ich habe lediglich das gleiche Voukoder Profil gewählt wie beim vorherigen Video!!

Da sollte man dann doch wohl erwarten können, das die Quali die gleiche ist, wenn nicht bräuchte es weder das Profil, noch das Tool.
Wenn ich einmal 18Mbit bekomme und beim nächsten quasi identischen Video was nur eindrittel so lang ist eine 5x größere Datei als das vorherige Video was 3x so lang war, ergibt das für nichts einen Sinn und nu ist gut mit Deinen Weißheiten!!

[klusterdegenerierung]

@kluster:
Vielleicht hast Du das Problem schon gelöst, dann ist mein Beitrag überflüssig.
Was in jedem Fall nicht sein sollte: Wenn Dein 2. File nur kürzer ist (1 Minute) und sonst von den Video-- und Kompressionsdaten her vergleichbar, sollte sich bei gleicher CRF-Einstellung (konstanter Ratenfaktor) in Deinem Programm die Bitrate nach dem Rendern im gleichen Rahmen bewegen wie beim ersten File - sicher nicht so stark erhöht wie in Deinem Beispiel!

Nee, nicht unbedingt, siehe mein Posting weiter oben.

Standardempfehlung: CRF nicht verwenden, weil man eigentlich in allen praxisnahen Videoanwendungen durchschnittliche Bitraten braucht und keine durchschnittlichen Qualitätsraten mit ggfs. unkalkulierbaren Bitraten.

Eigentlich ist CRF nur etwas für Videoarchivierung, bei der man eine bestimmte Mindestqualität festlegen will, und innerhalb dieser Qualitätsnorm die (hinsichtlich Dateigröße) optimale Bitrate erzielen.

Oder, um es noch mal deutlicher an einem Beispiel auszuführen: Eine CRF-Einstellung wie z.B. 19 sorgt dafür, dass Du auch bei einem Reißschwenk über einen Blätterwald mit Hagelschauer und Filmkorn keine Blockartefakte im mp4-Video kriegst, aber halt um den Preis, dass dann die Bitrate nötigenfalls (und temporär) z.B. auf 240 Mbit/s hochdreht...

HALLO!!!!
Die Werte habe ich nicht gewählt, nichts habe ich gemacht, nur Voukoder genutzt.

Einer steigt ins Taxi und fährt 30km und muß 50€ bezahlen, das gleiche Taxi fährt einen anderen 10km für 150€!
Gehts noch!!

[Skeptiker]

@kluster:
Vielleicht hast Du das Problem schon gelöst, dann ist mein Beitrag überflüssig.
Was in jedem Fall nicht sein sollte: Wenn Dein 2. File nur kürzer ist (1 Minute) und sonst von den Video-- und Kompressionsdaten her vergleichbar, sollte sich bei gleicher CRF-Einstellung (konstanter Ratenfaktor) in Deinem Programm die Bitrate nach dem Rendern im gleichen Rahmen bewegen wie beim ersten File - sicher nicht so stark erhöht wie in Deinem Beispiel!

Nee, nicht unbedingt, siehe mein Posting weiter oben.

kluster schreibt ja von einem Faktor >10 (18.5 Mbit/s versus 250 Mbit/s), was die Bitrate der beiden Videos betrifft - bei unveränderten Programm-Vorgaben.
Das scheint mir doch reichlich viel und liesse sich dann gemäss Dir so erklären, dass es sich beim ersten Video um ruhige Szenen mit wenig Details handelt, während das zweite (kürzere) Video aus wilden und/oder detailreichen Actionsequenzen bestehen würde.

@kluster: Du könntest die beiden Videos ja probeweise mit vergleichbaren Vorgaben in HandBrake rendern - dann wird klarer, ob es sich um einen Bug in Voukoder handelt.

[cantsin]

Kannst Du/Ihr einfach mal lesen was ich geschrieben habe????
Ich habe keinerlei Bitrate eingestellt!!! Ich habe nichts verändert!!!! Ich habe lediglich das gleiche Voukoder Profil gewählt wie beim vorherigen Video!!

Ja, Kluster, das ist aber das Problem. Weil Du eben keine Bitrate eingestellt hast, sondern dasselbe Profil wie vorher (mit einer Qualitätsrate), hast Du in der ersten Minute eine viel höhere Bitrate - während bei dem längeren Video sich das ganze auspegelt.

Das ist ungefähr so, als wenn Du beim Auto den mittleren Spritverbrauch misst, und dann feststellst, dass es bei einer einminütigen Fahrt um die Ecke zum Bäcker viermal soviel schluckt wie bei einer längeren Fahrt, obwohl Du in denselben Gängen und mit derselben Geschwindigkeit gefahren bist - einfach weil beim Anfahren mehr Energie benötigt wird, und sich das bei einer Minute dann als höherer Durchschnitt niederschlägt.

Die Abhilfe ist, Vokouder/Deinen Encoder auf eine mittlere Bitrate (statt Qualitätsrate) einzustellen. So, als ob Du Deinem Auto sagst: nie mehr als 7 Liter/100km verbrauchen, egal wie langsam dann die Anfahrt ist.

[MK]

Kannst Du/Ihr einfach mal lesen was ich geschrieben habe????
Ich habe keinerlei Bitrate eingestellt!!! Ich habe nichts verändert!!!! Ich habe lediglich das gleiche Voukoder Profil gewählt wie beim vorherigen Video!!

Da sollte man dann doch wohl erwarten können, das die Quali die gleiche ist, wenn nicht bräuchte es weder das Profil, noch das Tool.
Wenn ich einmal 18Mbit bekomme und beim nächsten quasi identischen Video was nur eindrittel so lang ist eine 5x größere Datei als das vorherige Video was 3x so lang war, ergibt das für nichts einen Sinn und nu ist gut mit Deinen Weißheiten!!

Das sind keine Weisheiten sondern Du liest oder verstehst nicht richtig.

Das wurde hier nun aber auch schon mehrfach lang und breit erklärt warum der CRF (mit Ratenfaktor 17 was KEINE Bitrate ist), welcher in diesem Profil als Strategie hinterlegt ist, gegenüber der Strategie ABR mit Angabe einer durchschnittlichen Bitrate kein konsistentes Ergebnis bringt. Stelle das doch einfach manuell auf ABR um, wähle eine Bitrate und gut ist.

Im übrigen ist es ziemlich daneben wie Du hier Leute angehst die versuchen Dir zu helfen.

[MK]

dann wird klarer, ob es sich um einen Bug in Voukoder handelt.

Es ist zu 100% kein Voukoder Bug sondern ein klassischer Fall von Anwenderfehler bzw. RTFM.

[Asjaman]

Mein Tipp wäre, die Finger von den erweiterten Optionen zu lassen. Alles abwählen dort, bzw. gar nicht erst anzeigen lassen.
Also: Enkoder, Codec H.264 (NVENC, falls vorhanden)
dann im Reiter "Optionen" in der Zeile "Strategie" Konstante Bitrate (CBR) wählen und darunter bei Bitrate deine gewünschten 18500 einstellen, dasselbe bei Puffergröße

Dann macht Voukoder, was du erwartest.

[MK]

Mein Tipp wäre, die Finger von den erweiterten Optionen zu lassen. Alles abwählen dort, bzw. gar nicht erst anzeigen lassen.
Also: Enkoder, Codec H.264 (NVENC, falls vorhanden)
dann im Reiter "Optionen" in der Zeile "Strategie" Konstante Bitrate (CBR) wählen und darunter bei Bitrate deine gewünschten 18500 einstellen, dasselbe bei Puffergröße

Dann macht Voukoder, was du erwartest.

Wurde schon mehrfach geschrieben aber nicht verstanden dass die Voukoder Presets keine Bitraten-Presets sondern Qualitäts-Presets sind.

CBR gibt es allerdings nur bei Nvidia NVENC und AMD AMF, x264/x265 arbeitet immer mit durchschnittlicher Bitrate (ABR) die man je nach Abspielgerät mit Max. Bitrate nach oben begrenzen muss und bei Berechnung der Bitrate auf eine feste Zielgröße mit mindestens 2-Pass encoden muss.

[Asjaman]

CBR gibt es allerdings nur bei Nvidia NVENC und AMD AMF, (etc.)

Danke für die Klarstellung.

[dienstag_01]

Aber warum sollte man Voukoder für NVENC nutzen, das kann man doch direkt aus Resolve?
Sinn macht der doch nur bei x264 o.ä., also was Resolve nicht von Haus aus mitbringt?

[MK]

Aber warum sollte man Voukoder für NVENC nutzen, das kann man doch direkt aus Resolve?
Sinn macht der doch nur bei x264 o.ä., also was Resolve nicht von Haus aus mitbringt?

Mehr Parameter, alternative Container, Audioformate, Metadaten, etc.

[dienstag_01]

Aber warum sollte man Voukoder für NVENC nutzen, das kann man doch direkt aus Resolve?
Sinn macht der doch nur bei x264 o.ä., also was Resolve nicht von Haus aus mitbringt?

Mehr Parameter, alternative Container, Audioformate, Metadaten, etc.

Ah, ok, so tief bin ich da nie eingestiegen. Mich hat nur x264 interessiert und das erschien mir beschwerlicher (langsamer) als der Weg über DNxHR und dann Hybrid.

[MK]

Ich rendere auch erst ein Masterfile und kodiere davon dann weitere Formate da sonst bei jedem Export die komplette Timeline mitgerendert werden muss.

[cantsin]

Ah, ok, so tief bin ich da nie eingestiegen. Mich hat nur x264 interessiert und das erschien mir beschwerlicher (langsamer) als der Weg über DNxHR und dann Hybrid.

Ist es auch, weil Resolve ja (im Gegensatz z.B. zu Premiere mit Adobe Media Encoder) nur innerhalb seines monolithischen Programms/Prozesses rendern kann und die Anwendung deshalb während des Renderns blockiert ist.

Für die Mitleser: Wenn man über DNxHR geht [zumindest bei Projekten, die keine schweren Effekt- und Filterberechnungen haben], geht das Rendern um ein Vielfaches schneller, und man kann anschließend im Hintergrund Handbrake/Hybrid/Shutter Encoder (die ja alle GUIs für ffmpeg sind) bzw. ffmpeg (das wiederum ein Frontend u.a. für die x264- und x265-Encoder ist) laufen lassen...

Zudem hat man dann noch den angenehmen Nebeneffekt, am Schluss sowohl (a) eine Masterdatei in Postproduction-Qualität (DNxHR oder ggfs. auch ProRes) zu haben, als auch (b) eine (h264/h265-) Datei zum Abspielen sowie Hochladen auf YouTube & Co.

Und für letztere würde ich immer auf eine Bitrate gehen, die sowohl für die Streaming/Social Media-Websites funktioniert, als auch für die gängigen Medienplayer incl. SmartTVs. Bei 1080p/SDR wären das dann h264 mit 18-32 Mbit/s in 8bit 4:2:0 Rec709 + 192 Kbit/s AAC-Audio. Dementsprechend würde ich dann in x264 bzw. seinen diversen Frontends ein 2-Pass-Encoding mit der passenden Zielbitrate machen.

[dienstag_01]

Ah, ok, so tief bin ich da nie eingestiegen. Mich hat nur x264 interessiert und das erschien mir beschwerlicher (langsamer) als der Weg über DNxHR und dann Hybrid.

Ist es auch, weil Resolve ja (im Gegensatz z.B. zu Premiere mit Adobe Media Encoder) nur innerhalb seines monolithischen Programms/Prozesses rendern kann und die Anwendung deshalb während des Renderns blockiert ist.

Für die Mitleser: Wenn man über DNxHR geht [zumindest bei Projekten, die keine schweren Effekt- und Filterberechnungen haben], geht das Rendern um ein Vielfaches schneller, und man kann anschließend im Hintergrund Handbrake/Hybrid/Shutter Encoder (die ja alle GUIs für ffmpeg sind) bzw. ffmpeg (das wiederum ein Frontend u.a. für die x264- und x265-Encoder ist) laufen lassen...

Zudem hat man dann noch den angenehmen Nebeneffekt, am Schluss sowohl (a) eine Masterdatei in Postproduction-Qualität (DNxHR oder ggfs. auch ProRes) zu haben, als auch (b) eine (h264/h265-) Datei zum Abspielen sowie Hochladen auf YouTube & Co.

Und für letztere würde ich immer auf eine Bitrate gehen, die sowohl für die Streaming/Social Media-Websites funktioniert, als auch für die gängigen Medienplayer incl. SmartTVs. Bei 1080p/SDR wären das dann h264 mit 18-32 Mbit/s in 8bit 4:2:0 Rec709 + 192 Kbit/s AAC-Audio. Dementsprechend würde ich dann in x264 bzw. seinen diversen Frontends ein 2-Pass-Encoding mit der passenden Zielbitrate machen.

18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

[cantsin]

18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

Naja, eigentlich nur der alte BluRay-HD-Standard... Wobei der noch bis zu 40 Mbit/s erlaubt. Was auch bedeutet, dass man bei 2-Pass 32Mbit/s-Encoding bei den üblichen temporären Abweichungen nach oben und unten (bzw. bei den Bitrate-Spitzen) noch auf der sicheren Seite ist, was Kompatiblität zu den meisten Hardware-Medienspielern (inkl. SmartTVs) betrifft, weil die i.d.R. ähnliche/dieselben Decoderchips haben wie BluRay-Player.

Außerdem ist man bei solchen Bitraten auf der sicheren Seite, was die Qualität bei YouTube, Vimeo & Co. angeht. Je besser die Qualität des Masters, desto geringer das Risiko, im nochmal Qualitäts- bzw. Bitrate-reduzierten Streaming-Codec deutlich sichtbare Kompressionsartefakte zu kriegen. [Deswegen schwören manche Leute ja sogar drauf, HD-Material auf UHD aufzublasen und als Fake-UHD auf YouTube & Co. hochzuladen, weil dann die Ausgangs-Bitraten noch höher sein dürfen.]

[dienstag_01]

18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

Naja, eigentlich nur der alte BluRay-HD-Standard... Wobei der noch bis zu 40 Mbit/s erlaubt. Was auch bedeutet, dass man bei 2-Pass 32Mbit/s-Encoding bei den üblichen temporären Abweichungen nach oben und unten (bzw. bei den Bitrate-Spitzen) noch auf der sicheren Seite ist, was Kompatiblität zu den meisten Hardware-Medienspielern (inkl. SmartTVs) betrifft, weil die i.d.R. ähnliche/dieselben Decoderchips haben wie BluRay-Player.

Außerdem ist man bei solchen Bitraten auf der sicheren Seite, was die Qualität bei YouTube, Vimeo & Co. angeht. Je besser die Qualität des Masters, desto geringer das Risiko, im nochmal Qualitäts- bzw. Bitrate-reduzierten Streaming-Codec deutlich sichtbare Kompressionsartefakte zu kriegen. [Deswegen schwören manche Leute ja sogar drauf, HD-Material auf UHD aufzublasen und als Fake-UHD auf YouTube & Co. hochzuladen, weil dann die Ausgangs-Bitraten noch höher sein dürfen.]

Ja, so ähnlich hab ich auch mal gedacht. Bis zu x264 ;)

[cantsin]

18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

Ja, so ähnlich hab ich auch mal gedacht. Bis zu x264 ;)

8000k gehen natürlich, wenn Du relativ glattes Ausgangsmaterial hast - entrauscht, ohne viel Bewegung und mit nur soviel Details/Texturen im Bild, wie sie z.B. für Innenräume typisch sind.

Ich habe gerade mal spaßeshalber einen Praxistest mit eigenem Material gemacht, das ganz gut die Grenzen von 8000 KBit/s-x264 aufzeigt. Ausgangspunkt war Raw aufgenommenes Material, das in Resolve geschnitten/bearbeitet und nach DNxHR rausgerendert war.

Encodierung nach h264 (mit dem x264-Encoder) einmal nach 8000k 2-pass und einmal nach 32000k 2-pass, mit der folgenden ffmpeg-Kommandozeile:

Code: Alles auswählen

ffmpeg -i input.mxf -c:v libx264 -tune grain -preset veryslow -profile:v high -level 5.2 -pix_fmt yuv420p -b 8000k -pass 1 -y output-8000.mp4
ffmpeg -i input.mxf -c:v libx264 -tune grain -preset veryslow -profile:v high -level 5.2 -pix_fmt yuv420p -b 8000k -pass 2  -y output-8000.mp4

...und das ganze nochmal entsprechend abgewandelt (mit "-b 32000k") für das 32MBit/s-Encoding.

Hier Screengrabs mit den jeweiligen Ergebnissen, einmal mit dem Motiv ohne Bewegung im Bild und einmal mit Bewegung:

002-32000.png

statisches Motiv, x264 32 MBit/s

002-8000.png

statisches Motiv, x264 8 Mbit/s

002-32000-crop.png

1:1-Ausschnitt, x264 32 MBit/s

002-8000-crop.png

1:1-Ausschnitt, x264 8 MBit/s

033-32000.png

Bewegtes Motiv, x264 32 MBit/s

033-8000.png

Bewegtes Motiv, x264 8 MBit/s

033-32000-crop.png

1:1-Ausschnitt, x264 32 MBit/s

033-8000-crop.png

1:1-Ausschnitt, x264 8 MBit/s