Unklarheiten bezüglich neueren x264CLI Optionen

Zitat

"r474: separate --thread-input from --threads"
=> Bedeutet das, die Option separiert den thread der für die Synchronisation der anderen threads zuständig ist von diesen, was auf Multi-Prozessor/-Core System nochmal einen leichten boost geben sollte?

#ifdef HAVE_PTHREAD
   [B] if( b_thread_input || param->i_threads > 1 )[/B]
    {
        if( open_file_thread( NULL, &opt->hin, param ) )
        {
            fprintf( stderr, "threaded input failed\n" );
        }
        else
        {
            p_open_infile = open_file_thread;
            p_get_frame_total = get_frame_total_thread;
            p_read_frame = read_frame_thread;
            p_close_infile = close_file_thread;
        }
    }
#endif

Du bekommst also threaded Input wenn du threads>1 stellst, oder --thread-input verwendest.
Falls du keine Slices verwenden möchtest, kannst du so immernoch davon profitieren.

Wieso? Wenn --threads > 1 oder --threaded input, soll x264 einen speziellen Thread für Prefetching verwenden.

Die Geschwindigkeitsgewinne, die im englischen Forum berichtet wurden, waren teilweise recht groß.

Bestätige - Dateioperationen in einem eigenen Thread sind häufig sehr empfehlenswert, auch für 1-Core-PCs. Nicht umsonst verwenden z.B. VirtualDub* und HeadAC3he dafür eigene Threads.

Die Option "--thread-input" ist somit generell (auch für 1-Core-PCs) nützlich, und für Multi-Core-PCs sollte man dann so viele Rechen-Threads wie Cores verwenden (der Disk-Thread teilt sich da schon rein, der braucht nicht viel Zeit).

1) Inhaltlich richtig. Rechtschreibung wird noch mal in einem etwaigen separaten Thread behandelt!
2) Ich glaube ja - denn zwischen mehreren Encoding-Threads muss ja ein Synchronisations-Thread "verhandeln", und der kann auch gern den Dateizugriff mit übernehmen, er muss ja die Daten verteilen.
3) Das wollte ich damit ausdrücken.

1.) Der Input Thread liest die Quelldaten ein, er erledigt auch ggf. die avisynth arbeit (VirtualDub macht das auch, Doom9 hat im Codec Comparison angemerkt, dass das deutliche Gewinne gebracht hat bei (damals noch nicht SMP optimierten) XviD. In die Ausgabedatei schreiben wird vom Hauptprozess gemacht.

2.) Das geht aus dem Stück Code hervor, das Sade gepostet hat, ich denke, dass das auch so im svn steht

3.) Weiß ich nicht, hab ich nicht ausprobiert, aber im englischen Forum wurden teilweise kleine Gewinne für Single Core berichtet (aber wie verlässlich das ist weiß man ja nicht).

Zitat

Hmm,.. wenn es keine Gewinne für Single CPUs bringen sollte ist der Parameter sinnfrei, da er dann ja nur sinnig ist wenn man eh mehrere Threads benutzt in welchem Falle er ja nichts extra macht. (davon ausgegangen Leute die mehrere Cpus/Cores haben auch Threads >1 benutzen)

Slices (die mit threads>1 gebildet werden) reduzieren die Qualität ein wenig.
Deswegen kann es sinnvoll sein keine Threads zu benutzen auch wenn man mehrere CPUs benutzt. Außerdem hatten (haben?) einige Decoder Probleme mit Slices.

Zitat

Hab hier mal angetestet und da bremst es eher bei SingleCPUs:

1. ohne --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 2
=>encoded 3621 frames, 16.20 fps, 1863.25 kb/s

2. mit --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1 --thread-input
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 3 --thread-input
=>encoded 3621 frames, 16.08 fps, 1863.25 kb/s

=> Wäre hilfreich wenn noch ein paar andere Leute das Testen könnten.

Cu Selur

Alles anzeigen

Der Test ist sinnlos wenn du nicht dein avs script postest.
Aber ich verstehe auch nicht was es bei Single Core CPUs bringen soll.

Aber die Qualitätsunterschiede sind sehr gering. Ich glaube nicht, dass irgendjemand durch Hinschauen einen Unterschied zwischen einer sliced und nicht sliced Variante eines Encodes erkennt.

Gerade im englischen Board aufgeschnappt:

Der Prefetch Thread hilft, wenn die CPU nicht der limitierende Faktor ist, also wenn man z.B. unkomprimiertes Quellmaterial verwendet.

Zitat

Aber die Qualitätsunterschiede sind sehr gering. Ich glaube nicht, dass irgendjemand durch Hinschauen einen Unterschied zwischen einer sliced und nicht sliced Variante eines Encodes erkennt.

Ist wahrscheinlich für die selben Leute gedacht, die auch --me esa verwenden.

und 3Pass

bei DVD* Auflösung hast du:
704 * 576 * 12/8 = 608256 Bytes (~0.58 MB/Base 1024) pro Frame.
Also bei >10fps könnte es etwas bringen.

*unkomprimiert was sowieso kaum jemand verwendet

Aus dem englischen Forum von pengvado persönlich:

Zitat

"On that topic, is there any real situation in which someone wouldn't want to use --thread-input?"
If input is piped from another program. That's inherently multithreaded, and the data to read is already in memory, so --thread-input will only increase the syncing overhead.
Or if the avisynth script is really cpu-bound.