Beiträge von truthy

Danke. Dann bin ich ja doch nicht so falsch gelegen, denn ich habe bisher immer QTGMC verwendet, sobald ich in irgendeiner Quelle horizontale Linien entdeckt habe ...
Interlaced encodieren und zb einen modernen SmartTV (und keinen BluRayPlayer) deinterlacen & skalieren lassen fällt für mich weg. Srestore ist mir glaube ich doch zu aufwendig.

zu SelectEven() bzw. 50fps
Videos, wie dieses, mit SD-Auflösung und 50fps werden problemlos auf einem BluRayPlayer abgespielt. Leider sieht es bei 1080p Videos mit 50fps anders aus. Da muss ich zb unsere sehr guten 1080p50 AVCHD Progressive Aufnahmen wieder nach 25p umwandeln (unter Edius mit 'nächstes Bild' statt 'Bildvermischung' --> schärfer) da so gut wie kein Standalone Player das abpielen kann (mein SmartTV allerdings schon). Dadurch verliere ich zwar die Hälfte aller Bilder, aber mir ist es immer noch 'flüssig' genug. Aus 50p wieder 50i machen damit es kompatibel wird will ich nicht, denn dann sieht es am SmartTV wieder nicht so gut aus.

Unter EDIUS habe ich mit New Blue Noise Reducer + Edge Smoother bzw. Selective Touch Up auch ein ganz gutes Ergebnis erzielt - das von QTGMC bzw. dfttest gefällt mir aber noch besser.

Ich werde also für Sample 2 Methode eins verwenden: QTGMC ohne SelectEven (50fps), Für Sample 3 dasselbe + noch etwas nachschärfen. Für Sample 1 will ich zwar nur dfttest ohne QTGMC anwenden. Leider weiss ich nicht, wie man folgende denoise settings von QTGMC auf dfttest 'übersetzt', also mache ich inzwischen einen zweckentfremdeten QTGMC progressive encode nur wegen dem noisefilter.

QTGMC( InputType=1, [B]Preset="Slower", EZDenoise=6, NoisePreset="Slower"[/B], EdiThreads=1 )

Update:
Also bei DVD-2&3 ohne SelectEven()/mit 50fps statt 25fps läuft irgendwas falsch. Hab euch per PM einen Vergleich mit und ohne SelectEven() geschickt - beide mit demselben QTGMC-Settings:

global MeGUI_darx = 4
global MeGUI_dary = 3
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
SetMTMode(3, 8)
DGDecode_mpeg2source("E:\...\VTS_01_1.d2v")
SetMemoryMax(768)
SetMTMode(2)
QTGMC( Preset="Slower", EZDenoise=0, NoisePreset="Slower", EdiThreads=1 ) 
SelectEven()
#bzw. #SelectEven() --> 50fps
LanczosResize(720,544) # Lanczos (Sharp)

Ich weiss schon warum ich das drinnen gelassen habe ... mir sind sowieso Framerates von 23.976-30.000 lieber, weils damit keine Probleme gibt - ne Idee warum das mit 50fps so stockt?
Das Encoding von der 1. DVD mit dem langsameren Noise-Preset sieht jetzt noch ein kleines Stück besser aus als vorher - das gröbste Bildrauschen ist weg, große gleichfarbige Flächen sind weicher und es ist trotztdem noch scharf geblieben. Vergleichsbilder: Link

Jedes Sample ist von einem anderen Film - einer anderen DVD. Die Vergleichbilder sind nur von der Ersten. Womit würde man jetzt Sample 2 & 3 deinterlacen? Mit FieldDeinterlace oder TIVTC? Das Erste scheint mir zumindest eh schon progressiv zu sein, obwohl die info interlaced anzeigt ... ich seh auf jeden fall keine linien mehr nur starkes Bildrauschen.

Okay, hab euch DL-Links/PW von drei 1min Samples von der Quelle per PM geschickt. (als mpg statt vob - ist aber nur gemuxt, gesplittet und demuxt worden)
Für mich ist das 1. eigentlich progressiv, die anderen 2 auch nur teilweise interlaced ...

Also bisher finde ich die Zweckentfremdung von QTGMC als Rauschfilter noch am Schönsten ... könnt ihr mir sagen, wie das zb aussehen müsste, wenn ich nur dfttest verweden will?
Anhand von diesen Einstellungen QTGMC( InputType=1, Preset="Slower", EZDenoise=6, NoisePreset="Slower", EdiThreads=1 )

Ich werde auch noch was komplett anderes probieren: Das 1. Video mit vdub nach Canopus Lossless speichern und mir mal das Ergebnis vom NewBlue Noise Reducer/Selective Touch Up o.ä. unter Edius ansehen. Dann könnte ich auch eine manuelle Szenentrennung durchführen und die Filter nur bei den Teilen verwenden, die sehr starkes Bildrauschen aufweisen. Nach der Bearbeitung wieder Lossless exportieren und mit x264 umwandeln.

Danke für die Erklärungen/Tipps. Ich habe QTGMC bisher nur für alte 'normalfilm' Quellen verwendet und auch wirklich zum deinterlacen - nie für Zeichentrick/Comic/Animation. Auf dem link von videohelp wird von jemandem zwar behauptet, dass, wenn man QTGMC im progresiven modus und nur wegen dem Schärfe/Rauschfilter verwendet, das Bild 'stabiler' wird also vorher ... aber davon merke ich eher nichts. Mit dfttest (wird bei Slower verwendet: noise-presets) & QTGMC ist es jetzt fertig. Jetzt mach ich noch einen Vergleich nur mit FFT3DFilter/dfttest/MSmooth/RemoveGrainHD. Habe hier noch ein paar sehr gute Erklärungen zu 'Spatial Smoothers' gefunden: link

Was ich auch intererresant finde, ist, dass ab und zu nach einem x264 (re)encode von mir der Ton leicht asynchron wird ... beim jetzigen file zb um +300ms. Original ac3 delay der dvd war 6ms. Trotzdem fällt es mir schwer zu erkennen, welchen Deinterlacer ich verwenden soll, wenn die Quelle nur teilweise interlaced ist. Eigentlich kommen für meine Quellen aus bisheriger Erfahrung nur 3 in Frage: FieldDeinterlace, TIVTC und QTGMC (statt früher yadif). Aber prinzipiell alles mit QTGMC deinterlacen ist ja anscheinend auch nicht das Gelbe vom Ei. 99% von allem meinen Encodings sind mittlerweile progressiv. Wäre es Ok wenn ich von den jetzigen 3 Quellen jeweils ein 30s Sample ohne Ton wo hochlade, damit Ihr mir sagen könnt, wie Ihr das deinterlacen würdet? Oder besser nur einen Link per PM?

EDIT:
Also MSmooth finde ich absolut schrecklich - egal wie ich theshold/strength einstelle mit/ohne Maskenvorschau. Entweder es wird alles zur komplett verschwommen und alle Details gehen verloren oder mehr als die hälfte an Bildrauschen bleibt bestehen.
RemoveGrainHD ist zwar besser aber die Details gehen auch verloren - ist ja auch für sehr feines Bildrauschen gedacht, Mode 17 hat noch am besten ausgesehen.

kA wie ich darauf gekommen bin, dass die Quelle interlaced war ... lt. mediainfo & in megui hatt er mir yadif vorgeschlagen, habs gerade nochmal probiert und ist eigentlich doch progressiv ...
Da hab ich doch einen ordentlichen Bödsinn gemacht, weil ich mir auch noch gedacht habe ohne SelectEven wird 25fps zu 50fps und dann ist es nicht mehr standalone kompatibel ... aber die Framerate wird ja nur beim Deinterlacing verdoppelt. Im progressiven modus kann ich mir das sparen. Aber es ging mir ja in erster Linie um EZDenoise und man kann ja QTGMC damit auch im progressiven Modus laufen lassen. link
Man lernt nie aus - danke ... also gleich nochmal und dieses mal richtig:

global MeGUI_darx = 4
global MeGUI_dary = 3
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
SetMTMode(3, 8)
DGDecode_mpeg2source("E:\VTS_01_1.d2v", info=3)
SetMemoryMax(768)
SetMTMode(2)
QTGMC( InputType=1, Preset="Slower", EZDenoise=6, EdiThreads=1 ) 
LanczosResize(720,544) # Lanczos (Sharp)

Edit: Ok es war wirklich nur der erste progressiv. Die anderen sind wirklich zumindest teilweise interlaced ... deswegen bin ich darauf gekommen.

Mhm, also die DVD-Quelle war schon interlaced - top field first - man hat auch noch ursprünglich horizontale Linien im Bild gesehen. Die Vergleichsbilder waren aber vor allem auf den Denoiser bezogen (nicht aufs Deinterlacing) - sind von der Preview unter MeGui bei genau demselben Frame.

Sry, dass ich den Thread wieder aus der Versenkung hole, hab aber ein kleines Update:

Ich habe gerade wieder mal QTGMC gebraucht und bin nicht nur vom Deinterlacing, sondern auch von den NoiseRemoval & Sharpen-Effekten absolut begeistert. Der Vergleich ist von einer ORIGINAL Kauf-DVD. Das Quellmaterial ist von 1988 und wurde leider nie digital remastered (wie mittlerweile bereits sehr viele andere). Ich finde mein Reencode mit QTGMC + EZ-Denoise sieht 10x besser aus als das Original. Da zu viel 'blur' ja auch nicht gut ist, ist das ein guter Kompromiss und sieht auf einem 50'' LED-TV wirklich gut aus. (über BR-Player skaliert, da die meisten neuen TV-Scaler für SD-Material grauenhaft sind)

Resize von 720x576 auf 720x544 ohne croppen und NACH QTGMC Deinterlacing/Denoising:

global MeGUI_darx = 4global MeGUI_dary = 3LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")SetMTMode(3, 8)DGDecode_mpeg2source("E:\...\VTS_01_1.d2v", info=3)SetMemoryMax(768)SetMTMode(2)QTGMC( Preset="Slower", EZDenoise=6, EdiThreads=1 ) SelectEven()LanczosResize(720,544) # Lanczos (Sharp)

Encoding Settings:

program --level 4.1 --preset veryslow --tune animation --pass 2 --bitrate 4000 --stats ".stats" --keyint 25 --min-keyint 1 --bframes 3 --ref 6 --vbv-bufsize 30000 --vbv-maxrate 40000 --output "output" "input"

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.

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.

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

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

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.

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

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?

okay habs jetzt gerade nochmal per fernwartung auf dem anderen PC probiert - dieses mal lief QTGMC 1st-pass mit ffms2 und lmash ohne probleme durch. Mit avisource(ffdshow VFW dv-->libav) ist is wieder gecrashed. dieses mal in minute 57 - das letzte mal in minute 34 mit ffms2 ... mir scheint, dass der crash nichts mit der Quelle zu tun hat, da es jedes mal an einer anderen Stelle passiert.
Screen

Der Virtualdub Video Stream Error Scan zeigt kein einziges unlesbares Frame. Testweise habe ich jetzt mit Virtualdub directstreamcopy jeweils 1 min, ungefähr da, wo es gecrashed ist, herausgeschnitten. 1st & 2nd pass mit ffms2, lmash und avisource/ffdshow ohne Probleme. Alles am 'Crash-PC'. Memtest habe ich gemacht - Hardware ist sicher nicht defekt.

DV-Total Runtime: 1:02:29.520 --> 93738 frames MediaInfo
Sample: 0:55:33 bis 0:56:31 --> frame 83325 bis 84775 (auf 58s gekürzt damits unter 200mb bleibt; den Ton habe ich entfernt ...)
Download-Link

dann hab ichs noch mit cuts in der avs-datei an genau denselben stellen probiert (das 1. ist die 34min): funktioniert wieder problemlos (ffms2/lmash/avisource(ffdshow))

__film = last
__t0 = __film.trim(49500, 51000)
__t1 = __film.trim(83325, 84825)
__t0 ++ __t1

also kA - irgendwie lässt sich das nicht auf einfachem Weg nachstellen/reproduzieren ... wenn das encodieren am anderen pc im schnitt 4x so langsam geht und es dann auch noch irgendwann crashed und alles umsonst war ist das schon sehr lästig. vl liegen die crashes auch an etwas komplett anderem ...

Selur
könnte man das ganze auch unter Ubuntu machen? funktioniert QTGMC-MT/Avisynth 2.6 Äquivalent?
dein script kann ich irgendwie nur auf dem x64 pc aufmachen (beim Abspielen kommt Allg. Fehler in GDI+). beim x86 pc (mit richtigen pfaden etc.) bekomme ich die fehlermeldung:
unable to load load.dll error 0x7e
ms visual c++ redist 2005/2008/2010/2013 ist installiert - kA was da fehlt oder die falsche version ist ...

in ein paar wochen will ich 3,5h dv-material am langsamen pc encodieren - mal sehen wie weit ich komme.

okay, also mit meinem besseren PC funktioniert QTGMC einwandfrei (egal ob mit ffms oder lmash (letzeres war ca 1fps schneller) --> dlls/megui/avisynth alles gleich. einziger unterschied 64bit OS, Quadcore CPU mit HT und 8GB Ram --> SetMTMode(3, und x264 im 64bitmode. Das Quell-DV-Video hat 100%ig nichts - habe ich ja sogar am schlechteren PC bereits ohne QTGMC interlaced erfolgreich encodiert.

megui-cl
program --level 4.1 --bluray-compat --preset veryslow --tune grain --pass 2 --bitrate 24000 --stats ".stats" --keyint 25 --open-gop --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 40000 --sar 16:11 --output "output" "input"

Selur
danke, ich könnts sowieso mal mit Hybrid statt MeGui am schlechteren PC probieren ... vl geht's dann. irgendwie muss ich das dort zum laufen bringen, da zukünftige dv-quellen auch dort encodiert werden sollen bzw. müssen ... würde es was bringen den crash mit zb windbg zu analysieren?

Danke für eure Hilfe. Ich bin mittlerweile draufgekommen, dass die Ruckler am BR-Player nur durch eine zusätzliche tonspur und/oder einer bitrate höher als 24Mbps auftreten. vbv, verschiedene presets etc. ist eigentlich egal (solange die ref-frames nicht zu hoch sind). Lange Rede kurzer Sinn: ich verwende in Zukunft preset very slow, grain, level 4.1, bluray-compatibility, gop wegen schnellerem seeken + meine anderen quantizer werte für konstantere qualität und angepasste ref-frames (bei 1080p 4, bei SD-720p 6; bframes bleiben auf 3, vbv auf standard 30k/40k).

x264 --level 4.1 --bluray-compat --preset veryslow --tune grain --pass Y --bitrate XXX --keyint 24/25/30 --open-gop --ref 4/6 --slices 4 --qpmin 10 --qpmax 51 --vbv-bufsize 30000 --vbv-maxrate 40000

beide crashen erst nach einer weile - mit ffms2 nach ca. der hälfte, mit lmash noch etwas später ... ich probiere das ganze auf einem anderen pc, mal sehen ob sich das reproduzieren lässt. wenn es auch crashed werde ich wo ein 1min sample hochladen - ungefähr bei dem zeitindex wo es gecrashed hat. aufteilen müsste es sich eh mit virtualdub lassen ...