XP SP 2. Runtimes? Keine Ahnung.
https://www.microsoft.com/de-de/download…ls.aspx?id=8328
Avisynth 2.58
Mittlerweile gibt es Avisynth 2.6. Update empfehlenswert.
Avisynth mit Virtualdub kann MTS-Datei nicht einlesen
-
-
Zitat
....oder ist irgendwas anderes faul??
kann sein,hab hier ein ähnliches Problem,resp hatte.
VC-1 und PGS
entferne ich alle PGS und nehme nur einen Audiostream,dann klappts.Beispielclip
PGS.jpg -
Welches FFMS2? So alt, dass es M2TS nur mit Haali Media Splitter fast zuverlässig lesen könnte? Oder so neu, dass es schon lavformats als Splitter verwendet (wie L-SMASH Source)?
-
Welches FFMS2? So alt, dass es M2TS nur mit Haali Media Splitter fast zuverlässig lesen könnte? Oder so neu, dass es schon lavformats als Splitter verwendet (wie L-SMASH Source)?
Hm...letzteres vermutlich?
Es ist FFMS2 2.21, frisch heruntergeladen.Grüße,
Andreas -
Etwa seit Weihnachten 2014 sollte die Abhängigkeit von Haali raus sein; die Release v2.21 ist also recht aktuell, ja. Sollte es da Probleme geben, wären die Entwickler (z.B. Myrsloik und qyot27) im doom9-Forum sicherlich daran interessiert. Ich werde das mal erwähnen...
FFMS2 C-plugin r1050+87 ist für mich das aktuellste. Muss mit LoadCPlugin verwendet werden.
Außerdem noch eine Test-Version 2.22 RC2, die aber schon heftig die Struktur umbaut, um den Inhalt der AVSI-Datei zu integrieren.
Alternativ wäre L-SMASH Source zu empfehlen (aktuelle Versionen von the_weirdo's DropBox), wird aber MSVC 2013 Runtimes benötigen, die wohl nicht mehr für Windows XP geeignet sein könnten...
Und letztendlich bleibt immer noch: M2TS mit mkvtoolnix nach MKV umverpacken, das versteht FFMS2 noch ziemlich sicher, auch in älteren Versionen. Der MKV-Container hat den Vorteil, dass er ein paar Metadaten enthält, die das Springen erleichtern, selbst wenn ein Programm nicht seinen eigenen Index generiert.
Hast du mal eine MediaInfo-Analyse der MTS-Datei? Und vielleicht auch das Skript, um zu sehen, wie komplex es ist?
Die MTS-Datei (evtl. verschlüsselt) verfügbar zu machen wäre wohl etwas schwieriger, vielleicht via MediaFire.
-
Versuch lieber L-Smash anstatt auf Biegen und Brechen ffms2 zur Zusammenarbeit mit TS zu bewegen.
http://forum.gleitz.info/showthread.php…ll=1#post450628 -
Glaube schon. Versuch es aber erst ohne. Wenn es nicht geht, installiere folgende:
https://www.microsoft.com/de-DE/download…s.aspx?id=40784 ("vcredist_x86.exe" für die 32Bit-Version von AviSynth/L-Smash) -
Ist ja alles nicht wahr, was das immer für einen Aufwand macht...:-/
Gibt es eigentlich irgendwo eine *Anleitung*, wie man das eine oder andere Paket installiert...?
Also gut:
--> Lsmash runtergeladen, ausgepackt und nur die DLL aus dem AVISYNTH-Unterordner in das AVISYNTH-Pluginverzeichnis kopiert
--> Script abgeändert:
cam1a=LSmashAudioSource("C:\temp\00000.MTS")
cam1v=LSmashVideoSource("C:\temp\00000.MTS")
audiodub(cam1v,cam1a)
lanczosresize(640,360)--> Mit Virtualdub aufgemacht:
Fehlermeldung dass irgeneine MSVC..120.DLL fehlt (war ja eigentlich klar).
Immerhin steht ja auch hier http://avisynth.nl/index.php/LSMASHSource dass man das vcredist-Paket braucht...(Un-)Lustigerweise hat er bei erneutem Öffnen der AVS-Datei diese Meldung nicht noch einmal gebracht, sondern dann nur noch, daß er den Befehl LSmashAudioSource nicht kennt...?!?!?! Wenn man also beim ersten mal nicht aufgepasst hat, tappt man im Dunkeln...
==> Anregung: Kann man da nicht einfach die Meldung ausgeben, daß dieses vcredist-Paket fehlt? Vielleicht gleich mit Link auf die MS-Seite? Wäre doch echt sinnvoller...--> vcredist_x86.exe über o.g. Link geladen (ging nur *ohne* Javascript!?!?) und installiert.
--> Erneut das Script mit Virtualdub geöffnet:
Access Violation...:-/--> Mal die beiden Befehle getauscht:
das gleiche...:-/--> Das Script abgeändert in die beiden anderen verfügbaren Befehle:
cam1a=LWLibavAudioSource("C:\temp\00000.MTS")
cam1v=LWLibavVideoSource("C:\temp\00000.MTS")
audiodub(cam1v,cam1a)
lanczosresize(640,360)Und geht !!!!! ....ächts...
Video läßt sich laden, ist synchron, man kann auch springen (z.B. ALT-RECHTS), wobei der allererste Sprung etwas dauert...aber danach, so wie man es von DirectShowSource oder DSS2 kennt.
Kein längliches Indexfile-geschreibe wie bei FFMS2 und auch (bislang) kein VirtualDub-Absturz.
Nun denn, er mal DANKE für die Hilfe!!!
Aber das mit der Anleitung sollten wir noch noch mal klären...
Grüße,
Andreas -
Zitat
Was ist da los...?
keine Ahnung,hier habe ich rechts aufm Desk den ollen Win Editor.
Links den Explorer,offen,aendere ich was am Script und betätige Ctrl+S,sehe ich nach gut 1 Sek.
links im Explorer,in der Spalte "Änderungsdatum" die neue Zeitangabe.Bin auch grad dran an "LWLibavAudioSource / Videosource"
Nur habe ich ich im Gegensatz zu Dir die Streams nicht auf der Systemplatte.
Aber daran wirds bei Dir sicher nicht liegen.
Normales MTS klappt.Ist aber WVC-1 im Stream,hilft mir auch der Multiplexer SolveigMM_ASF leider nicht.
VDub und da den Stream nach Canopus HQ bleibt mir nur übrig. -
LSMASH...Source ist nur für ISO-Media-Container (MP4, MOV, 3GPP) geeignet. Für die meisten Container sollte man eher LwLibav...Source benutzen.
Beim ersten Laden des Scriptes erzeugt LwLibav...Source einen Index, man kann aber einstellen, ob der als Datei auf Platte gecacht wird (*.lwi). Im Gegensatz zu FFMS2 erkennt LSMASHSource leider nicht, wenn man dann die Quell-Datei mit einer gleichnamigen ersetzt, dann wird versucht, die alte Indexdatei darauf anzuwenden. Man muss da also selbst darauf achten, gegebenenfalls mal die Indexdatei zu löschen, wenn man oft verschiedene Videoquellen gleichen Namens im gleichen Verzeichnis verarbeitet.
Dass das Schließen des Skriptes lange dauert, bedeutet vielleicht, dass das Plugin seinen benutzten Speicher gewissenhaft aufräumt, wer weiß... Wenn bei dir aus Mangel an RAM die Auslagerungsdatei verwendet werden musste, wäre das wahrscheinlich.
-
Zum Neuladen: Da habe ich mich unklar ausgedrückt:
Ich meinte F2 im VirtualDub. Das bewirkt, daß die Quelldatei neu geladen wird (also das ggf. geänderte Script). Bei DirectShowSource kann man schön im Editor "CTRL-S" drücken, im VirdualDub "F2" - das dauert das dann 1-3 Sekunden und der geänderte Stream ist auf dem Schirm - an der gleichen Frame-Nummer, wie vorher. Sehr praktisch für kleine Änderungen, die man sich im Vergleich zu vorher anschauen möchte (Subtitles früher/später, Überblendungen wann anders). Mit LSmash ist es halt wie oben beschrieben: Immer mehr als 30 Sekunden, bis was passiert, teilweise bis zu 45 Sekunden!
LSMASH...Source ist nur für ISO-Media-Container (MP4, MOV, 3GPP) geeignet. Für die meisten Container sollte man eher LwLibav...Source benutzen.
OK. Danke. Könnte die Software natürlich auch mit einer Fehlermeldung mal mitteilen statt eine Access Violation zu verursachen... Den Containerinhaltstyp kann man doch vorher auslesen / bestimmen...?
Beim ersten Laden des Scriptes erzeugt LwLibav...Source einen Index, man kann aber einstellen, ob der als Datei auf Platte gecacht wird (*.lwi).
Wo stelle ich das ein? Hiier http://avisynth.nl/index.php/LSMASHSource/LSMASHVideoSource finde ich leider nichts dazu.
Im Gegensatz zu FFMS2 erkennt LSMASHSource leider nicht, wenn man dann die Quell-Datei mit einer gleichnamigen ersetzt, dann wird versucht, die alte Indexdatei darauf anzuwenden.
Also beim Ausprobieren hatte ich den lanczosresize() auf eine andere Größe gesetzt - da sieht man die Änderung sofort, wenn sie eintritt (also nach 35 Sekunden dann) - aber der Index könnte in diesem Fall doch letztlich der gleiche bleiben, oder? Auch wenn man die AVS nur nochmal speichert (also gleiche Datei, nur anderes Datum und mit sicherheit "alt-index-fähig"), dauert es so lange.
Ich kann mir nicht vorstellen, daß LSmashSource wirklich so lange braucht, um den Index zu erzeugen - es ist eine 500MB-Datei, also nichts wirklich großes. FFMS2 brauchte *einmalig* unter 10 Sekunden auf dem gleichen Rechner...?!
Dass das Schließen des Skriptes lange dauert, bedeutet vielleicht, dass das Plugin seinen benutzten Speicher gewissenhaft aufräumt, wer weiß... Wenn bei dir aus Mangel an RAM die Auslagerungsdatei verwendet werden musste, wäre das wahrscheinlich.
Das ist es sicherlich nicht: 4x3,7GHz, 16GB RAM, keine anderen Anwendungen am laufen (bis auf den Editor und den Datei-Explorer). Speicher aufräumen kann damit nicht so lange dauern. Er swappt auch nix auf der Platte herum (LED nur selten kurz an, also praktisch Leerlauf).
Was könnte sonst noch sein?
Es ist wie gesagt kein FFDShow auf dem Rechner, kein FFMPEG, keine LAV-Filters, nichts. Kann das einen Einfluss haben? Fehlt ihm noch was?
Grüße,
Andreas -
Die Mediendatei.ext.lwi wird nur erzeugt, wenn sie noch nicht existiert, während ein Script die Mediendatei.ext lädt. Wenn also beide existieren, wird der Index nicht neu erstellt, sondern aus der Index-Cache-Datei geladen.
Das Erzeugen der Index-Cache-Datei kann man mit dem Parameter cache=false deaktivieren, dann wird bei jedem Öffnen eines AviSynth-Skriptes aus die Medien-Datei gelesen und ein Index erstellt, der im RAM gehalten wird. Die Funktionsparameter sind in der Datei README im LSMASHSource-Archiv dokumentiert.
Code
Alles anzeigen... [LWLibavVideoSource] LWLibavVideoSource(string source, int stream_index = -1, int threads = 0, [B]bool cache = true[/B], int seek_mode = 0, int seek_threshold = 10, bool dr = false, int fpsnum = 0, int fpsden = 1, bool repeat = false, int dominance = 0, bool stacked = false, string format = "") * This function uses libavcodec as video decoder and libavformat as demuxer. [Arguments] ... + cache (default : true) Create the index file (.lwi) to the same directory as the source file if set to true. The index file avoids parsing all frames in the source file at the next or later access. Parsing all frames is very important for frame accurate seek. ...Was beim Neuladen des Skriptes nun exakt passiert, weiß ich nicht. Warum das bei dir so lange dauert, erst recht nicht. Bei mir geht das bei einigen Testvideos unverzüglich.
Wenn du die Filter im Skript veränderst, die nach LwLibavVideoSource folgen, hat LSMASHSource keinen Grund, den Index neu zu erstellen, das wird also keine Ursache für die Verzögerung sein. Es sei denn, irgendwas wäre so verkorkst, dass bereits ein Lese-Zugriff auf die Index-Cache-Datei an sich ewig dauert. Du solltest die Index-Cache-Datei nur löschen, damit sie neu erzeugt wird, wenn sich der Inhalt der Medien-Quelldatei ändert. Der Inhalt des Skriptes sollte hier irrelevant sein.
Ob ffdshow installiert ist oder nicht, ist völlig egal, LSMASHSource interessiert sich nicht für DirectShow-Filter. Entsprechend auch LAV Filters als DirectShow-Filter.
Ob ffmpeg installiert ist oder nicht, ist völlig egal, LSMASHSource interessiert sich nicht für Kommandozeilen-Konverter.
-
Danke! Da habe ich ja auch beim falschen Befehl nachgeschaut.
Hier http://avisynth.nl/index.php/LSMASHSource/LWLibavVideoSource steht das natürlich korrekt drin.
Muss ich mal mit "herumprobieren". Wie lange dauert denn bei Euch so ein "F2"?Grüße, Andreas
-
^ noch etwas überarbeitet.
Soweit ich sehe, passiert das Neuladen "sofort". Ich hab hier "Big Buck Bunny" in CRF 6 encodiert mit FLAC-Tonspur in einer MKV, dieses per LwLibaVideoSource und LwLibavAudioSource geöffnet. Klar, beim Springen hängt es ab und zu mal bis zu 3 Sekunden, aber der Decoder muss ja bei Sprüngen, die nicht zufällig auf einem Keyframe landen, vom letzten vorherigen Keyframe an bis zur Sprungstelle decodieren, das dauert schon mal ein wenig. Aber auch nicht eine halbe Minute...
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!