Mein neuster Hardwarekauf

Ist ja keine Religion. Ich habe beides und objektiv ist der halt für die genannte Aufgabe ein absolutes Arbeitstier.
Transcoding geht auf meinem 265k quasi gleich schnell wie mit dem 9950X + RTX5070ti. Der Unterschied ist halt, dass der 265k dafür nicht einmal ein Zehntel des Stroms braucht.
Wäre DDR5 aktuell nicht so teuer, hätte ich mir schon längst noch einen 270k geschnappt - der ist nämlich was P/L anbelangt aktuell das beste Stück Silizium, das man kaufen kann.

Du arbeitest halt mit der Graka, das mache ich nicht, da ich nur eine RTX 3060 habe ...

Das ist ja der Punkt: Die iGPU von Intel ist bzgl. Qualitätsergebnis erstklassig und in der CPU halt einfach verbaut.
CPU Encoding verbrennt viel zu viel Power und ist ehlends langsam. Die iGPU im 265k rechnet beispielsweise einen 1080p x265 Stream auf höchster Qualität mit >= 300 Bilder pro Sekunde.
In AV1 ähnliches Spiel. Was meinst, warum ich den Server hab alle Filme in AV1 Umkodieren lassen? Das war in wenigen Tagen erledigt und hat der Speicherplatzverbrauch grob halbiert. Das geht halt irrsinnig schnell damit.

Du bist halt Profi und ich gebe nur Geld aus

Nee, nicht wirklich. Ich spiele damit nur rum und habe verglichen. Bis runter auf Einzelbild-Vergleiche.
Die Intel GPU macht einfach das beste Bild. Vom nativen CPU-Encode nicht zu unterscheiden. Da zeigen sich nur Unterschiede, wenn man sehr geringe Bitraten nimmt. Dann hat CPU Encode leichte Vorteile, direkt dahinter kommt die Intel GPU, mit etwas Abstand Nvidia und abgeschlagen AMD (iGPU). Die aktuellen RX 9000 GPUs (habe ich auch im Server) sind ziemlich gleich auf mit Nvidia bzgl. Encoding-Qualität - da haben sie echt nen Sprung gemacht.
Einfache Spielerei-Ergebnisse mit der vorhandenen Hardware.
Ich Encode gar nichts mehr auf der CPU. Selbst eine RTX3060 kann das schneller, als der 9950X. Absolut episch läuft aber einfach Intel QuickSync...

Kannst du mal dein Profil für 1080p x265 zur Verfügung stellen?
Ich habe auch schon viel experimentiert, aber bisher hatte mich noch kein GPU-Encoding umgehauen, das war qualitativ immer schlechter als CPU-Encoding.

Allerdings kann ich nur auf meine iGPU in der Core i5-10400 CPU zurückgreifen.

Überhaupt nichts besonderes.
Encoder: H.265 10-bit (Intel QSV)
Konstante bildfrequenz
Fabpalette: Wie Quelle
Konstante Qualität: 22 (oder auf welche Targetgröße man hinaus will)
Encodereinstellungen -> Voreinstellung: Quality
Rest Default

Nicht mit "Mittlere Bitrate" arbeiten. Ist Mist. Zwar deterministisch was die Dateigröße angeht, nur funktioniert das schlicht niemals hinreichend gut ohne 2-pass Encoding (was mit GPU Encoding nicht geht).

@MrHonk
Nutze bei GPU Encoding (nichts anderes) bei mir und Handbrake die average bitrate, zudem "preanalysis=1:vbaq=1:bframes=3:b_pyramid=1" als Extra-Parameter. Was laut ChatGPT bei Intel auf "b-pyramid=1:gop-ref-dist=4" hinauslaufen soll. Beim euqivalent für "Preanalysis" fängt der an Sachen zu fragen, die etwas sehr spezifisch sind.

Bei Full-HD als Zielformat hatte der selbst bei der ollen 6600XT ne Framerate um etwa 300 FPS. Da streite ich nicht um 200-300 kbps bei der Bitrate, wo ich noch etwas Größe gegen Qualität tauschen kann.

Hmm, irgendwas mache ich falsch. Habe heute VisionQuest S01E05 von h264 nach h265 umwandeln lassen. Das Original ist 1,82 GB groß.

H.265 10-bit (Intel QSV), konstante Bildrate, Quality 16 (lies sich nicht ändern), Farbpalette wie Quelle = 1,76 GB
H.265 10-bit (Intel QSV), variable Bildrate, Quality16 (lies sich nicht ändern), Farbpalette wie Quelle = 1,52 GB
H.265 (x265 - mit CPU encodiert), variable Bildrate, Quality 22, Farbpalette wie Quelle = 0,78 GB

Wäre der Größenunterschied deutlich geringer, würde ich GPU-encoding wirklich in Betracht ziehen, aber so lohnt sich die Umrechnung mit der GPU nicht für mich.

Das geht so nicht. Der Quality-Factor ist eine Implementierungsabhängige Größe.
Den Qualyfactor kann man nicht mit unterschiedlichen Encoder-Implementierungen vergleichen. Ein Q von 20 ist in NVENC etwas anderes als in QSV oder eben CPU-Encode.
Zumal mich irritiert, warum sich 16 (bessere Quali) nicht ändern lässt!?

Hat mich auch gewundert, aber ich konnte das Preset vorher auch nicht nutzen. Ich habe Hndbrake als Docker unter Unraid installiert und habe für die Umstellung die iGPU an den Docker durchgereicht.

Jagut, da weiß ich auch nicht. Ich nutz das auf nem Windows-Server oder halt Windows-Desktop.
Was da bei dir jetzt für Probleme sind, kann ich nicht beurteilen. Das ist bestimmt wieder so ein Limurx-Frickel-Problem.

Ich musste dafür jetzt 20 Minuten warten, naja... CPU halt, aber hier mal ein Vergleich (wie gesagt Q ist nicht identisch, zwischen x265 und QSV aber relativ ähnlich, bzw. nicht so weit auseinander):
QSV Q:24 -> 355MB
x265 Q:24 -> 379MB

Auf der CPU habe ich aber nur in "slow" gerechnet, weil die 3 Stufen noch darüber sonst den zeitlichen Rahmen gesprengt hätten.
Qualitativ ist der QSV-Encode hier ganz minimal schlechter, dafür aber halt auch kleiner. Der Versuch es auf die selbe Dateigröße zu bringen führt dann zu einem identischen Ergebnis (QSV Encode liegt dann bei 380MB, genau auf 379 bekomme ich es nicht).

Das wäre ja ein erfreuliches Ergebnis, wenn ich das hier auch so umgesetzt bekäme. Dann werde ich mal einen genaueren Blick auf den Docker werfen müssen.
Danke für deine Ergebnisse und das Testen.

🫣
War leider noch eine SSD nötig. Musste PS5 Games komprimieren.
Samsung 990 PCIe 4.0x4 NVMe M.2
Die steckt jetzt in nem USB Case.

Hatte ja erst die interne M.2 der PS5 gekauft.
WD_Black SN850P mit Heatsink

Da ich im Urlaub ja komplett flach lag, gab's da noch Euronen. Trotzdem schweineteuer.

@MrHonk Vielleicht habe ich es übersehen, aber welches Programm verwendest du? Ich hab sowohl XmediaRecode als auch HandbrakePortable. Und beide unterstützen sowohl CPU Codecs als auch Hardware auf iGPU/GPU.

Bei mir ist die Hauptanwendung, von der Mediathek (Öffis) in H.264 bereitgestellte Filme auf H.265 zu komprimieren. Meistens(!) nehme ich bei 720P als Zielgröße 850 kbps und bei 1080P um 1250 kbps. Unter 1100 eher nicht und über 1500 brauche ich auch nicht.

Beispiel: (den Film in FHD von 3SAT). Bereitgestellt mit dem "HD" Downloadknopf als 1080P (also FHD) in H.264 mit 6600 kbps, Zielgröße sind bei mir im Schnitt 1250 kbps ABR mit H.265/10Bit AMD VCE, "Quality" und eben "preanalysis=1:vbaq=1:bframes=3:b_pyramid=1" als Extra-Parameter. Das File schrumpft von 4.4 gb (mit 128 kbit AAC Audiospur als Stereo) auf 1,15 gb, für mich ohne sichtbare Einschränkungen und das mit etwas über 300 FPS laut Logbuch. Bei 720P/HD Material (nehme bei Serien wie "Hubert und/ohne Staller") reichen nur 850 kbps ABR (1080P wären 1100), was bei der typischen Dreiviertelstunde auf etwa 400 mb je Folge hinausläuft. Dafür durch die kleinere Zielauflösung mit aufgerundet 500 kbps im Encoding statt knapp über 300 wie bei 1080P.

PS: Bei mir arbeite ich sowas übers Netz bzw. noch eine WLAN Brücke, die Framerate ist durch die Netzanbindung bzw. Auslastung manchmal deutlich niedriger, als wenn diese direkt systemintern laufen würde.

Man muss bei der Bitrate etwas im Auge haben: Bei Filmen mit sehr viel Action, vielen schnellen Schnitten und Kameraschwenks muss die Bitrate trotz "Preanalysis" und damit etwas dynamischerer Verteilung der Peak-Bitrate etwa 20% hoch. Beim typischen Spielfilm bzw. dialoglastigen Serien wie Hubert und Staller eben weniger. Fußball zum Beispiel geht bei mir in FHD mit 1500 kbps statt 1200 bzw. bei HD nehme ich dann 1000 kbps statt 850. Gut genug. Witzigerweise will man beim Fußball den kleinen, weissen Punkt sehen. Als Testfile nimm ein Bundesligaspiel bzw. den Spieltag und einer Ausgabe des "ZDF Sportstudios". Fußball ist IMHO mehr Stress für den Encoder als jeder Actionfilm, das sind nur Schwenks der Kamera und schnelle Schnitte mit so nem uninteressant-kleinen, weissen Detail. Die heftigste Herausforderung sind übrigens alte, "grieslige" Filme. Dann Entrauschfilter draufzumachen kostet ohne Ende FPS, weil diese zudem auf der CPU laufen. Spriich: Das Filtern ist der bottleneck und nicht die Kodierung. Da schneidest du freiwillig ein paar typische Minuten als Schnipsel raus und machst vorher Tests mit Einstellungen, bevor der Rechner nen kompletten Tag was für die Tonne codiert. CPU Coding ist bei meinem 5800X trotz 8C16T der Notnagel, da nehm ich lieber die GPU.

Übrigens reichen mir 8 Bit bei Mediathekenmaterial, da bei Mediatheken das Material sowieso nur mit 8 Bit bereitgestellt wird. Wer von Blueray / DVD kommt, der wird eher 10 Bit nehmen. Was es "Hardware" bei mir nicht wirklich langsamer macht, aber in den "Zusätzlichen Parametern" andere Settings erfordert. Beim 10-Bit Encoder ist der AMD VCE übrigens etwas zickig was Zusatzparameter angeht, die lasse ich nur "ohne" laufen und die Bitrate bei 1500 für 1080P. Leider macht der 10-Bit Encoder eher einen "Overshoot" der Bitrate, mir in dem Fall aber egal. Weils die Qualität sichert. Bei 8-Bit und den oberen Settings trifft der die angepeilte Zielgröße jedoch recht gut.

Schnellschätzung der Bitrate bei mir: "Gute Einstellungen einmal finden" und dann mit der Wurzel der neuen Auflösung skalieren. Also doppelte Auflösung sind Wurzel 2 als Bitratefaktor. In 9 von 10 Fällen ist das gut genug, dazu habe ich eben zwischen jeweiliger Ober- und Untergrenze rund 20% fürs Bauchgefühl. Sport oben, diagloglastig (siehe der Pate als Beispiel) unten.