AMD Epyc 7742: 79 Fps im 8K-HEVC-Material-Echtzeit-Encoding

[hanfi104]

Eben nicht...

Wenn du sehr "zahme" Settings einstellst sind die für den Encoder viel schlechter parallelisierbar auf zig Threads als bei qualitativ sehr "harten" Einstellungen. Oder anders gesagt beim preset "very fast" wird der 3900X sehr viel näher an den fetten Epyc rankommen (da dieser seine ganzen Kerne nicht ausspielen kann) als beim preset "slow".

Natürlich ist die Größenordnung etwa abschätzbar, es kann aber Szenarien geben wo ein 3900X halb so schnell ist und andere wo er nur 10% der Performance bietet.

Natürlich wird das Setting genommen, welches auch immer die in diesem Test hier genommen wurde. Das meinte ich mit unerheblich. Was sie genommen haben ist natürlich unbekannt, doch wenn dann müsste man den 3900X natürlich mit selben Setting testen....
Und selbst bei schlecht parallelisierbaren Settings, in 8K wirst du wohl immer 64 Kerne ausreichend füttern können. Der Sprung von HD auf FHD ist ja schon enorm, was Kernauslastung betrifft. UHD ist da noch eine andere Klasse, UHD2 noch eine Steigerung
Ich kann die CPU mit 8K Material nicht auslasten, der RAM ist zu lahm und oder zu klein. In Slow sprengt es mir die 32 GB (bzw. 20GB, 12GB sind schon vorher belegt), in Very Fast wabelt er zwischen 100% und 0%, wird wohl nicht schnell genug gefüttert.
Source ist ein 8K Youtubeclip 8192x4096
"First 8K Video from Space"

 

[Mephisto_xD]

Eben nicht...

Wenn du sehr "zahme" Settings einstellst sind die für den Encoder viel schlechter parallelisierbar auf zig Threads als bei qualitativ sehr "harten" Einstellungen. Oder anders gesagt beim preset "very fast" wird der 3900X sehr viel näher an den fetten Epyc rankommen (da dieser seine ganzen Kerne nicht ausspielen kann) als beim preset "slow".

Naja. Das ist aber nur bei Live Content ein Problem. Beim Transcodieren/Encoden von bereits existierenden Videos wird ein guter Encoder einfach an mehreren Keyframes gleichzeitig arbeiten um mehr Kerne auszulasten. So lässt sich das Problem praktisch beliebig gut parallelisieren, auch bei zahmen Settings. Zur Not bekommt halt jeder Kern einen eigenen Keyframe.

Beim Livestreaming geht das natürlich nur beschränkt, bzw. nur wenn man dafür hohe Latenzen in Kauf nimmt.

 

[empy]

Mach dich doch nicht immer selbst so lächerlich.

Es geht hier nicht um eine Desktop-CPU sondern um Epyc!

Noch einer, der ganz offensichtlich nicht gelesen hat, worauf sich das bezieht. Wenn es um Epyc geht, warum wird dann hier über Intels Alltagsszenariovergleich hergezogen? Ich hab damit nicht angefangen.

Ist doch genau das was Intel gewollt hat, die Leute sind komplett auf das Konditioniert, was von ihnen kommt. Da ist es egal was in der wirklichen Welt vor geht.

Selber. "So seht, er hat eine Lanze für Intel gebrochen, steinigt ihn!" Jehova, Jehova...

Wenn man sich die Anwendungen ansieht die viele Leute benutzen und die nennenswert CPU-Power brauchen (also nicht einen Brief schreiben und per Mail schicken was Intel anführt als real world) gehört CPU-Videorendering/encodieren tatsächlich zu sehr häufig genutzten Anwendungen. YouTube, Twitch und so weiter sei Dank.

Das habe ich nie abgestritten. Ich habe ja auch schon erwähnt, dass ich von dem Intelmarketing nicht unbedingt viel halte, aber halt finde, dass es mit Epyc überhaupt nichts zu tun hat.

 

[Incredible Alk]

Ich kann die CPU mit 8K Material nicht auslasten, der RAM ist zu lahm und oder zu klein. In Slow sprengt es mir die 32 GB (bzw. 20GB, 12GB sind schon vorher belegt), in Very Fast wabelt er zwischen 100% und 0%, wird wohl nicht schnell genug gefüttert.

Fast^^
Bei sehr hohen Auflösungen ist RAM-Menge tatsächlich ein Problem je nach Setting. Wenn man da große motionestimation ranges wählt (was bei "slow" beispielsweise passiert) frisst das zig GB an RAM.
Zu langsam ist aber nicht das Problem, generell ist Bandbreite zum RAM nebensächlich beim HEVC-encoding. Der Grund warum bei schnellen Presets die CPU-Last manchmal stark einbricht ist, dass viele Algorithmen der Encodierung auf gegenseitige Rechenergebnisse angewiesen sind um weitermachen zu können (wenn beispielsweise Frame n+1 mit Informationen encodiert werden die aus frame n stammen). Je geringer der Rechenaufwand pro Frame ist (also je zahmer das Setting) desto großer wird die Chance, dass der Encoder weiter vorauseilen kann (etwa zum frame n+3) aber hier abwarten muss bis der Frame n fertig berechnet ist - dann siehste nen Auslastungsdrop.

Bei kostenlosen encodern gibts auch mal das Problem, dass der decodierer der aus dem ja bereits komprimierten Quellmaterial intern RAW-Material erzeugt das dann encodiert wird keine Hardwarebeschleunigung nutzt und/oder nur singlethreaded ist. Dann kanns passieren, dass eine sehr schnelle Vielkern-CPU Material schneller encodieren kann als das singlethread-Ding das Quellmaterial decodieren/bereitstellen kann... dann haste auch ständig Auslastungsdrops. Passiert beispielsweise sehr gerne wenn man Rauschfilter verwendet die der decodierer stemmen muss und dann gar nicht mehr nachkommt.

Naja. Das ist aber nur bei Live Content ein Problem. Beim Transcodieren/Encoden von bereits existierenden Videos wird ein guter Encoder einfach an mehreren Keyframes gleichzeitig arbeiten um mehr Kerne auszulasten. So lässt sich das Problem praktisch beliebig gut parallelisieren, auch bei zahmen Settings.

Ja, das gibts. Auch andere MT-optimierte Verfahren wie wavefront parallel processing als Beispiel. Aber wie du schon sagst bei Streams kannste das nicht verwenden es sei denn ein, zwei Minuten Lag sind ok.