Naja, wenn Du bobbed output haben willst würdest Du ', FPSDivisor=2' weg lassen, dann passe es auch wieder mit den Bewegungen.
Dann habe ich aber 50 bps und doppelte Größe.
Ich habe auch 50 bps als Input für Shortcut genommen und das dort bzw. mittels ffmpeg wieder in 25 bps (x264 High Profile) ausgegeben. Die Ausgabeclips sind völlig identisch, d.h. auch so wird nur jeder zweite Frame ausgegeben.
QTGMC Bob deinterlacing?
c.QTGMC(Preset="Slower", InputType=0, FPSDivisor=2)
Mit der Parametrisierung habe ich mich noch nicht intensiv beschäftigt, gibt es bessere Einstellungen?
Und damit sollte die Entscheidung gefallen sein.
Ja, wenn progressiv, dann vorab mit QTGMC. Aber progressiv oder interlaced ist offen.
Bei schnellen Bewegungen erscheint interlaced besser zu sein.
Schwere Entscheidung.
Vollkommen unklar für mich warum unkomprimiert gespeichert wird. Verlustfreie Kompressionsverfahren sollten heutzutage kein Performance Problem bedeuten. (+ Container und Flags bzgl. Farbe&Co sind auch nicht schlecht)
OK, genauer gesagt habe ich die rohen Capture-Dateien im verlustfreien Codec Lagarith gespeichert / archiviert. Dann erfolgt die Bearbeitung mit Avisynth / Virtual Dub und Export in YUY2 und anschließender Import in Shotcut.
In einem Rutsch ist schwierig, ich benötige Funktionalität aus beiden Phasen.
Ich überlege noch, ob ich interlaced oder progressiv arbeite. Wenn ich mich für progressiv entscheide, dann ist die Qualität deutlich besser, wenn ich in Avisynth mit QTGMC deinterlace und dies nicht von Shotcut machen lasse.
Ich bearbeite meine (unkomprimierten) Capture-Videos zunächst mit Avisynth (denoise, crop, resize) und plane, sie danach mit Shotcut weiterzubearbeiten (schneiden, Übergänge, ...). Dann Export aus Shotcut mittels ffmpeg ins h264-Format (mp4 Container).
Danke, soweit läuft es jetzt:
out = oriA.QTGMC( Preset="Slower", InputType=0, FPSDivisor=2)
Aber ich würde direkt progressiv machen.
Und dann mit QTGMC? Habe ich bisher nicht zum Laufen gebracht, irgendwelche Funktionen fehlten immer. Und die reichhaltige Parametrisierung...
Gibt es eine aktuelle Aufstellung, welche Plugins in welcher Version benötigt werden? Und einen einfachen Aufruf, nur für Umwandlung in progressiv, ohne weitere Einstellungen?
Ich denke wegen der höheren Komplexität unterstützen viele Editoren nur progessiv.
Da Interlaced langsam stirbt und alle neuen Sachen Progressiv sind, würde ich auch aus pragmatischen Gründen mit QTGMC (oder einem anderen filter) daraus progressiv machen.
Die Open-Source-Editoren unterstützen auch interlaced (sowohl als Eingabe als auch als Ausgabe über ffmpeg), wandeln aber für bestimmte Effekte zunächst in progressiv um. Dann wieder für die Ausgabe in interlaced umwandeln halte ich nicht für sinnvoll.
Noch nicht geklärt habe ich die Frage, ob Teile ohne Filter 1:1 verarbeitet werden und nur die Abschnitte mit Filter 2-fach gewandelt werden,
Ich könnte eine Umwandlung in progressiv in der Vorverarbeitung mit Avisynth+ machen oder die Clips in den Editor interlaced importieren und die Umwandlung vom Editor mittels ffmpeg machen lassen - beim Export halt. Was wäre denn da vorzuziehen?
Man bekommt dadurch völlig neue Inhalte, die eine Kamera so nie aufgenommen hatte.
Ja, aber macht ein moderner Fernseher das nicht auch, bzw. am PC der Player?
Somit ist es doch kein Vorteil, im Interlaced-Format auszugeben.
Es wird hier immer dazu geraten, Quellmaterial, das interlaced ist, auch interlaced auszugeben. Warum eigentlich?
Hallo,
ich habe meine Hi8-Videos digitalisiert (Lagarith, unkomprimiert) und roh verarbeitet mit Avisynth.
Jetzt geht es um die Komprimierung bzw. Umwandlung in H.264 (mp4-Container).
Bestimmte Editoren wandeln die Eingabedateien in progressive um, zumindest dann, wenn Filter oder Effekte genutzt werden.
Ich habe Probleme mit der Qualität damit erzeugter interlaced mp4-Dateien .
Wenn eine Umwandlung in progressive erfolgt und dann wieder in interlaced, dann erscheint das nicht als sehr sinnvoll.
Die Qualität von progressive output ist gut.
Ist es dann nicht sinnvoller, progressive output zu erzeugen?
Was spricht für eine Rückumwandlung in interlaced?
Selbst wenn es so ist, dass nur die Ausschnitte mit Effekten zweifach transformiert werden, ist es dann sinnvoll?
Gibt es Videoeditoren, die mit interlaced umgehen können, d.h. ohne mehrfache Umwandlung wieder interlaced ausgeben?
Highwayman.
Ich habe eine sehr einfache Lösung gefunden.
Nach Erstbearbeitung meiner SD-Videos (4:3) suche ich ein Tool für die weitere Verarbeitung. Interessant ist Shotcut, auf ffmpeg basierend. Das bietet einen Filter Blur: Pad, der eigentlich genau das leistet.
Evtl. ist mir persönlich da noch zu viel Bewegung in den Rändern. Vielleicht kann man das Blur-Bild über eine ganze Szene einfrieren.
Mit den ffmpeg-Einstellungen kämpfe ich noch, muss wahrscheinlich H.264 und Generic PAR verwenden.
Highwayman
Hallo,
ich überlege derzeit, ob ich mein SD-Material im Format 4:3 nicht besser als 16:9 aufbereite, wobei das Bild 1:1 erhalten bleiben soll, nur die schwarzen Ränder durch "mehr" Farbe ersetzt werden sollen. Was ist grundsätzlich davon zu halten? Das 4:3-Format ist ja eigentlich schon tot.
Im TV sieht man jetzt oft solche Anpassungen, wobei die Ränder mit veränderten Kopien der Bildinhalte belegt werden.
Das ist in der Regel grottig, insbesondere bei Hochkant-Handyvideos, weil die Ränder vom eigentlichen Inhalt ablenken.
Mir schwebt dann eher eine Lösung vor mit ruhigen Rändern vor, die in Abhängigkeit vom aktuellen Frame gefärbt werden, irgendwie als Durchschnittsfarbwert der rechten bzw. linke Seite.
Gibt es sowas schon als Avisynth-Lösung?
Oder zumindest einen Ansatz?
Gruß
Highwayman
Oh, bei den Vergleichen mit subtract (zwischen ori und den jeweils aus einem Halbbild berechneten Clips) ist mir erneut aufgefallen, dass die Abweichungen bei odd größer sind als bei even.
Nun habe ich auch eine Erklärung.
Das Verfahren oben arbeitet nicht symmetrisch.
Bei even sind die oberen Halbbilder zeilenweise identisch.
Bei odd hingegen (hier müsste die interpolierte Zeile jeweils oberhalb eingefügt werden) findet eine Verschiebung statt, die Originalzeile matcht mit der interpolierten Zeile.
Wenn es bei TomsMoComp keinen entsprechenden Parameter gibt (den ersten teste ich noch), dann muss ich vielleicht mit FlipVertical arbeiten. Das funktioniert dann jedenfalls in der Theorie (und dann auch mit üblichen selectEvery(4,0,3).
Du möchtest also nicht die Variante verwenden, die ich empfohlen habe: QTGMC oder TDeint im Bob-Modus (der sollte bei QTGMC Standard sein)?
Doch, ich möchte nach und nach alle Varianten probieren. QTGMC habe ich erst einmal zurückgestellt, weil ich da die Avisynth-Version wechseln muss (die läuft auf einer anderen, Win 10-Partition). Mit TDeint hat es noch nicht so funktioniert, dass die Gegenprobe (Wiederherstellung ori) Identität zeigt.
OK, ich habe den Fehler gefunden.
even und odd werden von TomsMoComp natürlich nach dem gleichen Verfahren erstellt.
Unter einer (Original-) Zeile wird eine interpolierte Zeile eingefügt.
Die Originalzeilen erhalte ich also in beiden Fällen durch selectEven:
even2 = even.separatefields().selectEven()
odd2 = odd.separatefields().selectEven()
Mit q = interleave (even2, odd2).assumetff().weave() erhält man dann den Originalclip ori unverändert zurück.
Alternativ dazu geht auch:
q7 = interleave (even, odd).SeparateFields().SelectEvery(4,0,2).Weave()
q8 = interleave (even.SeparateFields(), odd.SeparateFields()).SelectEvery(4,0,1).Weave()
ori = q = q7 = q8
Idee ist also, eine Zerlegung in Halbbilder vorzunehmen.
Mein Material ist TFF:
ori = ori.AssumeTFF()
xTop = ori.separatefields().selectEven()
xBot = ori.separatefields().selectOdd()
TomsMoComp (0,-1,0) rechnet die Halbbilder hoch, aus sich selbst heraus durch interpolierte Zwischenzeilen, ohne Betrachtung anderer Frames:
even = xTop.TomsMoComp(0,-1,0).assumeframebased().assumeTFF()
odd = xBot.TomsMoComp(0,-1,0).assumeframebased().assumeTFF()
Die Einzelbetrachtung der Clips even und odd macht einen guten Eindruck.
Jetzt wollte ich zu Testzwecken daraus wieder den Urspungsclip ori berechen:
even2 = even.separatefields().selectEven()
odd2 = odd.separatefields().selectOdd()
q = interleave (even2, odd2).assumetff().weave()
oder
q4 = interleave (even, odd).SeparateFields().SelectEvery(4,0,3).weave()
Ableich mit subtract zeigt q=q4, aber keine Identität mit ori.
Es sieht so aus, als ob die Bilder vertikal verschoben sind, vielleicht um eine Zeile.
Die Auflösung in aus Halbbildern erzeugten Frames erreiche ich mit folgenden Varianten:
SeparateFields().Bob(0.0, 1.0)
TDeintBob(tff=True)
TMCBob(tff=True)
Bei meinem Testclip trat bei allen 3 Varianten das Phänomen auf, dass die Frames abwechselnd "brauchbar" und "unscharf" waren. Dann habe ich festgestellt, dass dies schon bei SeparateFields der Fall ist. Es sieht aber wohl so aus, dass das nur bei einem Clip der Fall ist.
Derzeit experimentiere ich mit TomsMoComp(0,-1,0).
Mir geht es nicht um ein Ersetzungsskript. Das habe ich bereits: ich hinterlege zu einem Frame aus einer Python-Anwendung heraus eine Zahl, die einen Alternativclip beschreibt. So ist z.B. 2 eine zweite Digitalisierung, 3 eine Bereinigung von Fischen, 4 eine Wiederherstellung aus dem oberen Halbbild etc.
Jetzt geht es um die Definition der Alternativen, also z.B. eine (optimale) Formel für einen Clip berechnet nur aus oberen Halbbildern.
Dort, wo ein Bild eine Störung im unteren Halbbild hat, wird der Frame durch den entsprechenden Frame im Alternativclip ersetzt (mit den bekannten Avisynth-Funktionen).
Hallo,
ich suche nach einer Avisynth-Funktion oder einem Skript oder einer Möglichkeit, fehlende oder defekte Halbbilder in Interlaced-Material (YUY2) durch ein interpoliertes Halbbild zu ersetzen.
Dabei sollte das andere vorhandene Halbbild (vorrangig) genutzt werden.
Lösungen, das ganze Bild durch Interpolation zwischen Vorgänger und Nachfolger zu ersetzen, brigen bei bewegten Bildern schlechte Ergebnisse.
Gruß
Highwayman
Bei bewegten Bildern erscheint es besser, den Ersatzframe aus einem Halbbild zu berechnen. Natürlich nur, wenn die Störung auf ein Halbbild beschränkt ist.
Wie oben beschrieben:
oriB = oriA.SeparateFields().Bob().SelectEven()
oriC = oriA.SeparateFields().Bob().SelectOdd()
Hier ist mir aufgefallen, dass der Odd-Frame in der Regel sehr viel schlechter ist als der Even-Frame.
Woran kann das liegen?
stackhorizontal (oriA, oriB, oriC)
Leider ist die Qualität des interpolierten Frames nur bei ruhigen Bildern akzeptabel, bei Bewegungen haben Personen schon mal 3 Beine oder 6 Finger.
Kann man an der Funktion noch etwas schrauben?
function fflow (clip c)
{
sup = c.msuper (pel=1)
bv = sup.manalyse (isb=true)
fv = sup.manalyse (isb=false)
c.mflowfps (sup, bv, fv, num=0)
return(c.mflowfps (sup, bv, fv, num=0))
}
