SVP-like frame interpolation?

[burfadel]

Final result
https://s12.postimg.org/oyl4gmds9/91auto.png

Would there be a way to do a mask to avoid the artifact of certain types of motion, as seen to the top left of the girls shoulder? If you have a edge mask of the non-motion interpolated frames, and one of the motion-interpolated frame, you could do a motion analysis on them. The artifacts would shown as additional information in the edgemask, in which case the original frames information can be used instead of the interpolated frame. Or at least, a principle based on this concept?

I guess it's similar to stripemask, where you resolved the artifact in the fence.

However, compared with:

Frame 91, Interpolated image
https://s12.postimg.org/xxfs7e821/91flow.png

The remainder of the fence looks like it has motion distortion. Wouldn't that be unfavourable? Would it be possible to only apply the stripemask to the area where the artifact was created?

[MysteryX]

hum... I see what you're saying... if the StripeMask is still in an area, then it means it has no artifact. When artifacts appear, it means the stripes are broken.

I think you're onto something.

I was also thinking of a way of generating a mask of continuous areas in a way that would preserve more precise borders. A filter that combines unidirectional blur and binarize. Take the average of x pixels in a certain direction, and if the average is above a treshold, include that pixel in the mask. Repeat in all 4 directions.

[MysteryX]

New version 2017-05-28! (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.3-alpha)

hum... I see what you're saying... if the StripeMask is still in an area, then it means it has no artifact. When artifacts appear, it means the stripes are broken.
I've tried it and had no luck with it. The results are too erratic and inconsistent. It looks better to blend the whole fence, and while animated, you barely see it.

I have created a new filter ContinousMask. It turns [left] into [right]
https://s29.postimg.org/ns3te0pr7/Continuous_Mask1.png (https://postimg.org/image/ns3te0pr7/) https://s29.postimg.org/3m0bf4u3n/Continuous_Mask2.png (https://postimg.org/image/3m0bf4u3n/)

You specify a radius, and it takes [radius] pixels to the right, to the left, to the top and to the bottom and makes the average of them in the output. It only processes pixels that have a value > 0 in the source. Perfect for detecting continuous areas! Then you just have to call mt_binarize.

Using that, I've edited the stripe masking to cover the fence more precisely. Barely any artifact is making it through. So far it looks great, but it might require a bit more testing to see if it sometimes gives false positives, it maybe can be tweaked some more. You can also test this vs the last version.

[MysteryX]

StirpeMask will now work in Linear Light (2.2 gamma correction) which gives more consistent results. Adding high-bit-support, will release after a few other things are fixed.

Script updated. Stripes are now covered with no blending as it looks better. Stripes don't look good even with blending. It however causes artifacts at the junctions of no-blend zones but they're precise enough so that it doesn't do too much such artifacts. Also added Stripes argument to enable/disable stripe masking (default=true).

[MysteryX]

New version: 2017-05-30 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.4-alpha)

In this release, stripes detection is now done in linear light which results in more accurate detection across the spectrum. Added parameter Stripes to specify how to mask stripes: 0=disabled, 1=skip, 2=blend (default=1)

I'm leaving to California for the next 5 days so won't be giving updates until I'm back. This is a good time to test it. Send me positive vibes and wish me luck.

Edit: release updated with a fix for ContinuousMask's 16-bit support. Now it should work in 8 or 16-bit. What's not yet working in 16-bit is ConditionalFilterMT with AverageLuma that needs to be normalized. The normalization code is there but it isn't being called somehow.

Edit: release updated again. 16-bit mode now working 16-bit mode now working (except that debug won't display normalized values, but result will be good)

[Sharc]

No luck here. Crashes for "slower", stripes=1 or stripes=2, after few frames:
- for Stripes=1: Softwire: caught an access violation at 0x1390e25b(code+83)', attempting to read from 0xfffffff [ScriptClip], line 7
- for Stripes=2: MVTools: invalid vector stream, [Script Clip], line2
Single threaded, avisynth 2.6

Enjoy your trip to California :)

[MysteryX]

No luck here. Crashes for "slower", stripes=1 or stripes=2, after few frames
!?

It works perfectly fine here. Perhaps try with AVS+?

What's even more strange is that you're getting a crash on MVTools2 "MVTools: invalid vector stream"

[Sharc]

Perhaps try with AVS+?
Yep! All ok with AVS+. Thanks.

For comparison:
http://www.mediafire.com/file/3k7x9tpk71n6ve8/FRC_comparison6.mkv
This difficult clip is getting better and better. The bottom left picture (slower, other settings default) looks very good (stepping through frames and watching real-time)

[burfadel]

I get an error that there is no function named 'StripeMask' with the latest build. I believe there is an error with the dll's, they're practically identical! Only a few lines difference and 1 byte between the x64 and 32-bit DLL's when doing a file compare. With the 28 May version the DLL payload and file sizes are quite different as you would expect between 32-bit and 64-bit. It seems the 64-bit version of the 30 May buld is the 32-bit code, maybe at a slightly different commit because they aren't identical.

Here are the differences:
Comparing files FrameRateConverter.dll and FRAMERATECONVERTER-X64.DLL
***** FrameRateConverter.dll
L
¦Í-Y

***** FRAMERATECONVERTER-X64.DLL
L
BÍ-Y

*****

***** FrameRateConverter.dll

¦Í-Y

***** FRAMERATECONVERTER-X64.DLL

BÍ-Y

*****

***** FrameRateConverter.dll

¦Í-Y

***** FRAMERATECONVERTER-X64.DLL

BÍ-Y

*****

***** FrameRateConverter.dll

¦Í-Y

***** FRAMERATECONVERTER-X64.DLL

BÍ-Y

*****

***** FrameRateConverter.dll

¦Í-Y

***** FRAMERATECONVERTER-X64.DLL

BÍ-Y

*****

***** FrameRateConverter.dll

RSDSxOvûâ5H*;S`*hG

***** FRAMERATECONVERTER-X64.DLL

RSDSxOvûâ5H*;S`*hF

*****

***** FrameRateConverter.dll

¦Í-Y

***** FRAMERATECONVERTER-X64.DLL

BÍ-Y

*****


So yes, something drastically wrong there! The 28 May x64 DLL works fine in its place for normal use, but obviously would be preferable to use the correct version.

[Groucho2004]

I get an error that there is no function named 'StripeMask' with the latest build. I believe there is an error with the dll's, they're practically identical! Only a few lines difference and 1 byte between the x64 and 32-bit DLL's when doing a file compare. With the 28 May version the DLL payload and file sizes are quite different as you would expect between 32-bit and 64-bit. It seems the 64-bit version of the 30 May buld is the 32-bit code, maybe at a slightly different commit because they aren't identical.


The DLLs are both x86 from the same source. Minor differences will always be there because the linker puts a time stamp in the image. Therefore, using fc (or whatever binary compare tool you used) is pointless in this case.

Also, you can easily check this with AVSMeter:
[Avisynth info]
VersionString: AviSynth+ 0.1 (r2489, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: D:\WINNT\system32\avisynth.dll
Avisynth.dll time stamp: 2017-05-29, 09:04:37 (UTC)
PluginDir2_5 (HKLM, x64): E:\Apps\VideoTools\AVSPlugins\AutoLoad64
PluginDir+ (HKLM, x64): E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins


[CPP 2.5 / 64 Bit plugins]
E:\Apps\VideoTools\AVSPlugins\AutoLoad64\flash3kyuu_deband.dll

[CPP 2.6 / 64 Bit plugins]
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\ConvertStacked.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\DirectShowSource.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\ImageSeq.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\Shibatch.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\TimeStretch.dll [2.2.6.0]


[Plugin errors/warnings]
______________________________________________________

Error loading "E:\Apps\VideoTools\AVSPlugins\AutoLoad64\FrameRateConverter-x64.dll"
Cannot load 32 bit DLL with 64 bit Avisynth
______________________________________________________

[burfadel]

The DLLs are both x86 from the same source. Minor differences will always be there because the linker puts a time stamp in the image. Therefore, using fc (or whatever binary compare tool you used) is pointless in this case.

Also, you can easily check this with AVSMeter:
[Avisynth info]
VersionString: AviSynth+ 0.1 (r2489, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: D:\WINNT\system32\avisynth.dll
Avisynth.dll time stamp: 2017-05-29, 09:04:37 (UTC)
PluginDir2_5 (HKLM, x64): E:\Apps\VideoTools\AVSPlugins\AutoLoad64
PluginDir+ (HKLM, x64): E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins


[CPP 2.5 / 64 Bit plugins]
E:\Apps\VideoTools\AVSPlugins\AutoLoad64\flash3kyuu_deband.dll

[CPP 2.6 / 64 Bit plugins]
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\ConvertStacked.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\DirectShowSource.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\ImageSeq.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\Shibatch.dll
E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\TimeStretch.dll [2.2.6.0]


[Plugin errors/warnings]
______________________________________________________

Error loading "E:\Apps\VideoTools\AVSPlugins\AutoLoad64\FrameRateConverter-x64.dll"
Cannot load 32 bit DLL with 64 bit Avisynth
______________________________________________________



Ah ok! True. Either way, it shows the DLL is wrong. AVSmeter of course saying it directly.

Just in time for MysteryX's five day's away!

[MysteryX]

Just in time for MysteryX's five day's away!

DLL updated (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.4-alpha)

From LAX airport

[MysteryX]

New version 2017-06-05 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.5-alpha)

What's new:
- ContinuousMask no longer counts center pixel twice
- StripeMask threshold raised from 22 to 25 (after adding gamma correction)
- FrameRateConterter Stripes parameters is now [none|skip|blend]
- Stripes masking has higher blur radius when Stripes=skip, looks better
- Added Output=stripe to view the stripes mask

The parade clip triggers minor stripes masking in a few scenes. With Stripes=skip, it just looks great; can barely notice the mask at all

[MysteryX]

I just tried with Avisynth 2.6 and am not getting any crash. However, the results is different for some reason. The parade clip has issues with the crowd by the car, and it appears worse in Avisynth 2.6.

[MysteryX]

Raised StripeMask Trh from 25 to 26 and the parade crowd now looks fine. Updated release.

[Sharc]

Hmmm... I found the version of 30-May with skip=1 better (less artefacts for the fence) for the clip with the girl on the bike.....

[MysteryX]

There is a bug in this build, will release another one

[MysteryX]

New version (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.5.1-alpha)

What's new:
- ContinuousMask now counts central pixel twice again
- Increased ContinuousMask search radius from 18 to 20
- Increased Stripe Mask mt_expand from 8 to 12 when Stripes="skip"

[Sharc]

Comparing with version of 30-May I'd say that some frames are better, some are worse.....
But in any case it looks good. The improvements compared to the early versions are significant :)

[MysteryX]

I increased the blurring radius to remove "hard cuts"; perhaps it could be tweaked some more.

[MysteryX]

I see what you're saying about May 30th version giving better output.

New version: 2017-06-07 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.6-alpha)

Try this version. I had to tone down the settings a little bit so that the parade crowd doesn't get distorted -- it's tweaked on a fine line so that the fence looks good and the parade is excluded.

[Sharc]

It looks good now.
Question is perhaps how much is it tuned for the selected clips (fence, parade), or whether the current version/optimization is generally good for other clips as well....

[MysteryX]

It looks good now.
Question is perhaps how much is it tuned for the selected clips (fence, parade), or whether the current version/optimization is generally good for other clips as well....
Test it and let me know. It should be mostly good, and by testing with a variety of other videos, we can fine-tune settings further.

For example, after adding stripes masking and detecting after gamma correction, it might be possible to increase the blend over threshold.

[MysteryX]

I'm making tests with other videos. Stripes masking tends to trigger on parts of subtitles; which isn't bad since artifacts tend to show up around the text. However, "skip" doesn't look good when applied randomly in such places. "skip" is better in the clip you posted with large fences, but in most cases, "blend" looks better and is safer. Thus, I'll change Stripes default to "blend". I'm also changing another settings in StripeMask, Comp default for blksize=16 will be 2 instead of 3 (comparing 2 pixels to detect contrast changes instead of 3 for blksize>16)

For the most part, things are looking great.

[MysteryX]

New version: 2017-06-08 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.7-alpha)

Several tweaks:
- StripeMask's comparison width is now 2 instead of 3 for blksize=16
- BlendOver default raised from 50 to 60
- Stripes default changed from "skip" to "blend" -- safer
- Output=over now displays stripes mask as yellow (and artifact mask as cyan)
- Debug now displays Diff and Stripe values, and 4 digits instead of 6 digits
- Works correctly in 16-bit mode while maintaining compatibility with AVS 2.6 (debug mode still doesn't work correctly in 16-bit)

[MysteryX]

Here's an encode of a full sample video (difficult case with strong artifacts). It's part of a script that denoises and upscales from 288p into 768p.

Source (https://www.spiritualselftransformation.com/files/media-encoder-old.mpg)

Previous results with InterFrame (https://www.spiritualselftransformation.com/files/media-encoder-new.mkv)

Current results with FrameRateConverter in YV24 (https://mega.nz/#!iEAwFAaL!WzWjT5CllT9YlCxT9iJxcwEB4pbOptEEC5nXCKo9Zi0)

There are some artifacts with the lights near the beginning, but everything else is perfect. The quality is drastically higher than my previous results!!

Here's the script I'm using

file="Meu-Ayw-Tua-Lae-Tur.mpg"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Crop(0, 0, -8, -0)
ConvertBits(16)
ConvertToYUV444(chromaresample="Spline36", ChromaInPlacement="MPEG1")
ConvertToStacked()
KNLMeansCL(D=2, A=2, h=1.5, channels="YUV", device_type="GPU", device_id=0, lsb_inout=true)
ConvertFromStacked()
SuperResXBR(5, 1, 0, XbrStr=2.6, XbrSharp=1.3, MatrixIn="Rec601")
ConvertBits(8, dither=1)
FrameRateConverter(NewNum=60, NewDen=1)
SuperResXBR(3, 1, 0, XbrStr=2.6, XbrSharp=1.3, fWidth=1012, fHeight=778, fKernel="Bicubic", fB=0, fC=.75, FormatOut="YV12")
ResizeX(1004, 768, 0, 5, -8, -5)
Prefetch(8)


I'm having some performance issues though.

[Sharc]

New version: 2017-06-08 (https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.7-alpha)

Several tweaks:
- StripeMask's comparison width is now 2 instead of 3 for blksize=16
- BlendOver default raised from 50 to 60
- Stripes default changed from "skip" to "blend" -- safer
- Output=over now displays stripes mask as yellow (and artifact mask as cyan)
- Debug now displays Diff and Stripe values, and 4 digits instead of 6 digits
- Works correctly in 16-bit mode while maintaining compatibility with AVS 2.6 (debug mode still doesn't work correctly in 16-bit)
This version is very strong, for both stripes=skip and stripes=blend mode. Very nice!
The only minor issue is that it crashes under avisynth 2.60 here. No problem with avs+ though.

Edit:
Probably just the debug mode which created the avisynth 2.60 crash...

[Sharc]

Test it and let me know. It should be mostly good, and by testing with a variety of other videos, we can fine-tune settings further.

For example, after adding stripes masking and detecting after gamma correction, it might be possible to increase the blend over threshold.
Here another example for framerate doubling, with the version of 08-June-2017. Looks good, doesn't it?
http://www.mediafire.com/file/f06xv53etvf1se3/FRC_ma.mkv

[MysteryX]

I'm not satisfied with the video I posted earlier.

Here's an updated script. (https://github.com/mysteryx93/FrameRateConverter/blob/master/FrameRateConverter.avsi) StripeMask no longer affecting Skip, as Skip is designed for dealing with inconsistent masks with a threshold, while StripeMask is consistent in its results and can be accurately masked. Because of the lights causing distortions at the beginning of my clip, I lowered MaskTrh from 145 all the way down to 100. It looks a lot better, but still has a lot of artifacts with the flashes of light. Overall, the mask isn't strong enough to blend those frames, so it must be dealt with in other ways. Lowering the mask didn't have as much effect as I though it would on other clips; I tested the parade clip and it's not worse. It probably has limited impact because of the gamma curve that was applied on the mask first. I'll have to test on other clips if that still works.

The flashing lights still cause massive distortions that I'm not able to get rid of. Any idea on how to deal with this?

[Sharc]

The flashing lights still cause massive distortions that I'm not able to get rid of. Any idea on how to deal with this?
I am afraid that this presents a basic problem to motion estimation. Not sure that there is a solution to this (flashing lights, strobing)

[kolak]

1 thing for sure DCT=1

[MysteryX]

1 thing for sure DCT=1
That video is perfectly fine with DCT=1 (preset="slower")! and it requires it

[MysteryX]

Even with DCT=1 (preset="slower"), I get better results on my video with MaskTrh=100 than with 110 or 145. Can you test with your videos?

[Sharc]

Even with DCT=1 (preset="slower"), I get better results on my video with MaskTrh=100 than with 110 or 145. Can you test with your videos?
MaskTrh=145 has the edge in my case. Little to no difference between 100 or 110.

[MysteryX]

Is 145 just slightly better and 100 still good? (and safer for general use)

[Sharc]

Is 145 just slightly better and 100 still good? (and safer for general use)
Differences are subtle only and frame dependent. 100 is definitely still good. No problem.

[MysteryX]

One option is to add Artifacts=Weak|Medium|Strong. But if the difference is minor and 100 still looks good, then I'll just keep that as default.

[Sharc]

Agree. Better not overdo with too many options.

[MysteryX]

Agree. Better not overdo with too many options.
I did some more tests and this version seems good. Nothing more to add at the moment.

[hello_hello]

FrameRateConverter seems to be causing havoc on my PC (XP and Avisynth 2.6). I'm using a script such as the following one. AssumeFPS(25) was added for testing to see if going from a non-integer frame rate to an integer frame rate was the problem. FrameRateConverter.dll version 2017-06-08 with the updated version of the script. Most of the time programs simply crash without an error message as soon as I try to preview the script, but I managed to catch a few.

LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VTS_02_1.d2v")
AssumeFPS(25)
FrameRateConverter(50)

VirtualDub said:

An out-of-bounds memory access (access violation) occurred in module 'avisynth'...
...reading address 00000004...
...while running thread "Dub-I/O" (thread.cpp:197).

For AvsPMod it'd start out:

http://image.ibb.co/j5tm55/error_1.gif

Then a couple of times it got funky claiming errors in scripts in the Avisynth plugins folder that weren't actually being used in the script being opened.

http://image.ibb.co/bsu4sk/error_2.gif

http://image.ibb.co/m7Ztk5/error_3.gif

As soon as I removed FrameRateConverter() from the script things returned to normal.

Cheers.

[Sharc]

I had to switch to AVS+ (x86, 32bit) in order to make it work.
It crashed under Avisynth 2.6.0.6 here as well.

[Groucho2004]

I had to switch to AVS+ (x86, 32bit) in order to make it work.
It crashed under Avisynth 2.6.0.6 here as well.
False assumption below, please ignore.

The explanation is quite simple:
From Init.cpp

// Convert input to 8-bit; nothing to gain in processing at higher bit-depth.
int SrcBit = input->GetVideoInfo().BitsPerComponent();
if (SrcBit > 8) {
...
}
Calling a function that is exclusive to AVS+ without any error handling in place will of course cause a hard crash with the classic Avisynth versions.

[MysteryX]

Didn't Pinterf say that BitsPerComponent was implemented in the header file in a way that was backwards compatible?

[manolito]

This is my main complaint about FrameRateConverter... :scared:

MysteryX develops his app using only the latest and greatest versions of AviSynth, MaskTools and MVTools without any regard to users who prefer older (and more stable) versions of these filters.

Please note that I do not complain about his app not working on my ancient WinXP machine with a Non-SSE2 CPU. I am talking about a ThinkPad running Win7-64 on an Intel Core i5 CPU.

It probably comes down to Pinterf's efforts to modernize older AviSynth filters. It is fine with me to add new functionality like new color spaces and higher bit depths to these filters. But I firmly believe that feeding those filters with a script which does not make use of these new features should produce identical output compared to the older versions. (Maybe with the exception when a real bug has been discovered with the old versions).

But with Pinterf's latest versions of AVS+, MaskTools and MVTools this is not the case. When I run FrameRateConverter with identical parameters and switch between the different plugin versions, I either get crashes (AVS 2.6 vs AVS+), or the results are very different, probably due to different mask strengths.

This is the main reason why I gave up on FrameRateConverter in its current incarnation.


Cheers
manolito

[MysteryX]

I just haven't done tests yet with v2.6. Reporting bugs is sufficient, no need to complain.

[StainlessS]

Didn't Pinterf say that BitsPerComponent was implemented in the header file in a way that was backwards compatible?

AVS+ is "backwards compatible" with standard, but AVS standard is not necessarily "forwards compatible" with AVS+.

If coder uses only AVS standard methods, then no probs. :helpful:

[Groucho2004]

Didn't Pinterf say that BitsPerComponent was implemented in the header file in a way that was backwards compatible?
I had a look at the AVS+ header and there is indeed a fallback mechanism in place where for example BitsPerComponent() will return a constant 8 in classic Avisynth.

So, I don't know what's causing the crash but it does seem to be something in FramerateConverter.

[MysteryX]

I had a look at the AVS+ header and there is indeed a fallback mechanism in place where for example BitsPerComponent() will return a constant 8 in classic Avisynth.
Told ya :)

Will have to debug later.

[manolito]

The crash under AVS 2.60 is definitely caused by FrameRateConverter.dll. The last version which does not cause a crash is this version from May 28th:
https://github.com/mysteryx93/FrameRateConverter/releases/tag/v0.3-alpha

The following version from May 30th and all newer versions do crash AVS 2.60 reliably... :mad:

The problem with the old version from May 28th is that the conversion result is much worse.


Cheers
manolito

[hello_hello]

It probably comes down to Pinterf's efforts to modernize older AviSynth filters. It is fine with me to add new functionality like new color spaces and higher bit depths to these filters. But I firmly believe that feeding those filters with a script which does not make use of these new features should produce identical output compared to the older versions. (Maybe with the exception when a real bug has been discovered with the old versions).

You made me curious so I had a look, as I regularly use those plugins with QTGMC (makstools2, mvtools2, rgtools). I tested with QTGMC 3.33.

I'll confess when comparing the Avisynth output I don't think I could pick differences between the new plugins and the old ones visually, but there are some differences because when I saved identical screenshots (png) the image file size when using the old plugins was generally marginally higher (ie 849.6MB vs 849.4MB).

When I saved screenshots after encoding, the screenshots taken from the encode using the new plugins were slightly larger, which I thought was odd, given it was the other way around before encoding (ie 819.7MB vs 820.4MB).

Whatever the differences in the plugins, you can visually see it causes the video to be encoded slightly differently when using QTGMC. Not necessarily better or worse (at CRF18), which is what your post made me paranoid about and why I looked, but a little differently.

Even using my old Q9450 CPU though, the same NTSC video de-interlaced with QTGMC 3.33 encodes a couple of fps faster using the new plugins than it does with the old ones.