wieviele Kerne kann h264 maximal verwenden

D

DBGTKING

Guest
Hallo leute.JA ihr habt richtig gelesen.Es geht um den codec h264 vum video zu komprimieren.Gehen mal von maximalen settings ultra low bei 720p oder 1080p.Ich möchte wissen wie viele kerne der dadurch maximal nutzen könnte teroretisch oder gibt es überhaupt kein Limit.Das kann ich mir nich vorstellen.Alles hat sein Limit.Und treads verraten ja nicht wieivel kerne das Programm maximal verwenden kann.
Xmedia recode zeigt 128 Treads.Das heist der könnte teroretisch 64 kerne + HT auslasten oder habe ich ein rechenfehler.Ich frage darum weil nur aus neugier.So einen Prozessor gibt es ja nicht und selbst wenn wäre er ja unbezahlbar.Aber wer sich gut auskennt oder selbst erfarhung sammel konnte,kann er ja bitte mir antworten.Danke schon mal im voraus für eure Hilfe.
 
Mehr, als du dir leisten kannst. Die Frage ist nur was der Sinn davon ist.
h.264 kann problemlos 128 Threads benutzen (solche Systeme gibts sehr wohl (beispiel)). Nur hat das zwei große Probleme (die ab sagen wir grob 16 Threads relevant werden):

1.) Die Kodiereffizienz sinkt weil die Arbeitsaufgaben in immer kleinere Stückchen geschnitten werden und an den "Grenzen" von einem Stück zum anderen die Effizienz des Kodierers sehr klein wird. Oder anders ausgedrückt: Für die gleiche Bildqualität wirst du mehr Bitrate verbrauchen wenn du den Clip auf 32 Threads verarbeiten lässt statt auf 4.
2.) Der Performancegewinn wird immer kleiner (Amdahl-Gesetz). Wo 2 Kerne noch fast doppelt so schnell kodieren wie einer sind 8 kerne nur noch sagen wir 50% schneller als 4. Wenn du 32 Threads benutzt ist der Geschwindigkeitsvorteil gegenüber 16 kernen nur Minimal.

Punkt 2 Kann durch wiederum 2 Methoden abgefangen werden.
Methode A) Den nötigen Rechenaufwand pro Pixel erhöhen - also möglichst harte Einstellungen/Presets wählen. Das skaliert besser mit mehr Threads (ebenso möglichst hohe Auflösungen).
Methode B) Mehrere Clips gleichzeitig berechnen und Threads fest zuweisen. Also statt 4 Videos nacheinander auf 16 kernen zu berechnen den Encoder 4x starten und jeweils 4 Kerne fest zuweisen.

Anhang Methode C) HEVC (h.265) benutzen - der skaliert wesentlich besser mit mehr Threads und liefert nebenbei deutlich bessere Ergebnisse bei gleicher Bitrate (oder eben gleiche Quali bei 20-50% kleineren Dateien).


Übrigens: die Encoder laufen auch auf GPUs - da unter Umständen mit mehreren tausend Kernen - und entsprechend schlechter Kernskalierung (4K-Video zu HEVC wandeln lastet eine TitanX nicht mal 20% aus weils nunmal nicht besser geht). :-D
 
Zuletzt bearbeitet:
Eine h264 Kachel ist 16x16 Pixel groß.
Du unterteilst also Dein Bild in 16x16 Pixel Kacheln und lässt jede von einem Kern berechnen.
Bis dahin müsste es eigentlich skalieren.

An meinem 16 Threader gab es jedenfalls immer volle Auslastung, und das ist auch der Grund warum Grakas bei der Aufgabe so gut abschneiden, es lässt sich wundervoll zerhackstücken.
 
Also die möglichst hohe settings können das Problem aber auch nur bis zu eienr gewissen grenze verbessern.Ich kann mir nicht vorstellen das man so effizient 128 Kerne voll ausnutzen kann.Da wird bestimmt auch die größe der Datei limitieren.Wenn man so extreme settings wählt ist doch der sinn bzw der Vorteil vom Komprimieren aber wieder dahinn weil man dann kaum kleinere Dateien bekommt als das Quellformat.Somit ist auch dieses Extreme setting dann schon am ende angelangt.
Oder liege ich da mit der vermutung falsch.

@ Hisn nach deiner berechnung wäre das ja bis zu 256 kerne.Ist ja unglaublich wie weit die software skalieren kann.Hätte ich ja wirklich nicht gedacht.Ja wenn das so ist dann brauche ich mir ja wirklich keine sorgen zu machen ^^
 
Also die möglichst hohe settings können das Problem aber auch nur bis zu eienr gewissen grenze verbessern.
Richtig, wobei die Grenze zwar hoch ist (hadamard exhaustive motion estimation + radius 64 mit 16 ref-Frames oder sowas :ugly:) aber dann auch sinnlos wird da das nichts mehr an BQ bringt. Da hast du völlig Recht. Mehr als das Preset "very slow" hat bei h.264 nur in speziellen Fällen Sinn.
 
wow selbst 16 ref haben nur 64 kerne.Ich habe gerade nachgesehen xmedia recode hat ja nur 8x8.Das heist dieses Programm profitiert ja noch weniger als ich gedacht habe und dabei ist dieses Programm das schnellste von den ganzen Programmen.Aber aufgrund mangels guten Deinterlacer war ich gezwungen gewesen auf advidmux auszuweichen.Das merkwürdigerweise bei allen Rechnern langsamer war und das bei gleichen einstellungen.Vielleicht erzeugt einfach das 50 echte Fps einfach solch ernorm hohe last das das man das softort merkt.Ist zwar gut das das Programm mehr kann aber ob jetzt 16x8 oder 8x16 ist ja egal.Was bringen denn solch krumme einstellungen.Was hat sich denn da der entwickler nur dabei gedacht:what:
 
und dabei ist dieses Programm das schnellste von den ganzen Programmen.

All diese GUI-Programme machen exakt dasselbe, nämlich die Bibliotheken von x.264 zu verwenden. Entsprechend sind alle derartigen Encoder (sofern sie die gleiche Version von h.264 verwenden) exakt gleich schnell denn sie machen alle das genau gleiche wenn man die Einstellungen gleich setzt.

Das schnellste ist übrigens die GUI ganz wegzulassen und einfach die x.264_64.exe von Hand zu bedienen (also Kommandozeilen und so).
 
ja das mag schon sein,aber Kommandozeilen ist unübersichtlicher und man kann die einstellungen nicht so leicht machen.Also von der bedienung unoptimal.Naja sonst gibt es wohl nix mehr.hmm.Ok dann ist das halt so.dann weis ich das ich wohl nicht alles verwenden mag.Dann habe ich bei xmedia Recode durchschnittsbitrate und beim Advidmux konstante Bitrate gewählt.Habe das ganze unterschätzt.Kostet ganz schön leistung.
 
ja das mag schon sein,aber Kommandozeilen ist unübersichtlicher und man kann die einstellungen nicht so leicht machen.Also von der bedienung unoptimal.

Wenn man immer die gleichen Settings nutzt hat man die Befehle ein mal getippt und sie in einer txt-Datei gespeichert.
Öffnen, einfügen, Enter, fertig. Wesentlich komfortabler als die klickibunti Programme und auch noch schneller.

Dann habe ich bei xmedia Recode durchschnittsbitrate und beim Advidmux konstante Bitrate gewählt.
Das ist Technik von vor 20 Jahren. Bitte lies dich in dynamische Methoden und Quantisierer ein (ConstantRateFactor). Da benutzt du eine Zahl die bestimmt welche Bildqualität du haben willst und der encoder wählt bei jedem frame dynamisch aus wie viel Bitrate er dafür verwenden muss. Ist schneller, einfacher, flexibler und erzeugt qualitativ bessere Videos bei kleineren Dateigrößen. Selbst Bitraten einzustellen ist Quatsch.

Einsteiger (etwas älter): Das Encodingwissen – Das Encodingwissen
Fortgeschritten: Command Line Options — x265 documentation
 
wow so alt schon ,hätte das nicht gedacht.Ich sehe schon,ich habe nur ein bruchteil davon wirklich gelesen.Und dadurch nur einen gewissen teil wirklich ausgenutzt.Da muss man wirklich ganz viel aufpassen.Habe bei den ganzen einstellung das meiste auf standard gelassen so wie es ist.Habe damit wohl ein Potenzial wohl etwas verschenkt und es mir dadurch wohl etwas zu leicht gemacht.
Ich danke dir für all die infos.Ich habe das erfahren was ich hören wollte.Danke dir. ^^
 
Habe bei den ganzen einstellung das meiste auf standard gelassen so wie es ist.
Das ist auch nicht schlecht so.

Im Wesentlichen brauchste nichts zu tun außer dein preset zu wählen abhängig von der Rechenpower/Zeit und den CRF zu wählen abhängig von der angestrebten Qualität. Dann haste 98% des Codecs ausgereizt.
Beispielsweise CRF 20 preset veryslow für sehr ordentliche Qualität. größere CRF Zahlen (23, 25, 27) bedeuten schlechtere Quali bei kleinerer Datei, kleinere CRFs (19, 18, 17) machen das Bild besser und die Datei größer.
(der Nachteil von CRF ist dass du im Voraus nicht weißt wie groß die Datei wird. Je nach Bildinhalt kann das stark schwanken)

Nur um den UNterschied zu sehen: Benutze mal den h.265 mit CRF23 preset medium.
Das sollte grob gleich schnell sein wie h.264 CRF20 veryslow und die etwa gleiche Bildqualität liefern. Bei halber Dateigröße... ;-)
 
Das Problem mit h265 ist das ich das kaum abspielen kann. Wenn du mir zeigt wie man auf einem 2008er bluray player ohne neuen update seid Jahren beibringt h265 abzuspielen dann bist du noch besser als ich erwartet habe.
Im Moment verwende ich Crf 18 very fast. Dürfte in etwa Crf 20 medium bis in Richtung slow gehen oder?

Und mir ist noch ne Frage eingefallen. Wie entscheidend ist der CPU Takt unabhängig von den Kernen beim h264. Merkt man da einen riesen unterschied?
 
Das Problem mit h265 ist das ich das kaum abspielen kann. Wenn du mir zeigt wie man auf einem 2008er bluray player ohne neuen update seid Jahren beibringt h265 abzuspielen dann bist du noch besser als ich erwartet habe.

Das geht leider nicht. HEVC geht nur entweder mit Hardwareunterstützung (kann der Player nicht haben) oder in Software mit sehr, SEHR viel Rechenleistung (hat er auch nicht).
Da musste bei AVC bleiben (oder einen aktuellen Player kaufen).

Im Moment verwende ich Crf 18 very fast. Dürfte in etwa Crf 20 medium bis in Richtung slow gehen oder?
Vorsicht. CRF bedeutet "gleiche Qualität". Bedeutet CRF18 veryfast sieht genauso aus wie CRF18 veryslow (stimmt nicht ganz aber in der Theorie ist das so) - nur ist die veryslow-Datei viel kleiner weil die Kodiereffizienz mit stärkerem / langsameren Preset ansteigt.

Wie entscheidend ist der CPU Takt unabhängig von den Kernen beim h264. Merkt man da einen riesen unterschied?
Videokomprimierung skaliert fast 1:1 mit steigendem CPU-Takt da die Komprimierung. Sprich eine 4-GHz CPU ist fast doppelt so schnell wie die gleiche CPU bei 2 GHz.
 
Eine h264 Kachel ist 16x16 Pixel groß.
Du unterteilst also Dein Bild in 16x16 Pixel Kacheln und lässt jede von einem Kern berechnen.
Bis dahin müsste es eigentlich skalieren.

An meinem 16 Threader gab es jedenfalls immer volle Auslastung, und das ist auch der Grund warum Grakas bei der Aufgabe so gut abschneiden, es lässt sich wundervoll zerhackstücken.

Ich habe das nochmal genauer durchgelesen.Hast du echt nur mit dieser Einstellung den 8 kerne mit ht voll ausgelastet und normal dann nicht.

Und bei welcher einstellung kann ich ref frames einstellen?
Das radius 64 kann ich ja bei Bewegungsvektor finden.
Das andere bei Vollpixel-Ebene.
Möchte das falls die auslastung nicht ausreicht ja erhöhen könnte als möglichkeit.
 
Nein, meiner Meinung nach kannst Du die Kantenlänge Deines Frames nehmen (kürzere Seite), sie durch 16 Teilen und dann hast Du die Anzahl der Kerne mit denen h264 skalieren könnte.
 
So einfach ist das bei weitem nicht. Es können auch mehrere Threads an einem Tile arbeiten oder ein Thread an mehreren Tiles.
Beispielsweise könnten in einem 16x16 Tile 256 Kerne gleichzeitig für jeden Einzelpixel in den vorangegangenen 16 Frames den optimalen Bewegungsvektor zum nächsten Frame suchen. Das ist in der Praxis natürlich völliger Käse das so zu machen aber theoretisch geht das.

Und bei welcher einstellung kann ich ref frames einstellen?
Das ist der Nachteil von GUIs. Da ist immer alles anders.
Reference Frames einstellen hat den Befehl "ref=x" mit in dem Falle x=16 (1-16 möglich). Vorteil von Kommandozeilen. :ka:

Anleitung beschreibt schlichtweg:
--ref <1..16>Max number of L0 references to be allowed. This number has a linear multiplier effect on the amount of work performed in motion search, but will generally have a beneficial affect on compression and distortion.
 
Zuletzt bearbeitet:
Du hast es doch selbst angesprochen, aber irgend einem Punkt ist es Käse.
Wir schauen nur auf verschiedene Punkte.
720/16 ist gerade mal 45. Halte ich für einen machbaren Wert.
 
Ja, der Punkt über den ich nicht gehen würde ist 16 Threads, maximal vielleicht noch 20 mit nem 6950X.
Darüber würde ich mit mehreren Dateien gleichzeitig arbeiten um nicht zu viele Threads parallel zu haben.

Wenn man dann aufrüstet auf 4K in HEVC kann man auch wieder mit 32 oder 40 Threads kommen, da ist wieder mehr als genug Power nötig und auch in dem Codec sinnvoller parallelisierbar (hauptsächlich weil die Tiles / CTUs hier 64x64 sind).
 
ach Treads sind ref frames,verstehe.Nur leider ist das bei advidmux ausgegraut.Ich weis echt nicht warum ich da nicht sehr viel einstellen kann.Gibt es da ein schlater der das freischaltet?
 
ach Treads sind ref frames,verstehe.

Wie kommst du denn darauf?
Das eine hat mit dem anderen absolut nichts zu tun. Dass h.264 maximal 16 ref-Frames unterstützt und ich persönlich nicht mehr als 16 Threads benutzen will pro Datei ist rein zufällig die gleiche Zahl.

Thread = "Befehlsliste" die eine CPU abarbeitet
Ref-Frame = Referenzierungsbild, zu dem das zu komprimierende Bild Ähnlichkeiten aufweist. Ref=16 bedeutet, dass für ein zu komprimierendes Bild in einem Video die 16 letzten Bilder herangezogen werden um Ähnlichkeiten zu finden.
 
Zurück