Beiträge von H264x

    Okay und letzte Frage...
    Zum DeInterlacen von Interlaced BFF Material, den Befehl so abändern mit der intval auf 1 setzen: ??


    Code
    1. clip = core.avisource.AVISource(r"C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi")clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=[B]1[/B])clip = havsfunc.QTGMC(clip, [COLOR=#000000][B]BFF = True[/B][/COLOR][COLOR=#000000],[/COLOR] Preset = "Medium")



    Ich hoffe dann ist jetzt alles im grünen Bereich :)



    stax76


    Könntest du den "SetFrameProp" Befehl mit in deinem Programm in der QTGMC Script Erstellung mit einbauen?
    Hier mal das Script was von StaxRip als Standard Ausgabe Automatisch im Temp Ordner erstellt wird...


    Zum DeInterlacen von Interlaced TFF Material:


    Code
    1. import vapoursynth as vscore = vs.get_core()core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\fmtconv\fmtconv.dll')import importlib.machineryadjust = importlib.machinery.SourceFileLoader('adjust', r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\adjust\adjust.py').load_module()mvsfunc = importlib.machinery.SourceFileLoader('mvsfunc', r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\mvsfunc\mvsfunc.py').load_module()core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\mvtools\libmvtools.dll')core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\nnedi3\libnnedi3.dll')core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\scenechange\scenechange.dll')core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\temporalsoften\temporalsoften.dll')havsfunc = importlib.machinery.SourceFileLoader('havsfunc', r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\havsfunc\havsfunc.py').load_module()core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')clip = core.lsmas.LWLibavSource(source = r'C:\Video.avi')clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=[B][COLOR=#000000]2[/COLOR][/B]) [COLOR=#008000]# Korrekturzeile, die man an dieser Stelle hier noch einbauen sollte...[/COLOR]clip = havsfunc.QTGMC(Input = clip, [B]TFF[/B] = True, Preset = 'Fast')clip.set_output()


    Zum DeInterlacen von Interlaced BFF Material:





    Was mir noch aufgefallen ist^^
    Die Assume Befehle sollten zusammen mit in die QTGMC Auswahl Zeile rein.
    z.B. [ ] Field > QTGMC Fast + Assume TFF (in einer Spalte)


    Wenn ich jetzt nur AssumeTFF anklicken würde ist QTGMC nicht mehr aktiv.

    Das "TFF = True" ist überflüssig und nur als Fallback gedacht (siehe #1668).


    Habe das Script jetzt so angepasst und das "TFF = True" weggelassen:


    Code
    1. clip = core.avisource.AVISource(r"C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi") clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=2)clip = havsfunc.QTGMC(clip, Preset = "Medium")


    Und nun kommt diese Fehlermeldung:


    Du solltest nur die SetFrameProp- über die QTGMC-Zeile setzen. (Bzw. SetFrameProp- direkt unter die source filter-Zeile)


    So funktioniert das Script wieder!

    Code
    1. clip = core.avisource.AVISource(r"C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi")
    2. clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=2)
    3. clip = havsfunc.QTGMC(clip, [COLOR=#a9a9a9][B]TFF = True[/B][/COLOR][COLOR=#000000],[/COLOR] Preset = "Medium")


    Was läuft da falsch?

    Könntest du mir bei der Script Erstellung kurz helfen? :huh:
    Bekomme leider eine Fehlermeldung:


    Hab folgendes Probiert:

    Code
    1. import vapoursynth as vs core = vs.get_core() core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\fmtconv\fmtconv.dll") import importlib.machinery adjust = importlib.machinery.SourceFileLoader('adjust', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\adjust\adjust.py").load_module() mvsfunc = importlib.machinery.SourceFileLoader('mvsfunc', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\mvsfunc\mvsfunc.py").load_module() core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\mvtools\libmvtools.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\nnedi3\libnnedi3.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\scenechange\scenechange.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\temporalsoften\temporalsoften.dll") havsfunc = importlib.machinery.SourceFileLoader('havsfunc', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\havsfunc\havsfunc.py").load_module() clip = core.avisource.AVISource(r"C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi") [COLOR=#000000]# clip = havsfunc.QTGMC(clip, TFF = True, Preset = "Medium")[/COLOR][COLOR=#ff0000] # Die Zeile hier komplett löschen?[/COLOR]clip = core.std.SetFrameProp.QTGMC(clip, prop="_FieldBased", intval=2, Preset = "Medium") [COLOR=#008000]# Mein aktueller Script Änderungs Versuch[/COLOR]clip.set_output()


    Edit
    Sitze gerade am Linux PC...
    Mir ist so eben beim schreiben der Zeilen was eingefallen :eagerness: (Bin mir aber nicht sicher)
    Ich probiere später folgende Änderung aus:

    Code
    1. clip = core.std.SetFrameProp.[COLOR=#000000]havsfunc.QTGMC[/COLOR](clip, prop="_FieldBased", intval=2, Preset = "Medium")

    "c" ist nicht eine "Abkürzung", sondern eine anders benannte Objektvariable.


    Genauso wollte ich es irgendwie erklärt haben :daumen:




    Auch bekannt als "progressiv" = keine zwei verwobenen Halbbilder aus verschiedenen Aufnahmezeitpunkten. sondern das gesamte Bild aus dem selben Zeitunkt.


    Für Progressiven Inhalt brauch man ja kein QTGMC Script (bzw. DeInterlacer) an sich anwenden...
    oder?
    Da gab es doch Ausnahmen (Wenn das Video z.B. aus 70% Progressiven und 30% Interlaced Inhalt besteht)

    Code
    1. clip = c.std.SetFrameProp(clip, prop="_FieldBased", intval=2) #int _FieldBased (0=frame based, 1=BFF, 2=TFF)



    Hallo Sneaker2, hier noch eine kurze Anmerkung, was ich rausgefunden habe^^
    So wie ich die Funktion c auch core genannt verstehe, muss sie im Script überall gleich geschrieben werden...
    Entweder man Baut das VapourSynth Script nur mit dem Befehl core auf oder benutzt nur c als Abkürzung.
    Beides mischen geht nicht ;)


    Hab noch eine kurze Frage zu deiner oben genannten Variante...


    Hier mal mein VapourSynth / QTGMC Script:

    Code
    1. # Abgespickt aus StaxRip_x64 ;)import vapoursynth as vs core = vs.get_core() core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\fmtconv\fmtconv.dll") import importlib.machinery adjust = importlib.machinery.SourceFileLoader('adjust', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\adjust\adjust.py").load_module() mvsfunc = importlib.machinery.SourceFileLoader('mvsfunc', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\mvsfunc\mvsfunc.py").load_module() core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\mvtools\libmvtools.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\nnedi3\libnnedi3.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\scenechange\scenechange.dll") core.std.LoadPlugin(r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\temporalsoften\temporalsoften.dll") havsfunc = importlib.machinery.SourceFileLoader('havsfunc', r"C:\PortableApps\StaxRip_x64_1.3.4.0_stable\Apps\Plugins\vs\havsfunc\havsfunc.py").load_module() clip = core.avisource.AVISource(r"C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi") clip = havsfunc.QTGMC(clip, TFF = True, Preset = "Medium") clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=2) #int _FieldBased (0=frame based, 1=BFF, 2=TFF) # intval=2 Befehl steht für TFF # intval=1 Befehl steht für BFF # intval=0 Befehl steht für ???clip.set_output()


    Nach einwenig rumprobieren läuft es jetzt endlich unter VirtualDub-1.10.4_x64 :)


    Ist der Aufbau nun korrekt?
    Bzw.. mein Logisches Denken dazu...


    Zum DeInterlacen von Interlaced TFF Material:

    Code
    1. clip = havsfunc.QTGMC(clip, [B][COLOR=#ff0000]TFF[/COLOR][/B] = True, Preset = "Medium") clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=[COLOR=#ff0000][B]2[/B][/COLOR])


    Zum DeInterlacen von Interlaced BFF Material folgenden Befehl zum oben genannten Script abändern:

    Code
    1. clip = havsfunc.QTGMC(clip, [B][COLOR=#ff0000]BFF[/COLOR][/B] = True, Preset = "Medium")
    2. clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=[B][COLOR=#ff0000]1[/COLOR][/B])


    Und was bedeutet eigentlich intval=0 ? (frame based)

    Danke für die Erklärung :)
    Wenn man die Funktion erst gar nicht angibt, dann müsste ja der "Auto Thread Modus" aktiv sein?
    Unter XP Zeiten waren die Scripte noch ohne Thread Zuweisung.
    Muss ich mir mal einen neuen Merkzettel für die AviSynth Nutzung unter Windows 7 mit 64-Bit schreiben:

    Code
    1. Durch das Manuelle setzen von "[B]threads=1[/B]" wird der Auto Modus verhindert! Dadurch wird das Fehler Riskio gemindert.


    Dann denke ich mal, gillt die Thread setzen Regel auch für alle weiteren "xSource" Quellen wie z.B.


    AviSource("inputVideo",threads=1)
    FFVideoSource("inputVideo",threads=1)
    LWLibavVideoSource("inputVideo",threads=1)


    usw...

    Code
    1. FFVideoSource("output result file.mkv",threads=1,colorspace="yuy2",fpsnum=25)


    Was bedeutet eigentlich die Funktion: threads=1 ?
    Hab einen Laptop Mobile i7 CPU, der 4 Cores und 8 Threads besitzt.
    Sollte ich ihm dann Logischerweise, die vollen 8 Threads in diesem Beispiel AviSynth Script zuweisen?


    Ich hatte vor kurzem folgendes Problem als ich dieses Beispiel Video hier öffnen wollte...

    Code
    1. FFVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi")


    Die Automatische Erkennung von FFMS2 schlug fehl,
    da das Video komplett in Grüner Frabe und auf dem Kopf gestanden hat ;)


    Nach der Script Korrektur stimmte wieder alles :)

    Code
    1. FFVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi",colorspace="YUY2",fpsnum=25)


    Die Framerate + ColorSpace inkl. ChromaSubsampling,
    musste ich in diesem Beispiel manuell zuordnen,
    da sie wohl von FFMS2 nicht "automatisch" erkannt wurden.


    In der Gegenprobe mit L-SMASH-Works, funktionierte die Automatische Erkennung auf Anhieb!

    Code
    1. LWLibavVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi")


    In diesem Fall wurde die Framerate + ColorSpace inkl. ChromaSubsampling von L-SMASH-Works:
    automatisch, zuverlässig und korrekt erkannt :)

    Damit schneide ich über den schnellen Vorlauf nach Szene, ich erspare mir also die Sichtung im Originaltempo.


    Gut zu wissen :)


    Also wenn du nicht weißt, warum ausgerechnet deine Wahl besser sein soll, lass es, wie es ist.


    Genau, wenn ich was nicht weiß, lass ich auch davon die Finger und verlasse mich auf die Standard Einstellungen vom Hersteller.
    Möchte nur gerne wissen wie ein paar Funktionen funktionieren und welche Auswirkungen sie haben...
    Besonders beim letzten Konfiguration Punkt 12.) Exit, habe ich was sinnvolles entdeckt :)


    Ask for confimation to close
    Schützt VirtualDub vor Unerwartenen schliessen,
    wenn man Unabsichtlich mit der Maus auf das "Exit Symbol" kommt ;)
    Da VirtualDub vor dem Programm Exit vorher eine (Sicherheits) Frage stellt:
    Ob das Programm nun wirklich geschlossen werden soll...


    Und hier noch der Rest von der VirutalDub Konfiguration mit ein paar Bilder und den letzten fragen dazu:



    VirtualDub x86 + x64 / Preferences - 09.) Images



    VirtualDub x86 + x64 / Preferences - 10.) Threading


    Video compression threads [1]
    Wert Standard Eingabe ist 1


    Zeros disables video compressor multithreading
    ONE causes the compressor to run in a seperate
    thread for better performance on dual-core and SMP system.
    Values greater than ONE are not yet supported.


    Grobe Übersetzung auf Deutsch:
    Null [0] deaktiviert Video-Kompressor-Multithreading
    [1] bewirkt, dass den Kompressor in einem separaten ausgeführt
    Thread für eine bessere Leistung auf Dual-Core und SMP-System.
    Werte größer als 1 werden noch nicht unterstützt.


    Also müssen wir ab warten bis z.B. 8 Threads für die Modernen i7 CPU´s mit 8 Logischen CPU´s zur verfügung stehen?



    Video filter threading:
    Video filter process-ahead:


    Kann es sein wenn man hier jeweils 1 frame einstellen würde, das die Abarbeitung bei der Filterung eventuell sauberer ablaufen könnte?
    Zwar extram langsam, aber es wird doch wohl immer nur 1 Bild nach und nach bearbeitet bis es wirklich fertig ist...
    Und erst dann kommt der nächste Frame zum Zug.
    Soweit mein Gedanke dazu!
    Liege ich hier mit der Vermutung richtig?



    VirtualDub x86 + x64 / Preferences - 11.) Playback


    Hier könnte ich doch meine korrekte Audio "Conexant Soundkarte" zum abspielen verwenden, wenn ich das richtig verstehe??
    Ist dann doch besser als das "Default System Playback device" oder?



    VirtualDub x86 + x64 / Preferences - 12.) 3D accel


    Wäre es Sinnvoll diesen zum oben genannten Renderer dazuzuschalten?
    "Use Direct 3D 9/11 (EXPERIMENTAL)"



    VirtualDub x86 + x64 / Preferences - 13.) Batch mode options



    VirtualDub x86 + x64 / Preferences - 14.) Auto-recover options


    VirtualDub can optionally save recovery information before beginning
    a preview or render operation. If a programm failure occurs,
    this information can be used to restore the project state.


    [ ] Enable auto-recover


    Grobe Übersetzung auf Deutsch:
    VirtualDub kann optional Wiederherstellungsinformationen vor Beginn speichern
    eine Vorschau oder Render-Vorgang. Wenn ein Programm-Fehler auftritt,
    Diese Informationen können verwendet werden, um den Projektstatus wiederherzustellen.


    [ ] Enable Auto-wiederherstellen


    Wäre doch eigentlich Sinnvoll diese Option einzuschalten?



    VirtualDub x86 + x64 / Preferences - 15.) Startup options


    The following location will be used for configuration files,
    including the job queue and auto-recover files


    Grobe Übersetzung auf Deutsch:
    Der folgende Speicherort wird für Konfigurationsdateien verwendet,
    die Job-Queue und Auto-wiederherstellen-Dateien mit einschließt.



    VirtualDub x86 + x64 / Preferences - 16.) MRU list size



    VirtualDub x86 + x64 / Preferences - 17.) Exit


    Ask for confimation to close


    [ ] Den Haken kann man ruhig auf Aktiv setzen, wie oben schon beschrieben vor Unabsichtlichen Programm schliessen.


    Ausgabepuffer ist v.a. beim Capturing interessant, wenn unkomprimiertes Video schnell geschrieben werden muss.
    Und moderne Video-Festplatten haben ja auch einen großen Cache.


    Also ist die Funktion nicht wichtig da moderne Festplatten mit einem großen Cache,
    mit dem unkomprimierte Video schon von alleine aus klar kommen...
    So richtig?


    Wave Input - auch nicht wichtig, oder verarbeitest du riesige PCM-WAV-Dateien?


    Kommt drauf an, hatte schon mal eine WAV mit ca. 1 GB.


    Bei der Wahl eines Renderers wird festgelegt, wie die Frame-Inhalte angezeigt werden.


    Danke für die Erklärung :)



    Ähm... ich hatte dich auf der vorherigen Seite aber schonmal darauf hingewiesen, dass du mal mit den Display-Einstellungen dort "rumspielen" sollst - du hattest aber geantwortet, dass das nichts gebracht hat :hm: ...


    Den hatte ich wohl noch nicht probiert ;)


    _
    _
    Hab noch ein paar kleine Fragen zu den restlichen Settings...


    VirtualDub x86 + x64 / Preferences - 03.) Scene change thresholds


    Interframe (cut) und Interframe (fade)

    Kein Plan was die beiden für einen Einfluss haben...
    Da habe ich die Finger von gelassen und nichts verstellt.



    VirtualDub x86 + x64 / Preferences - 04.) CPU Performance optimizations


    Enable all avaiable CPU-specific optimizations
    Klingt Sinnvoll und verstehe ich soweit, das da alle CPU Eigenschaften genutzt werden
    und man siche keine Gedanken mehr machen brauch ob z.B. ein AMD mit SSE2 oder SSE3
    oder ein Intel Pentium 3 Anno 2000 mit MMX oder ohne MMX zugewiesen bekommt oder nicht.


    Da wohl VirtualDub mittlerweile die einzelnen CPU Funktionen in der Moderen Zeit alle automatisch erkennt!
    Someit meine Vermutung dazu :)
    Ist das so korrekt erklärt?



    VirtualDub x86 + x64 / Preferences - 05.) AVI options


    [ ] Prefer internal video decoders over installed third-party codecs (MJPEG and DV)
    Bevorzugen Sie interne Video-Decoder über installierten Fremdanbieter-codecs (MJPEG and DV)


    [ ] Prefer internal audio decoders over installed third-party codecs
    Bevorzugen Sie interne Audio-Decoder über installierten Fremdanbieter-codecs


    Die Haken waren von Werk aus nicht gesetzt!
    Hört sich doch eigentlich ganz praktisch an.
    z.B. beim FFMpeg Input Plugin
    oder sehe ich das falsch??



    VirtualDub x86 + x64 / Preferences - 06.) Timeline format


    VirtualDub x86 + x64 / Preferences - 07.) Render options


    VirtualDub x86 + x64 / Preferences - 08.) Disk I/O


    Diesen Punkt hatten wir ja hier schon mal in diesem Beitrag geklärt :)
    http://forum.gleitz.info/showt…100&viewfull=1#post449100

    Unter Windows ist ja eher Direct3D bevorzugt, wenn man sich da auf mitgelieferte Grafiktreiber von Windows verlässt, wird die OpenGL-Unterstützung nicht so toll sein.


    Direct3D = Das war der entscheide Schlüsselsatz!
    Vielen Dank für den Lösungsansatz :)
    Jetzt läuft alles prima, sauber und flüssig unter VirtualDub und VLC selbstverständlich.


    Durch die ganze Rumprobierei habe ich mir nun die kompletten VirtualDub Settings so verstellt,
    das ich die Ursprungskonfiguration nicht mehr herstellen kann :(
    Soweit ich sehe kann man nach diesem Englischen FAQ das Programm:
    VirtualDub wieder auf seine Werkseinstellung zurücksetzen...
    http://www.virtualdub.org/blog/pivot/entry.php?id=312


    Hab noch ein paar fragen zu meiner verstellten VirtualDub Konfiguraton...



    VirtualDub x86 + x64 / Performance Settings


    AVI Output buffering


    Kann die Konfiguration auf Volle Pulle 64 MB stehen bleiben?
    Wenn JA, was hat die "AVI Ouput buffering" für einen Einfluss?
    Verstehe nicht das sie als Standard Einstellung ca. 2 MB so niedrig eingestellt ist,
    da die Moderen Rechner heute zu Tage viel CPU Power und RAM Arbeitsspeicher, Grafik etc.. zur Verfügung haben.


    Wave input buffering
    War auch sehr niedrig vom Werk aus eingstellt...


    Auf welchen Wert, habt ihr denn den "AVI Output buffering" und "Wave input buffering" stehen?



    Render pipelining
    Kein Plan was sie für Einfluss hat...
    Da habe ich die Finger von gelassen und nichts verstellt.



    VirtualDub x86 + x64 / Preferences - 01.) Main Menü


    http://img.xrmb2.net/images/187860.png --> Update


    Output color depth: 24-bit (TrueColor) ist das Maximale was vom Werk schon eingestellt war.
    Hört sich gut, logisch und Vernüftig an :)


    Die "Process priority" von "Output color depth" und "Dub defaults", habe ich von "Normal" auf "Highest" volle Pulle gestellt.
    Kann man doch nichts verkehrt machen oder???
    Auch hier mein Gedanke,
    da die Moderen Rechner heute zu Tage viel CPU Power und RAM Arbeitsspeicher, Grafik etc.. zur Verfügung haben.


    Oder anders gefragt:
    Auf welche Geschwindigkeit, habt ihr die "Process priority" eingestellt?



    VirtualDub x86 + x64 / Preferences - 02.) Display options


    Und hier nun der Schlüssel zum Erfolg des Gesamten Beitrages!
    "Use Direct 3D 9/11 (EXPERIMENTAL)"
    1x angehakt und mehr hätte ich in den ganzen Optionen nicht verstellen brauchen,
    das das oben genannte Video dadurch nun flüssig läuft :)


    Mit den Renderer Optionen, habe ich noch nie wirklich durchgeblickt.
    Die Begriffe wie "DirectX" + "OpenGL" kannte ich zwar noch aus meiner Gamer Zeit,
    aber soweit ich noch weiß, hing das meistens auch von der verwendeten Grafikkarte ab.
    Ist für mich leider zu kompliziert um die ganze Sache zu verstehen,
    wie was mit der Grafikausgabe zu tun hat oder wie man das genau Physikalisch erklären kann ;)

    nach der Grundinstall und vor dem erstmaligen "ans Netz gehen" hast sicher alle Laufzeitbibliotheken installieren lassen zum Bsp.mit wsusoffline ?


    An Laufzeitbibliotheken ist hier in diesem Pack so gut wie alles enthalten: http://www.sereby.org/site/aio
    Ist ja praktisch fast das selbe wie WSUS nur ohne System Updates.
    Gehe mit dem Rechner ja nicht ins Internet.
    Sonst habe ich immer diese System Updates benutzt: http://winfuture.de/UpdatePack



    Beim MPC-HC kann man leicht den Renderer wechseln.
    Beim VLC muss man schon gut wissen, wo in den Optionen die passende Einstellung ist.


    Am selben Laptop unter Linux Mint 17.2 mit 64-Bit, spielt das Video unter VLC einwandfrei :)
    Ich habe kein Plan mehr, was ich machen soll :(

    Hallo Stax76


    Hab beim AviSynth Plugin: ffms2 einen Fehler in der Versionsbeschreibung gefunden...
    Es soll laut dem StaxRip Programm diese Version installiert sein:

    Code
    1. ffms2 = 2.22 RC2 x64; 2015-05-30


    Laut COPYING.txt Beilage in dem Ordner: both\ffms2 > ist es aber diese Version hier: 2.21 (cec671c)


    Ausserdem bekomme ich folgende Fehlermeldung, wenn ich ein Video per AviSynth + FFMS2 öffnen möchte:


    Hab das alte FFMS2 Plugin aus StaxRip_x64_1.3.2.2_beta > gelöscht
    und gegen diese Version hier Vollständig ersetzt: https://github.com/FFMS/ffms2/releases/tag/2.22


    Nun bekomme ich keine Fehlermeldung mehr und die Videos lassen sich jetzt prima per AviSynth + FFMS2 öffnen


    Ich vermute der Fehler liegt an dieser Datei hier, die man in dem FFMS2 Verzeichnis mit beilegen sollte: ffms2.lib
    Ist dann wohl mal wieder so eine DLL Bibliotheken Laufzeit Geschichte ;)
    Hatte ich damals bei L-SMASH-Works genauso gehabt:
    http://forum.gleitz.info/showt…543&viewfull=1#post449543



    Kannst es ja in der nächsten StaxRip Programm Version dann Aktualisieren...


    Eine frage noch:
    Warum befindet sich eigentlich ffms2 im Verzeichnis: both statt avs ?
    Blicke da nicht ganz durch ;)

    Du könntest z.B. mal mit den Einstellungen in VirtualDub unter "Options" -> "Preferences" -> "Display" rumspielen


    Brachte leider keine Besserung :(
    Hab das BM Test Video mit einer Laufzeit von knapp einer Minute mal auf File-Upload hochgeladen:
    http://www.file-upload.net/dow…ahme20160227MJPG.avi.html
    Würde mich freuen, wenn es jemand von euch unter Windows 7 mit 64-Bit testen kann,
    ob es flüssig unter VirtualDub bzw. VLC läuft?


    Sitze gerade am selben Laptop unter Linux Mint 17.2 mit 64-Bit und dort spielt es unter VLC einwandfrei :)

    Ich bin verwirrt: was sollen die LAV-Filters da jetzt ändern?


    Hab ja kein VfW Blackmagic MJPG Codec auf diesem System Installiert und bekomme bei der Nativen Zuspielung
    von L-SMASH-Works über AviSynth folgenden Decompressor unter VirtualDub angezeigt:
    Internal DIB decoder (YUY2)
    Jetzt nach dem ich die LAV Filters Installiert habe, bekomme ich nun einen anderen Decompressor angezeigt,
    wenn ich das Video ohne AviSynth direkt in VirtualDub als AVI Datei öffne:




    VirtualDub 1.10.x sollte einen internen MJPG-Decoder haben,
    das AVI also direkt öffnen können (zumindest den Video-Anteil; ist das Audio im AVI schon PCM?).


    Das Video lässt sich Trotzdem nicht flüssig abspielen, obwohl die AVI direkt in VirtualDub geöffnet wurde :(


    Ja der Audioanteil in dem AVI ist PCM
    Hier mal die komplette MediaInfo von dem Video --> http://img.xrmb2.net/images/888391.png (Vorsicht großes Bild)



    Was mich eher überrascht, ist die Verwendung von 64-bit-Programmen zum Öffnen von AviSynth-Skripten.
    Da verwendest du wohl AviSynth+?


    Genau AviSynth +
    Und zwar wegen: StaxRip_x64_1.3.2.2_beta
    Inklusive VapourSynth :)


    Step Install 1,2,3,4,5


    1.) AIO-RunTimes Pack --> http://www.sereby.org/site/aio
    2.) MatroskaSplitter
    3.) AviSynth+ r1825
    4.) Python-3.5.1-amd64
    5.) VapourSynth-r31


    Das ist alles was nach der frisch Installation von Windows 7 Pro 64-Bit eingerichtet worden ist.
    Aktuell habe ich noch keine VfW Codecs installiert und auch kein FFDShow etc...
    Es fehlen somit sämtliche Codec´s / Splitter!
    Na gut jetzt sind die LAV Filters heute NEU hinzugekommen ;)


    Und auch über den VapourSynth Frameserver, lässt sich das Video nicht über VirtualDub flüssig abspielen :(
    Ich werd noch Wahnsinnig :D



    'pinterf' hat gerade kräftig die Cache-Verwaltung analysiert und möglicherweise eine Korrektur gefunden für das Problem,
    das z.B. bei QTGMC den Speicher voll laufen ließ.


    Für QTGMC nehme ich aktuell: StaxRip_x64_1.3.2.2_beta > über den Frameserver: VapourSynth
    Kann unter StaxRip_x64 zwischen AviSynth+ und oder VapourSynth wählen, welcher zum Einsatz kommen soll...


    Was heißt eigentlich BM?


    Blackmagic ;)

    Das Problem besteht an meinem Laptop, der gerade frisch mit Windows 7 Pro 64-Bit eingerichtet wurde.
    Aktuell habe ich noch keine VfW Codecs installiert und noch kein FFDShow / LAV etc...
    Es fehlen somit sämtliche Codec´s / Splitter!
    Bin sonst mit AviSynth und den nativen DLL: FFMS2 oder L-SMASH-Works, gut zurecht gekommen :)


    Unter VirtualDub lässt sich das Video nicht flüssig wiedergeben :(
    Genauso wie mit dem VLC Player!
    Ausnahme: Der MPC-HC.1.7.10.x64 spielt das Video soweit flüssig ab.


    Weiß jemand wo der Fehler liegt?


    Hier noch mein Script:


    Code
    1. # Betriebssystem: Windows 7 Professional 64-Bit
    2. # Frameserver Version: AviSynth+ 0.1 r1825, MT, x86_64
    3. # Opener: VirtualDub 1.10.4 x64
    4. # ^^ Darüber werden die *.AVS Scripte geöffnet!
    5. LoadPlugin("C:\AviSynth_x64\L-SMASH-Works\LSMASHSource.dll")
    6. V = LWLibavVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi")
    7. A = LWLibavAudioSource("C:\Videos\BM Test Aufnahme 20160227 MJPG.avi")
    8. AudioDub(V, A)


    Hat überhaupt schon jemand hier aus dem Forum es geschafft ein 4 Stündiges VHS Tape an einem Stück, syncron zu capturen...?


    ja,natürlich,hab ich hier doch schon mehrmals erwähnt.
    Am genauesten gehts mit der NX Karte und da mit dem Canopus HQ in 4:2:2.


    Hatte mich falsch ausgedrückt ;)
    Die Frage sollte lauten:
    Hat überhaupt schon jemand hier aus dem Forum es geschafft ein 4 Stündiges VHS Tape an einem Stück, syncron zu capturen...
    mit dem ES10 als TBC dazwischen geschaltet!

    ich kann den Tonversatz auch bestätigen.
    Habe ein 2-Sunden Video über DMRES10-DMREH495-Blackmagic Shuttle-Blackmagic Software aufgenommen. Der Ton läuft gegen Ende immer mehr auseinander.

    Sowohl brotkasten als auch Bogilein verwenden also den ES10, haben den Ton (wie empfohlen) direkt an den DMR-EH angeschlossen und beide haben Asynchronitäten.

    Genau das wollte ich damit bestätigen :-)
    Deshalb mein Vorschlag:
    Capturen im 4x 60 Minuten Takt und jedesmal auf Aufnahme Stop drücken, wenn die 60 Minuten erreicht sind und dann eine neue Aufnahme anfangen...
    So hat es am besten bei mir funktioniert :)



    Den Tipp von H264x mit den 4x60min werde ich mal ausprobieren. Problematisch wäre es nur, wenn bereits 60min asynchron laufen würden.
    Das habe ich leider noch nicht ausprobiert.


    Und wie schaut es aus?

    Nun habe ich das Problem, dass die digitalisierung eines Tapes mit 4 Stunden Länge bei der Aufnahme selbst zunächst synchron zu sein scheint
    (bis auf die 120ms verzögerung aufgrund des zwischengeschalteten DMR-ES10).


    Das Problem hatte ich auch mal und bis heute nur eine Sinnvolle Lösung dafür gefunden:
    Capture lieber im 4x 60 Minuten Takt und drücke jedesmal auf Aufnahme Stop, wenn die 60 Minuten erreicht sind und fange dann eine neue Aufnahme an.
    Dann hast du 4 große Einzeldateien, die du per "Direct Stream Copy" mit VirtualDub zusammen fügen kannst und danach sollte die Riesengroße 4 Stunden Aufnahme, syncron sein :)


    Ich vermute 4 Stunden an einem Stück zu Capturen funktioniert nicht, da bei dieser Riesigen Datenmenge irgendwas durch einnander kommt, was dafür sorgt, das die Aufnahme nicht Syncron wird...
    Vielleicht weiß jemand anderes hier aus dem Forum, wie man das genau Physikalisch erklären kann ;)


    Anders gefragt:
    Hat überhaupt schon jemand hier aus dem Forum es geschafft ein 4 Stündiges VHS Tape an einem Stück, syncron zu capturen...?