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

Wir dampfen eine Blu-ray-Disc ein: APP vs. CUDA vs. Quick Sync

Wir haben nun also geklärt, dass es zwischen verschiedenen hardwarebeschleunigten Decodern deutliche Unterschiede gibt und dasselbe auch für Software-Decoder gilt. Doch wie sieht es beim Encoding aus? Immerhin ist das der Grund, warum wir uns überhaupt mit der Bildqualität beschäftigen.


AMD Radeon HD 6970
Nvidia GeForce GTX 580
Herstellungsprozess
40 nm TSMC
40 nm TSMC
Die-Größe
389 mm²520 mm²
Transistoren
2,64 Milliarden
3 Milliarden
GPU-Takt880 MHz
772 MHz
Stream Processors / CUDA Cores
1536
512
Theoretische Rechenleistung
2,7 TFLOPS
1,58 TFLOPS
Textureinheiten96
64
Texturfüllrate84,5 Gtex/s
49,4 Gtex/s
ROPs
32
48
Pixelfüllrate28,2 Gpix/s
37,1 Gpix/s
Videospeicher
2 GB GDDR5
1,5 GB GDDR5
Speichertakt
1375 MHz
1002 MHz
Speicherbandbreite176 GB/s (256-bit)
192 GB/s (384-bit)
max. Leistungsaufnahme
250 W
244 W

Für unseren Vergleich setzen wir die besten Single-GPU-Karten im Consumerbereich ein, die man derzeit kaufen kann, nämlich AMDs Radeon HD 6970 und Nvidias GeForce GTX 580.

Full BDAV, 31.2 GB H.264 BDAV
HH:MM:SS
AMD Nvidia Intel Performance Intel Quality
Hardware Decode & Hardware/GPGPU Encode1:24:000:49:340:19:350:23:22
Hardware Decode & Software Encode
0:47:550:49:380:35:210:46:13
Software Decode & GPGPU/Hardware Encode
1:01:170:50:210:48:170:48:41
Software Decode & Encode
1:04:261:04:220:55:381:05:20

Von unseren drei Testprogrammen wollte nur MediaEspresso unseren gesamten 31,2 GB großen Testfilm Iron Man konvertieren, der als ungeschützte Blu-ray vorlag. Sowohl MediaConverter 7 als auch Badaboom meldeten sich mit Audio-Fehlern, da keines der beiden Programme TrueHD erkennt.

Übrigens, wer Quick Sync nutzt, muss bei Media Espresso sich zwischen den Voreinstellungen Performance und Quality entscheiden. Bei AMD- oder Nvidia-Grafikkarten wird diese Option nicht angezeigt.

Wie unsere Benchmarks zeigen, scheint das Dekodieren am meisten Performance zu benötigen. Lesen wir die folgende Tabelle mal von unten nach oben: Aktiviert man für das Konvertieren APP oder CUDA, verkürzt sich die Zeit fürs Umrechnen ein wenig, und CUDA ist hier leicht im Vorteil. Den größten Performance-Schub bekommt man aber, wenn man Hardware-Decoding aktiviert. Das schlechteste Ergebnis bekommt man allerdings, wenn man APP Encoding und UVD 3 auf der Radeon gleichzeitig aktiviert. Jede andere Kombination von Einstellungen ist schneller, und dazu zählt sogar die Möglichkeit, alles in Software durchzuführen. Mit CUDA verbessert sich das Ergebnis gegenüber dem reinen Dekodieren in Video nur um magere 4 Prozent, wenn alles in Hardware ausgeführt wird.

Deutlich beeindruckender sind die Werte, die Intels Quick Sync vorweisen kann. Allerdings skaliert diese Lösung deutlich weniger aggressiv, wenn man die Voreinstellung „Quality“ wählt. Das kommt daher, dass beim Software-Encoding eine geringere Bitrate zum Einsatz kommt.

665 MB H.264 BDAV/M2TS Transcode, MM:SS
AMD Radeon HD 6970
Transcode-Anwendung
MediaEspresso
MediaConverter
Hardware Decode & APP Encode
2:29
1:40
Hardware Decode & Software Encode
2:28
-
Software Decode & APP Encode
1:57
-
Software Decode & Encode
2:41
1:22
Nvidia GeForce GTX 580
Transcode-AnwendungMediaEspressoMediaConverter
Hardware Decode & CUDA Encode1:37
1:06
Hardware Decode & Software Encode1:50
-
Software Decode & CUDA Encode2:02
-
Software Decode & Encode2:41
1:22
Intel HD Graphics 3000 (Core i5-2500K)
Transcode-AnwendungMediaEspresso Performance
MediaEspresso Quality
MediaConverter
Hardware Decode & Quick Sync Encode0:46
0:56
1:09
Hardware Decode & Software Encode1:26
2:22
-
Software Decode & Quick Sync Encode2:10
2:07
-
Software Decode & Encode2:10
2:43
1:24

Obwohl unser nur 665 MB großer H.264/AC3-Clip (ebenfalls im BDAV Container) mit der gleichen Bitrate läuft wie unser 31,2 GB großer Film, kommen sowohl die Radeon HD 6970 als auch die GeForce GTX 580 bei hardwarebeschleunigter Konvertierung auf deutlich bessere Ergebnisse. Beim Core i5-2500K mit Quick-Sync-Unterstützung zeigen sich hingegen nur dann nennenswerte Vorteile, wenn man beim Quality-Preset die Hardware zum Konvertieren mit einspannt.

ArcSofts MediaConverter kann entweder in Hardware- oder in Software konvertieren und lässt sich nicht ganz so fein einstellen, wie die Anwendung von CyberLink. Dafür ist der Media Encoder beim Konvertieren durchweg deutlich schneller. Schaut man sich die Zeiten an, sieht es auch so aus,als sei MediaConverter besser für die Nutzung mehrerer Threads optimiert. Immerhin ist das Video über eine Minute schneller konvertiert als bei der Konkurrenz.

Mit diesem kleineren Clip schafft es AMDs APP auch endlich, ein schnelleres Ergebnis zu liefern als wenn man die gesamte Aufgabe per Software abarbeitet. Der Unterschied fällt aber ziemlich gering aus. Das legt nahe, dass der neue Core i5-2500K einfach zu schnell ist. Man würde also mehr von der Beschleunigung durch AMDs Grafikhardware profitieren, wenn man sie in ein älteres System mit langsamerem Prozessor steckt.

Insgesamt rast Quick Sync CUDA als auch APP sowohl bei der Encoding- als auch der Decoding-Performance ganz schön alt aussehen. Die Unterschiede zwischen AMD und Nvidia sind in Anbetracht der gemischten Ergebnisse dafür weit weniger deutlich. Kommt das vielleicht daher, dass wir eine Blu-ray-Quelle mit hoher Bitrate nutzen?

Erstelle einen neuen Thread im Artikel-Forum über dieses Thema
Dieser Thread ist für Kommentare geschlossen
12 Kommentare
    Dein Kommentar
  • Super Artikel, aber bitte nochmal korrekturlesen :-)
    0
  • 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
  • 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
  • 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
  • Mich hätte wirklich interessiert, warum Hardware-Enconding schlechtere Qualität liefert. Steht das auch irgendwo im Artikel?
    0
  • 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
  • @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
  • 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
  • 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
  • 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
  • ". 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
  • @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