VirtualDub2 unterstützt kein MP4 oder MKV, möglicherweise auch kein h264.
Das erinnert mich an Hanns Dieter Hüsch - "Der Niederrheiner weiss nix, kann aber alles erklären".
ja, Aber ...
Wie du im avs sehen kannst werden da nur 64bit Plugins geladen.
Im Englischen nennt man das "Logical fallacy". 
Ich sehe lediglich, dass du in deinem Skript DLLs aus den Verzeichnissen "C:\Program Files (x86)\Video Tools\LSMASHSource-AviSynth-plugin-r929-msvc-64bit" und "C:\Program Files (x86)\Video Tools\xyVSFilterSubFilter-3.1.0.800\x64" versuchst zu laden.
Alles anzeigenOk, hier die Ausgabe von "MediaInfo":
Format : AVI
Format/Info : Audio Video Interleave
Format-Profil : OpenDML
Dateigröße : 3,32 GiB
Dauer : 1 h 30 min
Gesamte Bitrate : 5 283 kb/s
Kodierendes Programm : Lavf54.63.104Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
...
AVC in AVI Container -> Probleme vorprogrammiert.
Leider werden dazu aber erst mal alle Clips geöffnet, auch die, die in dem Moment noch längst nicht benötigt werden. Und für jeden dieser Clips wird zusätzlich noch mal ein Puffer von je 15 Frames durch den preroll-Parameter in DSS2 reserviert: Der mag für das Konvertieren, aber noch mehr für das zufällige Anschauen eines Clips nützlich sein; wenn man jedoch sehr viele Clips in der selben Skript-Umgebung offen hat, dann wird für jeden Clip ein solcher Puffer reserviert, und das verbraucht RAM. Und wenn eigentlich nur das Video von Anfang bis Ende durchgereicht wird, ohne dass es im Skript Filter gibt, die einen großen temporalen Radius haben (also weit in Vergangenheit und Zukunft jedes aktuell verarbeiteten Frames schauen müssen), dann braucht man so einen großen Preroll vielleicht gar nicht.
Hab' ich gerade mal getestet, "preroll=0", "seekthr=0" und "cache=0" machen kaum einen Unterschied.
Um das wirklich beurteilen zu können, müsste man in die Internas von AviSynth einsteigen. Beim Zusammenfügen einzelner Clips kann ich mir aber durchaus vorstellen, dass hierfür zusätzlicher Speicher benötigt wird, bzw. das ein großes Video am Stück besser funktioniert, eben weil nichts mehr zusammengefügt werden muss.
Ein grosser Teil des Speichers wird wahrscheinlich auch von den zahlreichen Instanzen von ffdshow benötigt. LAV Filters wäre hier wahrscheinlich besser (abgesehen von ffms2/lsmash die eindeutig vorzuziehen sind).
Die beste Lösung ist sicher DGDecNV. Ansonsten 64 Bit Workflow und/oder zusammenfügen der einzelnen Segmente.
Andreas
All diese Probleme und endlose Forum-Threads könntest du vermeiden wenn du 64 Bit Avisynth/VDub benutzt. "läuft nicht" ist wenig hilfreich bei der Fehlersuche. Versuch mal Avisynth 64 Bit mit dem "Avisynth Universal Installer" zu installieren.
Vorher empfehle ich eine gründliche Reinigung:
- "C:\Programme (x86)\AviSynth*" und Unterverzeichnisse löschen
- Lösche diese Registrierungsschlüssel (registry keys)
HKEY_CURRENT_USER\Software\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth
Solltest du dann immer noch Probleme haben kann AVSMeter weiterhelfen (AVSMeter -avsinfo").
Comodo Firewall ist sehr gut. Ich benutze eine ältere Version (5.10), die ist noch nicht so aufgebläht. Anti-Virus habe ich noch nie benutzt, da kann ich nicht weiterhelfen.
Ich bin mir ziemlich sicher, dass eines der Plugins/Scripts von StainlessS das kann. Musst du mal auf Doom9 (Englisch) posten.
Ich kenne mich schon recht gut aus was Matroska angeht, aber parsen ist was anderes als technical Infos zu lesen oder irre ich mich da jetzt völlig?
Alle Infos die du brauchst sind da. Vielleicht solltest du dir den Source Code von Bunkus' mkvtoolnix/mkvinfo ansehen.
Ich würde gerne Matroska Dateien selber parsen wollen, allerdings fehlt mir da der Ansatz.
Ist es wirklich so kompliziert Google zu benutzen?
Matroska Technical Info
Ach ja, ich vergaß ... wenn du ansonsten kein AviSynth installiert hast, verwendet MeGUI eine lokale Kopie für sich allein. Das erschwert diese Art von Test.
Bei AVSMeter kann man die zu verwendende avisynth.dll in AVSMeter.ini angeben:
# "AVSDLL"
# The user can specify the avisynth.dll to be used. This has to be a fully qualified path, for example
# "AVSDLL=d:\apps\avisynth\avisynth.dll" (without the quotes). The default is an empty string which
# means that AVSMeter will attempt to load avisynth.dll through the standard Windows search hierarchy.
AVSDLL=b. GPU beim Dekodieren nutzen spart CPU Power
Genau, viele unterschätzen diesen Vorteil. LSmash mit 4 Threads zweigt viele der verfügbaren CPU Zyklen für sich selbst ab was sich bei der Encoding-Geschwindigkeit bemerkbar macht.
-> verwirrt, dass bei may24 anscheinend nur 2GB adressiert werden können
Wir wissen ja nicht mal welches Betriebssystem benutzt wird. Auf einem 64 OS ist die Aussage "Avisynth kann max 2GB Arbeitsspeicher belegen" allerdings falsch.
Ja, darum geht es auch zu teil. es wird nur etwas in das MKV hinzugefügt... aber an dem Inhalt selbst ändert sich nichts... also der Hash der Tonspur etc. oder verändert diese sich wenn man etwas neu muxxt?
MKVPropEdit ist kein Multiplexer, eher ein Editor fuer MKV-Eigenschaften. Der Befehl oben fuegt lediglich eine winzige Datei als Anhang zur MKV hinzu und dadurch aendert sich natuerlich der MD5/SHA256/etc.
mkvpropedit.exe file.mkv --add-attachment dummy.png
"dummy.png" kann z.B. eine kleine, 4x4 pixel PNG-Datei sein.
Komisch, Avisynth sollte normalerweise eigentlich LARGEADRESSAWARE kompiliert sein und entsprechend auch auf mehr zugreifen können
Das LARGEADRESSAWARE Flag wuerde bei Avisynth garnichts ausrichten. Die Client-Anwendung, die avisynth.dll laedt, muss das Linker-Flag gesetzt haben um bis zu 4GB zu adressieren..
Könnt ihr nicht einfach andere Meinungen akzeptieren?
Weist du wie lange er vielleicht schon stiller Mitleser ist?
Das war keine Meinung sondern eine orthografische und grammatikalische Katastrophe.
Der Non-Local Means Algorithmus ist extrem rechenaufwändig. Alle CPU-Implementierungen sind praktisch unbrauchbar. Deshalb ist die OpenCL Variante so genial - Sie nutzt die enorme Rechenpower moderner GPUs.
Danke schau ich mir mal an. Hast Du mal ein Beispiel Werte die dann ungefähr MDeGrain2 entsprechen?
Ach ja und Erfahrungen zu dem Device?
Habe eine Intel HD 4800 eine GF 970m und CPU I7-4720HQ
Keine Ahnung was Mdegrain2 ensprechen wuerde. Meistens benutze ich das hier:
KNLMeansCL(d = 1, a = 2, h = x.x)
"h" bestimmt wie stark "entrauscht" wird. Das sollte irgendwo zwischen 1.0 und 2.0 liegen (meine Erfahrung).
Um eventuelles Banding nach dem Filter zu maskieren benutze ich "flash3kyuu_deband".
Das Ganze als Funktion in einer .avsi:
function Denoise(clip video, int "temporal", int "spatial", float "strength", bool "deband", bool "debug")
{
last = video
spatial = default(spatial, 2)
temporal = default(temporal, 1)
strength = default(strength, 1.0)
deband = default(deband, true)
debug = default(debug, false)
KNLMeansCL(d = temporal, a = spatial, h = strength, lsb_inout = false, info = debug)
(deband == true) ? f3kdb(sample_mode = 2, keep_tv_range = true, input_mode = 0, output_mode = 0, grainY = 32, grainC = 32) : nop()
return last
}Noch besser ist es wenn man die Filter mit Hilfe von DitherTools im 16 bit stacked Format laufen laesst.
KNLMeansCL sollte man nicht mit MT laufen lassen. Es hat auch keine Vorteile.
Die GF970M ist hoechstwahrscheinlich schneller als der integrierte Intel Chip.