TDeint and TIVTC

[Guest]

Tritical, please explain the field parameter in detail. Thank you.

[Guest]

I see that the EEDI2 filter has these parameters:

mthresh
lthresh
vthresh
estr
dstr
maxd
field
map
nt

Would it be possible for you to explain them in detail?

Thank you.

[Guest]

Thanks for the great interpolator.

Please describe parameter 'nt'. It's not in the README.

EDIT: I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

[tritical]

Originally Posted by Mug Funky

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.

Yeah... junctions are still a problem, specifically those involving diagonal lines/edges. There are also some patterns that can cause it to mess up when they are present at the right spacing. I still have quite a few ideas for improving it (slowing it down more) though... haven't even gotten to testing for consistency of interpolated values among directionally corresponding neighbors or testing for consistency among the final interpolation directions.

Originally Posted by neuron2

Please describe parameter 'nt'. It's not in the README.

In certain places a starting value is given to the "min" variable when checking for the direction that minimizes the cost function. If no direction gives a value less than the starting minimum then no direction is used. The nt variable is used when setting that initial value. The cost function sums the abs() differences of pixels in the sliding vectors, so nt corresponds to a pixel difference and the min variable is usually set equal to: # of differences*nt. I normally use 50 (TDeint's type=3 uses the same thing), but for testing purposes I decided to make it alterable. I found that changing it didn't effect things much at all and decided to leave it out of the readme. Theoretically, increasing nt should allow better diagonal edge/line reconstruction while creating more artifacts, and decreasing nt should hurt diagonal edges/lines but decrease artifacts.

[AVIL]

@tritical

I'vi give to EEDI2 v0.9 a try as bobber. I'm very happy with the results. Far better as TDEINT even with the default values. My footage is real video, not anime. Only a word : chapeau

[scharfis_brain]

here my small contribution to produce artifact free motion adaptive deinterlacing:

function securedeint(clip i, int th, int l)
{   function staticmask(clip e, int th, int l)
	{e0=e.motionmask(thy1=0,thy2=th,thc1=0,thc2=th,thSD=255)
	e1=e0.trim(1,0)
	e2=e0.trim(2,0)
	e3=e0.trim(3,0)
	e4=e0.trim(4,0)
	e5=e0.trim(5,0)
	e6=e0.trim(6,0)
	e7=e0.trim(7,0)
	ea0=logic(e0,e1,"OR")
	ea1=logic(e2,e3,"OR")
	ea2=logic(e4,e5,"OR")
	ea3=logic(e6,e7,"OR")
	eb0=logic(ea0,ea1,"OR")
	eb1=logic(ea2,ea3,"OR")
	ec=logic(eb0,eb1,"OR")
	(l==0) ? ec. greyscale().duplicateframe(0).duplicateframe(0).duplicateframe(0) :\
	(l==1) ? eb0.greyscale().duplicateframe(0) :\
	(l==2) ? ea0.greyscale() :\
		e0.greyscale()
}



i.converttoyv12(interlaced=true).separatefields()
e=selecteven().staticmask(th, l)
o=selectodd().staticmask(th, l)
interleave(e,o)
m=doubleweave().blur(0,1).binarize(upper=false)

b= getparity(i) ? i.separatefields().eedi2(field=3) : i.separatefields().eedi2(field=2)

d=i.doubleweave()

overlay(d,b,mask=m)
}

what it does:
creating two separate motionmasks for odd and even fields each. then combining them. so it is possible to identify static areas for sure.
but this will reduce detail in static areas, where a moving object recently has passed by.

parameters:
th = deinterlacing threshold:
0 -> stupid bob
6 -> a good value to start with
the higher the more residual combing

l = length of the combmask:
0 -> 16+2 fields are used for motion masking
1 -> 8+2 fields
2 -> 4+2 fields
any other value -> 2+2 fields

this large radius (l=1 or l=0) effectively helps against holes for linear moving, patterned structured, short shutter videos, that show deinterlacing holes with all other traditional deinterlacers.
(zilogjones, this one is for your games )

[tritical]

@scharfis_brain
Nice function. Your motion masking effectively does what my motion masking for TDeint2 does, though it doesn't have a sliding window and I do some spatial denoising prior to testing temporal differences in order to deal with noisy clips. Somehow I could bet yours runs faster .

@All
So here come some releases. First is [link removed], changes:

TDecimate:
   + speeded up some of the mmx functions that were added in the last release
   + modes 0, 1, and 3 now pre-compute metrics for the next needed cycle while
       delivering frames for the current cycle in order to evenly distribute cpu
       usage

TFM:
   + Added mmx versions of the isse scenechange routines
   + Optimized combed frame detection routines

Second is [link removed], changes:

   + Added edeint parameter

edeint works the same as "clip2" in tfm. It can be used to specify and external clip from which to take pixels instead of using one of TDeint's own interpolation routines. That means TDeint could use EEDI2 in the following way:

see this post for setting combinations

or for a combo of eedi2/tdeint for deinterlacing frames for tivtc you can use:

1.) tff

interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)

2.) bff

interp = separatefields().selecteven().EEDI2(field=0)
deinted = tdeint(edeint=interp,order=0,field=0)
tfm(clip2 = deinted,order=0)

Also, I noticed a mistake in the EEDI2 readme. Values 2/3 of the field parameter are switched. 2 actually starts with bottom and 3 actually starts with top.

Finally, I have been playing around with some possible ways of detecting junctions and corners in an image, which is where EEDI2 usually has problems, and a slightly modified version of the harris corner detection algorithm seems to do the job nicely. It completely avoids detecting plain diagonal lines while triggering on junctions and very complex areas. I'm probably going to add it as an optional step for avoiding artifacts.

[MacAddict]

Hmmm...Tdecimate is causing Vdub and VdubMOD to exit at the end of my scripts for some reason. This is the latest TIVTC v1.0 Beta 3. Using decimate() instead of tdecimate() resolves the issue on 2 film sources. Anyone else or do I have something strange going on?

I just went back to beta 2 and the script works fine. Perhaps the MMX speedups has caused this somehow in beta 3?

Edit-typo

[DarkNite]

Confirmed. It happens on both boxes here as well.

[tritical]

It is more likely the pre-buffering in modes 0, 1, and 3, cause the mmx speedups only effected ssd routines (requires ssd=true to be used) and one yuy2 luma difference routine. Plus, those mmx routines, if they are being used, get used on every frame so they would cause an error long before the end of the script. Also, I tested out all of the mmx routines on multiple clips, but didn't test a full encode (all the way to the end) with the pre-buffering . Will take a look.

EDIT:
Yeah it was the pre-buffering. I am guessing you both must be running windows xp sp2 cause TDecimate actually isn't crashing, it is throwing an avisynth error. Using a modified version of avisynth that doesn't have the little seh/c++ exception handling crash problem on sp2, this error reported in vdub:

"TDecimate: internal error during pre-buffering (%d,%d,%d)!"

Will put up a fix in a few minutes.

EDIT 2:

Here is a fixed version: [link removed]. Only change was one line of code to fix the end of clip processing in modes 0, 1, and 3. I will try to test things more thoroughly in the future .

[DarkNite]

That was fast, thanks for the quick fix.

[manono]

Hi-

I don't know if I got the same thing or not. I didn't think much of it at the time, and didn't write down the error message VDubMod gave me, but after seeing the 2 other posts I thought I'd better report. This was with the new TDeint, using it as a bobber:

TDeint(Mode=1)
RePAL(Quality=3)

The message was something about VDubMod not responding and having locked. Can't really remember. The encode had completed, and near as I can tell, the video was complete. Using Win XP SP1.

[MacAddict]

Thanks tritical, that was very speedy indeed :-)

In all my cases Vdub/VdubMod was just exiting at the end of every script no matter how small or large the source file. Unfortunately my AVS version doesn't throw the exception here on XP SP2 :-\

[tritical]

@manono
I tried to reproduce your problem but wasn't able to... using tdeint(mode=1) both with and without repal in yv12 and yuy2. What was the rest of your script? and what was the source?

@All
I did notice another bug with TDeint though... it doesn't handle the edeint option correctly when mode=1. It checks for the edeint clip to have the same number of frames as the input clip, which is correct for mode=0, but should be 2x for mode=1.

@MacAddict
It actually does throw the exception... its just that due to a bug in one of xp sp2's dlls, mixing seh/c++ exception handling will cause a hard terminate. Avisynth no longer uses such a mix when the script is initially loaded (so any errors detected and reported by a filter in its constructor will be reported correctly in vdub), but still uses such a mix when requesting frames from the chain of filters (so any avisynth errors thrown by a filter during it's getframe() processing will cause vdub to hard terminate on xp sp2).

[Mug Funky]

@ manono: it didn't say "possible livelock" by any chance?

that's more a warning than an error - means at some point during the encode virtualdub didn't use any CPU cycles. this'll happen if some other program maxes out your CPU (and you don't have hyperthreading or something similar) for 10 seconds or more.

i get it a lot when i use virtualdub to export the audio out of an avs, and encode to mpeg-2 at the same time.

[manono]

Yes, that may have been it, Mug. I'll pay more careful attention the next time it happens. It happened after the encode had finished, I think. I wasn't around, and when I came back, the uncompressed Lagarith AVI was done and this message was sitting on the VDubMod screen. For what it's worth, here's the script:

LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll")
LoadPlugin("F:\DivX Stuff\GKnot\TDeint.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RemoveGrain.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RePAL.dll")
LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll")
mpeg2source("K:\March Of The Penguins\5-1\5-1.d2v")
Trim(0,94874)
TDeint(Mode=1)
RePAL(Quality=3)
Undot()
RemoveGrain()

Damn R1 March Of The Penguins has an extra that's a mix of 30fps interlaced footage and PAL2NTSC blended 25fps footage. I decided to RePAL the whole thing and see how it turned out.

[Chainmax]

Originally Posted by neuron2

I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

Really? I have an immensely crappy 160x112 video I want to resize to 320x256, how would I go about using this filter for that?

[Guest]

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

[mg262]

How about turnright().eedi2(...).turnleft()?

[Chainmax]

Originally Posted by neuron2

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

Ok, so how do I do that? Would mg262's method work?