Beiträge von H264x


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

    Hallo, nutze schon seit einiger Zeit die Professional Version von Windows 7 mit 64-Bit.
    Heute ist mir was merkwürdiges passiert...

    Als ich die Datei [ ffmpeg.exe ]
    in einen der beiden System Ordner kopiert habe, wird sie automatisch doppelt gespiegelt :indecisiveness:


    Dabei ist es egal ob sie zuerst in System32 oder in SysWOW64 kopiert wird...
    Sie ist immer in beiden Ordner wie durch Zauberhand vorhanden!
    Mitlerweile habe ich rausgefunden, das der Dateityp dabei keine Rolle spielt.
    Ob *.exe *.txt usw....
    Man kann alles Mögliche in eins der beiden System Ordner kopieren.

    Weiß jemand, warum das so ist?

    Laut welcher Dokumentation sollte LWLibavVideoSource() die besitzen? Ich kenne nur "format".
    Siehe README, die meist beiliegt.


    Das war geraten!
    Hab gedacht man könnte die Scripte untereinnander abändern ;)
    z.B. Als Vorlage diente...

    Code
    1. AviSource("Test.avi[size=18][COLOR=#0000ff][B]"[/B][/COLOR][/SIZE],pixel_type="YV12")


    Habe nun den Befehl mit "format" getauscht, trozdem funktioniert die Manuelle PixelType Zuweisung mit L-SMASH nicht :(

    Code
    1. LWLibavVideoSource("FFMpeg.Screencast.Test.REC.mkv[size=18][COLOR=#0000ff][B]"[/B][/COLOR][/SIZE],format="YV24")


    Als Fehlermeldung bekomme ich: Script error expected a, or
    Was mache ich falsch?

    Habe hier auch eine Screencast Aufnahme mit dem Format-Profil: High 4:4:4 Predictive@L3.0


    Siehe MediaInfo Log: http://img.xrmb2.net/images/120856.png (Achtung großes Bild)


    Code
    1. LWLibavVideoSource("FFMpeg.Screencast.Test.REC.mkv")


    Im Automatik Modus erkennt L-SMASH-Works folgenden PixelType:


    Probiere ich die Manuelle PixelType Zuweisung per L-SMASH-Works aus, bekomme ich eine Fehlermeldung...

    Code
    1. LWLibavVideoSource("FFMpeg.Screencast.Test.REC.mkv[size=18][COLOR=#0000ff][B]"[/B][/COLOR][/SIZE],pixel_type="YV24")


    Ist YV24 überhaupt korrekt für High 4:4:4 Predictive ??

    Am Anfang war ich sehr enttäuscht von AviSynth (Plus),
    da viele Scripte aus der alten x86 Umgebung nicht mehr so liefen wie ich es mir vorgestellt hatte...
    Zumindest bei meinen letzten Test Versuchen vor einem halben Jahr!
    Aber nun dank StaxRip + AviSynth (Plus) 64-Bit + VapourSynth, läuft der FrameServer ganz Ordentlich.
    Mit VapourSynth hat man eine Zusätzliche Ausweich Möglichkeit,
    wenn es Funktionen gibt, die mit AviSynth (Plus) der Zeit noch nicht klappen (sollten / hätten / können / etc...)
    ;)

    Hatte letztens auch nochmal mit dem Blackmagic-Support geschrieben,
    weil die Shuttle erst nicht an meinem süßen neuen Lenovo "Ultrabook'chen" mit Intel-USB3.0 laufen wollte......


    Welches Lenovo Ultrabook´chen hast du denn... (Modell ??)
    ;)



    Warum ich gerne diesen Lösungsweg versuche, und nicht den USB 3.0 Shuttle?
    Nun, die Kosten zw. einem Hyperdeck und dem Shuttle halten sich fast die Waage, habe ein Hyperdeck für 160€ bekommen.


    Das Teil ist wirklich praktisch, da es für die Aufnahme ganz ohne PC / Laptop auskommt.
    Wollte mir das Hyperdeck vor Jahren auch mal kaufen, aber vom Preis war es damals unter 300 € schwer zu bekommen.
    Glückwunsch zu deinem 163,50 € Schnäppchen ;)
    http://www.ebay.de/sch/i.html?…=0&_sop=12&_dmd=1&_ipg=50


    Auf dieser Seite steht, das das BM-Hyperdeck keine Probleme mit der Aufnahme von 576i hat.


    Dann haben wir ja jetzt ein weiteres Aufnahmegerät für die Hosentasche :D
    Für den Hifi Audio Bereich gibt es quasi den Bruder: http://www.amazon.de/Tascam-DR-05V2-DR-05-V2/dp/B00LU8K790
    Wenn man Tapes und Vinyl ohne PC / Laptop digitalisieren möchte...

    Zu dem Thema fällt mir ein super Zitat ein :)