Notiz Community: HEVC mit AMD, Intel und Nvidia in Hardware wiedergeben

Jan

Chefredakteur
Teammitglied
Registriert
Apr. 2001
Beiträge
16.021
ComputerBase-Leser habichtfreak präsentiert im Forum eine neue FAQ zum Thema Wiedergabe von Videos im HEVC-Format (H.265). Welche GPUs respektive CPUs von AMD, Intel und Nvidia das Format in Hardware beherrschen wird ebenso geklärt wie die Anforderungen an den Prozessor bei der Dekodierung in Software.

Zur Notiz: Community: HEVC mit AMD, Intel und Nvidia in Hardware wiedergeben
 
Gamefaq schrieb:

Eine schöne Erklärung womit man welche Hardware nutzen kann wäre schon was. Was mich bei AMD bisher so ärgert ist der Mangel einer API fürs Encoding, die auch Beachtung findet. Bzw, das AMD selber auch Aktiv wird um ihre Techniken zu verbreiten.

Ich compiliere mir recht aktuelle ffmpeg git Versionen direkt mit Quicksync und nvenc. Bei beiden hat der jeweilige Hersteller mitgewirkt um das zu ermöglichen. Nun, für AMD gibt es da nichts und man muss aber eingeschränkte Software zurückgreifen.
 
Krautmaster schrieb:
sehr schön. Jetzt noch ein State of the Art Encoding Vergleich bitte.

tatsächlich habe ich genau das heute vormittag gemacht. allerdings weniger um den artikel zu ergänzen (encoden ist ja das gegenteil von dekodieren), vielmehr um für mich selbst die frage zu klären, ist x265 schon besser als x264? die erkenntnis fiel unerwartet aus:

als quelle diente h.264 - 4k - 25mbit

x264 - cq20 - 720p ist meine momentane stardardeinstellung für so ziemlich alles

erster versuch mit x265 (ebenfalls cq20 und 720p) war etwas kleiner bei schlechterer qualität. allerdings war meine ripbot version nicht aktuell (x265 v1.7). nach einem update war x265 auf v2.2 aktualisierst. wieder getestet, ergebnis noch schlechter :confused_alt::confused_alt:. selbst bei 10% mehr bitrate reicht die qualität von x265 noch nicht an x264 ran. zumindest sehe ich das so, vllt habe ich aber auch was an den augen ;):

vergleich.jpg

edit: schreibfehler gefunden. mit QF ist CQ gemeint (wie bin ich denn auf QF gekommen :confused_alt:)
 
Zuletzt bearbeitet:
nille02 schrieb:
Eine schöne Erklärung womit man welche Hardware nutzen kann wäre schon was.

Was willst denn da erklärt haben?

nille02 schrieb:
Ich compiliere mir recht aktuelle ffmpeg git Versionen direkt mit Quicksync und nvenc. Bei beiden hat der jeweilige Hersteller mitgewirkt um das zu ermöglichen. Nun, für AMD gibt es da nichts und man muss aber eingeschränkte Software zurückgreifen.

ffmpeg mit quicksync oder nvenc compilieren!? Nochmal in verständlich bitte. :confused_alt:
Ergänzung ()

habichtfreak schrieb:
als quelle diente h.264 - 4k - 25mbit

Ist das eine öffentliche Video Datei? Hast du da mal einen Link zu?
 
Gamefaq schrieb:
ffmpeg mit quicksync oder nvenc compilieren!? Nochmal in verständlich bitte. :confused_alt:

Die Funktionalität von ffmpeg ist sehr stark davon abhängig was für Optionen du beim compilieren (Den Quelltext der Anwendung in Programm umwandeln das du ausführen kannst) mit angibst.

ffmpeg könnte zum Beispiel kein H264 mit x264 encoden wenn man es nicht mit der Option --enable-libx264 compiliert. Oder im falle von Quicksync (--enable-libmfx ) und nvenc (--enable-nvenc ) sind. Als Benutzer braucht man sich meist damit auch nicht beschäftigen. Nur wenn man Sonderwünsche hat wird es nötig.

------------------------

habichtfreak hast du mal einen anderen hevc Encoder wie kvazaar getestet?
 
Ach so du arbeitest auf Kommandozeilen Basis mit dem Programm ohne eine GUI zu nutzen. Jedoch nennt sich das was du das Programm dann über die Kommandozeilen Befehle tun lässt encodieren nicht compilieren. Daher war ich jetzt verwirrt denn du Arbeitest ja hier jetzt nicht in Maschinensprache noch lässt du die einzelnen Bauteile von ffmpeg mittels eines externen Programms zu einer Funktionierenden Anwendung "kompilieren". ;)

Zu deinem AMD Problem kann ich nix sagen da ich eine nvidia Karte habe und auch das x265 Encodieren mittels nvenc mit zwei verschiedenen Programmen durchführen lasse. Dabei bestimmt das Quell Material welches Programm ich verwende da eines extrem schnell bei CRF encodieren ist und das andere wiederum beim 2Pass encodieren.
 
@Gamefaq:
nein, er meint, dass er den Sourcecode mit speziellen Einbindungen kompliert.
Das, was der allgemeine User nutzt, ist eine mit Standard-Optionen kompilierte Version.
Und dass ffmpeg aktuell nicht auf die API von AMD zugreifen kann.
Und dass das mit NVidia und Intel möglich ist.

Etwas genauer: ffmpeg encoded auf Softwareebene.
Um die speziellen Hardware-Features von Quicksync oder Nvidia zugreifen zu können, braucht ffmpeg eine Schnittstelle zur Hardware, das ist die sog. API.
Intel und NVidia haben für ein Öffnen der API gesorgt, so dass Drittanbieter-Programme drauf zugreifen können.
(Bei AMD ist es momentan noch eine Blackbox.)
Um diese API in Programmen wie ffmpeg nutzen zu können, muss sie aber während des kompilierens bekannt sein und der ffmpeg-Anteil mit kompiliert werden.
Dafür waren die benannten Kommandozeilen-Optionen.
 
Zuletzt bearbeitet:
Was gibt es da großartig zu wissen?
Und warum unbedingt über Hardware?

Einfach VLC an und gut ist.
H.265 ist mittlerweile sau-alt. (Fast 5 Jahre)

Keine Ahnung was ihr da auch mit den Encoder anstellt, bei 265 krieg ich je nach Video 50% Einsparung gegenüber 264 bei Optisch gleichbleibender Qualität. Hier dasselbe: ffmpeg hat ebenfalls x265. H.265 ist momentan das beste, dauert nur länger und ist immer noch nicht so populär wie x264.
 
MyNamesPitt schrieb:
Was gibt es da großartig zu wissen?
Und warum unbedingt über Hardware?
Weil es immer noch genug CPUs gibt, die nicht in der Lage sind h.265 schnell genug in Software zu dekodieren.

Einfach VLC an und gut ist.
Ne! Eben genau nicht! VLC (2.2.4) ist voll sche*** wenn es ums dekodieren von h.256 geht.
Mein Mediacenter hat eine rech betagte Core2 Duo CPU mit 3,5 GHz. Für Video reicht das völlig, nur leider nicht für h.265 in FullHD.
Allerdings steckt da eine GTX 750 TI drin, und die kann h.256 in Hardware (teilweise).

Nun ist VLC leider absolut nicht in der Lage h.265 in Hardware zu decodieren. Entspechent laufen die Videos da überhaupt nicht. In MPC HD laufen sie auf der gleichen Maschine aber einwandfrei.

Keine Ahnung was ihr da auch mit den Encoder anstellt, bei 265 krieg ich je nach Video 50% Einsparung gegenüber 264 bei Optisch gleichbleibender Qualität. Hier dasselbe: ffmpeg hat ebenfalls x265.
H.265 ist momentan das beste, dauert nur länger und ist immer noch nicht so populär wie x264.
Das verstehe ich in der Tat auch nicht. Da müssen die Settings falsch sein. Ich benutze immer handbrake und die Ergebnisse in h.265 sehen deutlich besser aus und sind kleiner als bei h.264
 
MyNamesPitt schrieb:
Und warum unbedingt über Hardware?

Versuch mal ein H265 Video mit 120Mbit auf einer Mittelklasse CPU Wiederzugeben. Ja selbst die Hälfte der Bitrate bringt die meisten CPUs beim Decoding schon ins schwitzen.

Hier bekommst man auch ein Testszene mit unterschiedlichen Auflösungen, Bitraten und Codecs http://jell.yfish.us/

Desweiten ist es eine Frage der Energieeffizienz. Selbst wenn deine CPU das in Software schafft ist der Energiebedarf ungleich höher verglichen mit einem Hardware Decoder.

-------------------

Danke Wishbringer. Die AMD API ist nutzbar, aber keiner hat es bisher dafür umgesetzt. Es reicht nun mal nicht nur eine API bereitzustellen. Die Hersteller müssen auch selber Aktiv werden um ihre Technologie an den Mann/Frau zu bringen (Intel und Nvidia tun das. Nvidia hat sogar einen Video Filter für ffmpeg geschrieben um das Bild direkt auf der GPU zu Scalieren. Leider ist der noch nicht in ffmpeg direkt enthalten).
Ich hatte mir damals MediaEspresso gekauft, weil man damit den Encoder der AMD GPUs nutzen konnte. Leider war das ein gewaltiger Fehlkauf über den ich mich noch heute ärgere. Die Software war leider mehr als schlecht.
 
habichtfreak schrieb:
wieder getestet, ergebnis noch schlechter :confused_alt::confused_alt:. selbst bei 10% mehr bitrate reicht die qualität von x265 noch nicht an x264 ran. zumindest sehe ich das so
Kannst du mal dein ffmpeg command zeigen?
 
Nvidia soll lieber mal einen Treiber für die gesicherte Wiedergabe von AACS 2.0 Inhalten wie Netflix 4k oder UHDs bereitstellen, damit man diese nicht nur auf Kaby Lake Plattformen nutzen kann. Die benötigte Hardware ist ja schon da. Gleiches gilt natürlich auch für AMD.
 
lejared schrieb:
Ne! Eben genau nicht! VLC (2.2.4) ist voll sche***


20pcf4M.png

nille02 schrieb:
Ja selbst die Hälfte der Bitrate bringt die meisten CPUs beim Decoding schon ins schwitzen.


54TJxLT.png


i5 2500k

---

Ja, also wie gesagt - keine Ahnung was ihr da fabriziert...
Holt euch mal nen PC aus diesem Jahrhundert und fummelt nicht an Codecs oder sonst wo herum.
VLC alleine spielt ALLES ab, vielleicht sollte ich dazu auch mal ein FAQ erstellen. ;)

sirwuffi schrieb:
Nvidia soll lieber mal einen Treiber für die gesicherte Wiedergabe von AACS 2.0 Inhalten.

Ich wette selbst das funktioniert auch problemlos im Firefox...
 
MyNamesPitt, benutzt nun mal ein 4k File von meinem Link. Und bedenke, deine CPU hängt da bei fast 30%, das ist eine menge fürs decoding.
 
Zuletzt bearbeitet:
nille02 schrieb:
MyNamesPitt, benutzt nun mal ein 4k File.
Von 4K war oben im Post nicht die Rede.
Normal das die CPU da einsackt - 4 Fache Last! ;)

Im Vergleich zu H.264 steigt die CPU-Last (bei 1K) nur sehr minimal an.
Ich kann mich nur wiederholen -> PC aus diesem Jahrhundert kaufen!

Meine CPU ist über 7 Jahre alt, übrigens. ^.^
 
Zurück
Oben