QTGMC Deinterlacing Script (v3.384)

[flossy_cake]

As I see, QTGMC also has a denoising option, and shouldn't ff3dfilter be called already during executing QTGMC?

Well, if remove libfftw3f-3.dll from c:\windows\System32 then QTGMC will still work for me but QTGMC(EZDenoise>0) will NOT work unless that dll is present. But wiki says "MVTools2 need the FFTW3 library" and MVTools2 is required for default QTGMC processing, so I have no idea why QTGMC still works without it maybe someone could explain that :thanks:

On a separate note I deleted my previous comment about SLRad because after more testing the info I wrote was wrong. The way QTGMC sharpens the image is still somewhat dynamic and unpredictable depending on duplicate frames in the clip and InputType. In the end I settle on 0.2 for InputType=1 and 0.4 for InputType=2&0 but I'm still testing with lots of content. Note: static test patterns should not be used because it's temporal sharpening. What you want is a scene with a little bit of camera movement with an actors face at a distance, then look how sharp their facial features are compared to no QTGMC at all. I think that might be the optimal sharpness setting, maybe.

[kedautinh12]

MVTool2 just need the fftw3 libraries in some functions. Did you try fftw3 3.3.10 version?
https://forum.videohelp.com/threads/388908-fftw-3-3-7-DLLs

[flossy_cake]

Did you try fftw3 3.3.10 version?

It looks like that one is from 2018, and mine is from 2016. It's working fine so I won't muck with it for now.

Did some more sharpness tests and came to the conclusion it's not worth messing with the advanced sharpening settings as they can make an improvement on one scene and then do the opposite on another scene. Probably because it's a temporal filter so it all depends on what's moving, whether previous frame was a duplicate, etc. etc.

[kedautinh12]

3.3.10 from 2021 not 3.3.7 from 2018. You need check comment below

[DTL]

" why QTGMC still works without it "

MAnalyse only uses fftw if dct>0. So for spatial-only search modes it does not require external fftw.dll and does not try to load it. So someone may try to look into QTGMC script (which modes uses MAnalyse with dct=0) and add to documentation the description of modes not required fftw.dll as dependency.

In current documentation at http://avisynth.nl/index.php/QTGMC

DCT (0...10) Modes to use DCT (frequency analysis) or SATD as part of the block matching process - see MVTools2 documentation for choices. Default: 0

As I see in that version https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.6%20and%20up/QTGMC.avsi DCT is not enabled in any internal preset - so only user can set DCT>0 as QTCMC() params and cause loading of fftw.dll.

[flossy_cake]

Thanks for clarifying.

Today I was playing around with LimitedSharpen (http://avisynth.nl/index.php/LimitedSharpen) which uses MaskTools2 and RGTools, which if I'm not mistaken are the same libraries QTGMC uses to apply sharpening.

Anyway I find the sharpening quality of LimitedSharpen is better as it produces less artefacts. I wonder if it's possible to mod QTGMC to use LimitedSharpen instead.

I had considered just doing QTGMC(Sharpness=0).LimitedSharpen() but I don't think it's the same because QTGMC sharpening is temporally limited (SLMode=2) so it would need to be modded into QTGMC itself but I don't have the expertise.

[flossy_cake]

The reason I'm complaining about the sharpening is that QTGMC needs some sharpening to counteract its [desirable] antialiasing blur, but it has this tendency to oversharpen high contrast outlines, especially if the source has such style of "baked in" sharpening where even QTGMC(InputType=1, Sharpness=0.2) still oversharpens those outlines to the point it's noticeable at normal viewing distances (paradoxically it seems less noticeable at close viewing distances).

Lowering the sharpening to 0.1 or 0.0 isn't an option as then the blur becomes noticeable so I can't find a happy middle ground.

What I'd like is to swap QTGMC's internal sharpener for LimitedSharpen, which uses the same MVTools functions to sharpen, so it should be possible to substitute in but could only by done by an author who understands QTGMC like Dogway, A.SONY or Vit.

[flossy_cake]

Just thought I'd share these images showing the differences between the 3 QTGMC modes (InputType=0/1/2) in case it helps newcomers understand the resolution-antialiasing tradeoff in each mode.

I've read several anecdotes of people being turned off QTGMC because of its excessive smoothing, but perhaps they are not aware there are 2 other modes which are a lot different in that regard.

To understand what's going on you'll need to view these images at 1:1 pixel mapping. This is hard to achieve for multiple reasons like Windows DPI scaling, browser scaling, Lensdump's website scaling, and row/column driver shenanigans on LCD's. Just keep fiddling until you see perfect full-contrast 1 pixel thick white and black lines in the bottom right corner of the test patterns next to the number 1.


Test image 1 - static scene resolution test. This shows how much resolution is preserved on elements that are stationary.

https://b.l3n.co/i/O65dev.png



Test image 2 - moving resolution test. The black frame of his glasses are moving and therefore the source only contains 288p resolution when it is moving due to the field cadence being 1:1 where each 720x288 field is a new image. This is useful for looking at how good each mode is at antialiasing the 288p to something that is far more pleasant to look at especially on a bigger screen.

https://a.l3n.co/i/O65qyC.png


Explanation of modes:

InputType=0 is the default mode which performs deinterlacing and smoothing. Vertical resolution is significantly reduced in this mode. I wouldn't call it "half vertical res" (see the converging lines) but it's certainly not full vertical res. I would only use this mode on dirty sources that need a significant cleanup. It's also good at smoothing sources with field misalignment where fields were scaled independently of eachother during post production.

InputType=1 is the light progressive repair mode for use on content that has already been deinterlaced or IVTC'd. This is my personal preference as it scrubs very small amount of detail on moving parts only.

InputType=2 is the strong progressive repair mode. It's the same as mode 1 but does additional smoothing on moving parts of the image. As you can see in the screenshot the 1 pixel thick static lines on the test pattern are still fully resolved, but the moving glasses frame is getting nnedi3 interpolated and is noticeably less aliased than InputType=1. This is probably my preferred mode for 1:1 field cadence video. However some 1:1 cadence stuff is already smoothed/filtered in the source and InputType=1 can give a cleaner result. Viewing distance and screen size obviously plays a big part when we are dealing with only 288p/240p resolution.

I neglected to label the QTGMC(Sharpness=x) value in the screenshots. In my opinion the default value of 1.0 is too high and produces an image that is not representative of the source sharpness in A-B comparisons. I'm currently using values of 0.2/0.5/0.8 for InputType=1/2/0 respectively. I am confident of the value 0.2 for InputType=1, but still fiddling with the other two. QTGMC uses temporal sharpness limiting where only moving parts of the image are sharpened for the sake of counteracting softening caused by itself. In my opinion this sharpening is necessary as Sharpness=0 appears softer than the source in A-B comparisons on moving elements (moving elements could include slight camera movements or an actors face slightly moving, so this countersharpening comes into play quite a bit).

If you have a soft source and would like to sharpen it I would not recommend trying to sharpen it with the QTGMC sharpness value which should only be used to counteract the softening caused by its own antialiasing, and nothing more. If you want to add more sharpening beyond that, do that afterwards with something like LimitedSharpen and/or aWarpSharp for edge thinning.


Script used for the screenshots


source = "https://drive.google.com/uc?export=download&id=1WfW3yXmGhIvUCiexQGYD18gSiXRe2bze"

LWLibavVideoSource(source, stream_index=-1, repeat=true)

orig = last

# double rate perpixel deint with slightly raised weave thresh
bwdif = orig.propDelete("_FieldBased").bwdif(field=-2, thr=2)

# QTGMC default mode
qtgmc0 = orig.QTGMC(InputType=0, Sharpness=1.0, preset="slow")

# QTGMC progressive repair 1
qtgmc1 = bwdif.QTGMC(InputType=1, Sharpness=0.2, preset="slow", rep0=13)

# QTGMC progressive repair 2
qtgmc2 = bwdif.QTGMC(InputType=2, Sharpness=0.4, preset="slow", rep0=13)

top_row = StackHorizontal(
\ bwdif.SubTitle("bwdif", align=5, size=30).AddBorders(16,16,16,16),
\ qtgmc0.SubTitle("QTGMC(InputType=0)", align=5, size=30).AddBorders(16,16,16,16))

bottom_row = StackHorizontal(
\ qtgmc1.SubTitle("bwdif.QTGMC(InputType=1)", align=5, size=30).AddBorders(16,16,16,16),
\ qtgmc2.SubTitle("bwdif.QTGMC(InputType=2)", align=5, size=30).AddBorders(16,16,16,16))

StackVertical(top_row, bottom_row)




edit: I forgot to mention as QTGMC is a temporal filter by nature it behaves slightly differently when processing video where each frame is a new unique image vs video containing duplicate frames. For example double framerate deinterlacing will give you duplicate frames on film based content, and in this case the duplicates slightly reduce QTGMC's smoothing effect as well as its countersharpening strength. So don't expect same results when using the progressive repair modes on say 25p vs 50p. 25p will have more smoothing and countersharpening, 50p will have less smoothing and countersharpening. Subjectively I prefer the result when the source contains duplicates, but you can't just chop it in half afterwards with SelectEven() as there is stuff going on with visual persistence when seeing antialiased topfield followed by antialiased bottomfield rapidly and successively that doesn't occur after chopping in half.

edit2: also forgot to explain the rep0=13 setting in the script above. Basically this setting I found through trial and error was best at reducing motion artefacts, especially when there are duplicate frames in the source, and especially for animation.

https://a.l3n.co/i/OCTYgb.png

https://b.l3n.co/i/OCTckq.png

edit: however when using InputType=0 for smoothing of field misalignment in the source, Rep0=13 will no longer be sufficient for that purpose so in that case it's best to use the default value i.e Rep0=undefined().

[DTL]

Trying to play with QTGMC settings I currently stuck with SrchClipPP param:
With SrchClipPP=0 some areas of the frame are more detailed but others are more blurry.
With SrchClipPP (default, 2 or 3) the areas are reversed.

So quick question to script writers: Can we somehow gather details from 2 clips - one processed with SrchClipPP=0 and other processed with SrchClipPP=default ? May be something with masktools or Expr ? It can even gather more noise from both clips because the next stage in our workflow is denoise. The task for QTGMC is only recreate more detailed progressive frames even keeping more noise.

Trying to feed non(or less)-PP clips to SuperCurrent input of MAnalyse as more detailed reference but it starts to make bobbing of many areas. Need some idea how to fix it is possible.

This is working as expected in C plugin: (for 3 clips: srcp_ref, srcp_c1, srcp_c2)

working_t wtDiffC1 = std::abs(srcp_ref[x] - srcp_c1[x]);
working_t wtDiffC2 = std::abs(srcp_ref[x] - srcp_c2[x]);
if (wtDiffC1 > wtDiffC2)
dstp[x] = srcp_c1[x];
else
dstp[x] = srcp_c2[x];

May this can be put to Expr() ? So less plugins required and less time to develop and debug.

[DeadSkullzJr]

Updated post here:
https://forum.doom9.org/showpost.php?p=2001440&postcount=1013

[DTL]

For better details gathering from different QTGMC calls with different params sets I made M_QTGMC() wrapper - https://forum.doom9.org/showthread.php?p=2001388#post2001388 .

It can be used with classic QTGMC based on classic 2.7.x mvtools and also with new 2.8.x . For classic - simply remove new arguments (mvt_*) from QTGMC calls. The most useful combinations of params found - block size 8x8 and 16x16 and pre-process of input clip for MAnalyse or not.

The Average() plugin for 2 clips average may be replaced with Layer or Overlap internal in the future versions.

[DeadSkullzJr]

Just thought I'd share these images showing the differences between the 3 QTGMC modes (InputType=0/1/2) in case it helps newcomers understand the resolution-antialiasing tradeoff in each mode.

I've read several anecdotes of people being turned off QTGMC because of its excessive smoothing, but perhaps they are not aware there are 2 other modes which are a lot different in that regard.

To understand what's going on you'll need to view these images at 1:1 pixel mapping. This is hard to achieve for multiple reasons like Windows DPI scaling, browser scaling, Lensdump's website scaling, and row/column driver shenanigans on LCD's. Just keep fiddling until you see perfect full-contrast 1 pixel thick white and black lines in the bottom right corner of the test patterns next to the number 1.


Test image 1 - static scene resolution test. This shows how much resolution is preserved on elements that are stationary.

https://b.l3n.co/i/O65dev.png



Test image 2 - moving resolution test. The black frame of his glasses are moving and therefore the source only contains 288p resolution when it is moving due to the field cadence being 1:1 where each 720x288 field is a new image. This is useful for looking at how good each mode is at antialiasing the 288p to something that is far more pleasant to look at especially on a bigger screen.

https://a.l3n.co/i/O65qyC.png


Explanation of modes:

InputType=0 is the default mode which performs deinterlacing and smoothing. Vertical resolution is significantly reduced in this mode. I wouldn't call it "half vertical res" (see the converging lines) but it's certainly not full vertical res. I would only use this mode on dirty sources that need a significant cleanup. It's also good at smoothing sources with field misalignment where fields were scaled independently of eachother during post production.

InputType=1 is the light progressive repair mode for use on content that has already been deinterlaced or IVTC'd. This is my personal preference as it scrubs very small amount of detail on moving parts only.

InputType=2 is the strong progressive repair mode. It's the same as mode 1 but does additional smoothing on moving parts of the image. As you can see in the screenshot the 1 pixel thick static lines on the test pattern are still fully resolved, but the moving glasses frame is getting nnedi3 interpolated and is noticeably less aliased than InputType=1. This is probably my preferred mode for 1:1 field cadence video. However some 1:1 cadence stuff is already smoothed/filtered in the source and InputType=1 can give a cleaner result. Viewing distance and screen size obviously plays a big part when we are dealing with only 288p/240p resolution.

I neglected to label the QTGMC(Sharpness=x) value in the screenshots. In my opinion the default value of 1.0 is too high and produces an image that is not representative of the source sharpness in A-B comparisons. I'm currently using values of 0.2/0.5/0.8 for InputType=1/2/0 respectively. I am confident of the value 0.2 for InputType=1, but still fiddling with the other two. QTGMC uses temporal sharpness limiting where only moving parts of the image are sharpened for the sake of counteracting softening caused by itself. In my opinion this sharpening is necessary as Sharpness=0 appears softer than the source in A-B comparisons on moving elements (moving elements could include slight camera movements or an actors face slightly moving, so this countersharpening comes into play quite a bit).

If you have a soft source and would like to sharpen it I would not recommend trying to sharpen it with the QTGMC sharpness value which should only be used to counteract the softening caused by its own antialiasing, and nothing more. If you want to add more sharpening beyond that, do that afterwards with something like LimitedSharpen and/or aWarpSharp for edge thinning.


Script used for the screenshots


source = "https://drive.google.com/uc?export=download&id=1WfW3yXmGhIvUCiexQGYD18gSiXRe2bze"

LWLibavVideoSource(source, stream_index=-1, repeat=true)

orig = last

# double rate perpixel deint with slightly raised weave thresh
bwdif = orig.bwdif(field=-2, thr=2)

# QTGMC default mode
qtgmc0 = orig.QTGMC(InputType=0, Sharpness=1.0, preset="slow")

# QTGMC progressive repair 1
qtgmc1 = bwdif.QTGMC(InputType=1, Sharpness=0.2, preset="slow", rep0=13)

# QTGMC progressive repair 2
qtgmc2 = bwdif.QTGMC(InputType=2, Sharpness=0.4, preset="slow", rep0=13)

top_row = StackHorizontal(
\ bwdif.SubTitle("bwdif", align=5, size=30).AddBorders(16,16,16,16),
\ qtgmc0.SubTitle("QTGMC(InputType=0)", align=5, size=30).AddBorders(16,16,16,16))

bottom_row = StackHorizontal(
\ qtgmc1.SubTitle("bwdif.QTGMC(InputType=1)", align=5, size=30).AddBorders(16,16,16,16),
\ qtgmc2.SubTitle("bwdif.QTGMC(InputType=2)", align=5, size=30).AddBorders(16,16,16,16))

StackVertical(top_row, bottom_row)




edit: I forgot to mention as QTGMC is a temporal filter by nature it behaves slightly differently when processing video where each frame is a new unique image vs video containing duplicate frames. For example double framerate deinterlacing will give you duplicate frames on film based content, and in this case the duplicates slightly reduce QTGMC's smoothing effect as well as its countersharpening strength. So don't expect same results when using the progressive repair modes on say 25p vs 50p. 25p will have more smoothing and countersharpening, 50p will have less smoothing and countersharpening. Subjectively I prefer the result when the source contains duplicates, but you can't just chop it in half afterwards with SelectEven() as there is stuff going on with visual persistence when seeing antialiased topfield followed by antialiased bottomfield rapidly and successively that doesn't occur after chopping in half.

edit2: also forgot to explain the rep0=13 setting in the script above. Basically this setting I found through trial and error was best at reducing motion artefacts, especially when there are duplicate frames in the source, and especially for animation.

https://a.l3n.co/i/OCTYgb.png

https://b.l3n.co/i/OCTckq.png

edit: however when using InputType=0 for smoothing of field misalignment in the source, Rep0=13 will no longer be sufficient for that purpose so in that case it's best to use the default value i.e Rep0=undefined().

This is helpful as I didn't understand what these were for when I was researching into their use case, though I do wonder, how come there are still some leftover field blemishes in the images you presented? Bad source recording or something?

[DeadSkullzJr]

Side note, I attempted to make a post earlier in regards to my tests with QTGMC and its lossless capabilities, not sure what happened to the post if it even made it through, but I decided that maybe I can safely try again, any moderators reading this, if this somehow gets stuck in moderation abyss, I am sorry for the duplicate posts, the last attempt I think happened while the system basically clocked out my login session, been a day or two and the post never made it, hence the second attempt. Moving forward though...

I tested QTGMC's lossless capabilities to see if such functions were true to their word (according to specific values and their corresponding information on the QTGMC page). I understand going this route has time consumption properties to it and won't seem worth it to most, however I have a machine to spare for the wait time and am willing to go full throttle with it and have been doing so in various ways for quite a while now (especially where encoding is concerned), I'm just looking to preserve as much quality as I can, if I can go lossless then even more so. I created a basic script according to the information provided on the page, script in question.

AviSource ("video.avi")
AssumeTFF
QTGMC (Preset = "Placebo", SourceMatch = 3, Lossless = 1)

This worked out great, however I did some investigating just to see if the results actually worked the way they should have, so I interlaced the deinterlaced video and did some frame by frame analysis. Results came back mostly positive. The correct amount of frames are present, and at a decent glance, the level of detail appears 1:1, however I did notice some very faint differences that should be mentioned. I'll provide pictures to show the results.

Frame pulled from the original interlaced video:
https://i.imgur.com/rgzjkwG.png

Frame pulled from the deinterlaced then converted interlaced video:
https://i.imgur.com/3IDmgcl.png

The original video was recorded as YCbCr 4:2:2 (YUY2 as the chosen codec color space) format, with the quality set to lossless, the footage is as clear as it is due to using an s-video connection, however I have performed this same test using my composite connection and it had the exact same results with that respective recording. Using the script created, the color space was set to be YUYV, however YUYV and YUY2 are interchangeable and won't (or at least isn't supposed to) impact the actual colors of the recording, I even used ConvertToYUY2 in the script just to make sure, and that didn't make a difference, which means it didn't need to be present in the script (likewise with the SourceMatch line as it seems using the Lossless line supersedes the SourceMatch functions as there wasn't any differences between the two video frames at all, maybe there is a more particular use case that I haven't run across yet). You might be looking at the two images above and thinking they are identical, and at face value that appears to be the case, however I compared the two frames seen above from the respective interlaced videos and got these differences:

Frame comparison between both frames (gray = no differences, red = differences):
https://i.imgur.com/1yjNo6S.png

Likely would have been more if I used anything faster than placebo, but the point is, true lossless is basically close, but definitely not all there. Clearly the color space is correct as if it was anything different, way more of the image would be red compared to gray, however the faint color differences with some of the pixels is very interesting, I'm not sure what is causing this or if it can even be corrected. There is a chance that maybe I am doing something wrong, if you guys know something I don't, feel free to correct me please.

[flossy_cake]

how come there are still some leftover field blemishes in the images you presented? Bad source recording or something?

I presume you mean the family guy comparison where he is holding the ball and there is still some residual motion artefacts on her nose and lips even with rep0=13? Those artefacts are not in the source, no. Given how QTGMC works as a temporal filter it's to be expected I think. Animation has these massive jumps in pixel luminance from frame to frame with the black character outlines appearing immediately in a single frame so temporal antialiasing is going to react to that with some blending with the line above/below which could be previous/current frame. I am not sure if the source match mode would resolve it as I don't use it and am not familiar with it. I am not surprised the pixels are not completely identical in your grayscale test image as there could be all kinds of slight rounding errors at multiple places in the pipeline. I'm not entirely clear on the exact processing you did for the "deinterlaced then converted interlaced video" - did you pick out the original (lossless) fields from the QTGMC deinterlaced (sourcematched) frames and weave them back together or something?

[LigH]

QTGMC, like every deinterlacer with motion estimation, relies on temporally continuous interlaced sources. Cartoons, containing temporally discrete stop-motion material, are not valid source material for an algorithm that tries to take advantage of information from the temporal neighbourhood of the current video field. Or the other way round: You are using the wrong tool for your purpose. You have to "abuse" it to make it omit its main advantage.

[DeadSkullzJr]

I presume you mean the family guy comparison where he is holding the ball and there is still some residual motion artefacts on her nose and lips even with rep0=13? Those artefacts are not in the source, no. Given how QTGMC works as a temporal filter it's to be expected I think. Animation has these massive jumps in pixel luminance from frame to frame with the black character outlines appearing immediately in a single frame so temporal antialiasing is going to react to that with some blending with the line above/below which could be previous/current frame. I am not sure if the source match mode would resolve it as I don't use it and am not familiar with it. I am not surprised the pixels are not completely identical in your grayscale test image as there could be all kinds of slight rounding errors at multiple places in the pipeline. I'm not entirely clear on the exact processing you did for the "deinterlaced then converted interlaced video" - did you pick out the original (lossless) fields from the QTGMC deinterlaced (sourcematched) frames and weave them back together or something?

I used a simple script to interlace the deinterlaced video.

AviSource ("video.avi")
AssumeTFF
SeparateFields
SelectEvery (4, 0, 3)
Weave

I also used VirtualDub2's interlace filter as well, while the resulting video hashes differed, I still proceeded to do a frame by frame comparison between both newly interlaced videos and both matched 1:1, however neither matched the original interlaced video still due to those pixel differences. Could be a chance that the interlacing process can be tuned up a bit, I'll have to play around some more with it, if you know something I don't, of course I am open to trying things out.

[flossy_cake]

QTGMC, like every deinterlacer with motion estimation, relies on temporally continuous interlaced sources. Cartoons, containing temporally discrete stop-motion material, are not valid source material for an algorithm that tries to take advantage of information from the temporal neighbourhood of the current video field. Or the other way round: You are using the wrong tool for your purpose. You have to "abuse" it to make it omit its main advantage.

A deinterlacer should be able to handle any field cadence without producing major artefacts, and with Rep0=13 it is capable of that. The family guy screenshots are using InputType=1 which is progressive repair mode (not deinterlacing) and I cherry picked those frames as a worst case example.

[LigH]

Handling exceptional material is not a classical "deinterlacing" algorithm in my opinion, which relies on a linear temporal progress from field to field, because the video content was originally recorded field by field and supposed to be displayed field by field as well, but our current displays work in progressive order now.

Instead it is rather a kind of decimation (http://avisynth.nl/index.php/External_filters#IVTC_.26_Decimation) (like in Inverse Telecine) or a least-different field duplication (http://avisynth.nl/index.php/External_filters#Duplicate_Frame_Detectors), reverting the weaving of two fields from originally progressive frames into a combed frame for a smoother playback on a display in interlaced mode (strictly "interlaced" video never had originally progressive frames, each field was shot at a different moment of time).

I agree though, that respecting scenes without obvious motion gives deinterlacers an advantage. Not processing still areas would preserve better quality than blindly processing everything as if there was linear motion everywhere and only one field would contain reliable content. And in addition, I guess cartoons could be treated like "scene cuts every few frames".

[flossy_cake]

Deinterlacing modes that I'm aware of...

Bob deinterlacing - just upscales each 720x240 field to 720x480 and displays them one after the other (with 1px vertical offset on alternate frames to preserve the field alignment). Looks pretty bad, aliasing, shimmer, flicker, softness to the image. Early HDTV's used to use this. It does look a lot better when the bob output rate is equal to the screen refresh rate, in fact you get a kind of field combining effect from persistence of vision. So even on static elements I wouldn't quite call it "half vertical res" but it's nowhere near full.

Per pixel / "motion compensated" deinterlacing - uses bob for moving parts of the image, weaves static areas, eg. BWDIF & TDeint. Looks way better than bob. Standard deinterlacing mode for most TV's and set top boxes since around 2006-ish.

QTGMC(InputType=0) - a very sophisticated type of bob deinterlacing that looks way better than bob and antialiases the image a lot. I tend to think of it as the best possible version of bob deinterlacing. Nothing is weaved, everything is bobbed, but the field upscaling is done by NNEDI3 for sharper edges, and then a ton of ultra sophisticated motion compensated smoothing to antialias the result. Great for cleaning up dirty content.

Per pixel + QTGMC(InputType=1/2) - what I consider to be the ideal combo. First do per-pixel deint with BWDIF or TDeint, then use QTGMC(InputType=1/2) to antialias moving parts of the image only (just make sure ProgSADMask is not set to 0 when using InputType=2 otherwise it'll just NNEDI3 interpolate the whole frame).


propDelete("_FieldBased") # because filters preference _FieldBased over Avisynth internal clip properties,
and _FieldBased is often different from clip properties and this can cause all kinds of
issues downstream relating to field order, saves huge headaches by just deleting it

BWDIF(field=-2, thr=2).Prefetch(1) # per pixel deint with slightly raised weave thresh to prevent film grain triggering bob

QTGMC(InputType=1/2, Preset="slow", Rep0=13, EdiThreads=2).Prefetch(4) # temporal antialiasing on moving parts of image only,
ie. the parts that BWDIF bobbed

[TCmullet]

I actually have skimmed all the prior pages of this thread! Looking for various insights as I begin usage of this amazing tool. I'm kinda glad my VHS/SVHS huge collection had to wait til 2024 so that QGGMC could be so greatly refined. THANKS to all the developers of all the various parts! I'm very impressed with what I see when I merely use all defaults.

The doc page is a bit out of date in that the Multi-threaded Usage section utilizes the SetMTMode function. But that no longer exists. I'm requesting info on how to get my processors to be utilized better. 4 cores, 8 threads. If there's documentation, please point me to it (I didn't see much in this thread). Or if none, then maybe someone who knows how can tell us here??

[flossy_cake]

I actually have skimmed all the prior pages of this thread! Looking for various insights as I begin usage of this amazing tool. I'm kinda glad my VHS/SVHS huge collection had to wait til 2024 so that QGGMC could be so greatly refined. THANKS to all the developers of all the various parts! I'm very impressed with what I see when I merely use all defaults.

The doc page is a bit out of date in that the Multi-threaded Usage section utilizes the SetMTMode function. But that no longer exists. I'm requesting info on how to get my processors to be utilized better. 4 cores, 8 threads. If there's documentation, please point me to it (I didn't see much in this thread). Or if none, then maybe someone who knows how can tell us here??


I think a good starting point for an average CPU might be QTGMC(EdiThreads=2).Prefetch(4). Then if you need more perf try 6 or 8 threads. Wiki says to make EdiThreads half of Prefetch, not sure if that's still relevant. I usually just leave it at 2 and haven't really seen better perf with higher values, although I'm only using a 4790k. But I use the "slow" preset instead of the default "slower" as that makes very little diff to image quality for a big perf boost. For realtime 1080i I use preset="faster".

Whatever you do, watch the CPU meter for about 15 seconds after starting playback to see what it settles on once the prefetch buffer is full. I aim for it settling on around 50% for realtime use. Beware though NNEDI3 uses this prescreening feature where it only calculates NNEDI3 pixels if it thinks the pixel would benefit, and you can get random scenes where the CPU suddenly spikes cause it decided heaps of pixels needed NNEDI3 (usually when the scene contains a lot of high contrast edges) that's why I leave some overhead.

[TCmullet]

I set Edi to 2 and prefetch to 4. That was better than the Edi 8 and no prefetch I had before. (I still need to study what prefetch is.) Then when I upped Edi to 6, I had very good improvement. Tried 8, but that brought it down some. So, Edi 6 and prefetch 4 it IS! Thanks!

[LigH]

Prefetch is multithreading of the whole script. A larger number of threads lets the filtering run in parallel on several CPU cores but may reduce the scope of some filters (they "see" only a part of the video which might limit the quality in some rare cases).

As documented, EDI is multithreaded additionally, the actual number of EDI threads is the product of EDIThreads multiplied with Threads in Prefetch. So the EDI plugin runs in that many copies and needs that many clip variables which requires a lot of RAM.

[flossy_cake]

I'll add there is difference between multithreading the whole script and multithreading individual filters, and it can affect things considerably in relation to the number of threads needed for equivalent performance.

eg. QTGMC().Prefetch(4) will only assign 4 threads for QTGMC alone, which is different than putting a Prefetch(4) at the end of the script which assigns 4 threads to all filters above it. In testing I found I could avoid bottlenecks caused by previous filters by putting each filter in its own separate thread(s).

Some filters like TFM and TDeint wouldn't support multithreading until I forced them to obey it with:


SetFilterMTMode("TDeint", 2, true)
SetFilterMTMode("TFM", 2, true)


Then I go like...


TFM().Prefetch(2)


And this would relieve a TFM bottleneck when I'm doing realtime 1080i screening in MPC-HC.

If you dont need realtime perf, none of this will really matter as you'll probably be loading up the CPU with ffmpeg encoding anyway.

If the CPU is already pegged at 100% during ffmpeg encoding you're probably better off NOT using multithreading in Avisynth as there are threadsafe issues in certain scenarios, and some filters weren't really designed for it. But it generally works ok.

[DTL]

It looks current QTGMC versions has an issue with static sharp areas - https://forum.videohelp.com/threads/414700-QTGMC-jumping-effects-on-still-parts-in-video . Are there any workarounds with current internal processing possible ?

Attempt to increase SourceMatch (+Lossless) causes also degradation of all other frame areas close to 'input look'. So it close to disables all 'magic' of details and sharpness and edges restoration created by 'main QTGMC core processing'. It is too high price for simply having some small progressively overlaied logo to be sharp enough.

External workaround is looks like using global exported motion vectors create 'motion mask' and apply simple weave to 'static areas'. But it is also dangerous as described the motion estimation output may be unstable (and also creating unusable frames) near real scene changes so this method may create again badly processed frames near scene changes and again some flickering on small sharp progressive logo. Are there internal workarounds possible in the QTGMC for this situation ? To not re-invent the wheel with external workarounds.

[tormento]

Is QTGMC good to IVTC from 29.97 to 23.976 or is there something better?

[Trixter]

I'm not sure if QTGMC is the best in the world for inverse telecine, but in cases where TIVTC/TFM fail for me (ie. lets combing through), I use this:

QTGMC(Preset="very slow", SourceMatch=3, LossLess=2)
SelectEven()
TDecimate()

This is orders of magnitude slower than TIVTC/TFM but it gets the job done.

[LigH]

QTGMC is a motion compensating deinterlacer, it is not primarily designed for Inverse Telecine. Telecine repeats some fields but does not progress in additional time slices.

Because the original material of telecined video was progressive, inverse telecine is in theory lossless (apart from previous compression loss), therefore every implementation should be sufficient.

Unfortunately, there is some cut and mixed material, the pattern is not always reliable...

[Trixter]

Because the original material of telecined video was progressive, inverse telecine is in theory lossless (apart from previous compression loss), therefore every implementation should be sufficient


I agree every implementation SHOULD be sufficient in theory, but in practice they are not always, due to sources edited after the telecine process (ie. a film transferred to video, then edited on video).

Unfortunately, there is some cut and mixed material, the pattern is not always reliable...

...which is when I turn to QTGMC as the inverse telecine process.

[tormento]

QTGMC is a motion compensating deinterlacer, it is not primarily designed for Inverse Telecine.
I know but I was looking for something better to deal with IVTC, when not perfectly lossless.

RIFE is a no. I don't own a Tensor nVidia card and the plain GPU variation is too slow on my 1660 Super.

[LigH]

As previously mentioned, the default solution should be TFM().TIVTC(); it has several options to handle hybrid material too.

http://avisynth.nl/index.php/TIVTC
https://github.com/pinterf/TIVTC

[tormento]

As previously mentioned, the default solution should be TFM().TIVTC(); it has several options to handle hybrid material too.
Tried it before trying RIFE and it's disappointing both in frame accuracy and in quality. nVidia PureVideo is really accurate and identical in results.

[Trixter]

Tried it before trying RIFE and it's disappointing both in frame accuracy and in quality. nVidia PureVideo is really accurate and identical in results.

I'm starting to think you aren't understanding inverse telecine. You're mentioning all these motionflow tools, and that's not the point of an inverse telecine process. If you have film frames telecined into interlaced material, then you use inverse telecine to recover the original 24fps film footage. RIFE doesn't do this, it's a motion synthesis tool... You're also using wording like "accurate and identical in results" but you're not mentioning what you're comparing the output to, and how you think it's "accurate and identical".

[DTL]

With some not very nice CT processing some original cine frames are more or less badly blended into interlaced fields. So it is really required to do more advanced IVTC in comparison with only good frames picking or combining too good fields in the good frame. So with still possible progress in AI/NN tools we can either see new IVTC tools for better restoration of original cine frames or some non-AI algorithms may be designed like mvtools-based or even non-MC to do partial frames subtraction from 2 cine frames blended fields/frames.

RIFE is only for interpolation - but avs-mlrt as an interface to run some NN models for frames processing may have more ways to solve this. But again we need to find first good working NN model to do this job and convert it into usabe with AVS tools format.

[tormento]

I'm starting to think you aren't understanding inverse telecine.
As DTL pointed, not every IVTC is perfect.

[t_2]

Sorry to break in here, but I think this is the place to ask my silly question.
I used AviSynth 25 years ago and after a long interval am a newbie to AviSynth+. I'm trying to set up QTGMC de-interlacing. I found a guide on YouTube that is great! I'm still having one problem, however. I get an error massage that: "Interleaved2Planer isn't a command." Could any kind soul tell me which plugin/dll/script does that command. Thanks in advance!

[hello_hello]

It's an old function from SSETools (http://avisynth.nl/index.php/RemoveGrain_v0.9/SSETools) and it probably means you're using an old version of QTGMC.

Try this one:
https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.6%20and%20up/QTGMC.avsi
It also requires:
https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi

Or Dogway's updated version (QTGMCp):
https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC%2B.avsi

64 bit version of Avisynth+? There's very few commonly used plugins that don't come in a 64 bit flavour now.

[t_2]

@hello_hello

Thank you so much!! That solved my problem. One more hurtle remains. I can now open my avs script up in AviSynth+ even while invoking QTGMC command. I can also scroll through the video. What an amazing de-interlacer! However, whenever I try to encode the avs of the film, the encoder chokes. HC encoder was nice enough to alert me of the problem.

When I set up QTGMC, I put the QTGMC.asvi script in the “plugins64+” folder along with the other dlls/plugins. However, HC encoder doesn’t like the QTGMC.asvi script that was already in the “plugins” folder of AviSynth+. (I guess that was installed there by default at the time of the AviSynth+ installation.) HC encoder’s error message gets more specific, however. It says that it doesn’t know what “AvsPlusVersion Number” means in line 237 of the QTGMC.avsi file which resides in the “plugin” folder of AviSynth+. Please see below the relevant part of the script.

232 # Dogways Added Defaults
233 RefineMotion = default( RefineMotion, false )
234 lsbd = default( lsbd, false)
235 lsb = default( lsb, false)
236
237 sisphbd = AvsPlusVersionNumber > 2294
238 sbpc = sisphbd ? Input.BitsPerComponent() : 8

Any Ideas about what the problem could be? Thanks in advance for considering this problem!

[hello_hello]

Do you have AvsPmod installed? I aside from it being a great editor and previewer for scripts, it'll always show you the error messages when you try to preview the video.

For the record, Avisynth+ should check the plugins64 and plugins64+ folders for plugins and scripts to load. It's probably just me but I keep scripts in one of them and dlls in the other.
Avisynth+ doesn't install QTGMC or any of it's plugins so I'm not sure how the script appeared in the plugins folder, but anyway, AvsPlusVersionNumber is a function in the Zs_RF_Shared.avsi script I linked to. Did you put a copy in one of the plugins folders? It's functions are used by several scripts.

When you said "I can now open my avs script up in AviSynth+ even while invoking QTGMC", how were you opening it? It's just that I'm not sure why you'd only bump into that error when encoding, rather than each time you use QTGMC. I'd only keep one version of QTGMC in the plugins folders anyway though.

[LigH]

When I set up QTGMC, I put the QTGMC.asvi script in the “plugins64+” folder

That's wrong. The "plugins[64]+" directories should only be filled with plugin DLLs which are originally shipped with AviSynth+ or which are explicitly made exclusively for AviSynth+ and are meant to be there. Generic A/V filter plugin DLLs and import scripts (*.avsi) belong to the directories without the plus in their name.

Yet it should not be "catastrophic" when a DLL is misplaced...

You can use e.g. AvsPmod or VirtualDub2 to open an AviSynth+ script, edit it, and check its behaviour. But this may behave slightly differently when navigating to distant frames and advancing frame by frame, compared to running a whole script sequentially. A good tool to check that behaviour as well is AVSMeter[64]. It can help checking for plugin conflicts of the installed AviSynth[+] environment as such, and it can benchmark your running script while monitoring the RAM demands.

When that exceeds your available physical RAM, Windows may swap to the harddisk which will slow down the processing a lot. Often you can avoid that by limiting the EDIThreads in your QTGMC call. Especially when your CPU has a lot of cores, the number of threads can get squared when you don't limit it, so does the RAM demand.

Also note that the syntax of multithreading changed between AviSynth by SEt and AviSynth+. Test your script with QTGMC([...,] EDIThreads=2) as extra parameter, and with Prefetch(4) as the last command (without or before a possible return), to limit multithreading to a conservative yet useful amount.

PS: The HC encoder was rather old, and to be compatible with the original AviSynth 2.5/2.6, it had to be a 32-bit code application. That means that only the 32-bit version of AviSynth+ (using 32-bit plugin DLLs subsequently) will be used by it.

[hello_hello]

That's wrong. The "plugins[64]+" directories should only be filled with plugin DLLs which are originally shipped with AviSynth+ or which are explicitly made exclusively for AviSynth+ and are meant to be there. Generic A/V filter plugin DLLs and import scripts (*.avsi) belong to the directories without the plus in their name.

Does it really matter if you use the plugins+ folder?
The way I understand it, and maybe it's changed, is that Avisynth+ only auto-loads a plugin if it hasn't already loaded a plugin with the same name, the idea being you could put plugins that only work with Avisynth+ in the plugins+ folder, which it checks first, and plugins that work with classic Avisynth in the plugins folder, which it checks second, so if there's two versions of a plugin with the same name, the version in the plugins+ folder is the one it'll use. If you don't have more than one version of a plugin though, I'm not sure why it'd matter which folder it's in.
The wiki only refers to plugins and not functions, so I don't know if the same rules apply to functions as it's not something I've tested.

[LigH]

I am not sure how much it matters. But I remember it was officially documented once. There is a difference in the handling of plugins IIRC ...

[armyofquad]

All attempts to follow instructions and use this do not work!!!!!

Not once single person seems to be able to explain how to use this, I've looked high and low, nada!!!!

I've downloaded a shitton of garbage to install on my computer, and still nothing but a "there is no function named 'QTGMC'" error!!!!!!

Mind you, nowhere, NOWHERE, does it actually say where I need to save the damn QTGMC.avsi file to. That would be useful information. A shit ton of additional plug-ins to download are listed, but NOOOOO, not something as simple as where in the heck to put the damn tool for it to work right!!!!!


Does anyone know how to write instructions anymore?

[Boulder]

You need the basic Avisynth knowledge to use the tools, and the Wiki is not a bad place to start. A simple search engine search "avsi avisynth" brings you to the correct page.
http://avisynth.nl/index.php/AVSI

[armyofquad]

https://www.dropbox.com/scl/fi/eyxskab0j0qzvopof8qt1/Capture.PNG?rlkey=lhn9iacm9m3e62t4jjdfejweb&dl=0

Sick and tired of a bunch of broken tools that just produce errors.

Please advise.

[armyofquad]

You need the basic Avisynth knowledge to use the tools, and the Wiki is not a bad place to start. A simple search engine search "avsi avisynth" brings you to the correct page.
http://avisynth.nl/index.php/AVSI

Thanks - but this doesn't help.

Every thing I've tried to follow is incomplete and results in errors. No one has written a proper set of instructions for this yet, and that is rather frustrating.

I cannot tell you how many times when asking for advice the answer is "use QTGMC", which is a COMPLETELY USELESS answer when NO ONE can actually tell me how to do that!

Someone please explain already!

[Boulder]

Did you copy-paste and save the raw text as it is? It's a common issue with GitHub (not just Avisynth related thing) that you need to either download the raw file or copy the code from it and not from the preview that it shows you by default.

[armyofquad]

Script error: There is no function named 'sh_getUserGloballMTint'

Please advise.

Please make a version of this that isn't hot garbage!

And I had to hard code the bugged command to return true to get around the broken command!

[armyofquad]

Did you copy-paste and save the raw text as it is? It's a common issue with GitHub (not just Avisynth related thing) that you need to either download the raw file or copy the code from it and not from the preview that it shows you by default.

Scripts look fine, I didn't copy paste any previews.

It's just a hot mess of garbage!

Errors, bugs, nothing works right!

Which is no surprise to me when it requires downloading 20 something different things, instead of one unified application that just works!

Absolutely ridiculous that no one can provide a stable method to get this working!

[Boulder]

I wonder what version you are using as the last one at real_finder's GitHub repo (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.6%20and%20up/QTGMC.avsi) does not contain any calls to that function.

[armyofquad]

I downloaded it today!

[Boulder]

Please post the link, and also post which line the error occurs at.
I guess this is the default branch, which is a little more up-to-date, but still it's not found there. https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/QTGMC.avsi

[armyofquad]

I literally downloaded the link you just posted here, made my troubleshooting change to hard code true to line 237 since no one seems to be able to fix this, and get the exact same results!

Say what you will, but something is calling that function, and it isn't working!

This tool is a hot mess! Please fix it already!

[armyofquad]

Please post the link, and also post which line the error occurs at.
I guess this is the default branch, which is a little more up-to-date, but still it's not found there. https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/QTGMC.avsi

line 380

It's literally right in that line. What do you mean there are no calls to that function, it's right there in line 380

[Boulder]

You had a spelling error in the error message which is why a search at GitHub didn't find any occurrences of it.

You sure you have this helper package installed as well?
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

[armyofquad]

You had a spelling error in the error message which is why a search at GitHub didn't find any occurrences of it.

You sure you have this helper package installed as well?
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

I had that in my downloads folder, but not in my plugin folder - this is such a disorganized mess of a way to have an application work. Not sure how anyone expects anyone to be able to use this, it is very user unfriendly. I suspect the programmer is of the mindset that since it's hard to code, it should be hard to use.

Maybe it's working now, but this was a very unpleasant user experience. This could use some work.

[armyofquad]

Ok, so I have the script working in avspmod.

Now what?

Doesn't seem to be any way to use it.

I try opening it in virtualdub, and it either barks at me about 32bit 64 bit stuff, or barks about a decompressor for p210.


How do you expect anyone to be able to use garbage like this that is incomplete and doesn't do anything on it's own? How am I supposed to be able to figure any of this out?

[Boulder]

Well, this is how most complex functions act whenever they need something else than what the internal Avisynth+ capabilities provide. They have dependencies and it's not meaningful to copy-paste the same helper functions in script files of different functions that use them, because keeping them all updated becomes a pain. real_finder has one collective helper function script which is needed for his custom functions and the rest of the dependencies are plugins so it is as simple as it gets.

[armyofquad]

That doesn't answer my question - now what?


What do I do with this script?


How do I get my video file output?

[Boulder]

I think you should go back and check that your Avisynth+ installation, plugins and related applications are the 64-bit versions if your system is 64-bit or vice versa for 32-bit systems. Any complaints about 32/64-bit mixture mean that this is not the case.

[armyofquad]

I think you should provide instructions to use the script once it's created.

[armyofquad]

It seems virtualdub2 does the trick.

However - the output is jagged, seems to have picked up the fields in the wrong order.

Please advise.

[Boulder]

AssumeBFF or AssumeTFF can be used to change the order reported by Avisynth.

[armyofquad]

Ok, got it.

My output has a framerate of 59.896. Is that to be expected?

[Boulder]

QTGMC bob-deinterlaces so yes, it doubles the framerate by default. There is an option to output at the original framerate and also to apply some motion blurring to make movement appear smoother despite discarding one field.

[rgr]

Ok, got it.

My output has a framerate of 59.896. Is that to be expected?

Should be 59.94fps. Maybe the video is VFR?

[TCmullet]

Let me add my 2 cents to Army's frustration. I'm a "medium experienced" Avisynth user. I just recently jumped into QTGMC usage. Army, this was developed (as best I can discern) by a number of people over time and using other functions that had been created previously by other users (and therefore not a standard part of Avisynth). So it takes a lot of work to gather and install all those functions on which QTGMC is dependent.

Your simplest problem which aggravated you the most (but you've since overcome) was the simple matter of copying any .avsi file you use into the plugins folder. By going forward, you've uncovered that your basic installation of Avisynth may have been flawed, which needs to be (and apparently is being) addressed.

As to QTGMC itself, I did a lot of experimenting with various options to "improve" it, but ended up discarding all options and using it "plain". Of course bobbing from i30 (interlaced 29.97 fps) to p60 (progressive 59.94 fps) was one of the things I wanted anyway. I avoided QTGMC for a long time, but when I saw how smart it was in cleaning up my VHS captures (which I'm just now creating), I realized QTGMC was better than all my manual attempts to clean things up.

I personally stick with 32-bit everything as each time I've tried to "go 64", there are problems.

I'm glad others have PATIENTLY responded to the issues you've been running into. No, Avisynth is NOT user or non-programmer friendly. But I'm retired from a career in programmer, so I understand both sides.

[Boulder]

No, Avisynth is NOT user or non-programmer friendly. But I'm retired from a career in programmer, so I understand both sides.

Being an IT professional for about 20 years now, I know that documentation is the last one finished, and often is left as it was at the very early stages. I can understand that because end users rarely consult them anyway, they like pictures and videos nowadays so it kind of feels like something you do without any real purpose. Also Avisynth has always been a bit of a technical thing whenever you start doing something more complex.

But then again, it's easier for a beginner than Vapoursynth :p

This is where things like ChatGPT can help a lot. Avisynth stuff is all around the Internet and the information does not need to be year 2024-accurate because all the basics are the same as for example five years ago.

[Sharc]

Ok, got it.

My output has a framerate of 59.896. Is that to be expected?
See the comment over at videohelp:
https://forum.videohelp.com/threads/415202-Why-is-there-no-help-on-this-forum-for-QTGMC#post2742199

[TCmullet]

As to QTGMC itself, I did a lot of experimenting with various options to "improve" it, but ended up discarding all options and using it "plain".

I avoided QTGMC for a long time, but when I saw how smart it was in cleaning up my VHS captures (which I'm just now creating), I realized QTGMC was better than all my manual attempts to clean things up.

I thought I'd show what I meant by "discard" and using it "plain". After all the research I did on the zillion options in QTGMC, here was my code that I used initially:
QTGMC(Preset="slow",EdiThreads=4,NoiseProcess=1,NoiseTR=2).prefetch(4)
vsCnr2()
neo_f3kdb()


But after tedious runs and comparisons, I elected to simplify, and I think I have better results when I let QTGMC do all the "smart" work.
QTGMC(Preset="slow").prefetch(4)

[LigH]

Limiting the EdiThreads is in fact useful when you have a lot of CPU cores, because the default number of EdiThreads is related to that, but it multiplies with the number of MT instances (used in Prefetch), so you have {EdiThreads * PrefetchThreads} copies of the EDI plugin running, each needing their own RAM. And NNEDI3 needs quite some more than others.

[Boulder]

It's also important to check if reducing the amount of prefetched frames helps as it's 2*threads by default. It can eat a lot of memory without any actual benefit.

[StvG]

That's wrong. The "plugins[64]+" directories should only be filled with plugin DLLs which are originally shipped with AviSynth+ or which are explicitly made exclusively for AviSynth+ and are meant to be there. Generic A/V filter plugin DLLs and import scripts (*.avsi) belong to the directories without the plus in their name.

Yet it should not be "catastrophic" when a DLL is misplaced...

Not wrong what you wrote but not exactly what's the description of these plugins folders.
https://forum.doom9.org/showthread.php?p=1646304#post1646304
https://forum.doom9.org/showthread.php?p=2004455#post2004455

[Balling]

How much better this is compared to closed source non-free kernel from Intel (MCDI motion compensated and MADI motion adaptive)? You must use https://test.libreelec.tv/13.0/Generic/Generic/ (Kodi set to VAAPI - MCDI) or Kodi on debian testong (does enable non-free kernels on non-free driver but not on MPEG2), same for windows (DXVA deinterlacer just crashes) and same for DXVA2/--vf=d3d11vpp=deint=yes in mpv https://github.com/mpv-player/mpv/issues/15197

Intel driver was fixed for deinterlacer only in August last year. Before that adaptive deinterlacer was broken since at least 2019. https://github.com/intel/media-driver/issues/804

Command to test: https://github.com/intel/media-driver/issues/556

[real.finder]

nhope presets Details link in -Vit- original Thread is dead!
Luckily, I had kept copies of them; I found them on my old laptop's hard drive
so I will put them here as image, with Overdrive80 Tables
https://i.postimg.cc/RhJQnghS/QTGMC-Presets.png (https://postimg.cc/FkmJMg08)

web archive link, just in case
https://web.archive.org/web/20251107000917/https://iili.io/KtP3iUg.png

[tormento]

Luckily, I had kept copies of them; I found them on my old laptop's hard drive
Moderators, please, pin this so we don't need to look for it in a couple of years. ;)

[flossy_cake]

Hey I was benchmarking with AVSMeter and I noticed something strange with multithreading, was wondering if it happens to others


ColorBars().ConvertToYV12().KillAudio() # make something for QTGMC to process
QTGMC(InputType=1, TR2=1, preset="slow").Prefetch(4) # 4 threads



avsmeter64 "C:\MyScript.avs"


Result:

https://i.imgur.com/K9dXWRJ.png

173fps @ 34% CPU utilization. Fine.

Now, if I double the threads to Prefetch(8):

https://i.imgur.com/zNt1bVw.png

200fps @ 80% CPU utilization!?

How is it so? With 2.26x CPU utilization I should expect 173fps * 2.26 = 392fps

Now you might say "oh that's not how it works, it's a rule of diminishing returns" - but look - if I drop threads by half to Prefetch(2), the ratio reduces proportionally:

https://i.imgur.com/LMFMHb0.png

i.e CPU utilization dropped by 47% and fps dropped by 54% - makes perfect sense.

So how come it doesn't scale in the other direction? What is the CPU doing?

By the way I did the same test in ffmpeg command line and got the same result

"c:\program files\ffmpeg\bin\ffmpeg.exe" -i "C:\MyScript.avs" -f null NUL

Very strange as I don't remember having this issue in the past. Or maybe I just wasnt testing properly? Have tried the 3 different MT_MODE's as well

:thanks:

[LigH]

It is not half as strange.

Multithreading does not scale linearly. There is always a bottleneck where one thread needs to wait for the result of others to summarize the partial results, e.g. the management thread to organize the partial tasks. Efficiency will have an optimum, then the performance will saturate.

You should also be aware that the more threads you split the process into, the smaller the scope of each thread may be, so they may miss adjacent spatial or temporal content which could have been used better in fewer threads with a larger scope each.

[flossy_cake]

It is not half as strange.

Multithreading does not scale linearly. There is always a bottleneck where one thread needs to wait for the result of others to summarize the partial results, e.g. the management thread to organize the partial tasks. Efficiency will have an optimum, then the performance will saturate.

Yes what you describe makes sense, and I was aware of such bottlenecks already -- which I was working around by putting other filters in Prefetch(1) -- but the problem was that I could not increase the CPU utilization no matter how many extra prefetch threads I assigned it. Because QTGMC was waiting on other filters, not waiting on things within itself.

My understanding was that if a thread is waiting for another to complete, then it should be using almost 0% utilization, not double the util from 40% to 80% just from "busy waiting" alone!

I am aware there are some applications where the busy wait loop is "active" like with RTSS and that consumes more util, but I would be surprised if Avisynth uses such active waiting loops

[LigH]

Also notice that it may be useful to limit EDIThreads because EDI filters spawn own threads depending on the number of CPU cores if not explicitly limited, which multiplies with the Prefetch threads, and that may result in a lot more threads than desired.

[DTL]

Hey I was benchmarking with AVSMeter and I noticed something strange with multithreading, was wondering if it happens to others
What is the CPU doing?

Possibly stall waiting for read/write requests to complete. Each thread in MT mode attempts to process frames and if single frame size is comparable or larger than CPU cache size it causes great mess at host RAM bus read-write traffic and greatly decreases MT scalability. If you use very small frame sizes (like about CPU_cache_size/number_of_threads divided to 2..3+ to store source and dest frames) it is expected better MT scalability.

With your test results it may mean your script is host (or total memory subsystem) memory performance bound at about 4 threads. So 8 threads adds very few. OS performance counters do not show CPU stalls on read/write instructions waiting to complete - they still show CPU load (they may simply measure thread taking CPU time and at each read/write instruction stall CPU cores do not release time slice to OS because of too much possible overhead on thread switching). So Windows CPU load % performance counter do not really measure CPU compute time only but total time of compute and data transfer from/to memory.

I just finished the first MT working version of new AVS+ filters and filtergraph data processing architecture - it is really times faster in any long filterchain. See this AVS+ core state (New form of Invert() filter and some changes in CacheGuard and Cache core filters) - https://github.com/DTL2020/AviSynthPlus/tree/2a174f751969c9d09b767b0059389fabb81ce112 . The 8 filters (Invert()) with 2500x1000 YV24 frame in a sequence is about 2.8 times faster at a poor 4cores CPU in comparison with AVS+ 3.7.5 release.

But this requires both all compatible filters rewrite (not complex) and also complex filtergraphs still need some thinking on cache design. It is all subject to a great version change to AVS+ 4.0. Not sure how long it will take but some demo is working. Maybe to show some real performance boost we need to first analyse all compatible filters used in QTGMC script. Though core mvtools2 in QTGMC is not compatible with new plane and partial plane granularity data processing modes so total performance boost may be not as great as with simple filterchains of all compatible filters.

[flossy_cake]

With your test results it may mean your script is host (or total memory subsystem) memory performance bound at about 4 threads. So 8 threads adds very few. OS performance counters do not show CPU stalls on read/write instructions waiting to complete - they still show CPU load (they may simply measure thread taking CPU time and at each read/write instruction stall CPU cores do not release time slice to OS because of too much possible overhead on thread switching). So Windows CPU load % performance counter do not really measure CPU compute time only but total time of compute and data transfer from/to memory.

Thanks, will test between CPUs (4790k vs 12600kf) to see how it scales.

Using a wattmeter on the 4790k I'm seeing an 8 watt increase going from 34% > 78% load in those QTGMC tests. At 100% torture load in OCCT only another +10 watts, not sure what to make of that.


Wattmeter measurements 4790k

Idle QTGMC 34% QTGMC 78% OCCT 100%
42w 74w 82w 92w


(4790k is 88w TDP)

[flossy_cake]

Also notice that it may be useful to limit EDIThreads because EDI filters spawn own threads depending on the number of CPU cores if not explicitly limited, which multiplies with the Prefetch threads, and that may result in a lot more threads than desired.

Yep ediThreads was the first thing I played with. It's weird I never see any performance improvement by increasing it so I just leave it at 2, but this is on an ancient system with a 4790k. Will revisit that setting on the newer 12600k.

[Boulder]

Thanks, will test between CPUs (4790k vs 12600kf) to see how it scales.

Using a wattmeter on the 4790k I'm seeing an 8 watt increase going from 34% > 78% load in those QTGMC tests. At 100% torture load in OCCT only another +10 watts, not sure what to make of that.


Wattmeter measurements 4790k

Idle QTGMC 34% QTGMC 78% OCCT 100%
42w 74w 82w 92w


(4790k is 88w TDP)

The CPU utilization and power don't go hand in hand. It also depends on type of load, for example AVX2 instructions will probably need more power (thus, the CPU will run hotter) than regular C code etc.

[hello_hello]

Hey I was benchmarking with AVSMeter and I noticed something strange with multithreading, was wondering if it happens to others

I thought I'd try your script and it confirmed what I already knew. For me, anything greater than Prefetch(12) will probably be a waste of time and possibly even hurt encoding speed, especially when x264 or x265 are using CPU cycles too. For your script it's only a little faster than Prefetch(8) even though Prefetch(8) is almost twice the speed of of Prefetch(4).

My CPU is an AMD 7900x 12 core, running in 105w eco mode to keep the temperature down a little (and because as a rule it makes no difference to encoding speed compared to the standard 175w mode). The maximum operating temperature is 95 degrees. As little as 10% CPU usage can push it up to 70 degrees almost instantly, while at 90 to 100% CPU usage (when encoding) it usually runs somewhere between 80 and 90 degrees.

ColorBars().ConvertToYV12().KillAudio()
QTGMC(InputType=1, TR2=1, preset="slow")
Trim(0, 4999)

Prefetch(4)
https://i.imgur.com/svLIRST.png
Prefetch(8)
https://i.imgur.com/sTWZott.png
Prefetch(12)
https://i.imgur.com/Cb319My.png
Prefetch(16)
https://i.imgur.com/bjYggjZ.png

Edit: I should add.... Avisynth is running in Wine on Linux.

[flossy_cake]

Prefetch(4)
https://i.imgur.com/svLIRST.png
Prefetch(8)
https://i.imgur.com/sTWZott.png
Prefetch(12)
https://i.imgur.com/Cb319My.png
Prefetch(16)
https://i.imgur.com/bjYggjZ.png



Thanks for the feedback - seems like it's normal behaviour then? Somewhere around 8-10 threads for your CPU seems ideal fps per watt if I'm reading that correctly at a glance.

I'll do some testing with a 12600k tomorrow, I am expecting around 6-8 to be optimal for that CPU. The way I figure it the wattmeter is the ultimate arbiter - if it's drawing more watts then it's indeed doing more work. And watts = heat.

[DTL]

Prefetch(12)
https://i.imgur.com/Cb319My.png


Can you test big prefetch threads count with different memory settings (timings and/or frequency and/or channels number) if possible ?

My test shows AVS+ filterchains are very sensitive to memory performance when all CPU cores busy with filters computing - https://forum.doom9.org/showthread.php?p=2024941#post2024941 . Optimization of workunit size for fastest caches (L1) in a filterchain looks like can add performance to 100s %.

[hello_hello]

I happened to have run a few tests recently, because I was having an issue with the PC randomly rebooting, which became more frequent and eventually evolved into the PC simply shutting down.
I still don't know what the problem was. I thought the motherboard had died as after one shutdown it refused to boot up again. I disconnected everything attached to the MB, thinking maybe it was due to a failing drive or RAM module etc, but I didn't find any problem hardware, and after I reconnected everything again the PC booted normally and it's been running fine for a couple of weeks now.

While I was experimenting to see if maybe a RAM module was the culprit. I ran test encodes with the RAM running at the default speed, and then again with Expo enabled in the BIOS, which if I remember correctly is 4800 MT/s vs 5600 MT/s for my RAM. The script I used for testing was one I'd been using to encode a 1080p video with x265 at the time. I can't remember exactly what it contained, but it would have used Prefetch(12) and no doubt included some sort of denoising with MVTools. Very likely with TemporalDegrain2 or QTGMC doing the denoising. I still have the text file where I noted the encoding times. For 5000 frames the difference in total time was roughly 25 seconds. More than I expected.

RAM running at 4800 MT/s

x265 [info]: frame I: 39, Avg QP:17.29 kb/s: 14700.78
x265 [info]: frame P: 1252, Avg QP:19.22 kb/s: 8844.25
x265 [info]: frame B: 3709, Avg QP:25.31 kb/s: 1944.94
x265 [info]: Weighted P-Frames: Y:7.1% UV:4.9%
encoded 5000 frames in 299.56s (16.69 fps), 3772.02 kb/s, Avg QP:23.72

RAM running at 5600 MT/s

x265 [info]: frame I: 39, Avg QP:17.29 kb/s: 14700.78
x265 [info]: frame P: 1252, Avg QP:19.22 kb/s: 8844.25
x265 [info]: frame B: 3709, Avg QP:25.31 kb/s: 1944.94
x265 [info]: Weighted P-Frames: Y:7.1% UV:4.9%
encoded 5000 frames in 273.28s (18.30 fps), 3772.02 kb/s, Avg QP:23.72

As a side note, I compared the default CPU mode to 105w eco mode with all other BIOS settings left at their optimized defaults. It was a fairly warm day, so even though the CPU is water cooled, in default mode it ran at it's maximum temperate of 95 degrees. 105w mode reduced the temperature by at least 10 degrees, but not so much the encoding speed.

Default CPU mode.

x265 [info]: frame I: 56, Avg QP:17.44 kb/s: 9362.94
x265 [info]: frame P: 1229, Avg QP:19.09 kb/s: 4364.02
x265 [info]: frame B: 3715, Avg QP:25.37 kb/s: 1232.94
x265 [info]: Weighted P-Frames: Y:5.5% UV:4.8%
encoded 5000 frames in 266.60s (18.75 fps), 2093.61 kb/s, Avg QP:23.74

105w eco mode.

x265 [info]: frame I: 56, Avg QP:17.44 kb/s: 9362.94
x265 [info]: frame P: 1229, Avg QP:19.09 kb/s: 4364.02
x265 [info]: frame B: 3715, Avg QP:25.37 kb/s: 1232.94
x265 [info]: Weighted P-Frames: Y:5.5% UV:4.8%
encoded 5000 frames in 266.76s (18.74 fps), 2093.61 kb/s, Avg QP:23.74

[DTL]

Good results. About 1.16 ratio memory frequency make about 1.1 ratio of fps increase. >50% proportional. As I remember at many general usage applications memory benchmarks we have much smaller proportion.

From what I see in QTGMC - many parts of filterchains can benefit from new processing modes. At least parts of mvtools - MCompensate and MDegrainX. Also may be mask tools and some other filters. The MAnalyse with chroma=true mostly probably not.

[flossy_cake]

I just wanted to say QTGMC(InputType=1, TR2=1, sharpness=0.2) is the best denoising and antialiasing filter I've ever seen and I'm really smitten with it. It's so gosh darn effective at cleaning up other people's trash encodes without smudging, blurring, airbrushing and Vaselineing everything to heck that I sometimes cannot believe it's even theoretically possible given the usual rule of "rubbish in rubbish out".

Of course it's not perfect, the smoothing is definitely visible in a way that you can sort of "feel" its presence even when not consciously scrutinising the image. But it's nowhere near the amounts of smoothing you get with InputType=2 or InputType=0, and/or higher values like TR2=2 or 3 which I am not comfortable with from a "videophile" type perspective. I have dabbled with TR2=2/3 for some especially trashy encodes and it did help clean the image up further, but the airbrushed look started creeping in a bit too much for my liking.

So the golden combo imo is InputType=1, TR2=1, sharpness=0.2. I am very confident of that sharpness value too. I can see that value of 0.2 is mentioned in the documentation as the default for Source Match mode. Coincidence? I think not.

And the icing on the cake: it's light on the the CPU *chef's kiss*

So a huge thanks to the guys who worked on it, you've done a great job with this filter :thanks:


late edit: forgot to mention, another important setting I like to use is Rep0=13 which controls the motion artefact repair. For animation I definitely need this setting to prevent motion artefacts on black character outlines otherwise there can be some frameblending type artefacts on moving parts of the image of certain frames (see Family Guy screenshots here (https://forum.doom9.org/showthread.php?p=1999882#post1999882)).

On camera based content it also seems to match more closely the original image in terms of geomertric shapes of objects, example: original (https://i.imgur.com/dPluA4p.png) , rep0=default (4) (https://i.imgur.com/nipCTRd.png) , rep0=13 (https://i.imgur.com/Xjv1OtP.png) (this is a very trashy low bitrate source and there is camera motion. Note for the rep0=default setting the actor's face on the left is blurred and geometrically distorted downwards, and the horse's ear is tweaked upwards vs the original/rep0=13)

[DTL]

If you get more blur with increasing TR2 only - you can try to set thSAD (thSAD2 for TR2 as I see) settings to lower values. It looks internal default of thSAD2 is 4x8x8=256. So may try to set below 256 (down to 120 and less). Increasing of tr generally good to get more blocks in averaging but make processing (much) slower. And after adjusting performance to acceptable level with TR2 you can try to set balance between noise reduction and blur with thSAD2 value. Also you need to manually adjust thSAD2 for each noise level in each footage. It is enough sensitive adjustment with steps about 10..20 may be visible in balance of noise/blur.

[flossy_cake]

If you get more blur with increasing TR2 only - you can try to set thSAD (thSAD2 for TR2 as I see) settings to lower values. It looks internal default of thSAD2 is 4x8x8=256. So may try to set below 256 (down to 120 and less). Increasing of tr generally good to get more blocks in averaging but make processing (much) slower. And after adjusting performance to acceptable level with TR2 you can try to set balance between noise reduction and blur with thSAD2 value. Also you need to manually adjust thSAD2 for each noise level in each footage. It is enough sensitive adjustment with steps about 10..20 may be visible in balance of noise/blur.

I see, I will need to experiment with that.

One of the hardest things I find is getting the sharpness right especially for low-res content. Because every display has a different sharpener (or none at all) so what I see at close distances on a PC monitor is different to what I see on my S90D at further distances. And there's no industry standards for sharpness either, the standard is something like putting up a sharpness test pattern and looking for ringing , but then we have deringing filters and LimitedSharpen/AdaptiveSharpen which can add as much sharpening as you like without any ringing so ultimately you kind of have to eyeball it and keep asking yourself "is the image too sharp or too blurry?". And then your eyesight starts to go blurry after too many hours of eyestrain from looking at the screen. And then after mpeg encoding the sharpness changes again. So I find this very difficult and sometimes I felt the need to go above sharpness 0.2 but when compared with the original it is definitely adding sharpness that wasn't there so 0.2 definitely the right default. And then if it's low bitrate maybe 0.3 or alternatively LimitedSharpenFaster(10) but then that adds more compression artefacts

[flossy_cake]

Does anyone else feel that maybe Samsung TV's have some kind of persistent low strength temporal noise reduction filter similar to QTGMC(InputType=1) but weaker?

[DTL]

Adjusting of thSAD is not about loss of sharpness directly (at the transients) - it is about losses of detailes of textures from bad blocks blends from wrong motion compensation. It is harder to restore with sharpeners after details loss and the details loss is not linear over the frame. Where motion compensation is correct you can have very high thSAD value without degrading of textures. And where it is no good - the thSAD is some sort of protection against too bad blends causing details (and sharpness) loss. But it can not do too much magic and if set too low it will pass also most of noise to output.

[Emulgator]

Does anyone else feel that maybe Samsung TV's have some kind of persistent low strength temporal noise reduction filter similar to QTGMC(InputType=1) but weaker?

Similar algos are implemented everywhere across all manufacturers, sharing a choice of few chipset families anyway.
Found this with 2004..2018's Samsung, Sony, Panasonic, LG.
One has to switch them off on purpose to get to the real source texture,
and sometimes I feel as if a bit processing stays in anyway, hidden as "MPEG Artifact Removal" or whatever the wording may be.

[Didée]

You may call me paranoid or seeing things that are not there. But I've had the imression that, back in a time when TVs internal deinterlacers were not yet so great, TGMC popped up here, and one or two years later those deinterlacers suddenly got much better!? :D

[LigH]

:thanks:

Hail thee, scripting magician!

And I agree, deinterlacing algorithms developed also in high level languages for compilers to binary releases. Even in GPU shaders.

[rgr]

Does anyone else feel that maybe Samsung TV's have some kind of persistent low strength temporal noise reduction filter similar to QTGMC(InputType=1) but weaker?

Like every manufacturer.
"Game Mode" disables most, if not all, of these enhancers.

[flossy_cake]

Like every manufacturer.
"Game Mode" disables most, if not all, of these enhancers.

Yeah I use game original mode for all SDR content on the S90D and i still think there is some temporal filtering. Some kind of "Samsung special sauce" going on. I don't mind it though. also the other day I discovered S90D even in game mode has a persistent debanding filter that kicks in for the 0-10 stimulus range when a grey ramp is displayed at a specific size, direction or zoom level. I can literally zoom the grey ramp in and out and watch the tones "pop" from native steps to smoothed steps at the threshold. I suspect the reason they do it in a horizontal direction is because of the panel uniformity issue with vertical lines on oleds at low stimulus which exacerbate banding in the horizontal direction, because if I display the grey ramp vertically i can zoom in and out and pan through the gradient and it's always native, smooth and not debanded.

[rgr]

Yeah I use game original mode for all SDR content on the S90D and i still think there is some temporal filtering. Some kind of "Samsung special sauce" going on. I don't mind it though. also the other day I discovered S90D even in game mode has a persistent debanding filter that kicks in for the 0-10 stimulus range when a grey ramp is displayed at a specific size, direction or zoom level. I can literally zoom the grey ramp in and out and watch the tones "pop" from native steps to smoothed steps at the threshold. I suspect the reason they do it in a horizontal direction is because of the panel uniformity issue with vertical lines on oleds at low stimulus which exacerbate banding in the horizontal direction, because if I display the grey ramp vertically i can zoom in and out and pan through the gradient and it's always native, smooth and not debanded.

Maybe this is just the effect of the Samsung upscale filter?

[Emulgator]

You may call me paranoid or seeing things that are not there. But I've had the imression that, back in a time when TVs internal deinterlacers were not yet so great, TGMC popped up here, and one or two years later those deinterlacers suddenly got much better!?
I am feeling the same, hihi. Somebody read up here from the Master, maybe ?

[Sharc]

I am feeling the same, hihi. Somebody read up here from the Master, maybe ?
Remember Faroudja? Was a kind of game changer as well for TV deinterlacers.

[johnmeyer]

Remember Faroudja? Was a kind of game changer as well for TV deinterlacers.Not only do I remember it, but I flew from San Jose to Las Vegas back in the early 1990s just to go to their suite and see their $15,000 line doubler. I did this because I was hanging around with people who were trying to create the "ultimate" home theater back in the early 1990s and they were planning to get an $80,000 Barco projector, a laserdisc player, and the Faroudia line doubler. I couldn't believe it would make that much difference but, given how marginal NTSC video looked like on a big screen, after seeing the demo at their hotel room suite, it did actually make a pretty big difference.

I never got one ... a little too rich for my blood.

[Sharc]

Not only do I remember it, but I flew from San Jose to Las Vegas back in the early 1990s just to go to their suite and see their $15,000 line doubler. I did this because I was hanging around with people who were trying to create the "ultimate" home theater back in the early 1990s and they were planning to get an $80,000 Barco projector, a laserdisc player, and the Faroudia line doubler. I couldn't believe it would make that much difference but, given how marginal NTSC video looked like on a big screen, after seeing the demo at their hotel room suite, it did actually make a pretty big difference.

I never got one ... a little too rich for my blood.
Legendary Faroudjas statement at an IBC 2004 session:
“I am amazed that anybody would consider launching new services based on interlace. I have spent all of my life working on conversion from interlace to progressive. Now that I have sold my successful company, I can tell you the truth: interlace to progressive does not work!”. :)

[johnmeyer]

Legendary Faroudjas statement at an IBC 2004 session:
“I am amazed that anybody would consider launching new services based on interlace. I have spent all of my life working on conversion from interlace to progressive. Now that I have sold my successful company, I can tell you the truth: interlace to progressive does not work!”. :)I agree with half of that twenty-year-old quote. I agree that interlace to progressive does not work, and it is why I've spent 20+ years in this forum advising people to NOT deinterlace unless they have to.

However, interlacing exists for a reason. That reason existed in the 1930s and 1940s when TV was being invented. It existed when the world transitioned from HD to SD starting in the late 1990s. And it still exists today.

The reason? Cost. Interlacing was a brilliant engineering solution to the economics of creating, transmitting, receiving, and viewing an image that would be pleasing to watch, but at a cost that "the masses" could afford. It provides the fluidity of 60 fps, but in half the bandwidth. The implications for broadcast bandwidth (in the analog era), the cost of the TV receiver, and the cost of almost every other aspect of television engineering was, and is, massive.

Now that video is almost entirely streaming, with OTA broadcast, cable, and satellite TV on the inevitable decline to obscurity, the economics of bandwidth still remain. However, because frame rates are no longer fixed, the current solution to the bandwidth/cost problem is to simply degrade the frame rate, as we see everyday in videoconferencing, and often see in streaming services.

As a result, I would not have agreed, in 2004, that it would be crazy to introduce a service that was interlaced. The economics still favored that approach and indeed, when I got my first HD set in 2012 (yes, rather late), I noticed that most of the OTA and cable program material was either 720p or 1080i. Almost nothing was 1080p. Interlace was still widely used, long after his quote.

[Didée]

It existed when the world transitioned from HD to SD starting in the late 1990s.
In that sentence, swap HD<>SD, methinks that's the correct order. ;)

In excuse for the general idea of "interlacing" -- it must be considered that back in that time, we only had CRT displays that inherently built up the image in an interlaced technique. That's why it made perfectly sense back in those times. In our modern times of progressive displays, of course interlacing should be considered an artificial relict ... but I think this has been discussed sufficiently in the past. It is like it is, some bad habits will stay forever.

[DTL]

Fast and UHD new displays can simulate interlaced scan good enough. Some convert script of SD interlaced to UHD progressive may be created with AVS. But for better simulation of CRT field fade it need 100..200+ fps output for 25i input.

[hippo88]

I tried to encode a .ts video (interlaced top field first) captured from TV into mp4 to 1080p with qtgmc setting = medium. The encoded video using megui x64 is slightly jerky when played on TV. But when I encode to 720p it plays fine. Does anyone know why. I tried with staxrip same result

[Trixter]

Inspect the output file (ffprobe, mediainfo, etc.) to ensure it really is 50/60p. If it is 25/30p, it will feel "jerky" when played. Ensure that megui or staxrip isn't cutting the framerate in half.

Try swapping the field order in case the fields are wrong. Put AssumeBFF() before QTGMC().

[hippo88]

Inspect the output file (ffprobe, mediainfo, etc.) to ensure it really is 50/60p. If it is 25/30p, it will feel "jerky" when played. Ensure that megui or staxrip isn't cutting the framerate in half.

Try swapping the field order in case the fields are wrong. Put AssumeBFF() before QTGMC().

I tried both, AssumeBFF & AssumeTFF video still jerky. It played fine on mpc on the pc. I have an older 1080 Samsung tv. I wonder if this is the problem.
Thank you for for your suggestion.

[wonkey_monkey]

I have an older 1080 Samsung tv. I wonder if this is the problem.

I think that's quite likely. I'm sure my old Samsung could only properly handle 1080i25/30, not 1080p50/60.

If you're playing over a network it could also be that it only has a 10mbit/s NIC and your 1080p file has too high a bitrate. It may also not support high USB speeds.

[hello_hello]

I tried to encode a .ts video (interlaced top field first) captured from TV into mp4 to 1080p with qtgmc setting = medium. The encoded video using megui x64 is slightly jerky when played on TV. But when I encode to 720p it plays fine. Does anyone know why. I tried with staxrip same result

The manual for my 2011 Samsung says it supports Level 4.1, although it also says 30fps is the maximum for 1080p.

It can play video at 50fps or 60fps if the resolution is lower, but it doesn't like long gops. If I remember correctly MeGUI adjusts x264's --keyint according to the frame rate, so for 60fps it'd probably set --keyint 600. The default for x264 is --keyint 250. If you try encoding at 1080p while making sure the keyint option is the default of 250, you might get lucky and find it'll make a difference.

[DTL]

Updates for versions v3.389s and v3.390s :

Params 'trymany' and 'temporal' for MAnalyse can be sent via QTGMC params. May be enabled to check for better quality.

Params thSAD, search and searchparam for MRecalculate may be separately controlled via RefineMotionAll, RefineMotionSearch, RefineMotionRadius.
RefineMotionRadius expected to be > SearchParam for the first MAnalyse search to get better results.
With RefineMotionAll set to true - sets MRecalculate thSAD to 0 and forces a refine search of all newly created smaller blocks with RefineMotion=true. With default thSAD for MRecalculate (1/2 of thSAD for MAnalyse ?) it looks many blocks are not refined but only interpolated for new MVs. At least at the not very noisy footage.

Also found PNew for TrueMotion=true internally defaulted to 50 and it may be too high (at least for MRecalculate stage and for not very noisy footage). Checked value of 5 at the PAL DVCAM footage (low noise pro camera) and it saves more fine details at the fast complex motion (water). With high PNew many better MVs are skipped and this makes final refine-search with MRecalculate less effective.

[real.finder]

Fast and UHD new displays can simulate interlaced scan good enough. Some convert script of SD interlaced to UHD progressive may be created with AVS. But for better simulation of CRT field fade it need 100..200+ fps output for 25i input.

you can try https://forum.doom9.org/showpost.php?p=2029962&postcount=74

it work with 480i/576i –> 1080p (or higher) and 60hz/50hz, you can encode it with x264 since it slow, using crf 16 or less (better) is ok

[DTL]

Some new idea how to make alternative MVs search version with current stable mvtools and prepare for the new SIMD updates of the slow esa search method - https://forum.doom9.org/showthread.php?p=2030228#post2030228

Also some note to check about presets: Preset placebo uses search 5 (umh ?) but I found it greatly worse in quality in comparison with 2 or 3 or 4. May be it was put to make performance a bit better but it may degrade quality. For placebo preset may be recommended some search modes from 2 to 4 (or at least left 4 as with most other presets).

[DTL]

Tried several (4) different attempts to upgrade existing exhaustive search (search=3) but they make very few quality additions. Though still not look how is the tesa search in x264 designed. Also the internal all levels search is exhaustive search in most of recent (and current) versions of mvtools so still no need to control it via separate searchcoarse param (if better quality required).
One more found limitation from the old ages of slow CPUs (or may be from SVP for realtime at old CPUs) - trymany algorithm (refining around all predictors and selecting best of the best) was disabled at finest level for better performance and no external control exist via MAnalyse params.
Also pinterf made an update to v.2.4.47 with fixes around multithreading.
So new build for experiments with better quality with trymany=true - https://github.com/DTL2020/mvtools/releases/tag/post_r.2.7.47_822_1 . Based on 2.7.47 release sources (commits up to 822 by pinterf).
Performance hit is visible:
With params
QTGMC(preset="slower", trymany=true) and x264 encoding of DVCAM/PAL footage at i5-9600K CPU (crf=5 to check fine difference)
trymany - only coarse levels: 29.1 fps 42649 Kbit/s
trymany - all levels including finest: 24.6 fps 42669 Kbit/s

[real.finder]

new update:- add new PhosphorSoft bool parameter to make QTGMC less aggressive, Especially in Anime/Cartoon