BM Video ruckelt unter VirtualDub, VLC (Keine flüssige Wiedergabe) Ausnahme: MPC-HC

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

    [Blockierte Grafik: http://img.xrmb2.net/images/290092.png]

    Einmal editiert, zuletzt von H264x (12. April 2016 um 13:11)

  • Ja ist ein Motion-JPEG Video.
    Hab es damals noch unter XP Zeiten mit AviSynth und den nativen DLL: FFMS2 oder L-SMASH-Work flüssig und sauber decodiert bekommen!
    Nur jetzt bei Windows 7 Pro 64-Bit sitzt irgendwo der Wurm :(
    Probiere gleich mal die LAV Filters auf meinen System zu Installieren, obwohl ich ja nur mit den Nötigstens auskommen wollte ;)

  • Ich bin verwirrt: was sollen die LAV-Filters da jetzt ändern? Das sind DirectShow-Filter/Decoder. Und weder VirtualDub noch VLC können nativ DirectShow-Decoder verwenden.

    Abgesehen davon: für die Decodierung in AviSynth ist doch grundsätzlich der Quellfilter (also in diesem Fall: FFMS2/L-SMASH) verantwortlich - VirtualDub, VLC, MPC-HC bekommen dann immer nur das unkomprimierte Video geliefert und müssen "schlimmstenfalls" noch eine Farbraumkonvertierung vornehmen... aber eben nichts anderes machen.

    Die Ursache könnte aber eventuell darin liegen, dass der MPC-HC (meines Wissens) als einziger das AviSynth-Script nativ über die eingebauten LAV-Filters öffnen kann und nicht auf den Umweg über das uralte VfW-Interface angewiesen ist. VirtualDub ist allerdings darauf angewiesen (es sei denn du erzwingst die Verwendung vom Ffmpeg-Input-Plugin für das Script)... beim VLC bin ich mir nicht ganz sicher. Die Installation der Standalone-LAV-Filters ändert daran allerdings (wie gesagt) nichts.

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

  • 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?).

    Ansonsten ist es sicher keine gute Idee, ein AviSynth-Skript mit libav-basierenden Playern zu öffnen anstatt direkt die MJPG-AVI-Datei, deren Inhalt sie wahrscheinlich hervorragend decodieren können.

    Was mich eher überrascht, ist die Verwendung von 64-bit-Programmen zum Öffnen von AviSynth-Skripten. Da verwendest du wohl AviSynth+? Bleib da mal informiert über die Weiterentwicklung, '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ß. Es sollte also hoffentlich bald eine neue Release-Version kommen.

    Was heißt eigentlich BM?

  • 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:

    [Blockierte Grafik: http://img.xrmb2.net/images/728335.png]


    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 ;)

    5 Mal editiert, zuletzt von H264x (12. April 2016 um 20:53)

  • 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:

    [Blockierte Grafik: http://img.xrmb2.net/images/728335.png]


    Der Internal DIB decoder (YUY2) ist für die Verarbeitung und Anzeige von unkomprimiertem(!) Video im YUY2-Farbraum da - also das, was (wie schon erwähnt) ein AviSynth-Script IMMER ausspuckt: unkomprimiertes Video. Die Videodecodierung übernimmt dabei L-SMASH.

    Wenn du die MJPG-AVI direkt öffnest, kommt der Internal Motion JPEG decoder (MJPG) zum Einsatz - das ist der von von 'LigH' erwähnte MJPG-Decoder, der in VirtualDub eingebaut ist. Die Videodecodierung übernimmt dabei VirtualDub selbst.

    Mit der Installation der LAV-Filters hat aber nichts davon zu tun ;) .


    Letztendlich glaube ich nicht, dass hier die Ursache für das Ruckeln am Decoder liegt, sondern eher irgendwo zwischen Decoder und Ausgabe. Du könntest z.B. mal mit den Einstellungen in VirtualDub unter "Options" -> "Preferences" -> "Display" rumspielen (erstmal alle Anzeigebeschleunigungen abschalten und schauen, ob es was bringt... falls ja: nach und nach anschalten) bzw. unter "Options" -> "Allow Video Overlays" abschalten.

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

  • 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/download-11478…27MJPG.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 :)

  • Hi

    Bis auf den Matroska Spltter habe ich hier nichts vom unten Gezeigten installiert.
    Avisynth natürlich schon aber nichts von "+"

    Zitat

    ....der gerade frisch mit Windows 7 Pro 64-Bit eingerichtet wurde.


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

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Dass mindestens ein Player es flüssig abspielen kann, bestätigt erst mal den Verdacht, dass es grundsätzlich möglich ist. Es liegt also an gewissen Rahmenbedingungen, dass bestimmte Player das nicht hinkriegen. Dass verschiedene Player verschiedene Renderer (oder grundsätzlich: Ausgabetechniken) verwenden, kann da schon ein wesentlicher Faktor sein. Gerade auch wenn ein Teil der Wiedergabe-Kette an Grenzen eines Bauteils stößt.

    Beim MPC-HC kann man leicht den Renderer wechseln. Beim VLC muss man schon gut wissen, wo in den Optionen die passende Einstellung ist. Bei VirtualDub hat man kaum eine Wahl (außer DirectX und Overlay, relativ allgemein). Aber es muss nicht unbedingt der Renderer sein, der hier Flaschenhals ist...

  • 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 :(

  • Tja ... ich weiß nicht genau, welcher Renderer im VLC Standard war, evtl. OpenGL; da hängt es dann sehr vom OpenGL-Grafik-Treiber des Herstellers ab. 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. Aber auch unter Windows wäre es denkbar, dass man noch mal DirectX zusätzlich installieren sollte, damit auch Direct3D-Renderer optimal laufen ... vielleicht solltest du wirklich mal 1. nachschauen, welcher eingestellt ist, und 2. auch mal andere testen.

  • 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...
    [Blockierte Grafik: http://img.xrmb2.net/images/824339.png]


    VirtualDub x86 + x64 / Performance Settings
    [Blockierte Grafik: http://img.xrmb2.net/images/905522.png]

    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ü
    [Blockierte Grafik: http://img.xrmb2.net/images/104484.png]

    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
    [Blockierte Grafik: http://img.xrmb2.net/images/716248.png]

    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 ;)

    6 Mal editiert, zuletzt von H264x (14. April 2016 um 12:13)

  • Ja, mit auxsetup kann man die Einstellungen wieder zurücksetzen.

    AuxSetup_Remove.png

    Ausgabepuffer ist v.a. beim Capturing interessant, wenn unkomprimiertes Video schnell geschrieben werden muss. Bei komprimierter Ausgabe weniger wichtig, da geht es ja nicht um Echtzeit. Muss also nicht größer als nötig sein. Und moderne Video-Festplatten haben ja auch einen großen Cache.

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

    Process Priority: "Highest" ist sicher falsch, hier kannst du den Rest des PCs fast unbedienbar machen, wenn eine Konvertierung angefangen hat. Lass das auf "normal" oder höchstens etwas höher.

    Bei der Wahl eines Renderers wird festgelegt, wie die Frame-Inhalte angezeigt werden. Am kompatibelsten sind DIB-Funktionen, aber auch am langsamsten: Hier wird das Video-Frame mit uralten Funktionen wie ein BMP-Bild auf dem Programm-Fenster dargestellt. Deutlich schneller ist das Hardware-Video-Overlay, da wird das Frame in einen vom PC aus nur beschreibbaren, aber nicht auslesbaren Bereich hinterlegt, der dann von der Grafikkarte über ein Rechteck mit spezieller Farbe geblendet wird. Bei OpenGL oder Direct3D werden aber die 3D-Beschleuniger-Funktionen benutzt, die in Spielen beispielsweise Texturen projizieren; das kann noch schneller gehen und unterstützt auch Skalierungen und YUV-Formate (evtl. sogar "halb decodiertes JPEG", also DCT-Makroblöcke, über Videobeschleuniger-Funktionen) recht unkompliziert.

  • 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 :)


    Ä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: ...

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.


  • 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
    [Blockierte Grafik: http://img.xrmb2.net/images/560705.png]

    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
    [Blockierte Grafik: http://img.xrmb2.net/images/818902.png]

    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
    [Blockierte Grafik: http://img.xrmb2.net/images/511741.png]

    [ ] 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
    [Blockierte Grafik: http://img.xrmb2.net/images/121998.png]

    VirtualDub x86 + x64 / Preferences - 07.) Render options
    [Blockierte Grafik: http://img.xrmb2.net/images/731505.png]

    VirtualDub x86 + x64 / Preferences - 08.) Disk I/O
    [Blockierte Grafik: http://img.xrmb2.net/images/872948.png]

    Diesen Punkt hatten wir ja hier schon mal in diesem Beitrag geklärt :)
    http://forum.gleitz.info/showthread.php…ll=1#post449100

    Einmal editiert, zuletzt von H264x (14. April 2016 um 16:15)

  • Normalerweise solltest du davon ausgehen, dass Standardeinstellungen nicht ganz unvernünftig gewählt sind, weil hier ein Programmierer am Werk war, der aus seiner eigenen Praxis die Erfahrungen gesammelt hat, die man braucht, um da vernünftige Werte einzustellen. Ganz besonders was Puffergrößen und Prioritäten angeht. Früher, als die Festplatten noch etwas langsamer waren und deren Ansteuerung mit Techniken passierte, die den ganzen PC schon mal für kurze Zeit blockieren konnte, war es wichtig, dass eben diese Plattenzugriffe die Aufnahme einer analogen Capture-Karte nicht unterbrechen. Auf solche Extremsituationen sind diese Werte optimiert. Diese Extremsituationen gibt es heute kaum noch. Beim bloßen Abspielen erst recht nicht. Also wenn du nicht weißt, warum ausgerechnet deine Wahl besser sein soll, lass es, wie es ist.
    __

    "Eingebaute Decoder" bedeutet "ohne jedes Plugin". MJPEG und DV kann VirtualDub auch ganz alleine decodieren, und das ziemlich exakt und zuverlässig (MPEG-1 auch, aber das gehört nicht in einen AVI-Kontainer). Welche internen Audio-Decoder gemeint sind, weiß ich aber nicht. Vielleicht nur ein Roh-Sample-Konverter. In der Dokumentation ist für mich bisher nichts dazu zu finden. War vielleicht mal angedacht...

  • Damit schneide ich über den schnellen Vorlauf nach Szene, ich erspare mir also die Sichtung im Originaltempo.
    Die Vorschau stoppt auch bei kleinen Bildfehlern, wenn die Sensibilität erhöht wird.
    Meine Werte liegen alle mehr rechts von den Voreinstellungen, ausprobieren!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!