Threadanzahl für x264

Ja das x264vfw X6 Treading Problem ist gelöst und nachdem ich nun weiß, das diese AMD CPU die Ursache auch für viele andere Probleme ist, geh ich eins nachdem anderen an.
Für das Overlay Problem in div. Playern habe ich mittlerweile auch eine Lösung gefunden. Man kann über ein zusätzlich erstelltes Dword für die Processor specific graphics pipeline (PSGP) das AMD 3DNow! in der Registry deaktivieren, so daß statt 3DNow! auf SSE2 zurückgreifen wird. Das erfährt man natürlich nicht auf der Microsoft Seite - aber sieh da SSE2 statt 3DNow und VMR9, EVR C/A, Haali Overlays usw. funktioniert nun alles plötzlich mit dem X6. :ani_lol:
(bis auf MADVR)

Probleme in div. Games (auch diese nvidia ntdll. crashes) lagen ebenfalls an der CPU.
Für manche Sachen wie z.b. die Codemasters Games gibts auch div. Thuban Hotfixes usw, nur funktionieren die allerdings teils nicht, ohne das man zusätzlich noch manuell div Registry Einträge vornimmt.
Sowas hatte ich mit noch keiner CPU und ist extremly uncool. :cool:

hallo Selur
Wie gesagt scheint es imo mit dem Threadingoptionen des vdub zusammenzuhängen, allerdings tritt dieser Fehler nur sporadisch auf.
D.h. bei 20 encodings ist vielleicht 1 drunter was "falsch" ist. Mit der 1.9er scheint das eher nicht zu passieren, aber dort ist das Encoding natürlich auch wieder langsamer. Daher bin ich nun wieder zurück auf 1.10. und hab das Program mal nach jedem Encoding neugestartet, denn so wie es aussieht scheint das warum auch immer ebenfalls zu helfen.
Sehr eigenartige Sache.

MadVR läuft nun auch, nachdem ich dem KMPlayer nur 4Kerne zugewiesen habe und statt des internen KM Video Decoders einen externen nutze. Nur alles ziemlich viel gefrickel und hätt mir im nachhinein wohl besser einen Intel Quad gekauft (der ohnehin auch schneller ist), denn so manche Sachen scheinen ja nicht unbedingt sonderlich "AMD X6 optimiert" zu sein.

AMD Turbo ist deaktiviert. (der ist ohnehin total nutzlos und nicht vergleichbar mit der von Intels)
Bei DirectX9 Problemen liegt es einfach daran das manche Microsoft dll´s teils nicht mit mehr als 4Kernen in verbindung mit 3dnow umgehen können: http://www.progdigy.com/forums/viewtop…aa248a8b1c8074c
Seitens MS gabs für XP usw. zwar einen Hotfix, nur gibts den aber auf der Microsoft Seite nicht als öffentlichen Einzeldownload.

Und Thuban Probleme mit div. Games sind auch "OS-übergreifend":
http://community.codemasters.com/forum/f1-2010-…ading-race.html
Vor ein Jahr hatte ich F1 2010 gekauft (stürzte immer ab) und ein halbes Jahr später erst, gab es einen funktionierenden ThubanFix - nur, muß sowas eigentlich umgehend vom Hersteller kommen. Und bei irgendwelchen älteren Programmen, sind Hersteller auch nicht sonderlich bemüht noch Updates zu bringen und man kann in so Fällen, dann eigentlich nur die Kernanzahl begrenzen und darauf hoffen das dies alleine ausreicht.

Zitat

Vielleicht hilft es für diese unnötig beschränkten Programme, sich in der msconfig eine Kopie des BCD-Starteintrags zu erstellen, in welcher die Anzahl der "Prozessoren" (bzw. Kerne) auf 4 begrenzt wird - siehe Windows7Tipps; Kopieren vielleicht mit EasyBCD.

Auf dem PC wo ich encode nutze ich (zwar) noch XP, aber man kann Programmen ansonsten Kerne auch einfach per Easytools fest/dauerhaft zuweisen. Betroffen waren bei mir primär die alte Terratec (DVB-T) Software sowie der KMPlayer (allerdings nur in Verbindung mit MadVR).
Alles andere was ich an Software hab läuft mit dem X6 incl. aller Kerne ansonsten stabil. (von dem eigenartigen vdub Verhalten sowie dem Koepi xvid abgesehen, wobei ich da aber eher denke das es nur an dem Build liegt)

Gestern kam eine neue vfw Version 2146 und die verursacht in dieser Kombi Dropped frames:
mbtree 1 / rc_lookahead 60 / sync lookahead 4 (->die ursache)
r.2120 = X4 keine Dropped Frames
r.2146 = X4 Dropped Frames

Ok, was ist falsch an den sync_lookahead Wert?
Soweit ich das verstehe, setze ich doch mit rc_lookahead die Anzahl an vorausgesehnen Frames zum Ablgeich für das Macroblock Tree Ratecontrol. Und über sync lookahead definiere ich die Anzahl der Frames die im SyncPuffer genutzt oder gehalten werden können zwischen Lookahead und Encoding. (wodurch es auch etwas schneller läuft)

Oder .... habe ich die Funktionen falsch verstanden, falls ja- was hat es mit dem sync_Lookahead sonst aufsich?

Das beantwortet jedoch nicht so ganz, was sync_lookahead eigentlich tut und ob man das braucht.
(In den x264 Presets ist dieser Wert anscheinend nicht gesetzt)

Zitat

Ich glaube nicht, daß Du einen Fehler in den x264-Einstellungen finden wirst. Evtl. lösen die Einstellungen Fehler beim Decoder aus.

Also z.b. das MBtree ging mit alten Versionen (r.1085) zumindest mal nicht in Verbindung mit B-Pyramid.
Seit geraumer Zeit (hab die Versionen nicht alle nachverfolgt ab wann), funktioniert MBTree+Pyramid aber schon zusammen, da manche Sachen offensichtlich mit der Zeit in den x264 Revisionen geändert wurden (was ja mit dem vfw Interface letzlich wenig zu tuen hat).
Da ich nicht genau weiß, was es nun mit dem sync_lookahead aufsicht hat, weiß ich natürlich auch nicht - ob man an diesem (nichtgesetzten) Wert überhaupt etwas ändern sollte?

Hey, ja die GM Story ist cool. ;D
Wahrscheinlich läßt sich auch nix mehr groß optimieren.
An der Hardware läßt sich auch nix mehr drehen, beim X6 habe ich das max. beim oc schon rausgequetscht, werd mich wohl mit abfinden müssen das HD Material "dauert".

Zitat

z.B. ffmpeg2source oder neuron2s DGDecNV mit AviSynth, welche man auch direkt in VirtualDub öffnen kann

DCGecNV ist das nicht der Cuda Decoder(frameserver), welche Treiber Rev. braucht der und kostet der nicht auch Geld?
Was ist ffmpeg2source? (kenne nur das FFInputDriver.vdplugin)

In vdub ist u.a. ja anscheinend so ne Art GPU basierte Hardwarebeschleunigung für Filter,
bringt bei mir -10% FPS, setzt das irgendeine bestimmte Grafikkarte vorraus (hab GTS250) oder bringt die vdub interne GPU unterstützte Filterbeschleunigung ab einer bestimmten CPU Leistung eher Nachteile (weil die CPU u.U. Waitstates einlegen muß oder so?)

Ja, hab da wohl was durcheinander geworfen - es war lediglich ein Denoise Filter mit CUDA Untersützung den ich mal hatte.
Nur, wofür ist die vdub Option 3D Hardware Acceleration
Enable 3D Filter Acceleration (DXVA)

Zitat

Beides sind "native" AviSynth-Source-Plugins (die haben eigene Decoder integriert). Und VirtualDub kann AviSynth-Skripte laden.

In Google hatte ich geguckt, nur er hatte ffmpeg2source geschrieben und unter dem Namen kamen halt nicht soviele Treffer.
Wg. des DGDecNV/CUDA Decoders, bringt das beim Encoden einen zeitlichen Unterschied anstelle wenn Eingangsmaterial über DS-Filter (/CPU) dekodiert wird?

(gleiche Frage häng ich noch gleich zum eacto an, läuft bei mir über das libavc (mit der Meldung das es nicht die vollen DTS Informationen dekodiert") --> bringt der Arcsoft DTS Decoder da einen bestimmten Vorteil beim umwandeln der DTS zu AC3?)

War ein Buchstabendreher mit dem VDXA:
http://www.virtualdub.org/blog/pivot/entry.php?id=256
Ich hatte es zumindest so verstanden, das diese Abhandlung sich um dies vdub 3D Hardwarebschleunigung dreht und eigentlich einen Performancevorteil (und nicht Nachteil bringen) sollte?

Zitat

Die mit Abstand meiste CPU-Zeit geht bei langsamen Einstellungen fürs Encodieren drauf.

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).
HD Material dauert mit meinen Settings meist 1.5-2h CRF, an 2Pass gar nicht zu denken - dauert dann ja fast 3-4h und der Quad ist im FirstPass wg. des höheren Takts sogar dann noch schneller als der X6.