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

43
News Andreas Link Als bevorzugte Quelle auf Google hinzufügen
Beispiel der Bandbreiten-Reduktion für Streaming-Dienste.
Quelle: Beamr

Der Software-Anbieter Beamr Imaging nutzt einen AMDEpyc 7742, um 8K-Videomaterial in HDR mit HEVC in Echtzeit zu Encodieren. Unter Nutzung aller 64 Kerne und 128 Threads der CPU schafft das System 79 Fps.

UHD hat sich bislang noch nicht wirklich durchgesetzt, da wird schon fleißig an der nächsten Generation gearbeitet. UHD 2 oder auch gerne 8K stellt dabei aber noch das eine oder andere Problem dar, denn das Videomaterial muss natürlich auch verarbeitet werden. Beamr Imaging hat dazu nun den ersten Echtzeit-Encoder für 8K-HEVC-Material bereitgestellt. Die Software braucht ein bisschen Leistung und die kommt von einem AMD Epyc 7742.

Der Epyc 7742 ist ausgestattet mit 64 Kernen, 128 Threads und 256 MiByte L3-Cache. Er taktet mit 2,25 GHz Basis- und 3,40 GHz Boost-Takt und kann auch paarweise verwendet werden. Die TDP liegt bei 225 Watt. Weitere Features sind 128 PCI-Express Lanes im Format 4.0 und DDR4-3200 EEC an acht Kanälen. Das reicht nicht nur für den Cinebench-Weltrekord, sondern auch für 79 Bilder pro Sekunde beim Echtzeit-Handling von 8K/10-Bit-Videomaterial.

Die Software kann natürlich für Broadcasting eingesetzt werden, aber auch für Streaming nicht nur von Filmen und Serien, sondern auch für Spiele. Wenn man natürlich bedenkt, dass die CPU alleine für bald 8.000 Euro den Besitzer wechselt, sollte man nicht mit einem großflächigen Einsatz rechnen. Denkbar sind solche Systeme etwa bei Sport-Live-Übertragungen. Eines der ersten großen Events sind die Olympischen Sommerspiele 2020 in Tokyo.

Passend zum Thema: Zen 2: AMD zeigt Epyc mit 9 Dies - ca. 1.000 mm² Silizium

In der Praxis ist das alles aber nach wie vor im Experimentalstadium, denn die gesamte Kette muss natürlich geschlossen sein. Das beginnt bei der Videoaufnahme in UHD2/8K und geht über die Verarbeitung des Materials und den Transport, etwa über eine ausreichend schnelle Internetleitung, bis hin zum Empfangsgerät, von denen in Deutschland nicht so wahnsinnig viele verfügbar sind. Wirklich lieferbar sind Geräte der Reihe Samsung Q900/Q050 und Sharp Aquos 500E. Geräte von Sony und LG sind nicht lieferbar. Die Preise starten bei noch halbwegs überschaubaren 2.400 Euro - explodieren aber rasant.

Quelle: Pressemitteilung

43
    • Kommentare (43)

      Zur Diskussion im Forum
      • Von Incredible Alk Flüssigstickstoff-Guru (m/w)
        Zitat von hanfi104
        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.

        Zitat von Mephisto_xD
        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.
      • Von Incredible Alk Flüssigstickstoff-Guru (m/w)
        Zitat von hanfi104
        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.

        Zitat von Mephisto_xD
        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.
      • Von empy Lötkolbengott/-göttin
        Zitat von Tech_Blogger
        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.

        Zitat von boedefelt
        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...

        Zitat von Incredible Alk
        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.
      • Von Mephisto_xD BIOS-Overclocker(in)
        Zitat von Incredible Alk
        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.
      • Von hanfi104 Volt-Modder(in)
        Zitat von Incredible Alk
        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"
      • Von Technologie_Texter BIOS-Overclocker(in)
        Danke für die Erklärung!
      Direkt zum Diskussionsende
  • Print / Abo
    Apps
    PCGH Magazin 08/2026 PC Games 07/2026 play5 08/2026 N-Zone 07/2026 Linux Magazin 07/2026 LinuxUser 07/2026 Raspberry Pi Geek 07/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk