x264 selbst ist durchaus multithreading-fähig. Allerdings weiß ich nicht, ob man in StaxRip selbst speziell dafür sorgen muss, dass passende Kommandozeilenparameter dafür verwendet werden (--threads # --thread-input).
Außerdem ist die Filterung in AviSynth oft genauso zeitaufwändig, und ohne spezielle Vorkehrungen (AviSynth-MT + MT.dll + MT() im Skript) auch nur auf einen Kern beschränkt.
Wie sieht den das verwendete Avisynth-Skript aus?
nur wenn ich dann den Job starten will sagt mir der Job Manager -Crashed- ?!?!
Hatte letztens das Windows Paket aktualisiert, weil die Version die ich erst hochgeladen hatte noch eine x264 Version enthielt, bei der der Filter-Patch integriert war, der dann mit dem normalen Aufruf kollidiert ist.
-> werde ich mal testen, ansonsten kannst Du einfach die x264 Version im Paket durch eine aktuelle Version von http://x264.nl austauschen. Hier auch mal ne aktuelle Version des Paketes wie ich es aktuell nutze: Hybrid32bitPackage_100503
(Falls das nicht hilft müsstest Du Dich schon herablassen und ein paar mehr Informationen liefern ansonsten kann ich das Problem nicht nachstellen)
Meinst du das : --crf 18 --level 4.1 --no-mbtree --b-adapt 2 --b-pyramid strict --deblock -1:-1 --me umh --threads 6 --aq-strength 1.1 --thread-input --output
Nein, dass ist der x264 Aufruf.
Wo finde ich das ?
k.A. nutze kein StaxRip
Findet man im Temp-Ordner des Projektes.
Etwa das hier ?
LoadPlugin("C:\StaxRip_1.1.6\Applications\AviSynth plugins\DGAVCDecode.dll")
AVCSource("H:\********* temp files\********.dga")
Crop(0,0, -Width % 8,-Height % 
ConvertToYV12()
Crop(0,132,-0,-132)
LanczosResize(1536,656)
Ja. 
Komische Auflösung die StaxRip da zusammenbaut, sollte aber nicht am Avisynth Skript liegen.
Benutze für die Auflösung doch etwas in Richtung 720p, es währe noch etwas Ressourcenschonender und je nach Fernseher und Sitzabstand sind die unterschiede vermutlich nur im direkten vergleich sichtbar.
Gestern auf der erfolglosen suche nach einem neuen Fernseher konnte ich zwei Modelle gleicher Hersteller (50er Plasma) mit unterschiedlichen Auflösungen vergleichen, der eine hatte 1920x1080 und der andere 1366x768 die unterschiede bei HD waren erstaunlich gering.
Ähnlich wird es sich sicherlich auch bei dem unterschied zwischen 1080 und 720 verhalten.
Hinweis zur Auflösung:
DXVA-Beschleunigung durch die Grafikkarte funktioniert überhaupt nur, wenn das Video exakt eine der typischen Standardauflösungen hat. Unter Umständen müsste man also sogar mit Letterbox (schwarzen Balken) encodieren, damit man beschleunigte Ausgabe überhaupt nutzen könnte ... falls das für dich irgendwie wichtig wäre. Aber wenn dein Prozessor schnell genug ist, ist das auch eher unwichtig.
__
Zur Mehrkern-Nutzung:
Wenn du sowohl "--thread-input" als auch { "--threads 0" | "--threads 2" } in der Kommandozeile hast, und trotzdem immer nur ein Kern ausgelastet wird, dann musst du irgendwas im System falsch haben, dass eine Mehrkern-Nutzung verhindert wird. Aber dann auch was eher hardwareabhängiges. Kann man so was im BIOS deaktivieren?! Kann Mehrkernunterstützung fehlen, wenn bestimmte CPU-Updates nicht installiert sind? Ständig exakt 0% hab ich auf einem Mehrkernsystem eigentlich niemals, irgend ein anderer Prozess hat eigentlich immer auch etwas Rechenzeit auf dem anderen Kern.
Welches Betriebssystem und welchen Prozessor hast du (so exakt wie möglich)? -- Ausführliche, aber trotzdem kostenlose Diagnose z.B. mit HWiNFO32.
LigH: zu DXVA: Sicher, dass nicht alles unter der maximal Auflösung was mod16 ist geht? (hab ich so im Kopf)
Nicht sicher. Aber der DXVA-Tester zeigt wohl so eine Art Info an, als ob es spezielle Bildflächen-Unterstützung gäbe... ?!
Noch mal nachgelesen und ein paar Kumpels gefragt: DXVA ist momentan wohl wirklich so eingeschränkt. (k.A. warum ich es anders im Kopf hatte)
Muß ich bei Windows 7 den Dual Core treiber installieren ?
So etwas wie einen "Dual Core Treiber" gibt es nicht 
Es gibt da wohl so ein AMD Tool, dass die Mehrkern-Auslastung "optimieren" soll, in dem es die CPU Kerne geschickt an die Anwendungen bindet, ab notwendig ist das nicht.
Windows unterstützt von Haus aus mehrere Kerne/Prozessoren, spätestens seit NT 4.0 Zeiten.
Die normale "Home" Version von Windows 7 ist soweit ich weiß auf 2 CPU-Sockel beschränkt, aber das reicht immer noch locker für ein 8 oder neuerdings sogar 12 Kern-System!
x264 skaliert übrigens problemlos auf mindestens 16 Prozessor Kerne:
http://img684.yfrog.com/img684/7954/x26416cores.png
Zitat von LighWenn du sowohl "--thread-input" als auch { "--threads 0" | "--threads 2" } in der Kommandozeile hast, und trotzdem immer nur ein Kern ausgelastet wird, dann musst du irgendwas im System falsch haben, dass eine Mehrkern-Nutzung verhindert wird.
Korrekt wäre "--threads 3" für ein 2 Kern System. x264 verwendet intern die Formel 3/2 * Anzahl der CPU-Kerne.
Das einzige was mir einfallen würde, um die Mehrkern-Nutzung zu verhindern, wäre die Affinität des Prozesses auf eine einzigen Kern zu setzen (z.B. mit ProcessExplorer).
Ich glaube daher eher, dass er irgendwo einen Bottlenck in der Quelle hat. Oder ein vermurkstes x264 Build ohne pthreads 
EDIT: Vielleicht sitzt der Wurm aber auch mal wieder in Avisynth. Ich würde vorschlagen es mal direkt mit FFM2 Input zu versuchen, anstatt den Umweg über Avisynth zu gehen.
Zitat von LighAber dann auch was eher hardwareabhängiges. Kann man so was im BIOS deaktivieren?!
Hyper-Threading kann man deaktivieren. CPU-Kerne komplett lahm zu legen wär mir neu - kenn mich aber mit AMD weniger gut aus.
Aber selbst wenn es so was im BIOS gäbe, dann würde auch das OS den zweiten Kern nicht mehr "sehen" und ihn dementsprechend im Taskmanager erst gar nicht anzeigen...
Ich war der Meinung, "--threads 0" verwendet automatisch eine "optimale" Anzahl... oder passiert das nur beim Weglassen des Parameters? Steht leider auch bei "--fullhelp" nicht ausführlich drin.
Außerdem ist - wie schon geschrieben - eigentlich eine Auslastung von "100% / 0%" höchst unwahrscheinlich, wenn Windows auch nur ansatzweise eine Lastverteilung macht, weil immer irgend ein Systemthread auch mal etwas Rechenzeit braucht. Da wäre die versehentliche Nutzung einer x264-Version ohne Threading-Unterstützung schon wahrscheinlicher.
Ich war der Meinung, "--threads 0" verwendet automatisch eine "optimale" Anzahl... oder passiert das nur beim Weglassen des Parameters?
Das stimmt ja auch. Ob man "--threads" einfach weg lässt oder ob man "--threads 0" übergibt ist egal, weil der Default-Wert schon "--threads 0" (aka "Auto Detect") ist. Was ich meinte ist, das x264 die "optimale" Thread-Anzahl als 3/2 * Anzahl der Kerne bestimmt, d.h. auf einem 2-Kern System wären das 3 threads. In diesem Fall entspricht "--threads 0" also "--threads 3" und nicht "--threads 2". Ein System mit N Prozessor-Kernen würde nur dann von genau N Threads voll ausgelastet, wenn jeder Thread immer etwas zu tun hat und wenn kein Thread jemals auf Daten von einem anderen Thread warten muss. Das ist in der Praxis eher selten der Fall, weshalb es durchaus sinnvoll sein kann, mehr Threads als Kerne zu erzeugen.
(Etwas Off-Topic, aber egal: Wenn man für GPU's Programmiert, dann erzeugt man sogar um Größenordnungen mehr Threads als man Rechenkerne hat, weil man damit die Delays mit Berechnungen "verstecken" kann und weil GPU Threads praktisch keinen Overhead haben - im Gegensatz zu den relativ schwergewichtigen CPU Threads)
Außerdem ist - wie schon geschrieben - eigentlich eine Auslastung von "100% / 0%" höchst unwahrscheinlich, wenn Windows auch nur ansatzweise eine Lastverteilung macht, weil immer irgend ein Systemthread auch mal etwas Rechenzeit braucht.
Das ist in der Tat seltsam. Selbst wenn nur einen Anwendung nennenswert Rechenzeit beansprucht und diese Anwendung nur einen Thread hat, schiebt Windows die Rechenlast trotzdem zwischen den Kernen hin und her. Normalerweise würde man daher so ungefähr 50% Auslastung auf beiden Kernen erwarten, anstatt 0%/100%. Sofern nicht an den Affinitäten gedreht wurde...
Zwischenfrage zur Threadanzahl - verwendet x264 wirklich immer noch Cores*3/2 als Default, oder ist das mal auf Cores*1 geändert worden? Meine, mich ganz dunkel an eine Diskussion darüber zu erinnern...
Wegen-und-Weil: Hyperthreading. Wenn ein z.B 4-Core ohne HT läuft, dann macht Cores*3/2 sicherlich Sinn, um den Prozi mit 6 Threads besser auszulasten. Aber, wenn ein 4-Core mit HT läuft, dann macht Cores*1 vermutlich mehr Sinn: 8 virtuelle Kerne auf 4 physischen Cores ... 8 Threads sollten da sehr gut auslasten. 12 Threads wären da vrmtl. schon wieder leicht kontraproduktiv.
Hmh ... vielleicht kann ich's am WE mal selber testen.
Edit - @ LaGu1:
Könntest ja mal einfach z.B. das LinX-Tool zum Testen verwenden. Einfach entpacken, linx.exe laufen lassen, und dann mal im Taskmanager sehen wie die Auslastung sich darstellt. Wenn dabei nicht alle Kerne nahezu vollständig ausgelastet werden, dann stimmt mit dem System etwas nicht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
