Eure Erfahrungen mit deshaker

Ich nehm eigentlich fast nur noch mvBob (rechnet halt ggf. ein paar Tage) und füttere damit dann den Deshaker.

Und falls tats. zu breite Schlieren seitlich durch das Entwackeln + Interpolation mittels Vor-/Nachframes erscheinen, dann halt im Deshaker evtl. statt Zoom None auch Adaptive Zoom, auch wenn das Resizing bedeutet - aber manchmal wirds dann trotzdem ansehlicher.

Und ja: durchs Bild laufende Personen sind für den Deshaker tats. oft ein Problem. In solchen Szenen nehm ich dann oft das nicht entwackelte Original

ich mache immen ein pseudo 3-pass mit dem deshaker.

1st pass: sture analyse
2nd pass: stures deshaking mit speed-settings.
3rd pass: das video vom 2nd pass angucken. die Framenummern aller fehl-entwackelten szenen (durchs bild laufende personen/objekte) notieren.
Diese Zeilen mit den Framenummern einfach aus dem Log-File entferen.
Man kann sogar einzelne Bildnummern entfernen, ohne dass dies groß affällt.
Und dann mit diesem Logfile nochmals Deshaken. Nun aber mit sauberen Settings.

Genauso ist auch meine Vorgehensweise. Das Ergebnis des 2. Pass lasse ich als DV-Video ausgeben und schau mir das mit Premiere über den DV-Camcorder am Fernseher an. Das zweite Fenster ist VirtualDub mit dem DV-Video - da kann ich die Framenummer ablesen. Und das 3. Fenster ist der Texteditor.
Aber zeitaufwändig ist das schon, zumindest wenn man eben Kinder filmt und Motive, bei denen sich viel bewegt. Wie schön, wenn die Kiddies mal älter sind und ich nur noch Landschafts-Aufnahmen mache

Wenn Du 16:9 Upscaling machst, solltest Du Dir wirklich unbedingt mal mvbob angucken.

Denn erst dadurch wird das deshaking und resizing artefaktarm.

also:
1) mit mvbob() bobben und als AVI ausgeben
2) deshaken
3) croppen und auf 16:9 resizen, reinterlacen und encoden.

Zitat von scharfis_brain

das video vom 2nd pass angucken. die Framenummern aller fehl-entwackelten szenen (durchs bild laufende personen/objekte) notieren.
Diese Zeilen mit den Framenummern einfach aus dem Log-File entferen.
Man kann sogar einzelne Bildnummern entfernen, ohne dass dies groß affällt.
Und dann mit diesem Logfile nochmals Deshaken. Nun aber mit sauberen Settings.

Werden die aus dem Logfile entfernten Framenummern dann komplett weggeworfen od. einfach nicht entwackelt, sprich an deren Stelle werden die Original-Frames beibehalten?

Zitat

einfach nicht entwackelt, sprich an deren Stelle werden die Original-Frames beibehalten?

Ja.
Dies wird aber so gemacht, dass es keinen Sprung gibt. Die Vorgänger- und Nachfolgerframes sind nahtlos an die nichtenwackelte Sequenz drangepappt.

Beim nachträglichen editieren des Videos ist dies nicht der Fall.

scharfis_brain:
Danke für den Tipp. Werde ich einmal in den nächsten Tagen anschauen und ausprobieren.

Für mein Verständnis: Was spricht konkret gegen SeparateFields() und Weave()? Habe nach der Suche hier, im SVCD-DVD-Forum und bei Doom9 keine konkrete Beschreibung und auch keine Vergleichsbilder-/Filme gefunden. Ich habe mir meine Ergebnisse auf Monitor und Fernseher (bei Letzterem als MPEG-2-kodiertes anamorphes 16:9-Movie sowohl mit 16:9-, als auch testweise mit 4:3-Flag) angeschaut und konnte keine deutlichen Fehler/Artefakte erkennen. Worauf müsste ich achten? Kanten? Zittern oder Flackern? Letzteres hätte ich mir theoretisch nach einer Skalierung vorstellen können, aber wirklich "falsch" sieht es hier nicht aus. Oder hängt das von der Fernseher-Größe ab? Dann hätte es mir doch auch auf dem Monitor deutlich in´s Auge stechen müssen.

P.S.: Ein Denoising mache ich derzeit nicht. Meine alte Sony mit 1 CCD hatte das wirklich noch nötig, aber mit dem Bild der Panasonic mit dem 3 CCD bin ich recht zufrieden. Auch TMPGEnc zeigt "von Haus aus" vergleichsweise niedrigere Bitraten beim 1st-Pass als bei meiner alten Cam - IMHO auch ein Beweis für das "saubere" Bild.

Zitat von scharfis_brain

Dies wird aber so gemacht, dass es keinen Sprung gibt. Die Vorgänger- und Nachfolgerframes sind nahtlos an die nichtenwackelte Sequenz drangepappt.

Ah bestens - das wusste ich nicht - optimal

Zitat von scharfis_brain

Beim nachträglichen editieren des Videos ist dies nicht der Fall.

eben - das war immer recht mühsehlig da halbwegs ordentliche Übergänge hinzukriegen...

Danke für den Tip!

JK1974: poste doch mal Dein Script mit separatefields() & weave() und das mit dem Bobber.

dann erkläre ich Dir die UNterschiede.

Hi,

hier mal mein aktuelles Skript:

V=AVISource("C:\temp.vdr")V=Crop(V,0,72,0,-72)V=SeparateFields(V)V=Spline36Resize(V,720,288)V=Weave(V)V=Crop(v,16,17,-16,-15)V=AddBorders(v,16,16,16,16)return V

Und hier das "alte":

V=AVISource("C:\temp.vdr")
V=ConvertToYUY2(V)
V=TMCBob(V,false)
V=Crop(V,0,72,0,-72)
V=Spline36Resize(V,720,576)
V=ReinterlaceBob(V,false)
V=Crop(v,16,17,-16,-15)
V=AddBorders(v,16,16,16,16)
return V

Recht trivial das Ganze...

Ich mache in diesen Skripts noch eine "Sauerei": Ich schiebe das Bild um eine Zeile nach oben, um aus dem DV-Bottom-Field-First-Video ein Top-Field-First-Video zu machen. Habe gelegentlich gelesen oder gehört, dass dass problematisch ist wg. irgendwelcher Phasen-Verschiebungen, verstanden habe ich´s aber nicht. Geht es um das Transkodieren von unverändertem DV- oder DVD-Material kann ich mir vorstellen, dass es besser ist, wenn die Macro-Blocks von Original- und Ziel-Datei übereinanderliegen, aber nach Deshaken etc. dürfte das IMHO egal sein. Oder ist mit dieser Phasen-Geschichte etwas anderes gemeint?
Darüber hinaus ging es mir auch um den Workflow: Ich wollte den Ton nicht jeweils manuell verschieben, sondern schiebe das aus Premiere exportierte WAV lieber gleich direkt in den AC3-Encoder. ;D

Besten Dank für Deine Hilfe!

Jörg

1) was sind VDR-Dateien?
2) separatefields(). resize().weave() wird Dir die Spatiale Halbbildanordnung (der versatz um einen halben Pixel) kaputt machen. Dies führt zu leichtem auf und ab zittern des Bildes und reduziert die effektive auflösung.

bei bob().resize().reinterlace() bleiben die Halbbilder immer um einen halben pixel versetzt.

3) die Fieldorder dreht man besser über

doubleweave().selectodd()

Als Ergänzung:

Bei dvd-svcd-forum findet man dazu deshalb nichts, mehr, weil der Thread, in dem ich damals scharfis Vorgehensweise gemixt mit meinen Erfahrungen damit beschrieb aus irgendeinem Grund nie "nach draußen" gehängt wurde. (ich frag' mich, warum nicht???)

A.Dittrich hatte dazu was recht anschauliches gepostet:

Zitat

um die fachliche Diskussion etwas zu beleben, hätte ich noch eine Anmerkung zu der "konventionellen" Methode, wie von Kika beschrieben.

Dabei ging es um separatefields.resize.weave

und weiter:

Zitat

Mal davon abgesehen, daß die Skalierung/Filterung von Halbbildern aufgrund der örtlichen Unterabtastung immer problematisch ist, macht man meiner Meinung nach immer einen grundsätzlichen (vermeidbaren) Fehler mit der Methode
"<Halbbilder separieren>, <Skalieren>, <Halbbilder verkämmen>, <Ränder hinzufügen>":
Vor der vertikalen Skalierung haben die Halbbilder einen örtlichen Versatz von einer halben Zeile. Dieser Versatz wird jetzt beim normalen Resizen (hängt von der verwendeten Methode ab) der separierten Halbbilder ebenfalls skaliert. Beim darauffolgendem Verkämmen der Halbbilder wird jetzt das untere Halbbild aber um eine halbe Zeile nach unten verschoben, was jedoch nicht hundertprozentig stimmt, da es ja nur um die skalierte halbe Zeile verschoben werden sollte. Abhilfe schafft eine Resize-Methode, welche z.B. die erste Zeile nicht verschiebt, also quasi den Referenzpunkt auf der ersten Zeile hat und nicht in der Mitte des Bildes.

Und außerdem:

Zitat

Bei der Methode mit dem Deinterlacer tritt dieses Problem natürlich nicht auf. Leider habe ich bis heute noch keinen wirklich richtig guten Deinterlacer für den PC gefunden, d.h. mit Bewegungskompensation, Erkennung verdeckter Bereichen, Zuverlässigunsinformationen für die Bewegungsvektoren und darauf basierenden Adaptiven Filtern, etc.

Zumindest das ist inzwischen gelöst. Zu der Zeit, als der Thread entstand, gab es als halbwegs intelligenten Bobber nur den SmoothDeinterlace.

Danach folgte noch:

Zitat

Dazu folgendes Beispiel:
Wir haben ein Frame mit 8 Zeilen, d.h. das obere Halbbild besteht aus den Zeilen 1,3,5,7 und das untere aus 2,4,6,8. Skaliert wird jetzt auf die Hälfte, und zwar im einfachsten Fall bilinear = Mittelwert aus je zwei aufeinanderfolgenden Halbbildzeilen. Wir Skalieren nach der beschriebenden Methode separieren, skalieren, vekämmen. Am Ende haben wir dann vier Zeilen: oberes Halbbild, y_neu(1) = (y(1)+y(3))/2, y_neu(3) = (y(5)+y(7))/2
unten: y_neu(2) = (y(2)+y(4))/2, y_neu(4) = (y(6)+y(8))/2
y(.) bezeichne dabei den Farb oder Helligkeitswert der Zeile/Pixel.

Schaut man sich jetzt an, wo die neuen Zeilen örtlich im Ursprungszeilenraster liegen ergibt sich, folgendes:
Vertikalposition von y_neu: vpos(1) = 2, vpos(2) = 3, vpos(3) = 6, vpos(4) = 7

Die Positionen sind also nach der Skalierung nicht mehr gleichmäßig über das gesamte Bild verteilt.

Alles anzeigen

Da brauchte ich dann auch Aspirin.

Hi,

scharfis_brain (& Kika):
1) Das sind die Frameserver-Dateien von VirtualDub. Werde vielleicht irgendwann mal versuchen, das Ganze direkt über AVISynth zu machen, aber ich muss erstmal finden, wie man in AVISynth VirtualDub-Plugin-Parameter übergibt.
Und wenn Dir VDR sonst noch über den Weg laufen sollte: So lautet auch die Extension für PES-Aufnahmen mit dem Linux Video-Disk-Recorder VDR - aber das ist eine andere Baustelle
2) Ich dachte mir sowas, nur hat´s A.Dittrich wirklich so erklärt, wie ich es hätte nie erklären können. Daher auch mein Hinweis mit dem Zittern. Allerdings wirkte es sich bei mir nicht so gravierend aus, wie ich gedacht habe, weshalb ich das Ergebnis so akzeptiert habe. Das mit dem "richtig guten Deinterlacer" ist auch mein Problem, aber vielleicht kann´s ja mvbob richten - werde ich mir wohl mal am Wochende anschauen (bin noch am Schneiden und Preview-Deshaken).
3) Aber dann muss ich ja den Ton verzögern. Kann mir jemand den genauen Grund erklären, warum das so besser ist bzw. einen Link posten? Kenne noch die Diskussionen im Zusammenhang mit dem CCE, aber wenn´s selbst die machen - denn anscheinend wird ja CCE von immer mehr Hollywood-Studios eingesetzt. Allerdings heißt das natürlich ja auch nicht, dass es gut sein muss, wenn es viele einsetzen - kennen wir ja...

Thanx!

Jörg

Zitat von JK1974

Das mit dem "richtig guten Deinterlacer" ist auch mein Problem, aber vielleicht kann´s ja mvbob richten

Wenns schneller gehen soll ist auch TDeint (TDeintBob) eine recht gute Alternative.