Fieldorder changes und kein Ende !

[getty]

Hallo zusammen

Ich hab da mal ne Frage bezgl. Fieldorder:

Ich mache analog captures via WinTV vom eingebauten Tuner. Es läuft Alles einwandfrei, das .avi ist ok, zumindest am Monitor :-)

Nach der Umwandlung nach SVCD (Standard), muss ich am TV feststellen, dass der TV-Sender, vermutlich bewusst, immer an denselben Stellen die Fieldorder ändert. Das Resultat ist also als Gesamtes nicht brauchbar :-(. Ändern der Fieldorder beim transcoden bringt deshalb auch nichts.

Hmm...was tun ?

Die Übergänge am Monitor finden, wie ? Und selbst wenn das sauber zu eruieren wäre, müsste dann das .avi in x-clips zerlegt werden mit verschiedenen Orders nach mpeg2 codiert werden und anschliessend, vermutlich mit unsauberen Übergängen gemerged werden. Eine wie mir scheint nicht praktiable Lösung.

Ich hab mal mit einem Tool "pulldown.exe" probiert im Nachhinein dem "ganzen" mpv File eine neue, unique Fieldorder zu verpassen, leider ohne Erfolg.

Oder sollte ich etwa, um Fieldorder-Probleme zu vermeiden, gleich auf das eine Field verzichten :-( ?

Hab hier und da schon gesucht, konnte aber bis jetzt keinen Thread finden, der genau dieses Problem behandelt. Nicht böse sein, wenn ich was übersehen habe.

Besten Dank für Euren Input.

[Der Karl]

Bist Du sicher, daß es der Sender ist?
Welcher Sender?
Nimmst Du mit der TV-Karte in YUY2 oder RGB24 auf?
Sind die betreffenden Filme evtl durch PAN&Scan gelaufen?
Sind es wirklich nachvollziehbar immer die gleichen Stellen?
(VCR mitlaufen lassen und versuchshalber diese Stellen nochmal aufnehmen)
Benutzt Du Virtual Dub?

Gruß Karl

[getty]

Hi Karl

Ich bin mir ziemlich sicher, dass es der Sender ist, weil dieselbe Sendung (Wiederholung) an genau denselben Stellen die Swaps beinhaltet. Typisch auch jedesmal der Change nach dem Vorspann und leider auch ein Change während der eigentlichen Sendung.

Die Aufnahme habe ich mit VD 1.4.10 bzw. auch mit der sync Version gemacht. Codec ist Huffyuv 2.1.1 (<-- convert to YUY2) in Virtualdub custom format 480 x 576 und auch da YUY2. Keine "Realtime" Filter beim Aufnehmen. Transcodiert mit TMPGenc 2.54a, Versuch mit CCE 2.50 führt zum exakt selben Ergebnis bzgl. Fieldorder.

VCR (Non S-VHS) mitlaufen lassen ? Ja, nach den ersten missglückten Versuchen. Wäre dann ein capturing mit nur einem field via WinTV nicht die qualitativ bessere Lösung ?, obwohl der VCR produziert überzeugende Bilder am TV, wenn man bedenkt mit welcher Auflösung da gearbeitet wird, dagegen sieht eine VCD (standard) mit ihrer niedrigen Bitrate ziemlich übel aus.

Gruss

[mb1]

[getty]

Hi mb1

Ok, hast Recht, bestimmt ist's der Film :-)

Das Signal, das bei mir ankommt ändert sich aber dadurch nicht...........



Gruss

[Der Karl]

Nun denn,

>Codec ist Huffyuv 2.1.1 (<-- convert to YUY2) in Virtualdub custom format 480 x 576 und auch da YUY2..

Wieso das? (<-- convert to YUY2)??  YUY2 rein -> YUY2 raus!
Meine Frage bzgl. YUY2 vs. RGB24 zielte dahin, daß BT-Karten gern selbst Fieldswaps produzieren.
Und zwar bei YUY2 - bei RGB24 nicht. Treiberfehler!

>dieselbe Sendung (Wiederholung) an genau denselben Stellen die Swaps beinhaltet.

Deutet auf Sender _oder_ Quelle.

>Warum sollte es dann der Sender sein.
>Eigentlich ist es immer der Film selbst !

Das ist durchaus nicht eindeutig. Z.B. PRO7 produziert aus sauberem Ursprungsmaterial regelmäßig
phase-shifts und zwar wahrscheinlich mit ihren PAN&Scan-"Maschinen" - meine Erfahrung.
Das waren aber immer phase-shifts, keine Field-swaps. Keine Ahnung, wie sich das aufs MPEG2-encoding
auswirkt.

Der _FILM_ selbst könnte ohnehin solche Fehler nicht bewirken *g*

Trotzdem ist die Geschichte rätselhaft. Wäre es wirklich ein Fieldorderfehler, müßte das auf dem
TV auch schon zu sehen sein.
Ich tippe auf dynamische phase-shifts.

Probier mal Folgendes:

In VD den "Telecide" von Donald Graft oder den "Autopal" von Simon Walters (evtl. mit
vorgeschaltetem "Deinterlace PAL movie" von Gunnar Thalin - vor den Autopal).
Diese Filter jeweils als ERSTE!
Schmutzige Stelle encoden und schaun ob der Fehler weg ist.

Ist leider immer schwer vorauszusagen, wie die Filter mit dem analogen Material klarkommen.

Source ist doch Kinofilm, also ursprünglich progressive? Oder?

Man könnte das auch in AVISynth mit GreedyHMA oder Decomb versuchen.

Erzähl dann mal, was rausgekommen ist.

Gruß Karl

EDIT: Vergessen. Nur ein Field aufzunehmen bei analogem Material ist IMHO qualitataiv völlig inakzeptabel.



Zuletzt bearbeitet von Der Karl am Mai. 28 2002,22:16

[Kika]

@Karl

> Das waren aber immer phase-shifts, keine Field-swaps. Keine Ahnung, wie sich das aufs MPEG2-encoding
auswirkt.

Solange man interlaced encodet spielt das keinerlei Rolle.
Ich habe das in mehreren Fällen ausprobiert. Z.B. bei einer Serie, die eigentlich progressive ausgestrahlt wurde, an Schnittstellen aber plötzlich Phase Shifts hatte.
Generelles Deinterlacen wurde mir zu unscharf, der Aufwand, die Phase Shifts zu beseitigen war mir zu hoch. Also hab' ich's interlaced encodet, was prima funktionierte, da ich bei sowas beim Maximum eh mit sehr hohen Bitraten arbeite.

[Der Karl]

@Kika

Stellt sich natürlich die Frage, _wie_ enodet wurde.
Das scheint bei MPEG2 generell problematischer als bei MPEG4 zu sein.
Kuhbaert fragte mich letzte Woche was ähnliches, da konnte ich aber nur raten.

Wäre sicher interessant, das grundsätzlich zu klären.

Woran liegts?

Gruß Karl

[Kika]

@Karl

Hm? Verstehe ich jetzt nicht ganz, was Du meinst.
Bei MPEG4 hast Du ja eh keine Wahl und musst deinterlacen. Bei MPEG2 zwingt Dich (außer vielleicht die Bitrate) ja niemand dazu.

Ansonsten hast Du fast freie Auswahl. Du kannst jederzeit auch progressive Video interlaced encoden, nur rumgedreht, das funktioniert natürlich nicht.
Ist natürlich nicht optimal, eigentlich progressives Material interlaced auf CD zu bannen, aber bevor ich mir die Qualität ganz versaue...

Wichtig ist halt, dass man den Encoder dazu richtig einstellt. Bei TMPGEnc ist das in den meisten Fällen dann eben Top Field First (A), bei CCE die Upper Field First Option dazu ausschalten.

[Der Karl]

@Kika

>Bei MPEG4 hast Du ja eh keine Wahl und musst deinterlacen. Bei MPEG2 zwingt Dich (außer vielleicht die Bitrate) ja niemand dazu..

Wie so häufig, verstehen wir uns "miß"...
Daß man MPEG4 progressive encoden muß, weiß ich schon ;-)
Du weißt auch, daß ich das weiß.

Was die "Fehler" betrifft, kann ich sie nur bei MPEG4-encoding eindeutig zuordnen -
die Besonderheiten von MPEG2 kenne ich nur vom lesen.

Insofern wäre ein grundsätzliches Verständnis schon nicht verkehrt.

Jetzt gehts aber ins Bett.

Gruß Karl



Zuletzt bearbeitet von Der Karl am Mai. 29 2002,00:35

[getty]

@Karl

Erst mal Danke für Deine Vorschläge !


BT-Karten und Fieldswaps wegen Treibern, hab schon davon gelesen, dachte aber bisher, dass dies nur zu Beginn der Aufnahme auftreten kann und dann die Order beibehalten wird, damit hätte ich keine Probleme....oder ist es etwa viel schlimmer und diese tolle Software macht das intermittierend ?!
Trifft dies übrigens auch auf PicVideo zu, wenn man YUY2 forced ?

Ob's nun der Sender bei der Ausstrahlung oder bei der Verarbeitung des Videomaterials (?) vermurkst hat, kann ich nicht nachvollziehen, ich muss nun mal mit dem empfangenen Signal zurande kommen.....Aber dazu noch was: ich hab keine dropped frames, zumindest zeigt das VD so an. Könnte es sein, dass VD dropped ohne dieses zu "bemerken" und dadurch ein fo-problem oder ein phase-shift problem auftritt, weil es vergisst den ganzen frame zu droppen ? Gibt es ein anderes Capturing Program, dass absolut zuverlässig ist und auch avi (opendml) erzeugen kann ?

Also es handelt sich nicht um einen "Kinofilm" es ist eine TV-Serie (keine NTSC source), also vermutlich original interlaced.
Auf dem TV ist das Bild bei der "Live" Sendung einwandfrei, der Tuner macht das schon :-) und zwar über die gesamte Länge der Sendung.

Ich glaube zwar kaum, dass es sich um phase-shifts handelt, da nach dem encodieren der entsprechenden parts mit der "richtigen" fo alles einwandfrei aussieht. Das Ganze ist wirklich nicht "zufällig" durch Signalprobleme oder sonstwas entstanden.

Also ich habe Deine Vorschläge zum Filtern mal durchprobiert - Resultat: NUR deinterlacing (oh graus !) scheint das Problem beseitigen zu können.

Also im Moment scheint es so, dass ich die bereits aufgenommenen avi doch tatsächlich durch den de-interlace fleischwolf pressen muss, aber wenigstens kann man das Resultat dann ansehen, bei fo-probs ist das unmöglich. Schade, schade.........

Aber was kann ich in Zukunft tun, wie nehme ich am besten auf, um ein nachträgliches de-interlacing zu verhindern ? Würde mich echt interessieren, ob's da einen Weg gibt, die ganzen phase-shifts und fieldorder problematiken zum vornherein zu "entschärfen", ohne studio-equipment versteht sich :-)).......Hab da auch noch ein paar "unkonventionelle" Ideen, die ich erst ausprobieren muss......


Gruss

[ANDREAS]

[Kika]

@Karl

> Daß man MPEG4 progressive encoden muß, weiß ich schon
> Du weißt auch, daß ich das weiß.

Sicher weiß ich das, ich versuche bei meinen Postings aber gelegentlich, auch an die stummen Mitleser zu denken, und die kapieren das ganze ja nicht, wenn wir Dinge, die für uns selbstverständlich sind, einfach unter den Tisch fallen lassen.

> die Besonderheiten von MPEG2 kenne ich nur vom lesen

OK, das ist natürlich zu wenig, um dann wirklich was sagen zu können. Die Theorie ist zwar schön und gut, aber gerade bei MPEG2 geht es ohne praktische Versuche absolut nicht.
Probier's einfach mal aus, MPEG2 ist schon ziemlich faszinierend ;)

@getty

> BT-Karten und Fieldswaps wegen Treibern, hab schon davon gelesen, dachte aber bisher, dass dies nur zu Beginn der Aufnahme auftreten kann

Nun, zumindest bei mir war das auch immer so. Es gibt aber massenhaft (glaubhafte) Berichte von Leuten, die sagen, dass sich das bei ihnen auch schon mal während der Aufnahme geändert hat.

> Könnte es sein, dass VD dropped ohne dieses zu "bemerken"

Ja und nein. Wenn VirtualDub droppt, dann meldet er das auch. Wenn die Karte aber selbst ein Field oder einen Frame verliert, dann muss das nicht unbedingt gemeldet werden.

> Ich glaube zwar kaum, dass es sich um phase-shifts handelt, da nach dem encodieren der entsprechenden parts mit der "richtigen" fo alles einwandfrei aussieht.

Dann sind es aber wahrscheinlich Phase Shifts. Wenn es ein Field Swap oder eine falsche Field Order wäre, würdest Du das SEHR deutlich sehen können.
Die Field Order kann sich beim Senden nicht ändern, das würdest Du schon auf dem TV deutlich sehen, ebenso eine Änderung der Field-Anordnung (Field Swap). Ausschließlich Phase Shifts fallen nicht auf. Beziehungsweise, sie fallen nur dann auf, wenn man genau weiß, worauf man zu achten hat. In dem Moment, in dem vom Sender aus ein Phase Shift kommt, springt das Bild ganz leicht.

[Der Karl]

EDIT: Das hat sich jetzt mit Kika überschnitten. Ich sehe aber, daß wir einer Meinung sind - ausnahmsweise ;)


@Getty

>hab schon davon gelesen, dachte aber bisher, dass dies nur zu Beginn der Aufnahme auftreten kann und
>dann die Order beibehalten wird.....

Nein, wenn Du YUY2 cappst, _kann_ das völlig zufällig während der Aufnahme hin- und herwechseln -
frag mal Kika ;-)
Mein Tip: Wenn Du die resourcen hast, in RGB24 cappen und die RGB/YUV-Wandlung in Software in Kauf
nehmen.

>Trifft dies übrigens auch auf PicVideo zu, wenn man YUY2 forced ?

Keine Ahnung. Kann ich nicht testen. Bei mir klappt das "force YUY2" gar nicht.
Du könnstest versuchen, mit Huffyuv in RGB24 zu cappen, aber "<-- Convert to YUY2" auswählen.

>ich hab keine dropped frames, zumindest zeigt das VD so an.
>Könnte es sein, dass VD dropped ohne dieses zu "bemerken" ...

VD ist mit sehr großer Wahrscheinlichkeit unschuldig. Wenn das Zeug schon schmutzig vom Sender kommt,
kriegt man das ohnehin nicht mit. Wenn der Capture-Treiber Mist macht und es nicht weitermeldet,
kann VD das ja auch nicht wissen ;-)
Was Besseres als VD gibt es für AVI IMHO nicht, besonders seit der sync-Modifikation von Andreas.
Wenn Avery jetzt noch die 2.0 mit WDM-Unterstützung rausbringen würde......

>also vermutlich original interlaced. ....
>Also ich habe Deine Vorschläge zum Filtern mal durchprobiert - Resultat:
>NUR deinterlacing (oh graus ! scheint das Problem beseitigen zu können.....

Habs schon "befürchtet". Bei echtem Zeilensprungmaterial nützen meine Vorschläge nix.
Deinterlacen würde ich vermeiden, falls Du mit hohen Bitraten arbeiten kannst.

>Ich glaube zwar kaum, dass es sich um phase-shifts handelt, ....

Ich bin ziemlich sicher, daß doch. Denn:

>Auf dem TV ist das Bild bei der "Live" Sendung einwandfrei, .....

Phase-shifts sieht man auf dem TV nämlich nicht.

Beim Frühstück ist es mir wieder eingefallen: Die "Spezifika" der BT-Karten. Lange nicht benutzt
und schon vergessen.....

Dein Problem ist möglicherweise folgendes:

Dein Capture-Treiber macht selbst einen ständigen Fieldswap.
Der Sender sendet (T=Top field / B=Bottom field):
T1B1 T2B2 T3B3 T4B4 T5B5
Dein Capture-Treiber gibt das an VD:
B1T1 B2T2 B3T3 B4T4 B5T5
Wenn Du jetzt beim MPEG2-encoding "Bottom field first" auswählst, ist die Wiedergabe auf dem TV wieder
richtig!
Wenn der Sender jetzt die phase wechselt, sprich _ein_ field fehlt, kommt folgendes:
T1B1 T2B2 B3T4 B4T5 B5T6
Dein Capture-treiber macht das draus:
B1T1 B2T2 T4B3 T5B4 T6B5

Was jetzt beim MPEG2-encoding passiert, entzieht sich meiner Kenntnis - keine Ahnung.
Eigentlich müßte es mit "Bottom field first" auch richtig wieder rauskommen, evtl. gibts
ja einen doppel-Fehler, den man sonst nicht bemerkt.
Du könntest auf jeden Fall z.B. im Huffyuv (oder sonstwo) versuchsweise "Swap fields on decompress"
einstellen. Mal schaun.

Gruß Karl



Zuletzt bearbeitet von Der Karl am Mai. 29 2002,10:36

[Kika]

@Karl

> Was jetzt beim MPEG2-encoding passiert, entzieht sich meiner Kenntnis - keine Ahnung.

*grins* Das willst Du auch gar nicht wissen - sieht grausam aus! Nämlich exakt so wie eine falsche Field Order.
Wer gezwungen ist (z.B. aus Performance-Gründen) in YUV2 mit einer Karte aufzunehmen, die diesen Field Swap macht, muss unbedingt die Field-Swap-Option in VirtualDub einschalten und dann mit richtiger Field Order encoden, also Top Field First, sonst kommt bei der Kombination Phase Shift plus Field Swap nur noch Mist heraus.

Gut, dass Du das geschrieben hast, ich habe da inzwischen ehrlich gesagt nicht mehr dran gedacht, da ich inzwischen in RGB24 aufnehme, um das alles zu vermeiden.

Was die Codecs dann draus machen, also ob YUV oder RGB, das hat zumindest auf dieses Problem dann keine Auswirkung mehr. Es zählt hierbei ausschließlich, was Capture-Karte, Treiber und Capture-Software draus machen.

[getty]

@Kika

>sieht grausam aus! Nämlich exakt so wie eine falsche Field Order

Danke ! :-)

Die Field-Swap Option in VD aktivieren, was bringt das für mein Problem ? Bedeutet dies nicht einfach, dass VD die Fields von B zu T oder T zu B umordnet ? Was hätte das für einen "positiven" Einfluss auf einen späteren phase-shift ?

Weshalb eigentlich phase-shifts immer an derselben Stelle im Original-Video, etwa um nur "ungenügende" Mitschnitte zu ermöglichen, sind Dir solche Praktiken bekannt ?

Upps, das waren jetzt viele Fragen....:-)

In der Zwischenzeit habe ich rausgefunden, dass meine BT oder der Treiber oder welches Teil auch immer mal bei T-Field oder B-Field "beginnt". Den späteren shift, wie ihr wohl zu Recht meint, kann ich mit einer geänderten Fieldorder, ab diesem Zeitpunkt "gradebügeln", das Bild sieht mit der "angepassten" fo ab dem bestimmten Zeitpunkt absolut ok aus. Nur wie sollte ich die Schnittpunkte am PC finden und das nachträgliche mergen der Sequenzen mit meinem lieben TMPGenc wird wohl ohne sichtbare Übergänge auch nicht möglich sein.

Gruss

[Kika]

> Die Field-Swap Option in VD aktivieren, was bringt das für mein Problem ? Bedeutet dies nicht einfach, dass VD die Fields von B zu T oder T zu B umordnet ? Was hätte das für einen "positiven" Einfluss auf einen späteren phase-shift ?

Das ganze löst Dein Problem! Entweder in YUV mit aktiviertem Field Swap oder in RGB24. Sonst passiert genau das, was Karl beschrieben hat.
Den Field Swap später durchzuführen, bringt nicht mehr viel, da der Schaden dann schon angerichtet ist.
Aber sicherer ist es auf alle Fälle, RGB24 zu nehmen.

> Weshalb eigentlich phase-shifts immer an derselben Stelle im Original-Video, etwa um nur "ungenügende" Mitschnitte zu ermöglichen, sind Dir solche Praktiken bekannt ?

Jetzt müsste Karl eigentlich mit seinem Fließband samt Kisten kommen ;) Absicht ist das nicht, sondern liegt zum Teil an der Konvertierung NTSC -> PAL und auch an den Schnittsystemen.

> In der Zwischenzeit habe ich rausgefunden....

Nun, so in dieser Form ist mir das nie passiert, und seit ich RGB24 benutze, kommen solche Fehler eh nicht mehr vor.
Ausnahmen sind Fehler, die durch Timing-Probleme entstehen können, die treten aber praktisch nur bei Aufnahmen von VCR auf.

[Der Karl]

>Weshalb eigentlich phase-shifts immer an derselben Stelle im Original-Video, etwa um nur "ungenügende"
>Mitschnitte zu ermöglichen, sind Dir solche Praktiken bekannt ?

Nee, Absicht um das Capturen/encoden für uns zu erschweren, ist das mit Sicherheit nicht.
Das ist entweder Schlamperei, oder hat evtl. sogar knallharte technische Ursachen.

>Absicht ist das nicht, sondern liegt zum Teil an der Konvertierung NTSC -> PAL und auch an den Schnittsystemen

Bei NTSC->PAL wäre das ja verständlich. Die "Fehler" treten aber auch (bzw. überwiegend) bei "reinem" PAL auf.
Schnittsysteme (bzw. deren Operatoren) und andere beteiligte "Maschinen" z.B. Pan/Scan erscheint logisch.

>In der Zwischenzeit habe ich rausgefunden, dass meine BT oder der Treiber oder welches Teil auch immer
>mal bei T-Field oder B-Field "beginnt".

Wie hast Du das rausgefunden? Bei der TV-Übertragung gibts nicht wirklich T- und B-fields.
Die field-dominace spielt erst ab Digitalisierung eine rolle.

Überhaupt dürfte das gar nicht sein. Anhand der Lage des VBI (vertical blanking interval) kann - sollte -
der Capture-Chip eindeutig den Beginn eines Vollbildes indentifizieren. Soll heißen: der Capture-Chip
sollte (dürfte) nie an einem field-wechsel beginnen.

Meine Beobachtungen bestätigen das auch. So sind finden harte Schnitte z.B. bei Werbeeinblendungen immer
zwischen zwei Frames statt - Bestätigung dafür, daß die (meine) Karte das richtig macht.

>Jetzt müsste Karl eigentlich mit seinem Fließband samt Kisten kommen....

Das muß ich wohl nochmal überarbeiten mit den "neuesten wissenschaftlichen Erkenntnissen" ;-)

Gruß Karl

[Der Karl]

Das hat mir jetzt keine Ruhe gelassen ;-)

Für das "komische" Verhalten der MPEG2-Encoder mußte es doch eine logische Erklärung geben.
Nach den "Behauptungen" von getty habe ich meine alte WINTV wieder "ausgegraben"
und etliche Probeaufnahmen gemacht.

Es ist tatsächlich so.
Wo die Karte bzw. der Treiber anfängt, ist blanker Zufall. Egal ob RGB24 oder YUV!

Während meine Asus _immer_ nachvollziehbar mit dem 1. Field eines TV-Vollbildes (wohlgemerkt:
ich rede nicht über progressive/interlaced/phase-shifted, sondern über das zeitlich erste
field eines kompletten 40ms-zyklus) anfängt, beginnt die BT-Karte mal mit dem Ersten(richtig)
mal mit dem Zweiten (falsch). Im zweiten Fall benötigt man dann einen Fieldswap.

Dieser Fieldswap ist das besonders gemeine an dieser Geschichte, DENN: es müssen nicht die
zwei Fields eines TV-Vollbildes, sondern die aufeinanderfolgenden fields _zwischen_zwei_
TV-Vollbildern geswappt werden.

Zusammenfassend:
Beginnt die BT-Karte falsch, hat man erstmal einen (evtl. zusätzlichen) phase-shift.
Der Sender arbeitet (bei progressive source) phase-shifted oder auch nicht - zeitlich aber
phasenrichtig und (nach meinen Erfahrungen) im Schnitt auch -Vollbild-genau.
Die fieldswaps der Karte sind außerhalb der (richtigen) phase.
Wenn der Sender jetzt einen Fehler (in der richtigen phase) macht, der sonst gar nicht
bemerkt wird, hat man im Ergebnis das allerschönste field-Wirrwar.
Also (über alles betrachtet) z.B. zwei phase-shifts mit einem field-swap dazwischen.

Was für ein Schrott!

Gruß Karl

[Der Karl]

@Kika

Wie ist das eigentlich?
Fängt Deine BT-Karte auch jedesmal anders an?

Gruß Karl