Videobearbeitung (PAL) mit VirtualDub

Gustav K. schrieb:
> Wobei ich mich auch frage, wie VirtualDub überhaupt erkennen kann, dass
> Bild und Ton nicht synchron sind.

Du bist der Erkenner und Korrigierer.

Audio -> Interleaving -> Audio skew correction


Übrigens weißt Du nun, warum die USB Grabber doch nicht so toll sind...
(lustig wird es, wenn der Versatz im Wert wandert)

Man kann doch irgendwo im Audiomenü die Zeit in ms direkt eingeben. Je 
nach Versatz positiver oder negativer Wert.

Crazy H. schrieb:
> Man kann doch irgendwo im Audiomenü die Zeit in ms direkt
> eingeben. Je nach Versatz positiver oder negativer Wert.

Wie Mhh schon schrieb:
> Audio -> Interleaving -> Audio skew correction

Gustav K. schrieb:
> Eine Minute
> grabben erzeugt so ca. 1 GB.

Nicht Dein Ernst, für VHS-Qualität!

Michael Bauer schrieb:
> Gustav K. schrieb:
>> Eine Minute
>> grabben erzeugt so ca. 1 GB.
>
> Nicht Dein Ernst, für VHS-Qualität!

Doch, er schrieb doch:

Gustav K. schrieb:
> erzeugt als
> Ausgabeformat *.avi, Codec YUV2, 720x576 mit 25 Frames.

Das ist normales AVI, hier werden also keinerlei Kompressionen 
angewandt. Kann schon hinkommen... Ließe sich aber mit einem Code 
beheben. Und grabben kann man auch sehr gut mit VirtualDub. Und zwar mit 
Codec.
Ich habe den Verdacht, daß Gustav mit einem anderen Programm gegrabbt 
hat.

Der Mhh schrieb:
> Audio -> Interleaving -> Audio skew correction

Grmpf, ich sah wohl den Wald vor Bäumen nicht - oder das Programm hat so 
viele Einstellmöglichkeiten, dass man den Überblick verliert. Bei der 
Gelegenheit: Was macht die Einstellmöglichkeit darüber (Audio block 
placement), hier kann ich einstellen was ich will, es ändert sich am 
Tonversatz gar nichts

> Übrigens weißt Du nun, warum die USB Grabber doch nicht so toll sind...
> (lustig wird es, wenn der Versatz im Wert wandert)

Habe mal 10min. einen laufenden Plotter aufgenommen, der Versatz wandert 
zum Glück nicht. An den Fahrgeräuschen und dem Absetzen des Stiftes kann 
man das gut sehen. Immerhin weiss ich jetzt, wieso die Filmemacher eine 
Klappe im Bild schlagen...

> Ich habe den Verdacht, daß Gustav mit einem anderen Programm
> gegrabbt hat.

Stimmt, das Grabben in VirtualDub mit 720x576 ist hier etwas fummelig, 
oft kippt das Bild um, eine notierte Einstellung geht mal, mal geht sie 
nicht. Ein anderes Programm grabbt da zuverlässiger. Allerdings ist auch 
beim Grabben in VirtualDub ein Zeitversatz vorhanden, es entfällt nur 
die Fehlermeldung. Der Zeitversatz ist übrigens nicht konstant, bei 
verschiedenen Aufnahmen habe ich Werte zwischen 3 und 12 Frames gesehen.

Das ist dumm, ich hatte gehofft, einen konstanten Wert ermitteln zu 
können, damit wäre das Problem mit dem Versatz aus der Welt gewesen. Ich 
werde also die einzelnen Szenen vom Band auch einzeln korrigieren 
müssen. Das wird fummelig.

Mit was grabben die Profis?

Gustav

Bernd S. schrieb:
> Das ist normales AVI, hier werden also keinerlei Kompressionen
> angewandt.

AVI ist zunächst nur ein Containerformat für A/V Streams. Die Streams 
können dabei sehr wohl komprimiert sein.

Gustav K. schrieb:
> Wobei ich mich auch frage, wie VirtualDub überhaupt erkennen kann, dass
> Bild und Ton nicht synchron sind.

Ist eher dein Job, der Versatz zu spezifizieren. Wobei eigentlich erst 
mit der Kombination aus VirtualDub und Avisynth die volle 
Leistungsfähigkeit erreicht wird.

A. K. schrieb:
> Ist eher dein Job, der Versatz zu spezifizieren.

Sicher, wurde ja auch schon genannt. Aber VirtualDub gibt ja eine 
Fehlermeldung aus (s. mein 1. Beitrag), die Zahl 12 muss ja irgendwoher 
kommen.

Gustav

Gustav K. schrieb:
> Sicher, wurde ja auch schon genannt. Aber VirtualDub gibt ja eine
> Fehlermeldung aus (s. mein 1. Beitrag), die Zahl 12 muss ja irgendwoher
> kommen.

Es gibt 2 Startlinien, welche um 12 Frames versetzt sind. Diesen Umstand 
findet VD albern und moniert deswegen.

(Es wird also nicht der Versatz im Filmchen angezeigt, sondern nur die 
ungleichen Startpunkte erkannt.)

A. K. schrieb:
> Bernd S. schrieb:
>> Das ist normales AVI, hier werden also keinerlei Kompressionen
>> angewandt.
>
> AVI ist zunächst nur ein Containerformat für A/V Streams. Die Streams
> können dabei sehr wohl komprimiert sein.

Das weiß ich schon. Wie man eber an der Filegröße sehen kann, ist das 
hier umkomprimiertes AVI, also jedes einzelne Bild ohne Komprimierung 
auf die Platte geschrieben. Ich denke, wenn man das nachrechnet, kommt 
die Größe schon in etwa hin.
Ich hatte mich nur etwas unglücklich ausgedrückt.

Bernd S. schrieb:
> Wie man eber an der Filegröße sehen kann, ist das
> hier umkomprimiertes AVI, also jedes einzelne Bild ohne Komprimierung
> auf die Platte geschrieben.

Habe mal wo gelesen, dass man beim Grabben möglichst unveränderte 
Einzelbilder einlesen soll, dann nacharbeiten und wenn das Filmchen 
fertig ist, einmal möglichst optimal komprimieren soll. Bei den 10 min. 
Plotterlauf hatte ich 13 GB auf der Platte, nach dem Konvertieren nach 
mp4 waren es gerade noch 42 MB, das ist ein Faktor von 310 - und das 
ohne sichtbaren Qualitätsverlust im Bild.

Habe eben meine Szene von Videokassette gegrabbt und Glück gehabt, 
VirtualDub meckert nur 2 Frames an. Da am Anfang einer die Heckklappe 
zuschlägt, habe ich eine Klappe im Bild - und die passt perfekt. Scheint 
offensichtlich auch an der Signalquelle zu liegen, wie gross der Versatz 
beim Grabben wird. Die Signale der ersten Versuche (erster Beitag) habe 
ich direkt meiner analogen Videokamera entnommen.

Aber noch was: Ich sehe im digitalisierten Bild, dass das Bild leicht 
gestaucht ist. Es ist höher als breit.

Das damalige 4:3 TV entspricht ja einem Verhältnis von 1.33. Habe hier 
eine Videokassette mit Testbild drauf (damals aus dem TV aufgenommen) 
wenn ich nun das Testbild nach 640x480 digitalisiere (640/480=1.33), 
dann ist der Kreis im Testbild nicht rund, sondern ein Ei. Bei beiden 
Formaten ist das Seitenverhältnis 1.33, das digitale Bild ist jedoch 
gestaucht. Wie kann das sein?

Gustav

Gustav K. schrieb:
> Scheint
> offensichtlich auch an der Signalquelle zu liegen, wie gross der Versatz
> beim Grabben wird.

Nein, liegt es nicht. Es liegt an den Ablenkungsmanövern von auf dem 
Rechner laufenden Prozessen.

Gustav K. schrieb:
> Habe hier
> eine Videokassette mit Testbild drauf (damals aus dem TV aufgenommen)
> wenn ich nun das Testbild nach 640x480 digitalisiere (640/480=1.33),
> dann ist der Kreis im Testbild nicht rund, sondern ein Ei. Bei beiden
> Formaten ist das Seitenverhältnis 1.33, das digitale Bild ist jedoch
> gestaucht. Wie kann das sein?

Weil das Bild eigentlich 768*576 Pixel beträgt. Wegen dem bei damaligen 
TV Geräten notwendigem Overscan musst Du mit 720*576 für ein rundes Ei 
aufnehmen. Damit bist Du aber wieder schon am Rande des Datenkollaps am 
USB Anschluss mit entsprechenden Nebenwirkungen...

Die Reduzierung auf 640*480 kann durchaus hässliche Ergebnisse 
produzieren. Da könnte 360*288 das homogenere Bild ergeben (oder einer 
internen Lösung mit Vollbild den Vorzug geben).

Der Mhh schrieb:
> Weil das Bild eigentlich 768*576 Pixel beträgt. Wegen dem bei damaligen
> TV Geräten notwendigem Overscan musst Du mit 720*576 für ein rundes Ei
> aufnehmen.

Das erstaunt, sind dann alle digitalisierten Aufnahmen gestaucht?

Ich überlege, ob ich meine Aufnahmen "entstauche". Dazu haben ich ein 
Testbild mit 768*576 mit einer analogen Kamera aufgenommen. Dann mit 
meiner Nachbearbungssoftware links und rechts so lange Pixel 
abgeschnitten (bei gleichem Bildformat von 720x576), bis ich im 
digitalisierten Bild einen runden Kreis habe.

Allerdings lese ich nun was von "nicht quadratischen Pixeln" ... ??
Deshalb mal zwei Testbilder, beim rechten Bild sehe ich hier einen 
runden Kreis. Bei einem Display mit rechteckigen Pixeln ist 
möglicherweise der Kreis im linken Bild rund.

Was seht ihr? Was macht Sinn?

Gustav

Gustav K. schrieb:
> Was seht ihr? Was macht Sinn?

Ich kann da nur für mich sprechen.

Ich digitalisiere in 720*576 und egal ob das Ergebnis über Röhre oder 
LCD ausgegeben wird - Eier gibts nur aus dem Kühlschrank.

Habe es jetzt auch hinbekommen, das Testbild mit VirtualDub in 768x576 
mit rundem Kreis zu erzeugen, obwohl das Eingangsformat nur 720x576 war, 
s. Bild. Es ist also alles möglich. Die Frage ist nur, welchen Weg 
schlägt man am Besten ein. Auf einer Röhre werden die digitalisierten 
Videos nicht mehr laufen, da keine mehr vorhanden ist.

Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild 
einige flimmernde Linien sieht? Bei allen Kassetten mit Videoaufnhamen 
aus verschiedenen Quellen ist das so. Wobei die originalen Bänder der 
Kameras stehts einmal auf Kassette überspielt wurden.

Der Mhh schrieb:
> Nein, liegt es nicht. Es liegt an den Ablenkungsmanövern von auf dem
> Rechner laufenden Prozessen.

Habe jetzt von einigen Bändern einige Szenen gegrabbt, VirtualDub 
meldete immer einen Versatz von 2 Frames. Am Signalausgang der analogen 
Sony-Kamera war der Versatz bei sehr vielen Versuchen immer 12 Frames.

Gustav

Leider wird ein weiteres Problem sichtbar:

Ein Band zeigt bei der Wiedergabe ein gutes Bild, das Ergebnis ist nach 
dem Grabben ebenfalls ein recht gutes Bild. Ein anderes Band ist in der 
Qualität vergleichbar, nach dem Grabben habe ich bei den Farben ein 
deutlich sichtbares Muster, vergleichbar mit einer 30° Kreuzrändel:
http://ww3.cad.de/foren/ubb/uploads/weimerv/raendeltest.jpg

Wenn ich versuche, dem Muster mit irgendwelchen Filtern zu Leibe zu 
rücken (z.B. blur), erhalte ich ein starkes Farbenflimmern. Alle 
Versuche, die Bildqualiät zu verbessern, gehen nach hinten los.

Hat jemand eine Erklärung für dieses 30° Muster in dem Farben?

Gustav

Gustav K. schrieb:
> Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild
> einige flimmernde Linien sieht?

Leider ja.

Ich lege beim umrechnen einen schwarz gefüllten Streifen darüber.
(Video - Filters - fill)


Gustav K. schrieb:
> VirtualDub
> meldete immer einen Versatz von 2 Frames. Am Signalausgang der analogen
> Sony-Kamera war der Versatz bei sehr vielen Versuchen immer 12 Frames.

Interne Lösung. Egal welche Quelle und Auflösung - null Versatz.

Gustav K. schrieb:
> Ein Band zeigt bei der Wiedergabe ein gutes Bild, das Ergebnis ist nach
> dem Grabben ebenfalls ein recht gutes Bild. Ein anderes Band ist in der
> Qualität vergleichbar, nach dem Grabben habe ich bei den Farben ein
> deutlich sichtbares Muster,

Aufnahme beendet, anderes Band rein und Aufnahme wieder gestartet?
Wenn ja, Rechnerneustart oder wenigstens Aufnahmeanwendung beenden und 
neu starten.

Das Muster siehr irgendwie nach Farbträger aus, der sollte eigentlich 
besser rausgefiltert werden. Ist dieses Muster auch in nicht farbigen 
Bereichen (Schwarz, Grau, Weiß), beim selben Band? Stammt diese Band von 
der selben Aufzeichnungs-Maschine, wie das Andere, das funktioniert? 
Vielleicht hilft das ja bei der Fehhlersuche.

Mit freundlichen Grüßen - Martin

Gustav K. schrieb:
> Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild
> einige flimmernde Linien sieht? Bei allen Kassetten mit Videoaufnhamen
> aus verschiedenen Quellen ist das so.

Einige Zeilen vor dem vertikalen Synchronsignal schalten alle 2-Kopf 
Videosysteme die Köpfe um, das V-Sync Signal kommt dann vom gerade 
eingeschalteten Kopf.
Durch das Umschalten entsteht ein leichter 'Skew' (Zeitversatz), auf den 
die meisten Grabber nicht schnell genug einrasten. Hilfe bringt hier nur 
eine Zeitbasiskorrektur, die vor dem Grabben das Signal 
zwischenspeichert und mit quarzgenauer Zeitbasis wieder ausgibt oder ein 
richtig hochwertiger Player.

Die flimmernden Zeilen kommen aber daher, dass der "noch aktuelle" Kopf 
bei 180Grad Umschlingung schon langsam den Kontakt zum Band verliert 
bzw. das schon bei der Aufnahme passiert ist. Eine Zeitbasiskorrektur 
braucht es beim Grabben eigentlich nicht, weil der billige Grabber genau 
das ist, was die sündteure TBC früher gemacht hat ;)

Der Mhh schrieb:
> Ich lege beim umrechnen einen schwarz gefüllten Streifen darüber.
> (Video - Filters - fill)

Das wäre auch eine Lösung, ich mache mit Cropping den Rand an allen 4 
Seiten ab (oben nur ganz wenig )und strecke dann mit resize wieder auf 
das ursprüngliche Format. Dabei darauf achten, dass ein Kreis rund 
bleibt.

> Interne Lösung. Egal welche Quelle und Auflösung - null Versatz.
Was heisst das jetzt genau?
Andere Hardware, wenn ja welche?

Das mit dem Versatz bleibt mir weiterhin ein Rätsel, denn VirtualDub 
meldet den Versatz weiterhin, selbst wenn ich am Anfang einigen Sekunden 
abgeschnitten und die Datei neu abgespeichert habe.

Leienhaft beschrieben: da sind zwei Papierstreifen (Bild/Ton), am Anfang 
ist ein Streifen etwas kürzer als der andere. Nun schneide ich mit einer 
Schere den Anfang bündig ab, wie kann man immer noch erkennen, dass die 
beiden Steifen einen Versatz haben? Die Bilder könnte man theoretisch 
durchnummerieren, wie nummeriert man den Ton?

> Aufnahme beendet, anderes Band rein und Aufnahme wieder gestartet?
> Wenn ja, Rechnerneustart oder wenigstens Aufnahmeanwendung beenden und
> neu starten.
Zwischen den beiden Aufnahmen lagen Tage, der Aufbau war der gleiche.

Martin Schlüter schrieb:
> Ist dieses Muster auch in nicht farbigen Bereichen (Schwarz, Grau,
> Weiß), beim selben Band?
Ja, aber nur ca. halb so stark ausgeprägt.
Richtig heftig wird es erst bei den Farben.

> Stammt diese Band von der selben Aufzeichnungs-Maschine, wie das
> Andere, das funktioniert? Vielleicht hilft das ja bei der Fehhlersuche.

Also die Aufnahmen hat ein damiger Schulfreund mir seiner riesen 
Videokamera (Schultergerät) gemacht. Danach hat er das Band aus der 
Kamera auf eine seiner Kassette überspielt und das Kameraband gelöscht, 
um es für weitere Aufnahmen zu verwenden. Von seinem Videorecorder haben 
wir es dann auf meinen Videorecorder kopiert. Also eine Kopie einer 
Kopie. Zusätzlich wurde das Band nun auf einem anderen Videorecorder 
abgespielt. Trotzdem war das Bild noch rel. gut, wenngleich die Farben 
etwas nach rechts und unten "verrutscht" waren. Ein leichtes 
Farbenflimmern war bereits auf dem Band zu sehen. Sicher nicht die 
optimalste Ausgangssituation, es gibt aber leider keine andere.

Georg A. schrieb:
> Die flimmernden Zeilen kommen aber daher, dass der "noch aktuelle" Kopf
> bei 180Grad Umschlingung schon langsam den Kontakt zum Band verliert
> bzw. das schon bei der Aufnahme passiert ist.

Diese Erklärung wäre für mich zumindest nachvollziehbar

Gustav

Gustav K. schrieb:
> Das wäre auch eine Lösung, ich mache mit Cropping den Rand an allen 4
> Seiten ab (oben nur ganz wenig )und strecke dann mit resize wieder auf
> das ursprüngliche Format. Dabei darauf achten, dass ein Kreis rund
> bleibt.

Das macht das Ergebnis schlechter als "fill", da ein "resize" sich 
prinzipbedingt Bildinformationen ausdenken muss.

Gustav K. schrieb:
>> Interne Lösung. Egal welche Quelle und Auflösung - null Versatz.
> Was heisst das jetzt genau?
> Andere Hardware, wenn ja welche?

Alter Rechner (Sockel A), alte Grafikkarte mit Videoeingang (Riva TNT2) 
und 2 große Festplatten (eine Quelle und andere Ziel beim umrechnen).
Damals wurde die Videofunktion mit mehr Liebe behandelt.

Gustav K. schrieb:
> Das mit dem Versatz bleibt mir weiterhin ein Rätsel, denn VirtualDub
> meldet den Versatz weiterhin, selbst wenn ich am Anfang einigen Sekunden
> abgeschnitten und die Datei neu abgespeichert habe.

Das ist ein "feature" der USB Lösungen.

Gustav K. schrieb:
> Also eine Kopie einer
> Kopie. Zusätzlich wurde das Band nun auf einem anderen Videorecorder
> abgespielt. Trotzdem war das Bild noch rel. gut, wenngleich die Farben
> etwas nach rechts und unten "verrutscht" waren. Ein leichtes
> Farbenflimmern war bereits auf dem Band zu sehen. Sicher nicht die
> optimalste Ausgangssituation, es gibt aber leider keine andere.

Dann liegt es leider an der schlechten Vorlage mit den Störungen, wenn 
sich sogar schon Laufzeitunterschiede von chroma und lumina über die 
Kopien aufaddiert haben.

Der Mhh schrieb:
> Das macht das Ergebnis schlechter als "fill", da ein "resize" sich
> prinzipbedingt Bildinformationen ausdenken muss.

Stimmt, um einen Kreis rund zu halten, muss man sogar noch etwas mehr 
links und rechts abknapsen. Wenn ich allerdings die Input/Output-Fenster 
nebeneinander setze, kann ich keinen sichtbaren Unterschied erkennen.

> Dann liegt es leider an der schlechten Vorlage mit den Störungen, wenn
> sich sogar schon Laufzeitunterschiede von chroma und lumina über die
> Kopien aufaddiert haben.
OK, dann kann man nichts machen. Ich habe bei der Bearbeitung der 
Aufnahmen kein Filter aktiviert, starkes Farbenflimmern macht keine 
Freude.

Habe mich mal zu "adaptivem Deinterlacing" etwas eingelesen, bei 
VirtualDub heisst das wohl "temporal smoother". Leider wird dabei der 
Ton unbrauchbar, gibt es eine Lösung, den Ton zu retten?

Gustav

Gustav K. schrieb:
> Habe mich mal zu "adaptivem Deinterlacing" etwas eingelesen, bei
> VirtualDub heisst das wohl "temporal smoother".

Welchen Filter ich verwende, kann ich im Moment nicht nachsehen (ich 
verwende den Rechner ausschließlich zum digitalisieren, daher steht er 
bei Nichtnutzung zugebuddelt im Schrank), dieser genannte ist es aber 
definitiv nicht.

Gustav K. schrieb:
> Leider wird dabei der
> Ton unbrauchbar, gibt es eine Lösung, den Ton zu retten?

Ich nehme den Ton im 48 kHz Format auf und bei jeder Berechnung (bis auf 
den Schluß, wo eine DVD draus wird) steht Audio auf "direct stream 
copy". Daher kann ich den Fehler auch gedanklich nicht nachvollziehen. 
Was bedeutet unbrauchbar in Deinem Fall?

Der Mhh schrieb:
> dieser genannte ist es aber definitiv nicht.
Also bei "temporal smoother" werden die letzten 1-8 Bilder mit die 
Berechnung den neuen Bildes miteinbezogen. Eine Einstellung auf 4 macht 
sich leicht positiv bemerkbar. Zwischen In- und Output Fenster wird 
zusätzlich ein zeitlicher Versatz sichtbar.

Der Mhh schrieb:
> Was bedeutet unbrauchbar in Deinem Fall?
Der Ton macht schrapp-schrapp-schrapp ...
Audio steht ebenfalls auf "direct stream copy"

Gustav