QTGMC Deinterlacing Script (v3.32)

[ihhm]

Can anyone please help me find a way to eliminate the vertical shimmers in this clip?

Sample clip:
http://www.mediafire.com/?zc2egghbal2vb11

The shimmers are most visible on the vertical lines of the window blind and cabinets. I even tried the preset "Placebo", but the shimmers are still there. Please pardon my ignorance if these are not called shimmers as I just started learning about encoding. I am still finding my way around MeGUI, QTGMC and Srestore.

[Mr Alpha]

I get these weird vertical lines (clearly visible in the clouds). Anybody have any recommendations for getting rid of 'em?
http://mralpha.s3.amazonaws.com/qtgmc-artifacts.png

[bluered1]

thanks for your great work on this awesome script.:) (http://www.egitimduragi.com/)

[-Vit-]

ihhm: QTGMC can deal with horizontal shimmering effects, but not really the vertical problems that clip is showing. It's not even a shimmer really, being rather occasional...?
Mr Alpha: Similarly, that doesn't initially look like anything to do with QTGMC, but I can't tell without seeing a short clip of the affected source.
bluered1: You're welcome.

[ihhm]

Vit, thank you for your reply. I will start a new thread outside of QTGMC to see if other filters can help.

[Mr Alpha]

Mr Alpha: Similarly, that doesn't initially look like anything to do with QTGMC, but I can't tell without seeing a short clip of the affected source.There is definatly a hint of the same pattern in the noise in the source, but it looks to me like rather than removing the noise QTGMC stabilizes it. Here (http://mralpha.s3.amazonaws.com/VTS_01_2-split.VOB) is a 10sec piece of the source.

[-Vit-]

That's a messed up source. The last shot is progressive and needs no deinterlacing. The first shot looks interlaced, and the top fields are fine, but the bottom fields are just a blend of the current and next frames (i.e. they do not contain a new temporal frame). I think the middle shot (from which your screen cap is taken) is the same. Then there's that fairly strong noise, over a detailed image.

You're not going to get double rate out of this, so QTGMC may not be the correct approach, although it does even out the differences in the fields - you'll want a SelectEven afterwards.

The frame blending means the noise has a temporal echo, which may fool any temporal denoising into thinking it's not noise, meaning you need a stronger denoise that you would expect. A spatial denoise of sufficient strength will destroy the detail. Also the temporal processing of QTGMC is reinforcing the issue, leaving you with that fairly stable grain. Really this needs a more customized repair job, beyond the scope of QTGMC. Within the QTGMC settings you might want to set TR1=1 and TR2=0 (or 1), to reduce the temporal processing of QTGMC and stop the grain from being stabilized. That will leave you with more noise to get rid of though...

[Mr Alpha]

That's a messed up source. The last shot is progressive and needs no deinterlacing. The first shot looks interlaced, and the top fields are fine, but the bottom fields are just a blend of the current and next frames (i.e. they do not contain a new temporal frame). I think the middle shot (from which your screen cap is taken) is the same. Then there's that fairly strong noise, over a detailed image.

You're not going to get double rate out of this, so QTGMC may not be the correct approach, although it does even out the differences in the fields - you'll want a SelectEven afterwards.

The frame blending means the noise has a temporal echo, which may fool any temporal denoising into thinking it's not noise, meaning you need a stronger denoise that you would expect. A spatial denoise of sufficient strength will destroy the detail. Also the temporal processing of QTGMC is reinforcing the issue, leaving you with that fairly stable grain. Really this needs a more customized repair job, beyond the scope of QTGMC. Within the QTGMC settings you might want to set TR1=1 and TR2=0 (or 1), to reduce the temporal processing of QTGMC and stop the grain from being stabilized. That will leave you with more noise to get rid of though...
If the frame blending is what is causing the issue, would it make sense to do it like this:

First run QTGMC with TR1=1 and TR2=0, but without any denoising at all,
then run SelectEven to get rid of the blended frames,
And lastly run a separate denoiser on the remaining even fields, thus hopefully avoiding the temporal echo?


A side question: What about crop? Would it make more sense to move crop to before QTGMC and thus save me some pixels to process, or would that interfere with QTGMC?

[-Vit-]

If the frame blending is what is causing the issue, would it make sense to do it like this:

First run QTGMC with TR1=1 and TR2=0, but without any denoising at all,
then run SelectEven to get rid of the blended frames,
And lastly run a separate denoiser on the remaining even fields, thus hopefully avoiding the temporal echo?

Yes that seems reasonable. There will still be a little blending in the result since QTGMC fundamentally relies on some temporal processing. Still it's better than completely discarding the blended frames, since they contain genuinely new spatial data, even if it is blended.

A side question: What about crop? Would it make more sense to move crop to before QTGMC and thus save me some pixels to process, or would that interfere with QTGMC?
Yes, that's fine.

[nhope]

Adding resizing at all is rather pushing the feature envelope of QTGMC and gamma-aware resizing has never really caught my interest, but I'll make a note to have a look...
I'm starting to look into upscaling with NNEDI3, as highlighted in this thread (http://forum.doom9.org/showthread.php?t=163345).

e.g.

#720x576 interlaced source
QTGMC()
NNEDI3_rpow2(rfactor=2, cshift="spline36resize", fwidth=1280, fheight=720)

Is this sensible, or is there a smarter way to integrate this type of resizing with the deinterlacing, since QTGMC uses NNEDI3 anyway?

-Vit-, if you are considering including resizing in a future version of QTGMC, is this something you could look at instead of, or in addition to the more basic resizers?

[-Vit-]

#720x576 interlaced source
QTGMC()
NNEDI3_rpow2(rfactor=2, cshift="spline36resize", fwidth=1280, fheight=720)
Is this sensible, or is there a smarter way to integrate this type of resizing with the deinterlacing, since QTGMC uses NNEDI3 anyway? ... if you are considering including resizing in a future version of QTGMC, is this something you could look at instead of, or in addition to the more basic resizers?
That is my preferred method of upscaling by far. If upscaling makes it into QTGMC it will be via some NNEDI3-related method.

[tormento]

Is it possible to use it to convert from 50i to 25p interpolating adiacent frames?

[kypec]

Is it possible to use it to convert from 50i to 25p interpolating adiacent frames?
Yes of course, it's the main purpose of this awesome script! :p
Please read the first post and included documentation for details.

[TheSkiller]

Yes of course, it's the main purpose of this awesome script! :pI have to disagree, the main purpose is to bob-deinterlace interlaced content which means the result has double the frame rate of the source. :p

There are no "adjacent frames" that need to be interpolated. It's actually the other way around, if you want to stay with the source frame rate, then you are throwing away 50% of the available temporal information (every other bob-deinterlaced frame is discarded). As a consequence, with most videos, especially ones with fast and/or shaky motion, this will lead to a stroby looking video. QTGMC offers the option to add motion blur to aid this but still it's naturally very recommendable to go with the double rate output if there's no particular reason not to (like YouTube).

[tormento]

I have to disagree, the main purpose is to bob-deinterlace interlaced content which means the result has double the frame rate of the source. :p
No, I want to go from 50i to 25p (with same speed, obviously). I did hope in something to use both fields, not only one.

[smok3]

tormetno, 1st example in 1st post of this thread:

YourSource("yourfile")
QTGMC( Preset="Slow" )
SelectEven()

[tormento]

tormetno, 1st example in 1st post of this thread[/CODE]
Does it take two fields in consideration or only one?

[Didée]

At max settings, up to fourteen fields for each output frame.

Don't compare QTGMC (its workflow) with that of other deinterlacers. it works different, it IS different.

Usual deinterlacers go "to weave, or not to weave, that's the question".

QTGMC basically is a motioncompensated temporal superresolution filter.

[TheSkiller]

tormento sorry you don't seem to understand how this whole deinterlace thingy of interlaced video works.
If you deinterlace an interlaced video using QTGMC("slower") naturally both fields will be taken into account for deinterlacing and that is why the output has double the frame rate of the input.
It converts 50 fields per second (wrapped in 25 interlaced frames per second) to 50 frames per second. If you then try to end up with 25 progressive frames per second you are throwing away what originally was in every other field. So to take "both fields into account" you have to stick with double rate output, as simple as that. You cannot keep the motion of 50p or 25i (50i) with just 25p. The speed of the video stays the same of course, speed is not even involved at all.

[Asmodian]

QTGMC basically is a motioncompensated temporal superresolution filter.

:D

I love how you get to the heart of the issue without dumbing it down much. Thanks Didée.

I have noticed that QTGMC does take both fields into account even if you output 25p, by this I mean there are more details on the output frame than exist on one field. I will have to leave how this is accomplished to others. ;)

[-Vit-]

Yes, QTGMC does "take both fields into account" (and more) even if you keep single rate. Every output frame is constructed from a range of neighbor fields as Didée has noted. By default the current field is interpolated into a full frame, then the two fields before and after (interpolated + motion compensated) are combined into the frame in such a way as to remove bob-shimmer. This temporal processing also enhances detail to some degree and has some noise reducing effect.
So all source data will have been used in your output even after a SelectEven(). The result will be primarily based on the even fields of course, but the neighboring ("thrown away") fields will have had an influence too.

[Gavino]

I have noticed that QTGMC does take both fields into account even if you output 25p, by this I mean there are more details on the output frame than exist on one field. I will have to leave how this is accomplished to others. ;)
Most deinterlacers will take neighbouring fields into account in some way, rather than simply interpolating a single field. Exceptions to this are Bob (at one end of the sophistication spectrum) and the nnedi family (at the other).

[ajp_anton]

When EdiMode doesn't match anything (so it uses Bob) (of course together with SourceMatch), the result looks horrible.
Adding a ComplementParity to bobbed fixes this.
Line 353-355: bobbed = (InputType == 0) ? planarClip.Bob( 0,0.5 ).ComplementParity() : \
(InputType == 1) ? planarClip : \
planarClip.Blur( 0,1 )

[Gavino]

When EdiMode doesn't match anything (so it uses Bob) (of course together with SourceMatch), the result looks horrible.
Adding a ComplementParity to bobbed fixes this.
I haven't looked into the details of how the bobbed clip is used inside QTGMC, and hence why your fix is necessary, but I suspect it is connected with the fact that Bob always resets its output clip to the default BFF.

Therefore, the parity should probably only be reversed if the input clip is TFF.

[ajp_anton]

I haven't looked into the details of how the bobbed clip is used inside QTGMC, and hence why your fix is necessary, but I suspect it is connected with the fact that Bob always resets its output clip to the default BFF.

Therefore, the parity should probably only be reversed if the input clip is TFF.
It's captured from an analog source, and in all the years I've captured these videos, I've never bothered to check which one it actually is, or which one is default. But I always had to use ComplementParity() before deinterlacing. So yeah, it's probably because of the non-default order.

[Gavino]

That suggests your captured clips are TFF.

If my assumptions about the problem are correct, your suggested fix to QTGMC will work for your source, but will make BFF sources go wrong instead. It needs to check the parity of the original input and reset the Bob() output to match it, rather than calling ComplementParity() unconditionally.

[-Vit-]

Thanks ajp_anton/Gavino, noted. I finally have the time for occasional QTGMC work again. I may put out a service release with a few minor bug-fixes/improvements in the next week or so, as the next major release will still take some time.

[shagratt71]

Im sorry if this a stupid question but I'm really trying my best to get to grips with all this. Is it possible to use QTGMC within Ripbot?, if so, is there anyone who would be willing to lend me a hand in setting it up?

[zerowalker]

Does anyone have like, a package for all the 64 bit plugins that exist and that is needed for QTGMC?
As i heard it´s should be pretty much faster, would like to try it:)

-Vit- // Good Work;U!!

[dbart]

Hi everyone :)

is there a filter/solution for this record ?

http://www.mediafire.com/?rwugl4d4269x5v6

thanks

[smok3]

dbart: looks like a dirty (composite connection?) analog path was there to make this happen, possibly with some less than perfect digital compressor (might be also something to do with the way some of the digital tapes work, when their head is getting aged...), deinterlacing works thought (i just tryed quick yadif=0).

[ajp_anton]

I'm starting to look through / rewrite the code for this to better understand how it works.
I noticed that instead ofts = bobbed.temporalsoften(1,255,255,28,2)
binomial = ts.merge(bobbed, .25)it's faster to dobef = bobbed.trim(0,-1)+bobbed
aft = bobbed.trim(1,0)
binomial = merge(bef,aft).merge(bobbed)
There are some slight differences of max 1, probably due to rounding.
Comparing them to a mt_lutxyz, which I guess is the most accurate (in 8-bit), on my test clips it seems temporalsoften has on average ~22% errors and "my" trick has ~25.0% (how many pixels are off by 1).
Not that it makes much speed difference either, but it's something...
edit: mt_lutxyz actually runs between these two in terms of speed (but obviously needs much more RAM and has slower startup time).

[-Vit-]

I doubt your few extra out-by-1 pixels will cause much problem since the result is only used for motion analysis where the pixels are aggregated into blocks. The lack of motion compensation at that point is likely a much more significant source of motion analysis error.
However, TemporalSoften has (simplistic) scene change detection, whereas your script will blend across scene change boundaries, which may cause analysis errors or conceivably make scene change boundaries be missed when motion analyzed...

[ajp_anton]

Ah, didn't think about that. That could be why it's slower =). The content I'm fine-tuning this for doesn't have any scene changes so I'm fine without it.

rep0 seems to take care of most of the scene change artifacts though. Especially rep0=0, which leads me to:
Is there any downside to using QTGMC_KeepOnlyBobShimmerFixes with rep0=0? It's "blocked" in your script (and the original TGMC), but I think it does a pretty good job. (And rep1/rep2? Haven't gotten that far yet =).)

edit: Another thing I've been thinking about... that epsilon in GaussResize.
I realize how meaningless this is, as it's probably well within the precision of 8 bits, but it disturbs me a little that the epsilon "downsizes" the clip. Using it to "shift" instead helps me sleep a little better at night =). (GaussResize(w,h,ep,ep,w,h,p=2))

[-Vit-]

Temporal smoothing is used to remove bob-shimmer, but we don't want large areas of motion blur so the Rep0/1/2 settings limit the amount of change that the temporal smoothing is allowed to make. Higher values for Rep0/1/2 allow larger areas of change from the smoothing, but (counter intuitively) 0 switches of the limiting completely and so allows all changes through. You're right that there is a code path for Rep0/1/2 = 0 that is not used. However, that code path would only allow 2-pixel high areas of change, much bob-shimmer covers a larger area than that. It would be getting close to doing no temporal smoothing at all, similar to TR0/1/2=0 and would be especially bad on stationary detail. Having said that, it does seem to be a little odd not to allow that code path even if it is not the most useful.

Why is 2 pixels not enough? Consider a stationary single pixel high horizontal line, positioned such that it appears only in the even fields. The bob will expand that to a 3 pixel high line, and clearly it will be a cause of major bob-shimmer, flickering on and off. When temporally smoothed, the now 3 pixel high line is softened in the even frames and appears in the odd frames. Bob shimmer removed - by a 3-pixel high area of change, which would be removed if you followed the Rep0=0 code path... I could make that more clear with a diagram, but I hope you get the idea...

[I note that my comments on that function need an update for precision: the two vertical in/expands allow through areas of change up to 4 pixels high, the in/deflate and RemoveGrain are not limited vertically so they also perform some measure of mask clean up]

As I'm sure you're aware, the epsilon is only there to trigger the GaussResize to do its blur even though we're not actually resizing, I'm sure it doesn't matter much where it is placed given the tiny value and the fact it is being used on a huge blur anyway. I do wonder if there's a more efficient way to do a Gaussian nowadays, or something similar.

[ajp_anton]

Yes it seems that higher reps are needed for really worst case scenarios (made some in mspaint =)).

rep=0 flickers slightly on most 1-pixel lines but works on everything (?) else, rep=3 captures 1-pixel lines, but rep=5 is needed for when two lines are spaced 2 pixels from each other. Here rep=0 fails hard.
What I don't like about rep>0 is that they allow too much blur in motion, and my videos are slightly blurred before being interlaced, so rep=0 works well there.

(I know why the epsilon is used, I just don't like where it's used, even though it makes exactly zero difference =).)

[-Vit-]

Those "worst case" examples occur in reality - almost any static text/captions/graphics, and also detailed stationary shots. I can easily find examples where the rep=0 code path looks very bad. However, as I have a small update to make shortly I will probably enable that code path with Rep=1 and shift the other Rep values up by 1. I'm sure the 2 people who actually use those settings manually can cope with the change :p

[Stereodude]

Does anyone have like, a package for all the 64 bit plugins that exist and that is needed for QTGMC?
As i heard it´s should be pretty much faster, would like to try it:)I tried to get QTGMC to work on a Windows 7 x64 system and was basically unsuccessful. I could use QTGMC in 64-bit mode (no script errors or complaints). In VirtualDub x64 after 42 frames it would basically go unusable. Advancing to the 43rd frame would cause it to hang for several minutes before finally returning the image. Same for the 44th frame, etc... This was with full 1920x1080i60 content. I gave up and used a 32-bit flow with piping to x264 x64.

Here is my post on it (http://forum.doom9.org/showthread.php?p=1538185#post1538185).

[wOxxOm]

if you have a 64-bit Windows and a lot of RAM (4+ GB) then patching 32bit host exe (avs2yuv etc) with 4GB limit patch (http://www.ntcore.com/4gb_patch.php) helps qtgmc a lot - then you can set SetMemoryMax(3072) or probably even more and enjoy your qtgmc.

[zerowalker]

Okay will try it:)

[SamKook]

if you have a 64-bit Windows and a lot of RAM (4+ GB) then patching 32bit host exe (avs2yuv etc) with 4GB limit patch (http://www.ntcore.com/4gb_patch.php) helps qtgmc a lot - then you can set SetMemoryMax(3072) or probably even more and enjoy your qtgmc.

If you encode to x264 directly, it already has 4GB support.

But what I wanted to say is that using SetMemoryMax sometime helped prevent crashes, but it doesn't seem to limit the RAM usage of the encoder, or it doesn't do it to that exact number. I used to set it to 1024 and x264 and virtualdub were using between 1.6 and 2.2GB of RAM depending on the source.

Piping it to 64bit x264(32bit also works but is a little slower) using avs2pipe(avs2yuv had problems with v2.6 of avisynth I think) without having distributor() in the avs(seemed a little faster with it, but it kept crashing with my settings) is the only way I found to prevent crashes using extreme setting with QTGMC

[redfordxx]

You might wanna consider trying RAverageW and RMerge in your script:
RMerge - if you are bothered with the issue, that max weight can be 255 not 256
RAverageW - for speedup

Pros and cons:
RMerge (mode=256)
+ correctly calculates merging with mask values reaching 255
- not sse optimized yet
RAverageW
+ faster
+ multiple input clips
- y,u,v=3 works but any other numbers disable the processing, like y,u,v=1

Basically, every lut which involves linear combination of clips is possible to write with RAverageW and is faster.

Examples:



lossed1.mt_lutxy( vresharp, "x x y - "+ string(sharpAdj) + " * +", U=3,V=3 )
RAverageW(lossed1,1+sharpAdj,vresharp,-sharpAdj)

mt_lutxy( lossed1, lossed1.VerticalCleaner( mode=1, modeU=-1, modeV=-1, planar=true ), "y x - " + string(SVThinSc) + " * 128 +", U=1,V=1 )
RAverageW(lossed1,SVThinSc,lossed1.VerticalCleaner( mode=1, modeU=-1, modeV=-1, planar=true ),-SVThinSc,bias=128, U=1,V=1)


backBlend2.mt_adddiff( finalNoise.mt_lut( "x " + noiseCentre + " - " + string(GrainRestore) + " * 128 +", U=CNmt1,V=CNmt1 ), U=CNmt2,V=CNmt2 )
RAverageW(backBlend2,1,finalNoise,GrainRestore,bias=-noiseCentre, U=CNmt1,V=CNmt1)
#however here we have problem with chroma processing option (only 1 or 3 possible)

degrain1.Merge( degrain2, 0.2 ).Merge( edi, 0.0625 )
RAverageW( degrain1, 12/16.0, degrain2, 3/16.0, edi, 1/16.0 ) # if I am not mistaken

[RockTheBass]

Hi everybody!

I need some help to encoding an NTSC video with 29.970 fps.
This is an IVTC video. It has 2 double frame after every 5th frame.

The video's Parity: Assumed Bottom Field First.

I want to deinterlace the video. Please help me how I do this properly using QTGMC. I think this is the best deinterlace filter, its works like a charm ;)

If I want to deinterlace a 25FPS PAL movie I using this script: AssumeBFF().QTGMC(Preset="Very Slow", FPSDivisor=2, EdiThreads=4)

But in this case I has to remove the duplicated frames, so I need to use something like this, right?

TFM(slow=2,clip2=QTGMC(preset="very slow", EdiThreads=4).SelectEven()).Tdecimate()

Unfortunatelly this script isnt looks great...

Can somebody help me and post me a proper script?

Thank you!

[Boulder]

TFM().TDecimate() for IVTC, no QTGMC at all there.

[RockTheBass]

TFM().TDecimate() for IVTC, no QTGMC at all there.

Ok, but I thought i hould combine them together, because the QTGMC is a well good deinterlace filter.

[Boulder]

There is nothing to deinterlace. After you IVTC, you have a progressive clip running at 23.976fps.

[RockTheBass]

There is nothing to deinterlace. After you IVTC, you have a progressive clip running at 23.976fps.

I understand. Then can you give it some good IVTC script, please? :)

[-Vit-]

You might wanna consider trying RAverageW and RMerge in your script
I'll have a look. I did promise a minor update and I haven't delivered on that yet. It'll be an incentive...

I particularly like the last of the three suggestions because it makes the temporal weightings of the neighbor frames a little bit clearer. Those weightings are the key feature in (Q)TGMC to remove bob-shimmer.

Not sure how much of a speed impact it will have though, most of the time is spent in NNEDI3 and MVTools...

[Didée]

Back when I wrote the old TGMC, I simply used Merge to reduce the number of required plugins. If it would've been for reasons like speed or clarity, I could've used mg262's Average() plugin just as well.

Speed should hardly be concerned with all three operations mentioned. Perhaps some 1080i-deinterlacing will jump from 2.345 fps to 2.346 fps? ^^

[Boulder]

I understand. Then can you give it some good IVTC script, please? :)Like I already wrote: TFM().TDecimate() is probably all you need. They are in the TIVTC plugin if I'm not mistaken.