TempGaussMC beta2

[rkalwaitis]

Sorry I have a couple of questions concerning TGMC.

What is the latestest version?

Can I increase its denoising capabilities? How?

Lastly if I had a film that is interlaced and its tivtc, what would be the correct way to use TGMC to deinterlace it? Megui does analysis and gives me this command for its script. tfm(order=1).tdecimate()

tfm(order=1).tdecimate()

[Didée]

What is the latestest version?
Technically, beta2 is the latest. There are "..u" and "..x" and "..z" modifications floating around ... some have taken NNEDI7 into the mix, others have EEDI815, ... nothing serious. ome incorpo

Can I increase its denoising capabilities?
Yes.
How?
Better don't.

if I had a film that is interlaced and its tivtc, what would be the correct way to use TGMC to deinterlace it?
If the source is hard telecined, the correct way of using TGMC is to NOT USE IT. TGMC is made to process pure video-type interlacing. Nothing else.

[rkalwaitis]

Thanks Didee, are there any other little tools which let a person know what type of interlacing a film has?

[18fps]

If the source is hard telecined, the correct way of using TGMC is to NOT USE IT. TGMC is made to process pure video-type interlacing. Nothing else.

What about using it as a bobber (with lossless option) for srestore? I liked it better than using yadifmod with needi.

[rkalwaitis]

18fps, how did you do that? This interests me very much, as Im not so certain that the tool that automatically test a source for me is always giving me the best solution. Unfortunately I am not experienced enough as many people are to simply look at it and see how something is interlaced. However the results that are provided by the program determining how something is interlaced sometimes leave me wondering if it was the right answer after looking at the product. I had such an issue and tried TGMC in conjunction with the deinterlacer and it seemed better, but the detail was much better. But I was not sure if TGMC was just cleaning up the mediocre attempt at deinterlacing the source.? I hope that made sense.

Thanks

[txporter]

You can try following the FAQ on neuron2's site to determine whether your source is interlaced, progressive, or telecined.

http://neuron2.net/faq.html

[rkalwaitis]

Thanks txporter this is a good place for me to start, which brings me to my original saying its much easier identified by eye. Perhaps why I sometimes get a quirky response when I use the analsye tool.

[rkalwaitis]

I followed Neron's FAQ page on figuring out how your source is interlaced. My results are --a a a b b c c c d d-- Bottom Field First(BFF) If I seperate the fields then everything doubles as such aaabbbbccccccdddd. When the source in not seperated you can definately see the interlaced venitian blind look, when seperated it looks melted together. My analysis tool gave me this to use to deinterlace the source --tfm(order=1).tdecimate()-- however Im not liking it. tfm(order=1)--means top field first. Is this right? Or do I have this backwards? However, If I followed Neuron's instructions properly my source is BBF because when I stepped forward frame by frame the video images did no go forward and then back--to the right in one frame and back to the left a bit in the next. So I changed tfm(order=1) to tfm(order=0).tdecimate() and things seem much better. Is their another deinterlacer that I can try that you guru's may know of? Is tdecimate necessary? Im not sure I understand it. What I read about it is that never use it with PAL and you may or may not with NTSC. Neuron's FAQ page was very educational, Im glad txporter turned me on to it.
Thanks

[18fps]

Is tdecimate necessary?

Yes, it is, as tfm just matches fields to recreate the whole frame, replacing the combed frames with good ones, but leaving repeated frames (it doesn't changes the frame count). tdecimate will try to delete repeated frames, if you give it the right ratio (delete x frames every y frames).

srestore should be used only when, even after a SeparateFields(), you can see two images blended on the same frame.

[xv]

I tried to deinterlace a quite noisy DV source. Unfortunately the temporal noise partly turns to static noise (all options default using nnedi3, also tried tr2=3 and tr0=tr1=1).
What is the recommend way to remove the noise using TempGaussMC or how to use TempGaussMC with an additional denoiser? Or is TempGaussMC not recommend at all with a noisy source?

[Gser]

I tried to deinterlace a quite noisy DV source. Unfortunately the temporal noise partly turns to static noise (all options default using nnedi3, also tried tr2=3 and tr0=tr1=1).
What is the recommend way to remove the noise using TempGaussMC or how to use TempGaussMC with an additional denoiser? Or is TempGaussMC not recommend at all with a noisy source?

Feel free to denoise before it.

[xv]

What denoiser is recommend? I tried MCTemporalDenoise, but it doesn´t work correctly with interlaced sources (I set interlaced=true), the picture jumps up and down every frame one line.
I tried it the other way round but result is rather poor (that´s what I expected), I also tried MCBob instead of TempGaussMC before denoising, the result is ok, but it is really really slow (playback ~0,2fps vs. 2fps with the first method)

[LoRd_MuldeR]

You can use something like:

function TempGaussMC_WithNoiseBypass(clip Source)
{
Denoised = Source.FFT3DFilter(sigma=3, bt=3, interlaced=true)
NoiseOnly = mt_makediff(Source, Denoised, U=3, V=3)
TGMC = Denoised.TempGaussMC_beta2u(edimode="nnedi3")
return mt_adddiff(TGMC, NoiseOnly.DoubleWeave(), U=3, V=3)
}

(Based on a former suggestion by Didée)

[xv]

If I understand that correctly, that means I deinterlace the video and keeping the noise, so that TempGaussMC works similar to MCBob.
That´s not my intention, I wan´t to remove the noise, adding a denoiser after deinterlacing makes it awfully slow (~0.2fps) and the additional FFT3DFilter will reduce speed even more (that means processing 1 hour video will take about 2 weeks).

I think the denoiser needs to be a) before deinterlacing or b) inside TempGaussMC. Because there is no stronger denoiser inside TempGaussMC, a) seems to be the only option, so what denoiser works good before TempGaussMC.
MCTemporalDenoise gives a great denoised result, but it doesn´t work correctly.

[Terka]

tgmc is a _strong_ denoiser! tr2=3 or you can use j. wells mvtools modification and use mdegrain5 or whatever in tgmc to be even stronger. but tr2=3 is enough. or use
http://forum.doom9.org/showthread.php?p=1411610#post1411610

[Didée]

Additional denoising "inside" of TGMC ain't gonna happen, most probably.
a) Too many different kinds of noise ask for too many different kinds of denoisers.
b) There's no particular reason (i.e.: no explicitely well-suited place) to make such internal denoising.

If TGMC's denoising isn't sufficient for your case, just use normal post-denoising like you would do with any other bob/deinterlacer.
And if so, it could really be beneficial to use the noise-bypass method.


So ... feel free to use


preNR = source.FFT3DFilter(sigma=8,bt=5,interlaced=true,plane=4)
preNRD = mt_makediff(source,preNR,U=3,V=3)
TGMC = preNR.TempGaussMC_beta2u(2,2,3,4,4,4,edimode="nnedi3",SLrad=2)
TGMC.mt_adddiff(preNRD.DoubleWeave(),U=3,V=3) # or "preNRD.bob()
MCTemporalDenoise(setting="very high",radius=6,pel=4,twopass=true,useTTmpSmth=true,deblock=true,useQED=true)


You might get a nice result ... around christmas time. :p

However, most likely not this year's christmas. :D

[Terka]

preNR = source.FFT3DFilter(sigma=8,bt=5,interlaced=true,plane=4)
preNRD = mt_makediff(source,preNR,U=3,V=3)
TGMC = preNR.TempGaussMC_beta2u(2,2,3,4,4,4,edimode="nnedi3",SLrad=2)
TGMC.mt_adddiff(preNRD.DoubleWeave(),U=3,V=3) # or "preNRD.bob()
MCTemporalDenoise(setting="very high",radius=6,pel=4,twopass=true,useTTmpSmth=true,deblock=true,useQED=true)Didee, you could advice also TNLmeans to rkalwaitis..

[Terka]

Didee,
could you give me some comments to
http://forum.doom9.org/showthread.php?p=1411610#post1411610
?

[Didée]

When you say that it works for you, then I assume that ... it works for you.

Interesting move to use global compensation for supposely-static areas. (Adjusting saturation of a B/W source?)


No time to look into that, I'm highly busy with renovating - the house looks like a battleground, and I absolutely need to finish before the wife returns from regimen. :devil: :D

[Terka]

When you say that it works for you, then I assume that ... it works for you.ya

Interesting move to use global compensation for supposely-static areas. (Adjusting saturation of a B/W source?)yayyayyay!

No time to look into that, I'm highly busy with renovating - the house looks like a battleground, and I absolutely need to finish before the wife returns from regimen. yaaaaaaaay!!!

[bloodem]

I'm gonna ask here, to avoid starting a new thread. So basically the problem is this: Until now, I used VirtualDub + AviSynth + TempGaussMC + Lagarith lossless codec, to deinterlace my AVCHD 1080i content. On my Core2 Duo E7300 the speed was somewhere around 0.58 FPS. I always thought that with a more powerful machine I could get better results... but now, when trying the same settings on a new machine with two Xeon CPUs (the new ones, based on Core i7 architecture) with a total of 8 physical cores + 8 virtual cores (HyperThreading enabled) I get THE EXACT same results. So it looks like this is the maximum speed that can be achieved with TempGaussMC.

I have TempGaussMC_beta1u2. I tried the latest version but the quality was a lot worse and the speed was practically the same. Am I missing something? Is there some way I can speed things up to at least 1 - 2 FPS?

[TheSkiller]

Do you use SetMTmode() at all (in other words, multithreaded version of AviSynth)? If not I'm not surprised.

But the problem could also be caused by something else, maybe your hard drive can't write the lossless Legarith video faster than that because of the insane amount of data, I'm mean we're talking about 50 or 59.94fps of lossless full HD. Please do the following: open your Legarith video with VirtualDub, go to File - File Information and tell us what is says at "Average bitrate".

Edit: These are (very) fast settings for TempGaussMC:

TempGaussMC(1,1,0, 0,0,0, edimode="bob",SVthin=0.0,pelsearch=1)

[LoRd_MuldeR]

Did you try to multi-thread your script? Like this:

MT("TempGaussMC_beta2()", overlap=4)

[um3k]

Yeah, if you want a significant improvement, you're going to have to download a multithreaded build of AviSynth.

Also, I recommend SetMTMode over MT for TGMC. MT causes problems for TGMC's motion compensation.

[bloodem]

Thanks for the quick replies guys!
I definitely wasn't using SetMTMode or something similar. I have AviSynth 2.58 installed and it looks like I probably need another version or a plugin in order to use this function, cause it doesn't seem to work. I tried this:

DirectShowSource("D:\00006.MTS")
AssumeTFF()
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")
SetMTMode()

Error "there is no such function"

A HDD speed related problem is out of the question... I have two 128GB SSDs in RAID0. They are capable of handling a lot more than a 425149 kbps bitrate (~ 52 MB /s )

[TheSkiller]

It works with 2.5.8. see this (http://forum.doom9.org/showthread.php?t=148117) thread.

Put the avisynth.dll into your \WINDOWS\system32 folder (backup the old one!) and the stuff in plugins into your plugins folder. Reboot.
Then use SetMTmode(2) before TempGaussMC.

[LoRd_MuldeR]

I definitely wasn't using SetMTMode or something similar. I have AviSynth 2.58 installed and it looks like I probably need another version or a plugin in order to use this function, cause it doesn't seem to work.

See:
http://avisynth.org/mediawiki/MT

[um3k]

I use SEt's Avisynth 2.5.8 MT: http://forum.doom9.org/showthread.php?t=148117

[bloodem]

Thanks a lot guys. It works pretty well. I'll get back with further details!

[txporter]

In my experience, 1080i material + TGMC + setmtmode results in a crash. Didee reported it in some thread that MVtools doesn't play well with setmtmode and that is my experience as well.

Once you do get 2.5.8MT avisynth working, your script should look something like this to use multi-threading:
setmtmode(5,0)
loadCplugin("path\to\yadif.dll")
mpeg2source("blah.d2v")
setmtmode(2)
TempGaussMC_beta2(1,1,0,4,0,0,edimode="Yadif",Smode=1, SLmode=1, Sbb=0,SVthin=0.0,pelsearch=1)

My experience is that setmtmode(2) before TGMC shows no improvement on SD material and causes crashes with 1080i.

[Didée]

In my experience, 1080i material + TGMC + setmtmode results in a crash. Didee reported it in some thread that MVtools doesn't play well with setmtmode and that is my experience as well.
Incidentially, in some recent tests I didn't experience those instabilities anymore. Don't dare to say, but it could be I intermittently fiddled with a BIOS voltage and forgot to restore the provenly stable preset. :o
For now, everything seems fine, however I didn't do very much the past days.

My experience is that setmtmode(2) before TGMC shows no improvement on SD material and causes crashes with 1080i.
Beg your pardon, but what you mean with "no improvement on SD material" by setmtmode(2)? Not faster than singlethreaded? I see numbers like
TGMC(1,1,0,4,4,0,"--",SVthin=0.0)
- 1 thread -> 9.9 fps / (64bit: 21.5 fps)
- 4 threads -> 23.9 fps / (64bit: 54.4 fps)
- 8 threads -> 41.5 fps / (64bit: 72.3fps)

That's for PAL 576i, on 4 cores + HT. Didn't ever test 1080i at all, but that surely needs to use much more memory. Maybe too much?

[Forteen88]

@Didée: Doesn't the TGMC-parameter lossless=3 save more details and grain?!

[Didée]

That's to be expected, yes. Your question sounds like it would not be so?

[txporter]

Incidentially, in some recent tests I didn't experience those instabilities anymore. Don't dare to say, but it could be I intermittently fiddled with a BIOS voltage and forgot to restore the provenly stable preset. :o
For now, everything seems fine, however I didn't do very much the past days.


Beg your pardon, but what you mean with "no improvement on SD material" by setmtmode(2)? Not faster than singlethreaded? I see numbers like
TGMC(1,1,0,4,4,0,"--",SVthin=0.0)
- 1 thread -> 9.9 fps / (64bit: 21.5 fps)
- 4 threads -> 23.9 fps / (64bit: 54.4 fps)
- 8 threads -> 41.5 fps / (64bit: 72.3fps)

That's for PAL 576i, on 4 cores + HT. Didn't ever test 1080i at all, but that surely needs to use much more memory. Maybe too much?

I will try retesting it. I am fairly certain that I was seeing no fps improvement with and without setmtmode on 480i material. And 1080i material would go 2+ gb memory and crash with setmtmode. Otherwise it would stay around 900mb (without setmtmode), if I remember correctly.

update:
mpeg2source.TGMC(1,1,0,4,0,0,edimode="Yadif",Smode=1,SLmode=1,Sbb=1,SVthin=0.0)
Q6600, 4gb, 64bit avisynth, 64bit x264
- 1 thread -> 13.58 fps (64bit) <-- no setmtmode used not setting threads to 1
- 2 threads -> 23.36 fps (64bit)
- 3 threads -> 35.27 fps (64bit)
- 4 threads -> 42.08 fps (64bit) # same setting 4 or 0 (verified to make sure) - initially was choking with x264 preset

Looks like I was incorrect. Perhap it was my use of Srestore earlier? Will check with 1080i material to see if I can avoid crashes.

update2 (1080i numbers):
- 1 thread -> 2.08 fps (64bit) # ran at 617mb memory & 35% cpu
- 2 threads -> 1.11 fps (64bit) # shot up over 2.7gb & 45% cpu / encoding didn't finish
- 4 threads -> didn't test

Looks to be a problem with 1080i material. Too much data to process with multi-threading?

update3: Srestore seems to be fine with setmtmode. Don't know where my data points came from before.

mpeg2source, bob=dclip, tgmc.srestore
- 4 threads + mt srestore - 13.96fps (64bit)
- 4 threads + no mt srestore - 7.8fps (64bit)

Memory usage with/without setmtmode + various number of threads varied only slightly from 582mb to 600mb. CPU usage improves from 30% to 95%. Seems perfectly stable on 480i material. Not sure why I have issues with 1080i sources.

[Forteen88]

That's to be expected, yes. Your question sounds like it would not be so?I was confused because you of you conversation:
"-Can I increase its denoising capabilities?"
"-Yes."
"-How?"
"-Better don't."

so I obviously mistakenly thought you meant it's not good to set a grain-keeping parameter such as lossless=3 :)
Anyway thanks a lot for TGMC, Didée.

[bloodem]

Well, back with details regarding SetMTMode(2)... It's unstable as hell ! After a couple of minutes, VirtualDub goes berzerk... Anybody know how I can fix it?

[TheSkiller]

Try SetMTmode(3) and SetMTmode(4). They are more compatible, but also slower.
Also adding a SetMemoryMax(2/3 of your total RAM) as the very first line of your script is usually a good idea. And don't use SetMTmode(2) before AviSource, AviSource works good with SetMTmode(3).

[bloodem]

This is my script:

SetMTMode(2)
DirectShowSource("D:\00006.MTS")
AssumeTFF()
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")


I'll try mode 3 and 4... see what happens.

[Didée]

The general rule-of-thumb is to let any kind of source filter work only single-threaded:

SetMTmode(5,threads) # set only 1 thread active for the source filter ...
XYZsource("source")
SetMTmode(2) # ... and multi-thread only after that
Do().More().Things()

That's the most failsafe way. Use SourceFilter-MT only when you specifically know it works for a certain filter.

[bloodem]

Well, tried the following and it's slow, as if I'm not using SetMTmode... :\


SetMTmode(5,1)
DirectShowSource("D:\00006.MTS")
AssumeTFF()
SetMTmode(2)
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")

[Didée]

No, no no.

The very first SetMTmode statement makes a fixed setting of how much threads will be used. This number-of-threads can not be changed later in the script again.

You want

SetMTmode(5,4) # set the script to use 4 threads, but only 1 active thread for the mode=5 section
DirectShowSource("D:\00006.MTS")
AssumeTFF()
SetMTmode(2) # now activate all of the 4 initiated threads to work in mode=2
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")

[bloodem]

Thanks for the help Didee, but it's useless. I used your script example and it's very very strange... It starts out rather fast, at about 1.8 FPS... and then it goes down to 0.3 FPS (without multithreading I had 0.6 FPS). I'm starting to think that it just doesn't work well with TempGaussMC...

[um3k]

Try adding a SetMemoryMax to the beginning of the script. Set it to a fairly high number, with my 3 gigs total ram, I usually set it to 512.

[bloodem]

Already tried it... Nothing changes.

[Didée]

Simple fact: 1080i (or p, for that matter) is not suited to be processed in such an exhaustive way. Or, if you prefer, today's typical home PC is not up to such a task.

Anyway. When you're going to TGMC some 1080i footage with SetMTmode, then 512MB is by far too little. With 4 MT threads, the RAM usage of TGMC is in range 1GB to 1.5 GB, depending on TGMC settings.

Try with SetMemoryMax(1200) or (1500), and see how it goes.

Also, it's (probably) better to use Avisynth 2.5.8-MT, not the older 2.5.7-MT. (Memory managment of 2.5.7-MT, albeit somehow working, is somehow broken.)

[Didée]

Small test. System: i7-860 8GB RAM, Win7 64bit.

SetMTmode(5,4)
SetMemoryMax(1536)
mpeg2source("shuttle.d2v") # NASA "Shuttle" sequence, 1080i 29.97, mpeg-2, 4746 input frames
SetMTmode(2)
TGMC_b2( 1,1,0, EdiMode=XX, SVthin=0 )

Avisynth 2.5.8 MT x86
XX="bicubic" : ca. 4.7 fps
XX="nnedi2" : ca. 3.7 fps

Avisynth 2.5.8 MT x64
XX="bicubic" : ca. 9.7 fps
XX="nnedi2" : still no nnedi2.dll for x64 available....

In all cases, processing speed stayed at a constant level from start til end. No speed breakdown.
_____

Trying something more insane under x64.

SetMemoryMax(1536)
TGMC_b2( 2,2,1, EdiMode="eedi2", SVthin=0 )

Starts good, but after some minutes broke down to 0.5 fps. VeeDub64 was using >3.2GB at that point, despite of SMM(1536).


SetMemoryMax(3072)
TGMC_b2( 2,2,1, EdiMode="eedi2", SVthin=0 )

3.3~4.3 fps, stable from start til end. Veedub64 stayed below 3 GB for at least the first 1800 output frames. Somewhen later, it had raised to 3.2 GB.


Seems the memory handling is not perfectly mature, and the speed surely is not big fun.
But overall, processing 1080i is technically possible, in reasonable time, if you're not too short with hardware ressources.

[bloodem]

Thanks for trying to help Didee, but the problem still doesn't go away. Just to make things clear: I have a powerful HP workstation, with 2 Xeon quad-core processors based on Nehalem architecture and 72 GB RAM. I have Windows 7 Ultimate x64, I'm using Avisynth 2.5.8 MT and my script is the following:

SetMTmode(5,4)
SetMemoryMax(1536)
DirectShowSource("D:\00004.MTS")
AssumeTFF()
SetMTmode(2)
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")

This script results in a crash in VirtualDub 1.9.9 right after starting the encoding process. (An exception occurred in module KERNELBASE)

If I change SetMTmode(5,4) to SetMTmode(5,3) and SetMemoryMax(1536) to SetMemoryMax(512), The encode seems to work, but it starts at 1.5 FPS and after one minute it goes down to about 0.3 FPS. If I change again SetMemoryMax(512) to anything higher it results in a crash after 20 - 30 seconds.

PS: I'm starting to think that the problem comes from Haali Media Splitter. But if I uninstall Haali Media Splitter, avisynth can't import the video. If I install FFDshow, I still can't open the AVCHD file. It looks like I can only open it if I use Haali Media Splitter + CoreAVC.

[Emulgator]

I guess this may be unrelated to TGMC, I have a similar issue crashing VDub 1.9.9.
Looks like increased memory use when watching Taskmanager...

Every F2 reload of a >700line script using
AnimeIVTC (although bbob=3, not in TGMC mode bbob=4)

AnimeIVTC(mode=2, aa=4, precision=3, killcomb=0, cache=15, normconv=true, bbob=3, omode=1, dark=0.2, thin=10, sharp=120)

On a 4GB RAM WinXP32SP3 DELL System:

F2 adds +1 new instance of ffdshow in taskbar
crashes when more than 2-3 instances are open.
ReduceflickerSSE3.dll seems to eat memory outside.

On a 8GBRAM Win7U64 CLEVO System:

F2 adds + 1 new instance of ffdshow + 2 instances of Haali in taskbar
crashing when more than 6 + 12 instances are open.

Crashreports to come...when it crashes again.
Right now I am content with closing and opening VDub new for every pass.

TGMC alone works nicely here on both engines since 2009...

[bloodem]

I uninstalled CoreAVC and Haali, tried DGAVCDec, the problem persists (VirtualDub crash) using scripts such as this one (with memory variations, thread variations, etc):

SetMTmode(5,4)
SetMemoryMax(1536)
LoadPlugin("c:\dga\DGAVCDecode.dll")
AVCSource("D:\00003.dga"
DirectShowSource("D:\00004.MTS")
AssumeTFF()
SetMTmode(2)
TempGaussMC_beta1u(tr2=0, EdiMode="nnedi2")

[bloodem]

Yep, the problem is TempGaussMC. I removed the line and it works without a glitch.
I guess I should try the new TempGaussMC, but like I said, I don't really like the quality :(