Threadanzahl für x264

Ach Gottchen, 4 Stunden? ... Als wir noch DVDs in DivX 3.11α mit Nandub SBC konvertiert haben, lief das üblicherweise die Nacht durch ... Jammern auf hohem Niveau! :zunge:

Zitat

was wohl daran liegt, das diese 50FPS haben.

Wobei man vermutlich die Hälfte der Bilder auch verwerfen könnte, da es vermutlich eh nur doppelte sind,.. *gig*
Kann LigH aber nur zustimmen, ich erinnere mich hier noch an Aktionen wo ich erst 2 Tage lang den Rechner hab laufen lassen um das AvisynthSkript erst mal nach HuffYUV zu rendern und dann noch mal 2 Tage um den 2pass Xvid encode hinter mich zu bringen,... nur um am Ende festzustellen, dass ich irgendwas falsch eingestellt hatte und das ganze noch mal machen darf.

Zitat von Der_Lurchi

Bei HD Material sehe ich keine so großen Sprünge, selbst wenn ich testweise auf "fast" Presets gehe, wird das nicht soo wesentlich schneller als wie unter slow. Bei niedrig auflösenden Sachen (DVDs usw) ist der Unterschied von fast zu slow Presets hingegen sehr deutlich spürbar (teils um das doppelte mehr FPS).

Also ein Faktor von zwei ist bei slow/fast durchaus normal und wird bei mir auch bei HD-Material erreicht. Achte mal auf die CPU-Auslastung bei der HD-Encodierung unter preset fast, ob dort nicht ein Flaschenhals sitzt.

Das Limit der CPU-Auslastung wird vor allem dann erreicht, wenn Register auf Daten warten müssen, die sie von außerhalb des Prozessors laden müssen. Je weniger also zu rechnen ist, umso öfter gibt es auch noch Pausen.

Eben weil da weniger Daten zu verarbeiten sind. Entsprechend müssen auch weniger Daten zwischen RAM und RAM und Festplatte hin und her geschaufelt werden, worauf die CPU warten müsste. Bei einer überschaubaren Datenmenge trifft dann auch der Level-2- oder gar Level-3-Cache öfters mal.

Meine Erfahrung ist, dass x264 eigentlich durch die Bank gut skaliert. Nochmal einen Testlauf mit einer 5-Minuten-Sequenz gemacht:

1080p Source, geladen mit Avisynth/DGDecodeNV, x264_r2146 --crf 21 , alles in x86_64 , auf i7-860 (4C8T)

--preset veryfast: 41.83 fps, 6144.61 kbps, CPU 50~70%--preset faster:   31.47 fps, 6898.15 kbps, CPU 80~95%--preset fast:     22.16 fps, 7158.45 kbps, CPU 99~100%--preset medium:   18.37 fps, 6881.94 kbps, CPU 99~100%--preset slow:     10.02 fps, 6823.69 kbps, CPU 99~100%--preset slower:    6.15 fps, 6641.32 kbps, CPU 99~100%--preset veryslow:  3.07 fps, 6205.86 kbps, CPU 99~100%

Skaliert doch recht gut.

Dass bei schnellen Presets die CPU-Auslastung sinkt (und mithin auch die Skalierung), liegt vor allem an der "Frametype decision": die ist nämlich noch nicht parallelisiert (oder nur wenig). Deswegen wird die Performance von dem Thread limitiert, der die Frametype decision durchführt.

Das Parallelisierungs-Problem ist knifflig: durch die vielen internen "Tools" gibt es zu jedem Zeitpunkt einen ganzen Strauß an verschiedenen Möglichkeiten, wie man die I/P/B-Verteilung anordnen kann, es muss also einiges probiert und geschätzt werden. Und vor allem: solange noch nicht entschieden ist, was mit Frame N eigentlich gemacht wird, solange kann auch noch nicht entschieden werden, was mit den später nachfolgenden Frames N+x am besten zu tun ist.
Die Frametype decision ist praktisch (noch) der Knackpunkt, an dem die ganze Parallelisierung auf eine rein lineare Kette zusammenbricht, bzw. auf den linearen Anteil warten muss.

Praxis: das Spiel von oben nochmal, mit --veryfast, aber diesmal im 2-pass-Verfahren. Hier wird die Frametype decision ja nur im 1.Pass durchgeführt. Der 2.Pass rechnet praktisch das gleiche wie zuvor oben, nur dass er eben keine Frametype decision mehr durchführen muss ...

--preset veryfast ,  2-pass


--pass 1         : 50.11 fps, 6293.60 kbps, CPU 35~50%
--pass 2         : 77.38 fps, 6155.47 kbps, CPU 99~100%

Hoppala... im Vergleich zu CRF: 60% --> 100% , und 41.8 --> 77.4 fps. Nur weil keine I/P/B-Entscheidungen mehr getroffen werden müssen.

Wenn der Arcsoft DTS Decoder ein DirectShow-Decoder ist, dann könnte er möglicherweise per DirectShowSource verwendbar sein. Vorausgesetzt, du hast auch einen Quellfilter, der *.dts-Dateien als DTS erkennt und weiß, dass der Arcsoft-Decoderfilter dafür geeignet ist.

Andere Möglichkeiten wären wohl FFAudioSource oder NicDTSSource. Da dies native AviSynth-Plugins sind, würde ich die vorziehen, außer es gibt gute Gründe, einen DirectShow-Decoder zu verwenden.

Und dann willst du aus VirtualDub heraus eine AC3-Tonspur encodieren? Womit? Mit dem AC3ACM-Codec von ffcHandler? Dann vielleicht doch lieber via MeGUI mit Aften?

Sicher, im ZIP-Archiv von DGDecNV liegen auch ein paar HTML-Dateien, z.B. die DGDecodeNVManual.html. Lesen! Und dann AviSource() gegen DGSource() austauschen (mit entsprechenden Parametern).

Wer übrigens erst croppen und dann skalieren will, kann auch beides in einem – sogar effizienter: Resize()-Filter in AviSynth unterstützen auch eine "Ausschnittsvergrößerung" mit vier zusätzlichen Parametern. DGSource() ebenso, wenn man sowohl crop- als auch resize-Parameter angibt.

Zitat von Der_Lurchi

Was meinst du mit "austauschen"?
Wenn ich die Zeile DGSource("Dateiname.dgi", resize_w=1280, resize_h=720) austausche mit: AVISource("Dateiname.dgi").Crop(10,10,5,5).BilinearResize(1280,720)
Gibts die Meldung "Avisynth open failure"

Das ist ja auch genau das Gegenteil von dem, was ich meine (ist ja klar, dass AviSource keine *.dgi öffnen kann):

Zitat von Der_Lurchi

AVISource("Dateiname").Crop(10,10,5,5).BilinearResize(1280,720)

^ Darin AviSource() ersetzen durch DGSource().

Deine Crop-Angaben sind etwas unlogisch. Du willst also nur 5×5 Pixel ab Position (10,10)? Oder doch eher links udn rechts 10 Pixel weg, sowie oben und unten 5?

DGSource("Dateiname.dgi").Crop(10,5,-10,-5).BilinearResize(1280,720)

oder

DGSource("Dateiname.dgi").BilinearResize(1280,720,10,5,-10,-5)

oder so ähnlich, ungetestet. Also: BilinearResize auf 1280×720 den Ausschnitt mit Rand 10 von links, 5 von oben, 10 von rechts, 5 von unten.

Allerdings sind 5 Zeilen oben und unten vielleicht keine gute Idee, ungerade Anzahlen in der Höhe sind immer etwas riskant. Vielleicht lieber 6.

Ich weiß nicht, welche Methode die GPU verwendet. Wahrscheinlich bilinear, eventuell bikubisch. Bei DGDecNV ist es wohl nicht dokumentiert.

AviSynth rechnet bei seinen Funktionen mit der CPU. Hier hat man eine recht große Auswahl, was aber auch heißt, dass man selber wählen (und alle mal ausprobieren) muss, was einem in welchem Zusammenhang am besten gefällt. Je mehr "Taps" (Stützpunkte) verwendet werden, umso höher ist der Rechenaufwand, aber das Ergebnis muss deswegen nicht unbedingt "schöner" wirken. Im Gegenteil, aufwändigere Funktionen können eher zum Ringing neigen als einfachere. Beim Verkleinern hatten wir unter anderem mal Spline16 vorgeschlagen.

ResampleHQ - Kernels (erfordert Browser mit Unterstützung von HTML 5 und JavaScript Canvas)

Zitat von Der_Lurchi

Den Arcsoft Dekoder habe ich derweil im eacto3 ans laufen gekriegt (was btw. auch diese Clipping Errors fixt ) Vermutlich wirds wohl letzlich dann doch am sinnvollsten sein, den video Stream über DGDecNV/Avisynth/vdub und das audio seperat weiter über eacto und die Spuren anschließend mit Avimux wieder zusammenführen?

Ich würde zuerst den Ton encodieren und dann in VirtualDub (mit AC3-Plugin) direkt die bereits fertige Tonspur wählen. Damit sparst Du Dir einen Arbeitsschritt.
ArcSoft direkt als AviSynth-Plugin habe ich noch nie gesehen, kenne da auch nur den DirectShow-Weg. (Bzw. genaugenommen würde ich H.264 nicht in AVI packen, aber das wurde hier ja schon bis zur Vergasung diskutiert.)