x264 & AMD Prozessor

Zitat

Wo finde ich denn eine passende Build?

Alle aktuellen builds, die nicht extra für z.B. ICC optimiert sind, sollten alle Features nutzen die sinnig sind.

Nebenbei: 3pass ist unsinnig, wenn man nicht sehr exotisches Material hat

x264 detektiert die erweiterten Befehlssätze deiner CPU zur Laufzeit. Es werden also nur die Befehlssätze verwendet, die von deiner CPU tatsächlich unterstützt werden.

Allerdings sind bei weitem nicht alle erweiterten Befehlssätze, die existieren, auch tatsächlich für die Video-Kodierung sinnvoll bzw. hilfreich!

Die x264 Entwickler haben natürlich nur für die Befehlssätze entsprechend optimierte Routinen implementiert, die für die ausgeführten Berechnungen wirklich irgendwelche Vorteile bringen.

Und natürlich werden auch nur diejenigen Befehlssätze zur Laufzeit detektiert, die tatsächlich irgendwo in x264 zum Einsatz kommen können. Das sind derzeit die folgenden:

/* CPU flags
 */
#define X264_CPU_CACHELINE_32   0x000001  /* avoid memory loads that span the border between two cachelines */
#define X264_CPU_CACHELINE_64   0x000002  /* 32/64 is the size of a cacheline in bytes */
#define X264_CPU_ALTIVEC        0x000004
#define X264_CPU_[COLOR='DarkRed']MMX[/COLOR]            0x000008
#define X264_CPU_[COLOR='DarkRed']MMXEXT[/COLOR]         0x000010  /* MMX2 aka MMXEXT aka ISSE */
#define X264_CPU_[COLOR='DarkRed']SSE[/COLOR]            0x000020
#define X264_CPU_[COLOR='DarkRed']SSE2[/COLOR]           0x000040
#define X264_CPU_SSE2_IS_SLOW   0x000080  /* avoid most SSE2 functions on Athlon64 */
#define X264_CPU_SSE2_IS_FAST   0x000100  /* a few functions are only faster on Core2 and Phenom */
#define X264_CPU_[COLOR='DarkRed']SSE3[/COLOR]           0x000200
#define X264_CPU_[COLOR='DarkRed']SSSE3[/COLOR]          0x000400
#define X264_CPU_SHUFFLE_IS_FAST 0x000800 /* Penryn, Nehalem, and Phenom have fast shuffle units */
#define X264_CPU_STACK_MOD4     0x001000  /* if stack is only mod4 and not mod16 */
#define X264_CPU_[COLOR='DarkRed']SSE4[/COLOR]           0x002000  /* SSE4.1 */
#define X264_CPU_[COLOR='DarkRed']SSE42[/COLOR]          0x004000  /* SSE4.2 */
#define X264_CPU_SSE_MISALIGN   0x008000  /* Phenom support for misaligned SSE instruction arguments */
#define X264_CPU_LZCNT          0x010000  /* Phenom support for "leading zero count" instruction. */
#define X264_CPU_ARMV6          0x020000
#define X264_CPU_NEON           0x040000  /* ARM NEON */
#define X264_CPU_FAST_NEON_MRC  0x080000  /* Transfer from NEON to ARM register is fast (Cortex-A9) */

Erweiterte Befehlssätze sind kein "magischer" Turbo-Boost, sondern man muss die neuen Befehle im jeweiligen Programm auch sinnvoll einsetzten können!

Soweit ich weiß, umfasst 3DNow! ausschließlich Fließkomma Operationen. Das mag für 3D Grafik hilfreich sein, ist aber für die Video Codierung leider nicht zu gebrauchen.

Video Codierung, zumindest nach H.264, verwendet praktisch nur Integer/Ganzzahl Mathematik

Zitat

ich mach da den 2ten durchgang aber halt mir --pass 3 weil ich folgendes gelesen hab

Warum willst Du den das .stats File aktualisieren, wenn Du keinen 3rd pass machst?

Zitat

ok, danke für die ausfürliche CPU info ich hab mir mal nen QuadCore bestellt, dann wirds vielleicht nochn tick schneller.

Da x264 Multi-Threading benutzt und zudem sehr gut skaliert, ist mit einem QuadCore die doppelte Geschwindigkeit eines vergleichbaren DualCore zu erwarten. Wenn du dir einen aktuellen Intel CPU (Nehalem Architektur) holst, sind noch mal 40% Speed-up im Vergleich zu einem gleich schnell getakteten Prozessor der vorherigen Generation drin...

Zitat

hmm, vielleicht gefällt mir das ergebniss ja net, zu groß, zu klein, zu weich, doch nur 720p statt 1080p etc und dann hab ich ne aktualisierte stats-file um nochmal zu codieren ... hab ich mir gedacht, oder denk ich falsch? Is meine erste BluRay die grad zu 264/MKV wird

Hört sich zumindest von meiner Seite aus nicht sinnig an.

Nebenbei: für Blu-ray Kompatibilität muss man noch auf einiges achten, die Streams die Du mit der oben genannten CommandLine erstellst sind wenn DU Pech hast nicht Blu-ray kompatibel.

Zitat

wenn ich den Kniff raus hab gehts auch schneller, hoff ich ...

x264 --fullhelp gibt eine Auflistung der Parameter und was ihre Defaultwerte sind.

Zitat von Fire

so, wollt mich nur nochmal melden. Hab jetzt den QuadCore eingebaut und schaff bei einem "x264 --tune film --crf 20" grad mal 7,x FPS (bei ca 4000-6000kb/s) ... is auch net viel mehr wie der DualCore (ok, ja man kanns net direkt vergleichen, nicht die gleichen einstllungen) ... schade schad

Ja, du musst schon die selbe Quelle und die selben Einstellungen verwenden, um irgendwelche Vergleiche ziehen zu können...

Zitat von Fire

ich hab da aber auch nochmal ne Frage, und zwar was der unterschied zwischen den ganzen Builds is, die ich zB auf doom10.org finde? ok, klar, da steht dieser Patch und jener Patch, aber für mich als Causual-Encodierer nicht so ausschlaggebend, oder?

x264 wird von den Entwicklern als Quellcode bereit gestellt. Es gibt keine "offiziellen" Builds. Man muss sich also vorkompilierte Binaries von irgend jemand holen, sofern man nicht selbst kompilieren möchte/kann. Fertige Builds gibt es für verschiedene Plattformen (Windows, Linux, MacOS, etc) und Architekturen (x86, amd64, etc). Darüber hinaus können verschiedene Compiler eingesetzt werden (GCC, ICL, etc), um die Builds zu erzeugen, und es können dabei auch verschiedene Compiler-Optimierungen eingeschaltet werden (oder eben nicht). Was Patches angeht: Dabei geht es zumeist um neue bzw. experimentelle Features, die es (noch) nicht in das offizielle x264 Repository geschafft haben. Je nach dem, ob man genau dieses Feature unbedingt haben muss, kann es sein, dass du ein gepatchtest Build brauchst oder getrost darauf verzichten kannst. Etwas Experimentierfreude sollte man aber auf jeden Fall mitbringen, wenn man zu Builds mit "inoffiziellen" Patches greift...

Zitat von Fire

jo, ok, ich nehm halt mal die Build von x264.nl ... und aktuell rattert er mit schnarchenden 6,85 fps bei 6900 kbit/s vor sich hin *seufz* und das mit nem 4x2,3GHz QuadCore ... muss ich jetzt auch noch übertakten *g*

Das Tempo hängt natürlich stark von der Auflösung des Quellmaterials und von den verwendeten Einstellungen ab. Man kann natürlich immer Qualität/Kompression gegen Geschwindigkeit eintauschen, indem man ein "schnelleres" Preset verwendet (z.B. "--preset fast" oder "--preset faster"). Aber 6,85 fps sollte bei SD Material durchaus im grünen Bereich liegen.

Für HD Material gibt es an einer Encodier-Geschwindigkeit von 6,85 fps mit Sicherheit nichts auszusetzen! ;D

Keine Ahnung welche Taktrate deine vorige CPU hatte, aber die Geschwindigkeitssteigerung hätte man sich sicherlich schon vorher so ungefähr ausrechnen können.
Wenn man den crf Modus benutzt könnte man doch auch etwas schnellere Einstellungen benutzen, die Qualität sollte darunter doch eigentlich nicht oder kaum leiden, nur die Dateien werden dann etwas größer.

Wenn man "schnellere" Presets verwendet, passiert beides: Die Datei wird größer und die Qualität wird schlechter. Jeweils zu einem gewissen Grad.

Zitat von Dark Shikari

Some of them lower the bitrate by improving compression efficiency, while others are more likely to raise the quality a bit. Some do a combination. It depends on the situation.

Da Du DirectShowSource verwendest, lässt sich evtl. mit einem anderem Decoder noch etwas Geschwindigkeit herausholen. Im Nachkommabereich ;).

Beim codieren über DirectShowSource vertraue ich bei AVC Material nur dem CoreAVC Decoder, der arbeitet sehr zuverlässig und wirklich Framegenau, was bei diversen anderen Decodern nicht immer der Fall ist. Auch ist der Output von sehr guter Qualität, besser als von CyberLink & Co.

Gruß gispos

Also ich hatte bis vor paar Tagen noch einen 3Ghz Amd Dualcore - nun den 2.9Ghz Triple (das Ding ohne cache)
Der X3 Triple ist im x264 bei mir zumindest in vdub (gleiche Settings natürlich) fast genau doppelt so schnell wie mein voriger X2. Also ich war mehr als positiv überrascht.
In anderen Programmen ist der Zuwachs allerdings en ticken weniger gewesen (hängt wohl auch von der jeweiligen Software ab). Bei manchen Settings wie diesem "adaptive B-frame", kriegt man (zumindest bei der vfw) was mehr Speed wenn man auf 4-5Threaths geht.

Das der Quad bei dir nicht schneller sein soll als dein Dualcore, na ja - also wenn mußte auch schon mit gleichen Einstellungen vergleichen. Btw. wieviel Mhz hatte eigentlich dein X2?

Zitat von gispos

Beim codieren über DirectShowSource vertraue ich bei AVC Material nur dem CoreAVC Decoder, der arbeitet sehr zuverlässig und wirklich Framegenau, was bei diversen anderen Decodern nicht immer der Fall ist.

Bei DirectShow kann man sich generell nicht auf Frame-Genauigkeit verlassen, da es eben zur Echtzeit-Wiedergabe und nicht zum Video-Schnitt konzipiert ist! Genau deshalb gibt es ja sowas wie DGIndex für MPEG-2 bzw. DGAVCIndex() für H.264. Allerdings soll DirectShowSource2() zumindest eine "bessere" Genauigkeit liefern, als das "normal" DirectShowSource().

Zitat von gispos

Auch ist der Output von sehr guter Qualität, besser als von CyberLink & Co.

Diese Aussage ist nun wirklich Blödsinn. Für die selbe Quell-Datei ist die Ausgabe aller H.264 Decoder immer identisch! Dafür gibt es schließlich Standards. Ein gültiger H.264 Video-Stream kann korrekt interpretiert nur zu genau einer möglichen Ausgabe führen. Wenn die Ausgabe eines H.264 Decoders für einen gültigen Stream vom Referenz-Decoder abweicht, dann ist das schlichtweg ein Bug. Aber so etwas wie unterschiedliche Dekodier-Qualität gibt es nicht. Es gibt nur korrekt oder fehlerhaft. Im übrigen ist CoreAVC derzeit nicht dazu in der Lage, H.264 Streams mit Weighted P-Prediction korrekt zu dekodieren. Wenn man also solche Streams, wie sie z.B. von einem aktuellen x264 erzeugt werden, dekodieren will, dann muss man derzeit zwangsläufig auf einen anderen Decoder zurückgreifen...