Avisynth mit Virtualdub kann MTS-Datei nicht einlesen

Bei mir dauert das Neuladen einer 30GB-MKV von (Magnet-)Festplatte auch locker eine Minute. Der Index scheint auch zwei mal erstellt worden zu sein (wuchs erst an, dann auf 0 Byte runter und wuchs erneut an) und ist im Vergleich zu ffms2 riesig. (3 MB vs 400 MB)
Ich weiß aber spontan nicht, ob das schon immer so war oder ob sich da etwas in den letzten Versionen geändert hat. Müßte man sich genauer anschauen.

Zitat

Der Index scheint auch zwei mal erstellt worden zu sein (wuchs erst an, dann auf 0 Byte runter und wuchs erneut an) und ist im Vergleich zu ffms2 riesig. (3 MB vs 400 MB)

Stelle ich hier so gar nicht fest.Siehe Screen,im rotumrandeten Feld.

selber verabschiede ich mich von ffms2 und nehme nur LSMASH + LWLibav.

Das zweimalige Erstellen wurde bereits irgendwo mal erklärt:

Wenn man im Skript zuerst LwLibavVideoSource verwendet, wird nur die Videospur indexiert. Folgt darauf LwLibavAudioSource, muss noch mal die Audiospur in Relation zur Videospur indexiert werden. Wer also beide Spuren verarbeiten will, sollte zuerst die Audiospur und dann die Videospur im Skript laden.

Deshalb verwendet MeGUI wohl zum Vor-Indexieren auch einen LwLibavAudioSource-Aufruf in einem Dummy-Skript.

Die Größe ist abhängig von verschiedenen Faktoren. Insbesondere unkomprimierte Formate, in denen praktisch überall Keyframes vorkommen, und Tonspuren mit entsprechend wahlfreiem Zugriff an jedem Frame, lassen riesige Indexdateien entstehen.

Wahrscheinlich ist das auch die Ursache bei andreasp: Mit Tonspur ist der Index erheblich größer, da dauert auch das Neuladen länger. Bei Kleinigkeiten wie BBB passiert das nach dem Indexieren aber auch "sofort".

Das kenne ich nur von (alten?) ffms2-Versionen. Bei mir sind die Indices von lwlibavvideosource und lwlibavaudiosource bitidentisch. Vielleicht lag es aber nur daran, daß meine Festplatte vollief, kann es nämlich nicht mehr reproduzieren. Oder Windows' Größenanzeige spinnte mal wieder etwas. War vermutlich ein Fehlalarm meinerseits.

Zur Größe des Index und Dauer des Neuladens:
Habe eine alte Version (Mai 2014) getestet und sie verhält sich genau so. Ist also alles normal und man muß damit leben.

Na gut, dann habe ich das vielleicht mit FFMS2 verwechselt, und LSMASHSource erzeugt immer den kompletten Index. Aber zum Glück schadet es nicht, trotzdem zuerst das Audio zu laden...

Normal ist das sicher nicht.

Und an möglichen Ursachen fallen mir erst mal nur katastrophale ein (z.B. dass du mal einen S.M.A.R.T.-Report deiner Festplatte lesen solltest). Jedenfalls würde mir kein Grund einfallen, warum ausgerechnet L-SMASH Works als einziger Decoder bei jeder neuen GOP so angestrengt darüber nachdenken müsste, wie es die Decodierung starten soll, während andere Quellfilter das nicht müssten. Der Index soll sich ja die Positionen von GOP-Starts merken, so dass der Decoder immer schnell die nächstmögliche Decodier-Start-Position vor dem aktuellen Frame findet.

Je nach AviSynth-Version mag es noch Methoden geben, dass der Decoder sich mehr Frames um die aktuelle Position herum merkt ([MT] Prefetch oder TIVTC.RequestLinear), und das sichergestellt wird, dass der Decoder nur immer eine Anfrage gleichzeitig bekommt (kann bei MT-Versionen wichtig sein). Trotzdem sollten auch unter ungünstigen Umständen keine 15 Sekunden nötig sein. Für mich ist hier am wahrscheinlichsten, dass die Festplatte die Daten nicht liefert.

Das ist dann wohl keine 32-bit-Windows-DLL für AviSynth 2.5x oder 2.6x?

Ich weiß nicht, womit die gepackt war; falls es ein 7z-Archiv ist, und du hast eine 7zip-Version älter als 9.20, kann es passieren, dass ohne Warnung fehlerhaft entpackt wird. Keine Ahnung, ob das hier zutrifft, war aber oft ein typischer Fehler, wenn DLL oder EXE mal defekt erschienen.

Zitat

Das "Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219" ist laut Systemsteuerung/Software genauso drauf wie das "Microsoft Visual C++ 2013 x86 Redistributable - 20.0.30501" (und noch zwei weitere von 2008).

Hatte hier früher auch ähnlichen Ärger,unter XP,hier half folgende Version,siehe Screen und im Anhang als Rar.
[Zum Glück hat man damals alles notiert....]

Avisynth Old.png

https://localhost/www.ww-consulting.ch/DL/vcredist_x86.rar

Zitat von andreasp

Dort wird zwar XP noch unter "Voraussetzungen" aufgeführt, aber ohne SP-Angabe...

Hier:
https://support.microsoft.com/en-us/kb/2661358

Wenn man in jede EXE oder DLL immer die komplette Runtime hineincompilieren würde, hätte man dafür aber x-mal den dafür nötigen Plattenplatz belegt. Durch die dynamische Verknüpfung spart man etwas Plattenplatz ... aber nur, solange die Anzahl der davon abhängigen Programme und Bibliotheken die Anzahl der eventuell dafür zu installierenden Runtimes in ihren verschiedenen Versionen deutlich übersteigt.

Programme so zu compilieren, dass sie ausschließlich und höchstens nur alle wirklich benutzten Funktionen enthalten, ist ziemlich schwierig für C-Compiler. Die Ähnlichkeit zu Damenhandtaschen ist frappierend (auch da findet man wohl einiges, was nur für den Fall mit drin ist, dass es eventuell mal nützlich sein könnte ... tatsächlich aber kaum wöchentlich verwendet wird). ;D

Zitat von andreasp

Dann nehme ich diesen hier?
[h=3]Visual C++ Redistributable for Visual Studio 2012 Update 4[/h]Soll angeblich bis XP SP3 funktionieren...

Grüße,
Andreas

Wenn du XPSP3 hast sollten alle Runtimes bis 2013 funktionieren.

Zitat von andreasp

Nachtrag: Es war die neueste Version, die ich drauf hatte. Aber weiter oben wurde ja über die "letzte XP-Version" diskutiert.

Also mal im "Old"-Ordner die einzige mit XP gekennzeichnete verwendet:
https://www.dropbox.com/sh/3i81ttxf028…nGMQ8a/Old?dl=0

L-SMASH-Works-r783-20150223-32bit-XP.7z

Nimm r768. Die funktioniert auf XP. Kannst du auch mit Dependency Walker testen.

Ja, "selbstverständlich" sind alle Runtime-Versionen von Visual C++ unabhängig voneinander, man muss tatsächlich alle Versionen installiert haben, die von allen installierten Programmen benötigt werden könnten. Und dazu kommen in den höheren Versionen eventuell auch noch unterschiedliche .NET-Assemblies der jeweiligen Service-Packs.

Wer sich regelmäßig mit dem Offline-Update-Generator von wsusoffline.net einen Update-USB-Stick erzeugt hat (sehr empfehlenswert, einen frisch installierten PC damit mit Update-Patches zu versorgen, bevor er erstmalig an ein Netzwerk angeschlossen wird), der wird alle MSVC-Runtime-Installer gesammelt haben und kann sie eine nach dem anderen installieren. Die aktuellen wsusoffline-Versionen unterstützen Windows XP (und Server 2003 bald) nicht mehr, man muss da vielleicht auf das Archiv zurückgreifen und hoffen, dass von Microsoft noch alles nötige herunterladbar ist.