Planet 3DNow! Logo  

 
English Français Русский язык Español Italiano Japanese Chinese

FORUM AKTUELL

   

Mittwoch, 16. Mai 2012

07:51 - Autor: Dr@

x264 und HandBrake erhalten GPU-Beschleunigung [Update]

AMD-Fusion-Logo
Einige haben die entsprechenden Logos vielleicht auch schon in den Folien von AMD entdeckt, denn es gab auf dem Presse-Event zur Vorstellung von AMDs zweiter Generation A-Serie APUs (Codename "Trinity") eine Überraschung: Der plattformübergreifende Open-Source-Encoder x264 für das Video-Format H.264 (MPEG-4 AVC) und damit auch das Videotool HandBrake, welches eine grafische Benutzeroberfläche für eben diesen Encoder ist, werden per OpenCL beschleunigt. Leider hielten sich die Sprecher von AMD uns gegenüber zu den Details der Umsetzung trotz mehrfacher Nachfragen bedeckt. Glücklicherweise bringen die Kollegen von AnandTech jetzt Licht ins Dunkel, immerhin handelt es sich hier um Tools, welche sich einer deutlich größeren Beliebtheit erfreuen dürften, als die meisten kommerziellen H.264-Kodierer. Das liegt neben dem offensichtlichen Grund (beide sind kostenlos verfügbar) an der sehr guten Bildqualität kombiniert mit einer sehr effizienten Kompression und Ausnutzung von Mehrkernprozessoren.

x264 und Handbrake bekommen OpenCL-Beschleunigung


Laut AnandTech verfolgen die Entwickler von HandBrake bei der GPU-Beschleunigung mehrere Ansätze: Zum einen verwendet das Transkodierungs-Tool die DXVA-Schnittstelle von Microsoft Windows, um die Dekodierung des Ausgangsformates über die GPU zu beschleunigen. Dabei kommt entsprechend der jeweiligen Hardware ein spezieller, festverdrahteter Funktionsblock (z. B. UVD von AMD oder PureVideo HD von NVIDIA) zum Einsatz, welcher speziell für diese Aufgabe optimiert wurde. Zum anderen werden GPU-typische Aufgaben wie die Skalierung und Farbraumkonvertierung ebenfalls auf die GPU ausgelagert. Außerdem soll für die Berechnung der "Lookahead"-Funktion des Enkodierungsprozesses ebenfalls über OpenCL auf die GPU zurückgegriffen werden. Diese Teilaufgabe ist hierfür gut geeignet, weil es sich um ein datenparalleles Problem handelt, welches bereits in einem eigenen Thread läuft. Mit der "Lookahead"-Funktion bestimmt der Encoder, wie viele Frames er vorausschauen muss, um eine optimale Bildqualität zu erreichen. Dies ist wichtig, da die Komprimierungsalgorithmen im wesentlichen darauf aufbauen, dass lediglich die Änderungen zwischen den einzelnen Bildern gespeichert werden. Letztlich ist es also das Ziel, die redundanten Daten so stark wie möglich zu reduzieren.

x264 und Handbrake bekommen OpenCL-Beschleunigung
Quelle: AnandTech


Für einen ersten Test stand AnandTech eine frühe Entwicklerversion von HandBrake sowie die aktuelle stabile Version des Tools zur Verfügung. Als Ausgangsmaterial für den Vergleich nutzten die Kollegen ein 1080p-Video im MPEG-2-Format, welches in das Formal H.264 mit einer Auflösung von 720p transkodiert wurde. Hierzu kam das High Profile von Handbrake mit den Standardeinstellungen zum Einsatz. Alle für den Test herangezogenen AMD- und Intel-Prozessoren erreicht mit der GPU-beschleunigten Version höhere FPS-Werte. Die getestete AMD A8-3500M APU ("Llano") verbesserte sich von 5,7 FPS auf 12,05 FPS und die AMD A10-4600M APU ("Trinity") von 6,98 FPS auf 15,01 FPS, was in beiden Fällen einer Verdoppelung der Trankodierungsleistung entspricht. Damit kann die "Trinity"-APU den Rückstand auf den Intel i7-2820QM ("Sandy Bridge") von enormen 73% auf lediglich 7% stark verkürzen, der allerdings mangels OpenCL-Unterstützung lediglich von der GPU-beschleunigten Dekodierung profitieren kann. Der Intel i7-3720QM ("Ivy Bridge") hält hingegen die Konkurrenz auch mit Beschleunigung auf Abstand.

Was dieser erfreuliche "OpenCL-Boost" für HandBrake bzw. x264 wirklich Wert ist, muss sich noch zeigen. Bisher konnten GPU-beschleunigte Encoder zwar zumeist überzeugen, wenn es allein um die Geschwindigkeit ging, lieferten dabei aber eine indiskutable Bildqualität ab. Letztlich lautete daher die Empfehlung, lieber die deutlich längere Rechenzeit auf der CPU in Kauf zu nehmen. Es bleibt zu hoffen, dass die Implementierung von x264 es besser macht. AnandTech trifft hierzu leider nur die Aussage, dass sie keinen Qualitätsunterschied zwischen den unterschiedlichen Ausgaben beobachten konnten, die mittels der OpenCL-beschleunigten Transkodierung erstellt wurden. Zudem wiesen die transkodierten Videodateien, welche allein auf den CPU-Kernen berechnet wurden, höhere Datenraten auf - wurden also weniger stark komprimiert. Diese Unterschiede können dem frühen Entwicklungsstadium der GPU-Beschleunigung geschuldet sein.

Der Projektleiter von x264, Jason Garrett-Glaser kommentierte die Zusammenarbeit mit AMD wie folgt:
Zitat:
"x264 is the world's leading video encoding library, used in applications ranging from web video to broadcast television, cloud gaming, telemedicine, Blu-ray, and more. AMD has been a great partner, working openly as part of the open source community to help enhance x264 with GPU capabilities using OpenCL."

Wann die GPU-beschleunigten Versionen von h264 und HandBrake verfügbar werden, ist unbekannt. Dies liegt aber in der Natur von Open-Source-Projekten, schließlich hängt das Tempo entscheidend davon ab, wie viel Zeit die freiwilligen Entwickler aufbringen können.


Update 12:45:

Anand Lal Shimpi und Jarred Walton haben in den Kommentaren zur News bei AnandTech weitere Details zum Stand der Implementierung verraten. Offenbar wird der OpenCL-Code derzeit nicht vom x264-Projekt entwickelt, sondern von AMD intern. Irgendwann soll der Code und die zugehörige Dokumentation dann der Open-Source-Community zugänglich gemacht werden. Derzeit befindet er sich unter Verschluss und kann ausschließlich von AMD direkt bezogen werden. Zudem hat sich AMD wohl bisher auf die Optimierungen für integrierte Grafiklösungen konzentriert, weshalb AnandTech darum gebeten wurde, vorerst keine Tests auf diskreten Grafiklösungen durchzuführen.

Zitat: Jarred Walton
"The OpenCL code at present is developed in house by AMD and they will eventually provide all of the code and documentation back to the open source community. However, for now it is all under tight wraps and there is no way to get it (other than from AMD)."

Zitat: Anand Lal Shimpi
"Not quite yet, the current build hasn't really been optimized or tested for dGPU usage. We were asked to limit our testing to integrated solutions for the time being."


Quelle:Links zum Thema:

» Kommentare
Planet 3DNow! RSS XML Newsfeed Planet 3DNow! Newsfeed bei iGoogle-Seite hinzufügen Planet 3DNow! Newsfeed bei My Yahoo! hinzufügen Planet 3DNow! Newsfeed bei Microsoft Live hinzufügen Planet 3DNow! Newsfeed bei My AOL hinzufügen

Weitere News:
Intern: Umleitungsprobleme
Intern: Planet 3DNow! ab 18:00 Uhr eingeschränkt erreichbar
Never Settle Forever: AMD überlässt Zusammenstellung der Spielebündel seinen Kunden
Microsoft Patchday August 2013
Der Partner-Webwatch von Planet 3DNow! (13.08.2013)
Kühler- und Gehäuse-Webwatch (11.08.2013)
Ankündigung Microsoft Patchday August 2013
Vorerst kein Frame Pacing für AMD-Systeme mit Dual Graphics
Intern: kommende Woche eingeschränkte Erreichbarkeit auf Planet 3DNow!
Kaveri verschoben und keine neuen FX-Prozessoren von AMD [3. Update]
AMD plant Vorstellung neuer High-End-Grafikkarte Hawaii im September
Kaveri verschoben und keine neuen FX-Prozessoren von AMD [Update]
Der Partner-Webwatch von Planet 3DNow! (06.08.2013)
Kaveri verschoben und keine neuen FX-Prozessoren von AMD
AMD startet neue "Never-Settle-Forever"-Spielebündel für Radeon Grafikkarten
Neuer Artikel: SilverStone Fortress FT04 - Die Hardware steht Kopf

 

Nach oben

 

Copyright © 1999 - 2019 Planet 3DNow!
Datenschutzerklärung