x265 und Ryzen 3900X nur 70% CPU-Last mit StaxRip

Es haeng auch von den Einstellungen und Filtern ab, wie stark eine CPU ausgelastet wird.
Und SMT hat auch bei Encoding einen Sinn. Am Ende sind bei SMT auch zusaetzlich Einheiten vorhanden, nur halt keine vollstaendigen Kerne.
Bei x264 habe ich deswegen auch regelmaeßig zwei Encodes parallel laufen, weil es schlichtweg etwas schneller geht, als sie nacheinander zu bearbeiten.
 
Kacke .. ich komme erst nächste Woche zum testen .. bis dahin halt nur theoretischer Schrott von mir. Sorry^^
 
@Scientist Keine Filter bei mir, ist mir ja alles klar. Mache das nicht seit gestern. 😉
 
SMT bzw. HT wurde ja explizit deswegen entwickelt, weil die komplette CPU selten in der Praxis vollstaendig ausgelastet wird und so durch verhaeltnismaeßig wenig Aufwand (zusaetzliche Transistoren/Chipflaeche) ein spuerbarer Leistungszuwachs erzielt werden kann.
Nun gut, wenn man nach dieser Seite geht, ist zumindest bei x265 preset "slow" der unterschied gering und damit ein deutlicher unterscheid zu x264.
Vielleicht liegt hier dann der Flaschenhals an einer anderen Stelle ...
Weitere Tests habe ich leider nicht gefunden.
 
Theorie ist bekannt, Blender profitiert ja auch massiv, Video encoding mit x26* halt nicht.

Gerade mal mit Handbrake getestet und dort ist die Auslastung etwas höher, so bei 80%. Allerdings habe ich mit Handbrake nicht so die Erfahrung und kann das daher nicht wirklich bewerten. Letztlich interessiert es mich auch nicht, ich brauche 100% und die gab es bisher immer mit Staxrip.
 
Zuletzt bearbeitet:
x264 ja (eigene Erfahrung, verlinkter Test #24), x265 moeglicherweise weniger (keine eigene Erfahrung).
 
Und meine eigene, 12 Monatige Erfahrung mit Ryzen ist, dass es so gut wie keinen Unterschied macht, Messungenauigkeiten. Bitte also mal selbst einen aktuellen Test machen oder auf das eigentliche Thema dieses threads konzentrieren. Ist es ein Problem meines Systems oder tatsächlich normal, die geringe Auslastung? Das kann auch jeder mit einem Ryzen selbst testen...
Ergänzung ()

Habe jetzt mal ein 1080p statt eines 720p Urlaubsvideos drauf geschmissen und die Last ist tatsächlich etwas höher, so bei 80%, was mir immer noch zu wenig ist und in 4K wandle ich nichts um.

Das lief mit dem alten Ryzen deutlich besser und so scheint das Upgrade gänzlich nutzlos zu sein. 😟
 
Zuletzt bearbeitet:
Ist zwar kein Filter, aber skalieren ist ein zusaetzlicher Arbeitsschritt und koennte entsprechend der Flaschenhals sein ...
Wie ist denn die Auslastung, wenn du nicht skalierst?
 
Zuletzt bearbeitet:
Ist normal. Du kannst threotisch zwei Instanzen starten damit die CPU 100% ausgelastet wird. Erfahrungsgemäß (ca. 10TB privates Videomaterial in den letzten Monaten) hast du dann aber immer wieder Segfaults von x265 die dann vorzeitig abbrechen.
Ist unter Linux ebenso.

Kannst mit den Numa-pools tweaken, ich encodiere aktuell hiermit:
Code:
sao=0
strong-intra-smoothing=0
rect=0
colorprim=bt709
transfer=bt709
colormatrix=bt709
range=limited
frame-threads=4
numa-pools=32
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bob.Dig und Scientist
Scientist schrieb:
Ist zwar kein Filter, aber skalieren ist ein zusaetzlicher Arbeitsschritt und koennte entsprechend der Flaschenhals sein ...
Ich habe nichts skaliert.
Ergänzung ()

GregoryH schrieb:
Also hatte ich vorher nur Glück, dass ich immer 100% Auslastung hatte mit meinem 2700X? Zwei Instanzen bedeutet zwei Encodes? Na, soviel hab ich nicht umzuwandeln.
 
Okay, hier fand genau dieselbe Diskussion statt: Link
12 Thread sind aktuell scheinbar einfach zu viel, um diese voll auszulasten.
Hier wurde auch nur der Tipp mit numa-pools gegeben.
 
  • Gefällt mir
Reaktionen: Bob.Dig
Also quasi normal. Danke, ich konnte es nicht glauben.

Demnächst nur noch NVENC. 😊
 
Eventuell wäre es ja mal interessant wenn Du mit den Qualitäts-Einstellungen spielst, so dass der Himmel irgendwann Artefaktfrei wird, und Du dann die Erkenntnis daraus mit uns teilst?
 
Bob.Dig schrieb:
Demnächst nur noch NVENC. 😊

Dann verabschiede dich aber von der Quali. Wenn du sowieso mit CRF 25/26 encodieren wolltest und auch mit 50%+ mehr Dateigröße zufrieden bist, ist das natürlich eine Alternative.
 
  • Gefällt mir
Reaktionen: Haldi
HisN schrieb:
Eventuell wäre es ja mal interessant wenn Du mit den Qualitäts-Einstellungen spielst, so dass der Himmel irgendwann Artefaktfrei wird, und Du dann die Erkenntnis daraus mit uns teilst?
Hab das File nicht mehr da und ich hab nicht alleine getestet. Es wurde aber auch nichts groß verstellt sondern mit einer festen Dateigröße die beiden encoder verglichen. Auch den AMD-Encoder haben wir getestet, der war aber weit abgeschlagen, zwischen Pascal und Turing konnte ich dann keinen Unterschied mehr feststellen. Der Thread muss hier noch irgendwo sein. Wenn es dich wirklich interessiert und du selbst testen und im Forum vergleichen möchtest, würde ich mir mehr Mühe geben bei der Suche.
GregoryH schrieb:
Dann verabschiede dich aber von der Quali. Wenn du sowieso mit CRF 25/26 encodieren wolltest und auch mit 50%+ mehr Dateigröße zufrieden bist, ist das natürlich eine Alternative.
Also ich bin nicht der Oberguru was das Thema betrifft, aber für mich sehen die Encodes mit NVENC wirklich nicht schlecht aus und sry für die PM, hab diesen Beitrag erst später gelesen. 😉
 
Für mich passt die Qualität, ich muss nicht optimieren. Ich dachte mir eher ihr würdet es machen, da ihr es ja scheinbar als sehr wichtig erachtet. Nur deshalb die Nachfrage. Und deshalb auch keine Suche. Bin ja sowieso nur reingestolpert um scheinbar Offensichtliches zu erzählen :-)
 
  • Gefällt mir
Reaktionen: spfccmtftt89 und Bob.Dig
GregoryH schrieb:
Dann verabschiede dich aber von der Quali. Wenn du sowieso mit CRF 25/26 encodieren wolltest und auch mit 50%+ mehr Dateigröße zufrieden bist, ist das natürlich eine Alternative.

Source 4k HDR 3min17@1.2Gb
Samsung and redbull see the unexpected

CPU only haswell3ghz
t enc = 2h 56min
size = 130MB
Power package = 50Wh

StaxRip 182 Nvidia HDR h265
GTX 1660 non supra
t enc = 7min 47s (13fps)
size = 274MB@12MBits
Power package GPU/CPU = 20Wh+40Wh

--cqp 30:30:30 --codec h265 --preset quality --profile main10 --tier high --level 5.1 --output-depth 10 --vpp-edgelevel --vpp-unsharp --vpp-select-every 2 --cu-min 32 --cu-max 64 --weightp --bframes 5 --ref 5 --gop-len 12 -- lookahead 32 --qp-max 30 --qp-min 19 --aq --aq- temporal --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" -- colormatrix bt2020nc --colormatrix bt2020 --transfer smpte2084 --aud --chromaloc 2 --mv-precision q-pel --cabac

[Parsed_psnr_4 @ 07cc8d40] psnr y:14.648594 u:28.781 v:32.439401 average:16.349934 min:11.341175 max:56.471403

Selbst mit psnr average:46.xxxx erzielt die GPU sehr gute Resultate (5Mbit, 2 Pass, H265 nvenc)

via Smartphone

Source sharp parasols 4k sdr
https://jpst.it/1Zew3
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: HisN
Staxrip.jpg
 
  • Gefällt mir
Reaktionen: Bob.Dig
Danke @HisN
😟
PS: Wie sieht das bei Dir eigentlich bei x264 aus? Vermute so wie bei mir.
Capture2.PNG

x265 macht es einem wirklich nicht einfach es zu mögen.
 
HisN schrieb:
Wiese nutzt Du nicht den Hardware-Encoder in der Graka^^

h265 scheint nicht endlos über Kerne zu skalieren. h264 scheint da besser zu sein.
Am Ende können wir Dir nicht helfen, sondern nur der Programmierer des Encoders, bzw. Du bei der Auswahl des Encoders.
Kann man auch GPU und CPU kombinieren - also das Sys. voll auslasten, mit dem, was es zu bieten hat?


Und was ist der Unterschied von Staxrip zu diesem x265-Bench? https://www.xin.at/x265/
 
Zurück
Oben