2L84H8
Lieutenant
- Registriert
- Okt. 2012
- Beiträge
- 558
nille02 schrieb:Die CPU braucht aber auch ein vielfaches der Watt/h wie der Hardware-Decoder.
Bleibt nur die Frage wie gut der Hardware-Decoder ist. Wenn da das Bild nicht gut ist wird das encoding auch schlecht. Dennoch ist die Hilfe, die die GPU bieten kann recht gering. Abgesehen vom lookahead (Wenn man den wert mal etwas anhebt.) ist der Rest eher neben bei erledigt für eine CPU.
Ich hoffe hier ja auf den Nachfolger von h264. h265 soll man deutlich besser über die GPU Decodieren und Encodieren können.
Diese Einwände sind durchaus berechtigt. Es ist natürlich ärgerlich, wenn die CPU-Kerne das Decoding machen müssen. Gerade bei den kleineren APUs reicht die CPU-Leistung dafür auch nur bedingt oder eben gar nicht.
Was die Qualität und Geschwindigkeit von OpenCL-Encoding mit Handbrake angeht, kann ich mich nur auf den schon oben erwähnten AnandTech-Artikel berufen:
http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu
While video transcoding is significantly slower on Trinity compared to Intel's Sandy Bridge on the traditional x86 path, the OpenCL version of Handbrake narrows the gap considerably. A quad-core Sandy Bridge goes from being 73% faster down to 7% faster than Trinity. Ivy Bridge on the other hand goes from being 2.15x the speed of Trinity to a smaller but still pronounced 29.6% lead. Image quality appeared to be comparable between all OpenCL outputs, although we did get higher bitrate files from the x86 transcode path. The bottom line is that AMD goes from a position of not really competitive, to easily holding its own against similarly priced Intel parts.
Der Treppenwitz ist natürlich, dass jede intel-CPU (oder AMD-CPU) mit zusätzlicher NVidia- bzw. AMD-Graka auch von OpenCL optimierter Software profitieren wird. Dann ist es mit einem "Vorsprung" durch die APU schnell mal vorbei.
In Anlehnung an das bisher von mir Geschriebene zum AMD-Grafik-Treiber, würde ich mir aber auch mehr Engagement von intel in Sachen QuickSync wünschen. Einerseits wird QuickSync sogar unter Windows nur von sehr wenigen Programmen wirklich eingesetzt und unter Linux liegt die QuickSync-Engine ganz brach. Über die unterschiedlichen Qualitäten der Outputs von x86-, QuickSync- und OpenCL-Encoding könnte man wohl auch eine Doktorarbeit verfassen. Irgendwie vergleicht man da auch Äpfel mit Birnen, auch wenn der Output von der Qualität her sehr ähnlich erscheint.