QTGMC Avisynth 2.6 x264 crash

LigH, Selur
MSVC*.DLLs waren nicht im AviSynth-Plugins-Verzeichnis, nur in System32 beim x86 PC. alle dlls etc sind jetzt von avisynth extension für hybrid - habe die unnötigen gelöscht. 1. reihe im avisynth-plugin ordner 2. in System32 und 3. als extra ordner: Bild.
werde wsusoffline c++ Laufzeitbibliotheken am x86-PC nach/neu-installieren und es dann nochmal mit megui probieren und danach endlich mit hybrid. am x64 pc geht das script jetzt ohne probleme. (dort hatte ich vergessen die msvc*.dlls zu löschen ...). avisynth über wine - hybrid unter ubuntu dürfte ev. sogar schneller sein ... müsste man testen.

Goldwingfahrer
Quelle ist eine ältere Sony-DV-Kamera also wird auch der Sony-DV-Codec verwendet ... dvsd. Überspielt mit Pinnacle Studio 15 (eigentlich nur wegen der Szenenerkennung ... bzw. wegen rudimentärer Nachbearbeitung Titel, Übergänge etc.) normalerweise capture ich mit dem etwas älteren TMPGEnc Authoring Works 4 - früher vor allem wegen den einfachen, selbst erstellbaren dvd-menüs. Gibts für Capturing eine bessere Programm-Empfehlung - eh vl sogar Virtualdub?
Wie geht das mit dem 'Grauschleier' entfernen - seh ihn eigentlich nicht wirklich in vdub mit ffdshow ... das konvertieren von dvsd nach cdvc mit zb Canopus-DV-File-Converter geht bei mir nicht. unter Virtualdub gibts ja nur den decompressor nicht den encoder ... wie/womit hast du das gemacht, Adobe Premiere oder sowas?

danke für die info. WinDV werde ich das nächste mal ausprobieren. EDIUS Pro 7 wäre schon fein, leider könnte ich es, wenn ich es mir kaufen würde, nur auf meinem x64 PC verwenden, da 64-bit ab Win7 Vorraussetzung ist. hatte sogar am alten PC zuvor ein x64 Win7 drauf, musste aber leider wegen fehlendem Scanner-Treiber zurück auf x86 wechseln. Die Codecs (EDIUS Codec Option 7.30) hab ich mir geholt und kann jetzt auch unter vdub von dvsd nach cdvc 'umwandeln'. ist das eigentlich verlustfrei bzw. ist der verlust so gering, dass es eigentlich egal ist? und hab ich das jetzt richtig verstanden, dass Grauschleier entfernen mit EDIUS Änderungen an Farben/Helligkeit/Kontrast/Gamma etc. bzw. den YUY-Kurven ist? Wenn ja, so perfekt muss das ganze nicht werden; dafür gibts eben professionelle software. das Endergebnis mit x264 soll nur ungefähr gleich schlecht aussehen wie das original - vor allem wenn ich mir anschaue, wie grauenhaft zb Farben/Sättigung etc. auf vielen Fernsehern eingestellt sind.

bezüglich crash:
das script funktioniert jetzt auch am x86 pc - die dlls sind jetzt die gleichen wie im vorherigen bild. gerade läufts mit megui danach mit hybrid. da das aber ungefähr einen halben tag pro encoding dauert wird es noch etwas dauern bis ich weiss, obs jetzt endlich funktioniert ...

Soda, endlich - jetzt hab ichs anscheinend hinbekommen, kein crash mehr - egal ob mit megui oder hybrid. kann dann eigentlich eh nur an den anderen plugin-dlls von avisynth-extension gelegen haben ... danke vielmals für die hilfe.

Goldwingfahrer
Hab gerade EDIUS 6 Trial getestet und alles ausprobiert was ich früher mit pinnacle studio (damals sogar v7/8 ;)) gemacht habe: Schneiden, Titel, Voiceover/Musik, Übergänge/blenden, simple Effekte ... Rendern und als DV-AVI (CDVC, WAV) exportieren. Gefällt mir sehr gut und läuft extrem stabil/problemlos. Vielleicht werde ich mir die abgespeckte Version (Neo 3.5) kaufen; v6 oder 6,5 sind immer noch sehr teuer.
Grauschleier entfernen/Farbkorrektur --> YUY-Kurve bearbeiten hab ich mir auch angesehen ... aber stimmt, da muss man doch schon wissen was man tut. vl kannst du mir dein profil, diese einstellungen oder ein bild von der yuv-kurve schicken damit ich das auch so hinbekomme ... per PN ev?

danke für die links/info. bei 'alles' muss man schon den rest dazunehmen '... was ich früher mit pinnacle studio gemacht habe.' ;D also alles, was ich als amateur brauche/kann. hab schon gesehen, dass es da zig-verschiedene einstellungen für alles mögliche gibt - ist ja doch eine professionelle software. danke, da kann ich mich ja mal bei gelegenheit einlesen herumprobieren.

Eine letzte Frage noch bezüglich sinnvoller x264 Bitrate. Habe jetzt das vorherige Sample rudimentär in Edius bearbeitet, als DV-Avi ausgegeben und mit QTGMC Fast nach x264 umgewandelt. (die YUV-Kurve gehört zwar noch angepasst, aber ich habe den Eindruck dass egal welche Punkte ich verändere das Ergebnis nur schlechter aussieht - hab noch keine Händchen dafür ... und auch keinen gut kalibrierten Montior zwecks Farbanpassung, nur einen alten LCD der über HDMI am PC hängt und auf dem sieht's ok aus - zumindest besser wie vorher mit Grauschleier) Einmal mit

x264 ~24Mbps BPP 2.315 Download-Link
x264 ~10Mbps BPP 1.000 Download-Link

Original-DV: 24,4Mbps (Encoded 28,8Mbps) BPP 2.357 - die 24Mbps-Variante wird fast gleich groß.
Seht ihr da qualitativ irgendeinen Unterschied zwischen den 2 Versionen? Prinzipiell ist es mir zwar egal, ob die fertige Datei 5 oder 11 GB hat, da es auf BD-R oder externer USB-HD landet, aber unnötig hohe Bitraten zu verwenden ohne Qualitätsgewinn wäre ja auch etwas sinnlos ... ist nicht 24Mbps bei SD-Auflösung 720x576 anamorph AR 16/9 overkill? Den einzigen Unterschied, den ich zwischen den 2 Dateien sehe ist am ehesten noch am Rad von dem Dreiradler, das bei der 10Mbps-Variante ev. etwas schlechter aussieht. Früher bei MPEG-2 DVD-Ausgabe war ja auch bei 8Mbps Schluss ...

okay, gerade ausprobiert: von mkv nach ts gepackt und unter Edius mit dem Layouter mal links dann rechts abgespielt (frame by frame) ... ich seh absolut 0 unterschied. zuvor habe ich beide dateien side-by-side mit mpc-hc abgespielt und frame by frame unter avisynth-script-creator mit megui verglichen. in zukunft stelle ich die bitrate so ein, dass ich auf BPP 1.0 komme ~ 10Mbps, alles höhere ist bei dieser Quelle anscheinend umsonst. em ende will ich doch wegen meiner leicht veränderten x264 settings und QTGMC mit avisynth/megui umwandeln, also von bearbeiteter AVI(DV/WAV) nach MKV(x264/aac).

vorerst mal danke für die großartige hilfe :daumen:
also irgendwie musste ich die 2 mkv-dateien mit tsmuxer nach AVCHD-Disc exportieren --> in m2ts packen; mit dem ts-container ist Edius 6 immer gecrashed bei mir. (egal mit welchem Renderformat)

... fast genau so wie du das beschrieben hast habe ich eigentlich die dateien unter edius verglichen (das war gemeint mit 'mit dem Layouter mal links dann rechts abgespielt (frame by frame)') - der einzige unterschied war, dass den Layouter bei der einen Datei nach links und bei der anderen nach rechts verschoben habe - statt zugeschnitten. ist aber im prinzip genau dasselbe. was ich allerdings nicht verstehe ist, warum ich eine progressive datei interlaced vergleichen soll. hat das irgendwelche vorteile? Ich habs jetzt auf jeden fall mal progressiv verglichen - und zwar so:

Neues Projekt mit Videovoreinstellung SD PAL 720x576 25p 16:9; Renderformat MPEG2-Program-Stream (auf progressiv umgestellt); V-Spuren 2, alles andere 0. Dann beim hinzufügen der Clips über Bin-->Eigenschaften beide auf progressiv umgestellt; die 24Mbps-Version in 1V gelegt, 10Mbps-Variante in 2V gelegt (übereinander, framegenau). im layouter beide auf 50,25% zugeschnitten, Links die 24Mbps Datei, Rechts die 10Mbps Datei: Screenshot ... auch so verglichen sehe ich qualitativ keinen unterschied.

Zitat von Goldwingfahrer

... Möchtest Du -nur- den Unterschied beider Streams sehen....dann gehe so vor
Das einfachste wäre, wenn Du die zwei in Frage stehenden Versionen in Edius auf die TL als Clips holst, die Clips in zwei Spuren übereinander legst und mittels Keyer > Mischen > Differenz im Vectorscope vergleichst.
Dann solltest Du sehen, ob und wenn ja wie stark der Unterschied ist.

soll dazu der layouter wieder 'unbeschnitten'/auf standard bleiben und soll der differenz-mixer auf beide spuren angewendet werden oder nur auf die mit höherer/niedriegerer bitrate?
Um das dann vergleichen zu können müsste man nur mehr wissen, wie man das Vectorscope/Wellenform interpretiert ... werd mich da etwas einlesen (zb hier)

Okay, also wenn ich wie beschrieben mit Keyer > Mischen > Differenz beide Dateien im Vectorscope vergleiche, bleibt es durchgehend so wie auf dem nachfolgendem Bild. Das dürfte dann heissen, dass da qualitätsmäßig zwischen den 2 Varianten nicht viel Unterschied ist (ich seh ja auch keinen). --> BPP 1.0 ~ 10Mbps reicht also definitiv. Bei den Farben habe ich gemerkt, dass da doch noch ein paar Szenen angepasst gehören (manche bei ca. bei IRE +110 statt +100 liegen). Danke für die hilfreichen Links, werde noch verschiedene Anpassungen vornehmen und dann neu encodieren.

Wir sind zwar jetzt etwas vom Thema abgekommen - mit dem Crash hat der halbe Thread nichts mehr zu tun - aber jetzt weiss ich, wie sich die gesamte Umwandlung und Bearbeitung von DV nach X264 (für mich) am besten bewerktstelligen lässt.

Fazit zum Abschluss

zum Videoschnitt mit Edius:
Die Aufnahme/Szenenerkennung/Dateitrennung von der Kamera über Firewire nach DV(cdvc) funktioniert problemlos wenn die Zeit auf der Kamera und dadurch auf dem DV-Band eingestellt ist. Beim Herausnehmen des Akkus von der Sony DCR-TRV11e wird leider immer die Zeiteinstellung und auch die Formatumstellung auf 16:9 anamorph bei 720x576i gelöscht, weswegen jetzt der Akku immer in der Kamera bleibt. Durch die angepasste YUV-Kurve wird u.a. der Grauschleier entfernt, danach werden die Farben mit Farbabgleich sichere Farbe beschränkt (Wellenform: IRE 0-100) und mit der 3-Wege-Farbkorrektur + Vektorskop ev. angepasst, wenn sie über die Grenze hinausgehen. Nach dieser Bearbeitung ist der Unterschied zum Original wirklich gewaltig - großes Dankeschön noch einmal!

Für die Zukunft haben wir uns jetzt doch einen mittelmäßigen Full-HD Handycam-Camcorder (Sony HDR-CX330e) der digital auf eine sehr schnelle 64GB-microSDXC-Karte aufzeichnet geleistet. Da dieser maximal mit 1920x1080 MPEG2-PS 28Mbps AVCHD-progressive aufnehmen kann, wird in Zukunft nur mehr bearbeitet/geschnitten, nach entweder MPEG2-PS/aac oder x264 bzw. h264/aac augegeben und im mp4 oder mkv container auf Daten-BluRay gebrannt. Mit der maximalen Einstellung passen ca. 6 Stunden auf die SD-Karte, mit der minimalen 26 Stunden, Deinterlacing fällt weg. Im Verlgeich zur guten, alten DV-Kamera wirkt das Ding zwar wie ein schlecht verarbeitetes Pastik-Spielzeug, die Aufnahmen sind aber natürlich viel besser. Die HDR-CX900e wäre zwar qualitativ auf dem Niveau gewesen, wie vor 13 Jahren unsere alte, war uns aber dann doch zu teuer für Gelegenheitsaufnahmen. Die DV-Kamera wird aber auch weiterhin verwendet, denn bei guten Lichtverhältnissen ist selbst die analoge SD-Qualität immer noch sehr gut, NightShot Aufnahmen sind auch was feines, sollten wir sie jemals brauchen ...

bezüglich Crash:
Selur: Danke noch einmal vielmals für das externe Script. An der Verwendung der 'internen'-dlls mit QTGMC-MT liegt anscheinend bei meinem 32bit-Win7-Rechner der Hund begraben ... falls jemand mal ein ähnlich kurioses Problem auf einem alten 32bit-Rechner haben sollte, müssen anscheinend die dlls extern geladen werden, damit es funktioniert.

Ausgangssituation:
Alle dlls von der avisynth extension. Bei beiden Varianten (intern/extern) ist nur die veränderte avisynth.dll im system32 ordner. Interessanterweise müssen fftw3.dll und libfftw3f-3.dll NICHT im system32 Ordner sein - die dürften wahrscheinlich über die größere avisynth.dll geladen werden (da die zughörige svhost.exe so lange arbeitsspeicher frisst, bis das ganze geladen wird). Bei der 'internen' Variante sind alle notwendigen dlls im avisynth-plugin-ordner (ohne loaddll/fftw3/libfftw3f-3), bei der externen die selben + diese 3 in einem eigenen ordner.

So, jetzt habe ich gerade eine anderes DV-Video (~ 40min) einmal mit der internen- und externen Variante probiert umzuwandeln/zu deinterlacen. Die interne ist wieder beim 1st pass mit avisynth.dll fehler gecrasht, die externe lief ohne Probleme durch (1st und 2nd pass). Bei einem kürzerem DV-Video (~ 5min) hat die interne Variante auch funktioniert ... anscheinend gibts da unter 32bit-Win7 irgendwelche Speicher/DLL-Probleme bei längeren oder größeren Dateien ... es kann also wirklich nur daran gelegen haben oder ev an irgendeinem Konflikt mit meiner(m) Hardware/Treiber/Windows. Bei meinem 64bit Win7 Rechner habe ich, wahrscheinlich wegen vor allem dem größeren Arbeitsspeicher, noch nie derartige Probleme gehabt.