Hi zusammen,
Ich versuche gerade herauszufinden ob es sich bei diesem Material um "echtes" Interlaced Video handelt oder um eine Telecine Wandlung von NTSC -> PAL. Dementsprechend würde ich dann QTGMC oder TIVTC verwenden ...
Hier ist ein Schnipsel
Hi zusammen,
Ich versuche gerade herauszufinden ob es sich bei diesem Material um "echtes" Interlaced Video handelt oder um eine Telecine Wandlung von NTSC -> PAL. Dementsprechend würde ich dann QTGMC oder TIVTC verwenden ...
Hier ist ein Schnipsel
PAL (25 fps) kann keinesfalls "herkömmliches" Telecine (3:2-Pulldown) haben; dieser Trick funktioniert nur zwischen Film (24 fps) und NTSC (~30 fps) wegen des 4:5-Verhältnisses.
Um zu erforschen, ob Telecine oder Interlacing vorliegt, schau dir den Clip mit einem Bobber an. Wurde schon dutzendfach dokumentiert: Bei echtem Interlacing und korrekter Halbbildreihenfolge wird man nach dem Bobben eine fortlaufende Bewegung sehen, weil ja die Halbbilder bei Interlaced-Aufzeichnung auch zu fortlaufenden Zeitpunkten aufgenommen wurden. Telecine dagegen vervielfacht in regelmäßigen Mustern ein Halbbild von ehemals progressivem Video, da wirst du mal zwei, mal drei gleiche Inhalte sehen. Siehst du Vor-Zurück-Bewegungen, war die Halbbildreihenfolge falsch herum.
Hm, ok so wie's ausschaut it's wohl echtes Interlaced, obwohl ich dem Ganzen nicht so ganz traue ...
Zitatobwohl ich dem Ganzen nicht so ganz traue ...
Warum?
Wei es "eigentlich" eine Konvertierung NTSC -> PAL sein sollte
Soweit es den geposteten Videoschnipsel betrifft - der ist nicht blend-konvertiert, und in gewissem Sinne auch nicht "richtig", sondern eher "falsch interlaced". Sprich: Phase-shifted progressive.
Wenn es durchgängig so ist wie im Sample, dann könnte man mit "separatefields().trim(1,0).weave()" die verteilten Halbbilder wieder zu Vollbildern kombinieren.
In vielen Fällen kann man der Sache aber nicht so recht trauen, oft hat man einen "dynamischen" Phase-Shift, d.h. es wechselt zwischen Sequenzen [mit] und [ohne] Phase-Shift. Und statt alles von Hand abzusuchen und abschnittsweise zu korrigieren, ist ein automatischer Field-Matcher wesentlich bequemer: TFM() aus der TIVTC.dll.
kannst ja mal gucken, ob TFM(clip2=QTGMC()) schöner aussieht,..
Möglich, aber wenn schon QTGMC, warum dann überhaupt noch TFM? Dann könnte man doch auch gleich QTGMC().SelectEven() ...
Ooooder ... TFM(slow=2,pp=0).Vinverse()
@ Didée: Ja, das ist schon echt besser ... jetzt muß ich mich nur noch um's Rauschen und Schärfen kümmern ;D
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!