Avisynth+

[StainlessS]

Fixed, sorry.

If size specifier is wrong then gets only first four bytes (half of __int64 start, bytes 0 to 3) from stack for vsprintf start arg,
vsprintf count would come from 2nd half (4 bytes, bytes 4 to 7) of start, so count on stack would NOT be accessed at all.

EDIT: for other readers, the vsprintf mentioned stuff, think Wonkey is using something like this


int __cdecl dprintf(char* fmt, ...) {
char printString[2048]="WonkeyWilly: "; // Must be nul Termed, eg "Test: " or ""
char *p=printString;
for(;*p++;);
--p; // @ null term
va_list argp;
va_start(argp, fmt);
vsprintf(p, fmt, argp);
va_end(argp);
for(;*p++;);
--p; // @ null term
if(printString == p || p[-1] != '\n') {
p[0]='\n'; // append n/l if not there already
p[1]='\0';
}
OutputDebugString(printString);
return int(p-printString); // strlen printString
}


EDIT:
This is my GetAudio:

void __stdcall tracker::GetAudio(void* buffer, __int64 start, __int64 count, IScriptEnvironment* env) {
debug("GetAudio: %d,%d", start, count);
if (start == -0x5452414b) {
switch (count) {
case 0: {
*((int*)buffer) = 0x5452414b;
} break;
}
} else {
child->GetAudio(buffer, start, count, env);
}
}


and this is my call to GetAudio, in the constructor of another filter:

int check = 0;
child->GetAudio(&check, 0x5452414b, 0, env);
debug("%d", check);



Not sure that I'm understandin' the -ve value in red [0x5452414b = 'TRAK'].

[wonkey_monkey]

It's a magic number to flip GetAudio into providing something other than audio. Negative numbers were making it crash, so I must have copied-and-pasted mid-testing. The comparison in GetAudio should be with the positive number.

I've abandoned that idea now because of the possible caching/bounds checking issue (something is intercepting the call and aborting it because the clip doesn't have that many samples). Now I'm calling it with start=0 and passing the magic number in the buffer. I'm not sure this will work either, because it's possible the returned values for a given start/count will change, and if something is caching them then it will interfere.

[StainlessS]

Avs+ Feature request:

Layer with YV24 support would be nice :) [think I requested this in avs Standard thread]

I would like to mod S_ExLogo() for YV24, currently only YUY2 [Layer also supports RGB32 & under avs+ RGB64].

S_ExLogo[YUY2 Only]:- https://forum.doom9.org/showthread.php?t=154559&highlight=S_ExLogo

# Based on Dekafka (YUY2 Only)
#
# HHHHHH s_Exlogo, samples above and below (shown left as 'H')
# VLLLLLLV and combines them into a horizontal bar.
# VLLLLLLV Samples left and right and combines them into a vertical bar (show as 'V'.
# VLLLLLLV Logo area shown as 'L'.
# VLLLLLLV These bars may or may not be blurred, and are then resized to fit
# HHHHHH the logo area. The resized bars are then mixed together based
# on arg "Spow" and the ratio of length of Vertical bars to length
# of horizontal bars. Finally, the resultant de-logo'd area is
# Layer'ed onto the clip using the Amount arg.
# Clipping can be set so as to avoid eg sampling letterboxing when
# blurring out the logo (would normally result in nasty black
# block instead of a nasty logo).
#
# Basic usage:-
# s_ExLogo(clip, int LogoX, int LogoY, int LogoW, Int LogoH)


S_ExLogo is a Mod of DeKafka:- http://avisynth.nl/index.php/DeKafka

EDIT: Despite what it says on the Wiki, Dekafka supports only YUY2, RGB32, RGB64(same as Layer).
Note this version works with any format, but there will be a RGB32 conversion. [NO THERE WILL NOT - at least not from eg YV12 or YV24]

EDIT: Only real reason for YV24 desirability, is to support ODD X coords.

[pinterf]

Good catch, Layer is somewhat retarded at the moment. YUY2 is supported so there should be no complain why it's missing other YUV formats. Nor it does support planar RGB, what a world we live in.
Problem registered, and will be solved, well before the next lunar eclipse (but not this week), thanks for the report :)

[StainlessS]

and will be solved, well before the next lunar eclipse
Terrific [EDIT: no hurry at all] , Layer is not nearly as RAM greedy and faster than Overlay, and often a better choice if colorspace supported.
Me is a happy bunny, Thanx.

EDIT: faster than Overlay
S_ExLogo may not be the best DeLogo filter, but it does a fair job and 'goes like the clappers' [real fast in comparison to most delogo'ers].

[BlockABoots]

Excuses my ignorance, but what is the latest release of avisynth (or what ever it has morphed into)?

Is there a better fork to use than standard avisynth, as i used to use AvsPmod in conjunction with avisynth is there an all in one app now a days?

[StainlessS]

BockABoots,
Here, Avisynth+ r2772, usually via pinterf sig link "My Avisynth+ repo on github", and then click Releases tab:- https://github.com/pinterf/AviSynthPlus/releases

Above (current avs+) is the only one that everybody should be using.

[BlockABoots]

Thanks

[manolito]

Above (current avs+) is the only one that everybody should be using.

Please allow me to disagree... :devil:

On an old computer with low system RAM and a single core CPU AVS+ does run, but it is way slower than plain vanilla AVS 2.60 (or 2.61 Beta). The only reason to use AVS+ on such a computer is if the user needs the high bit depth and extented color space features of AVS+.

Even on a much newer Core i5 CPU with 8 GB system RAM I found that I had to turn off multithreading completely when using ffms2 as the source filter (in the default serialized mode). Speed dropped to a crawl when the prefetch value was set to 4.

So I do see a few good reasons to prefer AVS 2.60 over AVS+.


Cheers
manolito

[wonkey_monkey]

Is it possible to have an AVSValue with an ArraySize() of 0?

[Groucho2004]

Please allow me to disagree... :devil:

On an old computer with low system RAM and a single core CPU AVS+ does run, but it is way slower than plain vanilla AVS 2.60 (or 2.61 Beta).
Can you post an example script which would show that classic Avisynth uses less memory than AVS+? My expierence is that AVS+ is much more efficient using the available memory.

[StainlessS]

My expierence is that AVS+ is much more efficient using the available memory.
Mine too.

Is it possible to have an AVSValue with an ArraySize() of 0?
Yes.

FrameSel plugin, 2nd arg is array of frame numbers,
env->AddFunction("FrameSel", "ci*[SCmd]s[Cmd]s[Show]b[Ver]b[Reject]b[Ordered]b[Debug]b[Extract]i", Create_FrameSel, 0);,

AVSValue __cdecl Create_FrameSel(AVSValue args, void* user_data, IScriptEnvironment* env) {
PClip _child = args[0].AsClip(); // Source Clip, No Default
AVSValue _Frames = args[1]; // Frames, Array of frame numbers as filter arguments
const char *_SCmd = args[2].AsString(NULL); // SCmd, Frames in string, defaults to NULL
const char *_Cmd = args[3].AsString(NULL); // Cmd, Frames Cmd File, defaults to NULL
bool _show = args[4].AsBool(false); // show, show frame numbers
bool _ver = args[5].AsBool(false); // ver, show version
bool _reject = args[6].AsBool(false); // Reject Mode
bool _ordered= args[7].AsBool(true); // ordered Mode
bool _debug = args[8].AsBool(false); // debug
int _extract = args[9].AsInt(1); // extract

if(_SCmd && *_SCmd == '\0') _SCmd=NULL; // Convert user supplied "" to NULL
if(_Cmd && *_Cmd == '\0') _Cmd=NULL; // Convert user supplied "" to NULL

// if(_Cmd==NULL && _SCmd==NULL && _Frames.ArraySize()==0)
// return _child; // No frames specified at all, return orig clip as if no filter.

return new FrameSel(_child,_Frames,_SCmd,_Cmd,_show,_ver,_reject,_ordered,_debug,_extract,env);
}
Above, is actually switched off (commented out), but still shows that you can have ArraySize==0 when no frames specified.

[wonkey_monkey]

Oh, sorry, I meant is it possible to construct an AVSValue with an ArraySize() of zero? I tried AVSValue x = AVSValue() but it had an ArraySize() of 1.

I'm using two creator functions which both instantiate the same class - one includes an i+ in its parameter definition, the other doesn't (but does have all the other variables). I also tried passing NULL but C++ wouldn't let me compare an AVSValue with NULL.

It's very easy to work around but I always try to strive for a neat solution (even if my source code doesn't suggest it).

[StainlessS]

For anything like that, I tend to look at Avisynth VERSION 3 header (v2.58) with baked code.


class AVSValue {
public:

AVSValue() { type = 'v'; }
AVSValue(IClip* c) { type = 'c'; clip = c; if (c) c->AddRef(); }
AVSValue(const PClip& c) { type = 'c'; clip = c.GetPointerWithAddRef(); }
AVSValue(bool b) { type = 'b'; boolean = b; }
AVSValue(int i) { type = 'i'; integer = i; }
// AVSValue(__int64 l) { type = 'l'; longlong = l; }
AVSValue(float f) { type = 'f'; floating_pt = f; }
AVSValue(double f) { type = 'f'; floating_pt = float(f); }
AVSValue(const char* s) { type = 's'; string = s; }
AVSValue(const AVSValue* a, int size) { type = 'a'; array = a; array_size = size; }
AVSValue(const AVSValue& v) { Assign(&v, true); }

~AVSValue() { if (IsClip() && clip) clip->Release(); }
AVSValue& operator=(const AVSValue& v) { Assign(&v, false); return *this; }

// Note that we transparently allow 'int' to be treated as 'float'.
// There are no int<->bool conversions, though.

bool Defined() const { return type != 'v'; }
bool IsClip() const { return type == 'c'; }
bool IsBool() const { return type == 'b'; }
bool IsInt() const { return type == 'i'; }
// bool IsLong() const { return (type == 'l'|| type == 'i'); }
bool IsFloat() const { return type == 'f' || type == 'i'; }
bool IsString() const { return type == 's'; }
bool IsArray() const { return type == 'a'; }

PClip AsClip() const { _ASSERTE(IsClip()); return IsClip()?clip:0; }
bool AsBool() const { _ASSERTE(IsBool()); return boolean; }
int AsInt() const { _ASSERTE(IsInt()); return integer; }
// int AsLong() const { _ASSERTE(IsLong()); return longlong; }
const char* AsString() const { _ASSERTE(IsString()); return IsString()?string:0; }
double AsFloat() const { _ASSERTE(IsFloat()); return IsInt()?integer:floating_pt; }

bool AsBool(bool def) const { _ASSERTE(IsBool()||!Defined()); return IsBool() ? boolean : def; }
int AsInt(int def) const { _ASSERTE(IsInt()||!Defined()); return IsInt() ? integer : def; }
double AsFloat(double def) const { _ASSERTE(IsFloat()||!Defined()); return IsInt() ? integer : type=='f' ? floating_pt : def; }
const char* AsString(const char* def) const { _ASSERTE(IsString()||!Defined()); return IsString() ? string : def; }

int ArraySize() const { _ASSERTE(IsArray()); return IsArray()?array_size:1; }

const AVSValue& operator[](int index) const {
_ASSERTE(IsArray() && index>=0 && index<array_size);
return (IsArray() && index>=0 && index<array_size) ? array[index] : *this;
}

private:

short type; // 'a'rray, 'c'lip, 'b'ool, 'i'nt, 'f'loat, 's'tring, 'v'oid, or 'l'ong
short array_size;
union {
IClip* clip;
bool boolean;
int integer;
float floating_pt;
const char* string;
const AVSValue* array;
// __int64 longlong;
};

void Assign(const AVSValue* src, bool init) {
if (src->IsClip() && src->clip)
src->clip->AddRef();
if (!init && IsClip() && clip)
clip->Release();
// make sure this copies the whole struct!
((__int32*)this)[0] = ((__int32*)src)[0];
((__int32*)this)[1] = ((__int32*)src)[1];
}
};


Looks like you need to give an array size.

AVSValue(const AVSValue* a, int size) { type = 'a'; array = a; array_size = size; }

int ArraySize() const { _ASSERTE(IsArray()); return IsArray()?array_size:1; }


EDIT: does this not work ?

AVSValue a[0];

Nope, error C2466: cannot allocate an array of constant size 0

EDIT: Some existing code that works,

AVSValue std1[STD_SIZE] = {child,0,0,0,0,0,0,false};
AVSValue xtra1[XTRA_SIZE];
xtra1[XTRA_RGBIX] = matrix;
std1[STD_FRAME] = n;

AVSValue std2[STD_SIZE] = {child2,0,0,0,0,0,0,false};
AVSValue xtra2[XTRA_SIZE];
xtra2[XTRA_RGBIX] = matrix;
std2[STD_FRAME] = n2;

MYLO mylo;

RT_MYstats_Lo(RTHIST_F,AVSValue(std1,STD_SIZE),AVSValue(xtra1,XTRA_SIZE),mylo,myName,env,hist1);
RT_MYstats_Lo(RTHIST_F,AVSValue(std2,STD_SIZE),AVSValue(xtra2,XTRA_SIZE),mylo,myName,env,hist2);

[wonkey_monkey]

Oh, I guess I can just use IsArray() instead then, thanks for the help. Returning 1 confused me into thinking it was being treated as an array.

[wonkey_monkey]

It's just occured to me that the "child" clip in the GenericVideoFilter constructor shouldn't really be called "child", should it? It should be "parent".

Not suggesting it should be changed, of course, just making an observation!

[manolito]

The files-only section also contains an x86 build for SSE-only processors.

Thanks for still supporting folks with non-SSE2 CPUs...

Just found out that DirectShowSource.dll from the Non-SSE2 folder seems to be broken. It sure does not work without SSE2. Using the older DirectShowSource.dll from the qyot27 build avisynth _r2741-g0cb91abf-20180803 fixes it.


Cheers
manolito

[manolito]

Can you post an example script which would show that classic Avisynth uses less memory than AVS+? My expierence is that AVS+ is much more efficient using the available memory.

Not on my ancient WinXP machine...

Specs:
https://i.postimg.cc/QxjQnyS4/specs.png (https://postimages.org/)


I tested it again using a short HD clip and converted it to DVD. I used two scripts, the first one is very basic, the second one uses jm_fps (frame rate interpolation) and is much slower. These are the scripts:

Easy.avs:
Video = DSS2("I:\test.webm", fps = 30, preroll = 15, lavs = "l0", lavd = "l0")
Audio = DirectShowSource("I:\test.webm", video=false)

Video = Video.ConvertToYV12()
Video = Video.Spline36Resize(720,576)
Video = Video.ChangeFPS(25)

AudioDub(Video, Audio)


Hard.avs:
Video = DSS2("I:\test.webm", fps = 30, preroll = 15, lavs = "l0", lavd = "l0")
Audio = DirectShowSource("I:\test.webm", video=false)

Video = Video.ConvertToYV12()
Video = Video.Spline36Resize(720,576)
Video = Video.jm_fps(25)

AudioDub(Video, Audio)


And these are the AVSMeter results for plain vanilla AVS 2.61 Alpha and for the current AVS+ version:

https://i.postimg.cc/yYwZCpTC/AVS-2-61-Easy.png (https://postimages.org/)

https://i.postimg.cc/q7pgpPhS/AVS-Easy.png (https://postimages.org/)


https://i.postimg.cc/gkRvjPj2/AVS-2-61-Hard.png (https://postimages.org/)

https://i.postimg.cc/B6kKZhGF/AVS-Hard.png (https://postimages.org/)bilder hochladen free (https://postimages.org/de/)


For me this is enough reason to not use AVS+ on this computer. It is slow enough as it is, but slowing it down even more without any additional benefit does not make sense to me.


Cheers
manolito

[qyot27]

Just found out that DirectShowSource.dll from the Non-SSE2 folder seems to be broken. It sure does not work without SSE2. Using the older DirectShowSource.dll from the qyot27 build avisynth _r2741-g0cb91abf-20180803 fixes it.
DirectShowSource.dll is the only plugin in the main source tree that actually requires linking in an external library - the baseclasses from the Windows 7 SDK. Said baseclasses library doesn't set a processor architecture, so on newer MSVC it just defaults to SSE2 unless overridden manually.

Being a system library, I'm pretty sure I always make sure to compile that piece using /ARCH:IA32 (i.e., none at all) for 32-bit.

[Groucho2004]

Not on my ancient WinXP machine...I used basically the same script as your "hard.avs" with a 720p clip and here are the results with my i5:

AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp

FPS (min | max | average): 18.57 | 198864 | 46.70
Process memory usage (max): 592 MiB
Thread count: 13
CPU usage (average): 24.9%


AviSynth+ 0.1 (r2772, MT, i386)

FPS (min | max | average): 18.64 | 137675 | 46.88
Process memory usage (max): 142 MiB
Thread count: 20
CPU usage (average): 24.6%


Edit: I just remembered that Avisynth (classic, not sure about AVS+) sets "SetMemoryMax()" according to the available memory:
MEMORYSTATUS memstatus;
GlobalMemoryStatus(&memstatus);
// Minimum 16MB
// else physical memory/4
// Maximum 0.5GB
if (memstatus.dwAvailPhys > 64*1024*1024)
memory_max = (__int64)memstatus.dwAvailPhys >> 2;
else
memory_max = 16*1024*1024;

if (memory_max <= 0 || memory_max > 512*1024*1024) // More than 0.5GB
memory_max = 512*1024*1024;

In your case this is probably 128 MiB. That would explain the rather moderate memory usage of Avisynth 2.6.1 in your test.

[TheFluff]

The reason Avs+ is slower on a 32-bit non-SSE machine might also be because IIRC a bunch of ancient MMX optimizations that were at best completely useless on any sort of reasonable hardware were removed from Avs+ pretty early on. Don't expect software that is actually maintained to keep optimization for ancient hardware forever.

If Avs+ is slower on an i5 though you're probably doing something wrong.

[Groucho2004]

If Avs+ is slower on an i5 though you're probably doing something wrong.It's not. In the example above, heavy use of mvtools mainly contributes to the speed. Simple internal operations such as resizing are much faster with AVS+.

[tormento]

Plus, if you have a x64 capable CPU, I strongly suggest to jump on x64 train, where FPS can see up to 10-25% increase. Nowadays a Windows 10 x64 Pro license can be found on Amazon for a few bucks. Nonsense to stay on ancient XP.

[manolito]

Sorry I really cannot live without a couple of older 32-bit plugins. AVS64 is definitely not for me...

[Groucho2004]

Sorry I really cannot live without a couple of older 32-bit plugins.Just curious - which ones?

[ChaosKing]

Can you give an example? I never found a non working plugin for avs+.

[manolito]

Just curious - which ones?

The most important one is LogoAway which is a 32-bit VDub plugin. Easy to use, very nice results and relatively fast. I tried most of the available logo removers, and this one did beat them all.

I just glanced over the list of available 64-bit AVS plugins, and this list has grown considerably. With a little effort I could probably find 64-bit replacements for most of my plugins. But there is another reason why I am not going to do this:

I do video conversions on at least 3 different computers. There's the notorious ancient WinXP machine, there is one Win7-32 laptop (only 2GB Ram, the 64-bit Win7 version is too slow on this laptop, constant swapping), and another Win7-64bit laptop with 8GB RAM. I have no intention to maintain 3 different AVS plugins folders, it is hard enough for me to maintain just one plugins folder. Getting working plugin versions for several scripts like QTGMC, LSFMod, Srestore or Finesharp took me a long time, and I want to keep this configuration. I know that if everything works on the WinXP machine then it will also work on the other computers. Maybe a little bit slower than it could, but no headaches for me.


Cheers
manolito

[manolito]

Can you give an example? I never found a non working plugin for avs+.

What tormento suggested is go the 64-bit route exclusively. For AVS+ the installer suggests to install both the 32-bit and the 64-bit versions in parallel (of course only if a 64-bit OS is detected).

While having both versions installed at the same time is possible, you can not mix 32-bit and 64-bit plugins in the same script. It's either one or the other, you need to keep the plugins separate.


Cheers
manolito

[lansing]

The most important one is LogoAway which is a 32-bit VDub plugin. Easy to use, very nice results and relatively fast. I tried most of the available logo removers, and this one did beat them all.

I just glanced over the list of available 64-bit AVS plugins, and this list has grown considerably. With a little effort I could probably find 64-bit replacements for most of my plugins. But there is another reason why I am not going to do this:

I do video conversions on at least 3 different computers. There's the notorious ancient WinXP machine, there is one Win7-32 laptop (only 2GB Ram, the 64-bit Win7 version is too slow on this laptop, constant swapping), and another Win7-64bit laptop with 8GB RAM. I have no intention to maintain 3 different AVS plugins folders, it is hard enough for me to maintain just one plugins folder. Getting working plugin versions for several scripts like QTGMC, LSFMod, Srestore or Finesharp took me a long time, and I want to keep this configuration. I know that if everything works on the WinXP machine then it will also work on the other computers. Maybe a little bit slower than it could, but no headaches for me.


Cheers
manolito
It might be a good time to buy new computers

https://www.newegg.com/Product/Product.aspx?Item=N82E16819113480

Ryzen 5 4-core/8 threads for $150, that will fix all your problem. Heck you can probably build three under $1000.

[real.finder]

While having both versions installed at the same time is possible, you can not mix 32-bit and 64-bit plugins in the same script. It's either one or the other, you need to keep the plugins separate.


Cheers
manolito

you can mix 32-bit and 64-bit plugins in the same script with mpp (mp_pipeline), you can even run avs+ inside it even if you have old avs installed by using "### dll:"

[Stereodude]

Just curious - which ones?
AFAIK, MCTD is 32-bit only so far. However, MP Pipeline lets you use it in an otherwise x64 process.

[poisondeathray]

MTCD works ok in avs+ x64 , just not higher bit depths (except in vapoursynth)

hdragc is one that is still x86 only (but you can get similar results with smoothcurve x64)

[wonkey_monkey]

Using multiline syntax (".\"), is there any way to comment out a line in the middle of a set of lines? For example:

version.\
fliphorizontal.\
flipvertical.\
killaudio

Is there any way to comment out the fliphorizontal line without affecting parsing of the rest of the script?

I don't know how much use multiline syntax gets, but I'm guessing it may have originally been something of an after-thought. Semi-colon termination would be so nice... :cool:

[qyot27]

C-style /* */ works (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Comments):
Version()/*.\
FlipHorizontal()*/.\
FlipVertical().\
KillAudio()

[* *] are also allowed as comment delimiters as well.

Although on something that simple (for exposition's sake) I wouldn't bother with the .\ style multiline syntax at all, and use the standard multiline form:
Version()
#FlipHorizontal()
FlipVertical()
KillAudio()
In the above, /* and */ could also be used, and would format more sanely, since they'd be contained to just the FlipHorizontal() line.

[Stereodude]

Was there an issue before with the dithering when reducing the color depth in AVIsynth+ (4:2:0 chroma formats) that was fixed? I noticed some vertical banding in the output video when dithering was enabled with SD/REC.601 previously with build 2700. I didn't see it in HD/REC.709 content. However, with the latest build 2772 AVIsynth+ I don't see it anymore.

[StainlessS]

Stereodude, see Changelog for current & prev versions via Pinterf (via his sig) on github / releases :- https://github.com/pinterf/AviSynthPlus/releases

[pinterf]

I don't remember any issues or coding activities connected to dithering.

[Stereodude]

Stereodude, see Changelog for current & prev versions via Pinterf (via his sig) on github / releases :- https://github.com/pinterf/AviSynthPlus/releases
I didn't see anything listed that would directly explain my observations. Hence the question.

I don't remember any issues or coding activities connected to dithering.
Weird... Oh well, I'm not seeing it now.

[FranceBB]

In the above, /* and */ could also be used

I use /* */ everyday to comment out multiple lines.
For the sake of coding, // would also be appreciated to have available as comment instead of using just "#" for single line commands, just to feel a bit more like C++ and C#.

I don't remember any issues or coding activities connected to dithering.

Speaking of Dithering, will other dithering algorithms be added in the near future? You know, like the Stucki error diffusion and the Atkinson error diffusion?
Don't get me wrong, I'm totally happy with the current Floyd-Steinberg error diffusion as it's one of the best dithering algorithms, but what if people need/would like to use other dithering algorithms?
After all, back when the world was 8bit stacked, 8 dithering methods were available.

[StainlessS]

// would also be appreciated

Bad idea at this late date. Too much potential to f*** up stuff, eg script scanning apps like AvsPMod, Avisynthesizer etc.
Also, adds nothing to the language.

[FranceBB]

Too much potential to f*** up stuff

Uh... I guess you are right.
After so many years it might be a problem.
Well, after all I got used to use # as comment anyway, so it's not a big deal...

Anyway, my request for the alternative dithering methods is still valid. :)

[qyot27]

# is more typical for scripting languages anyway. Bourne shell and its kin, and Python at least. It wouldn't surprise me if that was a near-universal convention.

What seems...off...about AviSynth's use of the .\ paired with # is that it seems like empty lines aren't collapsed, meaning that a # comment in the middle of a .\ multiline block will error out (which I'm pretty sure might be what prompted this particular discussion in the first place). So will removing the line's contents entirely, while leaving the blank line. In a typical AviSynth script without that line continuation syntax, empty lines are collapsed, skipped, or treated like a no-op. Moving the \ to the actual line it continues on, like this:
Version().

\FlipVertical().
\KillAudio()
works, but even then, the comment-in-the-middle (if it were there) doesn't.

[tormento]

After all, back when the world was 8bit stacked, 8 dithering methods were available.
Aren’t you confusing dither.dll from cretindesalpes?

[pinterf]

Probably most of those dithering methods were not used. You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.

[tormento]

Probably most of those dithering methods were not used. You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.
I pretty much used ordered. It's better compressed without too much washing it out.

[FranceBB]

Aren’t you confusing dither.dll from cretindesalpes?

I meant Dither Tools, that's why I said "in the 16bit stacked era".
Back then there was Dither Tools for everything about 16bit stacked and HDRCore for 16bit interleaved, but only Dither Tools had many dithering options:

Dithering method:
-1 no dither, round to the closest value
0 8-bit ordered dither + noise.
1 1-bit dither
2 2-bit dither, light
3 2-bit dither, medium
4 2-bit dither, strong
5 2-bit dither, stronger
6 Serpentine Floyd-Steinberg error diffusion + noise.
7 Stucki error diffusion + noise.
8 Atkinson error diffusion + noise.

You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.

Got it.

Probably most of those dithering methods were not used.

Well, maybe yes, but some people did use them, I think, as they have their pros and cons.
For instance, tormento just said that he uses ordered dither 'cause it's better compressed by codecs (of course, since it has a regular pattern and it's better identified by the motion-compensation algorithms on the 4x4/8x8 blocks etc).
Other people might instead have a lot of bitrate to spend on the video and maybe they prefer Stucki 'cause it looks sharper and so on.

[StainlessS]

As far as comments concerned, below is demo of how handy '[* ... *]' is,

Function DropDeadGorgeous(clip c,String DB,Int "ScanAhead", Int "X",Int "Y",Int"W",Int "H",Bool "Show", Bool "Verb",
\
\ Int "Prefilter", [* Prefilter *]
\ Int "SPad", Int "SPel", Bool "SChroma", Int "SSharp", Int "SRFilter", [* MSuper *]
\ Int "ABlkSize", Int "ABlkSizeV", [* MAnalyse *]
\ Int "ASearch", Int "ASearchParam", Int "APelSearch", [* MAnalyse *]
\ Bool "AChroma", Bool "ATrueMotion", [* MAnalyse *]
\ Int "AOverlap", Int "AOverlapV", [* MAnalyse *]
\ Int "ADct", Bool "ATryMany", [* MAnalyse *]
\ Int "RthSAD", Int "RBlkSize", Int "RBlkSizeV", [* MRecalculate *]
\ Int "RSearch", Int "RSearchParam", [* MRecalculate *]
\ Bool "RChroma", Bool "RTrueMotion", [* MRecalculate *]
\ Int "ROverlap", Int "ROverlapV", Int "RDct", [* MRecalculate *]
\ Float "Iml", Bool "IBlend", Int "IthSCD1", Int "IthSCD2", [* MFlowInter *]
\
\ Int "SOSthSCD2"
\ )


Its use totally evaded me until RaffRiff42 pointed it out some time ago [I had even forgot that it existed as a comment option], the nesting comments can be very useful.

EDIT: Above is not prototype for current posted DDG, will be as above in next version.

[shekh]

@pinterf
Tried planar rgb formats, found some issues:


AviSource()
ConvertToYV12()
ConvertToPlanarRGBA()
ConvertBits(16)


Alpha plane is uninitialized, sometimes 0xCD somietimes 0x00 bytes.
Same with depth 14,12,10.

ConvertBits(8)
Resulting format is RGBA32 but is filled with something wrong.


AviSource()
ConvertToYV12()
ConvertToPlanarRGBA()
OPT_Enable_PlanarToPackedRGB = true
ConvertBits(8)


Works normally except alpha is still uninitialized.
Using AviSynthPlus-MT-r2772.exe

8BPS: according to some sources this format is rle-encoded. There is decoder in FFMpeg which does not understand simple planar packing. Is this fourcc clash?

[pinterf]

Thanks, I'll look at those uninitialized alpha issues. As for 8BPS, yes, its handling is wrong because it wants rle, and I'm not even sure why I chose it, perhaps I did not find other fourcc for 8 bit planar rgb?

[shekh]

libavcodec\raw.c includes these:
{ AV_PIX_FMT_GBRP, MKTAG('G', '3', 00 , 8 ) },
{ AV_PIX_FMT_GBRAP, MKTAG('G', '4', 00 , 8 ) },
So it at least looks similar to other G3/G4 formats, but probably there is no program to understand it.