cce und field-order

[Tsunami]

@ shh :

ich habe mal ein paar Fragen an dich (es sollten aber auch andere antworten,
wenn sie die Antwort wissen) :

1.
du hattest mal geschrieben, das der CCE 2.62 das Bild um zwei Zeilen nach oben verschiebt,
wenn man 'upper field first' aktiviert (den thread finde ich leider nicht mehr),
und man daher das von FitCD erzeute Script manuell anpassen muss.
Ich habe das jetzt mal getestet, aber kann das nicht bestätigen.
Vielmehr verhalten sich alle CCE-Versionen gleich :
bei ausgeschaltetem 'upper field first' verschiebt sich das Bild nicht,
bei eingeschaltetem 'upper field first' verschiebt sich das Bild um eine Zeile nach oben.
(Wenn der CCE immer die gleichen Zeilen hernimmt zur Encodierung,
dann wird damit auf elegante und vor allem sehr schnelle (!) Weise die Field-Order umgedreht.
Es handelt sich hierbei also meiner meinung nach nicht um einen Bug, sondern um Absicht.)
Das gilt sowohl beim progressiven wie auch beim interlaced-Encoden,
ebenfalls ist es unabhängig davon, ob man einen interlace-fähigen Codec wie den PicVideo MJPEG
benutzt oder einen progressiven Codec wie den Huffyuv
(der Huffyuv erzeugt immer ein progressives Video, kann es aber beim Abspielen wie ein
interlaced Video behandeln).



2.
in einem anderen Thread hast du mal folgendes Avisynth-Script gepostet, mit dessen Hilfe
man angeblich die Field-Order eines bff-Videos zu tff-Field-Order verändern kann,
damit ein ehemals bff-Video auch auf solchen Standalone-Playern abgespielt werden kann,
die mit bff-Field-Order nicht zurechtkommen (Cyberhome) :

--- cut ---
AviSource("F:\DeinDVfilm.avi").AssumeFrameBased.SeparateFields
DeleteFrame(0)++Blackness(1)
FreezeFrame(1499,1499,1498)
BilinearResize(464,217,12,33,696,217).Weave
AddBorders(8,70,8,70)
--- cut ---


Fragen :
2a)
wozu fügst du den Befehl '++Blackness(1)' ein ?
Dieser Befehl erzeugt ein schwarzes Video mit einem Frame Länge, meiner Meinung nach ist
das überflüssig.

2b)
Ich habe in der Avisynth-Language-Reference mal nachgelesen, und dort ist der Befehl
'ComplementParity' für den Zweck der Field-Order-Korrektur vorgesehen, aber nach meinen Tests
funktioniert der nicht, weißt du evtl. warum nicht ?

2c)
wird mit dem obigen Script nicht ein Phase-Shift erzeugt, die man eigentlich vermeiden sollte,
bzw. falls es nicht so ist, wer kann mir nochmal detailliert erklären,
was man im allgemeinen unter einem Phase-Shift zu verstehen hat.
Wo finde ich in diesem Zusammenhang das Mega-Posting von 'Karl' in dem er das interlaced-Problem mit
Hilfe von Kartons erklärt hat ?

2d)
was genau meinen die CCE-Programmierer mit 'upper field first' ?
Meinen sie, das das Source-Video die Field-Order tff besitzt, oder meinen sie, das das
Ziel-Video die Field-Order tff besitzen soll ?
Mir ist in beiden Fällen allerdings die Logik dahinter immer noch nicht klar geworden.


-----

Hier mal eine Methode zur Feststellung der Field-Order im Source-Video,
die sowohl mit MJPEG, als auch mit Huffyuv funktioniert :


Avisynth-Script erstellen (name.avs) :

--- cut ---
SegmentedAVISource("c:\Capture.avi")
AssumeFrameBased()
ComplementParity()
SeparateFields()
--- cut ---

dieses Script mit VirtualDub öffnen :

File, Open video file, (Avisynth-Script laden)
[x] Popup Extended Open Options (ein)

interlaced frame mode : split interlaced frames into two fields (unswapped [nicht swapped !])

Video abspielen

keine Ruckler : das Source-Video hat die Field-Order 'Top field first (field A)'
Ruckler : das Source-Video hat die Field-Order 'Bottom field first (field B)'

-----

Hat man jetzt zum Beispiel festgestellt, das das Source-Video
die Field-Order 'Bottom field first (field B)' hat,
dann gibt es folgende Möglichkeiten, das Video ruckelfrei zu encoden :

Möglichkeit 1 :
-> 'upper field first' im cce einschalten
-> anschliessend braucht man das tff-Flag im mpg NICHT mehr mit Tools wie Easy Changer zu verändern
Vorteil :
das mpg wird auf jedem Player abgespielt
Nachteil :
Die Makroblock-Optimierung von FitCD funktioniert nicht mehr, weil das Bild um eine Zeile nach oben verschoben ist

Möglichkeit 2 :
-> 'upper field first' im cce ausschalten
-> anschliessend muss man das tff-Flag im mpg mit Tools wie Easy Changer ausschalten
Vorteil :
Die Makroblock-Optimierung von FitCD funktioniert
Nachteil :
das mpg wird auf Playern, die bff nicht beherrschen, nicht abgespielt (Cyberhome)

Möglichkeit 3 :
Avisynth-Script 'swap_field_order.avs' (siehe dein Script von oben) :

--- cut ---
SegmentedAVISource("E:\capture1\voy_mjpeg.avi")
AssumeFrameBased()
SeparateFields()
DeleteFrame(0)
#Blackness(1)
# Beispiel : der Film hat 401 Frames
# ergibt 802 Fields
# Nummerierung : 0 bis 801
# A = Start-Frame bzw. Field
# A = 801
# B = End-Frame bzw. Field
# B = 801
# C = Source-Frame bzw. Field, also Quelle für die Kopie
# C = 800
# FreezeFrame(A, B, C)
# oder einfacher :
# FreezeFrame(FrameAnzahl * 2 - 1, FrameAnzahl * 2 - 1, FrameAnzahl * 2 - 2)
FreezeFrame(801,801,800)
#Resizing hierher
#BilinearResize(464,217,12,33,696,217)
#BicubicResize(464,271,0,0.6,0,0,480,288)
Weave()
#AdBorders hierher
#AddBorders(8,70,8,70)
--- cut ---

-> 'upper field first' im cce ausschalten

Vorteile :
- Die Makroblock-Optimierung von FitCD funktioniert
- Das mpg wird auf jedem Player abgespielt

Nachteile :
- man muss manuell den Befehl 'FreezeFrame(A,B,C)' anpassen
- Phase-Shift ?
- Ein Schritt mehr ist notwendig, daher etwas langsamer
- Falls der CCE 2.50 dieses Avisynth-Script nicht annimmt,
dann muss man es mit Link2 in ein Pseudo-Avi umwandeln.
- Den Audio-Stream muß am Anfang um 20ms (Länge eines PAL-Fields) verkürzen (entfernen),
damit Audio und Video synchron laufen (mit beSweet (ota-Switch) oder mit Cool-Edit)

Alternative :
statt am Anfang des Audio-Streams 20 ms wegzuschneiden, kann man auch ein Delay von -20ms einstellen.
(Delay = AudioPTS - VideoPTS = 0.00 - 0.20 = -20ms)
Nachteil : Wenn so ein Video mit dem Media-Player abgespielt wird,
dann wird das Delay evtl. nicht beachtet.

Delay-Einstellung im bbmpeg-Muxer :
Video : 200
Audio : 180

Delay-Einstellung im i-Author-Muxer :
Video : 0.020
Audio : 0


Möglichkeit 4 (die NICHT funktioniert !) :
'SwapFields()' im Avisynth-Script oder den SwapFields-Filter im VirtualDub
beides funktioniert nicht, weil ein starkes bobbing auftritt, welches anstatt den Zeilenversatz
zu korrigieren, diesen sogar verstärkt, weil offenbar in die falsche Richtung gebobbt wird.

Fragen :
a)
ist an diesen Möglichkeiten irgendetwas fehlerhaft bzw. kann jemand bestätigen das sie funktionieren
(ich habe sie nur rein theoretisch hergeleitet)

b)
gibt es noch weitere Möglichkeiten, ein ruckelfreies Video zu erzeugen ?


-----


Gruß
Tsunami

[shh]

zu 1.:
Ich werde mir das nochmal anschauen. (Habe jetzt wenig Zeit)
Der CCE reagiert leider auch unterschiedlich auf verschiedenes Quellmaterial. Kika oder mb1 hat das selbe Proble wie ich. (der andere nicht)....
Ich habe übrigens immer geschrieben, daß das Video um eine Zeile hochgeschoben wird nicht zwei. D.h. wenn der CCE die tff-flags nicht ändert, wird natürlich die field-order geändert. Das sollte aber nie geschehen, weil bff-Video einfach bff ist, und ein tff-Video ein tff. Die field-order ändern macht da mehr kaputt, als daß man es brauchen könnte.

zu 2a.:
Nach SeparateFields hat man doppelte Anzahl "frames".
DeleteFrame(0) löscht das erste field.
++Blackness(1) hängt am Ende ein schwarzes field dran. (das könnte man natürlich auch irgendwie mit FreezeFrame ersetzen)
So hat man einen Phase-shift, was mein alter Cyberhome AD-N212 brauchte. Von den neueren Playern können, so weit ich weiß, alle bff-Videos korrekt abspielen.
Zu dem Zeitpunkt ist's leider nicht einfacher gegangen. Möglich, daß man das jetzt viel schneller/einfacher machen kann... Vielleicht funktioniert ja die phase-shift-Funktion vom SmartDeinterlace jetzt endlich in avisynth.

zu 2b: 'ComplementParity'
Der Befehl ändert nur die Field-Reihenfolge (bff oder tff). Das hat nichts mit phase-shifting zu tun, wie es bei mir nötig war. Wenn man ein bff-Video hat und einfach die field-order ändert, wird noch lange kein tff-Video daraus. ;)
Bff fängt einfach "unten" an; das dazugehörige top-field fehlt.

zu 2c)
Es wird ein phase-shift erzeugt: das erste field wird gelöscht.
Bei mir hat's funktioniert.
Der Thread mit den Kartons war damals auf dem UltimateBoard. Ich bin mir nicht sicher, ob der gerettet werden konnte.
Ein phase-shift ist meinem Verständnis nach einfach nur das Ändern eines Videos von bff zu tff oder umgekehrt.

zu 2d)
> was genau meinen die CCE-Programmierer mit 'upper field first' ?
Ich habe nicht den blassesten Schimmer. Angeblich soll da wirklich ein bug drin stecken, weil ein anderer User vor einiger Zeit eine gefixte Version zum Testen bekommen hat.

Zu den restlichen Ausführungen:
Ich glaube, das paßt so.

Ein paar Sachen noch:
Video von der DV-Cam kommt immer in bff daher.
Gecapturtes so weit ich weiß immer tff.
Ich sehe jetzt erstmal keine Notwendigkeit überhaupt feststellen zu müssen welche Art von interlaced Video man hat. (weil man es schon weiß)
Macroblock-Optimierung bringt meiner Meinung nach bei interlaced-Material nichts, weil die fields bei der motion-compensation einzeln betrachtet werden. Ich habe damals die motion-Vektoren nur von progressive-Material geprüft. Vermutlich (bzw ziemlich sicher) muß man bei interlaced-video noch kleiner resizen, damit die Vektoren nicht darüber hinaus schießen (pro field mind. 2 pixel). Weil man dann aber einfach zuwenig Freiheit der Zielgröße hat und es nach neueren Betrachtungen sogar warscheinlich ist, daß der CCE absichtlich solche motion-compensation duldet, wird das Ganze sehr fragwürdig.

----
Ich weiß nicht, ob du's mitbekommen hast, es ist aber in diesem Zusammenhang wichtig:
Die aktuelle FitCD-Version hat beim interlaced-resizing einen bug. Und zwar wird in bestimmten Situationen die field-order vertauscht. Aufpassen, daß bei AddBorders oben keine ungerade Anzahl Zeilen hinzugefügt wird.

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

[Kika]

Nochmal generell zu interlaced und CCE:

Bei mir funktioniert das interlaced Encoden mit CCE einwandfrei, allerdings gegenüber TMPGEnc mit umgekehrter Field-Order-Einstellung:

AV-Video (auch DVD)
TMPGEnc: Top Field First
CCE: Lower Field First

DV-Video (eben DV)
TMPGEnc: Bottom Field First
CCE: Upper Field First

Progressive
TMPGEnc: Top Field First
CCE: Lower Field First

Upper Field First bei progressive Video zu aktivieren kann wohl bei einigen Playern zu einem unfreiwilligen Field Swap führen. Der dusslige Pioneer 343 hat das sogar bei MPEG2 mit 352x288 fertig gebracht!
Wenn man's also nicht gerade braucht, weil man DV-Video encoden will, sollte man's unbedingt ausschalten.

[Der Karl]

Grundsätzlich: Mir ist immernoch etwas unklar (die Grundlagen habe ich schon verstanden) was
jeweils mit tff,bff,Upper,lower,OrderA,OrderB _gemeint_ ist.
Das zeitlich erste (wird auch zum TV als erstes übertragen) field im Frame wird nämlich ein
Zeile tiefer, als das zweite dargestellt. Meint Top nun das zeitlich Erste oder das "weiter oben"
angezeigte?

Zum phase-shift:

Progressive:
Nach dem 2:2 pulldown:
T1 T2 T3 T4 T5
B1 B2 B3 B4 B5
T1 und B1, T2 und B2 ... sind jeweils die fields, die zu einem ursprünglichen Originalbild gehören.
Wird falsch angefangen (erstes field T1 unterschlagen) ergibt sich nach der Digitalisierung:
B1 B2 B3 B4 B5
T2 T3 T4 T5 T6

Es wird natürlich in richtiger Reihenfolge übertragen, nur die Paarigkeit stimmt (progressive) nicht.

Interlaced:
Hier spielt noch die zeitliche Abfolge eine Rolle:
T1-T2-T3-T4-T5-
--B1-B2-B3-B4-B5
Nach phase-shift (T1 fehlt):
B1-B2-B3-B4-B5
--T2-T3-T4-T5-
Bleibt die fielddominace tff, werden ursprüngliche top-fields "unten" und ehemalige bottom-fields
"oben" angezeigt, obwohl die zeitliche Abfolge richtig ist.
Hier müßte man eigentlich B1 auch wegwerfen, oder T1 neu erzeugen. Dem Output-stream muß man dann
wieder tff "mitgeben".
Wenn ich mich recht erinnere, macht AVISynth da aber einiges "falsch" oder ich habe mich dumm angestellt ;)

Bei der Digitalisierung (von analog-TV) vermischen sich die Standardfehler meist noch mit Fehlern der
TV-Karten (zusätzliche Fieldswaps und/oder phase-shifts). Das wird dann richtig gemein, wenn es sich
dynamisch ändert.

>der Huffyuv erzeugt immer ein progressives Video...

Meiner Meinung nach ist das nur ein Fehler im decompressor, der gegenüber dem öffnenden Programm
(z:b: VD) nicht signalisiert, daß das splitten in fields zulässig ist. Vermutlich ein fehlendes Flag.
AVISynth kümmert sich um sowas nicht und nimmt sogar MPEG4-vids auseinander (was nicht sein dürfte).

>'ComplementParity' für den Zweck der Field-Order-Korrektur vorgesehen, aber nach meinen Tests
>funktioniert der nicht, weißt du evtl. warum nicht ?

Wie ComplementParity() arbeitet, hängt von der Struktur des Videos ab. Bei "FrameBased" wird nur die
fielddominanz geändert. Bei "fieldbased" werden wirklich die fields vertauscht.
Wertet z.B. das folgende Programm die fielddominanz nicht aus (geht z.B. immer von bff aus), ändert sich
möglicherweise gar nix. Dann:
SeparateFields()
ComplementParity()
#Trim(1,0)
#ComplementParity()
Weave()

Die beiden auskommentierten nach Bedarf.

EDIT: Hab mir das nochmal angeschaut und glaube jetzt auch zu wissen, was Du meinst:
Scheinbar wird nur mit der Lage der Zeilen jongliert, aber nicht die Reihenfolge der Fields im Output geändert (wenn man den fieldstream zb: nach VD ausgibt)
Das klappt nur, wenn man vor den ersten Befehlen im script "ComplementParity" anwendet, also z.B. vor "SeparateFields"
Sonst sieht man nur im fullframe ein Ergebnis, also "Weave" muß sein.
Mal verfolgen.....

>'SwapFields()' im Avisynth-Script oder den SwapFields-Filter im VirtualDub
>beides funktioniert nicht, weil ein starkes bobbing auftritt, welches anstatt den Zeilenversatz
>zu korrigieren, diesen sogar verstärkt, weil offenbar in die falsche Richtung gebobbt wird.

Hier ist wahrscheinlich zweimal was getauscht, das ist aus der Ferne aber schwierig.
Man müßte die ganze Kette untersuchen, welches beteiligte Programme, Encoder bzw. Frameserver
_was_ "anrichtet".

Wichtig: AssumeFrameBased() und AssumeFieldBased() _erzeugen_ eine neue fieldparity (bff).

Zur Kontrolle: Das zeitlich erste field eines 40ms-Zyklus bei der TV-Übertragung beginnt mit einer
ganzen Zeile und endet mit einer Halben. Das Zweite beginnt mit einer halben Zeile und endet mit
einer Ganzen. Wenn nicht letterboxed wurde, sieht man das.
Die sollte man möglichst ;) wieder richtig zusammensetzen.

>Wo finde ich in diesem Zusammenhang das Mega-Posting von 'Karl' in dem er das interlaced-Problem mit
>Hilfe von Kartons erklärt hat ?

Auf einer meiner vielen Platten ;)

Ich habe das aus dem Kopf geschrieben, nachdem ich mich auch lange nicht damit beschäftigt habe.
Bitte nicht erschlagen, falls irgendwas nicht ganz korrekt ist. ;) ;)

Gruß Karl



Zuletzt bearbeitet von Der Karl am Juli. 16 2002,21:57

[Der Karl]

Ergänzung:

Das ist recht lustig - vermutlich ein Bug im AVISynth. Man kann sehr wohl die fieldreihenfolge der Ausgabe beeinflussen. Dazu muß man allerdings tricksen.
Probiert mal folgendes script (nach und nach auskommentieren und in VD laden)

AVISource("D:\Capture.avi")
SeparateFields()
Trim(1,0)
weave()

AssumeFrameBased()
SeparateFields()
ComplementParity()
Weave()

AssumeFrameBased()
ComplementParity()
SeparateFields()
Weave()
AssumeFrameBased()
ComplementParity()
SeparateFields()
AssumeFieldBased()
Bob()

Gruß Karl
(again) ;)

[Kika]

Field Order:

Also ich kenne drei Arten, das zu beschreiben:

Top Field / Bottom Field

Upper Field / Lower Field

Even Field / Odd Field


Die Zuordnung ist dabei so:

Top = Upper = Odd

Bottom = Lower = Even

Vielleicht hilft's ja...
So, ich habe die vormals falschen Angaben korrigiert, sonst verwirrt das eventuell.

Bei mir ist es jetzt eben so, dass CCE das wohl genau anders herum interpretiert.

P.S.
Die Programme bzw. deren Hersteller scheinen sich darüber auch nicht so ganz einig zu sein  :angry:

[shh]

> Meint Top nun das zeitlich Erste oder das "weiter oben"
angezeigte?

Beim MPEG ist das ganz einfach. Da bekommt jedes field ein flag, ob es oben (top-field) oder unten (bottom-field) ist. Zusätzlich wird dann eine Layer darüber noch ein flag gesetzt, das darüber entscheidet wie diese fields abgespielt werden. Eben das flag tff_first on/off.
Die meisten MPEG-encoder werden nur das tff_first nach Benutzerwunsch setzen und das Eingangs-AVI "blind" encoden. Also die Zeile 1,3,5,... als top-field annehmen.

Beim AVI ist das leider ganz anders (und deswegen wird das warscheinlich auch von jedem Hersteller anders gehandelt).
Da gibts erst seit OpenDML Infos für "Frame and Field Indexing": OpenDML-Spec
Weil AVI aber für den PC und den Monitor gemacht ist (mit progressive-Anzeige), denke ich mal, daß top-field auch das geometrisch obere Halbbild meint. Der PC kann ja mit einem bff alleine im Grunde nichts anfangen.

Jetzt ist die Frage, wie solche tff- und bff-AVIs geWEAVED werden.
Beim tff-Video ist das klar: Da kommt das geometrische top-field auch zeitlich zuerst.
Wie ist das beim bff-AVI? Ist da Zeile 1,3,5,... das top-field vom zweiten frame oder was anderes?
Oder ist das etwa noch von codec zu codec verschieden??
Oder ist das eine Kompatiblitätsfrage der encoder, nämlich ob sie mit den field-infos der OpelDML-AVIs überhaupt umgehen können?

Karl> Bug im AVISynth

Scripte muß ich noch testen.
Ich weiß zwar nicht, wie das im Detail funktioniert, aber wenn avisyth "altes" AVI ausgibt (und kein OpenDML mit der entsprechenden field-info) ist es gut möglich, daß AVIsynth irgendwie was verdreht.
[Ich muß mir undedingt die OpenDML-Specs genauer anschauen...]
Vielleicht kann man das ja irgendwie mit AssumeFrameBased oder AssumeFieldBased kompensieren (oder flippen). Vielleicht mit Hilfe von ComplementParity... So genau war mir denen Funktion auch nicht bekannt.

Kika> Top = Lower = Even
Bottom = Upper = Odd

Huch! Was ist denn das fürn Englisch?? :0
Top = Lower und Bottom = Upper?
Welcher encoder macht denn sowas?

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

[Kika]

> Welcher encoder macht denn sowas?

CCE zum Bleistifft, schrieb ich doch weiter oben.
Wenn bei dem Top = Upper wäre, dann würden bei mir ja die Videos, die ich damit encode, alle das große Zittern haben, haben sie aber nicht, ergo?

Also:
Top = Odd (1,3,5,7 usw.)
Bottom = Even (2,4,6,8 usw.)

Und der CCE (jedenfalls meiner) machts genau falsch herum.

[Tsunami]

@ shh :

Du sagst, das bei einem bff-Video das allererste Top-Field fehlt.
Wo kann man das überprüfen bzw. wo hast du das gelesen ?
Es könnte ja auch sein, das bei einem bff-Video das bottom-Field (bf) des ersten Frames
vor (f = first) dem Top-Field im Video-Stream abgelegt ist und um dies zu kennzeichnen
wird das tff-Flag deaktiviert.
Ist ein TV überhaupt fähig, mit einem Bottom-Field den Bildaufbau zu beginnen, wenn kein
Top-Field vorhanden ist ?
Oder erzeugt ein Standalone-Player selber ein schwarzes Top-Field, wenn ein Top-Field
im Videostream nicht vorhanden ist ?



@ Karl :

[Kika]

@Tsunami

Schöner Artikel. Deckt sich (glücklicherweise ;) ) auch mit meinem zweiten Posting.
Was mich jetzt stark interessieren würde ist, ob Du (und andere) meine Erfahrungen bezüglich der vertauschten Angabe bei CCE bestätigen kannst.

Zu Odd und Even: es gibt nun mal sehr viele Seiten und technische Aufsätze, die diese Begriffe dafür benutzen, dürfte schwierig sein, das immer zu vermeiden.

Dieses ganze Durcheinander bezüglich der Bezeichnung der Fields scheint ja wirklich daher zu kommen, dass etliche Leute, und eben wohl auch Programmentwickler, das ganz eigen interpretieren, gerade so, wie Du's bei Odd und Even ja auch beschrieben hast.

Gruß,
Kika

[shh]

> Du sagst, das bei einem bff-Video das allererste Top-Field fehlt.

Ich glaube wir meinen das gleiche. Ich denke auch, daß es so gespeichert wird.
Das top-field des ersten frames muß aber fehlen, weil man sonst bff-Material ohne Probleme tff encoden könnte - was nicht möglich ist. (Auch nach evtl nötigen field-swaps).

> Ist ein TV überhaupt fähig, mit einem Bottom-Field den Bildaufbau zu beginnen, wenn kein Top-Field vorhanden ist ?

Hmm. Der [normale] Fernseher stellt ja nur seriell Halbbilder dar (ansonsten müsste er ja ein field zwischenspeichern). Warum sollte das auf progressives Material (tf + bf) beschränkt sein? Vielleicht haben die fields am Anfang einen Marker, der ihre Position kennzeichnet.
Wie das ein Player macht, weiß ich nicht. Warscheinlich kocht da wieder jeder sein eigenes Süppchen. Müsste für die Darstellung eigentlich egal sein.

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

[Der Karl]

@shh

>aber wenn avisyth "altes" AVI ausgibt (und kein OpenDML mit der entsprechenden field-info)...

Ich gehe doch ganz selbstverständlich ;) davon aus, daß AVISynth OpenDML ausgibt.

Zum Script. Mein Standardfall: progressives AVI mit phase-shift (Asus capture).

SegmentedAVISource("D:\Capture.avi")
SeparateFields()
Trim(1,0)
#ComplementParity()
Weave()

Dazu muß man folgendes wissen: Die Asus verhält sich absolut richtig. Ein phase-shifted progressives
Video würde also daherkommen: B1T2 B2T3 B3T4 (bezogen auf die ursprünglich richtige fieldpaarigkeit).
Das ist sowohl zeitlich, als auch auf dem TV "Darstellungstechnisch" richtig.
Mit "Trim(1,0)" wird B1 verworfen und T2B2 bilden (nach Weave) einen neuen progressiven Frame.
Das resultierende Avi ist wiederum top-dominant, weshalb jetzt richtig im Frame das (ursprünglich
zeitlich Zweite) T2 "oben" dargestellt wird, also mit einer halben Zeile beginnend! Dazu mehr - bei
@Tsunami ;)
Wäre! jetzt die (wieder progressive) Paarung falsch, würde das auskommentierte "ComplementParity"
die beiden fields nochmal swappen (unschwer an ausgefransten schrägen Kanten zu sehen).
Das klappt auch!
Ließe man "weave" jetzt weg, _sollte_ lt. AVISynth-doku sich die Reihenfolge der fields im Output
z.B. an VD ändern. Genau das geht nicht, sondern nur mit solcher Trixerei, wie ein meiner "Ergänzung".

@Tsunami

>Das ist falsch.

Hihi, bist also auch drauf reingefallen...

>Richtig ist das :
----- 1
---------- 2
---------- 3
----------
----------
----------
----------
-----

Yepp, trotzdem hast Du einen Denkfehler drin. Schau Dir mal das Raster auf Deinem TV an. Dann wird
auch klar, warum das so sein muß.
Vergiß mal fielddominanz bzw. parity und betrachte nur die "Physik".

Das _zeitlich_ erste field in der TV-Übertragung beginn (ganz!) links oben in der Ecke.
Die Zeilen werden schräg geschrieben. Das _zeitlich_ erste field beginnt also nach Deiner (richtigen)
Darstellung mit Zeile 2 und wird bis zur Hälfte von 576 "geschrieben". Von hier springt er nach oben
(der Zeilensprung ;) ) und fängt in der Mitte von Zeile 1 wieder an. Dieser "Einsprungpunkt" liegt
etwa auf gleicher Höhe, wie der Beginn von Zeile 2.
Die erste _übertragene_ Zeile eines 40ms-Zyklus ist also mitnichten die oberste dargestellte Zeile.
Damit ist auch klar, warum das bff von DV eigentlich richtig ist, da sowohl die zeitlichen, als auch
die "Darstellungstechnischen" Belange des TV korrekt berücksichtigt werden.
Dieses Thema wird in diversen "Veröffentlichungen" falsch dargestellt.

Wird jetzt digitalisiert: Nur mal angenommen, die Karte macht das richtig, dann wird dem digitalisierten
Stream tff mitgegeben.
Damit die zeitliche Abfolge der fields stimmt, muß VD also einen "swap" haben.
AVISynth wertet möglicherweise tff aus und "weiß", das er selbst swappen muß, oder ignoriert sogar
tff und nimmt selbst bff an. Das Ergebnis daraus braucht in VD dann "unswapped".

Arbeitet die Capture-Karte jetzt (zufällig) richtig - meine V3800 tut das - muß man nur die Fields eines echten
Interlaced Streams in die richtige Reihenfolge bringen und: - voila - das Allererste field beginnt mit einer
ganzen Zeile.
Die richtige Digitalisierung eines kompletten 40ms-Zyklus in ein Frame setzt voraus, daß die Karte die Lage
des VBI (vertical blanking interval) korrekt auswertet. Das machen viele TV-Karten nicht (oder falsch) und
fangen (wie der Fernseher) bei _irgendeinem_ Field an. Beim TV ist das aber analog, also egal.

Gruß Karl

[Der Karl]

Nochmal ich ;)

Die Lösung ist ganz simpel. Lädt man ein AVI, werten weder AVISynth noch VD irgendwelche Dominanz-infos
aus, falls es sowas in den AVIs überhaupt gibt.
AVISynth setzt immer bff voraus, VD immer tff. Einen tff-stream lädt also VD "richtig" und AVISynth "falsch".
Anders sieht es aus, wenn man von AVISynth nach VD "frameserved". Hier wird sehr wohl die dominanzinfo
mitgegeben, womit auch die Frage, ob AVISynth OpenDML ausgibt, geklärt sein dürfte

Wie sich andere frameserver (vdr, Link2, mpeg2dec.dll, Vfapi..) verhalten, wäre noch zu untersuchen.

Meine Asus macht (nachvollziehbar) immer bff.
AVIs sind also keineswegs immer top-dominant. Es kann allerdings sein, daß viele Programme meinen,
das wäre so.

Wie entsteht nun ein tff-stream?
Das hängt davon ab, wie die TV-(Capture-)Karte digitalisiert. Grundsätzlich muß im entstehenden Frame
das top-field immer oben sein, sonst stimmt die progressive Darstellung nicht (beide fields werden
gleichzeitig dargestellt).
Beginnt die Karte (wie meine Asus) mit dem bottom-field und danach das (zeitlich folgende) top-field,
was im resultierenden Frame (richtig) eine Zeile oberhalb des bottom-fields gespeichert wird, ist das
entstehende AVI bottom-dominant, da bei der Ausgabe die zeitliche Abfolge natürlich richtig berücksichtigt
werden muß.

Fängt eine Karte mit dem Zeilensprung (beginn zweites Halbbild) an, wird zuerst das top-field (oben)
und dann das zeitlich folgende bottom-field (unten) gespeichert.
Dieser stream muß als tff behandelt werden.

Zum "seltsamen" Verhalten von AVISynth:
Das muß man einfach wissen - wußte ich bisher auch nicht
AVISynth führt intern "Buch" über die fielddominanz bzw. -parity.
Ausgehend von bff - wenns anders ist, muß man AVISyth das sagen ("ComplementParity") zum Anfang,
merkt sich AVISyth jede(n) fieldlöschung bzw. -swap und paßt intern die dominanz an.
Das bezieht sich auch auf die Ausgabe an VD. Wenn man also fields (hoffentlich richtig) manipuliert,
muß man die gewünschte andere dominanz festlegen ("AssumeFrameBased / Fieldbased").

------ Schnipp ------------------------------

AVISource("D:\Top_dom.avi")

# aus einem echten top-dominanten stream #
# einen bottom-dominanten machen #
# er wird von AVISynth als bottom-dominant interpretiert #
# VD würde ihn richtig behandeln #

ComplementParity() #swap fields on input
SeparateFields()
Trim(1,0) # erstes field verwerfen (parity ändert sich mit -> bottom)
weave()

# end (hier ist er bottom - dominant) #

# zurück nach top-dominant #

ComplementParity() #swap fields on input
AssumeFrameBased() #behauptet, er wäre bottom-dominant
SeparateFields()
Trim(1,0) # erstes field verwerfen (parity ändert sich mit -> top)
weave()

# end (hier ist er wieder top - dominant) #
#

------ Schnapp ------------------------------

Gruß Karl

[Kika]

@Karl

Tja, Du hast es schon geschrieben....
Ich habe mich gestern auch nochmal intensiv mit AVISynth auseinander gesetzt und es stimmt wohl tatsächlich:
Es geht bei OpenDML, also dann, wenn Field-Dominanz-Informationen vorhanden sind, immer von bff aus, während VirtualDub von tff ausgeht. Steht auch so in der Anleitung drin (den Teil muss ich früher immer überlesen haben).

Hm, gehen wir jetzt mal einen Schritt weiter: Ungelöst ist ja nach wie vor die Frage, warum anscheinend bei einigen das Interlaced-Encoden mit CCE funktioniert, während andere wohl Probleme mit der Field-Dominanz haben.
Ich selbst habe das jetzt noch nicht checken können, glaube mich aber erinnern zu können, dass die, die damit Probleme haben, AVISynth benutzen. Ich selbst nehme (noch) meistens VirtualDub.
OK, das klärt zwar nicht so ganz, warum solche Probleme dann nicht mit TMPGEnc auftauchen... aber einen Test wäre das imho mal wert.

[Der Karl]

@Kika

>Ungelöst ist ja nach wie vor die Frage, warum anscheinend bei einigen das Interlaced-Encoden mit CCE funktioniert..

Mit dem Wissen um die Struktur des eigenen Streams und (das jetzt bekannte) Verhalten
von VD und AVISynth sollte es doch kein Problem sein, das Verhalten von CCE bzw. TMPGEnc herzuleiten.

Ich kann das leider nicht testen, da ich keinen Fernseher habe und einen MPEG2-stream
wieder zu zerlegen und fieldweise am PC zu analysieren ist recht fehlerträchtig, sprich: zweifelhafte Ergebnisse.

Gruß Karl