AviSynth+ thread Vol.2

[jpsdr]

Originally Posted by pinterf

Problem found and maybe fixed. A sample or telling the dimensions of your video would helped a lot

3840x1608
Sorry, i didn't thought about it, i was too much focussed on just the format part.
I can PM you my ftp server information and put the video on it if necessary, it's "small", less than 100 frames, it's was just a small thing for test purpose.

[pinterf]

Originally Posted by FranceBB

Yeah, I know.
It's a shame that they haven't updated anything since 2006 and I'm also sad to see it failing to compile while targeting new Avisynth+ headers...

Someone should really pick up the Sox filters and properly maintain them instead of leaving them in the Avisynth 2.5 abandonware...

Just wait and you'll see

[jpsdr]

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

[kedautinh12]

Originally Posted by jpsdr

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

Cause Directshowsource don't had any change very long. So can got from old ver avs+

[Reel.Deel]

Originally Posted by kedautinh12

Cause Directshowsource don't had any change very long. So can got from old ver avs+

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

[qyot27]

DirectShowSource does not get built by default, you have to specifically opt-in to build it. This is intentional, because unlike the other core plugins, DSS has a dependency on the DirectShow baseclasses library that, for whatever reason, is not part of a default install of either MSVC or the DirectX SDK. You have to build that library from the SDK samples, and because that's so non-intuitive (and because DSS should only ever be used as a last resort), it's better to leave it off by default so it doesn't impede the build process. Not to mention that for MinGW-w64/GCC builds, the MSVC-built baseclasses library is *probably* a no-go. There is something of a port of the baseclasses library to MinGW, but because DirectShowSource doesn't build with GCC, there's not really any way of vetting whether it works as intended.

That's not even touching the question of whether Clang or Intel compilers can build the baseclasses library at all, although I would assume that they can at least link to an existing build of it just fine ('Clang' in this case being assumed to be the clang-cl MSVC compatibility frontend, not the regular version of Clang that uses GCC's conventions).

[kedautinh12]

Originally Posted by Reel.Deel

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

I don't know but when Pinterf still use old date directshowsource.dll in his new build

[jpsdr]

Originally Posted by pinterf

Problem found and maybe fixed.

Tested the clang git build r3950, still the issue, so it's probably not pushed yet.

[pinterf]

Originally Posted by jpsdr

Tested the clang git build r3950, still the issue, so it's probably not pushed yet.

It's pushed; could you upload your sample clip fragment?

[jpsdr]

Originally Posted by pinterf

It's pushed; could you upload your sample clip fragment?

I've PM you informations.

[jpsdr]

Ok, i made more tests.

When i test a new avs+ version, i always do the same thing : open in VirtualDub2 the same avs file reading the same 10bit422 UTVideo file.
When VDub2 throw me an error message (it wasn't a crash), i thought there was an issue with AVISource in the clang build.
Well... There was indeed an issue in AVISource, but this was a fluke. As, for me, it wasn't a crash.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...

[pinterf]

Originally Posted by jpsdr

Ok, i made more tests.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...

Strange, temporarily I'd try to get rid of all autoloaded plugins, move them away, to make sure if one of them is making avisynth crash when loading. I don't have any other idea. My avsmeter is 3.0.0.4, and happily consumes any avisynth version

[pinterf]

Originally Posted by pinterf

Just wait and you'll see

When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again, test its various filters, and then try UpSoundOnSound which is using the same SoxFilter'ed clip four times, and realize that Avisynth+ has NO audio cache implemented... The feeling is priceless.

[DTL]

It looks GeneralConvolution() is somehow broken between 201x and 202x years.

In old decade

GeneralConvolution(0, "
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true, luma=true, chroma=false)

Make some sharpening effect on more medium frequencies in compare with Sharpen() because Sharpen use only 3x3 kernel. Now it return significantly distorted frame with lots of banding. The sum of coefficients is =1 so auto=true/false do nothing.

For simple YV12 format. Tried RGB32, tried 16bit.
At Windows7 tried AVS versions from 2.6 to +3.6 , +3.7 and still the same distortion. May be GeneralConvolution depends on some updated VisualC++ libs or other windows7 components ?


Here most simple form of bug with GeneralConvolution:

GeneralConvolution(0, "
-0.4 -2 -0.4
-2 9 -2
-0.4 -2 -0.4", auto=true, luma=true, chroma=false)

Make sharpening about as expected.

GeneralConvolution(0, "
-0.5 -2 -0.5
-2 9 -2
-0.5 -2 -0.5", auto=true, luma=true, chroma=false)

Turn to significant blurring. The switch from about good to significantly bad result occur when diagonal angle coefficients of simplest 3x3 matrix go from -0.4 to -0.5. Looks like some rounding or auto-normalization error ?

Same is with documentation example:
GeneralConvolution(0, "
-0.4 -1 -0.4
-1 5 -1
-0.4 -1 -0.4 ", auto=true, luma=true, chroma=false)
Still make sharpening as expected.

GeneralConvolution(0, "
-0.5 -1 -0.5
-1 5 -1
-0.5 -1 -0.5 ", auto=true, luma=true, chroma=false)
Switch to very blurry.

Same result with 3.7.2 release, 3.7.3 test 7 x64, x64_xp (x64_clang and x64_IntelClassic not work with AVI import filter error).

[FranceBB]

Originally Posted by pinterf

When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again

Originally Posted by pinterf

test its various filters, and then try UpSoundOnSound

Originally Posted by pinterf

, and realize that Avisynth+ has NO audio cache implemented...

Jokes aside, thank you so so so much for taking a look at this. It means the world to me and I'm really grateful to see how every time I highlight something you always go above and beyond to get it working.
We're really lucky to have you in this community, Ferenc! I mean it.

[wonkey_monkey]

Originally Posted by DTL

Looks like some rounding

Not sure about the rest of your trouble with GeneralConvolution but bear in mind that the Wiki states:

float values are converted to integers for 8-16 bit clips

So -0.5->-1, and -0.4->0.

[DTL]

Kernel of 5 at the center and -1 surround also should not be blur kernel. Now the significant discontinuity in output effect from corners kernel members 0 to -1 also not look like correct action. If even floats not accepted it is only expected more significant step from light sharp with
0 -1 0
-1 5 -1
0 -1 0

to stronger sharp with
-1 -1 -1
-1 5 -1
-1 -1 -1.

But now last kernel cause switching to blur. The visible difference - sum of 1st kernel is 5+(-4)=1 and sum of last is 5+(-8)=-3. May this negative sum sign also play role in the issue ?

Checked (YV12 8bit 4:2:0):
-1 -1 -1
-1 5 -1
-1 -1 -1 - blur

-1 -1 -1
-1 6 -1
-1 -1 -1 - slightly sharper

-1 -1 -1
-1 7 -1
-1 -1 -1 - sharper, horizontal and vertical double contour

-1 -1 -1
-1 8 -1
-1 -1 -1 - almost black frame ! (zero sum), still auto=true

-1 -1 -1
-1 9 -1
-1 -1 -1 - finally sharping, auto=true/false - equally.

-1 -1 -1
-1 10 -1
-1 -1 -1 (auto=true - less sharp, auto=false - significant level offset to white)

So auto=true do not work with zero and negative integer sum ?

But kernel of 5x5 of
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

with sum=1 still return sort of HigiPassFilter only with about removed DC component and very low frequencies. DC component (median level and very low frequecies) start to recover to about
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 45 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

45..50..60 value of the 'central' value. So sum is much higher 1. With auto=false and center 80 - return white frame. May be something is changed in 'auto=true' internal processing ?

Attempt to float32:
ConvertBits(32)
GeneralConvolution(0, "
-1 -1 -1
-1 5 -1
-1 -1 -1 ", auto=true, luma=true, chroma=false)
ConvertBits(8)

change nothing from 8bit luma - still blur.

So it looks logic of GeneralConvolution kernel coefficients processing is changed somehow and now for 'sharp' kernels the total sum must be >>1 and only auto=true is working ?
For example now about good linear sharpener is
GeneralConvolution(0, "
-1 -2 -2 -2 -1
-2 -2 -3 -2 -2
-2 -3 70 -3 -2
-2 -2 -3 -2 -2
-1 -2 -2 -2 -1", auto=true, luma=true, chroma=false) - result demo https://imgsli.com/MTYxNDkz
And adjusting center member in range about 60..100 it is now possible to adjust 'strength'. Where 60 is very strong, 100 is very weak and 50 is sort of high-pass filter only. May it is also valuable mode but it looks old versions work differently and old matrices require re-adjustment of 'center' member.

[wonkey_monkey]

Originally Posted by DTL

So auto=true do not work with zero and negative integer sum ?

auto is disabled when the sum is zero. If the sum is negative, then it divides by that negative sum, and I think that's where it's not behaving as you'd expect. But it is behaving correctly. I put the same maths through a different filter and got the same result.

The negative sum means the pixel with the positive value (the center one) makes a negative contribution to the output, while the surrounding negative coefficient pixels end up making a positive contribution. And the negative contribution of the center pixel is smaller than the positive contribution of the surrounding pixels, so the result looks like a blur.

[DTL]

May be auto (normalizing) not needed when sum=1 ? Typical kernel normalizing process is:
1. calculate sum of all members.
2. divide each member to sum.

Convolution with kernel with sum=1 at least keep DC and very low frequencies components unchanged.

[ryrynz]

Originally Posted by FranceBB

We're really lucky to have you in this community, Ferenc! I mean it.

Ferenc needs to have his details in the forum changed from "Registered User" to Avisynth GOAT.