Video-Encoding mit der Grafikkarte ist im GPGPU-Kontext eine Art Killer-App. Mit Quick Sync mischt nun aber auch Intel mit. Doch wie schlagen sich APP, CUDA und Quick Sync eigentlich bei Qualität und Geschwindigkeit? Einfache Frage, komplexe Antwort…
Vor nicht allzu langer Zeit schauten wir uns zwei Mini-ITX-Mainboards auf Brazos-Basis an (Mini-Fusion mit ASRock und MSI: AMDs Brazos ist da). Wer diesen Artikel schon gelesen hat, wird sich erinnern, dass wir bei den Encoding- und Decoding-Fähigkeiten der Plattform zu einigen überraschenden Ergebnissen gelangten. Wenn wir Videos komprimierten, war das Ergebnis was die Bildqualität anbelangte bei AMD und Intel sehr ähnlich. Wurde aber Nvidias CUDA eingesetzt, um das Konvertieren des Videos zu beschleunigen, sah das ganz anders aus – und zwar im wahrsten Sinne. Dann kam es in den Videos bei Szenen mit viel Bewegung zu deutlicher Klötzchenbildung. Darüber hatten wir zwar schon im Vorfeld einiges gehört, doch erst nach einigen Direktvergleichen, in denen wir den gleichen Frame verschiedener Kodierdurchläufe nebeneinander sehen konnte, wurde uns klar, wie gravierend der Unterschied hier tatsächlich war.
Das brachte uns auf die Idee, in einem eigenen Artikel die Bildqualität verschiedener Lösungen zu überprüfen. Immerhin blieben nach dem Brazos-Test genug Fragen offen, die dort nicht unbedingt relevant waren, denen wir aber dennoch auf den Grund gehen wollen.
Die Basics: Codecs und Decoder
Bevor wie aber ins Detail gehen, sollten wir erst einmal mit ein paar Grundlagen beginnen. Zunächst ist es sehr wichtig, zwischen einem Codec und einer Containerdatei zu unterscheiden. Beispielsweise nutzen Blu-ray-Inhalte oft die Dateiendung .m2ts. Das BDAV-Format (Blu-ray Disc Audio/Video) ist aber eigentlich nichts weiter als ein Container. Das enthaltene Video kann aber einen von drei Codecs nutzen, nämlich MPEG-2, H.264 oder VC-1.
Was genau ist nun also der Unterschied zwischen einem Codec und einem Container? Nehmen wir uns mal ein Beispiel, mit dem jeder etwas anfangen kann: Urlaubsgepäck. Der Koffer ist der Container, und die Art von Koffer, die man sich aussucht, gibt auch vor, was (und wie viel) man mitnehmen bzw. hineinstecken kann. Der Codec (zusammengesetzt aus Compression und Decompression) ist die Methode, mit der man seine Siebensachen (bzw. die Daten) in den Koffer packt. Das gilt im Prinzip für jegliche Art von Multimedia-Inhalten. Microsofts AVI-Format (Audio Video Interleave) ist beispielsweise ein Container, der diverse Codecs enthalten kann, von DivX bis MPEG-2.

Wenn man nun eine Datei in einem Video-Wiedergabeprogramm abspielt, durchlaufen die komprimierten Daten einen Decoder und werden als YUV-Daten auf dem Bildschirm ausgegeben. Der Decoder erkennt das Format und entpackt die Daten in nutzbare Informationen, die dann bearbeitet und als Video betrachtet werden können
Es gibt zwei Arten von Decodern: Software und Hardware. Vor UVD, PureVideo und Intels GMA 4500MHD wurde Video grundsätzlich von Software-Decodern dekodiert, die über die CPU liefen und dementsprechend mehr oder weniger Last erzeugten. CyberLink und InterVideo (heute: Corel) waren damals die beiden größten Firmen, die entsprechende Software anboten. Das erklärt auch, warum ATI den PowerDVD-Decoder lizenziert hat, um ihn im eigenen ATI DVD Decoder zu verwenden. Wie gesagt laufen Software-Decoder über die CPU und verursachen je nach Komplexität des Codecs und der Videogröße eine gewisse Last. Bei modernen CPUs fällt das nicht mehr wirklich ins Gewicht, macht sich aber speziell bei Mobilgeräten bei der Akkulaufzeit negativ bemerkbar.
Nach und nach erkannten Grafikchiphersteller diese Problematik und bauten in ihre GPUs dedizierte Decoder-Blöcke ein, die sich nur um Video kümmerten. So entwickelte sich das, was wir heute Hardwarebeschleunigung für Video nennen. Der Vorteil dieses Ansatzes ist, dass die GPU die Arbeit übernahm, wodurch die CPU-Last reduziert wurde und inzwischen praktisch bei 0% liegt.
Das hat aber auch einige andere Auswirkungen. Weil Videodaten immer von einem Decoder verarbeitet werden, ist es schwieriger, einen Referenzpunkt für Qualität und Effizienz festzulegen. Egal ob das Video einen Software- oder Hardware-Decoder durchläuft, der Datenstrom wird in jedem Fall manipuliert, bevor er als Bilderfolge auf dem Bildschirm ankommt. Benutzt man einen Software-Decoder, muss man keinen systemübergreifenden Vergleich durchführen, sofern man auf allen denselben Decoder einsetzt. Umgekehrt können aber verschiedene Decoder auf demselben System leicht abweichende Bilder liefern und so die wahrgenommene Bildqualität beeinflussen. Spielt man auf einem Rechner mit AMD- oder Nvidia-Grafik eine Blu-ray-Disc mit PowerDVD ab, wird das Ergebnis identisch aussehen, solange man die Hardwarebeschleunigung nicht aktiviert. In beiden Fällen wird der Videostrom dann nämlich per Software auf der CPU dekodiert, was das gleiche Ergebnis liefert.
Bringt man einen Hardware-Decoder ins Spiel, kann das Ergebnis wie gesagt ganz anders aussehen? Wie kommt das? Moderne GPUs bringen von Hause aus Funktionseinheiten mit, die sich ausschließlich um das Dekodieren und Bearbeiten von Videoströmen kümmern. Allerdings wird die hardwarebeschleunigte Dekodierung in der GPU eines Sandy-Bridge-Prozessors anders gestaltet und programmiert sein als bei GPUs auf Grafikkarten von AMD oder Nvidia.
Eins möchten wir von vornherein klarstellen: Es gibt keine Decoder, die als reine GPGPU-Lösungen arbeiten. Kein Decoder läuft komplett in DirectCompute, APP oder CUDA. Es ist auch nicht sinnvoll, sich einen solchen Decoder zu wünschen, weil man dadurch nichts gewinnt. GPGPU bringt immer dann Vorteile, wenn stark parallelisierbare Rohdaten bearbeitet werden sollen. Videos bestehen aber nun mal aus mehr als rohen Daten. Es findet auch eine Menge Bildbearbeitung statt, und die muss größtenteils nacheinander geschehen und ist damit seriell, nicht parallel. Die oben beschriebenen dedizierte Funktionseinheiten sind Fachidioten: Sie sind darauf spezialisiert, Video zu dekodieren und zu bearbeiten. Das und genau das können sie hervorragend; zu etwas anderem sind sie aber nicht zu gebrauchen. Die Arbeit auf weniger spezialisierte Hardware wie die Recheneinheiten der GPU zu verlagern ist nicht viel anders, als würde man diese Arbeit gleich wieder der CPU überlassen. In beiden Fällen müsste man einen Software-Decoder einsetzen.
Interessanterweise hat die Firma Elemental Technologies, die vor allem durch ihre Transcoder-Software Badaboom bekannt geworden ist, einen MPEG-2-Decoder auf CUDA-Basis entwickelt. Allerdings handelt es sich auch hier um keinen reinen GPGPU-Decoder. Teile der Video-Pipeline, beispielsweise Entropy Encoding, Syntax Encoding, Syntax Decoding und Entropy Decoding müssen seriell abgearbeitet werden. Andere Teile des Arbeitsablaufes lassen sich hingegen sehr gut parallelisieren. Dazu gehören Motion Estimation, Motion Compensation, Quantisierung, Discrete Cosine Transform, Deblocking Filtering und End Loop Deblocking. Deshalb ist Elementals MPEG-2-Dekoder auch eine Zwitterlösung. Einige Teile laufen auf der CPU, andere auf den CUDA-Cores der GPU.
- Bildqualität unter der Lupe
- Intel, AMD, Nvidia: Decoding und Encoding in Hardware
- Qualitätsprobleme bei CUDA-Transcoding? Ein kurzer Rückblick
- Test-Hardware und Benchmarks
- Hardware-Decoder: Qualität im Visier
- Software Decoding: Wenn die CPU ran muss
- Wir dampfen eine Blu-ray-Disc ein: APP vs. CUDA vs. Quick Sync
- Ein kleines Video komprimieren: APP vs. CUDA vs. Quick Sync
- Transcoding-Qualität: APP vs. CUDA vs. Quick Sync
- Transcoding-Qualität: Ergebnisse nach Anwendung
- Teufels Advokat - Gibt es einen "Besten"?
- Ein Blick in die Black Box: GPGPU-Encoding
- Fazit
Die Berechnung über die Grafikkarte wurde einem immer wieder schöngeredet. Diese Erfahrung hab ich auch schon beim Encodieren machen müssen. ATI-Stream (früher Avivo) war zwar extrem schnell...die qualität aber unterirdisch schlecht. Über Cuda hatte ich noch nicht die Möglichkeit. Aber im Moment ist es mir lieber, das Ergebnis stimmt, als jedem zu h ging, diese beschissene Qualität hinzubekommen.^^ Da müßte evtl die zugehörige Software optimiert werden....keine Ahnung.
Und dann wird noch für Krüppel-Hardware ala IPad konvertiert... Also wer auf dem Ding bei einem FullHD-BR-Rip noch Details erkennt, hat schon besonders gute Augen.
Dennoch ergeben sich auch bei diesen Bitraten Unterschiede, die sich ganz typisch immer einer der Hardware-Lösungen zuordnen lassen.
Darum ging es uns primär in diesem Artikel: Wo sind bei möglichst gleichen Voraussetzungen die Unterschiede zwischen den Hard- und Software-Lösungen.
Es ging auch nicht darum, einen der Hersteller dumm aussehen zu lassen (und die Ergebnisse sagen das ja auch nicht aus).
Es ist aber auch so, dass die Qualität zwischen CPU und GPGPU/QuickSync durchaus unterschiedlich ausfällt. Das wollten wir aufzeigen.
Btw, die aktuelle Badaboom-Version (als Final) ist noch mal ein Stück besser geworden.
Zumindest an diesem Punkt muss ich jetzt aber aus meiner eigenen Erfahrung widersprechen.
Zwei Gründe: Warum sollte man bei gleicher Bitrate neu kodieren? Geht es nicht darum, eine kleinere Datei zu erhalten? Das ist zumindest die Ausgangsidee dieses Tests. Es kann natürlich gut sein, dass das bei deinem Fall nicht so ist und du einfach ein anderes Format möchtest. Aber dann Frage ich mich, warum du überhaupt einen Qualitätsverlust durch Wandlung hinnehmen möchtest, denn nichts anderes passiert ja beim neu Kodieren.
Zweitens: Dass Badaboom auf dieselbe Qualität wie ein Software-Encoder kommt, konnte ich leider noch nie nachvollziehen. Natürlich sind die Ergebnisse bei höheren Bitraten besser als bei niedrigen. Aber es ist (am Beispiel iPad) sinnlos, eine große Datei mit hoher Bitrate zu erstellen, denn es geht ja um ein Mobilgerät.
Kommt eben immer auf das Einsatzgebiet und das Abspielgerät an.
Bei Mobilgeräten orientiere ich mich am Display und den unterstützten Formaten und versuche dann bei der neu Enkodierung so nah wie möglich am verwendeten Display zu bleiben, oder darunter. Mehr Auflösung im Video bringt ja nix, wird ja so oder so wieder an das verwendet Display skaliert. Das IPad hat nach Apples technischen Informationen ein Display mit einer Auflösung von 1024x768. Somit würde ich eine Auflösung wählen die so nah als möglich am Display liegt und keine die drüber ist, eher darunter. Ausserdem ist es ja klar, wenn man HD Material mit 720p oder 1080p für ein Mobilgerät verwendet das das verwendete Material kein Bitrate freundliches Material ist, allein schon durch die hohe Auflösung von HD Material. Ausserdem ist die Videohardware bei vielen Mobilgeräten auch nicht grad das gelbe vom Ei, da ich weder IPad noch ein anderes Apple Produkt besitze kann ich zu der Funktionalität der eingebauten Hardware nix sagen.
Ich will und wollte keinesfalls deine Kompetenz in Frage stellen. Mir ging es darum das man ein vernünftigen Vergleich zwischen den Hardwareencodern anstellt, mit vernünftigen Parametern. Ich hab mir das komplette von euch ins Netz gestellte Material im Original und die erstellten Kopien angeschaut und analysiert und hab dabei einfach für mich festgestellt das man mit den verwendeten Bitrates kein vernünftiges Ergebnis erreichen kann. Somit auch nicht aussagen kann welcher besser, schlechter, oder sonst was ist. Einfach die Vorgaben eines Herstellers zum Testen zu verwenden ergibt für mich keinen Sinn.
Damit war nicht gemeint das die Ausgangsbitrate der Eingangsbitrate entspricht, sondern das man die Bitrate nur soweit absenkt das sie die Qualität der Ausgabe nicht völlig ruiniert. Für mich heißt das zum Beispiel das ich für mein SD Material die Bitrate auf 2000 kbps im Durchschnitt und 4000 kbps als Maximum einstelle bei 720p sinds dann 3500 kbps im Durschnitt und 7000 kbps im Maximum. Sorry wenn ich das leicht missverständlich formuliert hab.
Ich hatte deine Bitraten-Aussage tatsächlich falsch verstanden.
Nebenbei - als wir den Test ausgebrütet haben, hatte ich mir eigentlich etwas anderes darunter vorgestellt. Das wäre auch dem näher gekommen, was du meinst.
Gut möglich, dass wir noch mal ein Follow-Up machen.