Richtiges Deinterlacing von NTSC?

Zitat von Deinorius

Hi

ich versuche gerade ne NTSC-DVD nach x264 zu komprimieren. Die Filterwahl sollte eigentlich passen. Was mich noch derzeit stört, ist das schlimme Interlacing. Es bleiben sowohl mit Decomb als auch mit TIVTC noch Artefakte übrig.

In meinen Augen ist das stinknormales NTSC-TFF-(echt!)Interlaced-Material. Das wird nicht Inverse Telecined, sondern deinterlaced/gebobt.

Zitat von Deinorius

Außerdem scheint es, dass 1 Frame vor Bildwechsel schmutzige Farbartefakte auftauchen, die auch nicht gerade schön aussehen. Kommt das auch vom Interlacing?

KA, hab aber auch nicht genau drauf geachtet ob das mit nem bober auch passiert. Müßtest du mit nem Bober deiner Wahl nochmal drauf achten.

Zitat von Deinorius

Meine Filterwahl: (ich hab meine drei Deinterlacing-Varianten aufgeschrieben)

Code

MPEG2Source("F:\DVD Video\Jeff Dunham 1\test.d2v")DeDot()Crop(8,0,-8,-0)Telecide(guide=1).Decimate() / tfm(d2v="F:\DVD Video\Jeff Dunham 1\test.d2v").tdecimate(mode=2) /mode=1

Das ist wie gesacht Schmuh(AFAIK).
DedOT ist auch kein deinterlacer/bober sondern soll dot-crawl und rainbows entfernen (IIRC) und die sehe ich hier nicht.

Zitat von Deinorius

Code

RemoveGrain(24)

Ich lasse Didée schprechen:
http://forum.gleitz.info/showthread.php?p=333838#post333838

Zitat von Deinorius

Code

DeGrainMedian(limitY=255,limitUV=255,mode=5,interlaced=false,norow=false)
FluxSmoothT(4)
gradfun2db(thr=1.6)

Das gefällt mir schon besser. DeGrainMedian entfernt die HotPixel und FluxSmoothT entfernt das restliche, feinere Rauschen. Würde ich aber noch mit DePan kombinieren.(temporales Filtern ohne Bewegungskompensation ist meiner Meinung nach keine gute Idee... DEPan ist ein guter (IMHO) Kompromis.)

NTSC ist nicht grundsätzlich immer umgewandelter Kinofilm. Fernsehkamera-Aufnahmen sind eben echt interlaced, und 29,97 Frames / 59,94 Fields pro Sekunde.

tach auch !

Um Denorius das Verständnis zu erleichtern :
ES gibt 2 NTSC Formnate:

- 23,9* mit Telecide auf 29,9* aufgepumpt.
Da wirkt inverse Telecide

- ""echtes"" 29,9* aus einer DV oder TV Kamera.

Nebenbei könntest Du oben die Hinweise auf die Quelle löschen ?
Ich bin nicht sicher, ob die nicht einen *hüstel* hat.

Welche ist es denn ?
1.) Arguing oder 2.) Spark ?

Da die für [Witzichkeit][Zusammengefasst] aufgenommen wurden gehe ich mal von TV Kamera und "echtem" 29,9* aus.

Zitat von bergh

tach auch !

Um Denorius das Verständnis zu erleichtern :
ES gibt 2 NTSC Formnate:

- 23,9* mit Telecide auf 29,9* aufgepumpt.
Da wirkt inverse Telecide

- ""echtes"" 29,9* aus einer DV oder TV Kamera.

Alles anzeigen

Wenn es mal so einfach waere. Auch bei NTSC kann alles moegliche an Wandlungen auftreten. Zum Beispiel Blendwandlung von Pal->NTSC, falsches IVTC (Doppelblends), 29.97 fps progressiv, und letztens habe ich sogar einfaches Fieldshifting gesehen.
Aber es stimmt natuerlich, dass deine zwei Beispiele mit Abstand am haeufigsten vorkommen.

Aus einem alten Guide von grua :

[Blockierte Grafik: http://i4.tinypic.com/5x5j876.jpg]

Also

MPEG2Source("F:\DVD Video\test.d2v")
TomsMoComp(-1,5,1)
Crop(8,0,-8,-0)
data=depanestimate(last,pixaspect=0.911) 
depaninterleave(last,data,pixaspect=0.911,prev=2,next=2) 
DeGrainMedian(limitY=255,limitUV=255,mode=5,interlaced=false,norow=false)
FluxSmoothT(4)
SelectEvery(5,2)
gradfun2db(thr=1.6)

Sollte den Job machen.

Zitat von Eastermeyer

Sollte den Job machen.

Tut es, aber nicht optimal. :zunge:

pixaspect=0.911

Ich bin mir nicht ganz sicher ob das tatsächlich das NTSC-seitenverhältnis ist. Müste man noch mal nachkucken (wikipedia? GleitzWiki?).

prev=2, next=2

Kompensiert jeweils 2 bilder vor und nach dem "Aktuellen" Bild. Die beiden Rauschfilter arbeiten aber nur mit nem radius von 1. Das jeweils 2.te kompensierte Bild ist Rechenzeitverschwendung.

Entsprechent mus dann Selectevery angepast werden:

SelectEvery(3,1)

Auserdem wurde ich das Video lieber boben. Mit MCbob oder MVbob zum beispiel. Sollte gerade hier, mit den eher "kleinen" Bewegunen, gut funktionieren.

Eastermeyer:
Und Text-Bilder (also Bilder mit und vorallem von Text) das nächste mal als 16-Graustufen-PNG! (Kleinere Datei, besser Lesbar!) :so-nicht:
Geht mit 2 Handgriffen und IrfanViev. (PngOut-Plugin nicht vergessen!)

Zitat

Ich bin mir nicht ganz sicher ob das tatsächlich das NTSC-seitenverhältnis ist. Müste man noch mal nachkucken (wikipedia? GleitzWiki?).

Das hab ich hier gemopst, da ging es auch um eine NTSC-DVD :
http://forum.gleitz.info/showpost.php?p=125814&postcount=12

Zitat

Kompensiert jeweils 2 bilder vor und nach dem "Aktuellen" Bild. Die beiden Rauschfilter arbeiten aber nur mit nem radius von 1. Das jeweils 2.te kompensierte Bild ist Rechenzeitverschwendung.

Okay, berechtgter Einwand. Hab' ich nicht so genau nachgeforscht.

Zitat

Auserdem wurde ich das Video lieber boben.

Bobben halte ich für keine gute Idee, denn x264 ist für hohe fps nicht optimiert.
Gebobbte Quellen brauchen als fast die doppelte Bitrate, hatte ich ja mit Selur hier getestet. Gut, vielleicht hat Deinorius ja den Platz (die Bitrate) zur Verfügung.

Zitat von Redfox

Code

prev=2, next=2

Kompensiert jeweils 2 bilder vor und nach dem "Aktuellen" Bild. Die beiden Rauschfilter arbeiten aber nur mit nem radius von 1. Das jeweils 2.te kompensierte Bild ist Rechenzeitverschwendung.

Entsprechent mus dann Selectevery angepast werden:

Code

SelectEvery(3,1)

NEIN! FALSCH!

Redfox, hier hast Du Eastermeyers Vorschlag "verschlimmbessert".

In seinem geposteten Script arbeiten zwei Temporalfilter mit Radius=1 zwischen dem Depaninterleave() und SelectEvery(). Wenn der Downstream-Filter die Frames n-1 bzw. n+1 anfordert, dann bekommt er sie vom Upstream-Filter. Damit der der Upstream-Filter aber die (gefilterten) Frames n-1 und n+1 liefern kann, muss er zuvor selbst die Frames n-2 und n+2 angefordert haben, um n-1 und n+1 überhaupt filtern zu können.

Deswegen ist prev/next=2 richtig. Mit prev/next=1 würde der erste Filter nur zur Hälfte mit ge-Depan()-ten Frames arbeiten.

Es wäre in diesem Fall hier wohl alles andere als dramatisch, sicher. DegreinMedian(mode=5) ist ein ziemlich "sanfter" Filter, vielleicht würde man am Ende nicht mal einen Unterschied sehen.
Aber es geht mir darum, was "technisch richtig" ist - jemand anders nimmt vielleicht das Script und baut stärkere Filter ein.

Prev/next=2 ist richtig. Prev/next=1 dagegen ist

Zitat von Redfox

nicht optimal. :zunge:

Regel:

Wenn mehrere Filter auf einen Bewegungskompensierten Interleave angewendet werden, dann muss der Interleave so 'lang' sein wie die Summe der temporalen Radien aller Filter außer des letzten, plus 1. (Oder so lang wie der temporale Radius nur des letzten Filters, falls dessen Radius größer sein sollte als die Summe der Radien der vorangegangenen.)

Beispiel:

Interleave( comp1,comp2,...,source,...compX,compY)
  clense()         #  temp.radius = 1
  RemoveGrain()    #  temp.radius = 0
  FluxsmoothST()   #  temp.radius = 1
  Deen(mode="c3d") #  temp.radius = 1
  TemporalSoften(3,10,10,20,2) # temp.radius = 3
SelectEvery(??,?)

In diesem Fall müss(t)en 4+4 kompensierte Frames interleave'd werden: (comp-4,comp-3,comp-2,comp-1,original,comp+1,comp+2,comp+3,comp+4)
Weil die Summe der temporalen Radien aller Filter vor dem letzen (also von Clense bis Deen) ist drei, plus eins macht vier.

Wenn der letzte Filter "TemporalSoften(5,...)" wäre, dann wäre der temporale Radius des letzten Filters größer als die Summe der vorangegangenen, und es müssten 5+5 kompensierte Frames interleave'd werden.

Deblocking immer vor dem Croppen !

Glaub' auch das nicht.

Zitat von Didée

Cropping mit 4/4 is' nu ganz schlecht. Die Macroblock-Grenzen sollten schon da sein, wo der Filter sie erwartet, und nicht irgendwo anders ... wenn Dir nachts vor Deiner Haustür der Schlüssel 'runterfällt, dann suchst Du den Schlüssel ja auch *dort*, und nicht unter der nächstgelegenen Straßenlaterne, nur weil man da mehr sehen kann.

Bobbing vor dem Deblocking ist auch problematisch. Es kann dazu führen, dass vertikal nicht deblocked wird. (Weil der Bob-Filter eine Interpolation an der Blockgrenze durchführt, und der Deblocker daraufhin das Blocking nicht mehr als solches erkennt.)

Also Deblocking immer ganz am Anfang.

... und wieder falsch.

- Deblock_qed nach dem Deinterlacen ist ungünstig.

- Deblock_qed vor dem Deinterlacen ist falsch.

Der intern verwendete Deblock() - Filter kann nur mit progressivem Material umgehen, also ... Workaround