x264 32Bit vs. 64Bit...

zwischen 10% und 15% soweit ich mich entsinne.

Zitat

Wobei... Solange es kein AviSynth in 64Bit gibt, macht's eh keinen Sinn...

Nur wenn man das AvisynthSkript direkt mit x264 öffnet,...

Lord Mulder hat da ein kleines Programm am laufen, gibt ein Thread im englischen Forum dazu.

Alternativ kann man auch mencoder als Decoder verwenden.

Es sollte noch erwähnt werden, dass die 64-Bit Version deutlich mehr Speicher adressieren kann.

Spätestens mit 1080p Material und entsprechend hohem "--rc-lookahead" bzw. "--me (t)esa" und/oder speicherintensiven Avisynth Skripten wird das wichtig!

Zuvor genanntes Tool findest man übrigens hier: http://forum.doom9.org/showthread.php?t=144140

LoRd_MuldeR:
Gibt es für dein Tool auch einen alternativen Link? Englisches-Doom9 scheint momentan tod zu sein.

http://dl.dropbox.com/u/3191920/x264…4.2009-11-25.7z

Ich setz' das mal hier mit rein...

Facts: Vista Ultimate 64bit, StaxRip 1.1.2.3beta, bzw. x264_64.exe (build 1369)

Encoding Flags: --crf 18 --ref 4 --no-mbtree --rc-lookahead 60 --bframes 4 --b-adapt 2 --direct auto --subme 8 --trellis 2 --me umh --sar 16:11 --fps 25 --deblock 0:0 --psy-rd 1.0:0.15 --threads auto --thread-input

Ich habe folgendes Phänomen:

Encodiere ich den Film mittels Staxrip (32bit) mit erhalte ich eine mittlere Bitrate von ~2500kbit/s.

Encodiere ich den Film per Console mit 64bit Encoder, geht die Bitrate durchs Dach und pendelt sich bei 7000kbit/s und mehr ein.

Aufruf ist wie folgt:

Zitat

pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe <flags> --output film.h264 - 720x576 : 4

Hat da jemand eine Erklärung? Das Script ist immer das gleich!

Gruss,
Bitspyer
</flags>

Ja. Offensichtlich verwendest du völlig unterschiedliche Parameter!

Deine oben genannten "Encoding Flags" (ich nehme mal an, dass das deine Staxrip Einstellungen sind) entsprechen in keinster Weise deinem Aufruf von x264_64.exe weiter unten

Um vergleichbare Ergbnisse zu erhalten, versuch es mal damit:
pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe --crf 18 --ref 4 --no-mbtree --rc-lookahead 60 --bframes 4 --b-adapt 2 --direct auto --subme 8 --trellis 2 --me umh --sar 16:11 --fps 25 --deblock 0:0 --psy-rd 1.0:0.15 --threads auto --thread-input --output film.h264 - 720x576 : 4

Einfacher wäre natürlich, sich an die Presets zu halten. In etwa so:
pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe --crf 18 --preset slower --tune film --output film.h264 - 720x576 : 4

@LordMuler: Hast Du eigentlich ein Szenario gefunden bei dem pipebuf einen (positiven) Geschwindigkeitsunterschied liefert?

Hab mal ein paar Tests gemacht und z.B.

pipebuf ffmpeg -r 25.000 -i "test.avi" -v 0 -vsync 0 -an  -r 25 -pix_fmt yuv420p -f rawvideo -  : x264 --crf 18 --fps 25 --output "D:\EncodingTemp\test_00_17_36_710.264" - 640x352 : 4

mit

ffmpeg -r 25.000 -i "test.avi" -v 0 -vsync 0 -an  -r 25 -pix_fmt yuv420p -f rawvideo - | x264 --crf 18 --fps 25 --output "D:\EncodingTemp\test_00_17_36_710.264" - 640x352

verglichen und konnte eigentlich keinen Unterschied in der Geschwindigkeit feststellen,..
(Testsystem: Windows 7 64bit, 6GB RAM, Intel SSD, aktuelle 64bit x264 und 32bit ffmpeg)

Ich habe pipebuf.exe in erster Linie geschrieben, damit man zwei Prozesse so starten kann, dass sie Daten über STDOUT/STDIN mittels Pipe austauschen. Der "|" Operator steht ja nur in der Eingabeaufforderung zur Verfügung, nicht aber wenn man einen Prozess direkt über CreateProcess() erzeugt. Man kann da natürlich Verrenkungen mit cmd.exe und dem /c Parameter machen, aber die Syntax (vor allem der Umgang mit Anführungszeichen) erscheint mir reichlich merkwürdig und ich habe dazu wenig bis keine offizielle Dokumentation gefunden. Das pipebuf.exe Tool erzeugt die Prozesse und die Pipe direkt über die Win32 API mit CreateProzess() und CreatePipe(). Dass man dabei die Größe des Pipe Buffers selbst festlegen kann, ist "nur" ein Nebeneffekt. Allerdings konnte ich keinen wirklichen Geschwindigkeitsgewinn gegenüber dem Default-Wert (0) feststellen. Das Optimum scheint bei 2 MB oder 4 MB erreicht, möglicherweise weil dies der Größe der Speicherseiten entspricht...

Ah, okay, mit dem QT Framework ist es recht einfach den STDOUT eines mit dem STDIN eines anderen Prozesses zu verknüpfen, hatte nur mal ein paar Files und unterschiedliche Buffergrößen (bis 50MB ;)) versucht und keinen Unterschied entdeckt weshalb ich dachte ich frag Dich mal.
-> Auf jeden Fall Danke für die ausführliche Antwort.

Cu Selur

Ups, da hat beim Posten der Editor etwas unterschlagen... Eigentlich sollte da noch stehen, das ich mittels Script und pipebuf.exe den x264_64.exe Encoder mit den selben Encoding-Flags aufrufe wie StaxRip.

Zitat von Bitspyer

Ups, da hat beim Posten der Editor etwas unterschlagen... Eigentlich sollte da noch stehen, das ich mittels Script und pipebuf.exe den x264_64.exe Encoder mit den selben Encoding-Flags aufrufe wie StaxRip.

Dann wäre es allerdings merkwürdig, wenn du zu unterschiedlichen Dateigrößen gelangst! Ich würde als nächstes mal die beiden resultierenden Dateien durch MediaInfo jagen und die tatsächlich verwendeten Parameter abgleichen. Es wäre hilfreich wenn du die MediaInfo Reports (Text Modus!) für die beiden Dateien hier postest...

OK.. hmm.. jetzt hab ich natürlich das eine File schon weggeworfen...

Reicht auch ein Ausschnitt? Ich würde dann einen Clip von ca. 10 Minuten encoden und mediainfo drauflassen.

Am besten wäre das kleinst mögliche Sample, dass den von dir beschriebenen Größenunterschied reproduziert. Ein 10 Minuten Clip sollte da normal reichen. Um die Parameter zu überprüfen reicht es allemal...

Tja, hmmm... jetzt bekomme ich es nicht mehr nachgestellt... Die Bitraten bleiben jetzt bei beiden Encodern im norm Bereich....:hm:

OK, ich habe wohl die Lösung gefunden...

mit dem avs2yuv wrapper muss man ja die Auflösung mit übergeben

Zitat

pipebuf.exe avs2yuv.exe film.avs -raw - : x264_64.exe <viele Flags> --output film.h264 - 720x576 : 4

Übergibt man nicht die korrekte, weil zB. cropping, dann geht die Bitrate durch die Decke.

Zitat von Bitspyer

Übergibt man nicht die korrekte, weil zB. cropping, dann geht die Bitrate durch die Decke.

Kein Wunder. Mit der falschen Auflösung interpretiert x264 die YUV Daten völlig falsch. Alles was dann übrig bleibt sind irgendwelche zufälligen Störmuster.

Sowas lässt sich natürlich nich effizient komprimieren. Mit dem CRF Modus schießt dementsprechend die Bitrate nach oben...