Beiträge von H264x

Zitat von LigH

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)

Zitat von LigH

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

Zitat von LigH

: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

Hier noch ein kleines Text Tutorial zum Screencast Video,
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:

StaxRip 1742 - Bild Anhang Nr.1.png

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

StaxRip 1742 - Bild Anhang Nr.2.png

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

StaxRip 1742 - Bild Anhang Nr.3.png

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

StaxRip 1742 - Bild Anhang Nr.4.png

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)

StaxRip 1742 - Bild Anhang Nr.5.png

6.) Nun sollte das Video korrekt dargestellt werden

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

Zitat von LigH

Wieso der MediaInfo-Report als Bild?

Angewohnheit zur besseren Übersicht (meinerseits)

Zitat von LigH

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

Audio
ID                                       : 1
Format                                   : PCM
Format-Einstellungen für Endianess       : Little
Format-Einstellungen für Sign            : Signed
Codec-ID                                 : 00001000-0000-0100-8000-00AA00389B71 
Dauer                                    : 1min 5s 
Bitraten-Modus                           : konstant 
Bitrate                                  : 2 304 Kbps 
Kanäle                                   : 2 Kanäle 
Samplingrate                             : 48,0 KHz 
BitDepth/String                          : 24 bits 
Stream-Größe                             : 18,0 MiB (4%) 
Ausrichtung                              : Ausgerichtet an Interleaves 
Interleave, Dauer                        : 40 ms (1,01 Video-Frame) 
Interleave, Vorlaufsdauer                : 500 ms

Zitat von LigH

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/download-11478…27MJPG.avi.html
Vielleicht kannst du es ja noch mal mit BeSweet testen?

Zitat von LigH

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

Zitat von stax76

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

Zitat von stax76

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

Zitat von stax76

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

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

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:

Zitat von Gubel

Ich weiß gar nicht mehr, wer mir vor 2 Jahren den Tipp mit dem 2-1-HDMI-Splitter gegeben hatte - ohne dieses Teil wäre der ganze Aufbau auch so nicht möglich gewesen.

Das war meine Wenigkeit

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

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.

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

Soweit wir das hier in diesem Beitrag
http://forum.gleitz.info/showthread.php…ll=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
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.

Zitat von stax76

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

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

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:

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:

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'C:\PortableApps\StaxRip_v1.3.2.0_x64\Apps\Plugins\vs\fmtconv\fmtconv.dll')
import importlib.machinery
adjust = 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]1[/COLOR][/B]) [COLOR=#008000]# Korrekturzeile, die man an dieser Stelle hier noch einbauen sollte...[/COLOR]
clip = havsfunc.QTGMC(Input = clip, [B]BFF[/B] = True, Preset = 'Fast')
clip.set_output()

Zitat von stax76

[Blockierte Grafik: http://s10.postimg.org/vv9banxs9/Unbenannt2.png]

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.

Zitat von sneaker2

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

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

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

Zitat von sneaker2

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

So funktioniert das Script wieder!

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, [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?
Bekomme leider eine Fehlermeldung:
[Blockierte Grafik: http://img.xrmb2.net/images/217789.png]

Hab folgendes Probiert:

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 (Bin mir aber nicht sicher)
Ich probiere später folgende Änderung aus:

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

Zitat von LigH

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

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

Zitat von LigH

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)

Zitat von sneaker2

Code

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

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

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:

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

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:

clip = havsfunc.QTGMC(clip, [B][COLOR=#ff0000]BFF[/COLOR][/B] = True, Preset = "Medium") 
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:

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

Zitat von Nel-son

Code

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

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

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!

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

Vielen Dank

Zitat von Rübezahl

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

Gut zu wissen

Zitat von LigH

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

VirtualDub x86 + x64 / Preferences - 10.) Threading
[Blockierte Grafik: http://img.xrmb2.net/images/480907.png]

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

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

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

VirtualDub x86 + x64 / Preferences - 13.) Batch mode options
[Blockierte Grafik: http://img.xrmb2.net/images/190238.png]

VirtualDub x86 + x64 / Preferences - 14.) Auto-recover options
[Blockierte Grafik: http://img.xrmb2.net/images/811718.png]

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

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

VirtualDub x86 + x64 / Preferences - 17.) Exit
[Blockierte Grafik: http://img.xrmb2.net/images/284616.png]

Ask for confimation to close

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

Zitat von LigH

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?

Zitat von LigH

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

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

Zitat von LigH

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

Danke für die Erklärung

Zitat von Tom Keller

Ä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

Zitat von LigH

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

Zitat von Goldwingfahrer

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

Zitat von LigH

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

Zitat von Goldwingfahrer

ja,es läuft flüssig sowohl unter VDub,VLC3.0 und auch Edius 7.5

Vielen Dank fürs Testen
Nur leider bin ich jetzt Ratlos, warum es bei mir nicht flüssig unter VirtualDub bzw.. VLC läuft
Mit Ausnahme: MPC-HC.1.7.10.x64 spielt das Video soweit flüssig ab.

Hallo Stax76

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

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

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 [Blockierte Grafik: http://forum.gleitz.info/images/smilies/smile_.gif]

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/showthread.php…ll=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