Download HandBrake 0.10.0 bringt Unterstützung für H.265, VP8, QuickSync und OpenCL

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
HandBrake-Logo.png


Die kostenlose Videosoftware HandBrake ist in der Version 0.10.0 erschienen, die eine Reihe von Neuerungen mit sich bringt. Ab sofort können auch die Codecs H.265 und VP8 für die Enkodierung von Videos verwendet werden, wobei HandBrake auf die Encoder x265 bzw. libvpx zurückgreift. x265 basiert in Teilen auf dem bekannten x264-Encoder, der ebenfalls von HandBrake bei der Erstellung von H.264-Videos Anwendung findet, und befindet sich noch in einem recht frühen Entwicklungsstadium. Außerdem haben die Entwickler Unterstützung für
(…)

» Artikel lesen
 
Danke, Dr.@ ich benutze das tolle Tool häufiger und bin froh das es jetzt diese Features beinhaltet.
*great*
 
Vllt. schaffen sie es rechtzeitig zum Marktstart des vollen Tonga-Chips. Ich wünsche es mir auch.
 
Ich fände es ja toll, wenn die auch die VCE-Einheit unterstützen würden ...

Das die Umsetzung seit langem auf sich warten lässt. Ich vermute, dass die Umsetzung nicht so tivial ist oder dass das Ergebnis nicht sonderlich beeindruckt. Qualitäts- oder Performanceprobleme.
 
Funktioniert denn die Hardware-Unterstützung auch für das High-Profile von x264? Was anderes kommt mir nämlich nicht ins Haus :)
 
sehr gut! tolles kleines Programm :)
 
Ich fände es ja toll, wenn die auch die VCE-Einheit unterstützen würden ...

Dito, alleine aus Marketing-/Imagegründen. Wenn AMD schon "mithilft", wäre die VCE Unterstützung mMn die wichtigere gewesen, vorallem eben, wenn eine Qucksync Unterstützung hinzukommt...
 
Und wie ist die Quali bei OpenCL? Ich nutze ja seit Jahren Ripbot und habe nicht annähernd etwas vergleichbares gefunden, aber wenn nun die GPUs mitmischen und das Resultet zufriedenstellend ist, wer weiß.
 
Bei der OpenCL-Geschichte sollte bedacht werden, dass es nur um den Filter zur Skalierung geht! Beim Transkodieren muss also von einer Auflösung auf eine andere umgewandelt werden, sonst gibt es keinen "OpenCL-Effekt".

Da es sich um unterschiedliche Algorithmen zur Berechnung des skalierten Bildes handelt, werden sich auch die Ergebnisse hinsichtlich der Bitrate/Dateigröße und Qualität unterscheiden. Ob die OpenCL-Version ordentlich aussieht (besser/schlechter/ähnlich/gleich), kann ich nicht sagen. Wer mag das mal testen und hier die Ergebnisse posten? :)

Weil es auch nur um die Skalierung geht, sollten auch keine signifikanten Unterschiede bei der Performance erwartet werden. Ich würde einen einstelligen Prozentwert erwarten. In ungünstigen Fällen könnte theoretisch der Skalierungsfilter auch einen höheren Rechenaufwand für den Encoder verursachen, sodass das Video nicht schneller, sondern langsamer umgewandelt wird. Auch hierzu würden mich Vergleichswerte interessieren. :)

Prinzipiell sollte es auch möglich sein, in HandBrake die OpenCL-beschleunigte lookahead-Funktion von x264 zu verwenden. Dies ist aber offenbar über das normale Benutzermenü nicht möglich. Dazu müsste man ein Batchscript schreiben. Aber auch da war ja die Erkenntnis, dass die multithreaded Version effektiver ist. Siehe mein damaliger Artikel, der auch in der News verlinkt ist und weiterhin Gültigkeit besitzt.
 
Mag hier mal einer der Intel-User kurz antesten wieviel von der Quicksync-Beschleunigung zu halten ist? Wenn das anständig funktioniert, womöglich noch mit reduzierter Leistungsaufnahme dank Hardware-Beschleunigung, wäre das ein Grund, meinem HTPC doch einen Intel zu spendieren.
 
Das die Umsetzung seit langem auf sich warten lässt. Ich vermute, dass die Umsetzung nicht so tivial ist oder dass das Ergebnis nicht sonderlich beeindruckt. Qualitäts- oder Performanceprobleme.

Wer sich die VCE Einheit mal angucken möchte, kann ja zu A's Video Converter greifen, da geht das.
Nur soviel, Performanceprobleme hat die eher nicht, macht bei "Quali" 123fps auf Kaveri A8-7600@45Watt.
Bei "Speed" dreht VCE bis 232fps auf, dabei ist nicht wirklich Dauerlast auf der Kiste.
File war 720p
Allerdings ....
Die optische Qualität ist eher grottig, so Stichworte wie Detailreichtum sollte man gleich vergessen.
Ist aber die Frage woran das liegt?
An VCE? Oder der Implementierung?
Muss wohl noch reifen ...
AMD sollte da generell helfend tätig werden!
 
Die große Version des Video-Optionen-Dialogs ist im Beitrag nicht verlinkt, übernehm ich das mal ;D

HandBrake-0.10-Optionen.png
 
Wer sich die VCE Einheit mal angucken möchte, kann ja zu A's Video Converter greifen, da geht das.
Nur soviel, Performanceprobleme hat die eher nicht, macht bei "Quali" 123fps auf Kaveri A8-7600@45Watt.
Bei "Speed" dreht VCE bis 232fps auf, dabei ist nicht wirklich Dauerlast auf der Kiste.
File war 720p
Allerdings ....
Die optische Qualität ist eher grottig, so Stichworte wie Detailreichtum sollte man gleich vergessen.
Ist aber die Frage woran das liegt?
An VCE? Oder der Implementierung?
Muss wohl noch reifen ...
AMD sollte da generell helfend tätig werden!
Ich tippe auch auf das reifen, ab und zu kann man bei den Developer ein paar Infos erfragen: http://devgurus.amd.com/thread/169531

Currently available dGPU R9 285 (Tonga) has support for 4K H.264 Encoder and Decoding. APUs and dGPUs scheduled for release in 2015 will have support for 4K Encoding & Decoding as well as H.265 decoding.
 
@ pic: Wusste gar nicht, das es jetzt da auch ne she Edition von gibt ... örks, sieht ja übel aus farblich.

Witzig noch zu erwähnen, bei A's Video Converter ist der Verbrauch der Mühle, der liegt nur 10Watt über idle.
 
@Brutus5000
Bringt die Verwendung des High-Profils von x264 bei dir denn viel? Bei meinen Videos konnte ich nur Unterschiede im dreistelligen KB-Bereich feststellen.
 
Zuletzt bearbeitet:
@Unbekannter Krieger: Im Vergleich zum Baseline-Profil (unter Handbrake ist das "Normal") war das bei mir ca. 30-40% Ersparnis. Also eine übliche Serienfolge (kein Anime) 45 Minuten bei Baseline ca. 1GB, High Profile 550-650 MB.

Ich habe lange damit experimentiert, weil die ersten Smartphones nur Baseline hardwarebeschleunigt wiedergeben konnten und mann dann auf den Software-Decoder wechseln musste. Das hat ordentlich am Akku gesaugt, aber andersherum war die SD-Karte ruckzuck voll.
 
Hmm... Meine Videos mit ca. 35 min Nicht-Anime-Material, nennen wir es Talk, wiesen wie erwähnt nur Unterschiede ab der ersten Nachkommastelle von MB auf. Werde es weiter untersuchen.
 
Bei gleichbleibender Qualität? Wenn Du nur ein andres Profil wählst, dann aber die Bitrate nicht anpasst, wird sich an der resultierenden Dateigröße auch nix ändern. Ich weiß allerdings auch nicht, wie das in Handbrake gehandhabt wird, ich nutze mal libav und mal ffmpeg per Kommandozeile (Skript).

Ich erziele mit dem High-Profil mit gleicher Bitrate wie zuvor eine deutlich bessere Qualität, weniger Artefakte - natürlich bei ungefähr gleich bleibenden Dateigrößen. Ich habe nicht versucht, den mit Sicherheit abnehmenden Größenunterschied des resultierenden Materials bei möglichst gleichbleibender Qualität zu ermitteln, da mir Qualität und resultierender Platzverbrauch momentan sehr zusagen (z.B. 1:46h bei 1024x576 [quadratische Pixel 16:9] ergeben 827 MB, Video-Bitrate=1000k, Audio-Bitrate [OGG] = 96k). Ich werd erst bei gut funktionierendem h.265 (Encoder und möglichst alle Abspielgeräte, die ich dann nutze) wieder mit der Bitrate experimentieren, um möglichst gleich bleibende wie oder auch noch etwas bessere Qualität als gegenwärtig bei niedrigerem Plattenplatz-Verbrauch zu erreichen.

Encodierungsmerkmal sind diverse Filme, Serien und sonstige Sendungen, Quelle DVB-S.
 
@nazgul99
Mein LG Blue-RayDisc Laufwerk wird mit SATA II angebunden über die SB950, kann mit x4 schreiben bei 50GiB Volumen. *suspect*
Je besser die Quelle desto kleiner das Ergebnis... *chatt*
 
Zurück
Oben Unten