QTGMC Deinterlacing Script (v3.32)

[William.Lemos.BR]

Sorry for not being ontopic, but "best results" compared to what ? (just out of curiosity)

Actually is kind of obvious it's better to filter the video after upscaling it and, basically, that was what I confirmed. Indeed, the noise profile generated in Neat Video has more quality as big as the video is.

Regarding Neat Video: I've tested a lot of other softwares and plugins and conclueded this was the best (of the worst) way of filtering without loosing details (since you manage how to set it's parameters appropriately). What I noticed is that all filtering aways kills the details. But I'm new to Avisynth, and I'm pretty sure that with more knowlege I'll find a better way of doing it.

[Didée]

after 24 hours of researching and testing I can say with ABSOLUT certainty: VIDEO ENHANCER IS A LIEWARE!

It doesn't use super resolution, as it caims.
No, that's overboard again. It surely uses SR. The problem is that for this kind of SR to work out, you need input with special properties.

Take some random video.

a) Downscale with bicubicresize(halfwidth,halfheight,0.5,0.25). Upscale with VideoEnhancer. It will achieve "almost nothing" compared to a simple re-scaling.

b) Downscale with gaussresize(halfwidth,halfheight,p=100). Upscale with VideoEnhancer. It will achieve a good improvement over a simple re-scaling.

TSR can work pretty good when the input is of the "decimated resolution" kind. The only pity is that the vast majority of all sources doesn't fall into this category. :)


But the idea behind super resolution is really interesting, do you agree? Going to give a try. In the end at least I'm going to learn usefull stuff.
Sure it's an interesting idea. But as noted above, in most everyday cases it is almost impossible to perform.

Do a forum search on the term "super resolution" / "superresolution". The topic has been discussed a few times already. Usual partipiciants have been: the naive optimists stating "THIS IS IT!", and the pessimistic naysayers stating "Y've been rickrolled". Oh, and some others that were throwing whitepapers about different sensational breakthrough algorithms.

The current status is:

We have lots of paper, but no functioning general-purpose superresolution. ;)

[dansrfe]

We have lots of paper, but no functioning superresolution

Well said.

[William.Lemos.BR]

No, that's overboard again. It surely uses SR. The problem is that for this kind of SR to work out, you need input with special properties.

Actually I know somehow it uses SR, but not the way it promisses, 'cause it doesn't ADD new information to the resulting image by analysing each frame in a sequence (for instance: a small blurry face will continue blurred, but bigger; you're not going to see eyes mouth and nose, even blurred, as I imagine a real SR process would do). For me this is not much diferent or revolutionary compared to other enlargement methods.

We have lots of paper, but no functioning general-purpose superresolution. ;)

That's it, you're right. What a pity! :(

[Didée]

However, let me point out the term "general purpose".

It's a different story when talking about "specialised conditions". For example, the topic of this very thread is a script that truly performs temporal superresolution. :)

It is just limited by two conditions:

a) the input has to be interlaced. (Interlacing is a native form of "decimated resolution")

b) the more lowpass filtering was used to create the original interlacing, the less effective the TSR part will be. (Lowpassing effectively changes "decimation" into "blurring")

[plonk420]

is this supposed to be a 30fps-oriented deinterlacer? it seems to have half the framerate (or at least notable motion) that mcbob gives me... on even frames, the image seems to be just slightly changed from the odd ones...

love the speed, tho!

[aegisofrime]

is this supposed to be a 30fps-oriented deinterlacer? it seems to have half the framerate (or at least notable motion) that mcbob gives me... on even frames, the image seems to be just slightly changed from the odd ones...

love the speed, tho!

It's a bobbing deinterlacer. It does have a mode for processing progressive content that outputs same framerate, might you have used that by mistake? The parameters for that mode is

QuickTGMC(InputType=1)#or 2, or 3

[dansrfe]

yeah you still have to use srestore after this to remove all the extra dupes and blended frames.

[kypec]

Well, this is my first experience with any lossless video codec. I want to use it for intermediate files that are the product of heavy processing in Avisynth. Later I plan to encode those lossless files with x264 2-pass method.
So far I was able to create AVI files Video
ID : 0
Format : ULY0
Codec ID : ULY0
Duration : 1mn 0s
Bit rate : 50.7 Mbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 fps
Standard : PAL
Bits/(Pixel*Frame) : 4.893
Stream size : 363 MiB (100%) via this command:avs2avi.exe myscript.avs -c ULY0

However, x264 can't recognize my AVI at all :(
What is the recommended way to feed UtVideo file into x264 encoder then?
:thanks:

[yup]

kypec!
try use simple script as input for x264
AVISource("Your file.avi")
I think this different approach for 420 coding.
yup.

[7ekno]

Totally agree with you, just don't have any idea of how to do it!

I would start with SimpleSlugUpscale (http://forum.doom9.org/showthread.php?t=153860), it works quite well on de-interlacing and upscaling ;) Sure it's not done within QTGMC, but it a nice "all in one" !

And it's a nice place to find all the filters needed for SSU & QTGMC in the one place (http://www.gyroshot.com/simpleslug.htm) (thanks Robert!) ;)

Also for those with little Avisynth experience, the walk thru (http://www.gyroshot.com/upscale2.htm) Robert has on his website (to get his filter & QTGMC) working is also pretty helpful !!

Regarding Neat Video: I've tested a lot of other softwares and plugins and conclueded this was the best

Um, yeah :P If I were you I would check out MCTemporalDenoise (http://forum.doom9.org/showthread.php?t=139766) and/or DFTtest (http://forum.doom9.org/showthread.php?t=132194) ;)

A simple command like MCTemporalDenoise(settings="low", gpu=true) will beat most things for denoising and speed !!! But of course it's probably far more customisable than NEATVideo !!!

7ek

[Desmodeus]

Comment Removed

[Mounir]

Is YUY2 /RGB support planned for QTMC ? I'm not a big fan of YV12

[-Vit-]

Is YUY2 /RGB support planned for QTMC ? I'm not a big fan of YV12
Adding other colorspaces wasn't on my to-do list, but I guess YUY2 should be fairly straightforward. It won't make it into the next update (due soon), perhaps the one after.
I don't think MVTools2 supports RGB input and MVTools2 is at the core of the script.

[Didée]

If it has to be by all means, you can do RGB, too. Take RGB in, clone it to YV12 to do the motion search. Then separate the three RGB channels to three greyscale YV12 clips, perform basically 3 times TGMC on that bunch, and join back to RGB.

"Mischief managed."

[palwan]

Any idea, why I get slower speed using QTGMC(preset="v.fast") ? what I mean I get faster speed using the options < "v.fast".

[Gavino]

Any idea, why I get slower speed using QTGMC(preset="v.fast") ? what I mean I get faster speed using the options < "v.fast".
It should be preset="Very Fast".
"v.fast" is not recognised, so it reverts to the default of "Slower".

[dansrfe]

Any idea, why I get slower speed using QTGMC(preset="v.fast") ? what I mean I get faster speed using the options < "v.fast".

With that logic I should be getting extreme or super duper fast speeds using QTGMC(preset="e.fast") or QTGMC(preset="s.d.fast") :rolleyes:

[palwan]

as it as been showed in script V.Fast,S.Fast,U.Fast, so I went according to that, but now I will try it with "Very Fast" and see the result.

[Gavino]

as it as been showed in script V.Fast,S.Fast,U.Fast, so I went according to that
You were looking at a comment in the code that uses abbreviations to fit on the line for the table below it.
For the actual values, see the comments in the Presets/Tuning section.

[palwan]

Yes, you were right Gavino :-) Now it works fine, thanks alot for pointing me out.

[szabi]

AVISource("C:\my_dv_vhs_video.avi,fourCC="cdvc").ConvertToYV12(interlaced=true).QTGMC( Preset="Slow", EdiMode="NNEDI3" ).SelectEven().FFT3DFilter (sigma=2, sharpen=0.4)

I am using this for deinterlacing and sharpening my video.
I tried preset slower but it was too slow that is why I changed preset slow, but the encoding speed looks like the same as slower.

Are there any way to speed up it?
Multithread support or anything else which can help to keep the quality with better speed.

bye
szabi

[yup]

szabi!
I am using QTGMC 2.51 wit Set Avisunth 2.6 build for multi-threading and masktools 2.6. For quad core speed up 2.5-3 times comparing to one thread.
For speed up encoding, first make lossless AVI (I am prefer Ut codec) using avisynth script and after make encoding.
yup.

[szabi]

I have DV-AVI (720x576@25fps). Should i transform it to an other avi, before encoding?
I think an unnecessary encoding just decrease the quality.
That is the last avisynth version I know: Avisynth 2.58 (http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/).
I have to check what masktool is.
It is the first time I hear about.

[Gavino]

I have DV-AVI (720x576@25fps). Should i transform it to an other avi, before encoding?
I think an unnecessary encoding just decrease the quality.
That's why yup said use a lossless codec for the intermediate. The idea is that a 2-pass encoder (for your final result) can be sped up by using the lossless intermediate as input rather than processing the (slow) script twice.

[Mystery Keeper]

I have DV-AVI (720x576@25fps). Should i transform it to an other avi, before encoding?
I think an unnecessary encoding just decrease the quality.
That is the last avisynth version I know: Avisynth 2.58 (http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/).
I have to check what masktool is.
It is the first time I hear about.

Your avi is encoded (not sure with what codec, but "avi" is just a container). When you process it with AviSynth, you get uncompressed frames, which you can either store as is or compress with encoder. If you save your video uncompressed, it takes a LOT of space to store and memory to play, so you better compress it. When it comes to using heavy scripts in AviSynth, it is oftenly good to save the output uncompressed or compressed with lossless codec, then compress it with the codec of your choice. That way AviSynth is not loading your CPU at actual compressing and doesn't run twice during 2 pass encoding.

[szabi]

As I wrote my avi is 720x576@25fps (FourCC:dsvd[sony digital video]).
But it is hard to work with it, so in script you see I change it to "cdvc"

Do i have to transfer it to uncompressed format or any kind of script modification is enough?

szabi

[ajp_anton]

I'm having trouble with a small timer that changes every frame. Instead of just upscaling the changing digit (MCBob does this), two frames are blended together.
Right now I'm using tr0=1,tr2=0,rep2=1 to improve this, but it reduces the quality of the rest of the video. What else can be done?

[-Vit-]

I'm having trouble with a small timer that changes every frame. Instead of just upscaling the changing digit (MCBob does this), two frames are blended together.
Right now I'm using tr0=1,tr2=0,rep2=1 to improve this, but it reduces the quality of the rest of the video. What else can be done?
You could set tr1=1 also to reduce the first temporal radius used for the output.

You could reduce blocksize so it is less likely to blend the digit as it finds it a poor block match. Try Blocksize=8. Too small a block size can cause poor motion matches (need enough detail in a block to make a good match)

A similar idea would be to reduce the SADs used for the temporal passes. However, I removed those as arguments in this version (can't remember why - probably cutting down argument count). You can find them in the script - search for _thSAD1 (& 2). The first has the stronger effect on the output. It defaults to 10*8*8, try reducing it to 5*8*8 or similar. This will make it less willing to blend blocks if they match poorly. It may reduce the effectiveness of the deshimmering though. If you don't like editing the script for a single vid, then use TempGaussMC_beta2, which has these values as arguments.

I may reinstate the SAD values as arguments next version.

[kolak]

Is there a way to use QTGMC with YUY2 in lossless mode?
When I tried it says not supported- converting to YV12 solves problem, but I would like to keep source as YUY2.

Thx

[Didée]

interlaced_yuy2_video

ConvertToYV12(interlaced=true).QTGMC().ConvertToYUY2().MergeChroma(last.Yadif(mode=1)) :p


It would be possible to make a "proper" YUY2 processing mode (it has been done before for TGMC). It only requires a bazillion of ConvertInterleavedToPlanar()/ConvertPlanarToInterleaved() Back-and-Forth-conversions in the script.

[kolak]

interlaced_yuy2_video

ConvertToYV12(interlaced=true).QTGMC().ConvertToYUY2().MergeChroma(last.Yadif(mode=1)) :p


It would be possible to make a "proper" YUY2 processing mode (it has been done before for TGMC). It only requires a bazillion of ConvertInterleavedToPlanar()/ConvertPlanarToInterleaved() Back-and-Forth-conversions in the script.

What is the quality loss?
What Yadif is doing there?

Thx

[Didée]

As they are, Q/TGMC can not process YUY2 video. However, the most obvious benefits of Q/TGMC is what they achieve on the luma plain. Therefore, that scriptline suggests to use Q/TGMC for luma (which is identical for YUY2 & YV12 anyways), and one of the "simple" deinterlacers for chroma.

[kolak]

Sounds good and I assume processing speed will increase a bit also.


Andrew

[Didée]

No. It will be a little slower. Q/TGMC is still doing "all" of the work, including chroma. A 2nd deinterlacer is used additionally, and its result replaces that of Q/TGMC (on chroma channels). More overall work => slower processing.

Such a "cheat mode" definetly could be integrated in the function, and then it would be possible to avoid a major amount of the overhead. (Not all, but most).

[-Vit-]

Thanks for the YUY2 version. It's good you didn't add it to the lossless code, because that part has been almost completely removed in the next version - it's been superseded by something quite new. I'll merge the changes into the version after next, when I'll also be looking at chroma optimizations.

[kolak]

Thanks- I was one of them, but interested in lossless part- hehehe :)


Andrew

[yup]

Stephen R. Savage! :thanks:
My source is analog capture in YUY2 colorspace. Now we can forget about wrong conversion for YUY2 to YV12 for interlaced source.
You use 2.58 Avisynth ot MT 2.57 build? Set 2.6 do not support planar video.
yup.

[pokazene_maslo]

Hello.
I have 3 questions about denoising.

fft3dfilter can be used to denoise interlaced and progressive video. If I use QTGMC like thisQTGMC( Preset="Very Slow", Sigma=2.2 , NoiseBypass=1, NoiseRemove=1.0, NoiseRestore=0.0 )

fft3dfilter is used before deinterlacing. However suggested order of filters is "deinterlace->crop->resize->denoise".
My question is which provides better quality? Denoise first and then deinterlace or deinterlace first and then denoise?

After answering question number 1, how to make fft3dfilter motion compensated? I'm using 64 bit avisynth and don't know how to do that.

Is it OK to replace fft3dfilter with fft3dgpu?

Thanks in advance!

[2Bdecided]

I just wanted to post to say that I love QTGMC. The overall speed increase on a full encode seems to be much greater than it appears to be during the first few frames. I don't know if that's right/wrong, but the output is fine so I'm very pleased.

Cheers,
David.

[-Vit-]

Hello.
I have 3 questions about denoising.

fft3dfilter can be used to denoise interlaced and progressive video. If I use QTGMC like thisQTGMC( Preset="Very Slow", Sigma=2.2 , NoiseBypass=1, NoiseRemove=1.0, NoiseRestore=0.0 )

fft3dfilter is used before deinterlacing. However suggested order of filters is "deinterlace->crop->resize->denoise".
My question is which provides better quality? Denoise first and then deinterlace or deinterlace first and then denoise?

After answering question number 1, how to make fft3dfilter motion compensated? I'm using 64 bit avisynth and don't know how to do that.

Is it OK to replace fft3dfilter with fft3dgpu?


The basic TGMC algorithm strongly deinoises, so the NoiseBypass setting is there to help keep grain and fine detail. But yes, with those settings it works for controlled denoising too. And since you're going to get some kind of denoising with TGMC whatever you do, then what you're doing is not unreasonable. However, which method provides best quality only you can decide. I use a hybrid approach, denoising some in QTGMC, some afterwards.

According to the docs, FFT3DFilter performs "partial motion compensation" internally. The temporal window is controlled with the BT setting in QTGMC. You can also get somewhat stronger motion-compensated denoising by increasing tr2 (max=3).

I haven't tried using fft3dgpu in QTGMC yet. I could be wrong, but doesn't fft3dgpu prevent use of SetMTMode? I couldn't imagine running (Q)TGMC single threaded, but I guess some people are...?

There are new features coming in the next couple of days concerning noise processing. I'll detail them at release time.


I just wanted to post to say that I love QTGMC. The overall speed increase on a full encode seems to be much greater than it appears to be during the first few frames. I don't know if that's right/wrong, but the output is fine so I'm very pleased.

Thanks. I use MeGUI for processing and I've noticed a similar effect. Maybe the fps calculation is taking account of initialization time?

[2Bdecided]

I use MeGUI for processing and I've noticed a similar effect. Maybe the fps calculation is taking account of initialization time?MeGUI here too - don't know - the frames themselves count by slowly at first, then far quicker after a while!

Cheers,
David.

[Gavino]

MeGUI here too - don't know - the frames themselves count by slowly at first, then far quicker after a while!
Probably because the later frames get more benefit from Avisynth's cache?

[-Vit-]

Probably because the later frames get more benefit from Avisynth's cache?
There are no huge temporal windows, so wouldn't the caching settle relatively quickly after only a few frames? The effect I see in MeGUI lasts for minutes. :confused:

[Didée]

If the effect is not present during e.g. screen previev in Vdub, but is present during encoding (probably to x264) - - - what does this tell you? :)

Maybe related (or maybe not) - see the speed oddity that Zep has reported here (http://forum.doom9.org/showthread.php?p=1445970#post1445970).

My vague guess is that it's related to "looking into the future". Keep in mind, with preset fast|medium|slow|slower, x264 is requesting 30|40|50|60 frames ahead of the current frame, due to MB-tree. That's not trivial! Quite possible that Avisynth needs some time to adapt its caching strategy to this situation.

[ajp_anton]

My vague guess is that it's related to "looking into the future". Keep in mind, with preset fast|medium|slow|slower, x264 is requesting 30|40|50|60 frames ahead of the current frame, due to MB-tree. That's not trivial! Quite possible that Avisynth needs some time to adapt its caching strategy to this situation.
I don't think Avisynth has any idea what x264 is doing. It should just read frames linearly no matter what the lookahead is.
x264's progress only reports when the frames are actually processed, which means that for the first ~40 frames of Avisynth processing, x264's speed is 0. Because the speed reported is the average, it will speed up during the encode. And finally, for the last ~40 frames, Avisynth will finish and x264 can process without any input bottlenecks.

[-Vit-]

I was encoding to lossless, so x264 is not the issue I'm seeing. Checking the MeGUI source, it is because MeGUI starts timing before the first frames are processed (or are reported as processed). The initialization time (several seconds on a complex script like this) skews the average for a while. I didn't check but there may also be a timing lag due to the threading of the status updates too (which sleep for a second at a time). I tried a quick tweak so it only starts the timer once frame 0 has come in and the fps converges quite quickly. MeGUI displays an overall average fps, a rolling average like vdub would be less prone to this.

[kypec]

I haven't tried using fft3dgpu in QTGMC yet. I could be wrong, but doesn't fft3dgpu prevent use of SetMTMode? I couldn't imagine running (Q)TGMC single threaded, but I guess some people are...?

Hey -Vit-, could you share an example script demonstrating how is QTGMC run multithreaded? I mean do you prefer SetMTMode(...) {temporal distribution} or MT(...) {spatial distribution} in your workflow?
:thanks: in advance!

[AnXioZ]

Hey guys, I'm having some trouble deinterlacing 1080i60 (60 fields per second) source. I want to keep the motion resolution so I am looking at 1080p60 deinterlaced result. When using QTGMC with any of the presets I get very weird results, such as repeated past frames so the video looks quite jerky. I am previewing the video in Avisynth. Adding "SelectEven()" or "SelectOdd()" fixes the issue but of course the motion resolution is cut in half. Any advice is appreciated. Thanks.

[aegisofrime]

Hey -Vit-, could you share an example script demonstrating how is QTGMC run multithreaded? I mean do you prefer SetMTMode(...) {temporal distribution} or MT(...) {spatial distribution} in your workflow?
:thanks: in advance!

Do it like this:

SetMTMode(5,4)
DGDecode_mpeg2source("C:\Source.d2v")
SetMTMode(2,4)
QuickTGMC(Preset="Slower")

Distributor()

Do not MT() QTGMC. It causes artifacts.

Hey guys, I'm having some trouble deinterlacing 1080i60 (60 fields per second) source. I want to keep the motion resolution so I am looking at 1080p60 deinterlaced result. When using QTGMC with any of the presets I get very weird results, such as repeated past frames so the video looks quite jerky. I am previewing the video in Avisynth. Adding "SelectEven()" or "SelectOdd()" fixes the issue but of course the motion resolution is cut in half. Any advice is appreciated. Thanks.

It sounds like you might have your field order wrong. Try adding either AssumeTFF() or AssumeBFF() before calling QTGMC. Like so:


SetMTMode(5,4)
DGDecode_mpeg2source("C:\Source.d2v")
SetMTMode(2,4)
AssumeTFF() # or AssumeBFF()
QuickTGMC(Preset="Slower")

Distributor()

@Vit: Any release date for the new version? :)