Frage von hubse:Hi,
ich hab hier irgendwo gelesen (ich hab gesucht, ich finds nicht mehr), dass man top-field- und bottom-field-Material nicht mischen darf.
Wenn man ein Bild spiegelt oder oder auf den Kopf stellt (z.B. wenn man die Steadycam umdreht um mit der Kamera nah an den Boden zu kommen und dann beim Schneiden das Bild umdrehen muss), hab ich dann aus top-field ein bottom-field gemacht? Bekommt man damit Probleme?
Gruß,
Martin
Antwort von Immedia:
Könnte Problematisch werden wen noch Left-field und Right-field dazukommen bei seitwärts Aufnahmen.
Antwort von tommyb:
@hubse
Interessanter Denkansatz. Habs mir gerade mal mit Avisynth angeschaut und ja - in de Tat - die Fields ändern sich.
An sich ist es nicht schlimm Top und Bottom zusammen zu benutzen, allerdings sollte das Schnittprogramm solches Material auch als solches erkennen und anpassen können.
Alternativ kann man das Material auch zu 50p deinterlacen und dann verabeiten (darum ist progressives Material so gülden :)
Antwort von WoWu:
Wirklich interessanter Ansatz, ab wann reagiert denn ein NLE, wenn ich ein Frame beispielsweise nur um einige Grad neige, werden die Zeilen ja neu gescannt ... warum also nicht bei 180° ? Hmmm.
Antwort von Jott:
An der Zeilenfolge ändert sich ganz sicher nichts, wenn man in der Timeline Footage dreht und wendet. Die bleibt immer so wie einmal eingestellt, passend zum Codec, auch wenn ein Clip darin auf den Kopf gestellt wird.
Antwort von WoWu:
Habs mir gerade mal mit Avisynth angeschaut und ja - in de Tat - die Fields ändern sich.
Glauben wir mal dem Praktiker ? :-)
Antwort von tommyb:
avisource("hierdateirein.avi") ## am besten DV-AVI
assumebff() ## annehmen dass Bottom Field First, weil DV
bob()
So is normal.
Und hier die Gegenprobe:
avisource("hierdateirein.avi") ## am besten DV-AVI
assumebff() ## annehmen dass Bottom Field First, weil DV
Turn180()
bob()
Uuups...
Und dennoch ändert dies nichts daran, dass ein Schnittprogramm welches mit Halbbildern vernünftig umgeht alles auch beim drehen, wenden und rotieren richtig macht.
Die Fieldreihenfolge lässt sich übrigens auch ganz einfach wieder "zurück-umkehren", in dem man oben eine Zeile (1px) wegcroppt und unten am Bild schwarz anfügt.
Z.B. so:
avisource("hierdateirein.avi") ## am besten DV-AVI
assumebff() ## annehmen dass Bottom Field First, weil DV
Turn180()
converttorgb32()
crop(0,1,0,0)
addborders(0,0,0,1)
converttoyv12()
bob()
oder sogar so:
avisource("hierdateirein.avi") ## am besten DV-AVI
assumebff() ## annehmen dass Bottom Field First, weil DV
Turn180()
swapfields()
assumebff() ## muss sein, weil auch der interne Field Tag in Avisynth geändert wird
bob()
Antwort von iMac27_edmedia:
Nimm das Material z.B. DV und XDCAM EX-Material, ziehe es auf die XDCAM-Timeline und schaue Dir die Zeilen an, dann wirst Du sehen dass die Zeilen für das DV-Material angepasst werden. Das kann man zusammenschneiden, wir und unsere Kollegen schneiden für Pro7 und RTL-Produktionen solches Material immer wieder an der AVID zusammen, das ist normaler TV-Alltag und die TV-Sender sind damit zufrieden, d.h. das Material ist Sendefähig!
Antwort von WoWu:
DV und XDCAM ist klar, aber hier geht es doch darum, dass beides DV Material ist, einmal nur im Scanreverse.
@tommyb
Mir ist der workflow noch nicht so ganz klar, ich würde ihn aber gern verstehen. Kannst Du noch einmal sagen, wie Du das Bild gedreht hast, bevor Du es getestet hast ?
Auch mit der einen eingefügten Zeile ist klar.
Mir geht es nur darum zu erfahren, wie das Frame ausgesehen hat, das zu der Turn 180 Anweisung geführt hat.
Mal ganz abgesehen davon, dass solche Probleme ja dann auch bei den Movie-Adapter Anwendern auftreten müssten, dessen Bild ohne Scan-reverse aufgenommen werden, wenn sie mit andern Bildern gemischt werden.
Antwort von tommyb:
@WoWu
Ich hoffe es hilft Dir, wenn ich die einzelnen Befehle soweit erläutere:
avisource("hierdateirein.avi")
Videodatei in AVS-Script laden
assumebff()
Avisynth kann die Fieldreihenfolge bei manchem Material erkennen (MPEG2), bei DV klappt das manchmal nicht (abhängig von VfW-Decoder). Mit assumebff() zwinge ich Avisynth das Material als Bottom Field First zu interpretieren.
Turn180()
Das Bild wird um 180° gedreht - ich könnte aber auch zwei Mal hintereinander "TurnLeft()" verwenden (so spare ich mir aber das Tippen).
bob()
Das Material wird in Halbbilder aufgespalten (mit Beachtung der BFF) und dan auf die Auflösung des Ursprungvideos hochskaliert (z.B.: 720x576).
Alternativ kann man übrigens auch separatefields() verwenden - dann wird nicht hochskaliert und man sieht die Halbbilder (inkl. halber Auflösung).
Wie der Turn180() Befehl in Avisynth realisiert wird weiß ich nicht, kann mir aber gut vorstelen, dass jeder Pixel eben um 180° gedreht wird, also "Pixel oben Links" wird zu "Pixel unten rechts" (Avisynth arbeitet normalerweise immer nur mit Vollbildern und braucht bei bestimmten Befehlen zwangsweise ein "interlaced=true" - z.B. bei Farbraumkonvertierungen).
Antwort von soloudmedia:
Versuch doch einfach das source material zu mischen. Wenn Du Streifen kriegts, hat's nicht geklappt. Dann kannst Du immernoch was ändern.
Antwort von WoWu:
Tommy, vielen Dank. Aber ich dachte, die Beobachtung wäre die, gewesen, dass ein Bild -auf dem Kopf- aufgenommen wurde und nun, nachdem es im NLE wieder .auf die Füße- gestellt wurde, also um 180° gedreht wurde, plötzlich eine andere Filed-Order hat, was ein Phänomen wäre.
Daher hatte ich das so verstanden, dass Avisynth diese "verdrehte" Field-Order vorgelegt hätte.
Aber nun verstehe ich das Scrips so, dass es damit nur gedreht wurde und eigentlich nichts über die vorliegende Field-Order aussagt ?
Antwort von tommyb:
Naja... bei 576 Zeilen würde Zeile Nr. 2 zum ersten Halbbild, Zeile Nr. 1 zum zweiten Halbbild gehören. Zeile 3 wiederum zum ersten HB, Zeile 4 zum zweiten.
Zeile 576 würde entsprechend auch zum ersten Halbbild dazugehören, Zeile 575 zum zweiten.
Drehe ich das ganze nun um, befindet sich Zeile Nr. 576 an Position 1. Behalte ich jedoch mein altes Auslesemuster bei, wird die neue Zeile Nr.1, ehemals 576, nicht mehr dem ersten Halbbild zugeordnet sondern ab sofort dem zweiten.
Der Fehler an sich ensteht also nur durch die falsche Interpretation.
Wenn ich diesen Vorgang in Vegas durchführe, dann interpretiert Vegas das richtig und es ruckelt nicht - funktioniert aber nur, wenn das Material auch korrekt als Interlaced erkannt wurde.
Wenn ich hingegen das Material in den Eigenschaften als progressiv kennzeichne, am Ende aber den Film "interlaced" exportiere (d.h. richtig Scheisse baue), dann funktioniert es natürlich nicht - aber das ist eigentlich auch verständlich.
Das letzte Mal wo ich ein ziemlich derbes Problem mit Halbbildreihenfolgen hatte war AVID, allerdings noch der Xpress Pro in Version 5.6.4. Dabei wurde ein DV-Projekt mit BFF angelegt und unter anderem MPEG2 Material eingelesen (inkl. der eigentlich richtig Halbbildreihenfolgen-Kennzeichnung beim Import - also TFF). AVID hat diese Angabe jedoch einfach mal so ignoriert und übelste Ruckeleie ausgespuckt an Stellen wo Effekte (z.B. einfache Blenden) verwendet wurden.
Effekte waren BFF, das Videomaterial welches "darunter" lag TFF. Total crazy.
Dennoch bleibt es wohl dabei, dass wenn ich Bilder habe die "auf dem Kopf" gefilmt wurden und ich diese in einem anderen Programm umdrehe als mein Schnittprogramm - die Fieldorder sich wohl umkehrt, aus BFF DV also TFF DV wird.
