Jup, auch wenns komisch ist.
Recoding profitiert ja sehr von mehr Kernen, aber warum bringt die GPU mit den unmengen von Kernen nichts?
Das hat viele Gründe.
1. (und der Hauptgrund): Die CUDA-Cores oder Stream-Cores der GPU sind weit weit weniger komplex als ein CPU Kern und können nur sehr spezielle Operationen ausführen. Früher wars noch schlimmer bevor es Einheitliche (Unified) Shader usw gab.
Um mit diesen Kernen komplizierte Dinge wie h.264 Berechnungen durchführen zu können muss dieser erst in sehr sehr einfache Berechnungen zerlegt und in für eine GPU verständliche Sprache übersetzt werden - nach der Verarbeitung das ganze wieder rückwärts. Das kostet immens Performance (deswegen sind GPUs bei Weitem nicht um den Faktor schneller beim konvertieren wie sie mehr theoretische Rechenleistung haben).
Bei GPU Konvertierern wird der einfache Weg gegangen, dass viele fortgeschrittene h.264 Funktionen nicht genutzt werden, da die GPU es schlichtweg ohne sehr großen Aufwand nicht kann - die Übersetzung in GPU-Sprache wäre zu aufwendig. unter anderem deshalb sind die GPU encoder so extrem schnell - einfach weil sie sich viel Rechenleistung gegenüber der CPU sparen. Wenn ich diese mit den Einstellungen betreibe dass die Qualität einer GPU-Kodierung gleichkommt ist zumindest bei mir im Selbstversuch eine GTX580 nur noch rund 1,2-1,3x so schnell wie meine CPU - und die Qualität ist für meine persönlichen Begriffe auch inakzeptabel.
2.: Encodieren von Videos ist nur recht begrenzt sinnvoll auf Multicore optimierbar. Je mehr Kerne genutzt werden, desto geringer wird die Bildqualität bei gleichen Einstellungen und Bitrate, da die verschiedenen "Arbeiten" der einzelnen Threads wieder zusammengefügt werden müssen und an den Fügestellen die Kompression ineffizienter ist (grob ausgedrückt). Das macht bei 4 oder 8 oder von mir aus noch 16 Threads wenig aus, bei wesentlich höherer Anzahl geht der Nutzen aber gegen 0 (daher unterstützt auch Professionelle Software meist nicht mehr als 16-Thread Rendering oder nutzt sehr ausgefeilte Algorithmen um das Problem zu unterdrücken bei sehr vielen Kernen).
Solches Multithreading ist nur sinnvoll, wenn der Encoder in sehr hohen Stufen läuft, sprich pro Einzelbild sehr viel Rechenleistung anfällt. Beim h.264 Codec ist es so, dass maximal 16 aufeinanderfolgende Frames gegenseitig Informationen übereinander enthalten können (Reference Frames), in der Praxis liegt der Wert gerade bei "Idiotensicheren" programmen und Defaultwerten deutlich geringer (2 oder 3). Das spart viel Rechenleistung auf kosten der Qualität und senkt das Multicore Potential, da theoretisch von 8 Kernen immer 5 warten müssen bis die anderen 3 fertig sind da ja immer nur 3 Frames miteinander "verbunden" werden. Da muss dann die Arbeit an einem einzigen Frame auf mehrere Kerne verteilt werden was sehr ineffizient sein kann (da genau dort wo kern A im Bild aufhört und kern B anfängt keine Komprimierung erreicht werden kann).
.
