Warum ist der Prozessor “ besser ” für die Codierung als die GPU?

Der Artikel, den Sie verlinkt haben, ist nicht sehr gut.

Normalerweise konvertieren Single-Pass-Bitratencodierungen Ihre Bitrate in einen RF-Wert mit a Maximales Bitratenlimit und nimmt es von dort.

x264 „ABR-Ratensteuerung mit einem Durchgang ist nicht als CRF + -Limit implementiert. Er hat Recht, dass 2 Pass ist jedoch bei weitem der beste Weg, um eine Zielbitrate zu erreichen.

Und er weiß anscheinend nicht, dass er x264 mit Threads = 3 oder so etwas starten könnte Lassen Sie etwas CPU-Zeit für andere Aufgaben frei. Oder setzen Sie die Priorität von x264 auf „sehr niedrig“, damit nur die CPU-Zeit erhalten wird, die keine andere Aufgabe benötigt.

Er verwechselt auch Threads = 1 mit der Verwendung von CUDA oder so etwas. Kein Wunder, dass Sie Fragen haben, weil das so ist Der Artikel hat eine SCHRECKLICHE Erklärung. Der gesamte Artikel besteht im Wesentlichen aus: Verwenden Sie x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv oder verwenden Sie eine Lichtfilterung mit einem AviSynth-Eingabeskript. Er empfiehlt tatsächlich Placebo „. Das ist lustig. Ich habe noch nie eine mit Placebo codierte Raubkopiendatei gesehen (Sie können dies anhand von me=esa oder me=tesa anstelle von für alle Voreinstellungen von guter Qualität bis zu veryslow.

Er erwähnt auch nicht die Verwendung von 10-Bit-Farbtiefe codieren und decodieren, aber selbst nach dem Zurückkonvertieren zurück auf 8 Bit erhalten Sie ein besseres 8-Bit-SSIM. Eine höhere Präzision für Bewegungsvektoren hilft anscheinend. Außerdem hilft es, nicht auf genau einen ganzen 8-Bit-Wert abrunden zu müssen. Sie können sich 8 vorstellen -bit pro Komponente als Speed-Hack; Quantisierung im Frequenzbereich und anschließende Komprimierung mit CABAC bedeutet, dass Koeffizienten mit höherer Bittiefe nicht mehr Platz benötigen.

(BTW, h. 265 profitiert weniger von 10-Bit-Codierungen für 8-Bit-Videos, da Bewegungsvektoren bereits präziser sind. Wenn die Verwendung von 10-Bit-x265 für 8-Bit-Videoeingänge von Vorteil ist, ist sie kleiner als bei x264. Es ist also weniger wahrscheinlich, dass die Geschwindigkeitsstrafe abfällt Ich bin es wert.)

Um Ihre eigentliche Frage zu beantworten:

edit: doom9 ist jetzt wieder aktiv, also räume ich den Link auf. Gehen Sie dazu, um genau zu zitieren, wer was gesagt hat.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google speichert nur die blöde Druckversion zwischen, die das Zitat nicht richtig anzeigt. Ich bin nicht ganz sicher, welche Teile dieser Nachrichten Anführungszeichen sind und welche der Person selbst zugeordnet werden.

Sehr unregelmäßige Verzweigungsmuster (Sprungmodi) und Bitmanipulation (Quantisierung / Entropiecodierung) passen nicht zu aktuellen GPUs. IMO die einzige Eine wirklich gute Anwendung im Moment sind ME-Algorithmen für die vollständige Suche, obwohl die beschleunigte vollständige Suche immer noch langsam ist, selbst wenn sie schneller als auf der CPU ist.
– MfA

Eigentlich kann auf der GPU im Grunde alles vernünftigerweise erledigt werden, außer CABAC (was getan werden könnte, es könnte einfach nicht parallelisiert werden).

x264 CUDA implementiert ein Fullpel und ME-Algorithmus zunächst subpelieren, später könnten wir so etwas wie RDO mit einem Bit-Kosten-Ansatz machen Ximation anstelle von CABAC.

Weil alles mit Gleitkomma mit einfacher Genauigkeit ausgeführt werden muss
– MfA

Falsch, CUDA unterstützt Ganzzahlmathematik.

– Dark Shikari

Dark Shikari ist der x264-Betreuer und Entwickler der meisten Funktionen seit 2007 oder so.

AFAIK, dieses CUDA-Projekt ist nicht erfolgreich. Es gibt Unterstützung für die Verwendung von OpenCL, um einige Arbeiten aus dem Lookahead-Thread zu entfernen (schnelle I / P / B-Entscheidung, keine qualitativ hochwertige endgültige Codierung des Frames).

Nach meinem Verständnis ist der Suchraum für die Videokodierung so groß, dass intelligente Heuristiken für die vorzeitige Beendigung von Suchpfaden auf CPUs die Brute-Force-GPUs übertreffen zumindest für eine qualitativ hochwertige Codierung auf den Tisch bringen. Es ist nur im Vergleich zu -preset ultrafast, wo Sie vernünftigerweise die HW-Codierung gegenüber x264 wählen können, insbesondere wenn Sie eine langsame CPU haben (wie ein Laptop mit Dual Core und ohne Hyperthreading) CPU (i7 Quad Core mit Hyperthreading), x264 superfast wird wahrscheinlich genauso schnell sein und besser aussehen (bei gleicher Bitrate).

Wenn Sie „eine Codierung erstellen, bei der Ratenverzerrung (Qualität pro Dateigröße) überhaupt eine Rolle spielt, sollten Sie x264 -preset medium oder langsamer verwenden. Wenn Sie etwas archivieren und jetzt etwas mehr CPU-Zeit aufwenden, sparen Sie Bytes, solange Sie „diese Datei behalten.

Randnotiz: Wenn Sie jemals Nachrichten von Toten in einem Videoforum sehen, ist dies der Fall.“ Es wird nicht hilfreich sein. Er hat sich in den meisten Dingen geirrt, über die er in jedem Thread gesprochen hat, den ich je gesehen habe. Seine Beiträge sind in ein paar Threads aufgetaucht, die ich über die x264-GPU-Codierung gegoogelt habe. Anscheinend versteht er nicht, warum es nicht einfach ist. und hat mehrmals gepostet, um den x264-Entwicklern mitzuteilen, warum sie „dumm sind …

Update 2017:

ffmpeg unterstützt die GPU-beschleunigte Videokodierung von h264 und h265 NVENC GPU . Sie können 1-Pass- oder 2-Pass-Codierung in der von Ihnen gewählten Qualität durchführen, entweder für hevc_nvenc oder h264_nvenc, und sogar mit einer GPU der Einstiegsklasse ist sie viel schneller als nicht beschleunigte Codierung und beschleunigte Intel Quick Sync-Codierung.

2-Pass-Codierung in hoher Qualität:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 

1-Pass-Standardcodierung:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 

NVENC ffmpeg-Hilfe und -Optionen:

ffmpeg -h encoder=nvenc 

Verwenden Sie es, es ist viel schneller als die CPU-Codierung.

Wenn Sie keine GPU haben, können Sie den Intel Quick Sync-Codec h264_qsv, hevc_qsv oder mpeg2_qsv verwenden, die ebenfalls viel schneller sind als die nicht beschleunigte Codierung.

Kommentare

• Verwenden Sie es , wenn Sie die Geschwindigkeit (und die geringe CPU-Auslastung) über die Qualität pro Dateigröße legen. In einigen Anwendungsfällen, z „2e2d55c5c8“>

Um etwas näher auf das einzugehen, was Peter sagt, hilft im Allgemeinen die Verwendung mehrerer Prozessoren in Fällen, in denen Sie mehrere unabhängige Aufgaben haben, die alle müssen durchgeführt werden, haben aber keine Abhängigkeiten voneinander oder eine Aufgabe, bei der Sie dieselbe Berechnung für große Datenmengen durchführen.

Wenn Sie jedoch die Ausgabe von Berechnung A benötigen Als Eingabe von Berechnung B und Ausgabe von Berechnung B als Eingabe für Berechnung C können Sie sie nicht beschleunigen, indem Sie für jede Aufgabe (A, B oder C) eine andere Kernarbeit ausführen, da dies nicht möglich ist Beginnen Sie, bis die anderen beendet sind.

Selbst in dem oben genannten Fall können Sie jedoch möglicherweise t o es anders zu parallelisieren. Wenn Sie Ihre Eingabedaten in Blöcke aufteilen können, haben Sie möglicherweise einen Kern, der A, dann B, dann C mit einem Datenblock ausführt, während ein anderer Kern A, dann B und dann C in einem anderen Datenblock ausführt

Es gibt auch andere Überlegungen. Vielleicht könnten Sie einen Weg finden, die Berechnungen zu parallelisieren, aber das Lesen der Daten von der Festplatte oder über das Netzwerk oder das Senden an die GPU dauert länger als das Durchführen der Berechnungen. In diesem Fall ist eine Parallelisierung nicht sinnvoll, da das Abrufen der Daten in den Speicher länger dauert als die Zeit, die Sie durch parallele Berechnung sparen.

Mit anderen Worten, es ist Sowohl eine Kunst als auch eine Wissenschaft.

Kommentare

• Oh ja, x264 lässt sich auf Multicore-CPUs recht gut parallelisieren. Ich skaliere fast linear bis zu mindestens 8 Kernen und anständig sogar über 32. Die Bewegungsschätzung kann parallel durchgeführt werden, wobei nur die notwendigerweise serielle Arbeit für einen anderen Thread und ähnliche Tricks übrig bleiben.
• Die Frage ist nicht ‚ t Parallelität im Allgemeinen, ‚ GPUs im Besonderen. Sie ‚ sind in dem Code, den Sie zum Ausführen bringen können, viel restriktiver als CPUs. Ich denke, es ist ‚ s, weil Sie ‚ keinen Code mit Zweigen haben können, die auf verschiedenen Blöcken des Bildes unterschiedliche Wege gehen. Ich verstehe ‚ nicht genau warum, aber ich denke, dass ‚ so etwas ist. Jeder Stream-Prozessor ist so einfach und mit so begrenzten Mitteln, dass er unabhängig von den anderen ausgeführt wird, dass Sie entweder immer auf den langsamsten warten müssen, bis er fertig ist, oder dass Sie nur begrenzt verzweigt sind oder beides.
• Wenn Sie einen Computercluster hatten (CPUs mit unabhängigem RAM, die ‚ nicht miteinander um Speicherbandbreite und CPU-Cache konkurrierten), haben Sie ‚ d brechen Sie Ihr Eingangsvideo in GOPs auf und senden Sie Abschnitte des noch komprimierten Eingangsvideos, die auf anderen Computern im Cluster dekodiert und komprimiert werden sollen.Es müsste also nur komprimiertes Eingangs- oder Ausgangsvideo übertragen werden. Bei einem Multicore-Shared-Cache / RAM-System wie einer Multisocket-x86-Workstation arbeiten mehrere Threads gleichzeitig mit denselben Frames. (bedeutet auch, dass Sie ‚ keinen neuen Code benötigen, um die globale Ratensteuerung für die Segmentierung von Codierungen durchzuführen.)