Fields vertauscht...

Hier ein Thread übernommen aus unserem altem Forum:

Zitat

Original von svenrender:

Ich encodiere häufig Interlaced Material zu SVCD und führe kein DeInterlacing durch... Normalerweise funktioniert es ganz gut, doch hin und wieder werden die Fields vertauscht...

Ich möchte ganz ger testet ob bei der erstellten SVCD-MPEG-Datei die Fields evtl. vertauscht sind. Jedoch sieht man beim abspielen mit PowerDVD oder ZoomPlayer nichts
Mit welchem Tool kann man also sicher erkennen ob eine Vertauschung vorliegt oder nicht???

Ist mir immer ein bischen zu spät, wenn man die SVCD gebrannt hat und auf dem TV ruckelt es

Zitat

Original von Morpheus:

Hallo,
dass müßte mit ReStream gehen. Einfach dein Film in ReStream laden dann siehst du ja ob ein Haken bei tff ist, wenn ja mach ihn weg und speichere neu.

Zitat

Original von Harald66:

Hi,

wobei ReStream ja nur den Headder ausliest, und somit auch nicht wissen kann, ob dieser korrekt ist. Da hilft nur das austesten mit TMPGEnc und dann im Zweifelsfall umpatchen.
Btw wenn Du beim encoden schon die richtige Field Order gewählt hast, kann das Ergebnis später nicht vertauscht sein (Ausnahme: bff mit CCE)

Zitat

Original von svenrender:

Harald66 hat folgendes geschrieben::

Da hilft nur das austesten mit TMPGEnc

Genau darum geht es ja, wie teste ich aber in TMPG ob die Angabe im Header richtig oder falsch ist???

Zitat

Original von Harald66:

Hi,

in dem Du jeweils die Field Order vertauschst (in den Settings) und dann mit Deinen Augen überprüfst obs zuckt oder nicht.

Zitat

Original von svenrender:

Aber leider zuckt es im Zoomplayer oder PowerDVD nie! Egal ob die Fields vertauscht sind oder nicht...

Zitat

Original von Harald66:

Hi,

Du sollst ja auch in TMPGEnc schauen!

Zitat

Original von svenrender:

Preview beim Encodieren??? Oder beim schneiden???

Zitat

Original von Harald66:

Hi,

beim Encodieren wäre etwas spät
Hab das Prog gerade nicht vor mir, und arbeite normalerweise ja mit dem CCE, deswegen jetzt etwas "Blindflug".
Auf der Seite, auf der Du diverse Filter in TMPGEnc auf das Video anwenden kannst (croppen, shcärfen, weichzeichnen, deinterlacen, u.s.w.) kommt doch auch ein Vorschaufenster, wenn Du auf eine der Auswahlmöglichkeiten Doüppelklickst. Unter dem Vorschaufenster kannst Du dann verschiedene Einstellungen ändern, wenn ich mich nicht irre, auch die Field Order.

Zitat

Original von svenrender:

Als erstes mal, kann ich keine MPEG-2 Filme direkt in TMPEG öffnen... Es funktioniert nur über AVISynth und DirectShowSource()....
Ich kann zwar die "Field oder" bestimmen bzw. ändern, doch in einem Vorschaufenster z.B. für "Source Range" kann ich keine Veränderung feststellen

Zitat

Original von Frank:

Ok, dann mal ganz schnell:
Die beste Methode zur Feststellung der Field Order

1. AVS Skript muss ok sein, in TMPGEnc laden.

2. Auf Settings klicken, Advanced auswählen.
Die Fieldorder sollte auf TFF (A) stehen.

3. Doppelklicken auf Deinterlace, es erscheint ein Monitorbild.
Methode Even-Odd field auswählen und aktivieren (Häkchen).

4. Wenn man den Film -> vorspult, dann darf nichts ruckeln,
dann ist der Film TFF codiert, andernfalls BFF!
In CCE bedeutet TFF, das UPPER FIELD FIRST nicht aktiviert sein darf! (Alter Bug)

Kontrolle mit verdrehter Fieldorder (Pkt. 2), dann ruckelts, wenn der Film TFF codiert ist.

Alles anzeigen

Zitat

Original von svenrender:

Jau, das scheint zu funkionieren! Thx!

EDIT: Hab in dem Zusammenhang ReStream angeschaut... Aber der erstellt ja immer eine neue Datei! Das dauert natürlich... Dabei muß doch für die Fieldorder nur der Header gepatcht werden... Gibt es da kein besseres Tool???

Zitat

Original von Harald66:

Hi,

nein, imo ist ReStream so ziemlich optimal.
Was auch noch geht ist der DVDPatcher.

Zitat

Original von P$ych025:

Hallo,

sorry das ich einfach hier rein poste, aber ich hätte da auch ein Frage dazu.

Da ich nun mit dem Capturn anfange wird das mit dem Deinterlacen ja auch aktuell für mich.
Ich weiß das wenn die Filed order vertauscht ist der Film ruckelt. Aber was ist die Fieldorder eigentlich und woher weiß ich wie die Fieldorder nun sein muss.

ein Link wäre auch OK, vieleicht nicht gerade den EDV-Tipp (hätte gern etwas leichtere Kost )

mFg

Alles anzeigen

Zitat

Original von svenrender:

P$ych025 hat folgendes geschrieben::

Aber was ist die Fieldorder eigentlich und woher weiß ich wie die Fieldorder nun sein muss.

Aber das wurde doch gerade in diesem Thead besprochen, wie man herrausbekommt ob die aktuelle Field-order korrekt ist oder nicht... Harald66: DVDPatcher kann leider nicht die Fieldorder ändern Wie geschrieben, bei ReStream wird immer eine zweite MPEG Datei erstellt, obwohl man ja nur den Header patchen muß (für die Fieldorder)

Zitat

Original von RB:

frank hat folgendes geschrieben::
In CCE bedeutet TFF, das UPPER FIELD FIRST nicht aktiviert sein darf! (Alter Bug)

Altes Missverständnis icon_smile.gif

Da der CCE ausschließlich ttf ausgibt (immer, unabhängig von diesem Häkchen!), wird bei aktivierter Option das Video vor dem Encoden um eine Zeile nach unten "gerollt", damit die field order für tff stimmt. Ergo muß "Upper Field First" nur bei bff interlaced Quellen aktiviert werden.

Alles anzeigen

Zitat

Original von Harald66:

Hi,

noch älteres Missverständnis:
tff im CCE nie aktivieren, sondern bei bff hinterher patchen. Sonst wird ja das Bild verschoben, und wer will das schon?

Zitat

Original von RB:

Die Geschichte des TFF im CCE ist eine Geschichte voller Missverständnisse... icon_lol.gif

Harald, Du vergisst daß wir hier von interlaced reden! Dabei kommt es doch nur auf die zeitlich korrekte Abfolge der fields an. Ein Fernseher stellt abwechselnd jeweils ein Halbbild dar, den interessiert es also nicht, ob das "verwebte" Bild das ein Computermonitor darstellen würde, nach unten verschoben ist. Hauptsache, das richtige Halbbild kommt zuerst. Der CCE arbeitet völlig korrekt, das ganze nachträgliche Bearbeiten kann man sich wirklich sparen.

Zitat

Original von Harald66:

Hi,

das sehe ich etwas anders. Durch das shiften des Bildes kommt es zu einer Verschiebung, die zum Einen die komplette Makroblockoptimierung beim resizen zu Nichte machen kann, zum Anderen enthält das Ergebnis nicht mehr das komplette Bild des Originals.
Entscheidend ist jedoch, dass der CCE immer tff macht. Wenn das Original jedoch bff war, dann stimmt die Reihenfolge der Halbbilder eben nicht mehr (immer vorausgestzt man bleibt interlaced). Das gibt dann eben u.U. ein unruhiges Bild, weil eben nicht das richtige Halbbild zuerst kommt. Das kann man nur verhindern, in dem man nie tff aktiviert und im Zweifelsfall, wenn man eben bff von DV hat, den fertigen Stream erst noch umpatcht.
Schau mal in die Suchfunktion hier und auf dem DVD-Board. Da hatten mb1, shh, YUV und ich einige Dinge zu dem Thema gepostet. Dürfet so etwa ein halbes Jahr her sein. Im Endergebnis hat shh damals auch die "CCE-Optimierung" aus FitCD rausgenommen, da sich herausstellte, das die wohl auch nur auf einem "Missverständnis" beruhte.

Zitat

Original von der Karl:

Moin,

..und nicht zu vergessen: Das verschieben um eine Zeile ist ein "fieldswap"!
Top wird zu bottom - und umgekehrt. Im Ergebnis sind Stufen in schrägen Kanten.
Das ist auf dem TV nur weniger gut zu sehen.

Um aus einem bff- ein tff-Video zu machen muß ein field verworfen und top- und bottom-field vertauscht werden.

Gruß Karl

Zitat

Original von RB:

Na klar muß ein Encoder ein field swap für eine bff-interlaced Quelle ausführen wenn er im output das tff-Flag setzt, was ist daran verkehrt? Ein Encoder erzeugt einen neuen Stream, er kann die Halbbilder in beliebiger Reihenfolge ablegen, Hauptsache er setzt das tff-Flag richtig.

Führen wir uns doch nochmal vor Augen, wie die Aufnahme und Wiedergabe von interlaced DV vor sich geht:

Die DV-Kamera nimmt ein Halbbild (field) auf und 1/50 Sekunde (PAL) später ein weiteres (irgendwie habe ich das Gefühl, ihr meint, es würden 25 Vollbilder pro Sekunde augezeichnet und das dann in Halbbilder zerlegt). Für bff wird nun das zuerst aufgenommene Halbbild im MPEG-Stream eben als "bottom field" und das zweite als "upper field" abgelegt und das tff-Flag nicht gesetzt. Die beiden Halbbilder haben zueinander keine "geometrische" Relation, lediglich eine zeitliche! So, der CCE encodiert solch einen Stream jetzt neu und setzt aus welchen Gründen auch immer im output immer das tff-Flag. Ergo muß der CCE natürlich einen "field swap" ausführen, damit ein Abspielgerät das richtige Halbbild (field) zuerst anzeigt, man muß ihn natürlich über das Aktivieren von "Upper Field First" dazu veranlassen. Wie da Treppenstufen entstehen sollen, ist mir schleierhaft, kann dann nur an fehlerhafter Abspielsoft/hardware liegen, die das tff-Flag nicht richtig auswertet.

Harald66:

Mit dem "verschieben um eine Zeile" habe ich mich vielleicht etwas unglücklich ausgedrückt, es ist natürlich ein Field Swap und es gehen keine Bildinformationen verloren. Auch ist die Bezeichnung "Upper Field First" im CCE sicher verwirrend, viele nehmen daher an, man müsste das entsprechend der field order der Quelle setzen, besser sollte es vielleicht "Swap fields because I always output tff" heißen icon_smile.gif Vielleicht deshalb ist diese Option im CCE 2.67 durch "Offset Line" ersetzt worden. Hier gibt man die Zeile des Quellmaterials an, welche die erste Zeile des vom CCE erzeugten top field sein soll, für bff-Quelle also 1, ansonsten 0. Bin mir nicht sicher, ob das nun einleuchtender ist, zumal man anscheinend beliebige Zahlen angeben kann icon_smile.gif ...

Alles anzeigen

Zitat

Original von svenrender:

RB hat folgendes geschrieben::
Die beiden Halbbilder haben zueinander keine "geometrische" Relation, lediglich eine zeitliche!

Entweder hab ich das falsch verstanden oder du hast da unrecht... Für mich haben die Haldbilder geometrisch miteinander zu tun... Genau deswegen können die genannten "Treppenstufen" entstehen, wenn die Fields vertauscht werden. Am besten sieht man es wenn man "Hardcore DeInterlaced":
SeparateFields().SelectEven()

Dabei sieht man ganz schön, gerade bei ruhigen Bildern in denen fast horizontale Linien verlaufen, das jedes Halbbild nur jede zweite Zeile darstellt. Natürlich liegen diese immer um 1/50sec auseinander...

Hier hab ich mal eben eine Seite gefunden, die das ganz gut Veranschaulicht:
http://www.saek-pentacon.de/f1/frames/

Doch wie kommt es übrhaupt dazu, das die Halbbilder hin und wieder mal vertauscht werden??? Es muß doch im MPEG-Strom klipp und klar drinstehen, welches zu erst kommt...
Ich dachte es liegt an meiner Methode mit DirctShowSource() zu arbeiten, die wohl nicht alle Informationen an AVISynth "weiterleitet"... Aber ich hab jetzt auch mit dem MainConcept erlebt, das die Fields vertauscht werden, obwohl ich als Imput direkt die MPEG Datei genommen hab...

Alles anzeigen

Zitat

Original von Harald66:

Hi,

na wenigstens können wir uns auf den FieldSwap einigen icon_wink.gif
Fest steht auf jeden Fall, dass die Methode des CCE bei aktiviertem tff
a. nicht wirklich sinnvoll ist (wieso nicht bff beibehalten?)
b. nicht wirklich gute Quali liefert
c. zu diversen Probs führen kann
Daher gibt es in meinen Augen nur eine sinnvolle Vorgehensweise:
Den Haken bei tff nie setzen, und wenn man mal wirklich bff Material hat, sich die Zeit nehmen und den fertigen Stream umpatchen.
Dann erhält man sauberes bff aus sauberem bff, was ja auch das Ziel ist.

Alles anzeigen

Zitat

Original von svenrender:

Wie werden überhaupt Interlace Bilder in MPEG behandelt??? Werden sie als Vollbilder komprimiert... Wird jedes halbbild einzeln komprimiert? Also wie SeparateFields()

Zitat

Original von Kika:

Bis auf den ProCoder behandeln alle Encoder beide Fields wie einen Frame. Allerdings kommen bei interlaced noch ein paar Feinheiten hinzu. Z.B. eine daran angepasste Bewegungssuche sowie eine andere Scanorder.
Der ProCoder hingegen kann beide Fields auch völlig getrennt encoden, was MPEG2 auch ausdrücklich erlaubt.

Zu FieldSwap und FieldOrder:

Jedes Field hat eine räumliche und eine zeitliche Position.
Ändert man die räumliche, hat man einen FieldSwap. Ändert man die zeitliche, hat man eine andere FieldOrder.

Field 1: Position 1 (F1P1)
Field 2: Position 2 (F2P2)

Bei einem FieldSwap vertauscht man die Fields. Es entsteht:
F2P1
F1P2

Bei einer falschen FieldOrder sieht's aber so aus:
F2P2
F1P1

Lustig wird's, wenn beides zusammen kommt:
F1P2
F2P1

Alles anzeigen

Zitat

Original von svenrender:

Kika hat folgendes geschrieben::
Der ProCoder hingegen kann beide Fields auch völlig getrennt encoden, was MPEG2 auch ausdrücklich erlaubt.

Nur mal so interessenhalber: Ist das Ergebniss wesendlich besser, wenn die Fields völlig getrennt encodet wird???

Zitat

Original von RB:

svenrender hat folgendes geschrieben::
RB hat folgendes geschrieben::
Die beiden Halbbilder haben zueinander keine "geometrische" Relation, lediglich eine zeitliche!

Entweder hab ich das falsch verstanden oder du hast da unrecht... Für mich haben die Haldbilder geometrisch miteinander zu tun...

Ich habe mich unglücklich ausgedrückt. Was ich meinte ist, daß es unwesentlich ist, welches Halbbild im MPEG2-kodierten Stream als upper (gerade Zeilen) oder bottom field (ungerade Zeilen) abgelegt ist, nur das tff-Flag muß entsprechend richtig gesetzt sein!

Harald66 hat folgendes geschrieben::
Fest steht auf jeden Fall, dass die Methode des CCE bei aktiviertem tff
a. nicht wirklich sinnvoll ist (wieso nicht bff beibehalten?)
b. nicht wirklich gute Quali liefert
c. zu diversen Probs führen kann

Zu a) : IIRC kommen einige ältere Player nicht mit bff zurecht.

Zu b) : Wie das? Der field swap verändert das Video doch überhaupt nicht.

Beispiel:

Wir haben eine bff-Quelle (upper field = A, bottom field = B), das zu dekodierende Frame ist also so aufgebaut:

A ----------------
B ----------------
A ----------------
B ----------------

Das tff-Flag ist nicht gesetzt, also würde ein Dekoder folgendes Bild ausgeben:

B ----------------
A ----------------
B ----------------
A ----------------

OK, der CCE macht jetzt ein field swap und kodiert das Ausgangsmaterial also so:

B ----------------
A ----------------
B ----------------
A ----------------

Er setzt aber auch das tff-Flag, ein Dekoder gibt also wiederrum

B ----------------
A ----------------
B ----------------
A ----------------

aus. Alles vollkommen OK.

zu c) : Welche?

Alles anzeigen

Zitat

Original von Harald66:

Hi RB,

zu a.
Zitat:
kommen einige ältere Player nicht mit bff zurecht

Kann ich nicht beurteilen. bff entspricht auf jeden Fall auch der Norm.

zu b.
Das haben Karl und Kika bereits erklärt.

zu c.
abgesehen von einem unruhigen Bild aufgrund der falschen Field Order (siehe auch Karls und Kikas Erklärung) kann es, wie schon mal geschrieben, die Makroblockoptimierung beim Resizen zu Nichte machen.

Alles anzeigen

Zitat

Original von RB:

Es gibt keine "falsche" field order, es gibt nur ein falsch gesetztes tff-Flag! Nur durch ein falsch gesetztes tff-Flag oder durch falsches Auslesen dessen beim Abspielen kann ein unruhiges Bild entstehen. Diesbezüglich gibt es keinen Bug im CCE. Einfache Regel: Häkchen bei Upper Field First im CCE nur für bff-Quelle setzen, sonst nicht.

Und das Problem mit der Makroblockoptimierung bei den Rändern kann man umgehen, wenn man (für bff-Quelle) den field swap gleich selbst im Skript vornimmt, danach resized und dann im CCE das Häkchen eben nicht setzt:

SeparateFields.ComplementParity
BicubicResize...
AddBorders...
Weave

Zitat

Original von Harald66:

Hi RB,

ich zitiere nochmals Karl:
Zitat:
Um aus einem bff- ein tff-Video zu machen muß ein field verworfen und top- und bottom-field vertauscht werden.

Und genau da liegt der Hase im Pfeffer. Der CCE verwirft eben dieses Field nicht, somit kommt es eben zu den Probs.

Zitat:
Es gibt keine "falsche" field order

Da hast Du recht, es gibt nur eine Field Order, die nicht zur "Reihenfolge" der Fields im Stream passt.

Was den Rest anbelangt, so verweise ich nochmal auf die einschlägigen Diskussionen auf dem DVD-Board (Karl, mb1, shh und Kika) und teilweise auf Amokinside (da hats mb1 auch noch mal ausführlich beschrieben, wenn ich mich recht entsinne). Hab jetzt leider keine Zeit die Threads alle zu suchen, musst Dir also selbst die Mühe machen.
Ansonsten belassen wirs dabei. Unsere unterschiedlichen Meinungen haben wir deutlich gemacht und erklärt, dann kann es jeder, der es austesten will, selbst versuchen.
Damit will ich die Diskussion keineswegs abwürgen, wenn sich also noch jemand anderes beteiligen will, immer zu ...

Alles anzeigen

Zitat

Original von svenrender:

Was an der Sache einfach Scheiße ist, das man beim entwickeln von Interlace PAL/NTSC Standard nicht einfach wirklich bindend vorgeschrieben hat, wann zuerst welches Halbbild kommt...

Hätte nan das in den Anfängen des Fernsehens gemacht, hätten wir jetzt nicht die Probleme damit

Zitat

Original von scharifs_Brain:

es war doch keine Notwendigkeit vorhanden, das festzulegen.
Dem TV ist es egal.
Ausserdem hat man damals doch nicht an die Probleme von heute gedacht.

Ausserdem war Interlacing nur eine Notloesung, mit der man Bandbreite und Technischen Aufand gespart hat.
Die Technik war vor 60 Jahren halt noch nicht so weit.

Zitat

Original von Kika:

Dieses einfach Untereinanderschreiben von ABAB usw. funktioniert nicht richtig. Dazu müsste man sich das "in Bewegung" ansehen.

Richtig (tff):

A1------
B1 ------
A2------
B2 ------

Field Swap:

B1 ------
A1------
B2 ------
A2------

Falsche Field Order:

Das kann man so nicht vernünftig darstellen. Sähe aus wie ein Field Swap, wäre aber ganz anders.
Richtig wäre es, wenn A1 entfällt und B1 anstelle von A1 angezeigt werden würde.

Encodet man tff als bff ohne irgendwelche Verschiebungen bzw. das Entfallen eines Fields, entsteht Müll. Wobei das mit dem Verschieben ja noch funktioniert, richtig ist es aber nicht, da eine Leerzeile entsteht.

Bei tff wird A1 angezeigt, dann B1, dann A2 usw.

Bei tff mit Field Swap wird nichts angezeigt, dann A1, dann B2, dann A2, dann B3, dann A3. B1 entfällt quasi. Die zeitliche Abfolge der Fields bleibt aber erhalten.
Sowas sieht völlig scheiße aus, weil das Motiv zeilenweise falsch zusammengesetzt wird.

Bei tff als bff encodet, also falscher Field Order, wird A1 an der Postion und zum Zeitpunkt, an dem eingentlich B1 erwartet wird dargestellt, dann das gleiche mit der Kombi aus A2 und B2. Zwar wird dabei dann nicht das Motiv falsch zusammen gesetzt, aber B1 erscheint eine fünfzigsten "zu früh". Der Effekt ist wie zwei Schritte vor, einer zurück.

Grober und einfacher kann ich's auch nicht erklären.

Alles anzeigen

Zitat

Original von RB:

Kika, bitte erkläre, was Du mit "Position 1" und "Position 2" meinst. Ich kann Dir nicht ganz folgen.

Bitte nochmal daran denken, "tff" ist ein Flag, ein Bit im MPEG-Header, das einem Decoder anzeigt, welches field zuerst ausgegeben werden soll, also welches field zuerst auf den (Fernseh)bildschirm, in die ungeraden Zeilen, geschrieben wird.

tff = 1 - das "upper field" (ungerade Zeilen) des Frame wird zuerst ausgegeben
tff = 0 - das "bottom field" (gerade Zeilen) des Frame wird zuerst ausgegeben

Von daher verstehe ich auch Deinen Kommentar "Dieses einfach Untereinanderschreiben von ABAB usw. funktioniert nicht richtig" nicht. Damit habe ich doch nur den Aufbau eines interlaced Frame (aus zwei Halbbildern per weave zusammengesetzt) beschrieben und was der CCE dann bei Aktivieren von "Upper Field First" macht.

Nochmal, bleiben wir bei dem Beispiel mit der DV Kamera. Diese nimmt für ein Vollbild ein Halbbild und 1/50 Sekunde später ein weiteres auf. Bezeichnen wir mal alle Zeilen des zuerst aufgenommenen Halbbildes mit 1Hx und alle Zeilen des zweiten mit 2Hx (x für die Zeile des Halbbildes). DV ist nun üblicherweise tff=0 (oder "bff" wer den Terminus lieber mag), also ist ein Frame im resultierenden interlaced AVI so aufgebaut:
Code:

Zeile 1 im Frame -> 2H1 -------------
Zeile 2 im Frame -> 1H1 -------------
Zeile 3 im Frame -> 2H2 -------------
Zeile 4 im Frame -> 1H2 -------------
...

Am Bildschirm müssen die Halbbilder natürlich entsprechend ihrer temporalen Relation ausgegeben werden, deshalb ist der Stream tff=0 und die Dekodierung/Anzeige sollte so erfolgen:
Code:

Zeile 1 am Bildschirm -> 1H1 -------------
Zeile 2 am Bildschirm -> 2H1 -------------
Zeile 3 am Bildschirm -> 1H2 -------------
Zeile 4 am Bildschirm -> 2H2 -------------
...

Da der CCE immer tff=1 setzt, sollte er natürlich bei solch einer Quelle vor dem Kodieren einen field swap durchführen, also Tauschen von Zeile 1 mit Zeile 2 im Frame, Zeile 3 mit Zeile 4 usw. Dazu veranlasst man ihn mit der zugegebenermaßen verwirrend bezeichneten Option "Upper field first". Das Vertauschen der Zeilen und das gesetzte tff=1 heben sich sozusagen gegenseitig auf, das Resultat ist genauso perfekt wie ein Encoden ohne field swap und tff=0.

Ich fürchte, besser kann ich's nicht erklären icon_smile.gif

Harald66 hat folgendes geschrieben::

Da hast Du recht, es gibt nur eine Field Order, die nicht zur "Reihenfolge" der Fields im Stream passt.

Die "Reihenfolge" der Fields im Stream (ich nehme an, du meinst damit welches Halbbild welche Zeilen des Frame belegt) ist vollkommen egal. Nur muß das tff-Flag richtig gesetzt sein.

Harald66 hat folgendes geschrieben::

ich zitiere nochmals Karl:
Zitat:
Um aus einem bff- ein tff-Video zu machen muß ein field verworfen und top- und bottom-field vertauscht werden.

Und genau da liegt der Hase im Pfeffer. Der CCE verwirft eben dieses Field nicht, somit kommt es eben zu den Probs.

Das müsste man tatsächlich machen, wenn man einen Player hätte, der mit bff nichts anfangen kann (und natürlich noch 20 ms Audio am Anfang wegschneiden). Der CCE macht das aber nicht (wozu auch?), er tauscht pro Frame die Zeilen (s.o.) und setzt das tff=1. Mit anderen Worten, er kodiert das Video so neu, daß der ursprüngliche Stream mit tff=1 richtig wiedergegeben wird.

Alles anzeigen

Zitat

Original von RB:

RB hat folgendes geschrieben::
Da der CCE immer tff=1 setzt, sollte er natürlich bei solch einer Quelle vor dem Kodieren einen field swap durchführen, also Tauschen von Zeile 1 mit Zeile 2 im Frame, Zeile 3 mit Zeile 4 usw.

Sorry, muss mich korrigieren. Der CCE verschiebt tatsächlich den ganzen Frame um eine Zeile nach oben, wenn man Upper Field First aktiviert. Zwar nicht der Weisheit letzter Schluß, das Ergebnis beim Abspielen ist aber dennoch korrekt. Wem das bei den optimierten Rändern in die Quere kommt, kann das wie gesagt über einen echten FieldSwap in AVISynth und das Ausschalten von Upper Field First im CCE lösen.

Zitat

Original von Harald66:

Hi RB,

dann sind wir uns am Ende doch noch einig geworden, das tff im CCE nicht zu aktivieren. icon_wink.gif
Wobei ich immer noch das umpatchen einem FieldSwap via Avisynth vorziehen würde.

Zitat

Original von Der Karl:

Moin,

>dann sind wir uns am Ende doch noch einig geworden, das tff im CCE nicht zu aktivieren.

Tff ist schon richtig icon_razz.gif - "upper field first" muß aus (doofe Bezeichnung).

>Wobei ich immer noch das umpatchen einem FieldSwap via Avisynth vorziehen würde.

Ich verstehe nicht, was das mit dem umpatchen noch soll. Man kann doch vor dem encoden
im AVISynth sauber die Fieldorder ändern (doubleweave().selectodd() ), dann braucht man gar nix
mehr patchen.
In FitCD ist das ja schon seit einigen Versionen mit drin.

Wer spaß dran hat, kann ja die 20ms Tonversatz noch ausgleichen (wenn er das denn hört - ich nicht!).

Alles anzeigen

Zitat

Original von svenrender:

ich bin ja so deppert...
Mit einem SeparateFields() kann man doch direkt in VirtualDub sehen ob die Fields richtig sind!

Also, AVS schreiben:
DirectShowSource("...")
SeparateFields()

in VirtualDub öffnen und mit Strg-F5 schauen ob es zittert...
Müßte gehen... Teste ich mal...

So:
Ich hab jetzt mal mit ReStream alle Varianten erstellt:
top field first eingeschaltet + ausgeschaltet
und progrssiv (mit tff aus)

Bei allen drei MPGs zittert es mit SeparateFields()!!!!!!!!!
Nur ein ComplementParity() beseitigt das Problem... Liegt es an den DirectShow Filtern??? Die Ligos weg die PowerDVD rein... Das selbe...

Alles anzeigen

Zitat

Original von Der Karl:

Moin,

>Nur ein ComplementParity() beseitigt das Problem... Liegt es an den DirectShow Filtern???

Nein. AVISynth interpretiert jeden stream als bff (VDub als tff).
Wenn Du also mit einem tff-stream reingehst, ist ein ComplementParity() Pflicht.

Gruß Karl

Zitat

Original von RB:

Der Karl hat folgendes geschrieben::
Nein. AVISynth interpretiert jeden stream als bff (VDub als tff).

Nicht immer. Wenn man mpeg2source verwendet, wird bff und tff richtig erkannt und auch an AVISynth weitergereicht. Ob AVISynth das Video gerade als bff oder tff erkennt, kann man leicht nachprüfen, indem man folgende Zeile in das AVS-Skript einfügt und es probeweise anspielt:

Code:

Subtitle(String(GetParity?"TopFirst":"BottomFirst"))

Alles anzeigen

Zitat

Original von Der Karl:

Moin,

>Nein. AVISynth interpretiert jeden stream als bff (VDub als tff).

Damit war "Directshowsource()" und "AVISource()" gemeint. Habs aber nicht explizit geschrieben.

Wobei auch bei MPEG2source() sich die 1.x und 2.x-AVISynth-Versionen verschieden verhalten.

>Subtitle(String(GetParity?"TopFirst":"BottomFirst"))

Das geht meines wissens auch erst ab 2.x.

Gruß Karl

Alles anzeigen