manuelle Ermittlung d. Field Order?

[Fido]

Hallo Leute,

Wie bekomme ich die richtige Field Order raus ohne den TMPGEnc Wizard zu benutzen?

Gruß Fido

[vegas]

Hi,

wenn Du für TV oder VHS Aufnahmen Field Order A und für DV-Material Field Order B nimmst passt das meistens schon. Falls nicht, hilft meines Wissens nur Ausprobieren (gibt ja nur 2 Möglichkeiten).
_________________
Vincent Vegas,

Typenschild:
Windows ME, Pentium III 800, Premiere 6, TMPGEnc 2.54, VCDEasy 1.1.2, Player: Cyberhome AD-L528

[Fido]

Hi vegas,

Hmm.., dann ist interlaced also immer A und progressive immer B! Ist das korrekt wenn ich mir das so merke?

Gruß Fido

[shh]

Nein, leider nicht.
Das ist ein wildes Kuddelmuddel und von Programm zu Programm verschieden.
Auch hat die field-oder absolut *nichts* mit der Art des Films, ob interlaced oder progressive, zu tun. Theoretisch könnte man ja alles mögliche mixen.

Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Fido]

Hi ssh,

ich hab in der c't einen Artikel über die Erstellung von SVCD gelesen, und die schrieben dazu leider nur das man die Field Order des Materials vor dem encoden schon kennen sollte, ohne näher darauf einzugehen wie man diese denn eigentlich ermittelt. Bei Benutzung des Wizard's erfolgt ja anscheinend eine Prüfung, die man ja manuell nicht starten kann. Hab ich zumindest nicht gefunden. Somit weiß ich nie was ich da eingeben soll! Ich dachte es gibt vielleicht ein Tool welches das Material vorher scannen tut.

Gruß Fido

[mb1]

In Tmpeg allein geht es leider nicht manuell.

Hier mal eine Möglichkeit, die Tsunami vor einigen Tagen gepostet hat:

[shh]

Ja, ich kenne den Artikel.
Die haben das wohl bewußt weggelassen (lieber garnichts schreiben, bevor man was falsches schreibt... ;))

Leider gibts keine automatische [sichere] Prüfmethode!

Manuelle Methode:
[gibts keine Interlacing-Kämme ist die field-order egal]
- Bild in VirtualDub laden und sich eine Bewegung anschauen. (zB ein Auto, das sich von links nach rechts geht)
- Die Kämmspitzen von dem Auto, die weiter rechts sind, kommen logischerweise später. Sind solche Kämme auf ungeraden Zeilen (1,3,5,...), ist das Video bottom field first (= bff), weil ja die geraden Zeilen (2,4,6,...) zuerst kommen.

Ach ja, dann muß man noch hoffen, daß man auch "ordentliches" Video vor der Nase hat. Also keins mit field-swaps, field-shifts usw. wie es zT Premiere schickt.

Material von der DV-Cam kommt immer in bff daher.
Gecaptured wird meistens in tff.
Warnung: Beim capturen wird oftmals ein field verschluckt (ganz besonders, wenn bei einigen Karten in YUY2 gecaptured wird). Dann hat man nahezu unbrauchbares Material, was sich nur noch durch intelligente deinterlacer (decomb etc.) richten läßt.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Fido]

hmm..., oder man läßt halt vorher doch einfach mal den Wizard scannen und schaut was der dazu sagt!

Na, gut dann erstmal Danke für die Info's.

Gruß Fido

[mb1]

Der Wizard macht es aber _nicht immer_ richtig.
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[Fido]

Oh mann..., ich sehe schon! Im Endeffekt helfen nur Gebete  

[Tsunami]

1.
Leider beginnt eine 'Hauppauge WinTV FM' mit irgendeinem Field, man kann also nicht pauschal sagen, das ein digitalisiertes Video immer eine tff-Field-Order hat.

2.
Wenn man 'YUY2 (YUV 4:2:2)' beim digitalisieren einstellt, dann kann während der Aufnahme mehrmals ein Phase-Shift auftreten.
Wenn man das nicht beachtet bzw. nicht repariert, dann sieht man auf einem Standalone Ruckler und Zuckungen
(Bei mir tritt so ein Phase-Shift ca. alle 10 Minuten auf).

3. Ich habe mittlerweile eine Methode gefunden, wie man mit Hilfe von verketteten Avisynth-Scripten mehrerer solcher Phase-Shifts in einem Rutsch reparieren kann (Werbung wird auch direkt herausgeschnitten).

4. Der TMPGEnc-Wizard kann die Field-Order leider nicht immer korrekt feststellen, daher sollte man auf diese 'automatische' Erkennung am besten ganz verzichten und alles manuell erledigen (mit die Äugen).

5. Wenn man minderwertige Technik einsetzt (WinTV), dann muss man die 'Ersparnis' mit harter Arbeit wieder tausendfach kompensieren (das hat allerdings auch den Vorteil, das man Dinge lernt, die man mit perfekter Technik nie erahnen würde)

_oOÔ_Tsunami_ÔOo_

P.S. Gebete helfen dir mit Sicherheit nicht.
Wenn du weisst was notwendig ist, damit ein Video funktioniert, dann ist Glauben unnötig.

[mb1]

@ Tsunami

Kann es sein, dass dein 3. Punkt nur funktioniert, wenn du weisst, wo sich die Phase Shifts befinden ?
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[Tsunami]

Man muss auf jeden Fall genau wissen, wo diese Phase-Shifts auftreten, automatisch geht das bisher noch nicht (wer das behauptet soll sich bitte melden).
Theoretisch ist auch eine vollautomatische Reparatur möglich, aber wer hat Zeit (und genügend Wissen), um so etwas zu programmieren ?

Zuerst lädt man ein Avisynth-Script in VirtualDub und notiert dich die Field-Nummern, an denen die Ruckler zuerst auftreten bzw. wieder verschwinden, danach erstellt man die verketteten Scripte.
Das genaue Verfahren kann ich demnächst mal posten, wenn es denn jemanden interressiert.

Noch besser wäre es, wenn 'int 21h' mal die Sourcen der Treiber herausrücken würde (damit wir die Bugs beseitigen können), da er ja laut eigener Angabe an der Konstruktion dieser Phase-Shifter-Karte beteiligt war (und leider nur aus Geldgier und nicht wegen der Sache an sich)



Gibt es eigentlich einen VirtualDub-Filter, der die Chroma-Fehler (Blöcke zu ca. 16x2 [SpaltenxZeilen]) der WinTV erkennen und reparieren kann ?

[Der Karl]

Die dynamischen phase-shifts kann man (größtenteils) verhindern, indem man nicht in YUY2,
sondern RGB24 cappt.

Mit welchem field die BT8x8-basierenden Karten anfangen, ist leider nicht vorauszusagen.
Hier hilft nach meinem Wissensstand nur andere Hardware, die das immer richtig macht.

Wenn das Ausgangsmaterial progressive war, muß man die phase-shifts nicht suchen, sondern
läßt einfach GreedyHMA oder Decomb (in AVISynth) bzw. Telecide oder Autopal (in VD) mitlaufen.

Für echtes Zeilensprungmaterial gibts IMHO keine solche Lösung.
Müßte man mal untersuchen, ob irgendein existierender Filter auch damit zurecht kommt.

Nochmal zu den dynamischen phase-shifts: Lt. Unitronic "BT848 Programmer´s Guide" vom 03.11.98
sollte dieses Problem längst gefixt sein. Setzen die Kartenhersteller auf noch ältere
sourcen auf???

---------- Schnipp-------------------------------------------------
Version 1.4.1 Mar 22 1997

This release fixes the following bugs:

5. Interlace error: in 2 field mode (ie. V > 240 for NTSC, V > 288 for PAL) sometimes the driver

would reverse the order of the fields.
---------- Schnapp-------------------------------------------------

Gruß Karl

EDIT: Achja, sourcen für irgendwelche BT-Treiber hab ich.
Wie gut bzw. aktuell - k.A.



Zuletzt bearbeitet von Der Karl am Aug. 01 2002,10:28