Beiträge von H264x


    Ich habe woanders gelesen, dass x264vfw sein Encodierergebnis auch parallel als eigene Datei herausgeben kann,
    dann wird nur ein "leeres" AVI vom Videoprogramm geschrieben, welches den Codec benutzt.
    Dann müsste das Ergebnis mit dem des eigenständigen Encoders gleichwertig sein.


    Bin gerade dabei den x264vfw Codec auszuprobieren um eine RAW ohne Container zu schreiben.
    Unter "Output mode" kann man zwischen VFW oder File wählen.
    Hab jetzt File gewählt und wollte mal wissen, was das mit den verschiedenen VFW FourCC Varianten auf sich hat?




    Und was bedeutet eigentlich die VirtualDub Hack funktion genau?
    Verstehe grob übersetzt, das wenn man die funktion Aktiviert (Haken gesetzt),
    das es zu invalid bitstreams kommen kann...





    Hab gerade gesehen, das es auch einen x265vfw Codec gibt :)
    http://forum.doom9.org/showpost.php?p=1755259&postcount=6


    Kurze frage am Rande...
    Hat jemand schon Erfahrung damit gemacht?
    Also hier gibt es schonmal 5 Sterne für den x265vfw:
    https://sourceforge.net/projec…play/?source=typ_redirect
    Sieht sehr vielversprechend aus.


    Auch hier gillt bestimmt die goldene Regel, das HEVC nichts im AVI Container zu suchen hat ;)
    So wie es schon bei AVC im AVI Container war.


    Also bitte "x264vfw" oder "x265vfw" nur für die RAW Ausgabe benutzen,
    damit das Ergebnis mit dem des eigenständigen Encoders gleichwertig anzusehen ist!!

    1. VOBInput.dll direkt zur BeSweet.exe legen;


    Gar nicht mal so einfach, diese DLL Datei noch aufzugabeln ;)


    http://dspguru.doom9.org/effects.html -> Der Link scheint tot zu sein.


    Und nach einer gefühlten halben Stunde suchen im Netz, habe ich die "VOBInput.dll" doch noch gefunden unter:
    http://www.doom9.org/index.html?/Old_news/september02.htm



    2. AVI-Datei direkt als core( -input ... ) verwenden.


    Schade, es bleibt weiterhin bei dieser Fehlermeldung hier: #58


    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.m4a" ) -bsn( -vbr 0.45 )"



    Dann hast du auch noch nicht getestet, ob BeSweet mit der VOBInput.dll die AVI-Datei direkt verarbeiten kann, ohne den Ton als WAV zu extrahieren.


    Könntest du mir den kompletten Befehl zur Umwandlung direkt aus dem AVI Container verraten?
    Dann teste ich das später nachträglich :)


    Aber QAAC müsste auch 24b-WAV verarbeiten.


    Das klappt einwandfrei und habe ich unter Punkt 08.) schon aufgelistet :)

    Code
    1. [U]
    2. Als Alternativen bieten sich direkt folgende Möglichkeiten an:[/U]
    3. WAV Audiospur mit EAC3to umwandeln.
    4. WAV Audiospur mit FFMpeg umwandeln.
    5. WAV Audiospur mit QAAC umwandeln.
    6. WAV Audiospur mit LameXP umwandeln.
    7. [COLOR=#008000]^^ Diese 4 können eine WAV Datei mit 24-Bit direkt zu AAC im m4a Container verarbeiten ohne dabei den Umweg über Audacity zu gehen ;)[/COLOR]

    Wie es schon hier in diesem Beitrag kurz angesprochen wurde...


    Bekomme folgende Error Meldung bei der Umwandlung mit BeSweet rein...
    http://img.xrmb2.net/images/199956.png
    Die Audiospur ist: WAV in diesem AVI Container, die ich zu AAC / m4a umwandlen möchte!



    PCM 24 bit sollte BeSweet eigentlich verarbeiten können, dachte ich.
    Mit der VOBInput.dll sogar aus der AVI heraus (klingt paradox, ist aber wahrscheinlich so). Wundert mich, dass das Probleme gibt.


    Hier nun mein Lösungsvorschlag von mir als kleines Text Tutorial :)


    01.) Beispiel Video, was für diesen Versuch genommen wurde:
    Hier ist Übrigens das Original BM Test Video dazu: http://www.file-upload.net/dow…ahme20160227MJPG.avi.html
    Solange es noch auf File-Upload online ist, kann es jeder der möchte, nach dieser Methode ausprobieren...



    02.) Demux WAV from AVI
    VirtualDub x86 or x64 > starten
    *.AVI Video öffnen
    > In meinem Beispiel: BM Test Aufnahme 20160227 MJPG 1080i.avi
    Oben in der Menüleiste auf: File > Save WAV > klicken
    WAV Datei abspeichern
    > In meinem Beispiel unter: C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.wav
    VirtualDub x86 or x64 > schließen


    03.) So sieht es dann aus, wenn die WAV seperat gespeichert ist:



    04.) MediaInfo von dieser demuxten WAV Datei durch VirtualDub:




    05.) Erster Versuch mit BeSweet diese WAV Datei (24-Bits) zu AAC [ -VBR 0.45 ] im m4a Container umzuwandeln.bat

    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.wav" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.m4a" ) -bsn( -vbr 0.45 )"Pause



    06.) Fehlermeldung #58 von BeSweet zu dieser 24-Bit WAV Datei:



    07.) Meine Vermutung zur Fehlermeldung #58 von BeSweet ist...
    Wie es schon im Titeltext von diesem Beitrag steht:
    BeSweet kann keine WAV Dateien mit 24 bits umwandeln!



    08.) Mein Lösungsvorschlag dagegen lautet...


    WAV Datei mit Audacity von 24 bits zu 16 bits umwandeln:
    Audacity > starten
    *.WAV Datei öffnen
    > In meinem Beispiel: BM Test Aufnahme 20160227 MJPG 1080i.wav
    Oben in der Menüleiste auf: Datei > Ton epotieren > klicken
    WAV Datei abspeichern mit folgenden Dateityp: [ WAV (Microsoft) signed 16-bit PCM ]
    > In meinem Beispiel unter: C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.wav
    Audacity > schließen


    Code
    1. [U]Als Alternativen bieten sich direkt folgende Möglichkeiten an:[/U]WAV Audiospur mit EAC3to umwandeln.WAV Audiospur mit FFMpeg umwandeln.WAV Audiospur mit QAAC umwandeln.WAV Audiospur mit LameXP umwandeln.[COLOR=#008000]^^ Diese 4 können eine WAV Datei mit 24-Bit direkt zu AAC im m4a Container verarbeiten ohne dabei den Umweg über Audacity zu gehen ;)[/COLOR]



    09.) Nun habe ich ja in diesem Beispiel schon den Weg mit Audacity begonnen!
    Was eigentlich total überflüssig ist ;)
    Und so sieht es dann aus, wenn die 24 Bit WAV als neue Datei mit Audacity als 16-Bit WAV geschrieben worden ist:



    10.) MediaInfo von der neuen WAV Datei mit 16-Bits, dank Audacity:
    Direkt mal 6 MB gespart ;)




    11.) Gegenprobe = Neuer Versuch mit BeSweet, die neue WAV Datei mit 16-Bits zu AAC [ -VBR 0.45 ] im m4a Container umzuwandeln.bat

    Code
    1. "C:\PortableApps\StaxRip_x64_1.3.4.6_test\Apps\BeSweet\BeSweet.exe" -core( -input "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.wav" -output "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i - Neu als 16-Bits.m4a" ) -bsn( -vbr 0.45 )"
    2. Pause



    12.) Diesmal war BeSweet erfolgreich bei der Umwandlung :)



    13.) Fertig :)


    Dieser Beitrag soll verdeutlichen, das es trotzdem mit BeSweet weiter gehen kann ;)

    Betrachten wir hier mal konkret den Zweck, dass libavcodec nur einen Decoder-Thread verwenden soll....


    Also bei diese beiden "xSource" Quellen, kann man dann sagen, dass der libavcodec nur einen Decoder-Thread verwenden soll :)


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


    ...weil bei manchen Kombinationen aus Container und Inhaltsvariante mehrere Threads nicht ganz zuverlässig arbeiten könnten.


    Gut das es eine Absicherung dagegen gibt ;)
    Wenn man ,threads=1 weglässt, kann was passieren, muss aber nicht.



    :eek: Gut zu wissen... e-m-b-e-d ist ja zensiert.


    Was heißt das mit "e-m-b-e-d ist ja zensiert" genau?
    Verstehe ich gerade nicht ;)


    Code
    1. Hier noch ein kleines Text Tutorial zum Screencast Video,
    2. wie man die Script Änderung per Hand vor dem Encoding Prozess in StaxRip vornehmen kann:


    https://vimeo.com/164821196


    1.) Quell Video in StaxRip per AviSynth + FFVideoSource laden:




    2.) Im Temp Ordner, den StaxRip zu jedem Video erstellt, kann man sich die Scripte vorher anschauen (Nicht dort editieren)




    3.) Wenn in der StaxRip Preview, das Video der Zeit noch nicht korrekt dargestellt wird... dann bei Schritt 4 weiter machen




    4.) Jetzt kommt die Manuelle Script Änderung in StaxRip per Hand zum Einsatz:




    5.) Zum Abgleich noch mal einen kurzen Blick in den Temp Ordner werfen um sich die Scripte anzuschauen,
    wie sie von der "Internen Script Edit Zentrale" in StaxRip verändert worden sind...
    (Hier nichts verändern! Nur zum Abgleich anschauen)




    6.) Nun sollte das Video korrekt dargestellt werden :)


    Vorsicht großes Bild
    http://img.xrmb2.net/images/638138.png

    Wieso der MediaInfo-Report als Bild?


    Angewohnheit zur besseren Übersicht (meinerseits) ;)


    Du kannst die Analyse auch im Format "Text" exportieren und hier als Code einfügen oder auf einen pastebin laden... nun gut.



    PCM 24 bit sollte BeSweet eigentlich verarbeiten können, dachte ich.
    Mit der VOBInput.dll sogar aus der AVI heraus (klingt paradox, ist aber wahrscheinlich so).
    Wundert mich, dass das Probleme gibt.


    Normalerweise kann BeSweet: WAV Dateien umwandeln...
    Vielleicht liegt es ja an der Samplingrate mit 48,0 KHz + 24 Bits, die den Error Code 58 produziert ?
    Hier ist Übrigens das Original BM Test Video: http://www.file-upload.net/dow…ahme20160227MJPG.avi.html
    Vielleicht kannst du es ja noch mal mit BeSweet testen?


    Extrahiert StaxRip dann die Tonspur falsch in eine WAV-Datei


    Das Demuxen macht StaxRip einwandfrei :)
    Neuerdings per FFMpeg Batch Befehl, statt wie bisher per VirtualDubMod (demux)
    Auch die Gegenprobe mit VirtualDub demux, wenn die WAV Datei nun aus dem AVI Container draussen ist,
    funktioniert nicht mit dem Manuellen "BeSweet" Befehlsaufruf.

    Seit der letzten Stable hat sich viel getan, ich hab ein Modultest der anzeigt wenn die Version von einem Paket nicht stimmt.


    Hab nun diese hier installiert: StaxRip_x64_1.3.4.6_test
    inkl. AviSynth+_r1849-MT-pfmod with VDubFilter x64 fix (Update)


    Der Modul Test scheint zur Zeit nicht zu funktionieren, da immer noch alle Apps als "Unknown version" ausgegeben werden...
    Weißt du was da los ist?
    Siehe auch mein Screencast Video dazu: https://vimeo.com/164111384


    In StaxRip und vielen anderen Programmen mit ordentlicher Benutzeroberfläche gibt es unzählige Funktionen die man nicht auf Anhieb findet


    Hab die Interne Script Edit Zentrale für AviSynth und oder VapourSynth nun gefunden :D


    Hab ich vor ein paar Tagen upgedatet, Lib Datei ist jetzt auch dabei.


    Nun ist es so, das bei der Version 2.22 von ffms2,
    wenn man ein Video per AviSynth + FFVideoSource öffnen möchte,
    das es komplett Grün und auf dem Kopf dargestellt wird ;)
    In meinem Beispiel war es eine AVI mit dem Blackmagic MJPG Codec als 1080i
    Abhilfe schafft hier folgende Manuelle Script Änderung per Hand:

    Zitat

    FFVideoSource("C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i.avi", cachefile = "C:\Videos\BM Test Aufnahme 20160227 MJPG 1080i_temp\BM Test Aufnahme 20160227 MJPG 1080i.ffindex",threads=1,colorspace="YUY2")


    Nach der Script Korrektur wird es im Preview Vorschaufenster von StaxRip korrekt ausgegeben :)
    Das threads=1 ist dafür da, das es bei 64-Bit Systemen zu keinem Decoder-Thread Überlauf kommen kann, der wohl Fehler produziert.


    StaxRip erkennt dieses Video an Hand seiner Header Informationen nämlich einwandfrei :)



    Wie schon oben beschrieben,
    fehlen zur Vervollständigung noch 2 Befehle im AviSynth Script bei FFVideoSource, damit es korrekt ausgegeben werden kann.
    Siehe auch mein neustes Screencast Video dazu:

    LigH


    MediaInfo --> http://img.xrmb2.net/images/888391.png (Vorsicht großes Bild)


    stax76


    Hier noch ein paar Aufälligkeiten zur der Stable Version von StaxRip_x64_1.3.4.0
    Hab zu den Fehlern jeweils kurze Screencast Videos erstellt...
    Vielleicht weißt du ja Rat?


    1.) Unter Apps / Status wird alles als "Unknown version" ausgegeben:
    Bei der Vorherigen Version: 1.3.2.2_beta von StaxRip_x64 war der Status auf
    OK in Ordnung.




    2.) https://vimeo.com/164111709

    Bei der Version 2.21 von ffms2, bekomme ich weiterhin folgende Fehlermeldung, wenn ich ein Video per AviSynth + FFVideoSource öffnen möchte.
    Und mit VapourSynth + ffms2 stürzt StaxRip ab :(




    3.) https://vimeo.com/164111956


    Bei der Version 2.22 von ffms2, ist soweit alles in Ordnung per VapourSynth + ffms2
    Wenn man ein Video nun per AviSynth + FFVideoSource öffnen möchte,
    wird es komplett Grün und auf dem Kopf dargestellt ;)


    Nach der Manuellen Script Korrektur unter VirtualDub wurde das Video korrekt ausgegeben :)

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


    Mir ist an einem anderen Beispiel Video aufgefallen,
    das StaxRip bei manchen Videos den korrekten Farbraum automatisch findet und in seinen Scripts mit einbindet:
    z.B.

    Code
    1. LWLibavVideoSource("C:\Videos\Test123.mkv", format = "YUV420P8")


    Soweit wir das hier in diesem Beitrag
    http://forum.gleitz.info/showt…979&viewfull=1#post454979
    es schon soweit kurz angesprochen haben, sollte man bestimmte Befehle bei den "xSource" Quellen noch angeben,
    damit sie vom "Farbraum" und der "Framerate" richtig erkannt werden
    und unter Windows7 mit 64 Bit, sollte man noch einen Riegel auf
    "threads=1" setzen,
    da sonst fehler passieren können, wenn mehrere
    Decoder-Threads gleichzeitig laufen...


    Bis jetzt kenne ich nur 2 "xSource" Quellen bei dem man diese Parameter setzen sollte:


    FFVideoSource("inputVideo",threads=1,colorspace="XXX",fpsnum=XX)
    LWLibavVideoSource("inputVideo",threads=1, format = "
    XXX",fpsnum=XX)


    Das wird eine große Herausforderung werden zu jedem Video die passende:
    Framerate + ColorSpace inkl. ChromaSubsampling, automatisch erkennen zu lassen,
    so das sie per FFMS2 oder L-SMASH Source richtig angewendet werden.


    Könnte man vielleicht einen kleinen Script Editor in StaxRip für die Abarbeitungs Scripte einbauen,
    bevor StaxRip mit dem Encoding Process startet?
    So könnte man sich die Haupt Scripte noch mal anschauen und Notfalls vor der Abarbeitung von Hand selber korregieren :eagerness:
    Im Temp Ordner, den StaxRip automatisch erstellt, kann man sich zwar die Scripte
    noch mal ansehen
    und auch mit einem Text Editor bearbeitung nur dann, wenn man im StaxRip Programm auf ENCODING Start drückt,
    wird das geänderte Script nicht übernommen, sondern der Ursprung des jeweilgen Scriptes wieder hergestellt.

    Folgendes ist im letzten Test Build neu:


    Vielen Dank für das Update :)
    Die Tagen kommen noch ein paar kleine Fehlermeldungen aus der Stable Version von StaxRip_x64_1.3.4.0
    Bin gerade fleißig am testen ;)
    Erstmal eins nach dem anderen...


    Bekomme folgende Error Meldung bei der Umwandlung mit BeSweet rein...
    Die Audiospur ist: WAV in diesem AVI Container, die ich zu AAC / m4a umwandlen möchte!
    "eac3to" oder "ffmpeg" oder "qaac" verrichten ihre Arbeit sauber :)


    Was ist da los mit BeSweet unter Windows 7 / 64-Bit ?

    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.