News x264 und HandBrake erhalten GPU-Beschleunigung

Dr@

Grand Admiral Special
Mitglied seit
19.05.2009
Beiträge
12.791
Renomée
4.066
Standort
Baden-Württemberg
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
<div class="newsfloatleft"><a href="http://www.planet3dnow.de/photoplog/index.php?n=14362"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Fusion-Logo.png" border="0" alt="AMD-Fusion-Logo"></a></div>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 <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1337065778">zweiter Generation A-Serie APUs</a> (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.<p style="clear:left;"><center><a href="http://www.planet3dnow.de/photoplog/index.php?n=20284"><img src="http://www.planet3dnow.de/photoplog/images/54308/medium/1_x264_Handbrake_OpenCL.png" border="1" alt="x264 und Handbrake bekommen OpenCL-Beschleunigung"></a></center>

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.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=20285"><img src="http://www.planet3dnow.de/photoplog/images/54308/large/1_x264-Handbrake-OpenCL.png" border="1" alt="x264 und Handbrake bekommen OpenCL-Beschleunigung"></a><small>
<b>Quelle:</b> <a href="http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu" target="b">AnandTech</a></small></center>

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 <i>High Profile</i> 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:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>"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."</i></td></tr></tbody></table></div>
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.


<a name="Update"><b>Update 12:45:</b></a>

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.

<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat: Jarred Walton</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>"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)."</i></td></tr></tbody></table></div>
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat: Anand Lal Shimpi</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>"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."</i></td></tr></tbody></table></div>


<b>Quelle:</b><ul><li><a href="https://docs.google.com/gview?url=http://www.amd.com/us/Documents/Second_Generation_AMD_A_Series_APU_Quotes.pdf" target="b">AMD</a></li><li><a href="http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu" target="b">AnandTech</a></li></ul>

<b>Links zum Thema:</b>
<ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330476490">HandBrake 0.9.6</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1335117289">OpenCL-Debugger gDEBugger ist jetzt auch für Linux verfügbar</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1324449069">Das AMD Accelerated Parallel Processing (APP) SDK 2.6 wurde veröffentlicht</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1322593666">AMD sponsert OpenCL-Implementierung in GIMP</a></li></ul></p>
 
Großsartige News!!! Danke dafür!

Wurde auch endlich mal Zeit, darauf warten sicherlich viele!!!!
 
Welche GPUs werden genau unterstützt? Auch HD2000, HD3000 von Intel und HD 5770 von AMD?

Ich zieh mir jetzt mal den Nightly Build zum Testen.
 
Na das ist doch mal ein Lichtblick! Bin gerade dabei meine über die Jahre sehr umfangreich gewordene DVD Film und Seriensammlung zwecks Backup zu digitalisieren (atm z.B. die 10 Staffeln Stargate SG-1 ^^).
Und da kommen absurd hohe Datenmengen zusammen! Richtig hässlich wirds bei neueren Serien in HD, die meisten von mir sind zum Glück noch aus der preHD zeit ^^.

Von der nötigen Zeit bei den ganzen transkodierungen ganz zu schweigen, evtl mache ich erstmal eine Pause und warte auf die neue HandBrake version mit GPU Beschleunigung, denke meine HD6980 dürfte da um einiges flotter sein als mein Phenom II X965 :).
 
Tja so schnell wird das nichts Leute

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).
 
Tja so schnell wird das nichts Leute
Kannst Du dazu bitte noch die Quelle angeben? :)


Edit:
OK, habs gefunden. Gibt es bei AnandTech ne Möglichkeit einzelne Kommentare direkt zu verlinken? Ich würde der News nämlich gerne ein Update verpassen.
 
..
Von der nötigen Zeit bei den ganzen transkodierungen ganz zu schweigen, evtl mache ich erstmal eine Pause und warte auf die neue HandBrake version mit GPU Beschleunigung, denke meine HD6980 dürfte da um einiges flotter sein als mein Phenom II X965 :).

Probiers doch mal aus und lass die Karte gegen deine CPU antreten.

Ich brauch mit Handbrake für eine DVD zwischen 8 und 12 Minuten.
Für eine BluRay zwischen 40 und 55 Minuten.
Ich habe aber nur eine 9800GTX+ so das ich so oder so nicht von der GPU Beschleunigung profitieren würde.
 
"Bisher konnten GPU-beschleunigte Encoder zwar zumeist überzeugen, wenn es allein um die Geschwindigkeit ging, lieferten dabei aber eine indiskutable Bildqualität ab."

Damit steht und fällt eigentlich alles.

"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 "

Was denn nun? ENCodieren oder TRANScodieren? Oder ist das nur in diesem Beispiel so?

Datenraten sind ohnehin nicht wirklich aussagekräftig.
 
"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 "

Was denn nun? ENCodieren oder TRANScodieren? Oder ist das nur in diesem Beispiel so?
x264 ist ein Encoder, mir dem sich unkomprimierte Videodateien in das Video-Format H.264 (MPEG-4 AVC) überführen lassen.

In dem Beispiel von Anandtech wird Handbrake getestet. Als Ausgangsformat dient dabei ein MPEG-2-Video das in das H.264-Format transkodiert wird, es wird also von dem einen komprimierten Format in ein anderes überführt.

Wo liegt das Problem?
 
Ein Verständnisproblem, welches ich hatte.

lassen sich die Benchmarks 1zu1 auf das (neu)encodieren übertragen?
 
[...HonigumBartschmier..]

Hm, sehr schön!

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.

wt..? Auf den nächsten AKW Gau würde ich eher wetten als darauf das AMD hier als Ausnahme zur Regel mal seine Software fertig gebacken bekommt.

Traurig! Vor allem weil man um ein paar Schlagzeilen willen auf ein reales Produkt verzichtet. Aber das ist natürlich das Vorrecht einer AG, AMD ist ja nicht die Heilsarmee.
 
ja, so ganz schön ist das natürlich nicht. Aber wahrscheinlich ist der Code noch so quick and dirty, daß es zu peinlich wäre, ihn zu veröffentlichen. Oder (wahrscheinlicher) man will noch prüfen, ob definitiv keine Patentrechte verletzt werden, d.h. darin keine 3rd-Party-IP verbraten ist.
 
Bei mir friert der Lappi ein will man den Prozess beenden.
Der Prozess selber ist langsam (10fps).
hd 3470, amd x2 64 2,1 ghz

Würde mir schon wünschen einen ordentlich Beschleuniger für ein paar DVDrips nutzen zu können.
Momentan rippe ich meine DVDs ganz auf Platte oder versuche mit diversen Tools den Hauptfilm raus zu picken.
Ich mach das aber momentan ehe nur wegen Platzmangel und nicht aus geizigkeit.

Welche Software liegt den weit vorne in der Geschwindigkeit ? Abgesehen von Handbrake halt.
 
Bei mir friert der Lappi ein will man den Prozess beenden.
Der Prozess selber ist langsam (10fps).
hd 3470, amd x2 64 2,1 ghz

Würde mir schon wünschen einen ordentlich Beschleuniger für ein paar DVDrips nutzen zu können.
Momentan rippe ich meine DVDs ganz auf Platte oder versuche mit diversen Tools den Hauptfilm raus zu picken.
Ich mach das aber momentan ehe nur wegen Platzmangel und nicht aus geizigkeit.

Welche Software liegt den weit vorne in der Geschwindigkeit ? Abgesehen von Handbrake halt.

Hi,

grundsätzlich hast Du die beste Qualität immer mit x264.exe - Ich verwende als Frontend dafür StaxRip Ein Tool, dass verhältnismässig einfach zu bedienen ist, aber auch den Profis Raum lässt, sich zu entfalten. StaxRip ist ein Frontend dass sich mehrerer Tools bedient (u. a. das extrem mächtige eac3to.exe sowie x264.exe, nur um mal die beiden "bekanntesten" und besten zu nennen!)

Allerdings verwende ich selbst meistens für DVDs das kommerzielle Nero Recode nebst AVC-Profil, dass Teil der Nero-Brennsuite ist. Das ist insgesamt etwas komfortabler, bietet aber nicht die gleiche großartige Qualität sowie Vielfalt wie x264.exe / StaxRip. Allerdings hast Du grade bei DVDs mit mehren Titeln große Vorteile.

Wenn es allerdings um Übernahme DTS-Tonspuren oder HD-Konvertierung geht, führt eigentlich kein Weg an MKV (also x264.exe nebst entsprechenden Audio-Tools) vorbei.

Guck dir mal StaxRip an, damit kann man eigentlich sehr gut Leben. Wie gesagt, mein Favorit wenns um Leistung und Qualität geht.
 
Probiers doch mal aus und lass die Karte gegen deine CPU antreten.

Ich brauch mit Handbrake für eine DVD zwischen 8 und 12 Minuten.
Für eine BluRay zwischen 40 und 55 Minuten.
Ich habe aber nur eine 9800GTX+ so das ich so oder so nicht von der GPU Beschleunigung profitieren würde.


werde ich tun sobald ich aus der Klinik entlassen wurde (und erstmal ne runde Diablo 3 gespielt habe!!!!).
Wo finde ich denn eine HandBrake und h264 Version die bereits OpenCL (teilweise) implementiert hat?


€dit:
komme derzeit überigends auf ca 90 fps wenn Deinterlace Filter aktiv sind und eta 135 fps wenn Deinterlace nicht aktiv ist mit meinem QuadCore. Leider ist Deinterlace pflicht bei den alten SG-1 Staffeln ;) die ham auch noch die gute alte "Filmkörnung" selbst im Originalmaterial, dachte erst es läge an meinen Codec settings und hatte dann teilweise so absurd hohe werte, dass eine 42 min folge 9 GB groß wurd, ehe ich auf die idee kam mal das original abzuspielen... :)

Ich wiederhole: KEINE HD DVDs / Bluerays ausm Kopf weiß ich die settings und auflösung gerade nicht mehr aber war was um die 7xx * 5xx mit RF von 19 und inklusive englischer und deutscher tonspur @320kbs und subs in beiden sprachen (eine 42 min folge resultiert in 700 - 1000 mb großen files).

Um mal nen richtwert zu geben ;).

meld mich "die Tage" dann wenn ich vergleichswerte mit GPU beschleunigung habe. kann aber nich sagen wann das is da die mich hier nich raus lassen wollen ^^.
 
Zuletzt bearbeitet:
Ich vermute mal, Du redest hier jetzt von StaxRip

Du musst in Staxrip doppelklick auf die weisse Leiste unter Source machen, dann "Single Or Merge" Files und dann wählst Du die VOB-Dateien der DVD-Struktur. Das ist genau der Punkt, wo Nero Digital deutlich mehr Komfort bietet, weil Du für StaxRip vorher genau gucken musst, welche VOB-Dateien die "richtigen" sind.

Hier mal ein Beispiel dafür, die rot umrandeten Dateien wären ein kompletter Film:

unbenanntlak6p.jpg



Edit

Staxrip fügt die hier ausgewählten Dateien dann im Endeffekt zu einer einzelnen Datei zusammen, nur dass da keine Missverständnisse auftreten! :)
 
wandle die dvd vorher mit makemkv in einen mkv container um - dabei kannst du auch alle audiospuren rauswerfen die du nicht brauchst. du kopierst damit lediglich die dvd in einen container, wandelst also noch nichts um.
 
Ist mit StaxRip eigentlich unnötig, weil der vorher auch alles zuerst de-muxt und du aus dem entmuxten raussuchen musst, wass alles wieder rein soll :)
 
hallo.
danke für die infos.
ich habe die dvds vorher mit dvdfab auf platte geriped. z.t. vollständig und z.t. mainmovie allein.
dabei kann man ja auch schon die tonspuren seiner wahl mitnehmen.
Stonehedge hat ja aber recht dass es mit staxrip auch entsprechend einfach vorbereitet wird.
mir kam das nur bischn ungewohnt vor die main vobs zu suchen und automerg zu nutzen.

der rip prozess mit x264 ist relativ langsam bei mir. etwa 15-20 fps. da dauert ein 100min film etwa 3std. und mehr. und es handelte sich hierbei um ein anime,mit entsprechendem codec setup.
mein laptop ist da einfach zu schwach für. wobei ich das ja dann einfach über nach oder bei was anderem im hintergrund laufen lassen kann.

90 min film in 90 min geriped. das wünsche ich mir XD. mit nem normalem PC sollte das aber auch kein ding sein.

danke euch
 
Na das ist doch mal ein Lichtblick! Bin gerade dabei meine über die Jahre sehr umfangreich gewordene DVD Film und Seriensammlung zwecks Backup zu digitalisieren
Digitale Daten zu digitalisieren ist schon bissel schräg, oder? ;)
DVDs hab ich auch mit Handbrake schön schnell eingedampft, da freu ich mich, wenn es noch schneller geht, sofern die Qualität dabei nicht leidet.
In welchem Format liegen denn Deine HD-Serien vor? Auch noch MPEG2? Blaustrahl-Scheiben nutzen ja eigentlich bereits H.264, da wird sich nur noch auf Kosten der Qualität Platz einsparen lassen.

lassen sich die Benchmarks 1zu1 auf das (neu)encodieren übertragen?
Es entfällt ja das Decodieren, also wird das Encodieren allein wohl mindestens so schnell sein, vielleicht sogar einen Hauch schneller (je nachdem, wie sehr das System eben mit dem Decodieren des Ursprungsformates beschäftigt wäre).
 
Bei mir friert der Lappi ein will man den Prozess beenden.
Der Prozess selber ist langsam (10fps).
hd 3470, amd x2 64 2,1 ghz

Würde mir schon wünschen einen ordentlich Beschleuniger für ein paar DVDrips nutzen zu können.
Momentan rippe ich meine DVDs ganz auf Platte oder versuche mit diversen Tools den Hauptfilm raus zu picken.
Ich mach das aber momentan ehe nur wegen Platzmangel und nicht aus geizigkeit.

Welche Software liegt den weit vorne in der Geschwindigkeit ? Abgesehen von Handbrake halt.

Da würde ich mich fragen ob .264 wirklich Wahl der Wahl der Waffen ist..
Ich, mit einem Brisbane 4850e & HD 5570 im Desktop nicht ganz unähnlich ausgestattet, schwöre aufgrund des gefälligen Sweetspots um Quali/Platzbedarf/Geschwindigkeit auf den steinalten Dr.Divx 8)
Da ich üblicherweise beschneide & auf 592 * ~360 runterkodiere macht der idR solide 50fps (nur übern Proz) , Bei Auflösungsbeibehaltung waren es mal "etwas über" 30
Ach ja , und die meisten DVD-Standalones spielen das auch willig ab *lol*

Mmoe
 
@mmoses

welche auflösungen schaffen den die Divx zertifizierten Geräte ? Schaffen diese auch 720*576 in einem AVI ctnr ?
ich würd ja gern bei der auflösng bleiben, halt nur besser komprimiert.
 
Zurück
Oben Unten