Es ist aber nicht möglich, 2 oder mehr Files gleichzeitig zu machen. Glaub' mir, ich hab das x-mal versucht, und ES GEHT EINFACH NICHT. Reine Zeitverschwendung!
Und zu dieser absolut unumstößlichen Tatsache verbitte ich mir jede weitere Diskussion!
:ja:
Gibt es kein Tool, das 2 oder mehr Files parallel kann?
Natürlich gibts das. Nennt sich x264.exe. Einfach Konsole aufmachen, tippen, starten. Wiederholen, bis RAM und/oder Rechenleistung alle sind.
Wenn du eine nvidia hast & BD/HD Material encoden willst, bringt DGIndexNV einen Zeitgewinn und ein Cuda Rauschfilter.
vdub ist in der Lage Videofilter in mehrere treads aufzuteilen (wobei das bei Cudabasierten Filtern wurscht ist)
Mehrere Jobs kann man in eine batch ablegen und machst halt zwei vdub Fenster auf oder so, oder ebend direkt mehrfach über die x.264.exe - obwohl ich nicht so ganz verstehe, wofür das gut sein soll - weil man hat doch idr. beim H.264 encoden normallerweise schon bei einem file idr. 90-100% CPU Auslastung?
(aber vielleicht habe ich auch falsch verstanden was du vorhast)
Ein AviSynth-Skript kann immer nur Video an ein einziges Programm weiterleiten.
Wenn man aber mehrere Videoprogramme bzw. Encoder gleichzeitig laufen lässt, dann können die schon jedes für sich ihr eigenes AviSynth-Skript als Videoquelle verwenden.
Es mag nur vielleicht bisher keine GUI geben, die mehrere Encoder gleichzeitig startet und überwacht. Daher bleibt dir derzeit nicht viel anderes übrig, als mehrere GUIs oder zumindest mehrere Kommandointerpreter (cmd.exe) zu starten, um mehrere x264 mit ihrer jeweiligen Kopie einer AviSynth-Videoquelle laufen zu lassen.
Dann wäre es eventuell empfehlenswert, die Anzahl der von jeder x264-Kopie genutzten Rechenkerne zu begrenzen.
Ja, so war das auch gemeint - nur inwiefern bringt das was?
Bei Preset Slow hat man (z.b. 1080p zu 720p) idr. schon 99-100% CPU Auslastung: http://www.fotos-hochladen.net/uploads/x264bfigebdml1p.jpg
Selbst mit Preset Fast liegt man noch im Schnitt bei ~95%.
Welchen Vorteil soll das daher eigentlich bringen zu parallelen und mehrere x.264 encoder gleichzeitig- wenn doch bei nur einem laufenden Encode faktisch keinerlei CPU Reserven mehr freibleiben oder verhält sich ein I7 dsbzgl. anders?
Oder anders ausgedrückt: Wenn die CPU-Auslastung bei der Konvertierung deutlich unter 80% liegt, dann verzögert irgend eine andere Hardware-Komponente die Lieferung encodierbarer Daten, und dann langweilt sich x264, weil es weit vorher schon klemmt.
So wird es dann auch wohl sein wie du sagst, hatte ja anfangs auch div. Probleme mit schlechter CPU Auslastung und lag letztlich primär (jedenfalls bei meiner Hardwarekonstellation) nur am verwendeten Dekoder (sowie am verwendeten build)
[Von irgendwelchen Filtern usw., die nicht MT fähig mal abgesehen]
Das liegt ganz einfach an der Tatsache, dass AviSynth ein Frameserver ist. Ein Frameserver ist dazu da, einem nachgeschalteten Programm ein Video zu liefern. Und ein Videoencoder encodiert üblicherweise immer nur je ein Video. Will man zwei Videos gleichzeitig encodieren lassen, muss man den Encoder zwei Mal starten.
StaxRip selber hat mit der Videokonvertierung auch eigentlich gar nichts zu tun. Es ist nur eine Benutzeroberfläche. Es baut ein AviSynth-Skript zusammen und ruft dann einen Encoder auf, der das Skript verarbeitet. Sobald die Konvertierung beginnt, tut StaxRip nicht viel mehr als darauf zu warten, dass sie fertig wird.
Oh-oh, hier scheint Verwirrung entsrtanden zu sein. Um es mal ganz einfach auszudrücken:
Eine Instanz von Avisynth kann nur eine Instanz einer Anwendung bedienen.
Es ist aber durchaus möglich, dass Instanzen mehrerer Anwendungen jeweils ihre eigene Instanz von Avisynth benutzen.
Es ist sogar möglich, dass eine einzige Instanz einer Anwendung mehrere Instanzen von Avisynth gleichzeitig verwendet. (Nämlich: wenn im *avs-Script ein weiteres *avs-Script per AviSource() geladen wird.)
Und dann gibt's noch Tools wie Hybrid, da werden von einer Instanz des GUIS ggf. mehrere Instanzen von CLI-Tools gestartet, die dann nach Belieben ihre eigenen Avisynth-Instanzen verwenden können.
Ist doch also eigentlich ganz einfach. 
(Das alles natürlich nur, soweit der Systemspeicher ausreicht.)
Ein Cuda Denoiser ist die Frage ob der was bringt. Also ist der schneller, als wenn man die CPU das machen lässt. Der fft3dgpu ist es nicht.
Zu den Denoisern kann ich nicht viel beitragen, da ich sie bei Blueray-HD.Material faktisch nie benutzte und etwaiges Grundrauschen in hochauflösenden Material doch meist über den Encoder mittels der Deadzone usw. angehe (statt Trellis dann zu nutzen)
Bislang hatte ich daher auch nur sehr wenige male einen Denoiser benötigt und hatte dafür diesen genommen:
http://compression.ru/video/denoising/index_en.html
Die CPU Auslastung lag auch damit immer bei 95-100% und ich konnte keinen größeren Zeitunterschied beim encoden (also wie ohne den Denoiser) feststellen. Ich hatte das jedoch in vdub genutzt, weiß daher auch nicht was/ob es da alles an cuda Sachen überhaupt für staxrip gibt.
Das was ich nur weiß, das manche Cudasachen (v.a. DGIndexNV) mit den neueren Nvidia Treiber irgendwie schlechter laufen (zumindest mit meiner 9800GTx) und bin daher zurück auf eine ältere (275.33) Nvidia Treiber Version.
Es ist sogar möglich, dass eine einzige Instanz einer Anwendung mehrere Instanzen von Avisynth gleichzeitig verwendet. (Nämlich: wenn im *avs-Script ein weiteres *avs-Script per AviSource() geladen wird.)
:eek: Grusel... da würde ich lieber schauen, ob Import() auch klappt.
Vermutlich könnte eine Anwendung auch mehrere Instanzen von AviSynth verwenden, wenn sie mehrere Videoquellen gleichzeitig verarbeiten würde. Dann könnte man vielleicht ein Programm entwerfen, welches selbst Encoderbibliotheken integriert hat (wie Avidemux) und damit mehrere Videoquellen parallel in mehrere Zieldateien konvertiert. Vorausgesetzt, dass z.B. libx264 reentrant ist (also parallelisierbar, ohne dass mehrfache Aufrufe die Kopien intern durcheinanderbringen).
Aber wenn das ein 32-bit-Programm wird, dann hätte es für alle gleichzeitig laufenden Konvertierungen nur insgesamt 2 GB RAM zur Verfügung. Und wenn es ein 64-bit-Programm wird, dann müsste es mit 64-bit-AviSynth klarkommen, welches leider noch längst nicht gleich weit entwickelt und alles andere als zuverlässig ist. Vielleicht könnte es sich mehrere 32-bit-AviSynth-Prozesse pipen lassen, so wie MeGUI den 64-bit-x264 ansteuert, aber das ist wieder Extra-Aufwand.
__
Moment. Ich weiß im Moment gerade nicht genau, was ein "Worker" ist ... aber vielleicht kann man mit mehreren davon mit der MeGUI mehrere Konvertierungen in der Job-Liste parallel abarbeiten lassen?
Wenn das stimmt, dann gibt es vielleicht doch schon ein Programm, das die Wünsche von trecordings erfüllt.
:eek: Grusel... da würde ich lieber schauen, ob Import() auch klappt.
Import ist der normale Weg, den man natürlich (fast) immer nehmen sollte.
Zusätzliche Avisynth-Instanzen braucht man für Spezialfälle, z.B. wenn Globale Variablen aus verschiedenen Scripten miteinander kollidieren, oder wenn komplexe Runtime-Geschichten betrieben werden. (Z.B. "Srestore" - das lässt sich generell nur einmal innerhalb eines Scriptes verwenden. Wenn man nun aus irgendwelchen Gründen zwei Varianten von Srestore-Bearbeitung miteinander verwursteln will oder muss, dann muss man eben etwas "gruseliges" machen.);)
Dann hast du das Problem immer noch nicht verstanden: AviSynth wartet schon darauf, dass das Video endlich ankommt.
Womit wird eigentlich decodiert: DirectShowSource (mit welchem Decoderfilter) oder ein nativer AviSynth-Decoder?
Und welche Eigenschaften hat das Original-Video exakt (ausführliche MediaInfo-Analyse)?
Außerdem berücksichtigen: Wenn es eine Intel-CPU mit aktiviertem HT ist und unter Win7 läuft, dann sind 50% Auslastung (Taskmanager etc) per Daumenregel bereits etwa 80% absolute Leistungsauslastung.
Die stark vereinfachte Story ist die:
HT bringt durchschnittlich [nur] 20% Mehrleistung, Win7 ist intelligent & lastet zuerst die physikalischen Cores aus. Wenn alle phys. Cores belegt sind und die HT Cores sind frei, dann sind das 50% "logische" Auslastung, laut Taskmanager&Co. Die nächsten 50% Auslastung durch die HT Cores bringen dann aber, wie gesagt, nur noch ca. 20% mehr Dampf. (In Laborbeispielen 25-30%, aber Praxis ist halt was anderes.)
Bei HT-CPUs darf man sich nicht vom Auslastungswert verrückt machen lassen. Wenn bei gut 50% Last bereits 60fps anstehen, dann würde 100% Last bei 70~75fps landen. Nicht mehr. (Wer auf 60fps / 50% = 120fps gehofft hat, hat Luftschlösser konstruiert.)
Und Cuda geht mit dem gar nicht. Das Bild ist nicht ok.
Ja, dann weiß ich auch nicht. Bei mir funktioniert der Filter jedenfalls einwandfrei über die Grafikkarte und verursacht gut über 20% GPU Load.
ist bei mir nicht schneller als der hqdn3d
Mal, anderersrum gefragt - wieviel sind die Encodes denn eigentlich überhaupt schneller wenn du hqdn3d wegläßt?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
