exist any filter specially done for (deinterlace) flicker

[Adub]

For one, post your script.

For another post the error that you are getting. What happens when you drop the script into virtualdub or media player classic?

[thetoof]

You say there are no errors.... so I guess that what's going on here is simply that tgmc is too slow for you. Of course it'll hang in MPC... it is not meant for speeds such as 60/50 fps. And for megui, you could simply do a lossless rendering pass to speed up encoding.

1st - try drag & drop your avs in virtualdub. If something else than an error appears, it means it works (you could hit file-run video analysis pass to confirm)
2nd - In vdub : video-compression-Lagarith (YV12 mode) / video-fast recompress / file-save as (about 20-40GB per hour of
footage (unless you use selecteven/odd or some decimation)
Then use that file to create a new avs file and use that for x264.

If step 1 works, it means there is no problems. If you want to skip step 2, fine, but be prepared to wait for a while and make sure that you have enough ram to run this. If you're doing a 2 pass encode, a rendering pass is strongly recommended (this way you don't have to run the filters twice = overall major speed-up)

[News Bot]

I got it working ok, a preview comes up now. I had to use the "mt=false" command (I'm running a Quad Core). However now I get a dreaded "CAVISynthStream: System exception - Illegal Instruction at 0x46b4c86" instead of the video itself being rendered. I get it with everything from MPC, VirtualDub, MeGUI etc. It will encode, but the output will just be that error for the length of the video, as will the preview.

Any way to fix this? I've installed and uninstalled several versions of AviSynth but all give the same error.

As for my script:

ffmpegsource("sample.mp4")
AssumeTFF()
TempGaussMC_beta1mod(mt=false,edimode="NNEDI",tr2=1).SelectEven()
Spline64Resize(596,384)
maa()
LSFmod(strength=50)

I've tried using purely TempGauss alone, but it will not budge. Is there any way to fix this issue?

[thetoof]

I can't reproduce your issue. Do you have the TGMCb1mod that uses mvtools2? http://www.mediafire.com/download.php?zjmtgc2qrzi
Guess I should've put some version numbers of something... (at first, this was only meant as something to include in the requirements.7z of animeivtc, but I ended up posting it here and there. My bad.)

[News Bot]

Yeah, I've used every version of TGMC there is, but I still get hit with the same error.

[thetoof]

Have you updated your mvtools version? Does it work with another type of source? (avi, mpeg2..)
The latest ffmpegsource uses a 2 pass decoding :
ffindex("file"), then it'll say it did not return a video clip, and you run
ffvideosource("file")

[News Bot]

I've singled out MVTools as the reason for the error now. The ONLY filter I get it with is TempGauss but it is certainly an issue with MVTools.

I'm using Windows Vista Ultimate 64 bit with Service Pack 1. But I've heard that it works for others, so I'm totally confused on the whole issue. =/

[Terka]

have a look at:
http://portal.acm.org/citation.cfm?id=1440455.1440555&coll=portal&dl=ACM

[Terka]

can be TGMC be upgraded to use mvtools 2?
will be there any spead/quality gain?

[thetoof]

It has been "upgraded", though not officially. Check tempgaussmc_beta1mod (you can get it on the wiki).
You can test and report for the *whatever* gain.

[Terka]

is there any spead/quality gain?

[krieger2005]

You can test and report for the *whatever* gain. :P. As i heard here in the forum it seems that it work better with MT, so with MT there should be an speed gain. Qualitywise there should't be any difference, since i think fizick just ported the internal processing from v1 to v2. But fizick can give here a better answer

[thetoof]

MT should be faster, but then you won't benefit of further upgrades (idx removal (requires less memory), MVDegrainx chroma shift correction (done in 1.10.2.1 and MT is 1.9.7.7... but Didée had corrected it for tgmc with the masktools anyways) and a few other thingies (see the latest MVTools2 changelog for more info)).
So, it doesn't work "better" (nothing really does in this forum ;)), but it's up to you to decide if the v2 upgrades are worth letting go of the MT speed boost.
On a side note, it'd be interesting to see the difference between SetMTMode(2,x) + mvt2 and mt=true.

[Boulder]

Is there an up-to-date TempGauss version with variableblur.dll being used? I seem to recall that it was supposed to be a bit faster, and the memory leak in the dll was fixed by neuron2 some time ago.

[Didée]

Can't tell for sure, but probably there isn't. Anyway, it doesn't matter. The Resize().Resize() combo (that replaces BinomialBlur()) on its own would perform multiple-times-realtime. So in the overall picture, the speed penalty is absolutely neglectable.

[Terka]

Which parametrs tweak in tgmc to calm static details like grass? Standard settings produce areas moving here and there.
see original:
http://rapidshare.com/files/25061661/Psi.rar
is it suitable to denoise/deblock (DV compression) before processing tgmc?

[2Bdecided]

Which parametrs tweak in tgmc to calm static details like grass? Standard settings produce areas moving here and there.
see original:
http://rapidshare.com/files/25061661/Psi.rar
You've been deinterlacing that clip for nearly two years! ;)

There's a bit of aliasing, which causes some instability. You can try some of the mo-comped super resolution stuff from other threads as a post-process, and then re-size back to SD. Painfully slow, but it helps a bit.

At least TGMC_alpha3 is more stable than mcbob. I'd be happy more than with it, I think - though it's too slow for most uses!

Cheers,
David.

[Terka]

is it possible to speedup the tg following way:
interlaced.separatefields() #not bobbing
calming
motion estimation
>so the calming an mo-est. is done on halve size clip.
is it possible to use the "halve_height" mo-vectors on original clip?

[Didée]

It could be done using MVIncrease(), but there's several problems. Accuracy (half- vs. full-pel) is one problem. A bigger one is that MVIncrease does *not* support block overlapping, so the process would be highly prone to introduce block artefacts.

[Terka]

the bobbed clip can be split to two using separatefields(); 2 clips processed used same mo-vectors. and weaved back.

[Didée]

Ah, didn't think of the obvious, now I see. Yes, that should be possible, and rather easy to do. Will be tried out somewhen soon, to see how it turns out.

[Terka]

thank you for replies. dont understand the last sentece. you or someone tried this already?

[Terka]

2 Didée:
1.tried to do the separate_fields - > weave, but im not able to implement it directly to Tempgauss (Tempgauss_beta1mod to be precise)
could you help?
2. tried fluxsmoothT to calm bob's flickering, looks good in static areas.
3.can we get some profit if temporalsoften be used as mo-comped?
for clean soures is TG realy good, (my) DV sources have much more noise which is difficult for me to beat.

[sarmano]

# apply sharpness limiting (SLmode 3|4), or has "draft" been requested?
stage3 = (draft==2) ? t .Subtitle("Draft 2") : (draft==1) ? t1 .Subtitle("Draft 1")
\ : (SLmode==3) ? ( (SLrad<2) ? stage2.repair(edi,1) : stage2.repair(stage2.repair(edi,12),1) )
\ : (SLmode==4) ? stage2.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage2

stage3


How it's working? I don't understand.
When it's removed TGMC works perfectly on 10x speed without strong sharpness limit.

[Didée]

"You shall not alter complex scripts when you don't know what you're doing."

Quick test:
TGMC with default sharpness limiting (SLmode=2): ~6.6 fps
TGMC with all sharpness limiting deactivated (SLmode=0): ~6.4 fps

If you comment-out (or remove) exactly the code sniplet that you posted, then TGMC will return just the input clip, without any processing, without any deinterlacing.

So - yes, doing *nothing* is a very fast operation, indeed. ;)

[sarmano]

"You shall not alter complex scripts when you don't know what you're doing."

So - yes, doing *nothing* is a very fast operation, indeed. ;)


Hmm. I tried encode 720p video clip without using TMGC and speed was ~8fps but with removed iterations from TMGC it's encoding about 1.2 fps. So - no, doing *something* isn't a very fast operation ;).

I really don't understand the step on stage3 and how many passes it'll do.

BTW: Thanx for answer anyway.
(Sorry for my English!)

[WorBry]

So - yes, doing *nothing* is a very fast operation, indeed. ;)

:D Love it

[Didée]

Hmm. I tried encode 720p video clip without using TMGC and speed was ~8fps but with removed iterations from TMGC it's encoding about 1.2 fps.
720p is progressive. You are using a deinterlacer on a progressive clip ... ?

I really don't understand the step on stage3 and how many passes it'll do.
That "stage3" section does not do something like several passes or "iterations". It's a basic IF..THEN..ELSEIF... condition.
Then, with default settings of TGMC, that section does *nothing*, anyway. With the default setting of (SLmode=2), the sharpness limiting is done earlier in the script (section "stage1b"). For that reason, your change wouldn't make much sense: you are removing a section that does no processing at all (with default parameter, that is).


Also, the code in TGMC is slightly different from the code you quoted (border/crop is missing). Due to those differences, it is not fully clear what exactly you removed, and what exactly is happening in your modified script.
If you want all doubts dispeled, post the complete version of your modified script.

In any case - if you get a 10-fold speedup, then it is impossible that TGMC still does what it's supposed to do.

[sarmano]

Didée many thanks for the explanation of the script.
The purpose of the removal step 3 was my desire to speed up the script a bit by removing unnecessary options as well.
I need some time to understand where I made an error in adjusting the data. Perhaps part of the code slows down the processing of data and I have the impression of useless steps.

720p is progressive. You are using a deinterlacer on a progressive clip ... ?
Yes, I used a resized progressive clip.After several tests, I noticed that NNEDI or EEDI2 does an image more elegant, as compared with the original material, even in small amounts.
Of course, this is not quite correctly associated with the technology of processing, but I really like the result of these actions.

[Terka]

Didée, could you help with the separate_fields - > weave, TGMC hack?
Thank you,
Terka

[Terka]

or someone else? Asked Didee, because he is the author.

[martinfrombern]

i get this strange artifact when using TempGaussMC_beta1mod(edimode="NNEDI"). source is pal dvd. screenshots (thumbnails):

http://hdimage.org/images/0iix94mx5ark26dfio5_source_thumb.png (http://hdimage.org/viewer.php?file=0iix94mx5ark26dfio5_source.png)http://hdimage.org/images/184wyx01af97qbrajt59_tempgauss_thumb.png (http://hdimage.org/viewer.php?file=184wyx01af97qbrajt59_tempgauss.png)

[Didée]

@ martinfrombern
Those are artifacts from failed motion compensation that hasn't been detected as being faulty. You might try using more aggressive repair options, such as TGMC(edimode="NNEDI", rep0=1,rep1=1,rep2=1).
The defaults for rep0/1/2 are 4/0/4. The smaller a number is, the more aggressive the corresponding repair section is acting (and "0" deactivates a given repair section).
However, the more aggressive you choose the repair values, the more likely it is you'll get bob-flicker in static scenes.


@ Terka
While the basic idea is pretty simple to do, it turns out that it's a bit cumbersome to implement into TGMC in such a way that everything still works as it should.

Meanwhile, to cool down your eagerness a little, let's make an estimate:
Say, TGMC is spending ~20% of its procesing time with the motion search. Your suggestion will cut down the time for motion search by ~50%. So in the end, your suggestion would bring ~10% speed increase with slightly reduced quality. (Those are rough numbers from the guts, but fairly realistic.)

See why I'm not overly thrilled to make those changes? Sure, every little bit helps, but ... boosting a 3.0 fps script up to 3.3 fps isn't very spectacular.

[Terka]

Didée, of course, the speed gain wont be big.
I wanted to try it myself, but im not able.
btw. didnot understand
"Will be tried out somewhen soon, to see how it turns out."
thank you, T.

[Sagekilla]

Meanwhile, to cool down your eagerness a little, let's make an estimate:
Say, TGMC is spending ~20% of its procesing time with the motion search. Your suggestion will cut down the time for motion search by ~50%. So in the end, your suggestion would bring ~10% speed increase with slightly reduced quality. (Those are rough numbers from the guts, but fairly realistic.)

This reminds me of Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_law). Even if you speed up one part of a program by an infinite amount, your program can still be very slow.

[lansing]

I kept getting an integer overflow error from the script after an install of windows 7.

I did a clean install of avisynth, some trial and error for all the required plugins. And the error message is still the same:

http://img266.imageshack.us/img266/4644/errormessagep.jpg

t1 = t.VCRep(dbob,ed=ed0,od=od0) #line 144
tD_2 = mt_makediff(ref,clp,U=3,V=3) #line 272

I think the problem comes from masktools, but I don't know what to do about it

[Undead Sega]

i dont mean to sound rude or anything, but is TempGaussMC considered to be 'the' Motion Compensation deinterlacer?

or what Motion Compensation is suppose to be? because there are probably hundreds of different MC's out there, which one do we know is the (works) better and etc.

[Adub]

Typically, the choices between motion compensated deinterlacers lies between MCBob and TempGaussMC. The latter has a nice effect in that it also filters noise, but you can't go wrong with either of these deinterlacers. Just pick the one that works best for your purposes.

[2Bdecided]

There are two mcbob versions - the eedi2 one, and the nnedi one. Horses for courses.

There are multiple tgmc versions - I still like alpha3 for my HDV footage.

tgmc beta1 and 2 give you lots of options - eedi2 or nnedi etc etc etc - there's a post a few pages back that summarises it. These can run faster than alpha3.


IMO(!) visible differences include:

how successfully shallow diagonals are recovered without flicker (tgmc better than mcbob)
how well noise and artefacts are suppressed (tgmc better than mcbob)
how well very fine details are preserved (tgmc beta default seems better than tgmc alpha 3; mcbob seems better too, but less stable)


I often compare the deinterlaced output with what you see on a native interlaced CRT. IMO tgmc can be better almost all the time; mcbob can be better most of the time, but most other oft recommended AVIsynth deinterlacers fail miserably to maintain the full perceived resolution. But mcbob and tgmc are too slow! ;)

Hope this helps.

Cheers,
David.

[Terka]

another speedup possible?
http://forum.doom9.org/archive/index.php/t-22096.html

[Didée]

No.

TemporalSoften is, roughly, 100 times faster than TGMC as a whole. Even if temporalsoften2 (very old & outdated, wasn't it designed for Avisynth 2.0, IIRC?) would be some percent faster, it wouldn't matter. Some percent from one percent is ... practically null.

BTW, somewhen lately I made I rough implementation (only POC, not *generally* functional, hence not posted yet) of your faster ME proposal, which also included the transition from MVTools v1.9.x (original TGMC) to the actual MVTools v2.4.x. What I observed was that there's a small speed improvement of "fast-ME" vs. the original "full-ME", but ... somehow, even with "fast-ME", the new MVTools-v2 version was slower than the original MVTools-v1 version ...

It seems a bit ridiculous to put effort into micro-improvements on the script level, when the hosting environment/tools get slower on a macro level ...

[Terka]

yes, i know that the improvement is low.
1.what is the most time consumer in TG? mvtools time could be halved, bob instead of nnedi/edi can be used.
2.so mvtools2 are slower than mvtools1? and what about quality?
3. im using TGMC on DV sources. unfortunately DV has quite big artefacts, so some appear more visible when TGMC calms most of the picture.
but TGMC is far best deinterlacer.

[2Bdecided]

But doesn't MVTools-v2 multi-thread properly? So it could be faster?

I don't know - I find it hard to keep up!

Cheers,
David.

[Adub]

Yes, MVTools2 multithreads nicely with MT. I have seen a speed up of several fps on my "heavy scripts" when compared to v1.

[aegisofrime]

Personally for me TGMC Alpha 3 runs faster than TGMC Beta 2 by adding a Distributor() to the end of the script. I usually get 10 FPS that way when on a pre-rendering job, as opposed to 8 FPS for Beta 2.

[Terka]

how modify TGMC to
use more frames in MVDegrain?

when used filtering like see below on DV source, result is more stable. But im sure Didee knows why he put the other routines to TGMC.


clp=avisource("c:\hj\kamera\avisynth\psi\!Psi.avi")
SetMemoryMax(512)
bob=clp.bob(0,0.5)
bob=clp.nnedi2(field=-2)



# denoise ##############################################################
calm = calmI(bob)
denoised = mo_denoiseAB (calm,bob)
denoised.Sharpen(0.5)
#######################################################################


###################################################
function mo_denoiseAB (clip calm,clip denoise , int "blksize", int "overlap", int "blksize", int "sharp", int "thSAD", int "refframes")
{
clp=denoise
idx = 20
blksize = default(blksize,4) # blksize value (4, 8 or 16)
overlap = default(overlap,blksize/2) # overlap value (0 to half blksize)
sharp = default(sharp,1) # 0=bilinear softest, 1=bicubic, 2=Wiener sharpest
thSAD = default(thSAD,400) # 640didee,200 orig. higher risks motion ghosting and swimming, lower risks blotchy denoising
refframes = default(refframes,8) # temporal radius for MVTools using the "Multi" modification by Josey Wells


vectors = calm.MVAnalyseMulti(refframes = refframes, pel = 2, blksize=blksize, overlap=overlap, sharp=sharp, idx = idx)

clp.MVDegrainMulti(vectors, refframes = refframes, thSAD = thSAD, idx = idx + 1)
return(last)
}

function calmI (clip)
{
t1 = clip.temporalsoften(1,255,255,28,2)
t2 = clip.temporalsoften(2,255,255,28,2)
t1.merge(t2,0.357).merge(clip,0.125)
return(last)
}

[Chainmax]

TGMC's latest version is TempGaussMC_beta1, right?

[Terka]

i think so.

[WorBry]

TempGaussMC_beta1 is the latest/last official release from the author, Didee. There's a modded version TempGaussMC_beta1mod (courstesy of thetoof) that uses the multi-threaded branch of MVtools or MVTools2.

http://avisynth.org/mediawiki/TempGaussMC

Probably both versions can be updated to include NNEDI2, just released:

http://forum.doom9.org/showthread.php?p=1296128#post1296128

Easy enough to do:

# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="NNEDI2")? clp.nnedi2(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob

[henryho_hk]

I love this function. It works even on those ill-brained footage with mixed interlaced and field-duplicated materials (....though I seem to find ghosting on those field-duplicated scenes.... very occasionally.... It may actually exist in the footage itself... not 100% sure).