Frage von MLJ:@All
Wir alle kennen DV (SD) und das bei DV immer das Untere Feld zuerst kommt, egal ob PAL oder NTSC, richtig ? Wer nun aber mit VirtualDub direkt mit einem DV Codec wie Cedocida z.B aufnehmen möchte, der sollte das berücksichtigen:
In der Hilfedatei steht folgendes:
"Field order
A causes the
top field (
even scanlines) to be displayed first. Field order
B displays the
bottom field (
odd scanlines) to be displayed first. It is more common for capture devices to use field order
B."
Aber die Realität ist genau anders herum und daher muss der gleiche Text sich so lesen:
"Field order
B causes the
top field (
odd scanlines) to be displayed first. Field order
A displays the
bottom field (
even scanlines) to be displayed first. It is more common for capture devices to use field order
B."
Genauso sehen es alle Hersteller von NLE's, Encodern oder Codecs und VirtualDub arbeitet genau so, nur kam Avery scheinbar irgendwann damit durcheinander.
"Field Order
A" means:
Lower field first
Bottom field first (BFF)
Even field first
Even/Odd field order
1st line bottom
"Field Order
B" means:
Upper field first
Top field first (TFF)
Odd field first
Odd/Even field order
1st line top
Bei VirtualDub sind davon die Filter "Field Bob" und "Interlace" betroffen. Weiterhin im Capture Mode die "Preview Acceleration" Optionen außer "Interlaced Frames". In VirtualDub selbst unter "Options - Preview" die Optionen "Weave TFF/BFF etc." außer "Progressive". Die Filter "Field Delay" und "Deinterlace" arbeiten richtig, d.h. das "Top Field" hier wirklich "Odd" und "Bottom Field" auch "Even" ist.
Also aufpassen: "TFF" ist WIRKLICH "Odd" und "BFF" ist "Even" obwohl es genau umgekehrt in VirtualDub in den Menüs und Optionen steht. Dieser Bug scheint sich bisher in allen VirtualDub Versionen wieder zu finden, auch in der neuesten Version 1.10.4, nur das diese früher "Field Order A/B" hießen und nicht wie in den neueren Versionen "Top/Bottom Field".
Viele nehmen ihren Videorekorder oder Kameras zum Digitalisieren der Videos, und da gilt "Field Order
B", bei Firewire "Field Order
A" da hier die richtige Feldanordnung gleich geliefert wird. Wer sich also über ruckelnde Videos gewundert hat, das dürfte das Problem gewesen sein.
Cheers, Mickey.
Antwort von Alf_300:
Ganz anders ist es wenn PAL DV zufällig PAL Digital Video bedeutet, dann gilt Oberes Bild ;-)
Antwort von MLJ:
@Alf_300
nein, es ist das native DV Format gemeint (Mini DV, Digital-8) und der normale DV Codec (dvsd, z.B. Cedocida, MainConcept, Panasonic, Adaptec), die alle als Standard das Untere Bild zuerst nehmen, egal ob es PAL oder NTSC ist. Ich habe das ganze auch mit einer Firewire Verbindung getestet und VirtualDub hat tatsächlich diese Bugs, und das scheinbar seit dem ersten Release (!).
Bei allen getesteten DV-Codecs traten die Interlace Fehler auf. Weiterhin habe ich eine Animation als Digital Video (DV) testweise gerendert, einmal mit "Field Order A", dann mit "Field Order B" mit dem Ergebnis, das die Animation mit "Field Order A" richtig und flüssig abgespielt wurde während die Animation mit "Field Order B" ruckelte wie Sau, im Player und in VirtualDub. Das ruckeln war weg, wenn man "Swap Fields" beim Importieren gewählt hat. Im MainConcept DirectShow Decoder kann man "Invert Field Order" anwählen, da ruckelte auch nichts mehr. Beim DirectX DV Decorder (qdv.dll) kann man nur die Größe einstellen, und der ruckelt bei falscher Feldanordnung.
Ich habe einige Kollegen angerufen und die gebeten das ebenfalls mal zu testen, alle kamen zu dem gleichen Ergebnis, also dürfte sich dieses Verhalten von VirtualDub damit bestätigt haben. Ich habe Avery bereits geschrieben und denke, er wird darüber nicht erfreut sein nachdem er so lange an der Version 1.10.4 getüftelt hat ;) Scheinbar ist das noch niemandem aufgefallen, warum auch immer.
Cheers, Mickey.
Antwort von Alf_300:
Ganz Toll dass das nun nach 10 Jahren und nachdem DV praktisch nicht mehr gebraucht wird auffällt ;-)
Antwort von MLJ:
@Alf_300
Tja, lieber nach 10 Jahren als nie ;) Im übrigen: Auch die ganzen VirtualDub Varianten (Mod, Surround, MPEG2, VCR etc.) sind davon betroffen, damit dürfte sich Avery den Quellcode nochmal zur Brust nehmen. VirtualDub funktioniert einwandfrei, solange man Progressiv verwendet, nur bei Interlaced muss man alles umkehren und im Hinterkopf halten, das EVEN eben ODD ist und umgekehrt.
Na, und DV wird immer noch gebraucht, denke mal an die Leute hier, die ihr Material via Firewire auf den Rechner ziehen, DV ist noch nicht tot :)
Cheers, Mickey.
