Avisynth+

[StainlessS]

That's an interesting question. I really wonder if "return" returns a clip or a number. In my current mental state, I would bet on ... number. I should try it.

function Fct2(clip c) {return c.info}

function Fct1(clip c) {
c # means explicitly: last = c
Fct2()
z=c.Invert
x=sin(.5)
sin(.5)
return Last # return result of Fct2(), Colorbars with Info
}

Colorbars.killaudio

Fct1()


EDIT: Also, I would disagree with first comment, # means implicitly: last = c

[TheFluff]

That's an interesting question. I really wonder if "return" returns a clip or a number. In my current mental state, I would bet on ... number. I should try it.
Last only works on clips (more specifically, every expression that isn't an explicit assignment and happens to evaluate to a clip assigns to last). It's a pretty unintuitive mechanism and I'd consider it a pretty awful hack in most languages but it is kinda excusable in a toy DSL like Avisynth script. Perl has something similar with $_, but at least it's more consistent about it and happily admits it's not really intended to write readable programs.

See here (https://forum.doom9.org/showthread.php?p=1651728#post1651728) and the surrounding posts for an extensive earlier discussion on attempting to make it less weird. The tl;dr is that Avisynth script kinda needs an assignment operator that is actually a real operator rather than a special type of expression, but good luck with that.

[LigH]

3) implicit assignments to last (all expressions that aren't one of the two first types and evaluate to a clip)

I see. So the statement "return last" is not ambiguous here. Rather the single "sin(.5)" without assignment is misleading.

Perl has something similar with $_

Pascal has the reserved variable "Result" to explicitly assign a return value in the scope of a function.

[StainlessS]

Whoa, that surprised me when removing the 'Return Last' from Fct1(),
The script's return value was not a video clip, (Is a float, 0.479426).

EDIT: Nice post Fluffy.

[TheFluff]

Pascal has the reserved variable "Result" to explicitly assign a return value in the scope of a function.

That's not the same thing at all. Pascal doesn't have a C-like "return <expression>" mechanism, so instead you assign to a special variable (either "result" or a variable with the same name as the function) to set the return value from a function.

$_ in Perl and last in Avisynth are special in that they act as a default parameter to many functions if no other suitable value is given. For example, in Perl saying "print;" is the same as saying "print($_);" much like how in Avisynth "blur()" is the same as "blur(last)". Since Perl is an imperative language, it doesn't need the implicit assignment part of the equation, though - function calls can just have side effects and mutate $_ with no problems (you still get implicit assignment to $_ when using it as an implicit iterator in loops though, but that's beside the point).

Avisynth script, however, is a quite poor excuse for a functional language that wants to pretend it is imperative, or perhaps more accurately, it's a schizophrenian language that has one data type that is purely functional and lazily evaluated, paired with a bunch of imperative scripting functionality that very much isn't. What you're writing in Avisynth script is a composition of functions (https://en.wikipedia.org/wiki/Function_composition_(computer_science)) (in other words, the filter chain), so from the script's point of view, clip variables are effectively immutable. Hence you get the hack that is the implicit assignment to last based on what the expression evaluates to - the clip data type is effectively living in a different programming language than everything else in Avisynth script and has its own semantics.

Arguably, the entire "assignment" part of clip variables is confusing, since you're not really assigning a value to a variable at all.

[MysteryX]

That deadlock thing is hard to catch. I was working on the problem during December, now I have returned to it.
I applied the latest ConditionalFilter code changes to the MT-pfmod branch, and this works.

Here's the x86 library of MT-pfmod with conditional filters (https://mega.nz/#!yVBk0BzJ!jHiGfGiFAzho2HQX-0kYR4w-UIFX8TXYoZFQ49ums_Q), if anyone wants to play with it (no 16-bit stuff in this version).


len=1
w=64
h=48
c1=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$008080)
c2=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$108080) # diff 16
c3=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$308080) # diff 32
c4=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$608080) # diff 48 -> diff (-)96
c=c1+c2+c3+c4
c.Loop(10000)
# this will deadlock sooner or later or never, more Prefetch makes deadlock to appear, even more -> deadlock sooner
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
/* This works for any Prefetch, no dependancy between them
c1=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
c2=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
Stackvertical(c1,c2)
*/
ConvertToRGB32() #additional filters modify timing thus, frame evaluation order/cache hit order in MT
ConvertToRGB24()
ConvertToRGB32()
ConvertToRGB24()
Prefetch(100)


No deadlock or anything, but CPU isn't being well utilized either. No problem found with frame order.

FPS (min | max | average): 87.34 | 14329 | 1564
Memory usage (phys | virt): 32 | 28 MiB
Thread count: 112
CPU usage (average): 17%

Strangely, if I run FrameRateConverter(debug=true) with this version, the texts are displayed correctly for the first frame then only gibberish is displayed for additional frames.

In contrast, the latest release of Avisynth causes occasional crashes even without MT.

[gaak]

Hi,

Cannot get this script to run to completion w/ i386 r2455:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
Import("\MKVideo Encoder NV\AVS Scripts MT\LoadPlugins.avs")
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
Spline64Resize(1280, 720)
RoboCrop(Laced=False, Align=True)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)", strength=200, smode=5, secure=true)
Prefetch(6)

Have tried Prefetch values from 3 to 7. As the value is increased the script completion percentage goes up but never past 85% when it crashes. Any other settings I can try?

Thanks.

[Gavino]

Whoa, that surprised me when removing the 'Return Last' from Fct1(),
The script's return value was not a video clip, (Is a float, 0.479426).

No surprise, really:
http://avisynth.nl/index.php/Grammar

if return is not present in the final executable statement of a script (or script block), it is implied – the statement is treated as if return was present.

So if the last statement of a function is "sin(.5)", that's what will be returned.

[StainlessS]

Clever Cloggs :)

[Gavino]

Also note:
The full AviSynth grammar - Closing_Remarks (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Closing_Remarks)

If there is no (explicit or implicit) return, a void value (ie a value of the 'undefined' type) is returned. For example, this will happen if the last statement is an assignment.

[StainlessS]

Thank you master (slap, slap).

[tebasuna51]

SetFilterMTMode("DGDecodeNV", 3)
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
...

As the value is increased the script completion percentage goes up but never past 85% when it crashes.

Maybe?
SetFilterMTMode("DGSource", 3)

[Reel.Deel]

Maybe?
SetFilterMTMode("DGSource", 3)

I don't think that's the problem, even thought SetFilterMTMode("DGDecodeNV", 3) is incorrect, as you've already pointed out. AviSynth+ automatically recognizes source filters. If it sees a source filter which has no MT-mode specified, it will automatically use mode 3 instead of the default MT mode. This has been the behavior since r2069.

Hi,

Cannot get this script to run to completion w/ i386 r2455:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
Import("\MKVideo Encoder NV\AVS Scripts MT\LoadPlugins.avs")
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
Spline64Resize(1280, 720)
RoboCrop(Laced=False, Align=True)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)", strength=200, smode=5, secure=true)
Prefetch(6)

Have tried Prefetch values from 3 to 7. As the value is increased the script completion percentage goes up but never past 85% when it crashes. Any other settings I can try?

Thanks.

Try running the script in AVSMeter with SetLogParams("stdout", 4) at the very beginning of your script. The logging facility in AVS+ will automatically log errors, and will issue warnings and notes about potential problems, buggy plugins, suboptimal settings, etc. If that does not show anything useful then try testing RoboCrop and DegrainMedian separately to see if they crash or not. Also make sure you're using the latest MaskTools2 and RgTools.

[gaak]

SetLogParams("stdout", 4)[/FONT] at the very beginning of your script. The logging facility in AVS+ will automatically log errors, and will issue warnings and notes about potential problems, buggy plugins, suboptimal settings, etc. If that does not show anything useful then try testing RoboCrop and DegrainMedian separately to see if they crash or not. Also make sure you're using the latest MaskTools2 and RgTools.

Thanks for the tip. I did what you advised and got this:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\SysWOW64\KERNELBASE.dll
Address: 0x75EAB782

I guess that falls under the "not show anything useful" heading. I'll try running the other filters separately to narrow the field.

[Groucho2004]

Thanks for the tip. I did what you advised and got this:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\SysWOW64\KERNELBASE.dll
Address: 0x75EAB782

I guess that falls under the "not show anything useful" heading. I'll try running the other filters separately to narrow the field.It may be useful to see which filter versions you're using. Run AVSMeter with the switches "-avsinfo -log". This will generate a log file (avsinfo.log). Post the content of that log file.

[gaak]

It may be useful to see which filter versions you're using. Run AVSMeter with the switches "-avsinfo -log". This will generate a log file (avsinfo.log). Post the content of that log file.

Found the problem. It was an old plugin (SplineResize.dll). Run with it, crash. With out it, no crash. Found a replacement: ResizersPack4.5.avsi. Slower but better quality and it works. Thanks to Reel.Deel and Groucho2004 for your guidance and software.

[LigH]

If the resamplers in the AviSynth kernel are not versatile enough for you, you might also be interested in ResampleHQ (http://svn.int64.org/viewvc/int64/resamplehq/doc/index.html). The features in the Resizers Functions Pack 4.5 (https://forum.videohelp.com/threads/369143-ResizersPack-MasksPack-PlaygroundPack-SmoothContrast-Logo-mod-functions#post2364034) by Dogway are rather special, though, and I would not be sure which of them are portable to new color spaces/configurations of AviSynth 2.6 and AviSynth+ without quirks, may require general updates...

[gaak]

If the resamplers in the AviSynth kernel are not versatile enough for you, you might also be interested in ResampleHQ (http://svn.int64.org/viewvc/int64/resamplehq/doc/index.html).

Thank you for the suggestion. Will give it a try. Right now looking into nnedi3_resize16.avsi. Seems to give good results up sizing, now seeing how well it does down sizing.

[LigH]

Probably not remarkably great. You should learn how the parts of each algorithm work, to understand which purpose they serve. "EDI" (Edge Directed Interpolation) functions are especially made to aid upsampling. I see no reason to believe that downsampling would be improved by it, the way it works.

And it is not even specifically related to AviSynth+. Another thread derailing... it's getting common in the last time. Well, this time I am involved... :o

[Groucho2004]

NNEDI / EEDI can't downscale. What they do is double the image height. So, this code will double both image width and height:
nnedi3(dh = true).turnleft().nnedi3(dh = true).turnright()

For downscaling, nnedi3_resize16 uses Dither_resize16, nnedi3 isn't involved at all.

[LigH]

Imagine I want to avoid autoloading for some plugins, prefer explicit loading for specific reasons; and I have such plugins in both 32-bit and 64-bit flavour.

Does AviSynth+ provide a core {function|constant} to check whether my script runs in a 32 or 64 bit environment, to calculate a base plugin directory accordingly? Something like:

MyPluginBase = "D:\AviSynthPlugins\special\" + (Is64bit() ? "x64" : "x86")

[Groucho2004]

Imagine I want to avoid autoloading for some plugins, prefer explicit loading for specific reasons; and I have such plugins in both 32-bit and 64-bit flavour.

Does AviSynth+ provide a core {function|constant} to check whether my script runs in a 32 or 64 bit environment, to calculate a base plugin directory accordingly? Something like:

MyPluginBase = "D:\AviSynthPlugins\special\" + (Is64bit() ? "x64" : "x86")I don't think Avisynth+ has an option to report its bitness. However, this could very easily be added as a function or constant:

if (sizeof(void*) == 8)
//64 bit module on Win64



With a bit more code this could be extended to report a WoW64 process (32 bit process on 64 bit Windows) and consequently a plain 32 bit process (error handling mostly omitted in the example):
#define PROCESS_32_ON_32 0
#define PROCESS_32_ON_64 1
#define PROCESS_64_ON_64 2

...

int ProcessType()
{
if (sizeof(void*) == 8)
return PROCESS_64_ON_64; //64 on 64

BOOL bWoW64Process = FALSE;
typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
LPFN_ISWOW64PROCESS fnIsWow64Process;
HMODULE hKernel32 = GetModuleHandle("kernel32.dll");
if (hKernel32 == NULL)
return -1;

fnIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(hKernel32, "IsWow64Process");
if (fnIsWow64Process != NULL)
fnIsWow64Process(GetCurrentProcess(), &bWoW64Process);
else
return -1;

if (bWoW64Process)
return PROCESS_32_ON_64; //WoW64

return PROCESS_32_ON_32;
}

[mkver]

I seem to have hit a bug in Overlay, namely the "lighten"-mode:

Maske=BlankClip(1,156,42,pixel_type="YV24",fps=25,color=$000000,channels=0)
Mard=BlankClip(1,56,42,pixel_type="YV24",fps=25,color=$000000,channels=0)
Mard2= Maske.Overlay(Mard,mode="Lighten")
Return Mard2

I expect to get a 156x42 YV24 clip with Y constantly being 16 and U and V 128; instead there is a 56x25 rectangle with top left corner (0,17) in which Y=128 and the chroma values are random garbage (changes every time I open the script, so maybe it is using memory that it shouldn't use).
Info() reported the following CPU instruction sets: SSE4.2, SSE3, AVX, AVX2, FMA3, F16C.
[Edit]: I am using 64bit r2455. It works with standard Avisynth 2.6.

[raffriff42]

re: mkver's issue: if either clip is at least 620px wide (more or less), the problem goes away.

[pinterf]

Thanks for the report. Lighten had this problem since r2290, as a victim of hbd transition. Fixed on git. The problem occured when base and overlay clip had different widths (pitches)

[pinterf]

RGBAdjust (http://avisynth.nl/index.php/RGBAdjust) - gain arguments autoscale (https://forum.doom9.org/showthread.php?p=1805251#post1805251), but bias does not. Levels - no arguments autoscale. Just noting it in passing.
RgbAdjust gain is not related to high-bit-depth scaling. It is simple multiplier, so no action or fix needed here on avs+ side (Slowly I'm processing recent posts)

[pinterf]

I'm still not able to solve the stability of the multithread-ScriptClip-with-nested-ConditionalFunctions problem (deadlock).

But there had been a couple of fixes and small additions since r2455, what's your opinion about a maintenance release soon?

- Fix: Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
- Fix: YUY2 HorizontalReduceBy2 did nothing if target width was not mod4
- 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
- (project can be compiled using gcc)
- 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

What other (small) issues or feature requests do you know?

[LigH]

Implement a core function / variable reporting whether the current process uses 32 or 64 bit code (maybe even WoW64)... not urgent, only if you get immediately a good idea how to realize it sensibly.

[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)

As before: Info() reported the following CPU instruction sets: SSE4.2, SSE3, AVX, AVX2, FMA3, F16C; 64bit r2455.

[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?

[MysteryX]

Normalizing AverageLuma and other such functions between various bit depths.

[mkver]

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]

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 (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins), can someone help me?
Here's my error: http://i.imgur.com/nGHLi5j.png
Here's dfttestMC: https://forum.doom9.org/showthread.php?p=1725400#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]

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]

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.php?p=1807621#post1807621

[pinterf]

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

[Groucho2004]

I tried what you said and the dfttest x64 has problemJust curious, could you try with this 64 bit version (https://www.dropbox.com/s/hm7t5yqvyzu9kk6/dfttest194_64.7z?dl=0) 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... :devil:

[Groucho2004]

@Groucho

So you are not occasionally cantankerous any longer?Of course I am. I just felt like changing the wallpaper.

[tuanden0]

Just curious, could you try with this 64 bit version (https://www.dropbox.com/s/hm7t5yqvyzu9kk6/dfttest194_64.7z?dl=0) 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]

r2069 (http://avs-plus.net/builds) 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 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2487-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]

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?