x264 output = f(CPU-Type, core/thread count)?

Von der Anzahl der Threads hängt es mit Sicherheit ab. Schließlich bekommt jeder der n Threads nur 1/n des Filmes zu sehen. (Ich kann nur jetzt nicht mit Sicherheit sagen, was exakt.) Dass es jedoch bis zur Cropping-Analyse reicht, ist tatsächlich überraschend.

Zur maximal erreichbaren Qualität kann ich nichts sicher sagen; wenn die Bitrate nicht beschränkt wird, dann kann der Encoder immer noch Teile des Bildes, für die keine hinreichend ähnliche Referenz gefunden wird, intra-codiert (also unabhängig) speichern, was halt mehr Platz braucht, aber ebenso die Qualität sichert. Relativ sicher ist lediglich, dass mit dem Geschwindigkeitsvorteil ein gewisser Nachteil im Verhältnis zwischen Größe und Qualität entsteht. Der kann jedoch durchaus unmerklich klein ausfallen.

Zitat von Wummel

Das führt jetzt ggf. zu weit, aber - weiß jemand wie die frames auf die threads aufgeteilt werden?
z.B. immer abwechselnd (wohl kaum, wäre wohl der worst case), oder jeder thread bekommt immer eine Sequenz von 10 oder 100 frames?

Nur falls es zufällig jemand weiß....

In x264 ist das Multi-Threading Frame-basiert, d.h. für jeden zu verarbeitenden Frame wird genau ein Thread gestartet, der sich auch nur um diesen Frame kümmert. Die maximale Anzahl von parallel laufenden Encoder-Threads ist durch "--threads" festgelegt oder wird standardmäßig auf 3/2 * #Prozessorkerne gesetzt. Die Frames werden aber keinesfalls unabhängig voneinander verarbeitet! Jeder Frame/Thread muss ja auf seine benachbarten Referenzframes zugreifen. Dabei ist sicherzustellen, dass ein Thread nur auf Bereiche eines anderen Threads/Frames zugreift, die bereits fertig gestellt sind. x264 garantiert jedem Thread dabei einen minimale "Breite" (es wird ja in Markroblock-Zeilen von oben nach unten gearbeitet), die im Referenz-Frame auf jeden Fall fertig/zugreifbar ist. Solange x264 im deterministischen Modus arbeitet (das ist der Standard!), beschränkt sich ein Thread sogar bei der Bewegungssuche im Referenz-Frame immer auf den minimal zugesicherten Bereich (anstatt einfach alles zu benutzen, was schon fertig ist). Genau diese Einschränkung bei der Bewegungssuche ist dafür verantwortlich, dass die Kompressionseffizienz mit steigender Anzahl von Threads leidet, d.h. die Datei wird bei gleicher Qualität größer oder die Qualität bei gleicher Größe schlechter. Allerdings sind die Unterschiede bei der Anzahl von Threads, die in der Praxis vorkommt, so klein, dass man sich da keine Sorgen machen muss. Die aller meisten Bewegungen sind ohnehin in horizontaler Richtung, so dass die Einschränkung der Suche in vertikaler Richtung kaum ins Gewicht fällt. Und auf jeden Fall leidet die Kompressionseffizienz bei diesem Ansatz weitaus weniger, als das bei Slice-basiertem Multi-Threading der Fall wäre. x264 unterstützt jetzt zwar auch wieder Slices (d.h. ein Frame wird in mehrere Stücke unterteilt), diese werden aber nicht zum Multi-Threading verwendet.

Ein paar Zahlen, die aber nicht mehr aktuell sein müssen:

Benchmarks:
cpu: 4x woodcrest 3GHz
content: 480p


x264 -B1000 -b2 -m1 -Anone
threads  speed           psnr
       old   new      old    new
1:   1.000x 1.000x   0.000  0.000
2:   1.168x 1.413x  -0.038 -0.007
3:   1.208x 1.814x  -0.064 -0.005
4:   1.293x 2.329x  -0.095 -0.006
5:          2.526x         -0.007
6:          2.658x         -0.001
7:          2.723x         -0.018
8:          2.712x         -0.019


x264 -B1000 -b2 -m5
threads  speed           psnr   
       old   new      old    new
1:   1.000x 1.000x   0.000  0.000
2:   1.319x 1.517x  -0.036 -0.006
3:   1.466x 2.013x  -0.068 -0.005
4:   1.578x 2.741x  -0.101 -0.004
5:          3.022x         -0.015
6:          3.221x         -0.014
7:          3.331x         -0.020
8:          3.425x         -0.025


x264 -B1000 -b2 -m6 -r3 -8 --b-rdo
threads  speed           psnr   
       old   new      old    new
1:   1.000x 1.000x   0.000  0.000
2:   1.531x 1.707x  -0.032 -0.006
3:   1.866x 2.277x  -0.061 -0.005
4:   2.097x 3.204x  -0.088 -0.006
5:          3.468x         -0.013
6:          3.629x         -0.010
7:          3.716x         -0.014
8:          3.745x         -0.018

Siehe auch:

Zitat

int i_mv_range_thread; /* minimum space between threads. -1 = auto, based on number of threads. */

Zitat

int b_deterministic; /* whether to allow non-deterministic optimizations when threaded */