News H.265/HEVC Main 10 Decode Support für AMD Stoney Ridge APU

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Vor einigen Tagen veröffentlichten AMD-Entwickler neuen Code für den Driver-Stack von UVD (Unified Video Decoder) des Open-Source-Treibers RadeonSI, der die Unterstützung für H.265/HEVC Main 10 Decode ergänzt. H.265, auch HEVC genannt, ist der aktuelle Codec, der z.B. für 4K-Videostreaming verwandt wird. Mit Hardware-Support dafür lässt sich die Hauptlast bei der Wiedergabe von derartigem Videomaterial auf die schnelle GPU auslagern.
(…)

» Artikel lesen
 
.......nur für Stoney Ridge vorgesehen. Das ist die Low-Power-Variante von Bristol Ridge, also den Excavator v2 APUs. Bristol Ridge ist die kurz vor der Veröffentlichung stehende Desktop-APU für den Sockel AM4, auf dem später auch Zen-CPUs (Summit Ridge) und Zen-basierende APUs (Raven Ridge) erscheinen werden. Für die aktuelle Excavator-Implementierung Carrizo ist der Patch offenbar nicht geeignet, was nahelegt, dass Stoney Ridge einen abermals verbessertes UVD (Unified Video Decoder) erhalten wird.

Aha, also wieder nichts für den normalen Desktop. Ich möchte endlich ein HTPC zusammenbauen, welche eine APU mit HEVC-Unterstützung bietet. Soll ich noch bis zur Rente warten???
Wahrscheinlich wird es nun doch ein HTPC mit Intel Skylake-APU. Verstehe nicht, warum AMD dies nicht für den Desktop-Markt anbieten möchte. 8-(
 
Ist x265 besser von der Qualität als x264? Gibt es da vollen AMD Support bzw. Herstellerunabhängig, leider kann weder Megui noch was anderes was ich kenne die AMD GPU/s nutzen beim Encoding, immer nur Nievidia :(

mfg
 
Aha, also wieder nichts für den normalen Desktop. Ich möchte endlich ein HTPC zusammenbauen, welche eine APU mit HEVC-Unterstützung bietet. Soll ich noch bis zur Rente warten???
Wahrscheinlich wird es nun doch ein HTPC mit Intel Skylake-APU. Verstehe nicht, warum AMD dies nicht für den Desktop-Markt anbieten möchte. 8-(

Und warum hast dann noch keinen Kaveri?!
Zitat:
Des Weiteren arbeitet ein spezialisierter Video-Encoder namens VCE2 im Kaveri. Unter anderem kann er bei H.264 nun auch B-Frames in Hardware beschleunigen. Der UVD ist beim Decodieren von H.264-Material nun fehlertoleranter und dank OpenCL ist auch eine H.265- oder HEVC-Beschleunigung möglich, die den Kaveri einen HEVC-4k-Datenstrom mit 30 Fps stemmen lässt.

http://www.pcgameshardware.de/A10-7...oller-GCN-TrueAudio-und-HSA-erklaert-1105047/
 
@Bond007
Bond007 schrieb:
Soll ich noch bis zur Rente warten
huh.gif
[...]
Verstehe nicht, warum AMD dies nicht für den Desktop-Markt anbieten möchte. 8-(
Bristol Ridge ist die kurz vor der Veröffentlichung stehende Desktop-APU für den Sockel AM4


C4rp3di3m schrieb:
Ist x265 besser von der Qualität als x264?
Ich habe noch keinen Unterschied erkennen können, die Dateien sind bei etwa gleicher Optik aber kleiner, wenn auch nicht viel. Nur das Encoding kann schon mal über 7 Stunden für ein halbstündiges Video dauern. Wobei Handbrake für x264 bei mir immer 6+ Kerne nutzt, für x265 anscheinend nie (oder höchst selten) mehr als 4.
 
@Bond007





Ich habe noch keinen Unterschied erkennen können, die Dateien sind bei etwa gleicher Optik aber kleiner, wenn auch nicht viel. Nur das Encoding kann schon mal über 7 Stunden für ein halbstündiges Video dauern. Wobei Handbrake für x264 bei mir immer 6+ Kerne nutzt, für x265 anscheinend nie (oder höchst selten) mehr als 4.

x265 hat noch blurring und ghosting Probleme, ist aber ansonsten durchaus vergleichbar.
Die Dateien sind ca. 30% kleiner bei selbiger Qualität, die Settings muss man sich halt zusammen frickeln (Ne Menge Testerei).
Handbrake?? :]
Der x265 cli Encoder (GCC 5.3 BDVer2) erreicht auf einem FX 8350 50%- 75% Echtzeit (Nein, nicht in Ultrafast).
Kaveri hat mit HEVC Wiedergabe null Probleme.
 
https://www.google.de/search?q=Kaveri+HEVC&gws_rd=ssl

So nun sage mir bitte wo Kaveri nativ HEVC unterstützt.

Mit einem Beweis in Linkform kann ich leider auch nicht dienen, aber die Prozessorauslastung ist beim Abspielen mit MPC-BE bei x265 Material ganauso wie mit x264.
Da ist also "etwas" *buck* , sonst wäre die Auslastung wesentlich höher.

Der Qualitätsvergleich von Codecs ist natürlich schwierig, weil sehr subjektiv.
Zumal gerade bei x264 vs x265 auch die Bitrateneinstellungen nicht identisch sind.
D.h. crf17 x264 != crf17 x265.
Um die selbe Qualität zu erhalten muss man den crf Wert von x264 für x265 ca. um drei bis fünf erhöhen.
Hier mal ein Vergleich von Orginal zu x264 zu x265.
Die Abwesenheit des Grainy-Snow-Whatever in den transcodierten Teilen sind nicht teil des Codecs, sondern werden per avs script gemacht.
Wenn man das mag, so kann man den Schneesturm 1:1 so behalten.
Dateigrössen: Orginal 26Gig, x264 16Gig, x265 9Gig
Comparison.jpg
 
Zuletzt bearbeitet:
Es gibt derzeit nichts was HEVC 10bit 4:4:4 ohne Software vernünftig dekodieren kann. Und selbst wenn, sind nur evt. 30Hz drinnen was bei einem 60Hz Video nicht ausreichend ist.

Deshalb ist es wichtig, dass man das in eine kommende UVD Einheit einbaut.

Schade nur, dass AMD keine neuen Masken für den Desktop macht wo solch eine UVD drinnen ist.
Hoffen wir es, dass diese wenigstens in die Polaris Karten der Billigklasse rein kommt.

HEVC kann deutlich besser sein als H264 bei gleichzeitig geringerer Datenrate und wird mit Main Profile 10 auch der Standard der HD-BluRays.
Dh. ohne diesen Codec wird man das auf keiner Graka wiedergeben können, es sei denn man hat nen 32Kerner oder eine 300W Graka im Hintergrund arbeiten, was für einen HTPC ungeeignet ist.

@Carpediem:
madvr nutzt die AMD Graka via OpenCL (was ich selbst mache)
 
bei der kleinen APU Stoney Ridge ist es aber wohl vordringlicher, weil die wahrscheinlich schneller auf dem Zahnfleisch ginge als ein voller Kaveri oder Carrizo, der ja einfach mehr Einheiten hat, um auch ohne ASIC-Routinen das Video ausreichend gut abspielen zu können. Und irgendwo muß man ja anfangen. Jedenfalls ist ein besserer UVD für sich alleine nichts, weswegen man einen neuen Chip auflegt.
 
Bisher spricht nichts dagegen, Stoney wie auch Bristol für AM4 oder FM2+ zu bringen - mit FP4 gibt's beide neben Carrizo
 
@tomturbo

Aha okay, ich nutze am liebsten Megui/AVS/DirectShow zum Encode in x264.
Werde mir das Tool von dir mal ansehen, macht aber nur Sinn wenn ich dort auch meine ganzen Einstellungen verwenden kann.
Bringt der GPU Encode viel mehr Leistung, Qualität bleibt aber gleich oder?

mfg
 
@tomturbo

Aha okay, ich nutze am liebsten Megui/AVS/DirectShow zum Encode in x264.
Werde mir das Tool von dir mal ansehen, macht aber nur Sinn wenn ich dort auch meine ganzen Einstellungen verwenden kann.
Bringt der GPU Encode viel mehr Leistung, Qualität bleibt aber gleich oder?

mfg

madVR ist ein Wiedergabefilter, kein Encoder.
 
Sorry ich habe das mit dem Encoder falsch gelesen/interpretiert.
madVR ist natürlich kein Encoder.
 
Atombossler schrieb:
HandBrake hat seit einigen Versionen x265 eingebaut. Was gibt es dagegen zu sagen?

FX 8350 50%- 75% Echtzeit (Nein, nicht in Ultrafast)
klingt für mich nach Auslastung von 4 bis 6 Kernen. Was du mit "Echtzeit" und "Ultrafast" meinst, ist mir gerade nicht bewusst.
 
HandBrake hat seit einigen Versionen x265 eingebaut. Was gibt es dagegen zu sagen?


klingt für mich nach Auslastung von 4 bis 6 Kernen. Was du mit "Echtzeit" und "Ultrafast" meinst, ist mir gerade nicht bewusst.

Na, wie der Name schon sagt: "Handbrake" -> fahren mit angezogener Handbremse. *lol*

Sicher ist x265 integriert, in der höchst aktuellen 1.5er Version ... :o (wir sind aktuell bei x265-1.9.088 ).

Echtzeit. (Wikipedia)
Definition
Die Definition der inzwischen durch DIN ISO/IEC 2382 abgelösten Norm DIN 44300 (Informationsverarbeitung), Teil 9 (Verarbeitungsabläufe) lautete:

„Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.“[1]
Durch die Hardware und Software muss sichergestellt werden, dass keine Verzögerungen auftreten, welche die Einhaltung dieser Bedingung verhindern könnten. Die Verarbeitung der Daten muss dabei nicht besonders schnell erfolgen, sie muss nur garantiert schnell genug für die jeweilige Anwendung erfolgen.

Bei Encoding bedeutet das mindestens: Encoding (fps) = Wiedergabe (fps)

Ultrafast ist ein x265 Preset und ist in der Regel für Capturing empfohlen, weil
damit in aller Regel die entsprechenden Geschwindigkeiten erreicht werden um Framedrops zu verhindern.

Das ist aber zum Encoding qualitativ nicht zu gebrauchen.
Das Schlechteste, was man da nehmen sollte, ist fast als Basis zum customizing (besser medium wegen b-adapt und rd-level etc.).

Auslastung liegt bei 100% auf allen Acht Kernen (und es sind wirklich 100%, da selbst die Uhr partiell stehenbleibt etc.).

Meine Angabe von 50%-75% Echtzeit bedeutet also bei einem zu encodierenden Stream mit der Target-Framerate von 24fps eine
Geschwindigkeit von ca. 12-19fps, je nach Szenenkomplexität (und zwar mit allen Bildfiltern mittels Avisynth/Vapoursynth).
 
Zuletzt bearbeitet:
Na, wie der Name schon sagt: "Handbrake" -> fahren mit angezogener Handbremse. *lol*
Sicher ist x265 integriert, in der höchst aktuellen 1.5er Version ... :o (wir sind aktuell bei x265-1.9.088 ).

Interessant. Welches Tool zum encoden/decoden ist denn am besten, wenn man Wert auf aktuelle Bibliotheken und beste Unterstützung der Hardware legt?
 
Unter Linux verwendet handbrake alle 8 Kerne meines FXs.
 
Interessant. Welches Tool zum encoden/decoden ist denn am besten, wenn man Wert auf aktuelle Bibliotheken und beste Unterstützung der Hardware legt?

Wieso Tool?
Nimm halt einfach den x265 cli Encoder (am besten Eigenkompilat oder die entsprechende .exe mit der Arch-Optimierung).
Da braucht es kein Tool, wozu auch?
 
Zurück
Oben Unten