Strange filter output after upgrading to avisynth+

[tyee]

Using Didee's McDegrainSharp filter here (https://forum.doom9.org/showthread.php?p=1508638#post1508638), I get normal output for sdr sources, but when I use a 4k hdr source I get strange sparkles on the left half of the video only, the right half is perfect. Using my old avisynth ver. 2.6, this did not occur. Any tips on what could cause it?

See snapshot here - https://imgur.com/a/4abwKPR

You can see a vertical line in the center of the image so the left and right halves are being processed differently.

[StainlessS]

State function args if non default, and can you post a lossless compressed source of a dozen or so frames [that reproduce problem, Suggest MediaFire]

Also, state version of AVS+, and MvTools, and if x64 or x86.

EDIT: Pinterf,

bs = (c.width>960) ? 16 : 8


EDIT: Post full script might also not be a bad idea.
EDIT: Also say if using the function from post following 2 posts after your linked post, ie the one with Precise arg [using MRecalculate].
There was at one time a bug in the Precise func,

backward_vec1 = (Precise) ? MRecalculate(super, backward_vec1, blksize=bs/2, overlap=bs/4,thSAD=100) : backward_vec1

Bug fix above in red (backward_vec1, was backward_vec2)

[pinterf]

EDIT: Pinterf,

bs = (c.width>960) ? 16 : 8


Yep. Tried with a 4096x3000 clip, could not reproduce. Need exact script, dimensions of clip, versions.

[StainlessS]

Yep. Tried with a 4096x3000 clip, could not reproduce. Need exact script, dimensions of clip, versions.

ColorSpace/BitDepth a good idea too.

[tyee]

This is my script

FFVideoSource("video.mkv")

Spline64Resize(1280,720)

McDegrainSharp(frames=1,bblur=0.6,csharp=0.6,bsrch=true)

Trim(50000,-200)

Clip is 3840x2160. I tried other sizes, same thing happens.
Avisynth+ version is the latest 0.1-r2772 i386
I'm not using precise
Removing the McDegrainSharp line, everything is ok.

Would this have anything to do with manually installing avisynth+?
The "c_api" folder is still sitting in my avisynth+ folder along with the files in it. Same with the "system" folder that was in the zipfile. Are those files supposed to be copied to a Windows folder? The docs don't say.

[pinterf]

c_api is for developers. You'd better use the official installer or the "universal" one. Ffms2 serves real 10bit for avs+ if your source happens to be 10bit. If so, then you have plugin which can't handle that properly.
Avsinfo tool can do wonders in order to have a proper and time saving help.

[pinterf]

Tried, yes, your source must be served as 10 bits, that's because Avisynth+ is detected, but your filters are old. Specifically, you should update your mvtools2.dll (and probably many others as well). You can find some basic plugins capable of handling 10+ bit formats at my github repository. See my signature. Or have a look at this project: https://forum.doom9.org/showthread.php?t=176443

[tyee]

I am using your latest mvtools2. How do I tell which plugins are required for mcdegrainsharp? I just looked at the script again but it does not mention all that are required. I will look at mvtools docs also. I'm not at home now so may be delayed a couple of days.

[StainlessS]

McDegrainSharp, requires only MvTools2.
You want lastest PINTERF version(from sig, below his post, then via Mvtools, and then via Releases)
Direct Link:- https://github.com/pinterf/mvtools/releases

Other Pinterf 10 bit filters via his sig[FilterName, Releases].

[pinterf]

When I replaced a fresh mvtools2 with an old one (v2.6.0.5) I was experiencing the very same pic halving issue.

[StainlessS]

With 10 bit clip from here (~840MB for 10 second clip) :- https://forum.doom9.org/showthread.php?p=1875247#post1875247
I'm NOT seeing any pic halving issue [I got lousy eyes, but could see the initial problem in image OK].
Tried with both MCDegrain and MCDegrainSharp.

Script

FFVideoSource(".\10Bit_Standard8_Scan_16FPS.avi")
Spline64Resize(1280,720)
#info # 10 bit
#McDegrainSharp(frames=1,bblur=0.6,csharp=0.6,bsrch=true)
McDegrain(frames=1)

return last


source

General
Complete name : D:\PINT\10Bit_Standard8_Scan_16FPS.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 844 MiB
Duration : 10 s 0 ms
Overall bit rate : 708 Mb/s
Writing library : VirtualDub2 build 43602/release # build I'm using, quite recent, less than 2 weeks old

Video
ID : 0
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 10 s 0 ms
Bit rate : 708 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 16.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 844 MiB (100%)


EDIT: Same with x64. I dont have HDR content.

EDIT: Still cant see when expanding luma range to max.

FFVideoSource(".\10Bit_Standard8_Scan_16FPS.avi")
Spline64Resize(1280,720)
# Return info # 10 bit

FC = frameCount
BPC = BitsPerComponent
oMaxY = BitLShift(1,BPC) - 1

iMinY = 255 # EDIT: OOps, Should be oMaxY, no matter
iMaxY = 0

# Will take a little while to scan every pixel
for(current_frame=0,FC-1) {
iMinY=min(iMinY,YPlaneMin(threshold=0.0))
iMaxY=max(iMaxY,YPlaneMax(threshold=0.0))
}

RT_DebugF("iMinY=%d iMaxY=%d : BPC=%d oMaxY=%d",iMinY,iMaxY,BPC,oMaxY) # iMinY=22, iMaxY=942 : BPC=10 oMaxY=1023 : Requires DebugView to view (Google)

Levels(iMinY,1.0,iMaxY,0,oMaxY,Coring=False)

#McDegrain(frames=1)
McDegrainSharp(frames=1,bblur=0.6,csharp=0.6,bsrch=true)

return last

Frame 11
https://i.postimg.cc/0zcW0byW/Frame11.jpg (https://postimg.cc/0zcW0byW)

EDIT:
When I replaced a fresh mvtools2 with an old one (v2.6.0.5) I was experiencing the very same pic halving issue.
Arh, you mean replace with old 8 bit MvTools on 10 bit src produces same thing.

EDIT: Tyee, make sure that you are using lastest PINTERF build, not latest NON PINTERF build. (link given in my prev post)
EDIT: Tyee, check that you removed OLD plugin from plugins directory.

[tyee]

Ok guys, thanks, I'll check when I get home.

[tyee]

Ok, back home and yes it works now! I had the older mvtools2.dll in my old plugins folder and avisynth+ was using that first. I renamed it and now the new version of mvtools2.dll is used in my new avisynth+/plugins+ folder. I found Groucho's Universal Avisynth Installer thread and saw the registry link that is being used (my old plugin folder) - "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth" (only on 64 bit OS). I'm not sure whether to leave all the older plugins there or move them to the new plugins folder?

One other question - How can I test if MT mode is being used. I don't see any higher fps when it's enabled.

[StainlessS]

Tyee, read the Universal AVS Installer comments, you need set the Plugins directory to use, in that file.

[MT mode, no idea, never use it]

EDIT: Maybe should have Uninstalled old AVS before using Universal AVS Installer.

[Groucho2004]

One other question - How can I test if MT mode is being used. I don't see any higher fps when it's enabled.Use AVSMeter. Compare number of threads/CPU usage/fps with and without MT statements. Also, post the script.

[tyee]

Here is my MT script -

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)

FFVideoSource("movie.mkv")

Spline64Resize(1920,1080)

McDegrainSharp(frames=1,bblur=0.6,csharp=0.5,bsrch=true)

output=Trim(101000,-2000)

# Enable MT
Prefetch(4)

return output

I have i7-3770K cpu.

[pinterf]

output=Trim(101000,-2000)

# Enable MT
Prefetch(4)

return output[/CODE]


Prefetch should appear in the filter chain, when you are using "output" clip variable, a single Prefetch() alone will do nothing, in this form it only applies on "last" clip variable which is not taking part in the final result

output=Trim(101000,-2000)
# Enable MT
return output.Prefetch(4)
or
output=Trim(101000,-2000)
output
# Enable MT
Prefetch(4)
return last

[tyee]

Thanks Pinterf. Just as I was about to try this I tried without enabling MT and got this error -

avs [error]: not supported pixel type: YUV420P10
x264 [error]: could not open input file `video.avs'

The source is 10 bit and I thought avisynth+ passes it. So is it my x264 that will not take it?

[StvG]

Vanilla x264 doesn't support avs input 10-bit. There is a patch here (https://github.com/DJATOM/x264-aMod-patches/blob/master/07-avs-input-10-12-14bits-support.diff). raw / y4m input 10-bit is supported.

[tyee]

Thx. I also tried ffmpeg and it seems to take it directly without any command line switches required. Whatever goes in (8 or 10 bit), comes out.