QTGMC Deinterlacing Script (v3.32)

[Didée]

It looks to be an ntsc tv capture and an attempted progressive divx encode but where someone forgot to turn off the interlace switch. The 4700 kbps is a giveaway it was handled by someone even more amateurish than myself. The trouble is that when QTGMC gets its mitts around it various sequences will show 'morphing' or stretching of facial features and such. As if the temporal smoothing is really having to work overtime (?) Very disagreeable.
The "trouble" is not related to QTGMC, you'll see exactly the same issue when using a simple Bob(). The clip simply is broken. Someone did change the vertical framesize with a "progressive" resizing method, thereby destroying the interlaced field structure. As a result, each top field contains alternating bands of top- and bottom fields, and same for the bottom field.

Here's a simple simulation of what has happened:
BlankClip(width=576,height=480)

interleave(BlankClip(width=576,height=480,color=$006000),
\ BlankClip(width=576,height=480,color=$600000))

AssumeTFF().ShowFrameNumber()

i1 = SeparateFields().SelectEvery(4,0,3).Weave()
i2 = i1.bicubicresize(576,464,0,0.5) .addborders(0,8,0,8,color=$200000)

stackhorizontal(i1.addborders(0,0,8,0,color=$002000),i2)

bob(0,0.5)
subtitle("bobbed interlaced source",x=160,y=32)
subtitle("""interlaced source resized 'progressive', then bobbed""",x=576+88,y=32)
return(last)

[nhope]

I'm an idiot. I had H264 decoding disabled in ffshow. I've enabled it now and DirectShowSource will open both .MTS fine. Incidentally the TM700 file had been giving exactly the same error as the HG21 file before I enabled the H264 decoding.

[nhope]

deleted

[nhope]

Didée, 3 questions about the script you used for the doll, which gave excellent results...

1. Have you tweaked that script specifically to cater for the horrific, moiré-inducing nature of the background, or is it a script that you might use generically for HD to 480i conversion?

2. Since QTGMC is a development of tempgaussmc, could tempgaussmc_beta2a(1,1,1,nsize=5,sharp=1,sharpness=0.0,svthin=0.0,sbb=0)
be done in QTGMC, to minimise the number of scripts involved?

3. Where would the "missing" AR 16:9 aspect ratio flag go?

[Didée]

1. Yes / maybe
2. Sure, just need to use parameter names
3. x264: "--sar width:height"

Generally, the usage of QTGMC (or even the 'double' usage) in this case here is ever-so-slightly over the edge.:D - With such a big downsize as in 1080 -> 480, a quite similar result probably could be achived with a much simpler bob (even yadif), or even with a direct fieldbased downsize.
I just had to go the TGMC route, since johnmeyer concluded (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=758762)
I tried your torture test using the QTGMC-based re-size script and the moiré patterns were horrible. I tried some of the slow presets, but that didn't help much. So, as much as I liked the results on my ballet footage, for this clip, I think it fails, and it fails quite spectacularly.
but as can be seen from my two samples, QTGMC of course can deal with this torture clip. One just needs to be a bit careful with the sharpness settings in this case. And of course, with so much high frequencies present, you should NOT do the final re-interlacing without lowpassing. "With best regards, Nyquist." ;)

[-Vit-]

Didée's script in QTGMC 3.31 form. Untested, just a settings conversion. I don't know what tempgaussmc_beta2a is, I only have beta2/mod (maybe a version that supports NNEDI3?).

# For more speed add Blocksize=32 and/or drop NNeurons and/or switch to "Faster"
QTGMC( "Fast", TR0=1,TR1=1,TR2=1, NNeurons=1, SubPelInterp=1, Sharpness=0 )

-- >here< is a good point to save an intermediate Huffy or Laggy or FLV-y -- ;-)

bicubicresize(1440,960)
bicubicresize(720,960,-.8,.6)

p1 = bicubicresize(720,480,-.8,.6)

p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 )

p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)

i1 = assumetff().separatefields().selectevery(4,0,3).weave()

# p1 # straight to 60p
# p2 # plus more calmed
i1 # re-interlaced p2

return(last)


If you're serving the script through MeGUI then you can set the AR by adding this to your script:

global MeGUI_darx = 16
global MeGUI_dary = 9

[sadie]

@didee:

Nice analysis. I understood but half of it. The upshot I take it is that 'clip is broken' = 'clip cannot be reglued'. Again, I wonder if there is a strategy within qtgmc that might somehow minimize that goofy stretching yet still clean out the combing (SelectEven?). And of course I can always just keep it interlaced and live with the blur. It's only to be used at a low resolution anyway. Thanks for the help.

[johnmeyer]

A quick follow-up to myself. I've tried to run the clip through Assume TFF/BFF().SeparateFields() with indifferent results (normal since this is after all a 'progressive clip'.) But both do show the distinctive signs of a field order problem (forward & back then forward again). The question remains: how to clean this up if possible?I downloaded your clip. I have seen this sort of thing before and it is a perfect demonstration of why I always recommend that people NOT deinterlace video and just leave things alone. The problem is not that deinterlacing isn't necessary in some limited circumstances, but rather that so many people screw it up and make things far, far worse.

I have been given many clips like this to clean up. First of all, the idiot(s) that screwed around with it before you got it managed to encode black bars into the video. Obviously you want to crop those out.

Second, the way I have dealt with identical videos in the past is to separatefields() to end up with half-height double-fps video.

I then carefully look at the odd and even fields. In the case of your video, it is quite clear that the odd fields were created from some sort of horrible estimation algorithm. You can see people's faces warp and distort. Yuchh!

The approach then is to decimate (delete) the odd fields, crop out the black bars, resize the remaining fields to the original frame size (minus the crop), and then use MVTools2 to estimate the the missing frames/fields. Obviously you are losing the "resolution" from the decimated fields, but they contain nothing but garbage, so it really doesn't matter.

The code below is extracted from a script I used when I restored all fifty-seven hour-long episodes of the Johnny Cash show for a collector several years ago. He got them from a collector in the UK who got them from Australia who got them from source here in the US. You get the idea. Too many hands. In my case, I was trying to get them to look like the original video broadcasts, and so I converted back to 60i. In your case, you might be happy just to convert them to 30p which is what I have done.

Here's a low bitrate encode of the resulting video:

KibSok_cut (fixed).avi (http://dl.dropbox.com/u/1561578/KibSok_cut%20%28fixed%29.avi)

If you encode at higher bitrate, it should look pretty clean.

loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
top_bottom_crop=40

AVISource("e:\frameserver.avi").ConvertToYV12.killaudio()

crop(0,top_bottom_crop,-0,-top_bottom_crop)

#Throw away bad fields. Video is now half size vertically.
separatefields().selecteven()

source=LanczosResize(640,464-top_bottom_crop)

super2=MSuper(source,pel=2)
backward_vec = MAnalyse(super2,blksize=16, overlap=4, isb = true, search=3 )
forward_vec = MAnalyse(super2,blksize=16, overlap=4, isb = false, search=3 )

MFlowFps(source,super2,backward_vec, forward_vec, num=30, den=1, ml=100)

[Didée]

Sorry John, but the technical part of your analysis of the problem is completely wrong.

At 'mastering' stage, nobody did try to deinterlace this video. The odd fields are not made by some horrible estimation algorithm, and the even fields share the very same issue like the odd fields.

What happened was that interlaced 720x480 was resized to 640x464 with a resizer in progressive mode. Exactly that, nothing more, nothing less.

Edit: proof:
http://img59.imageshack.us/img59/3882/interlacinghell.th.jpg (http://img59.imageshack.us/i/interlacinghell.jpg/)


Your solution is good - since it's close to impossible to (sufficiently) revert the interlace-damage, keeping just one field & discarding the other is the next best thing you can only do. But the problem analysis definetly needed to be corrected. ;)



Edit: <*deleted*> (issue purged)

[johnmeyer]

... if you post things about me in public that are not true, it should be corrected in public. I am very sorry you are offended, and I apologize.

You ask me to correct untrue things, and do so in public, so in good faith, let me attempt to do that.

First, since you did not quote the entire post from the Sony forum let me clarify something. My post in the Sony forum was VERY long, so I agree that you should not have quoted it all, but since others may not read my post in that forum, there might be a mistaken impression that I somehow went on a rant against you. So, let me state for those reading here who don't visit that forum: I did not identify you in any way in that post, and no one reading that post would know that it was you.

Second, I did not see the script you posted. I just looked at your post and see that it was edited approximately an hour and a half after the original post (the original post was at 14:55 and was last edited at 16:26). I am certain that I read your post just after it initially posted, and in fact you can see that my next post was at 15:36, which is about halfway between your initial post and your final revision.

So, I don't know if you added or edited the script after your initial post. However, I can say for certain that the script I see there now is quite complete and exactly what I was looking for. Therefore, I can understand that you would be extremely upset with me for saying that you hadn't been responsive when in fact you have now provided exactly what I was asking for.

I should mention that in one of my posts earlier in this thread I said:Thank you, thank you, thank you Didée for posting. Because I respect your opinion so much, it forced me to go back and re-do the QTGMC testing from yesterday. I think you can agree that this is not something a person would post who is trying to pick a fight with you.

Finally, I just now went to the Sony forum and I removed the sentence you quoted above from my post.

So, I have apologized, have described how the situation arose, and have removed the offending quote. I hope that settles this.

I had been working on a response to your tutorial on how improper resizing may have contributed to the bad things happening on the "KibSok_cut.avi" file, but given the circumstances, I think I'll lay low for awhile.

[nhope]

Didée & -Vit-, thanks for the info.

Can anyone tell me how to correctly change the following script to output BFF instead of TFF? (I know this isn't directly QTGMC-related but I want to compare the result of this script with some others including some QTGMC versions and some BFF versions done in other ways)

source=DirectShowSource("D:\My Videos\720x480-for-NTSC-DVD\challenge-Amendegw-AVCHD.MTS").assumetff()
IResize(source,720,480)
function IResize(clip Clip, int NewWidth, int NewHeight) {
Clip
SeparateFields()
Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
}

[sadie]

Thanks, John, for your effort of digging into the matter. I'm going to try and play with it next week when I'm off in the country. Still, I'm not entirely convinced. Even if your test sample is very low bit rate, I'm still not sure it only sort of resembles what I get using SelectEven settings with qtgmc. And i respectfully disagree that the odd fields are remarkably different from the even ones. The problem seems to be that they are just consecutively disordered. I should have uploaded a sample of my test using the simple avs:

DirectShowSource ("E:\KibSok.avi")
QTGMC (preset="fast")
Lanczosresize (720,576)
convertfps(50)

So here, it's true, the warping is more finely accentuated in the major moving parts of my sample than with yours, but so is the detail in the unaffected more 'static' parts. And the latter comprise roughly 2/3 of the video. So I suppose it all boils down to a global psycho-visual appreciation of the subject matter. In fact if I just closed my eyes once every three seconds I'd have no problems at all :rolleyes: But, I'll give your script an honest whirl.

More importantly, I want to know how come you guys don't seem knocked off your feet by the gal in this video.

[Gavino]

Can anyone tell me how to correctly change the following script to output BFF instead of TFF?
source=DirectShowSource("D:\My Videos\720x480-for-NTSC-DVD\challenge-Amendegw-AVCHD.MTS").assumetff()
IResize(source,720,480)

The simple answer would be to change 'assumetff' to 'assumebff'.
Since it works by resizing the individual fields directly, the IResize function preserves the field order of the input clip, so if you feed it BFF in, you will get BFF out.

However, that won't help if the input really is TFF and you want to change it to BFF. In that case you would need to reverse the field dominance before calling IResize. Various methods exist for doing this (eg stickboy (http://avisynth.org/stickboy/)'s JDL_ReverseFieldDominance), but a quick and dirty way (which loses the very first field) is
SeparateFields.Trim(1,0).Weave()

[nhope]

Thanks Gavino.

Going back to Didée's script to deal with that horror clip, I can see that the idea is to get a reasonable bobbed, 60p, full res clip and then do some fancy stuff to it, including bicubically downsizing it sequentially in stages and running QTGMC over it. Here's the resizing/filtering stage again:

bicubicresize(1440,960)
bicubicresize(720,960,-.8,.6)

p1 = bicubicresize(720,480,-.8,.6)

p2 = p1.QTGMC( "Slower", TR0=1,TR1=1,TR2=2, InputType=1 )

p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)

i1 = assumetff().separatefields().selectevery(4,0,3).weave()

# p1 # straight to 60p
# p2 # plus more calmed
i1 # re-interlaced p2

return(last)

I'm embarking on a round of tests for downscaling AVCHD/HDV to 720x480i for widescreen DVD. I have a minute of footage that includes that moiré-inducing horror clip but also more normal footage such as the HDV that can be seen on my YouTube channel (http://www.youtube.com/user/bubblevision). My list of tests at the moment:

1. Resizing in Vegas Pro
2. IResize "pure" script
3. QTGMC bob / Lanczos3 / no filtering > reinterlace
4. Simple bob > Didéeesque resize/filtering > reinterlace
5. Better bob (Yadif or TDeint) > Didéeesque resize/filtering > reinterlace
6. QTGMC bob > Didéeesque resize/filtering > reinterlace (=slow/ott)

Each will be encoded to MPEG-2 in CCE Basic.

It seems to me that there's a lot of filtering in Didée's script that may be excessive for most footage. Would anyone care to propose a "toned down" version that is more suitable for generic footage? Perhaps something between test 3 and tests 4/5/6? Resize in fewer stages perhaps? Use a faster preset for QTGMC perhaps? Or should I just go with it as is?

[johnmeyer]

Can anyone tell me how to correctly change the following script to output BFF instead of TFF? Just use ComplementParity() before the Weave or SwapFields() after. I think you get the same result either way. I tested, using your script, and it works.

[Gavino]

Just use ComplementParity() before the Weave or SwapFields() after. I think you get the same result either way. I tested, using your script, and it works.
That depends on what you're trying to achieve - cf my post above.

Yes, it will change TFF to BFF, but the resulting fields will have incorrect spatial alignment (if they were initially correct).

[johnmeyer]

Yes, it will change TFF to BFF, but the resulting fields will have incorrect spatial alignment (if they were initially correct).Are you saying that I'll get two top fields in a row and then two bottom fields?

I added an assumebff().separatefields() temporarily to the end of the script, and the temporal order was definitely correct (the initial video was tff), and I thought I saw the usual up/down movement between fields, but I guess I wasn't looking closely. I'll go back and look again.

The only issue I was aware of when changing parity is that you can lose the first and/or last field in the video. But, I'm still learning ...

[sadie]

John, before running off tonight I did finally manage to do a couple of encodes with your script and it pretty much confirms that it's at best a toss-up compared with my qtgmc approach. I incorporated your crop formula to good effect. There is a slight problem though in that your formula gives me an aspect ratio that is noticeably squished horizontally. I adjusted your script for PAL usage (num=25). Perhaps something went askew there. Anyway, thanks for the old college try.

On a quite separate note regarding your 'apology' to Didee, inasmuch as the offended party has re-edited his post for the second time and removed the accusation, maybe you ought to remove your apology as well. As it stands, it actually makes you out to look like the good guy:). To be more pointed, your altercation was another example of what unfortunately can happen when people abuse the prerogative to edit their own posts. I can't tell you how many times I've been thrown into a loop when people pulled such stunts with me. IMO an edit should be limited to the odd misspelling or rephrasal or such. But otherwise posts ought to remain in the spirit of what a forum really is supposed to be about: an honest running conversation between two or more parties. And if this means living with errors, omissions and delayed follow-ups so be it. I mean how often to do you go back and reread what what was posted an hour or day ago just to be sure there haven't been any 'updates'? And although it may have had the best intentions, Didee's edit should instead have been a separate follow-up. But as it stood, it made you appear not only to be presumptuous (which you were) but also a liar. I hope he at least sent you a humble little PM owning up to this. In fact his now excised 'accusation' (which by the way broke forum rule No. 9 big time) shouldn't even have appeared in this thread as it concerned a matter in a third-party forum. It should have been handled entirely by PM (or on the Sony site).

With that out of the way, I wish one and all a happy Easter week. Cheers.

[Gavino]

I added an assumebff().separatefields() temporarily to the end of the script, and the temporal order was definitely correct (the initial video was tff), and I thought I saw the usual up/down movement between fields, but I guess I wasn't looking closely.
The temporal order is correct, but top field pixels have become bottom field ones and vice versa, so will be displayed in the wrong place in the frame. Look at a still sequence and you will see immediately.

[johnmeyer]

The temporal order is correct, but top field pixels have become bottom field ones and vice versa, so will be displayed in the wrong place in the frame.I'll have to look at that when I get back to my main computer. I haven't actually used the script fragment I wrote above: I simply read the AVISynth doc, copied the code, and did a quick test which revealed that the temporal order was correct. I didn't see the spatial reversal. If that is happening, then Complementparity is of no use in this situation. I wonder when I would use it ...

In looking at scripts I wrote in the past, when I ended up having to reverse fields one time a few years ago, I wrote the code below, so I must have tried the simpler approach and realized it didn't work. I thought I was solving a tougher problem back then, but I guess it was this same thing.

source=AssumeBFF()

even=source.trim(1,0).separatefields().selecteven
odd=source.separatefields().selectodd
interleave(odd,even)
fixed=weave()

#In the line below, use the OPPOSITE of what you chose above
#because the fields have now been reversed.

AssumeTFF(fixed)

[Gavino]

In looking at scripts I wrote in the past, when I ended up having to reverse fields one time a few years ago, I wrote the code below, so I must have tried the simpler approach and realized it didn't work. I thought I was solving a tougher problem back then, but I guess it was this same thing.
It's even simpler than you think.
That entire code can be replaced by
SeparateFields().Trim(1,0).Weave()
which is what I suggested in post #614 above.

This works to reverse field dominance no matter whether you start with TFF or BFF.

[johnmeyer]

On a quite separate note regarding your 'apology' to Didee, inasmuch as the offended party has re-edited his post for the second time and removed the accusation, maybe you ought to remove your apology as well. I am a little shy about further editing my post unless Dideé or the forum admin requests it. As you state above, edits should usually be limited to spelling mistakes and similar things. However, if the forum moderator contacts me by PM, or if Dideé does the same, and if either asks me to edit the post, I will certainly do so. I have never intended to do anything except help people and do so in a way that is neither threatening, belittling, or difficult. Hopefully my collective posts in various forums back that up.

You mention forum rules, and one of the rules is to not have a discussion about the rules, so I think I will leave it at that. This matter is finished, and I suggest that none of us post further about it.

[johnmeyer]

SeparateFields().Trim(1,0).Weave()
Got it!

[boondoggle]

I tried out the example settings from the manual "QTGMC( Preset="Slower", NoiseProcess=1, NoiseRestore=0.0, Denoiser="dfttest", DenoiseMC=true, NoiseTR=2, Sigma=4.0 )" (the manual still says "NoiseBypass" instead of the new name "NoiseProcess" btw) but an error with "no function named "dfttest"" occurs. It doesn't seem to be gone in the script though? :confused:

[-Vit-]

Get the plugins package from the OP, or download dfttest directly from the link at the bottom of the OP. Also make sure you get the fftw3 library (again see the OP).

I suggest you use EZDenoise and NoisePreset as described in the manual rather than that more manual setup. Together they will create similar settings to yours and suffice for many straightforward denoising requirements. Someone else pointed out the error in the manual too - I've already updated it for the next version.

[Asterra]

I got a pretty basic question that probably has a pretty easy answer.

Following the guide in the OP, and using Avisynth 2.6 MT from SEt, I get this:

script error: there is no function named "SetMTMode"

This function is supposedly part of mt.dll, which does not come with 2.6. Lacking options, I snagged mt.dll from an earlier version but, unsurprisingly, that fixes nothing.

Not sure what step I missed (or is missing).

[SubJunk]

This isn't the right thread for that question, but the answer is you need to replace the avisynth.dll file with another one. You can fix the problem by following Step 1 of this guide (http://www.spirton.com/convert-videos-to-60fps/#Instructions), and hopefully a moderator will put our 2 posts into a new or relevant thread

[pachti]

hello,
sorry for my poor english, i try to do best i can do to be the most readable...

i try tonight to use QTGMC but i can't load my video in megui or vdub
megui close trying open the video in preview
vdub can load 2 frame then tell: "CAVIStreamSynth: system exception - -access violation at 0x10012380, reading from 0x580"

that's my best try to load... before i got many error about removegrain in line 394...

my script is:
FFVideoSource("D:\video.mkv")
QTGMC( Preset="Faster" )
SelectEven()
crop( 24, 148, -18, -138)
LanczosResize(1296,544)


thx

edit
well i think i got a bug with ffvideosource...
i try with DirectShowSource then it works!!
i didn't search enough before posting.... (since this mornig...:( )

edit2:
~4fps encoding in x264 bd5 profile... not so fast...
did i got another bug?
i have a i3... under seven64

[-Vit-]

Use an MT version of avisynth, then you can do something like this:

SetMemoryMax(400) # ...or 300 or 700 or whatever works without crashing
SetMTMode(5,6) # ...or (5,4) or (5,8) or whatever goes fast without crashing

XXXSource("D:\video.mkv") # Whatever source filter works for you
SetMTMode(2)

crop( 24, 148, -18, -138) # May need to tweak crop values to keep QTGMC happy
LanczosResize(1296,Height()) # Horizontal resize before QTGMC is faster (***as long as you are starting > 1296. I assume it is 1920 content?)

QTGMC( Preset="Faster" ) # Or "Very Fast" or "Super Fast" for HD content...

LanczosResize(1296,544)

SelectEven()
Distributor() # Use this line for MeGUI, remove this line for VDub

[pachti]

thx for your help
i tried avisynth mt but i never could load my video. neither directshowsource or ffvideosource
each time, megui close or i got " any fonction setMTmode exist" (message in french, i translate it ;) )

i will try this filtre later because I do not stay on a failure and i don't have time for the moment....
i'll be back ;)

PS my source is a french hdtv rip 1440x1080i
i miss my 1st resize it was 1080x544 no 1296...
the crop need 2more hight for qtgmc

[-Vit-]

The error "Function SetMTMode doesn't exist" suggests that you don't have MT avisynth. Go to the first post (http://forum.doom9.org/showthread.php?t=156028) - you will find some Avisynth MT links under "Multi-Threaded Usage".

About the crops and resizes - do whatever your source needs - just do not resize vertically before QTGMC, and keep the height a multiple of 4 (for YV12).

[matfra]

Hello,
Would it be possible to integrate SeeSaw script into QTGMC? I dont like the sharpening function into QTGMC. It give a greenish look to the video. I tried adding SeeSaw() after the QTGMC but it look too strong.

[-Vit-]

The "Sharpness" setting in (Q)TGMC is not a good substitute for a stand-alone sharpener. It's relatively simple and gives a little more attention to the vertical sharpness (as that's where the interpolation occurs in deinterlacing).

There might be some logic to adding more sharpening flexibility to QTGMC, given that it has to resharpen anyway. But it wouldn't have any more features/quality than a specialist sharpening script. In any case I'm not focused on QTGMC development at the moment and I will have other priorities when I return to it.

Try setting a lower sharpness value in QTGMC, say 0.4, and allow your post-script to do more of the sharpening. Or if you have the time & processor power, then setting SourceMatch=2 will allow you to almost switch off QTGMC resharpening (say Sharpness=0.1). The result will be very close to the source, which might allow you to do a better job with a standalone sharpener afterwards. Not appropriate for HD, too slow.

[ttatcs]

Thanks for this beautiful script ! Such amazing magic when I showed the result to others .

One thing I can not figure out :
I have read and followed the instructions the manual says but still can not use yuy2 video as source . Is there special match to achive this ? I mean avisynth version , mt avisynth , masktool ?
What is the must to make yuy2 video as the source ?

again , Thanks for your work!

[matfra]

In any case I'm not focused on QTGMC development at the moment and I will have other priorities when I return to it.

I hope you gonna return to it soon master :)

[-Vit-]

I have read and followed the instructions the manual says but still can not use yuy2 video as source . Is there special match to achive this ? I mean avisynth version , mt avisynth , masktool ?
What is the must to make yuy2 video as the source ?
What is the error that occurs when you try to use YUY2 as a source?

yup has reported that YUY2 doesn't work with 2.6 versions of avisynth - I haven't confirmed that but it sounds plausible. For similar reasons you should use mt_masktools-25.dll not mt_masktools-26.dll

[yup]

ttatcs and -Vit-!
Now for me YUY2 colorspace work. SEt 2.6 build, mt_masktool 25 not 26. Kasandro plugins only with SSE2 support.
Example
Import("QTGMC-3.31.avsi")
SetMTMode(2,2)
DirectShowSource("cap1.avi")# YUY2 source
SetMTMode(2,2)
AssumeTFF()
ConvertToYUY2(interlaced=true)
Crop(16,12,-16,-12)
ColorYUV(autogain=true, autowhite=true)
QTGMC(Preset="Placebo",ChromaNoise=true)
Real working script for 50 minutes video.
yup.

[nhope]

...Kasandro plugins only with SSE2 support.
Which plugins do you mean exactly?

[ttatcs]

What is the error that occurs when you try to use YUY2 as a source?

yup has reported that YUY2 doesn't work with 2.6 versions of avisynth - I haven't confirmed that but it sounds plausible. For similar reasons you should use mt_masktools-25.dll not mt_masktools-26.dll

my script:
Avisynth 2.5.8 tsp MT version

---------------------------------
SetMemoryMax(600)
SetMTMode(5, 6)
AviSource("c:\temp\jj.avi" ,audio=false ) # lagarith lossless yuy2 video
#Converttoyv12()
AssumeTFF()
SetMTMode(2)
QTGMC( Preset="Very Slow", EdiThreads=3)
------------------------------------------

load to virtualdub 1.9.11
error :
"Avisynth open failure: mt-makediff : unsupported colorspace. masktool only support planar yuv color space(yv12, yv16, yv24) "

when I add "converttoyv12()" then everything ok .

[-Vit-]

Is there a line number with that error message?

Edit: I've tested a Lagarith YUY2 interlaced AVI and it was fine. So...
- That is mt_masktools25.dll you are using?
- You don't have both masktools25 and masktools26 in your plugins do you?
- Could you upload a small piece of that source...

[Didée]

Is it definite that Lagarith is decoding to YUY2? Perhaps it decodes to RGB ...

---------------------------------
SetMemoryMax(600)
SetMTMode(5, 6)
AviSource("c:\temp\jj.avi" ,audio=false ) # lagarith lossless yuy2 video
return( info() )
#Converttoyv12()
AssumeTFF()
SetMTMode(2)
QTGMC( Preset="Very Slow", EdiThreads=3)
------------------------------------------

[yup]

@ttatcs
Please list for avisynth/pugin directory. May be problem with masktools 26?
yup.

[Gavino]

Now for me YUY2 colorspace work. SEt 2.6 build, mt_masktool 25 not 26. Kasandro plugins only with SSE2 support.
Are you saying that mt_masktools-25.dll works with SEt's 2.6 build and mt_masktools-26.dll does not? That seems contradictory to previous understanding.

[yup]

@Gavino.
Before using YUY2 colorspace inside QTGMC no problem I can use both version 26 and 25, but after transfer to YUY2 properly work only 25 version.
yup.

[yup]

@ttatcs
I am using following version
31.12.2010 18:13 966144 mt_masktools-25.dll
24.10.2007 10:41 33280 RemoveGrainSSE2.dll
24.10.2007 10:41 24576 RepairSSE2.dll
11.04.2005 12:16 30720 SSE2Tools.dll
28.02.2008 08:03 11776 VerticalCleanerSSE2.dll

@Gavino when I only replacing to 26 version masktools I get error message
---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
mt_makediff : unsupported colorspace. masktools only support planar YUV colorspaces (YV12, YV16, YV24)
(QTGMC-3.31.avsi, line 775)
(QTGMC-3.31.avsi, line 387)
(E:\Video\Mother\new\2002\deint2002.avs, line 9)
---------------------------
ОК
---------------------------

yup.

[ttatcs]

Is there a line number with that error message?

Edit: I've tested a Lagarith YUY2 interlaced AVI and it was fine. So...
- That is mt_masktools25.dll you are using?
- You don't have both masktools25 and masktools26 in your plugins do you?
- Could you upload a small piece of that source...

Thanks Vit , Yup and Didée . Your suggestions are priceless .
I kept both "mt_masktools-25.dll" and "mt_masktools-26.dll
" in the plugin directory .

After I put "mt_masktools-26.dll" out of that directory then the error was gone.

Really appreciate your work .

[Dogway]

Im getting heavy ghosting using QTGMC for deshimmer in an IVTC'ed anime source.
I use this line, is this normal?
QTGMC(Preset="Slower", InputType=1,sharpness=0.0)

[SubJunk]

Try different values for InputType (0-3)

[-Vit-]

Although I know a number of people use it with success, QTGMC is not really designed for anime. QTGMC relies on identifying the motion from frame to frame. With a film source the frame rate is fairly high and movements between frames are usually small; the detail of film means good matches can often be found. Anime will run at a lower rate, may contain duplicate frames, have stylized/artificial movement, and be hard to track if there is a lack of fine detail. So motion matches on anime can be poor, which will lead to ghosting on the temporal steps of the algorithm (and possible blurring / halo strengthening). The same problems can apply to game captures to a lesser extent.

Tweaking parameters might help a little [for example, reduce the temporal radiuses - QTGMC( "Slower", TR0=1,TR1=1,TR2=0) ], but if you're getting heavy ghosting then it may simply be that QTGMC is not going to work for this task.

[nhope]

For anyone who is interested, I did some 1080-60i to 480i DVD test renders and converted them to a ready-to-burn DVD project for comparison. One of them uses the "IResize" script referred to a couple of pages back, and another includes a QTGMC pass as suggested by Didée. See here (http://forum.doom9.org/showthread.php?t=160950).