Analog Capture mit DV Codec

[RS1980]

Ich geb mich noch net geschlagen, wenn ich demnächst mal Zeit haben sollte, dann mach ich mich dran und probier das mal aus bis es klappt ;-))

[orchidee]

@RS1980
Genau, ich geb auch noch nicht auf und werd das auch noch mal probieren. Dabei habe nun folgende Theorie: Das DV-Video ist richtig, wenn in der Einzelbilddarstellung die Halbbilder geometrisch richtig angeordnet sind (nicht immer leicht zu sehen) und das Video vom Tmpgenc-Wizard als bff erkannt wird. Je nach dem, was man nun beim Capturing für ein Video herausbekommen hat, lassen sich folgende Fälle unterscheiden:
1.) Halbbildanordnung richtig/ Tmpgenc - bff
benötigte Aktion in Vdub: keine
2.) Halbbildanordnung richtig/ Tmpgenc - tff
benötigte Aktion in Vdub: field swap + phase shift
3.) Halbbildanordnung falsch/ Tmpgenc - bff
benötigte Aktion in Vdub: phase shift
4.) Halbbildanordnung falsch/ Tmpgenc - tff
benötigte Aktion in Vdub: field swap

Der field swap-Filter ist ja bei Vdub dabei, die anderen sind im smart deinterlacer integriert, man muß nur den eigentlichen Deinterlacer abschalten.
Das könnte zwar so funktionieren, aber es besteht die Gefahr, daß das Video nach der einen oder anderen Behandlung und anschließendem Encoden (mpeg-2) bobbing zeigt.

Naja, wie gesagt, das ganze ist nur so ne Theorie von mir und kann kompletter Blödsinn sein. Aber nur durch probieren kriegen wir das raus.

[Der Karl]

Es ist so, wie Orchidee schreibt.
Vorausgesetzt, die Capture-Karte erzeugt nicht selbst noch dynamische phase-shifts.

Gruß Karl

[Gunnar]

> Genau, ich geb auch noch nicht auf und werd das auch noch mal probieren
Und dazu geselle ich mich auch noch, ich will das es funktioniert ;) . Muß mir noch mal die Infos über die Fieldschweinereien raussuchen. Außerdem möchte ich die ganze Prozedur mit Avisynth erledigen, wenn es geht.


Gruß Gunnar
_________________
Gruß Gunnar

[orchidee]

Also, zum Encoden bin ich gestern nicht mehr gekommen, da ich mich erstmal mit der der etwas eigenwilligen Arbeitsweise des Smart Deinterlacers vertraut machen mußte.
Also ich habe zunächst mal ein paar Schnipsel vom TV gecaptured (verschiedene Sender; sowohl mit DV, als auch mit MJPEG-Codec). Schon nach relativ kurzer Zeit hatte ich nun Material für 3, der von mir beschriebenen 4 Szenarien:
1.) Halbbildanordnung richtig/ Tmpgenc Wizard sagt - bff
2.) Halbbildanordnung richtig/ Tmpgenc Wizard sagt - tff
3.) Halbbildanordnung falsch/ Tmpgenc Wizard sagt - bff

Zu 2.) beim Smartdeinterlacer muß nun folgendes aktiviert sein:
-disable motion processing
-field swap before phase shift
-phase shift
Die Option "field swap before phase shift" allein bewirkt nämlich nur einen field swap (ohne phase shift). Nun scheint es so zu sein, daß der phase shifter immer von einer buttom-Dominanz ausgeht, daher erhält man bei "field swap after phase shift" ein anderes Ergebnis, nämlich einen Stream, der offenbar so aussieht:
t1  t2  t3
b3  b4  b5

zu 3.) beim Smartdeinterlacer muß nun folgendes aktiviert sein:
-disable motion processing
-phase shift

zu 1.) Hier habe ich testweise mal versucht, daraus einen Stream zu machen, der vom Tmpgenc-Wizard als tff angesehen wird:
-disable motion processing
-field swap after phase shift
-phase shift
bringt hier das richtige Ergebnis.

Hoffentlich werden diese Streams nun auch vom CCE richtig encodet (ohne bobbing).

[RS1980]

Kurze Zwischenfrage:
Smartdeinterlacer?
Was ist das, hört sich ja gefährlich an...
Der Film soll ja interlaced bleiben, oder was macht das Programm ?



Zuletzt bearbeitet von RS1980 am Sep. 26 2002,22:14

[Gunnar]

Ist eigentlich ein Deinterlacer aber mit "disable motion processing" kann man das wohl deaktivieren und mit den anderen Funktionen wie "orchidee" beschrieben hat die Fields wieder richten. Ich teste das morgen auch mal.

Gruß Gunnar



Zuletzt bearbeitet von Gunnar am Sep. 25 2002,23:52
_________________
Gruß Gunnar

[orchidee]

Also bei mir funzt jetzt alles. Alle encodeten Streams werden von meinem "Stehallein" richtig abgespielt.
Noch ein wichtiger Hinweis: Wie mb1 erwähnte, muß man beim Wizard der Tmpgenc Vers. 2.58 aufpassen. Wenn man hier das DV-Material direkt einlädt, so wird der Field-Order-Check nicht ausgeführt (es erscheint auch kein Statusbalken), sondern es wird einfach bff angenommen. Wenn man das Video aber über den VDub-Frameserver einlädt, dann wird wieder analysiert.

[Gunnar]

> Also bei mir funzt jetzt alles
Bei mir klappt es jetzt auch. Mein AVI muß mit ...

-disable motion processing
-field swap before phase shift
-phase shift

... bearbeitet werden. Da ich aber eine Lösung für Avisynth gesucht habe ist folgender simpler Trick anzuwenden:

Beispiel 720x576
Crop(0,1,720,575).AddBorders(0,0,0,1)

"SwapFields" oder "SeparateFields.ComplementParity.Weave" darf in meinem Fall nicht angewendet werden weil wohl Avisynth immer von bff ausgeht.

Es gibt zwar keine Lösung direkt mit einer TV-Karte einen DV-Konformen Stream erzeugen aber es klappt wenigstens in einem zweiten Durchgang.

Gruß Gunnar



Zuletzt bearbeitet von Gunnar am Sep. 27 2002,21:44
_________________
Gruß Gunnar

[orchidee]

Hallo Gunnar,
schön, daß es jetzt auch bei dir klappt. Allerdings ist mir eins nicht ganz klar, nämlich warum dein avisynth-Script funktioniert. Dieses bewirkt doch nur einen field-swap oder? (ich kenne mich mit avisynth nicht so gut aus, also hilf mir auf die Sprünge)
Erwartet hätte ich ein Script wie dieses hier,

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

welches "Der Karl" ja schon in einem anderen thread veröffentlicht hat.

[Gunnar]

So ganz klar ist mir die Sache auch nicht. Wenn die TV-Karte/Treiber Kombi einen TTF-Stream erzeugt aber mit einem DV-Codec (BFF) encodet wird ensteht eine flasche Fieldorder und das Video ruckelt auf dem TV-Bildschirm (wie bei mir). Wenn man nun eine FieldSwap durchführt müßte eigentlich alles wieder im Lot sein aber es ruckelt immer noch. Ob da Avisynth irgendeinen Murks macht ? Jedenfalls brauche ich nur einen Phase Shift im Script einzufügen und es klappt. Vielleicht kann der Karl Licht ins Dunkel bringen.

> welches "Der Karl" ja schon in einem anderen thread veröffentlicht hat.
Wo ist dieser Beitrag ?

Gruß Gunnar



Zuletzt bearbeitet von Gunnar am Sep. 29 2002,12:22
_________________
Gruß Gunnar

[orchidee]

@Gunnar
hier ist der Link: http://www.dvd-svcd-forum.de/phorum....4;t=346

[Gunnar]

Danke für den Link.

Hier meine Vermutung.
Original:

T1 T2 T3 T4 T5
B1 B2 B3 B4 B5

Die Karte/Treiber-Kombi verursacht einen Phase Shift

B1 B2 B3 B4 B5
T2 T3 T4 T5 T6

Der DV-Codec (bff) dreht die ganze Sache wieder

T2 T3 T4 T5 T6
B1 B2 B3 B4 B5

So liegt das Video auf der Platte. Nun wird es in Avisynth geladen und wieder (gewollt) ein Phase Shift gemacht

Crop(0,1,720,575).AddBorders(0,0,0,1)
AssumeFrameBased.SeparateFields
(Resize usw.)
Weave

"SeparateFields" legt beide Fields (pro Frame) hintereinander und verdoppelt die Framerate (720x288) auf 50Hz. Es wird aber auch quasi ein Swap (ungewollt) gemacht und dadurch ensteht ...

T2 T3 T4 T5 T6
B2 B3 B4 B5 B6

... und es stimmt wieder. Avisynth geht immer von bff aus. Das kann man durch "AssumeTFF" verhindern ist aber in meinem Fall nicht nötig.

Ob das nun stimmt was ich geschrieben habe müßte mal ein Profi überprüfen.

Gruß Gunnar



Zuletzt bearbeitet von Gunnar am Sep. 29 2002,16:34
_________________
Gruß Gunnar

[orchidee]

@Gunnar
Auch wenn ich kein Profi bin, so scheint mir deine Theorie doch irgendwie nicht ganz stimmig zu sein.
Hier mal meine:
Wir gehen von einem Input-Stream aus, der so aussehen soll:
b1t1b2t2b3t3.., wobei die zeitliche Abfolge richtig sein soll, wenn das buttom, vor dem zugehörigen top-field kommt.
Daraus macht die Capture-Karte dann z.B.:
t1 t2 t3 t4
b2 b3 b4 b5
Dieser Stream ist absolut ok, wenn man ihn als tff betrachtet, die Reihenfolge der Darstellung ist dann nämlich wieder:
t1b2t2b3t3 (also wie im Ausgangsstream)
Diese Art erhalte ich fast immer, wenn ich mit meiner TV-Karte und MJPEG-Codec aufnehme.
Der DV-Codec scheint tatsächlich zu vertauschen, also:
b2 b3 b4 b5
t1 t2  t3 t4
Dieser Stream ist ok, wenn man ihn als buttom-Dominant betrachtet (t1b2t2b3t3..), jedoch sind buttom und top-fields in der progressiven Darstellung räumlich vertauscht. Außerdem stimmt die Paarigkeit (b2t1) nicht, was aber für interlaced Videos unerheblich ist.
Solche Streams erhalte ich fast immer, wenn ich mit DV-Codec capturere. Um dies nun wieder hinzubiegen ist lediglich das wegwerfen von t1 nötig ("buttom dominanter" phase shift), wodurch sich:
t2 t3  t4  t5
b2 b3 b4 b5    ergibt. Dieser Stream muß auch als bff angesehen werden.

In deinem Fall scheint aber etwas anderes zu passieren:
Also beschreibe es nochmal genau: wie wird dein Video vom Tmpgenc-Wizard erkannt, wenn du es von Vdub frameservest?
Wie sieht die progressive darstellung in Vdub aus, sind die Halbbilder geometrisch vertauscht? Ferner kann es evtl. auch sein, daß ein buttom field nicht dem zeitlich nächsten, sondern übernächsten top-field zugeordnet wurde. Dabei sieht progressiv zunächst fast alles ok aus, aber bei Bewegungen sieht man nicht nur interlaced-Streifen, sondern richtige Doppelbilder. Achte auch auf diesen Effekt.

Unklar ist mir aber immer noch, warum
Crop(0,1,720,575).AddBorders(0,0,0,1)
einen phase shift erzeugen soll!!!!!

[Gunnar]

Ja kann sein das ich einen Denkfehler mache und "Phase Shift" nicht richtig kapiert habe. Ich werde mal stark bewegte Szenen capturen und den Stream auseinander nehmen ... jetzt will ich´s wissen

EDIT: Und was für einen Denkfehler ... habe ein ganzes Field mit einer einzelnen Zeile verwechselt.

> Crop(0,1,720,575).AddBorders(0,0,0,1)
Dadurch wird natürlich kein Phase Shift erzeugt. Faß an den Kopf ...



Zuletzt bearbeitet von Gunnar am Sep. 29 2002,18:35
_________________
Gruß Gunnar

[Gunnar]

Und weiter geht´s ...

> wie wird dein Video vom Tmpgenc-Wizard erkannt ...

Wie immer mit einem DV-Codec (Panasonic) aufgenommen.

Ohne VD-Filter -> Field A -> Bild ruckelt nicht und sieht sauber aus.
Mit Fieldswap -> Field B -> Bild ruckelt nicht sieht aber unsauber aus (Zeilen vertauscht).
Mit Phase Shift -> Field B -> Bild ruckelt.
Field Swap after Phase Shift -> Field A -> Bild ruckelt.
Field Swap bevor Phase Shift -> Field B -> Bild ruckelt nicht und sieht sauber aus.

Spiele ich das AVI direkt über meine Schnittkarte oder Camcorder ab (TV) ruckelt es.

Ich hab im Moment den Durchblick verloren und muß mal ne Nacht drüber schlafen.

Gruß Gunnar
_________________
Gruß Gunnar

[orchidee]

Hm,

[Gunnar]

EDIT: Alles "Sherlock Humbug" was ich geschrieben hatte, also ab in die Tonne damit. -> CUT
--------------------------------------
Die ganze Sache läuft viel einfacher ab:

Meine TV-Karte/ Treiber liefert den Stream ganz sauber ...

T1 T2 T3 T4 usw.
B1 B2 B3 B4 usw.
(ttf)

... der DV-Codec (Panasonic) nimmt es so wie es kommt und encodet das Ganze. Es bleibt beim:

T1 T2 T3 T4 usw.
B1 B2 B3 B4 usw.
(ttf)

Abspielen kann man das natürlich nicht über eine DV-Karte oder Camcorder ohne Ruckelei. Hier muß der Stream zwingend (bff) haben was ja nicht der Fall ist. Die zeitlich ersten Fields  (bezogen auf den Inhalt) sind in der T-Reihe zu finden. Encoden (ttf) mit Tmpgenc, CCE oder sonst einem Encoder klappt natürlich ohne Ruckelei hinterher.

Wenn nun, aus welchen Gründen auch immer, das Video geschnitten und über eine Timeline direkt über die entsprechende Hardware auf dem TV abgespielt werden oder auf einem VCR aufgenommen werden soll, muß der ursprüngliche Stream vorher bearbeitet werden. Was für ein langer Satz
Nochmal, es geht mir nur darum mit einer TV-Karte DV-Konformität zu erreichen. Das ein CC mit Analog-In das Ganze besser kann is klar. Also ...

1. Mit Huffyuv 704x576 24bit aufnehmen.
2. Fieldorder wechseln, Crop(0,1,720,575).AddBorders(0,0,0,1), ggf. croppen, resizen und mit Border auf 720x576 auffüllen (FitCD).
3. Nochmal mit DV-Codec encoden.

Nun ist zumindest der Videostream konform und kann über die Timeline auf den Empfänger abgespielt werden. Der Ton allerdings kracht und ist verstümmelt ... bei mir jedenfalls. Der muß gesondert behandelt werden.

Gruß Gunnar



Zuletzt bearbeitet von Gunnar am Okt. 03 2002,14:34
_________________
Gruß Gunnar

[mmp40]

hallo ihr zwei,

wenn ich mal schon sooo weit wäre.
Ich will DVD von externen DVD-Player über die GraKa (Geforce 4 Ti4600 ViVo) auf den Pc bringen/aufnehmen/capturen um dann VCD oder SVCD draus zu machen.

Mit VDub bekomme ich ein bild von der Farb-Film-DVD (also über externem DVD-Player =>VIn GraKa => PC-VDub),
aber :
1. ist das bild immer s/w
2. im Preview-mode ist in der mitte noch ein dicker weißer, waagerechter querbalken drin.

Gleiche prozedur mit einer VCD (anstattDVD) im ext.-DVD-Player :
==> kein weißer querbalken, aber nur s/w-bild.

Als Treiber habe ich die WDM-treiber von window und den nvidia von der GraKa.

Könnt ihr mir helfen, oder habt einen Tipp

gruß mmp40

[orchidee]

Ich weis zwar nicht, wiso du die DVD nicht einfach rippst, aber zu deinem Problem habe ich schon mal was gehört.
1. Wenn du den S-Video-Eingang deiner GraKa benutzt, so muß natürlich auch ein vollwertiges S-Video-Signal eingespeist werden - sonst s/w-Bild. Ferner muß meist auch noch softwaremäßig angegeben werden, das S-Video-In und nicht Composit-In genutzt wird.
2. Das Problem mit dem weißen Balken kenne ich auch irgendwo her, in Verbindung mit den Asus ViVo-Karten (nvidia-Chipsatz). Am besten du schaust mal auf dem DVDBoard im "Capture"-Forum nach und suchst dort mit "v7700" oder "v3800". Ich glaube bei WinXP mußt du den Display-Treiber deines GraKa-Herstellers zusammen mit dem Referenz-Capture-Treiber (wdm 1.08) von nvidia anwenden. Zusätzlich benötigst du noch eine WDM-taugliche "Dummy"-Capture-Software, die einmal nach dem booten gestartet werden muß, damit Vdub läuft (bin aber nicht ganz sicher).