ich habe ein problem bezüglich mit final cut gecapturtem dv-material:
zum zweck der nachbearbeitung wollte ich gerne mit dv aufgenommenes super8 filmmaterial in virtualdub mit dem antiflicker-plugin nachbearbeiten (um das flackern zu entfernen). final cut speichert bei mir das gecapturte material ohne dateiendung (in den eigenschaften steht quicktime). leider kann ich dieses nicht in virtualdub öffnen, ich dachte das sollte mit dem panasonic dv-codec für vfw möglich sein, da man hiermit laut beschreibung dv-dateien in virtual dub öffnen kann. die fehlermeldung lautet: format not supported.
ich vermute es liegt am quicktime dv codec und das virtualdub nicht damit umgehen kann.
vielleicht hat jemand erfahrungen bzgl. dieses themas, ich würde mich über hinweise sehr freuen!
1.
an das final-cut-pro file einfach die endung .dv oder .mov hängen, eventuell erkennt virtual dub das file dann korrekt.
2. sollte 1. nicht funktionieren, öffne das final-cut-file in quicktime per drag&drop und exportier es als avi. dieses sollte dann geöffnet werden können. allerdings hast du damit eine generation verloren - die qualität wird also nicht unbedingt besser.
1. wenn ich eine endung dranhänge, ist virtualdub trotzdem nicht in der lage, die datei zu öffnen. es ändert nichts an der fehlermeldung.
2. ich wollte generationsverluste natürlich möglichst umgehen, aber wäre eine idee. könnte man das resultierende avi problemlos wieder in final cut importieren oder muss ich dazu wieder zurückkonvertieren (in quicktime)?
eine andere frage: ein filter zum entfernen des projektionsflackern für final cut wäre auch eine lösung. ich weiss, das magic bullet das kann, ist halt etwas teuer für non-professionals. kennt jemand ein freeware plugin, das dazu in der lage ist?
also final cut, (wie quicktime) kann avis lesen, die mit einem dv-codec erstellt wurden.
es gibt natürlich viele plugins, die extra ein super-8 flickern erzeugen, wenn man einen super8-look haben möchte (den ich übrigens sehr schick finde), aber der umgekehrte weg ist viel schwieriger.
es kommt ein wenig darauf an, wie lang dein material ist.
wen es sich um einen 30 sekünder handelt, würde ich ernsthaft in betracht ziehen, die frames die für das flackern hausptsächlich veranwortlich sind, zu löschen und ggf. einen anderen frame hier einzusetzen, oder die gelöschten frames ganz weglassen.
ansonsten fällt mir da derzeit nichts ein, solange ich nicht das material gesehen habe. kannst du eine preview irgendwo ablegen ?
es handelt sich um relativ viel material (1-1,5h) in dutzenden kleinen clips für die einbindung in eine längere doku. leider wurde beim abfilmen nicht viel wert auf richtige geschwindigkeitseinstellung am projektor etc. genommen, so dass das flackern schon mitunter recht störend ist.
danke für das preview angebot, leider habe ich momentan keine möglichkeit zum hochladen.
ich werde bei einem bekannten mal die magic bullet-variante ausprobieren, kann dann ja mal berichten, ob das funktioniert hat.
nach erfolglosem versuch mit magic bullet (kann den flickereffekt nur künstlich erzeugen, nicht reduzieren) hab ich es nochmal mit virtualdub probiert.
das hat dann auch funktioniert mit folgendem trick:
1. die finalcut dateien umbenennen in .mov dateien (bei mehreren z.b. mit "a.f.5 rename your files")
2. avisynth 2.5x installieren
3. textdatei erzeugen mit editor, folgenden eintrag machen (mit angabe der zu öffnenden datei):
directshowsource("g:\super8\xxx.mov")
4. textdatei als avisynth-skript speichern mit der endung .avs (z.b. test.avs)
5. virtualdub öffnen
6. .avs datei in virtualdub öffnen
das dient dem zweck, die quicktime dv datei nicht direkt in virtualdub zu öffnen (was nach wie vor mit der fehlermeldung quittiert wird), sondern sie per avisynth und direct show an virtualdub weiterzureichen. ansonsten kann natürlich das skript noch um bearbeitungsfunktionen erweitert werden --> siehe avisynth.
eine frage noch: kann durch das öffnen per directshowsurce die qualität des videomaterials leiden?
eine frage noch: kann durch das öffnen per directshowsurce die qualität des videomaterials leiden?
Jein ;-) Es kommt darauf an, was du unter Leiden definierst.
Die Fakten sind...
wenn in VD irgendeine Bearbeitung im Full Processing Modus gemacht wird, wird diese im RGB Farbraum gemacht. Das DV Quellmaterial und das Zielmaterial ist aber Material aus dem YUV Farbraum.
Beide Farbräume umfassen eine andere Menge an Farben, so dass es bei "exotischen" Farben, die z.B. durch nachgeschaltete Filter produziert werden, durch die zweifache Konvertierung zu Verlusten kommen kann.
Weiterhin müssen bei "normalen" Farben genaue und resersible Umwandlungsvorschriften benutzt werden. Die Rechengenauigkeit und die Rechengeschwindigkeit auf Computern ist eine begrenzte Resource, d.h. es hängt vom Können und Wollen des Programmschreibers ab, wie genau ein Programm das macht. Ich habe grosses Vertrauen in Avery Lee ;-)
Die Umwandlung vom Farbraum gilt im Prinzip auch für Avisynth. Wobei in Avisynth manche Filter im YUV Farbraum bleiben und so die Umwandlungen nach/von RGB entfallen können.
Desweiteren hängt es vom verwendeten DV Decoder ab, wie ein DV komprimiertes Einzelbild in ein unkomprimiertes, bearbeitbares Bild entpackt wird. In Avisynth kann man dies beeinflussen bzw. korrigieren. Scharfi hat sehr interessante Ausführungen dazu in seinem Blog http://md2.boerde.de/scharfi/?p=2
mir ging es primär um die bearbeitung des super8 materials, also 100% farbtreue ist mir nicht so wichtig, da echte farbtreue nicht mehr vorhanden ist.
ich benutze den cedocida dv codec, der optionen für die farbraumkonvertierung bietet.
meine frage zielte mehr auf block-artefakte ab durch evtl. transcodierung beim öffnen.
oder anders: kann ich das quicktime dv gecapturte material per avisynth weitergeben ohne das der bildinhalt neu codiert werden muss? dass ich im full processing mode verluste habe, erscheint mir logisch, aber sollte das video im "display input video"nicht genauso aussehen wie in final cut (bis auf die farben evtl., wie du beschrieben hast)?
das scheint mir nicht so zu sein, oder handelt es sich nur um ein darstellungsproblem (von mac zu windows, anderer monitor, auflösung etc.), ich habe den eindruck, das grössere block-artefakte im bild erscheinen.
der antiflickerfilter arbeitet nur mit yuy2, also muss ich vorher umkonvertieren.
so sieht mein momentanes skript aus, vielleicht hast du eine anregung:
No panic! Soweit, dass man Farbunterschiede deutlich sieht, darf die schlechteste eine YUV nach RGB Konvertierung nicht kommen ;-)
Ansonsten hilft es, genau zu unterscheiden, wer was macht. Und 1-2 typische Beispielstandbilder (vorher/nachher) zur Fehlersuche sind auch nicht verkehrt (ggf. bei www.imageshack.us ablegen).
Avisynth ist bei dir a) ein Vermittler zwischen den DirectShow Filtern (MOV einlesen und DV dekodieren) und VirtualDub (DV komprimieren und AVI speichern) und b) fürs Antiflicker zuständig.
Avisynth bearbeitet in diesem Sinn nur unkomprimiertes Material, d.h. Blöcke hättest du dir vorher eingeschleppt (DirectShow) oder nachher produziert (DV Codec in VD).
Den Unterschied zu sehen, ist problematisch. Du könntest eine Testserie fahren z.B. in VD mit einem anderen guten Codec speichern (Huffyuv, MJPEG) und nachsehen, ob Blöcke drin sind bzw. ohne zu speichern in VD betrachten.
Wenn dann auch Blöcke vorhanden sind, stammen die wahrscheinlicher aus dem DV Dekodieren durch DirectShow. Aber genau das ist wiederum unwahrscheinlich. Der DV Standard soll nach Hörensagen das Entpacken soweit standardisiert haben, dass alle DV Decoder exakt gleich arbeiten.
Wenn die Blöcke weg sind, wurden die vorher wahrscheinlicher bei DV Encodieren durch den DV Codec in VD reingeschleppt. In diesem Fall kannst du probieren hier einen anderen DV Codec (Panasonic, Matrox, Mainconcept) einzusetzen, wenn du bei DV bleiben willst. Hilfreich ist dabei das Tool VCSwap zum Austauschen (Swappen) des zu verwendenden Videocodecs.
Das Austauschen des Directshow DV Codecs geht - im Prinzip - auch. Nur hast du da keine so grosse Auswahl. Mir fällt da nur der Mainconcept DV Codec als Alternative zum Micro$oft DV Codec ein. Hilfreich ist dabei das Tool GSPOT zum Anzeigen des vom DirectShow-System verwendenden Videocodecs. Dazu Anzeigen lassen wie eine DV AVI Datei abgespielt würde...
Eine Sache kann dich allerdings foppen und das ist reine Spekulation, weil ich seltenst mit DV MOV Dateien "Umgang habe":
Wenn DirectShow das Einlesen der MOV Dateien und das Entpacken an Quicktime und dessen abartigen DV Codec abgibt. Dann bist du auf den Quicktime DV Codec angewiesen. Ich weiss nicht ob man den tauschen kann. No Panic! In diesem Fall würdest beim Betrachten der MOV Quelldateien in QT schon Blöcke sehen.
Zu dem Rest des Skripts...
Du machst die ganze Antiflicker-Geschichte in Avisynth. Eigentlich brauchtst du VD nur noch zum komprimieren und zum speichern.
Nur deswegen musst du nicht in den Full Processing Modus gehen sondern kannst einen der beiden Modi wählen (Fast Recompress?), wenn der DV Codec da mitmacht. Entsprechend brauchst du das converttorgb() am Ende des Skripts nicht.
Oder du verzichtest - je nach weiterem Processing - ganz auf VD und machst von Avisynth aus direkt ein Frameserving in die nächste Anwendung hinter VD z.B. den MPEG Encoder für die DVD Produktion.
Die Parameter in den Entrausch-Funktionen habe ich mir nicht angesehen (zuviel Aufwand und abhängig vom Quellmaterial).
Bei DV Codecs kenne ich den Begriff nicht. Bei VirtualDub (VD) hängt es mit dem Farbraum zusammen.
Man kann - grob gesagt - die einzelnen Punkte in einem Bild aus drei Grundfarben ggf. plus einem Alphakanal zusammenmixen (RGB Farbräume) oder aus einer Helligkeit und zwei Farbinformationen (YUV Farbräume).
Diese beiden Arten von Farbraum können jeweils noch mal unterteilt werden.
Eine Unterteilung bei RGB geht z.B. über die Anzahl der Bits/Grundfarbe (8,16,...).
Eine andere Unterteilung bei YUV geht z.B. über das Farbsampling (Pixel teilen sich Farbinformationen mit Nachbarn, 4:4:4, 4:2:2, 4:2:0,...) und/oder über die Ablage der Daten im Speicher (alternierend YUV oder planar erst alle Y (Helligkeit) dann alle U bzw. V (Farbdifferenz)).
Lange Rede kurzer Sinn:
Es gibt einen Haufen Farbräume, die als Eingabe/Ausgabe für einen Codec in Frage kommen.
Bei einem DV Codec ist das Ziel bei PAL ein DV komprimiertes YUV 4:2:0.
Im "einfachsten" Fall erwartet der Codec auch eine solche Eingabe, weil dann keine weiteren Umrechungen erforderlich sind.
Bei "komfortableren" Codecs, frisst der Encoderteil auch Bilder aus anderen Farbräumen, die dann umgerechnet werden. Und der Decoderteil kann auch andere Bilder an aufrufende Programme liefern.
Die Programme und Codecs einigen sich normalerweise untereinander, so dass man als Anwender davon nicht viel sieht. Ausser wenn es mal nicht klappt und eine Fehlermeldung kommt. "RGB Programm kann nicht mit YUV Dekoder..."
Aber es gibt Programme (z.B. VirtualDub) und Codecs (z.B. Huffyuv), wo man als Anwender einstellen kann, welche Einigungen bevorzugt werden sollen. Manchmal versteckt sich das unter einem Punkt z.B. "Force RGB Output..."
In so einen Fall fällt auch das Fast Recompress bei VD. Wenn man weiss, dass YUV Material in YUV Material umkomprimiert werden soll, dann kann man versuchen, gezielt die YUV Eingangsroutinen des Codecs anzusprechen.
danke erstmal für die umfassenden infos, vcswap ist sehr hilfreich zum testen des exportierten files.
ich habe mal 2 bilder zum vergleichen auf imageshack hochgeladen, das erste ist direkt aus fcp exportiert, das zweite ist das selbe bild als vd-standbild der directshowsource-datei (ohne weitere filter, konvertierungen etc.). zu beachten ist auch, das trotz gleicher einstellungen (jpeg mit höchster qualität) das vd bild wesentlich kleiner ist.
allerdings sieht man in dem fcp bild wohl auch nur ein halbbild, während im vd bild ein vollbild zu sehen ist? vielleicht ein problem beim decodieren durch deinterlacing?
ich denke man kann schon einen qualitätsverlust erkennen, abgesehen von den farben. das lässt dann darauf schliesen, das wirklich das öffnen mit dem dv codec die qualität vermindert.
das dv sowit standardisiert ist, das ein und dieselbe datei mit unterschiedlichen codecs geöffnet eine gleiche bildqualität liefert (ohne blöcke), dachte ich auch.
das originalbild in quicktime betrachtet sieht nun aber auch dem vd ergebniss sehr ähnlich (bild exportieren ging nicht).
kann ich den dv codec für den import in vd irgendwie beeinflussen? ich bin verwirrt, da ich nicht weiss, welchen codec er nun benutzt. directshowsource = m$ codec oder doch quicktime bei mov?
An den Beispielbildern sieht man, dass was mit der Farbtiefe nicht stimmt. Besonders gut hinter der Frau mit Kanne zu sehen: Posterisierung (statt Grauverlauf) an der grauen Wand. Die bessere JPEG Kompression ist damit erklärbar.
Welches der x Programme/Umwandlungen zwischen FCP und VD dafür verantwortlich ist???
Ich kann es nicht nachvollziehen, weil ich schon Probleme habe, DV MOVs in Avisynth reinzubekommen. Normale MOVs gehen, aber welche mit DV-PAL Kompression nicht. Du hast sicher DV-PAL Kompression in deinen Videos (QT->Film->Filmeigenschaften einblenden->Videospur->Format)?
Mein Vorschlag: gehe nochmal einen Schritt (ok, mehrere) zurück und lasse den ganzen QT/Avisynth Abschnitt weg.
http://www.neowin.net/forum/lofiversion/index.php/t345220.html hat geschrieben:...use final cut to make a DV-AVI file. Select EXPORT WITH QUICKTIME COMPRESSION. Where you can select format, (it will most likely say QuickTime) open the menu, and select AVI. In the advanced properties, you can now select DV-AVI. - Windows will understand this.
Damit hättest du ein DV AVI durch FCP erzeugt. Das bearbeite direkt in VD.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
