TDeint and TIVTC

[tritical]

@puffpio
Yep, what you have should work. If you want to see exactly which frames it is dropping you can use: TDecimate(cycleR=3,display=true).


@All
[link removed], changes:

TFM:
   + assembly optimizations

TDecimate:
   - don't require input and tfmIn files for mode 5

From the readme:

As of version 0.9.11.8 of TDecimate, an input and tfmIn file are no longer required for mode 5. If an input file is not specified then a value of ULLONG_MAX-1 (the maximum value tdecimate has) is assigned to all metrics. Likewise, if a tfmIn file is not specified then all matches are assigned as 'c', not combed, and not a d2v duplicate.

So be sure that vidDetect is set correctly when not using an input or tfmIn file.

The assembly optimizations to tfm are plain x86 assembly (not mmx/isse). I hand wrote the code for the only two remaining routines that use a significant amount of cpu time (actually they are the two costliest) in the default tfm/tdecimate code path and are not already using mmx or isse (they have too many branch and early exit conditions to make simd useful). On my systems the code runs about 2.5x faster than the compiler generated code and lead to an overall speed increase in tfm of 30-50% .

Weird, I've been changing the title of my first post in this thread for a while, but today is the first time it actually changed what title is seen in the forum.

[Egh]

Originally Posted by tritical

TIVTC v1.0 Beta 9[/URL], changes:

TFM:
   + assembly optimizations

TDecimate:
   - don't require input and tfmIn files for mode 5

I was quite suprised but seems new TFM (compared to the one even 2 builds ago ^^) is seriously faster. The gain for metrics calculation in yatta is likely +20% or so. But I didn't test that extensively. Have you measured speed improvement for new build?

[anton_foy]

As I post for the first time in this great thread I give two THUMBS UP for tritical and everyone who has made this Deinterlacer possible! Beautiful work guys!
It is also very fast IMO.

Yet I have a slight problem. The footage I use is mpeg2(d2v) interlaced 1440x1088 that i first upsize to 1920x1080 this is my script:

mpeg2source("C:\...\snow.d2v")
LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)
Lanczos4resize(1920,1088)
Crop(0,0,0,-8)
interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp)

The clip has very little movement in it, only a bit of wind blowing in the trees but on the branches it looks like the horizontal lines are jumping a bit up and down. I am guessing it is because the DeInterlacer interpolates the fields in a certain way. When there are some more movement it leaves small grains/pixels that are very distinct or contrasty.
This is not too bad but I just want to know if it is part of the DeInterlacer or just a bad scripting from my side.

[AS]

Best to deinterlace and then upsize.

[Chainmax]

tritical, you are awesome. I only wish there was something we could have done about those troublesome X-Men captures .

anton_foy: it is bad scripting on your part. Like AS said, if it's actually interlaced, either a) deinterlace and resize or b) separate fields, resize each of them and weave back. If it's telecined, IVTC and then resize. I don't know much about interlacing, but I heard many times here that directly resizing interlaced is a bad, bad idea.

[Didée]

Slowly, Chainmax & AS, slowly. What anton_foy does is fully OK. He is resizing only horizontally, thus leaving the interlaced structure completely untouched. Nothing wrong with that.

So far for protecting anton_foy ... now comes the bashing:

LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)

BOOO!!

[tritical]

@Egh

Originally Posted by Egh

I was quite suprised but seems new TFM (compared to the one even 2 builds ago ^^) is seriously faster. The gain for metrics calculation in yatta is likely +20% or so. But I didn't test that extensively. Have you measured speed improvement for new build?

From beta 7 to beta 9 I got a speed up of about 30-40% for tfm on my laptop (pentium M). The sse2 stuff gave another slight improvement on my p4 system.

I would expect maybe even more of a gain from the last two builds with yatta than in normal operation since it uses micout=1. The new mmx/isse stuff in beta 8 was part of the checkcombed routine, which with default settings is usually only run once per frame, but with micout=1 is run 3 times per frame. The assembly optimizations in beta 9 effected the builddiffmapplane and comparefields functions which get used on every match comparison when slow=1 or 2 (builddiffmapplane isn't used with slow=0). Those 3 functions were also the ones taking up the most cpu time in tfm/tdecimate so speed improvements to them make quite a difference. I can probably still speed up slow=0 by a good bit, but not sure if anyone uses it.

@anton_foy
Your script looks ok to me, but even though you are only resizing horizontally it would still probably be better to deinterlace first and allow tdeint/eedi2 to work on the original image. And if nothing else, it will run faster (I don't even want to imagine how slow it runs on a 1920x1080 image).

Originally Posted by anton_foy

The clip has very little movement in it, only a bit of wind blowing in the trees but on the branches it looks like the horizontal lines are jumping a bit up and down. I am guessing it is because the DeInterlacer interpolates the fields in a certain way. When there are some more movement it leaves small grains/pixels that are very distinct or contrasty.
This is not too bad but I just want to know if it is part of the DeInterlacer or just a bad scripting from my side.

Ususally bobbing does result in some jumpy horizontal lines since how a horizontal line gets interpolated will vary depending on which field is kept. It would probably be eliminated if you went for same framerate output (mode=0). The movement artifacts are most likely from imperfect motion-masking, if you want more resilient detection try using scharfis_brain's function that requires a longer static period.

@Chainmax

Originally Posted by Chainmax

tritical, you are awesome. I only wish there was something we could have done about those troublesome X-Men captures .

Me too, but I haven't had any insights about how better to deal with that particular problem. It's tough to come up with a reliable and automatic way for tfm to choose a match that every statistic it calculates says is worse than the other, and to only do it for the specific frames for which that happens. That's why I much prefer working with sane sources .

[foxyshadis]

Currently the state of hybrid->cfr decimation is pass most frames through, blend the recalcitrant segments. (Decimate mode 1/3, TDec's hybrid mode 1/3.) Is it possible to replace that with a motion-compensated clip (motion/mvtools 1.x) via the clip2 parameter in tfm? At worst they fall back on blending anyway. I'm not sure if I'm missing any special considerations or if it really is that simple. Also not sure how it would add a dup frame for tdecimate for every cycle in that case. Or would that have to be done to the clip2 clip beforehand?

I tried one clip with 60i and 24 telecine, and it seemed all right, but hard to tell. It has so little motion (and quality) in the 60i part, and the only dvd I knew was hybrid I sold. Maybe it's time to rip some more.

[DarkNite]

If you have any Excel Saga sitting around that would be a good start.

Oh, the memories...

[Egh]

Originally Posted by tritical

@Egh

From beta 7 to beta 9 I got a speed up of about 30-40% for tfm on my laptop (pentium M). The sse2 stuff gave another slight improvement on my p4 system.

I would expect maybe even more of a gain from the last two builds with yatta than in normal operation since it uses micout=1.

Well i didn't test that extensively, only ongoing projects. And as usuall I have background programs working, different priorities for metrics collector thread and most important -- there's also scene change detection filter working during ymc operation. So the gain from TFM metrics seems to be extraordinary, cause I was talking about gain in ymc step in general (I use ymc as default with TFM, slavc and TDecimate). Since metrics collection is only a fraction of that step then the speed of metrics collection just skyrocketed :P Overal time for one episode (720*480 24min) decreased from ~45min to approx. 32-33min. I guess that means metrics collection per se now is twice as fast as before And my cpu is Athlon XP 1800+, so SSE1 only. And even with only that, I'm close now to 1:1 ratio. So on something like 2200+ ymc should process one episode in real time then.

Btw, any suggestions for TFM setting as for ymc? I usually use TFF, mode=1, field=auto,slow=1,pp=7,MicM=0. That's pretty much default configuration in ymc. Still quite puzzled though with Chroma and mChroma parameters, seems doesn't have much effect...

[Chainmax]

Originally Posted by Didée

Slowly, Chainmax & AS, slowly. What anton_foy does is fully OK. He is resizing only horizontally
...

Oh, I didn't notice that .

[anton_foy]

Thanks guys! Yes I dont think it would do any difference by rezising before or after TDeInt since deinterlacing is only a horizontal matter. I think I scripted it a bit better now...no jumpy or jittery lines and motion is stable but it is not using eedi2. New script:

mpeg2source("C:\...snow.d2v")
Crop(0,0,0,-8)
LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)
TDeint(mode=1,order=1,mtnmode=1)
Lanczos4resize(1920,1080)
LimitedSharpen(ss_x=1.0,ss_y=1.0,Smode=4,strength=150,soft=34)
ConvertToRGB32.Deblock(1, 1, 1, 1)

After treating the footage with this script it looks AMAZING! TDeInt is great and fast, 1,67 fps...hehehe it ten times faster than my previous deinterlacer.
BTW Didée, a bad choice of using DeBlock?

[Chainmax]

It's just that using VDub means converting to RGB and back, which unnecessary slows down the encode. Besides, there are many excellent deblockers for avisynth like DeBlock_QED or FunkyDeblock.

[tritical]

Currently the state of hybrid->cfr decimation is pass most frames through, blend the recalcitrant segments. (Decimate mode 1/3, TDec's hybrid mode 1/3.) Is it possible to replace that with a motion-compensated clip (motion/mvtools 1.x) via the clip2 parameter in tfm? At worst they fall back on blending anyway. I'm not sure if I'm missing any special considerations or if it really is that simple. Also not sure how it would add a dup frame for tdecimate for every cycle in that case. Or would that have to be done to the clip2 clip beforehand?

I think the better way might be to run the motion compensated conversion on the output from tfm (or you could leave out tfm or replace tfm with a deinterlacer), and then feed that to tdecimate. So a script for vfr->cfr with film and 30p would look like:

tfm()
newfps = mcChangedFPS() # 29.97 to 23.976
tdecimate(mode=1, hybrid=1, clip2=newfps)

I've thought about doing this before, but there are some problems. Mainly, most of the mc methods use a recursive approach that produces different results if you jump to random frames than if you run up to that frame linearly. In the above method, tdecimate wouldn't be requesting every frame but only random ranges of frames so it might cause problems. I am not up to date on all of the mc filters for avsiynth (the new mvtools and mg262's filter) and don't know how much that would really effect things. However, if it is a big problem tdecimate could easily be made to request every frame from clip2 in a linear fashion. I remember thinking about another potential problem with this before, but can't remember it now.

Btw, any suggestions for TFM setting as for ymc? I usually use TFF, mode=1, field=auto,slow=1,pp=7,MicM=0. That's pretty much default configuration in ymc. Still quite puzzled though with Chroma and mChroma parameters, seems doesn't have much effect...

Those settings seem fine to me. mChroma usually wont effect things much, especially in yv12 where there isn't much chroma information. Literally all it does is run the temporal/spatial differencing on the chroma planes and adds the results to the statistics gathered from the luma plane. The chroma results aren't multiplied up to adjust for the sub-sampling vs luma. If you want to see how much it actually changes things you can use debug=true with mChroma=true/false and check how much the match statistic numbers change. In the debug output it will also list the ratio between matches which indicates how well tfm could differentiate between the two matches (which is good and which is bad). The larger the number (>1) the better the recognition and the closer to 1 the worse.

chroma=true is pretty much only needed if there are frames that have chroma only combing. Otherwise, it usually just makes things worse due to false detections... a false detection in yv12 counts the same as finding 4 combed luma pixels since in the combed frame detection chroma is adjusted for the sub-sampling vs luma.

[foxyshadis]

I know motion can handle out-of-order access because of how its frame cache works, though it might have to recalculate an extra frame or two every time. It also plays havok with some conditional functions. Not sure if you have to access out-of-order (like TFM) but it would probably play a little nicer with them if you could do it sequentially.

Thanks for the pointers though, that helps me a lot. I didn't realize TDecimate had a clip2 as well, sicne it's not in the readme.

[tritical]

Thanks for the pointers though, that helps me a lot. I didn't realize TDecimate had a clip2 as well, sicne it's not in the readme.

It doesn't have such an option atm, that was just an idea. To me it seems like that would be the best way for things to work since the hybrid decision is made in tdecimate. Then when a hybrid section is detected it just requests the frames for that section from clip2 instead of doing the blend conversion on frames from the input clip.

For that matter, I had planned a while ago (I've forgotten exactly who asked for it) to allow decimation detection to be run on the input clip but to actually deliver frames from a second clip. I might tackle these two features after I finish optimizing slow=0 and write an mmx version of the isse comb checking functions. I think these new features would be suited to a v1.1 release.

[foxyshadis]

Another minor bug: "CFrameDiff does not have a named argument "ssd""

I look forward to a future version then, though I'm sure it'll be a little while until then.

[tritical]

Looks like I forgot to add ssd into the parameter string... it'll be fixed in the next version. I've completed all the optimizing stuff I wanted to do... so the next release will be v1.0 RC1 and I'll only do bug fixes on that version from now on. A v1.1 release will probably be out shortly after. Current things to add are:

1.) tdecimate clip2 for hybrid modes and to allow running decimation detection on one stream while delivering frames from another. These should be pretty quick/easy to add.

2.) ovrHelp file generation option for tfm. It would work such that you run field matching twice, once with field=0 and once with field=1, with output enabled. Then, tfm would take those two output files and generate a file that lists frame #'s where the matches don't correspond, where combed frame detections don't correspond, of possible missed combed frames or falsely detected combed frames (based on relative mic values of neighboring frames). It would also make a list of detected combed frames and frames where u/b matches were used.

The ovrHelp thing is mainly because I'm too lazy to go through and find things manually.

[tritical]

[link removed]. Only real changes were fixing the "ssd" parameter problem in CFrameDiff and fixing an issue with a few of the sse2 routines that were added to tfm/tdecimate in beta 8 (forgot that the count value for psrldq is # of bytes not bits). I also added an "opt" parameter to all the filters which allows forcing the use of c, mmx, isse, or sse2 routines (for testing purposes). The other changes were just optimizing slow=0 in tfm and porting assembly stuff from tfm/tdecimate into fielddiff/framediff.

[Chainmax]

tritical, would it be possible to make a faster version of EEDI2 for use as a standalone image enhancement filter like HQ2X?