QTinput error in output with Avisynth+

[astronob]

Hi,

Can someone advise me why QTinput doesn't seem to work with Avisynth+, when it was working fine with Avisynth?

This is how it outputs now in Avisynth+

http://i.picpar.com/IQMd.jpg

Just a simple script

qtinput("D:\Video.mov", audio=1)
ConvertAudioTo16bit()
converttoyv12()
QTGMC(Preset="Slow", sharpness=1.2)
selecteven()


If I use ffms2, directshowsource and so on, they all display and output just fine. Any feedback would be appreciated. Thank you.

[StainlessS]

Well firstly, QTSource is quite old (version I have is 2006, on Wiki latest v0.1.4 2011):- http://avisynth.nl/index.php/QTSource

I would suggest LSmashVideoSource() as better option for ISO containers, more recent and specifically for ISO containers [does not need to index file, and does not need Quicktime].

Function IsISOFileName(String s) { # req RT_Stats
s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".m4v"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")
}


Best not to obscure your problem with extraneous stuff, ie qtinput("D:\Video.mov") would have been enough.
Maybe add an Info, just so it can be seen what it was decoded to, ie

qtinput("D:\Video.mov")
info


And what does MediaInfo produce for the clip, particularly, what bit depth, width, colorspace,
the green stuff at the bottom, and diagonal slanting might suggest problem with width/rowsize/pitch.

Have you actually tried with this clip in Avs standard ?

Also, have you tried any other settings, eg, color, mode, raw, info, vfw

Function Prototype [prototype from WIKI says "file" is optional(quoted), I doubt that is the case]

QTInput (string "file", int "color", int "quality", int "audio", int "mode", string "raw", int "info", int "dither", string "vfw", float "gamma", float "vfrFPS")


EDIT: If the clip aint too big, maybe you could post it somewhere.

EDIT: Also, which version Quicktime you got installed ?
EDIT: And which version QTSource.

[hello_hello]

Hi,

Can someone advise me why QTinput doesn't seem to work with Avisynth+, when it was working fine with Avisynth?

This is how it outputs now in Avisynth+

I haven't had a chance to play with the sample you sent me yet, but I suspect 10 bit is an issue for QTSource.

Video
ID : 1
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 13 s 280 ms
Bit rate mode : Constant
Bit rate : 221 Mb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Top Field First
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 350 MiB (99%)
Language : English
Encoded date : UTC 2019-10-24 09:55:33
Tagged date : UTC 2019-11-13 06:32:06
Color primaries : BT.601 PAL
Matrix coefficients : BT.601

I hadn't considered that possibility until I saw the sample because you said it decodes the video fine when you're using Avisynth 2.6. Someone with more smarts than me will have to explain why that happens, because I don't understand it myself. I assume AvsPmod can display bit depths greater than 8 bit? I haven't had a chance to test that yet as I don't use AvsPmod much myself and I almost always work with 8 bit sources. Depending on your target playback device, you might have to convert it to 8 bit for encoding anyway. You're using mpeg2 encoding again for that one?

[qyot27]

If it's not the bit depth, it may be because AviSynth+ processes YUV 4:2:2 as planar (YV16) internally, not as YUY2, and that could be screwing with something in the pipeline. The doc page on the Wiki (http://avisynth.nl/index.php/QTSource) says it uses one of RGB32, RGB24, or YUY2 (owing to the fact it's a 2.5 plugin, not a 2.6 plugin). So no planar YUV.

I wouldn't bother using QTSource unless it's a format libavcodec can't handle, but if you're deadset on it, try setting color=0 or color=1 to force RGB24 or RGB32 output rather than YUY2. Also, raw="v210" may or may not help.

Knowing that it's using 10bit, though, I absolutely would not use plugins that are restricted to 8bit output (like QTSource). Don't dither if you don't have to.

[astronob]

Well, adding color=0 and color=1 both give me a picture with Qtinput, but color=0 output is noticeably darker than color=1 (RGB24, vs RGB32), but is closer to the source color. Here is the info from using Qtinput in avisynth+. As mentioned in another thread in doom9, mode=4 gives me very similar, but not quite identical color. On the source, the whites are a little brighter, but I compared using qtinput with mode=0, color=4 (or color=0, both produce identical output) and straight ffms2 to input the video, and the output looks the same to me. It's a shame Qtinput hasn't been further developed to allow the input of 10bit and greater video bit depth. Perhaps if we all raised a petition we could persuade tateu to develop it a bit more. :-P

http://i.picpar.com/3aNd.jpg

Here is the small sample video I'm using (the file will stay up for 30 days before it's deleted.

https://ufile.io/zazzgey7

It's a VHS rip. I was basically trying to clean the grain/noise from the video while preserving the best detail, by running some filters on it in an avisynth script. I know it's always a compromise, remove more grain, lose more detail etc. I've tried the inbuilt filter of QTGMC (EZdenoise), I've tried temporaldegrain, temporaldegrain2 and MCTD. I liked the output of MCTD, but some detail was lost on "VeryHigh" settings, plus it's crazy sloooow, like 1.5 hours to encode a 3.5 minute video. The others I can get faster output. I ended up installing Avisynth+, which was where the input error for Qtinput started, which worked fine in Avisynth 2.6. Nevertheless, mode=0, color=4 seems to allow input now for Qtinput. I would ask, those with more experience in scripting, if you want to try your hand on improving the output from that small sample, what script could people suggest to clean up that grain while still delivering a detailed picture? And doing it in a reasonable time if possible. The VHS player delivers pretty good detail, and almost no scan line on the bottom, so I don't have to crop the video, but it does output a bit more grain in the outputted video than other VHS players I've tried. Anyway, any suggestions would be most welcome, as my experience in this area is limited. Thanks.

[StainlessS]

Perhaps if we all raised a petition we could persuade tateu to develop it a bit more. :-P

He aint been around since 2013:- https://forum.doom9.org/member.php?u=4847

I did a failed download of your sample, I'll try again when better connection.


vFN="D:\sheena-easton-machinery-small-sample.mov"
c=LSMASHVideoSource(vFN)
AudioDubEx(c,LSMASHAudioSource(vFN))
info


Try above, QTSource is rarely used by anybody.

[qyot27]

Well, adding color=0 and color=1 both give me a picture with Qtinput, but color=0 output is noticeably darker than color=1 (RGB24, vs RGB32), but is closer to the source color. Here is the info from using Qtinput in avisynth+. As mentioned in another thread in doom9, mode=4 gives me very similar, but not quite identical color. On the source, the whites are a little brighter, but I compared using qtinput with mode=0, color=4 (or color=0, both produce identical output) and straight ffms2 to input the video, and the output looks the same to me. It's a shame Qtinput hasn't been further developed to allow the input of 10bit and greater video bit depth. Perhaps if we all raised a petition we could persuade tateu to develop it a bit more. :-P

color=4 doesn't exist. QTinput's color= parameter only has values up to 2; clearly, if you use something >2, it just forces it back to 0.

Converting to RGB from a YUV source is going to entail things like full vs. limited range, which QTinput (or Quicktime 7 on Windows, which is itself deprecated, unsupported by Apple, and hasn't gotten security updates in years) is probably not handling, or not handling correctly. There is also the fairly well-known "Quicktime gamma bug" that messes with full vs. limited range when decoding H.264 (https://vitrolite.wordpress.com/2010/12/31/quicktime_gamma_bug/). Who knows, maybe other formats like uncompressed v210 are included in that. And if you're trying to resize up to 720p or something, then the conversion between BT.601 and BT.709 is going to come into play somewhere in this too. There's lots of places subtly wrong color conversions can occur.

And not knowing anything about how QT7 handled >8bit I/O, I can't say whether that's something that has latent color conversion bugs (or they might be considered "features") Apple never fixed before abandoning it.

At least by using FFMS2 or LSMASH, you're not limited to 32bit - both plugins can be used under 64-bit AviSynth+, and you're dealing with the original YUV422P10 content, so any necessary color conversions can be handled by internal filters or external plugins outside the source filter that can be counted on to be correct. There's also the option of using AviSynth+'s multithreading capabilities to speed up the processing filters (FFMS2 and LSMASH use libavcodec's internal multithreading anyway, but being source filters, have to be used in MT_MODE_SERIALIZED, which might cause a bottleneck).

[astronob]

Hi, if people have difficulty with that link, here is an alternative mediafire link.

http://www.mediafire.com/?i13zesa05u3sq10

Here is the strange looking output if I use your script StainlessS. An adjustment to the script to get the correct output would be nice. :-) In addition, if people could suggest a nice script I could try to clean up the grain from the video while preserving as much detail as possible would be appreciated, as my knowledge in these matters is limited. Thanks.

http://i.picpar.com/ijNd.jpg

[StainlessS]

Maybe try force 10 bit 422 (planar 10 bit equiv to YUY2)


vFN="D:\sheena-easton-machinery-small-sample.mov"
c=LSMASHVideoSource(vFN,format="YUV422P10") # or "YUV420P10" (10 bit YV12)
AudioDubEx(c,LSMASHAudioSource(vFN))
info

[qyot27]

Update your version of LSMASHSource.dll (http://avisynth.nl/index.php/LSMASHSource#Archived_Downloads)
(although it doesn't like something about the audio, maybe the fact it's uncompressed? LwLibavAudioSource handles it, but will generate an index)

[StainlessS]

My version LSmash produced rubbish too, so updated to qyot27 first dll in list, and works fine, no audio probs that I could hear (only checked on headphones).

Try something like this


# Seems to be Progressive on viewing SeparateFields, ie dont need deinterlacing

vFN="D:\WORK\Sheena Easton machinery small sample.mov"
c=LSMASHVideoSource(vFN) #,format="YUV422P10") # or "YUV420P10" (10 bit YV12)
a=LSMASHAudioSource(vFN)
#a=LwLibavAudioSource(vFN) # LSMASHAudioSource() seem to work ok for me
AudioDubEx(c,a)
# return info
C1=QTGMC(Preset="Slow", sharpness=1.2).selecteven() # Req QTGMC v3.363s and smdegrain v3.1.2.104s
C2=McDegrainSharp(frames=3) # 1->3, req McDegrainSharp:- https://forum.doom9.org/showthread.php?p=1737045#post1737045
StackHorizontal(C1,C2)

My preference is the McDegrainSharp one on right [click twice for full size] McDegrainSharp my goto filter for almost every clip.
https://i.postimg.cc/pys6Jz94/bit10-00.jpg (https://postimg.cc/pys6Jz94)
You can change frames to 1 or 2 if too much noise removed by McDegrainSharp. [but Sheena always had a kinda shiny sheen]

EDIT: Nasty 'glue' marks before/after scene change.

EDIT: QTGMC has some switch to just denoise, and not deinterlace, no idea what it is though [I dont use it that often].

EDIT: Processed as below script available as Sheena.mp4 ~3.5MB @SendSpace in my sig below, available for 30 days [could have benefitted from contrast adjustment]

vFN="D:\WORK\Sheena Easton machinery small sample.mov"
c=LSMASHVideoSource(vFN)
a=LSMASHAudioSource(vFN)
AudioDubEx(c,a)
McDegrainSharp(frames=3)
Crop(10,0,-14,-0)
# for MeGUI 10 Bit
RT_signalDar2(4,3)
ConvertBits(16)
ConvertToYUV420()
Return last

EDIT: Also uploaded same script as above but without McDegrainSharp, ~10.7MB Sheena_No_McDegrainSharp.mp4 [ie not much diff from 350MB source clip, just compressed non lossless].
EDIT: Also Added Sheena_Contrast.mp4 ~3.7MB, with a bit of Levels as Below

vFN="D:\WORK\Sheena Easton machinery small sample.mov"
c=LSMASHVideoSource(vFN)
a=LSMASHAudioSource(vFN)
AudioDubEx(c,a)
Crop(10,0,-14,-0)
Levels(128,1.0,1020,64,940,coring=false)
#Histogram(mode="Levels")
#Return last
McDegrainSharp(frames=3)
#Return last
# for MeGUI 10 Bit
RT_signalDar2(4,3)
ConvertBits(16)
ConvertToYUV420()
Return last

[astronob]

Hi StainlessS,

Please share qyot27's dll so I can update mine too. :D BTW, I'm running XP, I've tried various versions of the LSMASHsource.dll, but I'm still getting that weird output. Can anyone suggest the right dll to try? Thanks.

[astronob]

Hey, LSMASHVideoSource, is still giving me rubbish in the output. I tried updating the dll, but no joy. I'm using WinXP 32 bit. Does that dll apply to Win7 and above? If so, is there a XP32 compatible dll I can use? Thanks.

[hello_hello]

Why don't you just use ffms2? It's working for me. For Avisynth+ the output is 10 bit. I'm not sure what happens to the extra bits, but it opens as 8 bit with Avisynth 2.6 and looks okay.

The only way I could get LSmash to output something sensible (the last XP compatible version) was to tell it to output 8 bit video. None of the higher bitdepth formats fixed the garbled video.

LSMASHVideoSource("E:\sheena-easton-machinery-small-sample.mov", format="YUV420P8")

[StainlessS]

Dont know if 10 bit XP LSmash available, my XP one dont work.


vFN="D:\WORK\Sheena Easton machinery small sample.mov"
#c=LSMASHVideoSource(vFN)
#a=LSMASHAudioSource(vFN)
FFIndex(vFN)
c=FFVideoSource(vFN)
a=FFAudioSource(vFN)
AudioDubEx(c,a)
#return Info
Crop(10,0,-14,-0)
Levels(128,1.0,1020,64,940,coring=false)
#Histogram(mode="Levels")
#Return last
McDegrainSharp(frames=3)
#Return last
# for MeGUI 10 Bit
MeGUI_darX=4 # RT_signalDar2(4,3), preset DAR for MeGUI
MeGUI_darY=3
ConvertBits(16)
ConvertToYUV420()
Return last


EDIT: quot27 version was from post 10. [EDIT: I'm currently on W7]

[astronob]

hello_hello is right, you can get output if you tell LSMASH to output 8bit video as he has done, otherwise nada, but yes, ffms2 also works just fine too.

[FranceBB]

@astronob... LWLibavVideoSource for Windows XP will output anything greater than 8bit as 16bit interleaved, which is why you're seeing it that way.
On AVSPmod right click on the preview and choose "Bit Depth" -> "Interleaved yuv420p16". The preview will reload and it's gonna be fine.
Beware that in 16bit interleaved the picture contains the MSB and the LSB (Most significant bit and Less significant bit) interleaved together, so you gotta remember that all your filterchain has to be aware of that and 16bit interleaved compatible as well as your encoder (as it receives a 16bit interleaved output).
DO NOT use filters that expect 8bit planar with 16bit interleaved as that will fuck everything up.

16bit interleaved (https://i.imgur.com/fCDdo7B.jpg) -> Setting the preview the right way (https://i.imgur.com/x3ZJzr1.png) -> Correct planar output (https://i.imgur.com/o8ccHgt.jpg)

Dont know if 10 bit XP LSmash available

Nope, no one ever compiled it. The last XP Compatible version from the wiki is quite old.

is there a XP32 compatible dll I can use?

Nope. Your best shot with XP x86 is ffms2 C plugin which is the most updated indexer and it supports planar high bit depth with Avisynth+ (instead of stacked/interleaved).
Please keep in mind that the development of the C version of ffms2 dropped XP compatibility as well, so although it's more updated than LSMASH and it will be fine for many formats, it's still not the very last version and it won't get any updates in the future (unless qyot27 starts loving XP users again and re-introduces XP compatibility making a lot of XP die-hard happy, which is extremely unlikely to happen).

[astronob]

When I try to encode a "mov" file capture, captured with the v210 codec, avspmod gives me an error when I use ffms2, I added converttoyv12() for QTGMC, and it's saying "only 8 bit sources allowed". Is it the version of ffms2 I'm using? I'm using version 2.23.1. Would another version be more appropriate?

[StainlessS]

vFN="D:\WORK\Sheena Easton machinery small sample.mov"
#c=LSMASHVideoSource(vFN)
#a=LSMASHAudioSource(vFN)
FFIndex(vFN)
c=FFVideoSource(vFN)
a=FFAudioSource(vFN)
AudioDubEx(c,a)
#return Info
Crop(10,0,-14,-0)
Levels(128,1.0,1020,64,940,coring=false)
#Histogram(mode="Levels")
#Return last
McDegrainSharp(frames=3)
#Return last
# for MeGUI 10 Bit
MeGUI_darX=4 # RT_signalDar2(4,3), preset DAR for MeGUI
MeGUI_darY=3
ConvertBits(16)
ConvertToYUV420()
Return last



Above in blue, whatever bit depth [although I dont know if avsPmod supports it].
EDIT: And QTGMC.3.363s.avsi.

[astronob]

Adding "convertbits(8)", without the quotation marks, after the importation of the file with ffms2, fixes the display in avspmod and allows the encoder to encode the script. Adding this string to the input line of ffms2 also works colorspace = "YUV420P8" or "YUV422P8", and negates the need to add convertbits(8) after the import line. It also eliminates the need to add converttoyv12(0 before QTGMC, but if I don't add converttoyuy2() if using colorspace="YUV420P8" (but not for colorspace="YUV422P8") at the end of the script, the video is stretched vertically in the preview window, the same height, but half the width. I don't get that at all. In addition, seems I still need to add converttoyuy2() at the end of my script for my chosen encoder, CinemaCraft Encoder, otherwise it won't encode the video. But I didn't have to do it before, I might have added some dll or avs or avsi script to the plugins folder which broke my previously fine working script. :( However, temporaldegrain2 only works with avisynth+ and so I have to use avisynth+, which has it's benefits, it definitely allows for faster encoding for me than avisynth 2.6, but you have to get the right dependencies and plugins in the plugins folder, otherwise all you get thrown up is one error after another.

[qyot27]

"YUV422P8" == YV16. YUY2 and YV16 are both 4:2:2 formats, but YV16/YUV422P8 is planar (and is what AviSynth+ works in for 4:2:2, internally) and YUY2 is not.

[astronob]

There is "planar" and there is "interleaved". So can someone explain the difference to me?

[FranceBB]

There is "planar" and there is "interleaved". So can someone explain the difference to me?

Planar is the regular one; it's what the majority of encoders expect, it's what 4:2:2 based formats like XDCAM use.

yv16 is 4:2:2 planar.

YUY2 is 4:2:2 interleaved; it dates back many years ago when Avisynth only had support for yv12 and YUY2. YUY2 was the first way to have 4:2:2 support inside Avisynth as yv12 was 4:2:0 planar. Since we didn't officially have support, YUY2 was a "workaround" to introduce support to have more precision. As a matter of fact, many filters back then were supporting yv12 only and were quickly ported to YUY2. Later on, the official 4:2:2 planar support arrived (yv16) along with 4:4:4 planar (yv24). Everything I've been talking about is 8bit.

Now I'm gonna confuse you a bit (sorry about that).

The situation described above with everything in planar and only 4:2:2 available in both planar (yv16) and interleaved (YUY2) has been what we have been using for years and with time people stopped using interleaved in favor of planar except for a few old filters that still required interleaved (but since the conversion between yv16 and YUY2 was lossless, nobody cared). The reason why I said that I'm gonna confuse you a bit is that after this configuration, people were seeking more precision 'cause high bit depth arrived. Since Avisynth was working with 8bit only, what was invented back then was 16bit stacked, namely a 16bit with 8bit MSB and 8bit LSB stacked one on top of the other. This allowed people to have much more precision in their calculations and in particular in operations like denoise, debanding etc. Most importantly, it was possible to index 10bit and above sources and maintain 10bit precision by having 16bit stacked (MSB and LSB stacked one on top of the other). This whole project was called "Dither_Tools". At the same time, another developer started working on an alternative solution for the "high bit depth problem" and he "invented" 16bit interleaved which was pretty much the same as stacked but this time MSB and LSB were inteleaved one with the other. 16bit stacked was often called "Double Height" 'cause MSB and LSB were stacked one on top of the other while 16bit interleaved was often called "Double Width" as MSB and LSB were interleaved one with the other. The "antagonist" of Dither_Tools (16bit stacked) was HDRCore (16bit interleaved) and since those two were developed at the same time and since there wasn't official high bit depth support for Avisynth (16bit planar), developers were left in the dark and started supporting one or the other or both. For instance, f3kdb supports 16bit stacked and 16bit interleaved but not planar (although there has been a recent fork called f3kdb neo which dropped support to stacked and interleaved and introduced support to planar just to confuse things further). Eventually, developers started supporting Dither_Tools more and it became more popular than 16bit interleaved. Many years later (2016), the development of the official Avisynth project stopped and the repository froze. As a consequence, people migrated to Avisynth+ which is a project that aimed to introduce many renovations inside Avisynth and one of them was official planar high bit depth support which superseded 16bit stacked and 16bit interleaved. Unfortunately, though, we're at a point in which many filters were already supporting either 16bit stacked or interleaved and developers didn't bother to support planar and this is where we are now: many filters were ported to support planar high bit depth, but many others are still relying on stacked and/or interleaved.

I probably repeated this story thousands of times as it's very confusing for a lot of people who join the Avisynth community in recent times but have not been part of the "change" as it's extremely difficult to get around all those particular things.
All this is actually documented on the wiki: http://avisynth.nl/index.php/ConvertStacked
Anyway, I understand that it still creates a lot of confusion among new people who join this wonderful encoding world.

[StainlessS]

Avisynth Colorspaces on Wiki (there is probably a graphic somewhere):- http://avisynth.nl/index.php/Color_spaces

Wikipedia:- https://en.wikipedia.org/wiki/YUV

VLC:- https://wiki.videolan.org/YUV

Greenend Image Formats:- http://www.chiark.greenend.org.uk/doc/linux-doc-3.16/html/media_api/pixfmt.html

M$:- https://docs.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering
M$ hi bit:- https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats

[hello_hello]

Of the denoising I tried, the two methods I preferred for the sample from post #8 were QTGMC in progressive mode or TemporalDegrain (the original version, not TemporalDegrain2). They both settle the picture wobble a bit.

FFVideoSource("E:\sheena-easton-machinery-small-sample.mov", threads=1, colorspace="YUV420P8")
QTGMC(InputType=1, EzDenoise=3)
CropResize(0,0, 16,4,-16,-4, NoResize=true, InDAR=15.0/11.0)
QTGMC.mkv (https://ufile.io/y3ff44mg)

FFVideoSource("E:\sheena-easton-machinery-small-sample.mov", threads=1, colorspace="YUV420P8")
TemporalDegrain()
CropResize(0,0, 16,4,-16,-4, NoResize=true, InDAR=15.0/11.0)
TemporalDegrain.mkv (https://ufile.io/vcd3gr65)

[StainlessS]

Something I was playing with [req avs+]

vFN="D:\WORK\Sheena Easton machinery small sample.mov"
BITS10=false # Bit Depth, true=10 ::: True requires TemporalDegrain2(), false can change to TemporalDegrain().
#
CROP_X = 10 # Crop
CROP_Y = 0
CROP_W = -14
CROP_H = -0
#
DOLEV0=False # Levels on C0, QTGMC
DOLEV1=False # Levels on C1, TemporalDegrain
DOLEV2=True # Levels on C2, McDegrainSharp
#
LEV_IPLO = 32 # Levels, Set using 8 bit TV range (SrcY is about 32 -> 255, ie hi and low too bright)
LEV_GAM = 1.0
LEV_IPHI = 255
LEV_OPLO = 16
LEV_OPHI = 235
#
C2FRAMES=2 # For McDegrainSharp (1->3, 1=default, 3=max denoise)
ORG_LIMIT_TV = False # Limit Output to TV_Range
C0_LIMIT_TV = True
C1_LIMIT_TV = True
C2_LIMIT_TV = True
#
SUBS = True # Show subs
RET = 3 # 0=C0, 1=C1, 2=C2, 3=Stack4
########### END CONFIG ##########
CSP=(BITS10) ? "YUV420P10" : "YV12" # FFVideoSource failed with Colorspace="YUV420P8", so using "YV12" [Unknown Colorspace, or similar].
LEV_SHFT = BITS10 ? 2 : 0
LEV_IPLO=BitLShift(LEV_IPLO,LEV_SHFT)
LEV_IPHI=BitLShift(LEV_IPHI,LEV_SHFT)
LEV_OPLO=BitLShift(LEV_OPLO,LEV_SHFT)
LEV_OPHI=BitLShift(LEV_OPHI,LEV_SHFT)
#
LIM_YLO =BitLShift(16, LEV_SHFT)
LIM_YHI =BitLShift(235,LEV_SHFT)
LIM_UVLO=BitLShift(16, LEV_SHFT)
LIM_UVHI=BitLShift(240,LEV_SHFT)
###########
FFIndex(vFN)
c=FFVideoSource(vFN, threads=1, colorspace=CSP)
a=FFAudioSource(vFN)
AudioDubEx(c,a)
Crop(CROP_X,CROP_Y,CROP_W,CROP_H)
#return Info
ORG=Last
OrgLev=Levels(LEV_IPLO,LEV_GAM,LEV_IPHI,LEV_OPLO,LEV_OPHI,coring=false) # NOT Applied to ORG
C0 = DOLEV0 ? OrgLev : ORG
C1 = DOLEV1 ? OrgLev : ORG
C2 = DOLEV2 ? OrgLev : ORG
#
C0=C0.QTGMC(InputType=1, EzDenoise=3)
C1=C1.TemporalDegrain2()
C2=C2.McDegrainSharp(frames=C2FRAMES)
#
ORG=(ORG_LIMIT_TV) ? ORG.Limiter(LIM_YLO,LIM_YHI,LIM_UVLO,LIM_UVHI) : ORG
C0 =(C0_LIMIT_TV) ? C0.Limiter(LIM_YLO,LIM_YHI,LIM_UVLO,LIM_UVHI) : C0
C1 =(C1_LIMIT_TV) ? C1.Limiter(LIM_YLO,LIM_YHI,LIM_UVLO,LIM_UVHI) : C1
C2 =(C2_LIMIT_TV) ? C2.Limiter(LIM_YLO,LIM_YHI,LIM_UVLO,LIM_UVHI) : C2
#
ORG=(SUBS)?ORG.Subtitle("ORG") : ORG
C0 =(SUBS)?C0.Subtitle("C0.QTGMC") : C0
C1 =(SUBS)?C1.Subtitle("C1.TemporalDegrain") : C1
C2 =(SUBS)?C2.Subtitle("C2.McDegrainSharp") : C2
(Ret==0) ? C0 : (Ret==1) ? C1 : (Ret==2) ? C2 : StackVertical(StackHorizontal(ORG,C0),StackHorizontal(C1,C2))
# for MeGUI
MeGUI_darX=4 # Whatever, Preset DAR for MeGUI
MeGUI_darY=3
(BITS10)?ConvertBits(16):NOP # MeGUI requirement for 10 bit
ConvertToYUV420()
#info
Return last

[astronob]

Hi hello_hello & StainlesS, I got Temporaldegrain2 to eventually work, and quite liked the output. IMO, the de-grain is similar to the original Temporaldegrain, but it retains more detail, as others have noted. Fastdegrain is good too, certainly encoding is faster, but I did notice some detail was lost, as has been noted. MCDegrainsharp, at it's highest settings, is very slow and does remove practically all the grain, but too much detail is lost for my liking at the highest setting, things like skin tones become overly smoothed and "fake" looking. Ultimately everything is a tradeoff I guess, the big downside with using these filters at their highest settings is that encoding times slow to an absolute crawl, not even 1fps, and I never found personally, any increase in speed from using Avisynth+ in MT mode either. Ultimately, what I would like to see, is the developers somehow harnessing the power of the GPU to do some or all of the encoding, rather than just the CPU. The processing power of today's modern GPU's is just phenomenal. That is an area of development with great potential to improve these abysmally slow encoding times with these filters.

[StainlessS]

Below, McDegrainSharp, 1st & 2nd tests 8 bit, 3rd 10 bit.
1st MCDegrainSharp Frames=2, 10.69FPS.
2nd MCDegrainSharp Frames=1, 18.68FPS.
3rd MCDegrainSharp Frames=1, 10Bit, 12.34FPS.
All with levelling, and also TV_Levels Limiting (for better compression).
Can also adjust sharpness[EDIT: "csharp"=0.6, I sometimes use 0.33] in McDegrainSharp, if required [or not use Sharp, ie Use McDegrain() instead].
Timing with AvsMeter on Core Duo Quad 2.88GHz CPU.
Of course, does not take encode time into account, but that is something else.

https://i.postimg.cc/8shbW0j1/z.jpg (https://postimg.cc/8shbW0j1)

EDIT: McDegrainSharp blurs [hides] bad MC compensated areas, and sharpens good matching areas.

EDIT: Above without any kind of attempt at MT, I never use it.

EDIT:
MeGUI @ 10Bit, CRF=20.0, Slower, Audio=96Kb/s, 4.85 FPS, CPU @ 98.0%
[EDIT: FPS was still getting faster due to pause near start in MeGUI, clip was not long enough for better timing, guess that it might have hit about 5.5FPS if longer]
https://i.postimg.cc/PCmvJPyK/z2.jpg (https://postimg.cc/PCmvJPyK)

EDIT:
Added this after Audiodub and before any cropping/levelling etc

AudioDubEx(c,a)
Last++Last++Last++last # *4
Last++Last++Last # *12
Crop(CROP_X,CROP_Y,CROP_W,CROP_H)

Made 12 times longer clip, 2:39, and re-encode as prev 10 bit clip, hit 5.35FPS, not quite as high as I anticipated.
https://i.postimg.cc/zbKsnfd2/Untitled-00.jpg (https://postimg.cc/zbKsnfd2)

EDIT: I would prefer Frames=2 or 3 with that noisy clip, but usually just use 1.
Those with "trained eyes" see grain as detail, my untrained eyes just see noise :)