Analoges Capturing = interlaced ! aber warum bei mir nicht ?

1)

Assumetff()
separatefields().selectevery(4,1,2).weave()

erzeugz BFF!
es muss 4,0,3 heissen!

2) wenn die frames nach tdeint(mode=1) duplikate sind, solltest Du mal telecide anstatt tdeint nehmen. (dann kann auch das reinterlacing weg!)

Moin,

nee - das "Video" ist progressive und die Karte (der Chip) arbeitet bff.
Also kein "AssumeTff", sondern "AssumeBff" bzw. ganz weglassen und Doubleweave().SelectOdd() hintendran...

Gruß Karl

Zitat

Zitat

Aha, ich wusste gar nicht das es sowas gibt, in meinem Hirn blieb immer hängen analoges Capturing ist interlaced und tff.
Wieder was gelernt.

Natürlich ist das "Verfahren" interlaced, aber wenn die Quelle progressive ist (war) ist das Ergebnis auch wieder progressive, wenn man es richtig zusammensetzt...
TV-Karten arbeiten (fast) alle tff - Grakas mit VI (video in) je nach chip - auf der Asus v7700 ist ein Philips 7113, der arbeitet halt bff. Im Grunde kommts ja drauf an, wie man anfängt (Auswertung des VBI - vertical blanking interval) und das macht ja eigentlich der Treiber; die Philips 7108/7113 mit den nVidia WDM-Treibern machen eben bff - na und!

Zitat

Dann müsste ich die Kammertefakte im gecapturetten AVI ja eigentlich auch mit Telecide weg bekommen und kann mir den ganzen Interlaced Kram sparen ?

Klar kannst Du auch telecide nehmen - aber wenn keine dynamischen wechsel drinsind, erfüllt DoubleWeave().SelectOdd() die gleiche Aufgabe - erstes field wegschmeißen und die fo umdrehen - aus bff wird tff, bzw. in diesem fall progressive. Da ist es dann völlig egal, wie man weitermacht....

Gruß Karl

Zitat

In einem älteren Thread habe ich eine Diskussion von Dir und Kika gelesen, deshalb nahm ich an Assumetff und dann separatefields().selectevery(4,1,2).weave() erzeugen tff .

Das war dann aber eine ältere Diskussion. Da ging's dann mit Sicherheit um die Befehle in AVISynth, bei denen das tatsächlich so ist, also genau genommen einen Bug.

Ganz korrekt wäre die Aussage sowieso nicht, denn sie muss wie folgt lauten:

separatefields().selectevery(4,1,2).weave()
Das vertauscht die Fieldorder.

separatefields().selectevery(4,0,3).weave()
Das lässt die Fieldorder unangetastet.

Poste doch mal das script, wo es bei bff ruckelt...

Nein - der Picvideo ist nicht schuld - es geht ja nicht um Codecs, sondern um Inhalte.
Swapfields wäre völlig verkehrt.

Gruß Karl

Hi

Angeregt durch den Thread habe ich das auch mal ausprobiert.

AVISOURCE("H:\test.avi",pixel_type="YUY2")
Assumetff()
TDeint(mode=1)

Kann ich signs "Phänomen" bestätigen, gerades Frame ist immer die Kopie des vorherigen ungeraden Frames.
0= ist die Kopie von -1 ? , 2 ist die Kopie von 1 , 4 ist die Kopie von 3 usw.

Ist mir vorher noch nie aufgefallen (ok. habe nie analoges VHS mit der ASUS gecapturet) .

Lasse ich Assumeetff mal weg, also arbeite im bff
AVISOURCE("H:\test.avi",pixel_type="YUY2")
TDeint(mode=1)

So ergibt das das absolute Frameanordnungschaos:
Frame 0 ist ganz normal, Frame1 ist ein frame vor 0 (oder dessen identische Kopie) , 2 ist wiederum ganz normal, 3 ist die Kopie von 0, 4 ist ganz normal 5 ist die Kopie von 2, 6 wiederum ganz normal, 7 ist die Kopie von 4 usw.
Scrollt man durch VDUB so gibs den reinsten Wackelpudding.
Um das richtig anordnen zu können muss man 1,0,3,2,5,4,7,6,... usw. auslesen.

Ob man das nun mit SelectOdd.DoubleWeave berichtig oder wie auch immer, keine Ahnung, einfach Assumetff und SelectOdd wäre dann wohl der einfachere Weg um 25 Vollbilder zu erhalten.

Oder eben gleich mit "Telecide" arbeiten, allerdings höchstens mit der Decomb 511, die neue DecombLegacy ist ja Readme Technisch fast undurchdringbar.

Allerdings fällt mir der passende Telecide Befehl bei beiden Situationen jetzt nicht ein, ich arbeite einfach zu selten damit und die Readme der neuen Version hat mich eher abgeschreckt als zu einer Aktualisierung verleitet.



max

Moin Max,

ist doch klar! TDint wird (mit Mode=1) als bobber betrieben = double framerate. Dann ist bei progressivem Input natürlich jedes 2. Frame doppelt.

Ansonsten ist das natürlich nicht egal, was man in AVISynth macht!

Zitat

AVISOURCE("H:\test.avi",pixel_type="YUY2")
Assumetff()
TDeint(mode=1)

Das ist zweimal falsch, also (zufällig) wieder richtig!

Korrekt wäre das so:

Zitat

AVISOURCE("H:\test.avi",pixel_type="YUY2")
Assumebff() <- kann auch entfallen, weil Standard
TDeint(mode=1, order=0)

oder so:

Zitat

AVISOURCE("H:\test.avi",pixel_type="YUY2")
DoubleWeave().SelectOdd() <--- bff -> tff
Assumetff() <- kann auch entfallen..
TDeint(mode=1)

Gruß Karl

Zitat von Max

Allerdings fällt mir der passende Telecide Befehl bei beiden Situationen jetzt nicht ein, ich arbeite einfach zu selten damit und die Readme der neuen Version hat mich eher abgeschreckt als zu einer Aktualisierung verleitet.

Funktioniert einer der beiden Telecide-Befehle aus Decomb 5.1.1?:

Telecide(order=0,guide=2,post=0)
Telecide(order=1,guide=2,post=0)

cu, grua

Zitat von Karl

Korrekt wäre das so:

AVISOURCE("H:\test.avi",pixel_type="YUY2")
Assumebff() <- kann auch entfallen, weil Standard
TDeint(mode=1, order=0)

Dazu ein Auszug aus der TDeint-Readme (Ver. 0.9.7):

Zitat

order:

Sets the field order of the video.

-1 - use parity from AviSynth
0 - bottom field first (bff)
1 - top field first (tff)

default - -1 (int)

Somit müsste man den order-Parameter doch weglassen können, da er defaultmäßig ja aus AviSynth ermittelt wird:

AVISOURCE("H:\test.avi",pixel_type="YUY2")
TDeint(mode=1)

müsste also das selbe liefern wie AVISOURCE("H:\test.avi",pixel_type="YUY2")
TDeint(mode=1, order=0)

da ja AviSource BFF meldet.

Es ist also nur wichtig vor TDeint(mode=1) das richtige AssumeTFF bzw. AssumeBFF zu setzen, den Rest regelt TDeint dann alleine.

cu, grua

Ja Grua - im Prinzip hast Du recht.
ABER: Ich traue solchen Automatismen nicht, denn dann dürfte das:

Zitat

AVISOURCE("H:\test.avi",pixel_type="YUY2")
Assumetff()
TDeint(mode=1)

bei bff-input nicht funktionieren.

Gruß Karl

karl:

ob man nun die fieldorder über assumeXff() oder den order-parameter festlegz ist wurscht.

beide setzen nur ein Flag!

order übergeht ein vorheriges assumeXff()

assumexff ist aber die sauberere Methode, scriptingmäßig.

ohne order-parameter wertet TDeint nur das zuvor mit assumeXff() gesetzte Flag aus.

Also nix mit automatismus

Hi

da hat der Karl mal wieder recht und ich gestehe, zu meiner Schande, ich habe die Readme von TDeint gar nicht gelesen, sondern einfach nur signs Script kopiert und nachgesehen.
Somit ergibt natürlich die ganze Sache einen Sinn

Und nun wird streng mathematisch negativ x negativ gleich positiv, die Frameanordnung bereichtigt.

Aber im Prinzip ja egal, wie scharfie schon sagte, denn wenn man nix Assume technisches in das Script schreibt muss man bei TDeint ordern , aber eben Order=1 (also tff ? ) , oder halt Assumeen und TDeint auf Default belassen.

Mein Problem gerade, oder besser signs Problem, die Source kann dann doch nicht bff sein oder wie ?
Denn wie gesagt belässt man alles auf bff gibs Anordnungsprobs, erst bei tff flag wirds zumindest Anordnungstechnisch korrekt.
Zum Glück capture ich nicht so.

Allerdings stellt sich da die Frage ob man überhaupt mit Tdeint arbeiten sollte ?

Ich glaube ja, denn durch einfaches DoubleWeave.SelectOdd. Verbleiben Kammstruckturen in den Frames, so zumindest sehe ich das gerade in VDub.
Oder halt mal Telecide antesten, das dürfte zumindest bedeutend schneller gehen als mit Tdeint.


max

Moin again,

erstmal eine Korrektur: Ich hatte im "Hinterkopf", daß TDeint standardmäßig von "order=1" ausgeht. Das ist nicht so - richtig ist "order=-1", woe Grua ja auch geschrieben hat.

Meine Vermutung war, daß TDeint da irgendwie unsauber mit der Fieldparity umgeht. Nachdem ich das jetzt mal mit "echtem" bff- Material (DV-Capture) nachgebaut habe, hat sich das auch nicht bestätigt = TDeint arbeitet korrekt.

Die Frage ist jetzt, was Ihr da für Material getestet habt; Ich habe ja selbst lange Zeit mit Asus-Karten (V3800, V7700) gecappt und die haben immer bff geliefert.

Kann mal Jemand ein paar Frames mit viel Bewegung von diesem "strittigen" Material hochladen?

Gruß Karl

Hi

ich habe nur ISDN also nur ein paar frames meines Testmaterials, Beginnend mit frame 500 bis frame 508 , ein VHS Capture, ergo frame0 bis 8 .
Laufende Affen dürften ein fieldorder Prob auch bei diesen wenigen frames ersichtlich machen, denn wenn Sie in Ihrer Vorwärtsbewegung eingeschränkt sind, fällt das auf.

Mehr geht nicht sonst bin ich stundenlang am upload aber 8 frames müssten ja reichen.

Achja, liegt bei Lycos und Lycos macht immer Ärger bei Videodateien, einfach ....avimax Dateiendung in avi umbenennen.

Videocodec ist PICVideo, um die Datei möglichst klein zu kriegen wurde beim capturen schon gecroppt .Alte kaputte VHS, aber Qualität ist ja erstmal nebensächlich.

http://mitglied.lycos.de/maxjat/test8frameskarl.avimax

max

Hi Max,

das ist kein Picvideo, sondern UNCOMPRESSED RGB. Das File ist zwar tff, das sagt aber nix aus, weil es ja schon bearbeitet ist - gecroppt usw...

..wenn schon, wollte ich eine unveränderte sequenz des Original-captures.

Gruß Karl

EDIT: Sehe grad, daß Du schon beim cappen gecroppt hast - naja vielleicht machst Du ja demnäxt nochmal was, oder wir warten einfach auf Signs...

Hi

Neiiin ist das peinlich.

So jetzt ganz frisch vom Videorecorder unbehandelt und ungecroppt beginnend mit Orginalframe 0 , zwar keine netten Affen mehr, aber dafür ein schöner Wüstenschwenk, und auf Bewegung kommts ja an 20 frames dürften zum analysieren reichen.

Nochmal sorry für das RGB File, da habe ich gepennt in VDub.


http://mitglied.lycos.de/maxjat/testkarl.avimax


max

Moin Max,

na also - der Clip ist bff und alles ist so, wie es ein muß!
Vermutlich habt ihr (Du und signs auch) bei der Aufnahme ungeradzahlig gecroppt und hattet dadurch ein tff-Video aus der Asus - zumindest der letzte Clip läßt sowas vermuten.

Mit dem aktuellen clip geht auch:
AVISource..
DoubleWeave().SelectOdd()
vernünftig und das Ergebnis ist perfekt progressive.
Die Welt ist also wieder in Ordung!

Gruß Karl