QTGMC Deinterlacing Script (v3.32)

[Mini-Me]

I'm trying my script again right now with MT i'm not sure why VIt called the best settings "lossless" because it's not lossless for me , take a look:

Original:
http://img195.imageshack.us/img195/5138/originalrn.jpg
QTGMC:
http://img802.imageshack.us/img802/8199/qtgmc.jpg

settings used:
MT("""QTGMC( "Slower", EdiThreads=1, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )""", threads=2,overlap=16)

As -Vit- and Didee said, a sample would be helpful to see what's going on here. I'm not even sure what kind of image comparison I'm looking at; it could be any one of these four:
Woven frame and final frame: Assuming this is a pure interlaced source and QTGMC is being used correctly, there's a problem here. I don't think this is the case though.
Bobbed field and final frame: If this is the case, it would be helpful to see the neighboring bobbed fields from the source too (or better yet, the source clip).
Original separated field and supposedly (but obviously not) lossless counterpart from the final frame: Assuming this is a pure interlaced source and QTGMC is being used correctly, the last smoothing is doing more damage than I'd expect.
Original separated field and generated pair from the final frame: This kind of comparison wouldn't really make any sense; it would be better to see the whole final frame.

A thought just came to me though: The temporal smooths in QTGMC might GREATLY benefit from "gamma-corrected" smoothing, when it comes to thin horizontal details. See here (http://forum.doom9.org/showthread.php?t=160038) to get an idea of what I'm talking about. The basic idea is that at ordinary gammas, any kind of smoothing or averaging ends up reducing the overall luminosity of areas (the softened grill of the car has been darkened excessively). To correct for this, you would reduce the gamma, perform your operations, and increase the gamma again.

As a quick test to see if it might help, you could try sandwiching your QTGMC call between with two calls to levels or LaTo's Smoothlevels (the first reducing gamma and the second increasing it again). The optimal solution requires 10+ bit processing in Avisynth, but if the Smoothlevels solution makes the picture look better in the meantime, why not? :) If time is no object, you could even repair very subtle detail (least significant bits) lost in the gamma shifts by doing the following:
Run QTGMC normally and save the result as A.
Reduce source gamma, run QTGMC on darkened source, and increase the gamma of the result, and save the result as B.
Run some kind of repair filter that replaces pixels from B with pixels from A if they're in the same brightness neighborhood (within 1 or 2 luma or so). I could probably think of some hacky way to do this off the top of my head, but I don't want to embarrass myself in the presence of my betters. ;)

[Didée]

Regarding 'gamma correction' -- generally a good idea. But a simple un-gamma before QTGMC + re-gamma afterwards probably is no good idea. Besides of the 8bit problem, I assume that MVTools' motion search will not react very gracefully if ME is performed on a clip with linear gamma. If at all, then the motion search should be done on the normal input, and the gamma operations be done only in the parallel processing path ('super' clip & separate base clip for rendering).

[Mini-Me]

Regarding 'gamma correction' -- generally a good idea. But a simple un-gamma before QTGMC + re-gamma afterwards probably is no good idea. Besides of the 8bit problem, I assume that MVTools' motion search will not react very gracefully if ME is performed on a clip with linear gamma. If at all, then the motion search should be done on the normal input, and the gamma operations be done only in the parallel processing path ('super' clip & separate base clip for rendering).

I never even thought about linear gamma making motion estimation's job harder, but by compressing the lower-mid range compared to usual, I guess it might. In that case, I may have finally found a use for supplying my own motion clip to QTGMC! ;)

Actually, by the same token, would motion search possibly be better if performed on a clip with higher-than-usual gamma?

[javlak]

Hi. According to this (http://avisynth.org/mediawiki/Removegrain), the RemoveGrainSSE3.dll bug has been fixed. What is the official QTGMC author's stance on this? Can we revert to RemoveGrainSSE3 or should we still continue to use RemoveGrainSSE2.dll?

And I do not wish to step on any toes or insult anyone, but I have downloaded pretty much every free filter/plugin from MSU. Even though Mounir talks about a payware filter, if their freeware is any measure, I can safely say that their quality cannot match anything the high-performance plugins avisynth can throw at them. The demo pictures they show on their website are nothing more than demo pictures, not real-life applications. Believe me, I've tried Boolet, FieldsKit, Topaz Enhance et al, and QTGMC leaves them far behind. Your particular case is, as others have already mentioned quite difficult for any deinterlacer.

[-Vit-]

The fixed version of RemoveGrain has some changed and undocumented functionality. It comes with no source code. So it can't be recommended. In the last version with source code there is exactly one line of difference between SSE2 and SSE3 versions. It won't make a difference.

I tend to agree regarding the MSU plugins. Whilst the guys seem to know what they're doing, the plugins they do release are not very special. Their Video Quality Measurement tool is quite handy though.

[aegisofrime]

Hi. According to this (http://avisynth.org/mediawiki/Removegrain), the RemoveGrainSSE3.dll bug has been fixed. What is the official QTGMC author's stance on this? Can we revert to RemoveGrainSSE3 or should we still continue to use RemoveGrainSSE2.dll?

And I do not wish to step on any toes or insult anyone, but I have downloaded pretty much every free filter/plugin from MSU. Even though Mounir talks about a payware filter, if their freeware is any measure, I can safely say that their quality cannot match anything the high-performance plugins avisynth can throw at them. The demo pictures they show on their website are nothing more than demo pictures, not real-life applications. Believe me, I've tried Boolet, FieldsKit, Topaz Enhance et al, and QTGMC leaves them far behind. Your particular case is, as others have already mentioned quite difficult for any deinterlacer.

Q/TGMC and x264 were the two pieces of software that woke me up to the idea that freeware can be better than payware :)

[Mounir]

You believe the marketing fairytales?
Hmm yeah i believe the hype, why don't you ?

[Overdrive80]

Update doc plugin in spanish. Link: http://www.mediafire.com/?1h1r5tf2t9t8rq1

[CruNcher]

Hmm yeah i believe the hype, why don't you ?

Hehe because without hard facts it's hard and these samples are known once schumacher and flag :) people here on doom9 are confronted with situations most test sequences shown their don't reproduce :)
And if you want to test the base of their algorithm you can do that http://www.yuvsoft.com/download/deinterlacing/index.html
And well it's Didée (nothing to add) :D

[upyzl]

First I'm new to QTGMC here...
A question maybe stupid for others but confused for me

Could QTGMC use FFT3Dgpu instead of FFT3Dfilter? How?

[-Vit-]

Could QTGMC use FFT3Dgpu instead of FFT3Dfilter? How?
I guess you could replace the single call to FFT3DFilter in the script.
I have never done so because FFT3Dgpu is unstable for me. I believe it is also unstable generally with SetMTMode, which many people use with QTGMC.

I don't think it would give a great speed up because denoising is only a small part of the processing (and not enabled by default anyway).

[smok3]

thanks!

p.s. Getting around 1.7 fps in virtual machine with non-MT version (on quad core machine).

[upyzl]

@ -Vit-

Thanks for the reply!

[The Showstopper]

Does QTGMC works on interlaced credits (30i) scrolling on top of a telecined background??

[Heaud]

It needs to be done with a script such as the one in this link (http://forum.doom9.org/showthread.php?p=1466105#post1466105).

[Lighto]

Thanks guys for the awesome script.
I am having trouble getting MT to work without crashing, would it make sense for me to run parallel non-MT instead to fully make use of my CPU?

Thanks. :)

[-Vit-]

Would it make sense for me to run parallel non-MT instead to fully make use of my CPU?
It will certainly works and can be effective sometimes - depends on the source and settings. It's not as fast as using SetMTMode - having your CPU under full load does not necessarily mean it's working efficiently.

Have you tried the various ideas from the first post? Particularly different versions of Avisynth MT and my modded plugins? Also try running MT at less than full load, that can help whilst still being faster.

____

On a related point, I recommend updating to nnedi3 0.94 (http://forum.doom9.org/showthread.php?t=147695), it gives a nice speed-up (thanks tritical!).

[kolak]

I tried new plugins, all versions of avisynth and on HD sources and my 24core machine it crashes until I limit it to <4 cores. Even this sometimes crashes- only not using mt gives stable results, but 2fps is way to slow :(

It's a bit hopeless :(
Quality is better than anything I've seen including big K$ solutions.


Andrew

[-Vit-]

Well, you can safely use a faster preset with HD material, e.g.
QTGMC( "Faster" )


Also, you should usually output to a lossless intermediate file when using QTGMC on HD. Then encode that lossless file to x264 or whatever. Otherwise Avisynth will run out of memory (it's still a 32-bit app, so limited to 2Gb).

[kolak]

Well, you can safely use a faster preset with HD material, e.g.
QTGMC( "Faster" )


Also, you should usually output to a lossless intermediate file when using QTGMC on HD. Then encode that lossless file to x264 or whatever. Otherwise Avisynth will run out of memory (it's still a 32-bit app, so limited to 2Gb).

I use one of Canopus Lossless/HQX/HQ (or uncompressed).

I have to try again 64bit, but last time I had no luck. Couldn't make it working at all :(

Andrew

[Chikuzen]

I use one of Canopus Lossless/HQX/HQ (or uncompressed).

I have to try again 64bit, but last time I had no luck. Couldn't make it working at all :(

Andrew

http://forum.doom9.org/showpost.php?p=1507717&postcount=17

[smooth_hands]

Well, you can safely use a faster preset with HD material, e.g.
QTGMC( "Faster" )


Also, you should usually output to a lossless intermediate file when using QTGMC on HD. Then encode that lossless file to x264 or whatever. Otherwise Avisynth will run out of memory (it's still a 32-bit app, so limited to 2Gb).

Vit, would you mind sharing the methods/command line calls you use for the lossless intermediate file step? By looking at the command line parameters in MeGUI, I have figured out how to use mencoder to do this, but the intermediate files it produces are massive (like 250+GB for a normal length movie if I recall). Is this unavoidable?

[-Vit-]

In MeGUI just check "Add pre-rendering job". That will first run the avisynth script to output a lossless huffyuv file, then encode that file in a second pass. The intermediate file will be around 200Gb per hour at HD. It will be deleted after processing if you have "Delete intermediate files" checked in Options.

If you don't have the temporary space:
- Don't use a pre-rendering job - reduce settings/threads so it can cope
- Use avs2yuv (or avs2pipe?) to pipe the avisynth output to a separate x264 process to do the encoding. Each process will get it's own memory space. I haven't tried this, I saw the idea here, though I'm sure others use this method for the same reasons.

[kolak]

http://forum.doom9.org/showpost.php?p=1507717&postcount=17

Yes- this is some solution, but if you have few files, than it takes a bit of additional work. If we could make some batch file, which would do all automatically, than that would be more useful:)

I'll try and check how much my PC can do and how much faster it's compared to single thread.

I have 24GB of RAM, so this should not be a problem.

Andrew

[smooth_hands]

In MeGUI just check "Add pre-rendering job". That will first run the avisynth script to output a lossless huffyuv file, then encode that file in a second pass. The intermediate file will be around 200Gb per hour at HD. It will be deleted after processing if you have "Delete intermediate files" checked in Options.

If you don't have the temporary space:
- Don't use a pre-rendering job - reduce settings/threads so it can cope
- Use avs2yuv (or avs2pipe?) to pipe the avisynth output to a separate x264 process to do the encoding. Each process will get it's own memory space. I haven't tried this, I saw the idea here, though I'm sure others use this method for the same reasons.

Thanks for the response. The MeGUI option is the same as what I was describing; I just take the same parameters and enter them at the command line. I want to not bring MeGUI into the equation because I have a batch file I use to do all my processing, and MeGUI adds a non-automated step right in the middle of the chain.

I have tried avs2yuv but it always seemed to go slower AND be less stable for me. I also tried reducing settings as per your guide but making it through anything longer than about 15-30min (real-time) of HD video is a crapshoot.

I just wanted to make sure there wasn't some alternative that was as stable as, but faster than, simply running QTGMC in non-multithreaded mode. I don't seem to ever get crashes that way, and it's quicker than doing 2 passes (lossless via mencoder->lossy via x264), but obviously significantly slower than 1 pass running QTGMC in multithreaded mode.

How much memory should one have to have a good chance of avoiding these crashes, anyway? I have 4GB (Windows 7 x64) with no other programs running besides basically bare minimum Windows processes and Microsoft Security Essentials.

I just love this filter so much for interlaced content that I want to do everything in my power to get it into my workflow whenever feasible :)

[-Vit-]

You need 2Gb spare memory for 32-bit avisynth. 4Gb and a low system load sounds OK.

The alternative posted above, splitting an encode into chunks (http://forum.doom9.org/showthread.php?p=1507717#post1507717), is the other way to get more speed whilst retaining stability. It's not the speedup of SetMTMode but it can help. However, to take best advantage you may need more memory - that approach relies on creating several processes rather than several threads. Each process can have its own 2Gb.

One other thing: mencoder was dropped from MeGUI quite a while ago, in favor of ffmpeg for lossless output. I use the dev builds, dunno if that change has made it to the stable builds yet.

[dfan]

hi
how i could make a timecodes' file correctly with tdecimate?

if i use qtgmc+selecteven+tdecimate(+ovr) then there are some zones to 24fps but that really are to 30fps (tfm+tdecimate+ovr detect them correctly ._.). Any idea for fix this?

thx

[nhope]

I've started testing the following script for PAL DV > NTSC-for-DVD conversion, as an improvement over my previous method of blending frames in Vegas Pro. Initial results are promising, although of course it's slow. I would welcome any comments or suggestions for improvement. Thanks

#Frameserve from Vegas Pro in YUY2.

AviSource("d:\fs.avi")
ColorYUV(levels="TV->PC") #Reverses frameserving levels squeeze
QTGMC()
Spline36Resize(720,480)

#Could save lossless intermediate here

super = MSuper(pel=2)
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=60000, den=1001)

AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
weave()

[johnmeyer]

Nick,

Is your source interlaced? If so, does this script give correct results?

[edit] Forget this post. I didn't see the QTGMC line.

[-Vit-]

Can use QTGMC's own motion vectors, which it exposes for later use. This will be faster and likely give better vectors. But then you must resize after the flow

#...
QTGMC( SubPel=2 ) # SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2) # Only need multiple levels for MAnalyse
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)
Spline36Resize(720,480)
#...

[Edit: If you use faster presets on QTGMC then you will need to set hpad/vpad to 16 on the MSuper line]

This process is detailed in the QTGMC docs under the heading "Accessing QTGMC Motion Vectors"

Or you could try Interframe (http://forum.doom9.org/showthread.php?t=160226) to do the 50->60fps. The script is still essentially MFlowFPS, but it has been tweaked heavily.

[nhope]

Thanks very much -Vit-. I hadn't realised that Interframe could do framerate conversions other than doubling.

So now I want to try your 2 suggestions; The MFlowFps script using QTGMC vectors and the following script using InterFrame:

#Frameserve from Vegas Pro in YUY2

AviSource("d:\fs.avi")
ColorYUV(levels="TV->PC") #Reverses frameserving levels squeeze
QTGMC()
Spline36Resize(720,480)

InterFrame(FlowPath="C:\Program Files\AviSynth 2.5\plugins\")

AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
weave()

One of the Interframe dependencies is a modified mvtools2.dll from here (http://www.svp-team.com/wiki/Download). How would you recommend managing 2 different versions of mvtools2.dll (one for QTGMC and one for InterFrame)? Or could the same version be used for both? Would I have to split the script and load plugins from different folders?

Also, RemoveGrainSSE3.dll is in the InterFrame dependencies folder, but I'm running RemoveGrainSSE2.dll with QTGMC. I guess I should go for one or the other, but which?

[-Vit-]

I skimmed the SVP modded MVTools code a while back and the changes were fairly limited in scope, so I imagine it will still work for normal use [that's just a guess though, I don't actually use it myself]. Just note it's based on 2.5.11.1. The latest version is 2.5.11.2, which fixes a crash bug that affected QTGMC with certain resolutions/blocksizes. But that shouldn't affect your use case though.

Use RemoveGrainSSE2. There was a bug in RemoveGrainSSE3 until the final version, but that one has some changed and undocumented functionality so it shouldn't be relied on. There is no noticeable difference between the two anyway.

[SubJunk]

How would you recommend managing 2 different versions of mvtools2.dll (one for QTGMC and one for InterFrame)? Or could the same version be used for both?Yeah I don't think you will have any problems using the same one for both. Most of the SVP changes have been done to a new function they created called MSmoothFPS, so MFlowBlur and MSuper (which QTGMC uses) still work as they did before AFAIK.

Also, RemoveGrainSSE3.dll is in the InterFrame dependencies folder, but I'm running RemoveGrainSSE2.dll with QTGMC. I guess I should go for one or the other, but which?The one with the highest number :D ;) But seriously it won't make much difference, you can use either one

[nhope]

Thanks -Vit- and SubJunk. I ran the InterFrame script with the original RemoveGrainSSE2.dll and mvtools2.dll supplied in -Vit-'s required plugins pack and I had no problems.

I found little difference in the quality of the result, but in my single-threaded environment the MFlowFps method was about 7-8% faster than the InterFrame method. Also InterFrame doesn't support YUY2, and I prefer not to use YV12 in this case because it gives me this chroma shift error (http://forum.doom9.org/showthread.php?t=161011) when I take interlaced YV12 into CCE Basic for MPEG-2 encoding.

So anyway, the following script gives a stunningly good PAL>NTSC conversion compared to anything I've tried before (which is A LOT of software methods). So good in fact that I think I can start just offering NTSC DVDs instead of both PAL and NTSC depending on territory (my original footage is PAL, which won't play worldwide). Thank you!

#Frameserve from Vegas Pro in YUY2

AviSource("d:\fs.avi")
ColorYUV(levels="TV->PC") #Reverses frameserving levels squeeze

QTGMC( SubPel=2 ) # SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2) # Only need multiple levels for MAnalyse
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) # For faster QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)
Spline36Resize(720,480)

AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
weave()

Just one thing. There are still jaggies in evidence such as around the diver's mask in this screengrab. I suspect they are unavoidable, but any suggestions to reduce them?

http://dl.dropbox.com/u/21489814/jaggies.jpg

[Didée]

There are still jaggies in evidence such as around the diver's mask in this screengrab. I suspect they are unavoidable, but any suggestions to reduce them?
That can't be judged from one screenshot, because you're re-interlacing. Deactivate the Separate/Select/Weave sequence, and check if there still are jaggies then.

(Though, straight from the guts, those jaggies don't really look like they're re-interlacing related, but rather like something's going seriously wrong. It pretty much looks like aliasing from a simple standard deinterlacer!)


Oh, BTW ... if the frameserved output really has a PC-->TV levels squeeze, then that's not good at all ... in particular for underwater shots. (During level squeeze information is getting lost, and you won't get that loss back by expanding again....)

[nhope]

That can't be judged from one screenshot, because you're re-interlacing. Deactivate the Separate/Select/Weave sequence, and check if there still are jaggies then.
Sorry. that screenshot was misleading. It was actually of a single field doubled in height after re-interlacing :stupid: ... I did as you suggested and the pre-re-interlaced 59.94p frames are as smooth as a baby's bottom. The jaggies/combing were showing up on my 5-year-old LG DVD player + Samsung CRT TV. Perhaps it's normal and I'm looking too hard. Or perhaps, even though they are "multi-system", they are from PAL-land and don't behave the same as a TV from NTSC-land. It's definitely no show-stopper anyway.

Oh, BTW ... if the frameserved output really has a PC-->TV levels squeeze, then that's not good at all ... in particular for underwater shots. (During level squeeze information is getting lost, and you won't get that loss back by expanding again....)
Vegas works internally in RGB. The Debugmode frameserver will serve RGB or YUY2. When frameserved out in RGB there is no levels squeeze. When the frameserver does an RGB>YUY2 conversion it uses Rec601 and so I need to expand the levels out again in AviSynth. Perhaps I'd be better serving in RGB and converting to YUY2 with matrix="PC.601" in AviSynth?

[nhope]

This is where I have ended up and I'm really happy with the results, but didn't test the NTSC>PAL script much since I don't have original SD NTSC footage.

(Note that Vegas works internally in RGB, so I'm using the path of least conversions)

PAL to NTSC

#Frameserve PAL source from Vegas in RGB24 format

AviSource("d:\fs.avi")
AssumeBFF()
ConvertToYUY2(interlaced=true, matrix="PC.601")

QTGMC( SubPel=2 ) #SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2) #Only need multiple levels for MAnalyse
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) # For very fast and quicker QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)
Spline36Resize(720,480)

SeparateFields()
SelectEvery(4,0,3)
weave()

NTSC to PAL

#Frameserve NTSC source from Vegas in RGB24 format

AviSource("d:\fs.avi")
AssumeBFF()
ConvertToYUY2(interlaced=true, matrix="PC.601")

QTGMC( SubPel=2 ) # SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2) # Only need multiple levels for MAnalyse
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) # For very fast and quicker QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=50, den=1)
Spline36Resize(720,576)

SeparateFields()
SelectEvery(4,0,3)
weave()

1080-50i to SD NTSC

#Frameserve 1080-50i source from Vegas in RGB24 format

AviSource("d:\fs.avi")
AssumeTFF()
ConvertToYUY2(interlaced=true, matrix="PC.601")

Spline36Resize(720,height)
QTGMC("faster", sharpness=0, SubPel=2) #SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2) # Only need multiple levels for MAnalyse
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) # For very fast and quicker QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)
Spline36Resize(width,480)

blur(0.0,1.0)
sharpen(0.0,0.75) #Adjust 2nd value between 0.5 and 1.0 to taste

SeparateFields()
SelectEvery(4,0,3)
Weave()

One question. For which exact QTGMC presets would hpad=16 and vpad=16 be required in these 3 cases?

[-Vit-]

One question. For which exact QTGMC presets would hpad=16 and vpad=16 be required in these 3 cases?
"Very Fast" and quicker presets for all those 3 scripts.

This v/hpad requirement is only there because QTGMC still contains a workaround for a bug in MVTools 2.5.11.1 and earlier, fixed in the latest version 2.5.11.2. I kept the workaround in case people didn't upgrade their MVTools. The next QTGMC version will drop the workaround and will use the default v/hpad in general (and will require the latest version of MVTools).

[kypec]

The next QTGMC version will drop the workaround and will use the default v/hpad in general (and will require the latest version of MVTools).
Mind to tell what new exciting improvements can we look forward to in this next version? :)

[aegisofrime]

Mind to tell what new exciting improvements can we look forward to in this next version? :)

I would like to know that as well. :)

Still, if the next version of QTGMC requires the latest MVTools, I do hope somebody can compile a 64-bit version of that. 64-bit has consistently been more stable and faster than 32-bit for me, although the newest version of NNEDI3 has somewhat closed the gap considerably.

Also, on a slightly OT note, if somebody can post a guide on how we can do our own 64-bit compilations that would be great.

[Dogway]

I observed chroma smears too much. In a similar way mdegrain does when plane=4 with high SAD. Can I disable chroma in some way?

edit: it was MY BAD, cropping before QTGMC, just to save a few 0.xx fps

[-Vit-]

Mind to tell what new exciting improvements can we look forward to in this next version? :)

I didn't mean to suggest a new version was imminent. I have been very busy on a different project, but that has reached a stable point now, so I will be turning my attention back to QTGMC soon.

I have been working on a number of additions. In no particular order:
- Various motion vector tweaks for speed up or quality improvements: use of vectors derived from downsized clip (faster for HD); refinement of vectors through MRecalculate and a new plugin of mine; some vector mask trickery to help with areas of bad match
- Change output frame rate, i.e. use MFlowFPS with the refined vectors noted above. Allows 50i->60p or 60i->50p or whatever.
- Resizing of output, including an attempt to find extra detail from neighbors for upscales.
- Some denoising improvements (related to the above)
- Standalone functions (no deinterlacing): QDenoise, QMotionBlur, QVectors
- Some defaults automatically adjust based on input resolution
- Bug fixes (as ever)...

Most of these are still in progress and I dunno in what order they will appear. Also now would be a good time for requests.
____

...the latest MVTools...
QTGMC will still work with MVTools 2.5.11.1. It's just that version's MCompensate is unstable when there is edge motion on certain resolutions. Doesn't affect most typically used resolutions at all, so it may not affect you.

____

I observed chroma smears too much. In a similar way mdegrain does when plane=4 with high SAD. Can I disable chroma in some way?

src = whatever
luma = src.QTGMC()
chroma = src.YourFavoriteChromaDeinterlacer()
MergeChroma(luma, chroma)

Can't switch off chroma processing entirely in QTGMC, but can speed it up by setting RepChroma=false and ChromaEdi="Bob"

[nhope]

Also now would be a good time for requests.

Well, if you are going to build in options for frame-rate changes (which I think is a great idea), maybe you could build in options for rescaling? Under the covers it would do something like a width-before/height-after Spline36Resize. Or maybe there is other stuff you can do in the script to optimize rescaling quality.

[nhope]

Further to that you could put in shortcut options to effectively make it a format-converter. e.g. "PAL2NTSC", "NTSC2PAL"

[nhope]

Also re-interlacing of double-rate video with choice of field dominance handled as options. e.g. reint="TFF", reint="BFF".

[-Vit-]

Lol, anything else?

PAL<->NTSC:
- I already mentioned that rescaling will be added. My primary interest is high quality upscaling, rather than rescaling for PAL<->NTSC conversion, but I guess any rescaling will be supported.
- Frame-rate change (flow) has always been an obvious add-on since QTGMC already calculates motion vectors (also slow-mo / speeded-up output).
- Reinterlacing is the step that gets no benefit from being inside the QTGMC script, but I guess I'll add it for convenience. I'll provide some alternative approaches.

So although it wasn't explicitly my intent, I expect a future QTGMC to be able to do PAL<->NTSC conversions, and yes I'll make some easy settings for it. It will do InterFrame-like work too. Both these will probably support progressive or interlaced input or output.

Don't ask about ETA though, as I said my main interest is some upscaling experiments, which are only tangentially related to QTGMC. Conversion support will just be a beneficial side effect.

[Robert Martens]

Well, if you are going to build in options for frame-rate changes (which I think is a great idea), maybe you could build in options for rescaling? Under the covers it would do something like a width-before/height-after Spline36Resize. Or maybe there is other stuff you can do in the script to optimize rescaling quality.

Also re-interlacing of double-rate video with choice of field dominance handled as options. e.g. reint="TFF", reint="BFF".

You may have some fun playing with this thing (http://forum.doom9.org/showthread.php?t=153860), a script I've been revising since early last year. No framerate conversions, as I don't feel confident in my ability to do that well, but the width-before/height-after rescaling is already present (for interlaced input that's being downscaled; there's no sense resizing horizontally before deinterlacing if you're upscaling), as is re-interlacing with choice of field order. There's a variety of presets that should make usage a bit easier, taking proper pixel aspect into account to crop the input as necessary for different shaped output, pillar/letter/windowboxing, and some other features that may prove useful for some applications.

Mind you, with no background in math, signal processing, computer science, or any related field (and insufficient intellect to pick up the subjects in less than a lifetime), I've long since reached my limit with regard to quality improvements, so I certainly look forward to whatever Vit cooks up for rescaling.

[nhope]

@-Vit- & Robert Martens - Thanks a lot. I have a ton of interlaced 4:3 PAL DV to upscale to 960x720-25p for YouTube. Was going to just use QTGMC + Lanczos4 on it but I'll check out SimpleSlugUpscale and eagerly await QTGMC upscaling developments. If you want any PAL DV test footage, just say so.

[Yellow_]

If now is a good time for feature requests would there be any benefit in considering gamma aware resizing and 16bit msb/lsb stacked?

[-Vit-]

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.
16-bit stacked does interest me and is similar in some ways to what I am looking at for resizing. I will look into it, but I expect speed / script complexity problems.