XviD mit mehreren Prozessorkernen arbeiten lassen?

Xvid kann seit über 2 Jahren schon mit mehrkern prozessoren umgehen, das 1.2 Build gibts schon lang, nur wurde es nie Stabil released und war noch experimental.

Alexins hat in der 1.3er Version auch AutoSMP eingebaut. Seh auch gerade das es den in der Version 1.20 bzw. 1.21 auch geben soll. Normal müsste er deine 2 Prozessoren auch erkennen.

[Blockierte Grafik: http://img20.myimg.de/Aufnahme14f4a0_thumb.jpg]

Ist es denn bei dir auf 0? 100% wirst du aber auch nicht erreichen können mit VDM/VD, ca.70-85% mit den neuen Builds ist schon gut. Das mit AutoGK 100% gehen weiß ich nicht... nie was mit gemacht.

:eek: Hast recht - auch Koepi bietet nun Version 1.2.1, damit ist sie wohl "offiziell"!

Wie üblich die Empfehlung: Alte XviD-Versionen - wenn vorhanden - erst mal deinstallieren. Nur so zur Sicherheit.

Es sollte funktionieren, wenn man in den erweiterten Optionen (Button "Other Options...") im Register "Encoder" im Feld "Number of threads (0=autodetect)" Zahlen hineinschreiben kann, die nach dem Beenden und dem erneuten Aufruf der XviD-Codec-Konfiguration auch erhalten bleiben. "0" ist auch der empfohlene Wert, wenn man es nicht wirklich besser weiß (die optimale Anzahl Threads muss nicht zwangsläufig mit der Zahl der Kerne übereinstimmen).

Es ist möglich, dass AutoGK seinen eigenen XviD-Codec bevorzugt verwendet. Diese Vermutung ist ohne Gewähr.

Zitat von Drognaut

[...]
Habe dann zufälligerweise einen Versuch mittels AutoGK gemacht. Damit probeweise ein Stream encoded und siehe da XviD benutzte beide Kerne; Systemauslastung von 100%. Und die Zeit war die Hälfte dessen wie mit VDM.
[...]

Hallo,

das mit der Auslastung von Nahe 100% kann ich ja glauben, das gibt es seit ca 2 Jahren, aber der Speedup von 2 ist nur schwer zu schlucken.
Kannst Du bitte mal mit einer Stoppuhr (also absichtlich nicht auf die angezeigten fps verlassen) beide Szenarien mit dem gleichen Werkzeug stoppen?
Also AutoGK mit einem Kern gegen AutoGK mit 2 Kernen?

Wenn Du das Tool, die Xvid-Version und die Anzahl Kerne auf einmal tauschst, dann hat das Ergebnis ja nicht direkt mit dem XviD Speedup zu tun sondern ist eine Mischung.

bis besser,
T0B1A5 ... der sich fragt, warum es 2 Jahre gedauert hat bis die meisten Leute 1.2.0 entdecken und wieviele Jahre es wohl noch dauern wird bis die Masse ELDER4XviD entdeckt :p

Zitat von Lugia25000

Xvid kann seit über 2 Jahren schon mit mehrkern prozessoren umgehen, das 1.2 Build gibts schon lang, nur wurde es nie Stabil released und war noch experimental.

Hallo !

Und warum lastet dann AutoGK meine beiden Kerne zu 99% aus, auch wenn eine ältere XVID dabei war ?
Da muß schon ewig implementiert sein.
Und die Einstellung wieviel Threads ich haben möchte braucht eigentlich kein Mensch, oder ?

Doch... die Anzahl Threads ist schon wichtig. Sie hat auch einen Einfluss auf die Auslastung mehrerer Kerne. Allerdings auch auf die Qualität der Encodierung.

Zitat von LigH

Doch... die Anzahl Threads ist schon wichtig. Sie hat auch einen Einfluss auf die Auslastung mehrerer Kerne. Allerdings auch auf die Qualität der Encodierung.

Vielleicht wollen manche Zocker noch eine ZockCPU von XviD unbefleckt lassen :p
Ansonsten ist sicher eine AutoErkennung das Beste.

Bei XviDs SMP hat die Zahl der Threads keinen Einfluss auf die Qualität im Gegensatz zu X264 wo ein geringer Einfluss auf die RateControl da ist.

Aber warum diskutiere ich hier eigentlich mit? Privat habe ich immer noch einen SingleCore AMD, hehe.

bis besser,
T0B1A5

Auto GK hat seine eigene Xvid Version, wenn ich mir das changelog angucke und die letzte änderung sehe..
VERSION HISTORY 11 November 2007
2.48b
- XviD build downgraded to CVS 08/12/06 as in 2.40
- DGMpgDec updated to version 1.5.0 beta 12

benutzen sie eine Xvid Version aus dem Jahr 2006, wieso da 100% Auslatung gehen sollen und ob die auch wirklich 100% genutzt werden bezweifel ich, das prog muss da irgendwas mit zutun haben und selbst x% schlucken. Würd ich aber nie verwenden, wenn sie selbst so eine alte Xvid Version haben und wie es aussieht auch nix von VAQ oder sonst was drin haben. DGMpgDEC ist doch auch schon bei 1.5.2? Naja ich würd sowas nicht verwenden, wie gesagt.

Zitat von 708145

Bei XviDs SMP hat die Zahl der Threads keinen Einfluss auf die Qualität im Gegensatz zu X264 wo ein geringer Einfluss auf die RateControl da ist.

Nicht? — Hmm. Ich kann mir nie merken, ob die Parallelisierung immer noch über Slice-Bildung geht oder doch keinen Einfluss mehr auf die Vektorsuche hat...

Zitat von LigH

Nicht? — Hmm. Ich kann mir nie merken, ob die Parallelisierung immer noch über Slice-Bildung geht oder doch keinen Einfluss mehr auf die Vektorsuche hat...

Slice based parallelism war nur bei frühen X264 Versionen in Verwendung.

XviD SMP verwendet Zeilen von MacroBlocks die soweit parallel beerechnet werden, wie alle benötigten MBs auch schon da sind. Daher rührt der hohe Overhead!
Mein ELDER ist zwar effizient, aber passt eben nicht in Anwendungen wie AutoGK oder VDM, und damit interessiert sich kein Schwein dafür, dass man auch auf 64 Kernen kodieren kann
Dauert aber nur noch ca. 1 Jahr bis Intel den >64 Kern Atom rausbringt
< edit>Edith sagt grad, dass der aber eh net für HeimNutzer erhältlich sein wird sondern für SuperComputer. Schade, das. < /edit>

X264 hat ein Frame basiertes Modell: unabhängige Frames werden parallel kodiert. Das ist das intelligenteste hat aber bei XviD niemand implementieren wollen

bis besser,
T0B1A5

Ich frage mich gerade, ob es sonst irgend welche Umstände bei dir gibt, die beim manuellen Encodieren die Anzahl dafür verfügbarer CPU-Kerne auf 1 reduziert. So etwas kann man durchaus erzwingen, wenn das nötig ist, weil z.B. bestimmte Programme mit Mehrkern-Prozessoren nicht klarkommen. Aber warum sollte man, bei Video-Tools? Immerhin sind diese Eingriffe so speziell, dass du das sicher nicht vergessen hast, wenn du so etwas getan hättest...