Avisynth+

[MysteryX]

Normalizing AverageLuma and other such functions between various bit depths.

[mkver]

Originally Posted by LigH

Are you sure the reason is not the height of 62 pixels, which is not a multiple of 4, so the chroma planes in YV12 would have an odd height?

I checked different sizes and this happens e.g. on 32x32 or 32x40, too. But I couldn't reproduce it if the width is different than 32.
I have also not checked other pixel formats than YV12 (8 bit).

[pinterf]

Originally Posted by mkver

And I ran into another issue with weird chroma: The blur filter doesn't seem to like input that is 32 pixel wide:

Return BlankClip(1,32,62,pixel_type="YV12",fps=25,color=$000000,channels=0).Blur(1.4)

Thanks, I see the same issue with YV24, width=16. Will look at it.
EDIT: edge case. fixed on github

[tuanden0]

I got pink screen when I use prefetch for dfttest x64, can someone help me?
Here's my error: http://i.imgur.com/nGHLi5j.png
Here's dfttestMC: https://forum.doom9.org/showthread.p...00#post1725400
Here's my script:

LWLibavVideoSource("E:\Download\banding anime test script.mkv") #LoadSource
AssumeFPS(24000, 1001)
Trim(24478,28000)
RemoveGrain() #get rid of light banding
dfttestMC(sigma=2, lsb=true)
SmoothGrad()
DitherPost ()
flash3kyuu_deband(dither_algo=2)
Toon() #Line darken
Prefetch(4)

[DJATOM]

Setfiltermtmode("dfttest", 2)

[tuanden0]

Originally Posted by DJATOM

Setfiltermtmode("dfttest", 2)

Still pink screen
I tried setfiltermtmode 1 2 3 and 4 but the problem still there

[DJATOM]

Try dfttest(sigma=2, lsb=true) with MT mode 2 and check if it fails. It might be dfttestMC problem.

[tuanden0]

Originally Posted by DJATOM

Try dfttest(sigma=2, lsb=true) with MT mode 2 and check if it fails. It might be dfttestMC problem.

I tried what you said and the dfttest x64 has problem, i tested dfttestMC and using dfttest x86 + prefetch and It's OK

[MysteryX]

More bugs in VirtualDubFilter
https://forum.doom9.org/showthread.p...21#post1807621

[pinterf]

Thanks, registered. I will dig into the problem later, I wish I had 48 hours in a day.

[Groucho2004]

Originally Posted by tuanden0

I tried what you said and the dfttest x64 has problem

Just curious, could you try with this 64 bit version of dfttest? If that fails too, try setting "threads" to "1" in the dtftest parameters.

[manolito]

@Groucho

So you are not occasionally cantankerous any longer? How did you achieve that? I've been trying to overcome this character flaw a couple of times, but never succeeded...

[Groucho2004]

Originally Posted by manolito

@Groucho

So you are not occasionally cantankerous any longer?

Of course I am. I just felt like changing the wallpaper.

[tuanden0]

Originally Posted by Groucho2004

Just curious, could you try with this 64 bit version of dfttest? If that fails too, try setting "threads" to "1" in the dtftest parameters.

It'w not work
Frames still pink and sometime there're blue frames or red frames ?_?
Maybe I try to find another way, thank you Groucho2004

Fixed *yay*
I tried to set dfttest with force=true and it's work
SetFilterMTMode("dfttest", 2, force=true)

[pinterf]

Originally Posted by ultim

r2069 is out, and this build should be fun I encourage you all to take a look at it, as it brings some serious enhancements to MT, and then some. Let's see...
[...]
- The behavior of MT_SERIALIZED (mode 3) changed. While the earlier implementation caused all filters that are called from the serialized filter to be also serialized, now it only serializes the one and only filter that it is specified for. This has a couple of important consequences:
-- If you have a mode 3 filter towards the end of your script, the speed penalty is much-much less, since earlier basically your whole script went into mode 3, whereas now other filters can still execute in parallel. The placement of mode 3 filters in your script just got un-critical!
-- This also means it is now a really bad idea to have a big lock/mutex inside your GetFrame() instead of marking it as mode 3, because your plugin will exhibit the old behavior and you won't be able to benefit from the potential improvements at all.
-- There is also a downside: The new mode 3 theoretically does not provide the same amount of MT-protection as the old one. However, I'm not sure it matters to many plugins at all. If it does, the old mode will be re-introduced as mode 4. So keep me up-to-date!
[...]
Edit: Despite my obvious enthusiasm, this build is still a test build. Please treat it as such.

I encountered this downside.
In MT mode MT_SERIALIZED filters are really getting parallel request for the same instance, that means that their GetFrame is called in a reentrant way, just if they were MT_NICE_FILTER.

That means that the internal working buffers allocated in filter's constructor are used parallel, which is not good at all.

When you encounter strange behaviour for a filter that specify itself as MT_SERIALIZABLE (such as my FFT3DFilter version does), then try a forced mode selection for it.
SetFilterMTMode("FFT3DFilter",MT_MULTI_INSTANCE,force=true)

Or if no autoregistering happens, just specify MT_MULTI_INSTANCE and look if it makes your process any better.

[MysteryX]

Perhaps this could explain KNLMeans' image corruption with MT_SERIALIZE

[bxyhxyh]

I think many people asked partial multi-threading and partial single-threading.
So Can Avisynth+ can do them without problems?

Sometimes most part of my script don't need multithreading.
But xsharpen slows it so much when I use it with 5x super sampling.
or sometimes TDecimate crashes saying "major internal error, report this to tritical" when I try multi-thread all functions.

[pinterf]

New release, smaller bug fixes, interesting additions.

Download Avisynth+ r2287-MT

2487 (20170528), changes since v2455
-------------------------------------
# Fixes
  Blur width=16 (YV12 width=32)
  Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
  YUY2 HorizontalReduceBy2 did nothing if target width was not mod4

# optimizations
  Blur, Sharpen 10-16 bits planar and RGB64: SSE2/SSE4 (2x-4x speed)

# other modification, additions
  - New script function: int GetProcessInfo([int type = 0])
    Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
    With type=1 the function can return a bit more detailed info:
    -1: error, can't establish
    0: 32 bit DLL on 32 bit OS
    1: 32 bit DLL on 64 bit OS (WoW64 process)
    2: 64 bit DLL
  - ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
  - ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
    (note: greyscale through devIL can be corrupt with some formats, use png)
  - ImageWriter: flip greyscale images vertically (except "raw" format)
  - SubTitle: new parameter "font_filename" allows using non-installed fonts
  - Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
  - Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
    (not the script text!)
  - SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
      Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
      SubTitle(Title,utf8=true)
  - New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(), 
    they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively

And now I have to dig into those nasty MT things.

[raffriff42]

I'm having a lot of problems with this version on both vdub 1.10 and vdubFM, even with the simplest script, namely, "Version()"

[*] AVI: Opening file "E:\Data\Downloads\_test.avs"

[i] AVI: Avisynth detected. Extended error handling enabled.
[*] Beginning dub operation.

[i] Dub: Input (decompression) format is: RGB888.

[i] Dub: Output (compression) format is: RGB888.
[*] Ending operation.

[E] Error: Avisynth read error:
    Avisynth: script open failed!

I loaded the Version script and selected File, Run video analysis pass to check framerate. I suspected a problem because another movie I had opened with both FFMpegSource and LibAVSource played verrry slowly and then crashed.

[E] Error: Avisynth read error:
    Could not allocate video frame. Out of memory. memory_max = 536870912, 
    memory_used = 3686451 Request=3686431
    (E:\Data\Downloads\_misc.avs, line 1023)

[MysteryX]

Originally Posted by pinterf

And now I have to dig into those nasty MT things.

The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?