ResizersPack,MasksPack,PlaygroundPack, SmoothContrast, Logo & mod functions

[Dogway]

Sorry, I didn't realize, I only read the restoration subforum here on videohelp.
It looks you got it all sorted out by the looks of it.

About the thread script functions, I'm developing new tools for old film based sources. Specially to deal with film gate and deshaking but most likely will go into a new thread.

[LouieChuckyMerry]

Sorry, I didn't realize, I only read the restoration subforum here on videohelp.
It looks you got it all sorted out by the looks of it.

Things are going really well. I've already encoded almost 30 episodes and, after several days of testing and the help of other kind people here, I'm now able to run (a very slightly modified version of) your script in AviSynth 2.6 MT, achieving ~2.65 FPS on my dual-core setup. That's three episodes every night while I sleep, way more production than I'd ever hoped for given the output quality. Anyway, thanks again for all your help .

About the thread script functions, I'm developing new tools for old film based sources. Specially to deal with film gate and deshaking but most likely will go into a new thread.

Would these new tools be useful for older movies with varying film stock, like from the 30's, 40's, 50's, 60's, etc., when they'd use different exposures for different lighting? I ask because I'm working through my collection in reverse chronological order and as I enter the 80's & 70's (and probably getting worse as I go) it seems like the noise in my sources is much less "even", if that makes sense. For example, scenes filmed at night are much noisier than scenes filmed in daylight.

[Dogway]

-Updated Resizers Pack to v4.0 with new functions PadMirror() and Dither_addborders8().
-Updated Resizers Pack to v4.1 for making PadResize() modulo compliant.
-Updated Resizers Pack to v4.2 reworked default colors for Dither_addborders8()
-Updated MasksPack to v2.2, changed completely BoxMask() to a faster approach.
-Updated MasksPack to v2.3, removed masktools dependency for boxmask()
-Updated SmoothContrast to v.3.0. Parameters weren't in line with the last SmoothAdjust changes.

LouieChuckyMerry: Well for old I meant up to the 80's, I never dealt with older ones. The new functions are here. Mainly for film gate and fixing black borders as a result of stab(). It's a bit advanced stuff but can surely come handy later on.

[LouieChuckyMerry]

Thanks for the updates . And the 80's aren't old...

[hello_hello]

Hi Dogway,
I thought I'd point you to my post here in case you're interested. It's regarding an odd encoding speed problem when using your modded version of QTGMC in a script with LSFMod. I say odd, because I appear to have found some video where the issue always occurs, but only when re-encoding the video from the beginning. If you happen to be interested in looking at it, let me know and I'll upload a sample.

[Dogway]

QTGMC+x264 sounds like a horrible idea.
If you are going to use heavy scripts I recommend you to encode lossless then h.264. It's usually faster too.

I didn't do anything out of the norm, just enabled higher precision for dfttest and mdegrain, very safe modifications. Probably you are running out of memory or buffer is not big enough. Another option is to use mp_pipeline.

Make a test to lossless and if failed upload a sample.

[hello_hello]

The lossless test failed.

I use x264 for encoding with QTGMC in the script pretty regularly without issue (I use it in progressive mode for noise filtering quite a bit as I've been doing in this case), although mostly for 720p or lower resolution. I find that because it doesn't push the CPU very hard (single threaded mode) the rest of the CPU time might as well be spent doing the encoding. It's just every now and then it slows down for some reason and I happen to have found a sample where the problem's quite repeatable, so I thought I'd mention it. Maybe it's just "one of those things"..........

Anyway, I tried again with a dual core PC running XP (the quadcore is busy at the moment) and while over-all speed is a little slower, the result is the same. If I encode the attached sample with the attached script using QTGMC 3.33 I get (according to MeGUI's log file) an average of 3.34fps. Using QTGMC 3.33d I get 1.7fps. If however, I put Trim(50,0) at the end of the script, the speed using QTGMC 3.33d increases to 3.28fps. The small difference between that speed and using QTGMC 3.33 is probably due to the sample being small and the encoding speed not getting as much chance to "ramp up" so to speak, but there's just something odd happening that's being caused by encoding the video from the very beginning (and it seems only when QTGMC 3.33d is used in combination with LSFMod).

Also it seems the bitrate for a given CRF value (I've been using CRF18 + Tune Film + Slow speed preset) tends to be a little higher using QTGMC 3.33.

Encoding lossless the result is the same. QTGMC 3.33d + LSFMod is slower than QTGMC 3.33 + LSFMod if you encode the sample from the beginning. The former drops to around 1.78fps by the end using this old PC. For QTGMC 3.33 + LSFMod it's doing about 3.66fps.

Attached is a small sample of the video along with the scripts I'm using (just in case I'm missing something obvious there). As I said, maybe it'll be just one of those things that's not worth fussing about, but maybe you'll find something.

Cheers.

Edit: A bit more info. For whatever reason, the above problem only seems to occur when running QTGMC in progressive mode as I was with the attached script. I tried again with QTGMC in de-interlacing mode (same video) ie

QTGMC(Preset="medium", EzDenoise=1)
SelectEven()

and QTGMC 3.33 and QTGMC 3.33d seem to run at about the same speed (with LSFMod in the script), although 3.33 still seems to result in a slightly higher bitrate. Odd......

[Dogway]

The reason adding a trim works could depict a buffer issue as I said. The loader caches previous frames and you get some headroom. I don't think this is something to be surprised, QTGMC+LSFMod+X264 on a HD source in an old dual core CPU, it's calling for problems.

v3.33d requires a bit more memory than the original due to the extra precision and frame size,
low CPU usage when filtering is a symptom that something is wrong, it means the script is bottlenecked so adding x264 is not going to fix things.

I recommend alternatives. When using QTGMC I always used a single script with only QTGMC encode to lossless. You can try with Didée's suggestion changefps(last,last,true) after the loader for caching, requestlinear(), or as I said and recommend mp_pipeline().

[themaster1]

Trying for the first time SatMask and i get an error "don't know what sat is"...fantastic. Working with dither-1.9 & masktools 2.0a48

[Dogway]

How are you calling it?

[themaster1]

satmask(sat) as advised in the avsi script

[Dogway]

you have to define "sat". Use like this, you can swap SmoothTweak() with tweak() if you want.

sat=SmoothTweak(saturation=1.5)
satmask(sat)

[hello_hello]

The reason adding a trim works could depict a buffer issue as I said. The loader caches previous frames and you get some headroom. I don't think this is something to be surprised, QTGMC+LSFMod+X264 on a HD source in an old dual core CPU, it's calling for problems.

Well I'll confess I'm not sure I understand the "old dual core" logic. Snazzy new 8 core or old dual core doesn't change the amount of RAM available does it? I think by switching to the old dual core for further testing I at least proved it's not CPU related.

QTGMC+LSFMod+x264 on a HD source is the sort of thing I do regularly. It's only recently I've bumped into this problem, although admittedly it's only recently I've started using LSFMod regularly.

Unfortunately, QTGMC+LSFMod+huffyuv doesn't change anything, so taking x264 out of the equation makes no difference. Nor it seems, does reducing the resolution of the source video. It just makes the effect less noticeable. I tried again (same script) except this time the source was 720x400. I let it run until x264 was encoding frame 1000, at which point I was encoding at 7.25fps, according to MeGUI. Then I switched to QTGMC 3.33d and tried again. Encoding speed peaked at 6fps by around frame 400 and by frame 1000 it was down to 5.06fps.

So chances are this is a problem I've been experiencing more than I realised, but I hadn't noticed until I started encoding a bunch of 720p video and it became more obvious.

v3.33d requires a bit more memory than the original due to the extra precision and frame size,
low CPU usage when filtering is a symptom that something is wrong, it means the script is bottlenecked so adding x264 is not going to fix things.

x264 doesn't fix things, it just makes use of an otherwise not so busy CPU. Unfortunately, encoding to lossless doesn't fix the problem, so I still think there's something "odd" happening that shouldn't be. It also seems odd to me the problem only occurs when running QTGMC in progressive mode. I'll experiment a bit more and report back if I make any startling discoveries.

[Dogway]

It doesn't matter whether you got 64Gb of RAM, avisynth can only use a maximum of 2Gb (probably not even that). You are using higher precision filtering with "hack" code so to speak, using msb and lsb approach, in other words doubling the frame size (buffer fills faster). In SD this hasn't a great impact but for HD it has.

x264 can use the rest of 62Gb of free RAM but it doesn't change the fact that avisynth is bottlenecked idling as it waits the frame buffer to flush before going the next frame. By using mp_pipeline you divide buffers in different chunks overcoming the 2Gb limit allowing the thread chain to go smoother. My knowledge on this is limited so read more on the mp_pipeline thread in Doom9. Other people choose to encode in parallel, or in several passes using intermediaries.

My only concern with your issue is you are not even using lsb (they default to false) so the only mod being executed is the custom inflate/deflate functions. I reverted the QTGMC_deflate/QTGMC_inflate with plain masktools mt_deflate/mt_inflate (as the #comments even suggested). Unless they are slower than the QTGMC_ hack I can't think of any other reason, test with following script.

revert to QTGMC_deflate/QTGMC_inflate:
https://www.sendspace.com/file/w71pfj

[hello_hello]

That fixed it. It also made the output bitrate the same.

QTGMC+LSFMod+x264 with the 720p sample I uploaded previously.

QTGMC 3.33 - 3.86fps, 4366kbps
QTGMC 3.33d - 1.78fps, 4309kbps
QTGMC 3.33 (revert) - 3.85fps, 4366kbps

For the record, this is the result using the same script for encoding as before while adding LSB=true and LSBD=true to QTGMC's parameters (I don't know if the latter makes a difference with the default denoising).

QTGMC 3.33d - 1.72fps, 4138kbps
QTGMC 3.33 (revert) - 1.79fps, 4200kbps

I'm not sure what to make of that yet. I don't seem to be able to monitor Avisynth memory usage with XP but I'll look for a way to do it and experiment a bit more. It certainly smells like a memory problem but I don't understand why it happens just under one particular circumstance. QTGMC and LSFMod both use MaskTools2 so maybe that's got something to do with it, although I've tried several versions with the same result.

I know it's not an important problem as such, and it's easy enough to work around, but maybe one day knowing why it's happening will be beneficial. If you have any other ideas I don't mind testing and in the mean time I'll keep playing around......

Cheers.

[Dogway]

I don't think there's anything special on lsfmod other than more meat to chug. I guess the outcome would be similar with other filters.

There's nothing special on the revert. I originally modified it to use presumably faster, leaner mt_deflate() instead of original mt_logic() and removegrain combo workaround, because it was indeed a work around speed gain (no longer necessary with modern versions of masktools). So I can't answer why the awkward method works fine while the straight forward doesn't, but it would help to update hardware or even software. I personally use SEt's MT avisynth 2.6, on Win7, the OS makes a change, I have a dual boot with XP and 7 had a slight lead.

lsb helps with quantization. I'm not sure if worth as much as to halve your filtering speed. Try the alternatives methods of my above post and check in case it's bottlenecked.

[hello_hello]

I didn't continue with MT Avisynth after a couple of tries that didn't result in a 100% stable outcome. Mostly it'd be fine, but after setting up encoding jobs and returning to the PC a few times expecting it to have spent hours/days encoding, only to discover it'd really spent most of that time displaying an error message, I went back to single threaded Avisynth. I don't think it's any slower than MT Avisynth in that when there's slow filtering involved I simply run 2 encodes at a time (or split an encoding job in two and run them together), and it's rock solid that way, apart from this particular QTGMC slowdown problem.

The only other time I've had a similar speed problem turned out to be QTGMC/mt_masktools slowing to a crawl when the source video wasn't mod16, so for a while I worked around that with AddBorders() until I discovered this version of MaskTools2 isn't bothered by that sort of thing.

A hardware upgrade is on the cards pretty soon for me, and probably Win7 to go with it, but to be honest I doubt it'll fix the problem in question, it'll likely just enable the encoding to run faster when it's running slowly. Did you test my sample yourself?

Anyway, I'll try the methods you suggested, keep experimenting and report back if I discover anything new, but how exactly do you monitor Avisynth's memory usage? Process Explorer still only seems to show the x264 process but nothing specific to Avisynth. Am I missing something?

Thanks.

[Dogway]

Process Explorer still only seems to show the x264 process but nothing specific to Avisynth

That's why it's not a good idea to pair x264 with heavy scripts. I went through similar hurdles before, but for me setting up parallel scripts etc is too much extra work to bare.
I just encode to lossless since they usually require less resources (memory) then watch out that speed is good as well as CPU usage. If everything is ok, pass, otherwise mp_pipeline or divide the script in several passes to intermediary, that's how I do it personally. It's not better or worse than what other people do just what works best for me. There's no rock solid solution in avisynth.

[hello_hello]

Well I'm sold on MP_Pipeline so far. I don't really know what I'm doing with it so I just copied the sample script and modified it to apply it to mine. Which worked. Encoding speed for QTGMC 3.33 went from 3.86fps to 4.66fps. For QTGMC 3.33d it went from 1.78fps to 4.72fps.

MP_Pipeline("""
FFVideoSource("E:\test.mkv", cachefile="D:\test.mkv.ffindex", fpsnum=24, fpsden=1, threads=1)
QTGMC(InputType=1, Preset="medium", EzDenoise=1)
crop(4, 2, -4, -2)
Spline36Resize(1280,720)
### prefetch: 16, 0
### ###
""")
LSFMod(strength=75)
gradfun3()

After adding lsb=true to QTGMC 3.33d's options encoding speed went from 1.72fps to 1.85fps.

MP_Pipeline changes the bitrate marginally (it went from 4366kbps to 4348kbps for QTGMC 3.33) but I don't think it's enough to worry about.

So it seems I was on the verge of not enough memory with this one. I still think it's odd though that just one particular circumstance shows a problem, but I'll keep playing around.

Thanks.

[hello_hello]

One of the things I do hope MP_Pipeline will fix (and it seems it might) is the media player out of memory error messages I sometimes get when using complicated filtering while previewing the script in MeGUI's preview (SRestore seems to be the worst offender). I had a play and so far so good but I noticed something......

When I use the script from my previous post with QTGMC 3.33 and let the preview play from scratch, TaskManager is showing MeGUI's memory usage at frame 350 as roughly 994,000K, and for MP_Pipeline it's 644,000K (while it's just sitting idling, MeGUI uses about 32,000K).

When I switched to QTGMC 3.33d the numbers were 986,000K and 648,000K so for that rough test the two QTGMC versions seem to require around the same amount of memory. I don't know if it's really that simple though......

When I stop using MP_Pipeline with QTGMC 3.33d the rate at which the preview runs begins to slow at about frame 60 and by frame 80 it's running at a crawl. For QTGMC 3.33 the preview just plods along at a fairly consistent pace. I don't know if MeGUI's preview has it's own maximum memory limit (it seems to) but in both cases it peaked at about 1,100,000K.

I don't know what to make of any of that. I just thought I'd mention it.


Some single vs dual simultaneous encoding observations using my test.mkv source file. QTGMC 3.33.

A single encode manages 3.86fps.
Two simultaneous encodes manage 3.01fps & 3.02fps.

With MP_Pipeline a single encode manages 4.66fps
Two simultaneous encodes manage 2.60fps & 1.86fps.

Aside from two simultaneous encodes without MP_Pipeline already happily pushing CPU usage to 100%, I think I literally ran out of RAM during the last one. I won't try that again till I have some more memory and I'm running something other than XP.

I'll leave you in peace now and stop messing up your thread. Thanks for your help!

[Dogway]

Study it and try different settings for mp_pipeline, it can easily make a difference, I normally have to tweak the mp_pipeline cache every time for a new script. Just ask in doom9 or open a thread here if you need more help so we or more people can discuss and join in.

[LouieChuckyMerry]

Hi Dogway. I just noticed that LinearResize has the options Lsb_In and Lsb_Out and was wondering if my usage here:

LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\DGIndexNV\DGDecodeNV.dll")
DGSource("SourcePath")
### Deinterlace-Match Fields-Decimate-Fix Line Doubled Fields ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
Function FieldMatch(Clip C) {
TFM(Order=-1,Mode=5,PP=2,Clip2=FieldMatch(),Slow=2,MChroma=False,Ubsco=False,CThresh=12,Chroma=True)
TDecimate(Mode=1)
NNEDI3(Field=-2)
Merge(SelectEven(),SelectOdd())
### Stabilize ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
LinearResize(640,480,Kernel="Spline36")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(DFTTest(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=500,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2,Chroma=False)
### Deband ###
GradFun3(Thr=0.55,SMode=2,Lsb=True,Lsb_In=True,StaticNoise=True)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=20,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

would benefit from this in any way, speed or quality or anything? If so, then would this be the proper way:

LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\DGIndexNV\DGDecodeNV.dll")
DGSource("SourcePath")
### Deinterlace-Match Fields-Decimate-Fix Line Doubled Fields ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
Function FieldMatch(Clip C) {
TFM(Order=-1,Mode=5,PP=2,Clip2=FieldMatch(),Slow=2,MChroma=False,Ubsco=False,CThresh=12,Chroma=True)
TDecimate(Mode=1)
NNEDI3(Field=-2)
Merge(SelectEven(),SelectOdd())
### Stabilize ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(DFTTest(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=500,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2,Chroma=False)
### Deband ###
GradFun3(Thr=0.55,SMode=2,Lsb=True,Lsb_In=True,StaticNoise=True)
### Resize ###
LinearResize(640,480,Kernel="Spline36",Lsb_In,Lsb_Out)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=20,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

Also, I'm a bit confused about which mode to use because of the wording of the .avsi. It states:

Default mode= for output is always 6 (error diffusion), this gives out the most quality, but for video encoding
### it is recommended to use 0 (ordered dither) or similar for better optimization on encoding quantization.

It seems to me I should use "Mode=0" because I'm encoding but if I remember correctly you told me to use the default "Mode=6" when you recommended switching from RatioResize to LinearResize. Thanks .

[Dogway]

Resizer comes after denoiser (generally). Mode here is indistinct because you are not dithering down to anything, your pipeline is still in 16-bit (not lsb_out but lsb_out=true) and ultimately exporting as 10-bit -Dither_Out()-

Then you want debanding just after all high bitdepth filtering, that is Gradfun3 after Dither_Add16.

[LouieChuckyMerry]

Ahhh, I wondered about the proper order, and thanks for explaining the LinearResize mode reasoning and pointing out that I forgot the "=True" (twice). I had the GradFun3 at what I thought was the end of the high bitdepth filtering, not realizing that the mode change for Dither (to "Mode=-1") only changes how the non-high bitdepth filters are applied (and not the overall pipeline). Now I know better. So (please correct me if I'm wrong):

LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\DGIndexNV\DGDecodeNV.dll")
DGSource("SourcePath")
### Deinterlace-Match Fields-Decimate-Fix Line Doubled Fields ###
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
Function FieldMatch(Clip C) {
TFM(Order=-1,Mode=5,PP=2,Clip2=FieldMatch(),Slow=2,MChroma=False,Ubsco=False,CThresh=12,Chroma=True)
TDecimate(Mode=1)
NNEDI3(Field=-2)
Merge(SelectEven(),SelectOdd())
### Stabilize ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(DFTTest(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=2,ThSAD=400,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2,Chroma=False)
### Resize ###
LinearResize(640,480,Kernel="Spline36",Lsb_In=True,Lsb_Out=True)
### Darken-Thin Lines ###
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=20,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
### Deband ###
GradFun3(Thr=0.55,SMode=2,Lsb=True,Lsb_In=True,StaticNoise=True)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

And if I read the LinearResize .avsi correctly Kernel="Spline36" is the default, so can I change the line to:

LinearResize(640,480,Lsb_In=True,Lsb_Out=True)

I ask because it helps me keep track of things more easily if only non-default settings are listed. Also, is it typical that debanding is always the last thing? Thanks for your help.

[BÌG•bµdd]

Sorry i jumped in while u were talking friends .all function are nicely moded by u Dogway but MCawarpsharp3 is 2x slower than you'r Smdegrain Mod why is it like that ?does it work more better than Smdegarin ?
MCawarpsharp3 some slow settings "Subsamp=4" is supa-slow
Mcawarpsharp3 "fast=true" doesn't help much to speed things up, don't know why i dnt like it as i like your smdegrain so much

[Dogway]

In the last month (4.3, 4.4, and 4.5) I fixed all issues regarding PadMirror and PadResize. So I make a call up to all those that downloaded it before to download this fixed version.

[hello_hello]

Edit: Dogway, you don't need to worry about modifying QTGMC for me (as per the request below). real.finder was kind enough to do it.
http://forum.doom9.org/showthread.php?p=1743994#post1743994
I'm still trying to sort the slowdown problems. At least now I know I'm not alone.

Dogway, if you're still about could I ask a favour?

Back here you modified QTGMC for me while I was trying to sort out a slowdown problem and at the time it seemed to fix it. As there's a newer version of QTGMC since then I switch to it but the speed problems have been driving me nutty (encodes either run at full speed or at about half speed for no apparent reason, yet after aborting a slow encode and starting it again it usually runs at full speed). Anyway....

I'm currently back to using the version you modified for me, so far without speed issues, but I was wondering, could you apply the same modification to the latest QTGMC for me so I can test it, or could you tell me what I'd need to modify? I've attached the version I've been using because I'd like to see if reverting the same change fixes the speed problem. If it doesn't then I guess I need to look elsewhere. The last few times encoding slowed I wasn't using LSFMod (as I was previously) and I was decoding with DGDecode (previously ffmsindex) so that seems to eliminate LSFMod and ffmsindex as culprits I've also tried different versions of the plugins QTGMC uses but haven't found a culprit there yet.

Thanks.

The script probably wasn't called "QTGMC 3.33s (mod) v2.avsi" when it was uploaded in the QTGMC thread at doom9, but I'm pretty sure it's the latest version. I've changed some of the QTGMC script names on my PC because I was getting confused as to which version I was using.

Thanks again.

[hello_hello]

Given it seems to have fixed my speed problem again, here's QTGMC 3.33s with "revert to QTGMC_deflate/QTGMC_inflate" in case anyone wants it.
And apparently there's also a small change relating to the old RemoveGrain plugin.
http://forum.doom9.org/showthread.php?p=1743994#post1743994

[Dogway]

Sorry hello_hello, I've been having internet issues since the 19th, the whole day yesterday.

I don't have the version I fixed for you, since I didn't need it. So if you have it around pass it along to see all the changes I did perform.

I see problems with the newer versions you posted, at a glance there are some potential lsb clips that under yuy2 are treated the same as non-lsb (8-bit) clips. This is a known problem for several reasons, for example you will get artifacts at the bottom of the frame. To process them correctly you need to do some plane rearrangements that I included in SMDegrain as helper functions.

[real.finder]

Sorry hello_hello, I've been having internet issues since the 19th, the whole day yesterday.

I don't have the version I fixed for you, since I didn't need it. So if you have it around pass it along to see all the changes I did perform.

I see problems with the newer versions you posted, at a glance there are some potential lsb clips that under yuy2 are treated the same as non-lsb (8-bit) clips. This is a known problem for several reasons, for example you will get artifacts at the bottom of the frame. To process them correctly you need to do some plane rearrangements that I included in SMDegrain as helper functions.

work fine here

ColorBars(width=720, height=480, pixel_type="rgb32")
ConvertToYUY2()
AddGrainC()
Interleaved2Planar
super_search = MSuper(rfilter=4, planar=true)

bv2 = super_search.MAnalyse(isb = true,  delta = 2, overlap= 4)
bv1 = super_search.MAnalyse(isb = true,  delta = 1, overlap= 4)
fv1 = super_search.MAnalyse(isb = false, delta = 1, overlap= 4)
fv2 = super_search.MAnalyse(isb = false, delta = 2, overlap= 4)

MDegrain2(MSuper(levels=1, planar=true), bv1, fv1, bv2, fv2, thSAD=300, thSADC=150, lsb=true, planar=true)
Planar2Interleaved
ConvertToYV16
DitherPost(mode=6)
ConvertToYUY2