Halbbildfolgen-Problem bei Cinergy 600TV

[Matsch]

Nachdem ich meine Versuche mit der Lifeview 3000 abgebrochen und die Karte zurückgegeben habe (das bekannte Soundproblem, starkes Helligkeitsflackern beim Capturen analoger Videos sowie diverse Konfigurationsprobleme) suchte ich nach einer anderen Karte mit Philips-Chip. Also habe ich mir die Cinergy 600 gekauft - und siehe da, all die bekannten Probleme treten damit nicht auf. Dafür aber, wie auch schon bei der Lifeview, ein ebenso unangenehmes Problem, wofür ich keine Lösung finde. Eine Mail an die Hotline war bis jetzt zwecklos. Schon nach 1 Woche (!) erhielt ich die Bestätigung, daß meine Anfrage nunmehr eingegangen sei. Eine Antwort habe ich auch nach 2 Wochen noch nicht erhalten. Zum Problem:

Völlig gleichgültig vom verwendeten Video-Encoder weisen AVI-Dateien ein falsche Halbbildfolge auf (Topfirst statt bottomfirst). Auf dem PC ist das nicht zu sehen, das Bild scheint richtig gut und scharf. Doch beim Überspielen auf einen Recorder macht sich die falsche Halbbildfolge an dem bekannten horizontalen Ruckeln bemerkbar. Nun kann man ja die Halbbildfolge tauschen, z.B. mit Ulead Media Studio. Das Ruckeln ist dann auch weg, nur ist das Bild spürbar unschärfer. Betrachtet man sich die Bildfolge einzeln Bild für Bild am Camcorder (der dabei Halbbildschritte macht), wird sichtbar, daß offensichtlich noch immer nicht die richtige Halbbildfolge besteht. Beide Halbbilder zucken immer noch geringfügig abwechselnd hin und her. Für mich ergibt sich der schwere Verdacht, daß die beiden Halbbilder nicht aus einem einzigen Vollbild stammen, sondern idiotischerweise aus je einem Halbbild des aktuellen und einem des nachfolgenden Bildes. Sichtbar wird dieser Verdacht auch in Zwischenbildern beim Szenenwechsel, die regelmäßig vorhanden sind und tatsächlich aus je einem Halbbild der alten und einem der neuen Szene besteht.
Ich habe in diesem Forum noch keinen Hinweis auf dieses Problem gefunden. Nutzen den Cindergy-Besitzer die gecapturten Files nur am PC? Ist das Halbbildproblem noch niemandem aufgefallen.
Übrigens habe ich das Problem sowohl unter Win98SE als auch unter Win2000.

[Kika]

Zunächst mal: Bei analogen Aufnahmen ist TFF richtig, nicht BFF. Also stimmt das alles.

Überspielen auf einen Rekorder: Womit machst Du das? Via TV-Out einer Grafikkarte? Da können die meisten Karten nach wie vor nicht richtig mit interlaced Video umgehen.

[Matsch]

Also, meine Anordnung sah so aus:
- Capturen mit VirtualVCR oder VirtualDub (keine Unterschiede im Ergebnis), erzeugen eines DV-AVI-Files (Mainconcept Codec)
- Einfügen der AVI unter Media Studio, Feldoption auf Feld-Reihenfolge A eingestellt
- Erstellen eines Videofiles als DV-AVI DV-Codec Typ1, Feldreihenfolge A. Das Ergebnis (betrachtet z.B. auf Media Player) sieht genauso gut aus wie das Original, sehr gute Schärfe.
- Exportieren der Datei auf einen DV-Camcorder. Bereits beim Überspielen sieht man, daß die Schärfe zwar ausgezeichnet ist, aber heftiges Ruckeln bei horizontalen Bewegungen auftritt.

Gegenversuch:
- vor dem Erstellen der Videodatei die Feldeigenschaft des Clips auf B einstellen, weiter wie oben: Bewegungen laufen jetzt fließend, kein Ruckeln mehr, jedoch ist das Bild deutlich unschärfer.
Betrachtet man sich dann die Aufnahme auf der Kamera im Einzelschrittbetrieb (wobei zumindest meine Panasonic immer nur Halbbildschritte macht), sieht man, daß die aufeinanderfolgenden Halbbilder noch immer keinen korrekten stetigen Bewegungsfluß aufweisen, sondern immer noch leicht hin und her zappeln. Irgendwie scheint die Halbbildfolge immer noch falsch zu sein.

Wie kommst Du überhaupt auf TFF bei analog? PAL ist doch m.W. immer BFF, also 2. Halbbild zuerst?

Wenn die Karte z.B. zuerst das 1. Halbbild einspeichert und nach dem 2. Halbbild (in der Annahme, jetzt liege das Vollbild vor) die Weiterleitung in das AVI-File macht, dann aber korrekt das 2. Halbbild zuerst, besteht das dort abgelagerte Vollbild aus dem 2. Halbbild des Folgebildes und dem 1. Halbbild des vorhergehenden Bildes. Dann würde genau der beobachtete Effekt auftreten, da dann das eigentlich zeitlich vor dem 1. Halbbild liegende 2. Halbbild plötzlich einen Teil des Folgebildes enthält, also ein zeitlich späteres Bild.

[Matsch]

Nachtrag:
1. Ich habe mich nochmal belesen: Bei PAL werden immer zuerst alle geraden (bottom), danach die ungeraden (top) Zeilen übertragen, also auf jeden Fall BFF. Ich gebe zu, daß an einigen Stellen im Internet was anderes steht.

2. Meine letzte Antwort war nicht eindeutig, die Bezeichnungen 1. und 2. Halbbild sind nicht korrekt und eher irreführend. Gemeint war mit dem ersten Halbbild das Topfield, also die ungeraden Zeilen - die eben als 2. Halbbild übertragen werden - und umgekehrt.

Daher zum besseren Verständnis den betreffenden Abschnitt nochmal übersetzt:

"Wenn die Karte z.B. zuerst das ungerade Halbbild (Topfield) einspeichert und nach dem geraden Halbbild (Bottomfield) - in der Annahme, jetzt liege das Vollbild vor - die Weiterleitung in das AVI-File macht, dann aber korrekt das gerade Halbbild zuerst, besteht das dort abgelagerte Vollbild aus dem geraden Halbbild des Folgebildes und dem ungeraden Halbbild des vorhergehenden Bildes. Dann würde genau der beobachtete Effekt auftreten, da dann das eigentlich zeitlich vor dem ungeraden Halbbild liegende gerade Halbbild plötzlich einen Teil des Folgebildes enthält, also ein zeitlich späteres Bild."

[orchidee]

Wenn du mit einem DV-Codec anolog aufnimmst und am Ende tff rauskommt, so ist das schon schlecht (Ebenso, wenn du mit einem anderen Codec aufnimmst und dann nach DV wandelst).
Du mußt also mit dem smart deinterlacer für Vdub oder per avisynth-script nach bff umwandeln, und zwar so, daß das 1.Halbbild verworfen wird. Wie das geht, ist hier vom "Karl" schon mehrfach beschrieben worden.

[Kika]

@Matsch

Was Du über die ÜBERTRAGUNG von PAL schreibst, ist richtig, hier geht's aber um das ENCODEN von Videos und darum, wie Hard- und Software damit umgehen bzw. was die einzelnen Hersteller für eine Meinung darüber haben, was denn nun ein Top-, Even, oder Upper-Field überhaupt ist.

In den allermeisten Fällen ist es so, dass AV Top Field First hat, DV aber Bottom Field First - Ausnahmen bestätigen die Regel...

Wenn Deine Karte von AV also wirklich TFF aufnimmt - und davon gehe ich aus -, Du daraus dann aber ein DV-Video machst, musst Du die Field Dominanz umkehren, sonst führt das immer zu diesen Rucklern.

[Matsch]

Leute, danke für die Hinweise.

Z.Z. verfolge ich noch eine andere Spur. Es ist m.E. eben nicht eine einfache Vertauschung der Halbbilder innerhalb eines Vollbildes (das läßt sich ja einfach korrigieren), sondern die gespeicherten Vollbilder bestehen anscheinend aus je einem Halbbild des vorhergehenden und einem des nachfolgenden Halbbildes (beim Szenenwechsel deutlich zu sehen). Anscheinend wird DOCH die Halbbildfolge BFF im erzeugten File eingehalten, nur daß das erste (even) Halbbild bereits aus dem nächsten Vollbild stammt. Daher ist auch keinerlei befriedigende Korrektur möglich.

Wie kann eigentlich der PC beim Capturen die Halbbilder korrekt unterscheiden und zuordnen? Doch nur durch Auszählen der Zeilenimpulse, synchronisiert durch den Bildimpuls. Was aber nun, wenn die Lage des Bildimpulses zum 1. Zeilenimpuls nicht sauber ist oder schwankt - oder noch schlimmer - ein Zeilenimpuls beim Zählen gar nicht erkannt wird? Dann werden doch wohl auch die Halbbilder vertauscht interpretiert werden (je nachdem, ob eine geradzahlige oder ungeradzahlige Differenz entsteht). Und beim Abspielen eines Analogbandes ist nicht unbedingt von astreinen Synchronimpulsen auszugehen, immerhin kann ich am TV zeitweise ein geringfügiges vertikales Zittern des Bildes beobachten (analoges Signal des Originals).

Da an manchen (meist zusammenhängenden) Stellen im gecapture-ten File KEINE Fehlbilder beim Szenenwechsel entstehen, will ich jetzt untersuchen, ob in diesen Szenen auch diese Ruckler auftreten oder nicht. Wenn meine o.g. Theorie zutrifft, kann es doch sein, daß sich die TV-Karte im Falle von dropped frames versucht neu zu synchronisieren und manchmal interpretiert sie eben die Halbbilder richtig, mal falsch, je nach Zustand der Sync-Impulse (und der mehr oder weniger gut ausgeprägten Eigenschaft von Hard- und Software, mit unsauberen Sync-Impulsen umgehen zu können).
Wenn es an unsauberen Impulsen liegen sollte, weiß ich dann auch keine Lösung mehr.

Ich will mich jetzt mal ranmachen und einen Videofilter zu MSP programmieren, der aus je einem Halbbild des letzten und des nächsten Vollbildes ein Vollbild zusammensetzt. Ist diese Aktion erfolgreich, wäre das zumindest der Beweis dafür, daß tatsächlich das neue Vollbild aus 2 ehemaligen Vollbildern erzeugt wird, also die Halbbilder falsch interpretiert wurden.

Außerdem werde ich nochmal Versuche machen mit analogen Eingangssignalen direkt aus einem TV-Ausgang, dabei sollten doch wohl keine Sync-Probleme auftreten. Mal sehen, ob das Ergebnis dabei anders aussieht.

[bergH]

tach auch !

Den Auffwand kannst Du Dir sparen, solche Filter gibt es für Virtual Dub.
Der Smart De-interlacer hat alleEinsetllungen, die man braucht.
Field-swap, phase-shift  und und und.

Links sind in der Linksammlung

Frag mich jetzt bloß nicht, was das alles bedeutet,. INterlace werde ich im Leben nicht begreifen (wollen)
_________________
Gruß BergH

[Kika]

Ein einzelnes Field kann man ganz leicht mit AVISynth wegwerfen, damit das wieder stimmt:

SeparateFields()
Trim(1,0).Weave

[Der Karl]

Für tff-source aber erst:

ComplementParity()


bzw. so:

ComplementParity()
DoubleWeave().SelectOdd()


Gruß Karl

[Matsch]

Dank an bergH und Kika,

ich habe mich bisher weder mit VirtualDub noch mit AVISynth allzu tiefgründig befaßt, da ich für die DV-Bearbeitung kaum was anderes als MSP gebraucht habe (wurde erst mit der Absicht des Digitalisierens analoger Videos interessant). Daher könnten Eure Hinweise sehr wertvoll sein (Smart deinterlacer klingt eigentlich mehr nach Wandlung in progressiv, daher habe ich diesen Filter bisher nicht beachtet).
Werde mich also nochmal mit all den neuen Gedanken ans Testen machen, kann aber 'ne Weile dauern.

[bergH]

tach auch !

Klar ist der de-interlacer für die Wandlung nach progressiv.
Was man bei ECHTEM Interlace nicht machen sollte.
Aber die "Pre-Processing" Filter.
Field Swap, Phase Shift etc. helfen auch bei der Suche nach Fehlern.
So und nicht anders war der Tipp gemeint.
_________________
Gruß BergH

[orchidee]

@Matsch
Nochmal zum Problem die ursprünglich progressive Ordnung der Frames wieder herzustellen. Wenn du den Fall hast, daß an verschiedenen Szenenwechseln die Anordnung mal stimmt und mal nicht, so kann das verschiedene Ursachen haben.
1. Capture-Karte erzeugt phase shifts - andere Treiber probieren, sowie anderen Farbraum beim capturen, sonst-> in die Tonne mit der Karte
2. Der Effekt ist schon im Ausgangsmaterial so vorhanden (wohl durch eigenartige NTSC-PAL oder Film-PAL-Konvertierungen bedingt) - da hilft nur behandeln wie echtes interlaced Material (es spielt keine Rolle, daß die Paarigkeit der Halbbilder manchmal nicht stimmt, da sie zeitlich richtig ausgespielt werden)

[Gunnar]

Immer wieder ist zu lesen das bei einigen Usern die TV-Karte\Treiber Kombi "phase shifts", "field swaps" oder weiß der Deibel was erzeugt. Leute wie schafft ihr das ?
Weder mit meiner WinTV noch mit der PCTV-Pro ist das jemals bei mir aufgetreten. Das Gleiche mit der Typhoon, Lifeview und der Cinergy 600 die ich nur noch verwende.

Sorgt mal dafür das euer System nicht vollgemüllt ist, dann klappt´s auch mit dem Capturen.

Gruß Gunnar
_________________
Gruß Gunnar

[Der Karl]

Moin,

>Klar ist der de-interlacer für die Wandlung nach progressiv....

>Aber die "Pre-Processing" Filter.....

Den "Deinterlacer" kann man komplett ausknipsen! Dann ist das Ding auch für eine
(echte !) Änderung der fieldorder gut. MSP und Konserven würde ich da nicht über den Weg trauen.

>Sorgt mal dafür das euer System nicht vollgemüllt ist, dann klappt´s auch mit dem Capturen.

Sag das mal meiner WINTV - die weiß nämlich nix von Deinen Weisheiten

Gruß Karl

[Matsch]

Hallo Leute,

erstmal habe ich einen Teilerfolg.
Daß der Smart Deinterlacer auch interlaced Material erstellen kann, habe ich inzwischen auch herausgefunden. Und tatsächlich, nach field swap + phase shift liegt das DV-AVI-File in korrekter Form vor, richtige Bildfolge und immer noch unverändert scharf! Damit steht fest, das Ausgangsmaterial hat, wie bereits angenommen, wirklich die Halbbildfolge b2t1-b3t2-b4t3-...

Bleibt die Frage: Wieso wird so falsch gecapturet? Bin ich hier eigentlich der Einzige, der das Problem hat oder merkt's nur keiner? Das File liegt übrigens bei allen meinen neuen Versuchen IMMER in der inkorrekten Form vor, gleichgültig, ob ich ein externes Signal von Camcorder, VCR oder TV oder das interne Tunersignal capture.

Weiß jemand, ob es einen ähnlichen Filter (field swap, phase shift) für MSP schon gibt? Wäre schon ganz gut, Korrektur und Schnitt in einem Aufwasch zu machen, außerdem sollte ich davon ausgehen können, daß das erzeugte File dann auch MSP-geeignet ist. Wenn nicht bekannt, werde ich mich wohl mal drüber her machen, allerdings nicht mit Zeitdruck, da ist ja immer noch der Ausweich VD...

Mit der Korrektur durch VD habe ich dann aber wieder ein neues Problem, das ich schon an anderer Stelle im Forum gepostet habe:
Beitrag zu Dateigröße VD
Während sich das File (10GB) vor der Behandlung noch tadellos in MSP (6.0, 6.5) verwenden läßt, sind NACH der Transformierung in MSP 6.0 davon nur noch 2GB sichtbar (9:21 min, obwohl die Datei weiterhin 10GB groß ist), MSP6.5 stürzt ab, sowie ich die Datei auf die Timeline ziehe (BS Win2000, NTFS). Viele andere Programme können mit dem erzeugten File aber korrekt umgehen.
Es muß aber an VD liegen, da anders erzeugte große Files (immer gleicher Codec) von beiden MSP-Versionen korrekt verarbeitet werden (siehe auch Link).

Apropos:
>Sorgt mal dafür das euer System nicht vollgemüllt ist, dann klappt´s auch mit dem Capturen.

Mein System ist garantiert noch nicht vollgemüllt, da ich gerade erst vor 3 Monaten von Win98SE auf Win2000 umgestiegen bin und das System daher fast noch jungfräulich ist. Und das Problem hatte ich auch schon bei der Lifeview 3000 unter Win98SE (allerdings liegt es nahe, daß beide denselben Capturetreiber verwenden - cap7134.sys. Möglicherweise einfach nur der Referenztreiber von Philips?).

[Gunnar]

@Matsch

Ich kann deine Probleme einfach nicht nachvollziehen. Habe in 2 völlig verschiedenen Rechnern (WinXP-SP1) 7134-Karten drinn (Cinergy 600 + Typhoon) und die capturen nicht nur nach stundenlanger Aufnahme (Vdub_sync) mit NULL Drops (Canopus DV-Codec) sondern auch ohne deine Fieldschweinereien. Zugegeben, es hat schon einige Mühe gekostet bis die Rechner das machten was sie sollten und auch die Phillipstreiber (cap7134.sys) sind nicht das gelbe vom Ei aber bei richtiger Optimierung (Hardware + Software) läuft´s wie geschmiert.

Kann mich erinnern mal ein Problem mit dem Morgan Codec gehabt zu haben der beim Capturen die Fields vertauscht hatte. Auch hier war die Lösung nicht nur einfach ein neues WinXP zu installieren sondern zusätzlich den ganzen überflüssigen XP-Müll zu deaktivieren oder rauszuschmeißen. Vom grafischen Schnickschnack, überflüssigen Codecs/Filter, Dienste usw. Ich verwende eine eigene primäre Partition für mein Capturesystem + Captureplatte natürlich. Da ist wirklich nur das drauf was unbedingt nötig ist. Die ganze Palette der Videobearbeitung ist seperat untergebracht.

Mit einem entsprechenden Script läuft die Aufnahme per Timer wie bei einem Videorecorder. Das Rohmaterial wird dann mit VD geschnitten, mit Fit2disc (Avisynth) optimiert und dem CCE zum Fraß vorgeworfen. Für auftretende Tonprobleme, für die 7134-Karten bekannt sind wenn kein Delay im Captureprogramm ausgeführt wird, ist im Script ein primitiver Workaround eingebaut.

Ich wiederhole noch mal: WinTV, Pinnacle PCTV-Pro, LifeView, Typhoon und Cinergy 600 liefen/laufen ohne deine genannten Probleme. Und ich bleibe dabei in deinem Rechner hängt der Furz quer, sonst würde es klappen

Es wäre vielleicht auch hilfreich eine genaue Beschreibung deiner Hardware zu haben und in welchen Slots deine Karten stecken, Treiber, IRQ-Verteilung usw. Es gibt so viele verschiedene Möglichkeiten wieso es bei deinem Rechner klemmt.

Gruß Gunnar
_________________
Gruß Gunnar

[Gunnar]

[Matsch]

@Gunnar

Weiß der Deibel, wie Du das machst.

Also:
Prozessor AMD XP 2400, Board EPOX 8RDA mit nForce2-Chipsatz, TV-Karte Cinergy 600TV steckt in einem PCI-Slot mit eigenem Interrupt (muß sich den nicht mit Grafikkarte teilen). Ansonsten steckt nur noch eine Firewire-Karte drin (ebenfalls auf eigenem Interrupt). Treiber für die Karte ist wie bei Dir die Version 1.4.0.0.
Betriebssystem ist Win2000 mit Servicepack 3.

Ansonsten habe ich auch für die Videoprojekte eine eigene Festplatte drin, die NICHT mit der Systemplatte an einem Port hängt (7200/min, gemessene lineare Übertragung ca. 25 MB/s). Ich habe auch beim Capturen von externen und internen Tunersignalen keine dropped frames, beim Capturen vom analogen Camcorder allerdings schon. Ich denke aber, das ist normal, da der ja beim Aufzeichnen nach Aus- und Einschalten der Kamera immer eine Teil der bisherigen Aufzeichnung überschreibt und es an solchen Stellen leicht zu Synchronproblemen kommen kann. Hinzu kommen dann noch Störungen durch Bandfehler.

Andere DV-Encoder als den Mainconcept habe ich noch nicht probiert, wohl aber Versuche mit anderen Nicht-DV-Codecs gemacht. Auch dabei stets die Fielddreher und -schieber.

[Matsch]

Vielleicht ist das alles ja nur eine Konfigurationssache. In der Registry hat Terratec z.B. einen Eintrag "Scaler", der einen Wert "Field Sequence" = 4 sowie weitere Parameter möglichweise für die Lage/Abstand der Syncronimpulse enthält. Doch woher soll man wissen, was die bedeuten?
Ich habe den Parameter Field sequence probeweise mal von 1...5 durchprobiert, jedoch ohne eine Änderung meines Problems. Dabei habe ich festgestellt, daß die anderen Parameter offensichtlich bei Nutzung ständig aktualisiert und eigene Änderungen dann wieder überschrieben werden.