Ohne die Dateien direkt zu untersuchen, kann ich erst mal nur raten: Die eine ist zu alt (Interface für AviSynth 2.0), die andere zu neu (Interface für AviSynth[+] 2.6)... Mit AVSMeter ließe sich das sicher analysieren, wenn die jeweilige DLL ins AutoLoad-Verzeichnis kopiert wird. Hast du noch ein altes AviSynth 2.5 installiert?
Wenn sich bei einem Windows-Programm eine avisynth.dll im selben Verzeichnis wie das Programm selber befindet, wird diese Version verwendet statt der, die im Windows-System-Verzeichnis ist. Dann könnte es sein, dass GordianKnot vielleicht eine AviSynth-2.0-DLL lokal mitbringt und diese dann mit DGDecode.dll 1.8.5 zusammenarbeitet... aber ich hab's nicht installiert, weiß das also nicht sicher.
Wenn du nur ein 32-bit-AviSynth installiert hast, können auch nur 32-bit-Programme damit arbeiten.
AVSMeter läuft problemlos durch.
Wie genau? Protokollierst du das installierte System mit avsinfo oder analysierst du damit das GK-Skript? Im ersten Fall wird sich AVSMeter bei der Systemanalyse nicht beschweren, weil es nicht weiß, wo die DGDecode.dll liegt, sofern du sie nicht auch ins Plugins-Verzeichnis kopiert hast. Aber das siehst du ja, ob MPEG2Source im Protokoll der unterstützten AviSynth-Funktionen auftaucht.
Noch eine mögliche Ursache: Dein Windows 10 hat vielleicht ein paar ältere Visual-C++-Runtimes nicht installiert?
Wie genau? Protokollierst du das installierte System mit avsinfo oder analysierst du damit das GK-Skript?
- Das GK-Skript ist im AVSMeter problemlos durchgelaufen.
- Der MPC-HC-32-bit spielt das GK-AVS-Skript problemlos ab (nicht jedoch 64bit).
- Die x264.exe-32-bit encodiert das GK-AVS-Skript problemlos (nicht jedoch 64bit).
Also eher ein GKnot-Problem.
Ältere Visual-C++-Runtimes sind auch vorhanden, ab 2005, jeweils als 32- und 64-Bit-Version.
Warum das Ganze?
Ich nutze GKnot mit der x264.exe in VMware an gleichen PC mit Win7/32bit. Benchmarks zeigen daß der Host - je nach Test - deutlich schneller sein kann als das Gastsystem. Deshalb wollte ich gucken in wie weit x264 auf dem Hostsystem schneller ist als unter VMWare. Hierbei habe ich festgestellt, daß es im Host kaum schneller läuft. Die Idee, die Encodierung im Host statt auf dem Gastsystem laufen zu lassen bringt letztendlich nichts.
Dennoch würde mich interessieren warum GKnot meckert. Vielleicht läuft es generell nicht auf 64-Bit-Windows?
Gruß
akapuma
Wilde Idee: Vielleicht ist da im SourceCode von GordianKnot irgendwo ne alte Avisynth header Datei mit drinnen,...
Andere Idee: Kann es vielleicht sein, dass da ein paar .dlls im Windows/System32 Ordner landen die in den SysWOW64 Ordner müssen?
Ich habe es gefunden!
GKnot kann seine eigenen .avs nicht öffnen, weder unter Win10/64 noch unter Win7/32. Was fehlt ist ein ConvertToRGB() hinten, dann geht es 
Gruß
akapuma
In dem Fall könnte es daran liegen, dass ein VfW-Codec fehlt, der Farbraumkonvertierungen implizit durchführt, vor allem mit YV12. Geeignet wären der Xvid-Codec oder der aus LAV Filters, wenn man dort im VfW-Decoder die Zuständigkeit für Raw-Formate aktiviert.
Don’t have an account yet? Register yourself now and be a part of our community!
