Video-Transcoding unter der Lupe: APP, CUDA und Quick Sync im Vergleich

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.

Erstelle einen neuen Thread im Artikel-Forum über dieses Thema
Dieser Thread ist für Kommentare geschlossen
12 Kommentare
    Dein Kommentar
  • ypnaphelios@guest
    Super Artikel, aber bitte nochmal korrekturlesen :-)
    0
  • dAShEIKO@guest
    Das Thema Video En-/Decodieren und Codecs ist mehrere Abende füllend und extrem trocken. Hab grade beim durchlesen auch einige Male auf durchzug geschaltet ;)
    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.
    0
  • aconst
    Ich habe vor einigen Wochen eine ähnliche Frage im Forum gestellt: Am Ende waren wir alle (fast) einig: CUTA/Stream sind schnell aber nicht gut genug.
    0
  • jo-82
    Leider läßt ihr die Referenz, x264, völlig links liegen.
    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.
    0
  • HeinoPeterle@guest
    Mich hätte wirklich interessiert, warum Hardware-Enconding schlechtere Qualität liefert. Steht das auch irgendwo im Artikel?
    0
  • Bulletdemon360
    So leid er mir tut aber ich verwende Cuda mit Badaboom und TMPGEnc Video Mastering Works 5 in Kombination mit dem 460 GTX Grafikchip von NVidia und bin sehr zufrieden damit. Ich verwende es primär für die Konvertierung von SD und 720p Bildmaterial. Nachdem ich euren Test durchgelesen habe, habe ich mich mehr als gewundert. Nach Download eures erzeugten Materials und einer Analyse fällt mir eins auf, ihr nützt nicht im Ansatz VBR für das Bildmaterial , zusätzlich sind die von euch verwendeten Bitrats einfach zu niedrig um vernünftiges Material zu erzeugen! Eine mittlere Bitrate von 3038 kbps und einem Maxima von 3060 kbps am Beispiel von der Cuda enkodierten Datei deathrace_h1080p-iPad ist ein Witz das entspricht einer konstaten Bitrate. Ich verwende schon für 720p Material eine durchschnittliche Bitrate von 3500 kbps mit einem maxima von 7000 kbps, für SD 2000 kbps mit einem Maxima von 4000 kbps. Da kann der Encoder dann bei Actionszenen mehr kbps pro Sekunde nutzen, eure Einstellung verhindern dies effektiv. Wenn man sich dann die Originaldatei anschaut mit einem Maxima von über 9000 kbps dann ergibt das einen Sinn. Ausserdem empfiehlt sich für HD Material eine 8x8 Transform Adaptivity zu verwenden die erst ab High Profile @ L4.0 unterstützt wird, welches wiederum von TMPGEnc Video Mastering Works 5 unterstützt wird und eine bessere Komprimierung bietet. Badaboom verwendet dafür im von ihm unterstützten Main Profile eine Matrix von 4x4 welches für SD Material ausreicht aber nicht unbedingt für HD und schon garnicht bei euren niedrigen Bitrates. H.264 ist ein absolut geniales Format da es alle möglichen Geräte abdeckt vom Handy bis zum Bluray Player. Aber man sollte schon mit realen Werten arbeiten und nicht nur mit Traumwerten die man so nicht erzeugen kann. Denn CPU Encoding ist für H.264 ziemlich lahm auch wenn man einen I7 sein eigen nennt, Hardwareencoding ist eine galante Lösung die viele nützen können da sie die benötigte Hardware schon in Ihrem Rechner haben.
    0
  • benkraft
    @Bulletdemon360 - Die Kritik an sich mag zutreffen, gleichzeitig sind das aber die Profile, die von den Anwendungen vorgegeben sind. Diese Qualität bekommt man also, wenn man stumpf sagt "Konvertiere Film X für mich per iPad-Profil".
    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.
    0
  • Bulletdemon360
    Was mich an diesem Artikel primär stört ist die Art des Vergleichs. Ihr vergleicht rein effektiv nicht Hardwareencoder miteinander sondern die Standardeinstellungen von verschiedenen Encoderfrontends. Ein richtiger Vergleich wäre für mich z.B. ein Softwareencoder gegen die Hardwareencoder und das mit vernünftigen Einstellungen, oder Ihr benennt den Artikel um auf "Hardwareencoder Software im Standardeinstellungsvergleich". Ansonsten vergleicht Ihr ja nur die Qualität von Standardeinstellungen der verschiedenen Softwarefrontends für Hardware als Encoder. Auch stört mich die Aussage das Software besser sei als Hardware, diese Aussage kann ich so nicht unterstreichen. Ich encodiere schon seit Jahren angefangen mit MPG und DivX/XVid und heute verwende ich nur noch Hardwareencoding mittels Cuda. Warum? Weil ich mit keiner Software so schnell zu hervorragenden Ausgabeergebnissen komme. Die Hardware verwendet ein Singlepassverfahren und das mit hervorragender Qualität bei bis zu 144 fps bei meiner Hardware und SD Material, 720p mit bis zu 50 fps. Wenn ich vergleichbare Qualität mittels Software erreichen möchte, brauche ich zumindest ein Dualpass wenn nicht sogar ein n-Pass Verfahren (3 oder mehr Durchgänge) und das bei unter 25 fps pro Sekunde Enkoderleistung. Am Beispiel von Badaboom wird bei Hardwareencoding die Qualität immer auf High gestellt und dabei werden die hohen fps Encodingleistung erreicht und das ohne einen Kompromiss bei der Qualität, sofern die verwendeten Bitrates dem Eingangsmaterial entsprechen. Der Artikel sagt eigentlich nichts über die Vor- oder Nachteile von Hardwareencoding aus und stellt auch keinen Vergleich zwischen den verschiedenen zur Verfügung stehenden Systemen dar sondern vergleicht Standardeinstellungen von Softwarefrontends gegeneinander und vermittelt damit einen völlig falschen Eindruck von den Möglichkeiten und der erreichbaren Qualität von Hardwareencodern.
    0
  • benkraft
    47629 said:
    . Am Beispiel von Badaboom wird bei Hardwareencoding die Qualität immer auf High gestellt und dabei werden die hohen fps Encodingleistung erreicht und das ohne einen Kompromiss bei der Qualität, sofern die verwendeten Bitrates dem Eingangsmaterial entsprechen.


    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.
    0
  • Bulletdemon360
    Ich rekonvertiere auch um kleinere Dateien zu erhalten, das ist ja Sinn und Zweck der Übung. Nur sollte man auch bis zu einem bestimmten Grad bei der zu erreichenden Komprimierung realistisch bleiben. Wenn ich z.B. in 720p einen Satelittenstream aufnehme besitzt dieser im Original so um die 12000 kbit/s im Videostream, wenn ich diesen dann rekonvertiere hat er noch 3500 kbit/s im Average, als Maxima 7000 kbit/s. Nur das ich dabei die Bitrate nur soweit reduziere das dabei die Qualität nicht komplett über Bord geworfen wird. Bei SD Material kommt man im Schnitt bei Satellitenstreams auf 8000 kbit/s diese besitzen eine Auflösung von 720x576. Da erreicht man in der Komprimierung mittels H.264 so um die 2000 kbit/s im Average (4000 kbit/s im Maxima) ohne das dabei große Verluste bemerkbar wären. Ich erhalte beidesmal kleinere Dateien ohne dabei die Qualität großartig zu verlieren. Das ist ja die Kunst am komprimieren von Videomaterial.
    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.
    0
  • Bulletdemon360
    ". Am Beispiel von Badaboom wird bei Hardwareencoding die Qualität immer auf High gestellt und dabei werden die hohen fps Encodingleistung erreicht und das ohne einen Kompromiss bei der Qualität, sofern die verwendeten Bitrates dem Eingangsmaterial entsprechen."

    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.
    0
  • benkraft
    @Bulletdemon - Ich fühlte mich auch keineswegs persönlich angegriffen oder in meiner Kompetenz angezweifelt. Das ginge hier auch gar nicht, weil ich hier vornehmlich als Übersetzer aufgetreten bin. :)
    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.
    0