Wieder zu NTSC -> PAL Konvertieurng

Das Script ist OK (sieht meinem eigenen ja auch verblüffend ähnlich), wenn Du echten interlaced Source hast. Bis auf threshold=0, da habe ich mich inzwischen auch überzeugen lassen, dass Werte zwischen 2 und 6 da besser sind.

a) assume?ff() bringt bei kerneldeint-geschichten GAR NIX. der Order-parameter überschreibt das brachial. also: BFF / TFF steuerung über den order-parameter!

b) converttoyuy2(interlaced=true) wozu? das macht doch nur die Farbinfo kaputt!

anstatt dessen lieber das converttoyuy2(interlaced=false) direkt VOR separatefields().

1) in AVS zu resizen ist immer besser (so man denn weiss was man tut!), als dies dem encoder zu überlassen.

2) obs interlaced ist kann nur das auge entscheiden. Programme sind zu doof dafür.
wenn Du ein Muster hast: 3 Frames non-interlaced und dann 2 frames interlaced dann kannst Du die ganze deinterlace geschichte vergessen und musst eine IVTC machen. Sieht um LÄNGEN besser aus. aber wie gesagt nur bei solchem material!

3) siehe AVS-Doku.

4) SAMPLE her!

https://localhost/www.putfile.com
https://localhost/www.rapidshare.de

scharfis_brain
AssumeTFF() war da drin, weil ursprünglich KernelBob() benutzt wurde und ich grundsätzlich die korrekte Fieldorder angebe. KernelBob() setzt die ja im Gegensatz zu LeakKernelBob() nicht wieder auf BFF.

Mit Deiner Bemerkung zum ConvertToYUY2 hast Du mich jetzt verwirrt.

Zitat von Kika

Mit Deiner Bemerkung zum ConvertToYUY2 hast Du mich jetzt verwirrt.

Och, man gewöhnt sich dran. Immer wenn ich bei Interlacing-Geschichten denke "aaah ... JETZT hab ich's kapiert!", dann kommt scharfi recht bald mit einem Kommentar daher, der mich eines besseren blehrt ...

wenn ein Deinterlacer YUY2 und YV12 unterstützt und die Quelle YV12 ist, sollte man es TUNLICHST unterlassen, VOR dem Deinterlacing den Farbraum zu wechseln. Das Konvertieren zw. YuY2 und YV12 ist wie ein fieldweises vertikales resize der Chromaplanes.

wenn man aber erst NACH dem deinterlacing den Farbraum progressive umskaliert dann hat man motion adaptive color space conversion :zunge:

siehe hier:
http://forum.doom9.org/showthread.php…motion+adaptive
und auch den Großmeister - Neuron2 - musst ich erst überzeugen:
http://forum.doom9.org/showthread.php…motion+adaptive

tach auch !

@Didiee
Wilkommen im Club.
[Blockierte Grafik: http://static.howstuffworks.com/gif/aspirin-ch.jpg] 

aaah ... JETZT hab ich's kapiert!

Didée
Ja, bis zum nächsten Mal...

scharfis_brain
Ach so, dass meinst Du. OK, das Script war mein eigenes, und ich hatte nicht daran gedacht, dass der Source, den ich habe, als RGB24 importiert wird (das basiert noch immer auf dieser alten Luma-Range-Geschichte).
Ich hatte schon befürchtet, dass ConvertToYUY2 generell die Farbinfos zerstören würde.

rgb -> yuy2 braucht keine interlaced behandlung....

Schaden tut sie imho aber auch nicht, oder gibt's da auch neuere Erkenntnisse?

Aber OK, ändern wir das Script mal ab, jetzt aber nur für TFF geeignet:

LoadPlugin("leakkerneldeint.dll")
avisource("ntsc.avi")
LeakKernelBob(order=1, sharp=true, twoway=true, threshold=4
BicubicResize(720,576,0,0.6)#oder auch LanczosResize(720,576), je nach Source auch 704x576
ConvertFPS(50).ConvertToYUY2(interlaced=false).AssumeTFF()
SeparateFields().SelectEvery(4,0,3).weave()

Hm, was vergessen?

Nachtrag: interlaced=true geändert in interlaced=false

ConvertFPS(50).ConvertToYUY2(interlaced=true).AssumeTFF()

FALSCH!

richtig ist, wie ich schon oben schrieb:

ConvertFPS(50).ConvertToYUY2(interlaced=false).AssumeTFF()

Jo, glatt vergessen. Aber ich schrieb ja auch "Hm, was vergessen?"

Hab's korrigiert.

@ scharfi

Wie würde man eigentlich aus SmartDecimate einen Bob-Filter basteln? Vermutlich mit DoubleWeave() und ... ?
(Bestimmt würde ich da wieder irgendwas vermurksen ...)

Warum frag' ich jetzt so etwas? Darum:

Der Trend bei Deinterlacing-/Bob-Filtern geht ja zu immer niedrigeren Thresholds. (Was ich sehr begrüße.)
Offensichtliches Problem: Ist Rauschen in der Quelle, kann und wird u.U. auch in statischen Bereichen deinterlaced. Und Entrauschen vor dem Deinterlacen ist ja oftmals heikel.

So. Mal angenommen, man hätte einen Rauschfilter der ein Ergebnis liefert, dass man *so* nicht unbedingt für den Output verwenden wollte ... das aber wunderbar als "Entscheidungsgrundlage" für den Deinterlacer/Bobber geeignet wäre. Dann bräuchte man eben einen Deinterlacer bzw. Bobber, der zwei verschiedene Clips als Input akzeptiert - einen zum Analysieren, und einen zum tatsächlichen Bearbeiten.

Derzeit gibt's wohl nur einen Deinterlacer, der das ermöglicht - eben SmartDecimate. Deswegen wäre ein SmartDecimateBob recht brauchbar.

(Wenn ich tritical das 2-Clip-Konzept einfach so vorschlage, krieg' ich wahrscheinlich eine Jacke mit seeehr langen Ärmeln angezogen. Erstmal ein funktionsfähiges Proof-of-Concept, dann kann man betteln gehen )

Didèeeeeeeeeeeeeeeeee!
Aber da gibs doch was von Ratiopharm!
Whoops falscher Film!

Noch nie was von Motion Map denoising gehört?
Das konnte schon SmartDeinterlace für VDub von Donald Graft (und das ist DREI Jahre her)

Triticals TDeint hats auch eingebaut.

>> Noch nie was von Motion Map denoising gehört?

Aber sischer dat. Aber wie der Name sagt, wird da die Maske denoised. Muss ich erklären, warum das billig und unsicher (um nicht zu sagen MURKS) ist? Oder reicht's wenn ich sage, dass ich mir in dem Punkt ziemlich sicher bin?

Na dann: Fräg Tritical!
Der Ärmelt sowieso grad an was passendem, Du kommst also nicht ungelegen.