x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

Ich würds eigentlich lieber nicht zu bunt haben, und die Leserlichkeit geht vor (für alle Forenskins und Kontraste), daher möchte ich es gerne so belassen, wie's ist.

==

I would actually not want it to be too colorful, and readability comes first (for all forum skins and contrasts), so I would actually like it to stay as it is.

@Grindhavoc: Welche Forenskin benutzt du,wenn ich fragen darf? Weil bei meiner dunklen ("Voodooalert inception" Skin) sieht man es eigentlich relativ deutlich. Ich wollte ja noch die Platznummern einfärben, aber das geht leider nicht so selektiv wie erhofft.

Zitat von Grindhavoc

[...]
Würde der Benchmark wohl auf so nem Teil laufen?
http://cgi.ebay.de/Grass-Valley-C…=item2c596deb54

Unwahrscheinlich, so wie wohl auch MediaCoder mit CUDA Support als Ersatztest wenig geeignet wäre (denke ich). Das Transcoding wird die Karte sicher beherrschen. Nur in der Regel unterstützt nur x264 selbst die ganzen modernen Bleeding-Edge Features um die Qualität ans Maximum zu treiben.. Dinge wie CABAC oder die Macroblock-Statistik, die x264 im Pass 1 schreibt sind sonst eher nirgends möglich. Daher wär es qualitativ kein 1:1 Vergleich. Ist ein bißchen wie zwei Grakas vergleichen, wennst eine mit und eine ohne FSAA benchst..

Hmm, Miss Esther sollte es wohl nächste Woche hinter sich haben..

Edit: Hab mich grade auf der Grass Valley Webseite zum "FireCoder Blu" schlau gemacht, und im [Manual des Produkts] bzw. der Software dazu ist schon deutlich zu sehen, daß da kaum Einstellungsmöglichkeiten für H.264/AVC bestehen. Das Teil kann sich also nicht mit x264 messen.

Ich selber würde die Idee der Hardwarebeschleunigung im Videotranscoding ja eh großartig finden, sowas wollt ich schon immer haben. Aber leider schauts so aus, daß die dedizierte Transcodinghardware immer ewig weit hinten ist...

Zitat von FS03

Die Auslastung war aber eher als bescheiden zu Bezeichnen, zumindest beim ersten Pass (~40%).

Er hatte noch eine Anmerkung zum Bench: "single pass quality mit nem crf wäre besser".
Jetzt aber noch den Bench umzustellen halte nicht in Anbetracht der vielen schon vorhandenen Ergebnisse für Sinnvoll.
Für eine Bessere Auslastung von mehreren Threads kann man nicht was machen, oder?

Ah, das sollte ich noch kommentieren. Der Grund, warum ich kein Constant Ratefactor ("CRF") Ratecontrol einsetze, ist einfach der, daß ich auf eine Zieldateigröße hinkodiere, nicht auf eine Zielqualität (oder qp). Dafür ist ein Bitratecontrol mit 2-Pass optimal. Bei den Filmen ziele ich ja auf eine DVD9 Größe ab (~8GB), und diese Vorgehensweise habe ich für den Bench einfach übernommen.

Zum anderen Problem:

x264 setzt standardmäßig n*1.5 Threads ein, wobei n der Anzahl an logischen CPUs entspricht. Das heißt, ein Quadcore kriegt schon 6 Threads, ein 8-Kerner bekäme 12 Threads, das hier gezeigte SR-2 System 36 Threads (12 Kerne + HT, also 24 "CPUs"). Leider sinkt die Leistung gemäß des Gesetzes des Abnehmenden Ertrags und in Pass 1 greift das Threading irgendwie ned so. Daher würde ich empfehlen, die Systemlast während Pass 2 zu beobachten, denn der profitiert noch stärker von der Kernanzahl, hier sollte die Auslastung deutlich höher sein.

WUWHUAWHhuwauhuahauhauuahuahahahahhaaaa...

aaah....

ah..

Ok, is drin.