AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Gavino]

For some time, I have been puzzled (and mildly annoyed!) that using a run-time function like AverageLuma outside of a run-time filter (ScriptClip, etc) produces the error "Invalid arguments to function ...", especially when the source code contains logic to produce the more helpful "This filter can only be used within ConditionalFilter". So I decided to investigate properly.

The reason the more helpful (and presumably intended) message is not produced is that the code (in AveragePlane::AvgPlane and elsewhere) looks like this:
AVSValue cn = env->GetVar("current_frame");
if (!cn.IsInt())
env->ThrowError("Average Plane: This filter can only be used within ConditionalFilter");
However, if current_frame does not exist (the usual case outside the run-time environment), GetVar will throw a NotFound exception and the error-checking code will never be reached. The exception is propagated back to the parser, which is evaluating the original call to AverageLuma (etc), where it sees this as an inability to call and reports it as "Invalid arguments".

The solution is to use the exception-protected GetVar from conditional_reader.h instead of env->GetVar to read current_frame (in 4 places in conditional_functions.c). At the same time, the error message could be changed to refer to "run-time filters" instead of specifically to ConditionalFilter (which I suspect was the only one that existed when this code was written).

[Terranigma]

There's a new version of soundtouch [1.5.0]. You think you guys could incorporate the change in the next release?

Also, could you bring back the previous behavior of conditionalreader for boolean types where you could specify true or false without adding a space after a value?

e.g. previous behavior:
1080t = works

e.g. new version:
1080t = doesn't do anything
1080 t = works

:thanks:

[Frank K Abbott]

I'm getting a no function named spline64resize() error and I'm a bit confused as to where to get the MT and modded avisynth dll for 2.6

[IanB]

@Frank K Abbott,

MT and setmtmode are not currently supported.

Spline64Resize works fine for me. Whose version of 2.6 are you using?


@Terranigma,

I seem to remember commenting on this before, but I can't find my previous post. There have been no changes that effect Avisynth's usage of of SoundTouch. All of the changes are in the free standing application and source code tweaks to pacify the latest recalcitrant compilers. I will be picking up the current version when I do the change to the next compiler at 2.6.1.5.1. SoundTouch library Change History

1.5.0:

* Added normalization to correlation calculation and improvement automatic seek/sequence parameter calculation to improve sound quality
* Bugfixes:
o Fixed negative array indexing in quick seek algorithm
o FIR autoalias filter running too far in processing buffer
o Check against zero sample count in rate transposing
o Fix for x86-64 support: Removed pop/push instructions from the cpu detection algorithm.
o Check against empty buffers in FIFOSampleBuffer
o Other minor fixes & code cleanup
* Fixes in compilation scripts for non-Intel platforms
* Added Dynamic-Link-Library (DLL) version of SoundTouch library build, provided with Delphi/Pascal wrapper for calling the dll routines
* Added #define PREVENT_CLICK_AT_RATE_CROSSOVER that prevents a click artifact when crossing the nominal pitch from either positive to negative side or vice versa


And "1080t" should be throwing a syntax exception. I'll look into it.

[Frank K Abbott]

Yea the main prob was that I switched out replaced the avisynth.dll in system32 with the 2.8.5 version that was modded by Jeremy with 2.6 installed so that's why spline64resize wasn't working. When is MT support expected in AviSynth 2.6?

[MfA]

Likewise while in deep thought mode, what about 32bit pixels. Are they float, int32 or uint32. Is black 0.0 or 16.0 or another value. Is white 1.0, 235.0 or another value.
Floating point, standard conversions should use 0.0 for 0 and 1.0 for 255. Pixel shaders are the most familiar floating point image filters and that's how they do it ... I see no good reason to deviate.
Also in 16 and 32 bit pixel formats do we undo gamma and make the values linear.
Good for default behaviour, but conversions should let the user disable it or set their own lift/gamma/gain values.

[IanB]

@MfA,

It's good that others are thinking about this.

Of course if the API luminance distribution is truly linear, then there should be an expectation that coming from and going to the existing 8 bit spaces be user configurable for gamma, range and bias. i.e. O=(((I-k1)*k2)**k3)*k4+k5

For k3==2 there are some obvious very fast implementations with pmullw xmm0, xmm0 and a fairly quick implementation with sqrtps xmm1, xmm2 for k3==1/2. So there is a practical case for the API to say the 16bit and 32bit formats are fixed wrt Gamma=2.0 versus the 8bit spaces and the user only gets to pick from a limited selection of k1, k2, k4 & k5.

There are also some quickish implementations for O=logN(I) and O=k**I using exponent bit stuffing with IEEE floats which might mitigate the above assertion.

For the 16bit space note that 255**2=65025 (fits) and 255**2.2=196964.7 (doesn't fit)

[MfA]

k2 is redundant and k5 doesn't really belong in a gamma curve IMO.

Any way ... reading a bit, Rec 709 is the standard for cameras, and it can't even be described by this formula and neither can sRGB. So you need flags for Rec 709 and sRGB as well as the general gamma curve with parameters (oh and wikipedia says EBU uses a different gamma value for Rec 709 as well, wonderful).

You'll need a little more than just bit stuffing, Jim Blinn's tricks aren't very precise ... at least not with single precision.

I don't see the need for 16 bit, but if it has to be done why not just do the conversions in floating point and then go back to 16 bit to save some headaches?

[IanB]

@MfA,

Think a little harder about the algebra involved, yes a real implementation probably would fold k2 into k4 as k2**k3 to avoid a redundant pmul*, but I hoped the general expression would be clearer for documentation purposes. i.e. YV12 to a 'YV48' k1=16, k2=1/235, k3=2.2, k4=32767, k5=0 and the inverse k1=0, k2=1/32767, k3=1/2.2, k4=235, k5=16.

As for k1 and k5 they will usually be 0, 16 or the translation of 16.

For explicit complex conversions for Rec709, sRGB, etc you are probably looking at a plugin.

What I am brainstorming for here is a proposed relationship between existing 8bit spaces and possible 16bit and 32bit spaces. The way I am reading your responses is as inverse arguments that point back to a fixed Gamma=2.0 rule.

Yes Jim Blinn's 'tricks' are a little brutish, but for a 235 state translation they can be made to do a satisfactory job.

And for well implemented filters 16bit could be twice as fast as 32bit (memory bus limited, as in BitBlt).

[MfA]

Inverse gamma correction in YUV doesn't make a whole lotta sense, if you want to work in a linear colour space the linearisation has to happen in RGB. Which is why I don't see the need for level adjustments ... those will be taken care of in YUV<->RGB. After linearisation you can go back to YUV if you want.

I disagree about the Rec.709 transfer function, it deserves to be in core for (inverse) gamma correction as much as it deserves to be in there (with Rec.601) for YUV<->RGB. Skipping sRGB okay, but the industry standard?

[tritical]

Seems there is a bug in the cache filter's handling of setcachehints(). Specifically, if CACHE_NOTHING is sent, it doesn't check to see if setcachehints() was previously called with CACHE_RANGE or CACHE_ALL... it simply sets h_policy = CACHE_NOTHING. IMO it should always go with the largest request. Avisynth 2.6 and 2.5.8 seem to work this way.

Also, since it isn't mandatory for filters to call setcachehints() - which would be a really good idea IMO, the cache filter needs some other way to know if it is being hit by multiple filters and override a CACHE_NOTHING hint. Otherwise, it's never safe to use CACHE_NOTHING because while your filter may not require caching, you never know if a second or third or fourth, etc... filter is hitting the same cache but doesn't call setcachehints(). Even if all of those filters are non-temporal (don't require caching if used alone) and hint CACHE_NOTHING, a cache would be useful when they are all branching from the same point.

[Gavino]

Seems there is a bug in the cache filter's handling of setcachehints(). Specifically, if CACHE_NOTHING is sent, it doesn't check to see if setcachehints() was previously called with CACHE_RANGE or CACHE_ALL... it simply sets h_policy = CACHE_NOTHING. IMO it should always go with the largest request. Avisynth 2.6 and 2.5.8 seem to work this way.
I wasn't sure what you meant at first, since as far as I know SetCacheHints has always been like this, and it's not something specific to 2.6.0 Alpha 2.

But I think you are actually saying that this a design fault in SetCacheHints, period. Your suggested change seems reasonable, but would prevent a single filter from setting the hints to CACHE_NOTHING after it had previously set them to something higher (in practice however, not a very likely requirement).

[kemuri-_9]

i have a question about the following in interface.cpp:

bool VideoInfo::IsYV12() const { return (pixel_type & CS_PLANAR_MASK) == (CS_YV12 & CS_PLANAR_FILTER); }

this IsYV12() is different from the 2.5.x series in the fact that this 2.6.x version does not detect and flag CS_I420 as also being YV12 like it did for 2.5.x.
was it intended for the transparency of I420 being recognized as YV12 to vanish with 2.6.x or is this a bug?

[IanB]

@Tritical, Gavino,

Yes, the way Cache hints are handled sucks and always has. The decision for doing a CACHE_NOTHING is a bit barse ackwards, really the child should be the one saying I am a zero (or very low cost) filter, I do not need to be cached. And for the CACHE_ALL case, it seeds a number that really doesn't tune anything very much. And for the CACHE_RANGE case their has been universal confusion about what the argument value actually means.

You may have noticed that I have cribbed with the ABI a little and now have SetCacheHints returning an int (was void). virtual int __stdcall SetCacheHints(int cachehints, int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.The idea being to have filters optionally implement this method so the parent cache instance can query the child about it's performance criteria, i.e. Things like :- Zero cost? MT challenged? Is sequential cheap? Is random expensive?, ...

I'll probably reassign the actual enum values for these keys and treat the old values as legacy and do something safe for calls from legacy 2.5 filters.



@kemuri-_9,...
CS_PLANAR_FILTER = ~( CS_VPlaneFirst | CS_UPlaneFirst ),
...
CS_YV12 = CS_PLANAR | CS_YUV | CS_Sample_Bits_8 | CS_VPlaneFirst | CS_Sub_Height_2 | CS_Sub_Width_2, // y-v-u, 4:2:0 planar
CS_I420 = CS_PLANAR | CS_YUV | CS_Sample_Bits_8 | CS_UPlaneFirst | CS_Sub_Height_2 | CS_Sub_Width_2, // y-u-v, 4:2:0 planar
...

[kemuri-_9]

@kemuri-_9, CS_PLANAR_FILTER = ~( CS_VPlaneFirst | CS_UPlaneFirst ),

Ah, I seemed to have overlooked how this was defined...
it's a bit obscure that the & CS_PLANAR_FILTER covers both YV12 and I420 in the condition, but i guess it works... though a note indicating this would be useful.

[IanB]

YV12 and I420 are the same primitive colour space to Avisynth. As of 2.6 the CS_VPlaneFirst and CS_UPlaneFirst bits are only used in env->NewVideoFrame() to set the initial order of the chroma planes in memory. Once on the fly the plane order should be irrelevant. In fact the SwapUV() filter just flips the pointers in the PVideoFrame, likewise the UtoY8 and VtoY8 just snatch the appropriate pointer and size numbers, making all 3 zero cost filters.

[kemuri-_9]

right, it's just seems like I420 is a special case though that's because it is the only colorspace that is CS_VPlaneFirst.

on the point of the colorspaces, is YUV9 going to be supported by 2.6? it's not commented out in avisynth.h though it is everywhere else.
if it is going to be supported then YVU9 should also be supported, this would give another use case to CS_VPlaneFirst being utilized making I420 seem less special-cased.

it would also be interesting to see NV12 eventually get supported by avisynth.
But as it doesn't seem to fit into the colorspace definition scheme as it is a peculiar format that has Y as planar and UV as interleaved, this doesn't look currently feasible.

[tritical]

Going back to the cache. My suggestion for going with the max request was due to scripts such as:

some_source()
a = last.spatial_filter1()
b = last.temporal_filter()
c = last.spatial_filter2()
another_filter(a,b,c)

Now you've got multiple filters hitting the same cache (this scenario is where the cache helps significantly). Let's say both spatial_filter's send CACHE_NOTHING, the first temporal filter sends CACHE_RANGE, the final filter doesn't call setcachehints() at all. The cache gets disabled causing a big slow down depending on the speed of some_source(). If the cache goes with the max request it wont get disabled. Of course, this doesn't fix the problem if temporal_filter doesn't call setcachehints(). It also doesn't fix the problem if all the filters are spatial and send CACHE_NOTHING, which would be fine if each was the only filter requesting from that point, but if two or more are requesting then a cache is useful.This is why I said the cache really needs a way to know how many filters are requesting from it, and that with how it currently works, sending CACHE_NOTHING is never really a good idea. Of course, there are a few external plugins around that can be used to fix this situation if you are aware of it.

Another situation is that cache instances are not added after aligned/unaligned splice, which makes sense, but the splice filter doesn't pass setcachehints() on. So if you do something like:

a = source1()
b = source2()
a+b
somefilter()

somefilter calling setcachehints does absolutely nothing. I would expect the setcachehints call from somefilter to be passed through splice to the cache's after source1() and source2().

[Wilbert]

I was looking at Mask() and i might have found something. The code "starts" with

cyb = int(0.114*32768+0.5);
cyg = int(0.587*32768+0.5);
cyr = int(0.299*32768+0.5);

__declspec(align(8)) static const __int64 rgb2lum = ((__int64)cyr << 32) | (cyg << 16) | cyb;
__declspec(align(8)) static const __int64 alpha_mask = 0x00ffffff00ffffff;
__declspec(align(8)) static const __int64 color_mask = 0xff000000ff000000;
/*
for (int y=0; y<vi.height; ++y)
{
for (int x=0; x<vi.width; ++x)
src1p[x*4+3] = (cyb*src2p[x*src2_pixels] + cyg*src2p[x*src2_pixels+1] +
cyr*src2p[x*src2_pixels+2] + 0x8000) >> 16;

src1p += src1_pitch;
src2p += src2_pitch;
}
*/
__asm {
...
}

I can't judge whether the mmx code is the same as the commented c code. If it is supposed to be the same then i think the coefficients should be

cyb = int(0.114*65536+0.5);
cyg = int(0.587*65536+0.5);
cyr = int(0.299*65536+0.5);

Apologies if the mmx-code is correct.

[IanB]

@Wilbert,

Yes, the following script show a 1 bit discrepancy:-ColorBars()
Subtract(Mask(BlankClip(Last), Last).ShowAlpha(), GreyScale())The C code comment is pretty boiler plate but does not quite match the MMX code. In MMX you are stuck with 16bit signed multiplies, so the scale factor can only be 32768. Likewise the rounder should be half this, i.e. 16384 (0x4000).

So I have adjusted the comments and added the rounding into the main code, I'll check this into CVS next commit.

[kemuri-_9]

An issue has been brought to my attention involving x264 with the underlying cause being avisynth:

scenario:
an autoloaded .avsi script has a syntax error

result:
x264 crashes.

cause:
the Avisynth C API avs_create_script_environment has no try/catch wrapping around the use of CreateScriptEnvironment() which throws exceptions, like in the case of of an autoimported script having parser exceptions.
this causes the C application to crash from unhandled C++ exceptions.

as such there are two options to handling the situation...

option A:
if there's an exception, simply return a NULL/0 value

extern "C"
AVS_ScriptEnvironment * AVSC_CC avs_create_script_environment(int version)
{
AVS_ScriptEnvironment * e = 0;
try
{
e = new AVS_ScriptEnvironment;
e->env = CreateScriptEnvironment(version);
}
catch (std::bad_alloc) {}
catch (AvisynthError) {
delete e;
e = 0;
}
return e;
}

option B:
Utilize the already existing error field of AVS_ScriptEnvironment and expose this with a new API function (as it is not currently exposed for some reason I am not aware of)

// add this method to avisynth_c.h and avisynth.def as well
extern "C"
const char * AVSC_CC avs_get_error(AVS_ScriptEnvironment * p) // return 0 if no error
{
return p->error;
}

extern "C"
AVS_ScriptEnvironment * AVSC_CC avs_create_script_environment(int version)
{
AVS_ScriptEnvironment * e = 0;
try
{
e = new AVS_ScriptEnvironment;
e->env = CreateScriptEnvironment(version);
}
catch (std::bad_alloc) {}
catch (AvisynthError err) {
e->error = err.msg;
}
return e;
}

[IanB]

@kemuri-_9,

Yes all stub functions should try/catch Avisynth errors.

On a quick scan I can see at least avs_function_exists(), avs_new_video_frame_a(), avs_make_writable(), avs_create_script_environment() and avs_delete_script_environment() having unprotected IScriptEnvironment calls.

Yes, AVS_ScriptEnvironment is opaque, so how have people been getting access to AVS_ScriptEnvironment::error, seems logical that there be avs_get_error(AVS_ScriptEnvironment * p).

AVS_Clip also has an error member and it has avs_clip_get_error(AVS_Clip * p).

Any other missing bits and pieces you are aware of?

The current runtime environment does not know about std::bad_alloc, the expected behaviour is malloc returning 0 on failure. What are you suggesting here?

And unfortunately what you need cannot be done transparently. So you will need AVISYNTH_INTERFACE_VERSION > 3 to get support for these fixes. :(

[kemuri-_9]

@kemuri-_9,

Yes all stub functions should try/catch Avisynth errors.

On a quick scan I can see at least avs_function_exists(), avs_new_video_frame_a(), avs_make_writable(), avs_create_script_environment() and avs_delete_script_environment() having unprotected IScriptEnvironment calls.

Yes, AVS_ScriptEnvironment is opaque, so how have people been getting access to AVS_ScriptEnvironment::error, seems logical that there be avs_get_error(AVS_ScriptEnvironment * p).

indeed AVS_ScriptEnvironment is an opaque struct so up until now there has been no way of accessing the error field of it unless the calling application goes into the avisynth codebase and gets the definition for it.
which is an extremely risky/bad practice to do.


AVS_Clip also has an error member and it has avs_clip_get_error(AVS_Clip * p).

Any other missing bits and pieces you are aware of?

yes, avs_clip_get_error has been in use since i switched x264 from using VFW API to the C API.

I am not aware of any other missing functionality at this time.


The current runtime environment does not know about std::bad_alloc, the expected behaviour is malloc returning 0 on failure. What are you suggesting here?

the std::bad_alloc was primarily to catch the potential exception thrown by the new on AVS_ScriptEnvironment
(a habit from x264 since it checks all memory allocations, even the really small ones).
truthfully the new/delete on AVS_ScriptEnvironment seems a bit overkill (I'm not particularly fond of new/delete on structs).
the new/delete could be replaced by use of calloc/free, which would also allow the constructor in AVS_ScriptEnvironment to be removed.


And unfortunately what you need cannot be done transparently. So you will need AVISYNTH_INTERFACE_VERSION > 3 to get support for these fixes. :(

Yes, this does change the C API to expose a new function...
I never particularly understood why the C API has its own version though...
this doesn't make much since to me as the version checks are technically against the C++ API version (which is currently at 5 in 2.6)
so if the user has avs 2.6, the 4 value you're bumping the C API version to will still pass initialization checks even though it could not have the new API function.
if you want this version check to work as intended for the C interface, it needs to be overhauled in some fashion.

[IanB]

Yes the avs_create_script_environment(int version) code is confused. It should be checking against it own API version not the C++ API version.

The API version should refer to how much of the set of entry points are available. And we have been quite slack in updating this value as new entry points get added across the Avisynth versions.

The C API has an easier time here, either the DLL won't load if statically linked and need entry points are missing or the GetProcAddress calls fail with dynamic linking (and hopefully get handled).

With the C++ API if the IScriptEnvironment's vtable is different/shorter than expected you get to run some random address, then crash and burn.

[DVDBob]

Are you working still on a new build because the latest official build is from 2009 September 27 ???

[royia]

Are you working still on a new build because the latest official build is from 2009 September 27 ???
I hope someone does.
This is an amazing project, I hope someone it taking care of it.

I would really like to see a portable version (Only DLL library for other applications, if it possible) and 64 bit support.

[dansrfe]

I hope MT and SetMTmode support comes out fast for this...

[LaTo]

I have a feature request: Can you add in the SDK a way to overlay text on a PVideoFrame?

It would be great, coding font only for a few debug info is a headache. Thanks!

[Gavino]

I have a feature request: Can you add in the SDK a way to overlay text on a PVideoFrame?
I requested this a while ago - see this thread.

[LaTo]

I requested this a while ago - see this thread.

Thanks Gavino, I missed this topic.

I hope this is still on the IanB's todolist because it would be really useful :D

[Wilbert]

Thanks Gavino, I missed this topic.

I hope this is still on the IanB's todolist because it would be really useful
That's already done months ago. Checkout the latest csv version.

[LaTo]

That's already done months ago. Checkout the latest csv version.

Great! I'll have a look this weekend.

[StainlessS]

Moved here from another thread:

Do you have an example where this is broken?

colorbars.Trim(0,100).ConvertToYV12() # 640x480@29.97
#ConvertToYUY2() # UnComment in v2.6 for error @ ytouv()
u=utoy()
v=vtoy()
ytouv(u,v) # When crash, In VdubMod "File Information" shows 640x960 YUY2, then crash

[IanB]

Oops, some code is missing. Also screwed for non VY12 planar. :o

I'll check the fixes in next round of CVS updates.

[StainlessS]

@IanB

This snippet was posted in another thread, as you have not responded,
I thought I should re-post here:

NEW Info.h, as it stands, when signed char is used EXT ASCII
characters 128 & above [eg (c)opyright, chr$(137), I think]
will not print (never did under old Info.h) and if unsigned
then characters 224 and above will reach out of font with
rubbish results and potential access violation.

DDigit has always had a fix for this and is quite efficiently implemented.
See here for futher info and the post following for a demo of DDigitTest
which shows full character sets when signed char, unsigned char and
with the fix applied, for the new Info.h.

http://forum.doom9.org/showthread.php?p=1462089#post1462089

[jmac698]

I thought of a feature that would be useful, I'd like a new type info with just per video info, I could use this as a template on new videos. Example, I usually copy whole videos just to get a template of a video I want to create,
black=blackness
white=black.tweak(bright=255)
Where I could use:
color_black=$000000
color_white=$ffffff
info template=blackness
black=blankclip(template,color_black)
white=blankclip(template,color_white)
smalltemplate=template.crop(0,0,-(width-4),-(height-4)#4x4 square - or use ConvertTo(4,4)
whitesquare=blankclip(smalltemplate,color_white)

There's other examples where I'm passing a template around just to copy the info. Imagine someway to automatically adjust color formats and sample rates and even resolution. Using converto(clip video, info template). So I could load my video and just info DVDCompliant=(720,480,"YV12",48000,16) / mpg2source()... / ConvertTo(DVDCompliant).

Another thing I'd really like that's nearly impossible now, a way for a plugin to extend video properties especially per frame. I'd like to expose last.frametype (i.e. I, P, B) for example for a filter I want to write. (I found a way to merge two encodings of the same digital TV capture for improved SNR).
Anyhow, there's a standard hack for per frame, something about the lower bits of the first 64 pixels in a video has something in it? Debug hints from dgdecode and another plugin that can use it. There's also the motion vectors from mvtools.
Imagine every frame having an IsCombed property.. would be wonderful! And you could choose which plugin you want to give you that property. You could change plugins for difficult to detect sections, yet still have a general ScriptClip to deinterlace them.

[Gavino]

I thought of a feature that would be useful, I'd like a new type info with just per video info, I could use this as a template on new videos. Example, I usually copy whole videos just to get a template of a video I want to create
No need for a new type - a clip essentially is just a template until you start requesting frames from it. When you provide a 'template' clip to BlankClip/Blackness, all you are doing is copying its properties, not its contents.
Imagine someway to automatically adjust color formats and sample rates and even resolution. Using converto(clip video, info template). So I could load my video and just info DVDCompliant=(720,480,"YV12",48000,16) / mpg2source()... / ConvertTo(DVDCompliant).
You can always write your own ConvertTo function using the script language. But conversion of dimensions also involves a choice of resizer to use, aspect ratio considerations, etc.

[Wilbert]

I'm updating the documentation again :) Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top. It's perhaps nice to add this as an option where it starts to skew.

Also, when do you know when to use "Add "Global OPT_AVIPadScanlines=True" option for DWORD aligned planar padding."? Is it sometimes set to false by some input filters?

[Gavino]

Happy New Year, Wilbert (and anyone else reading this).

Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top.
My first thought was that this was a design fault - the visual result should not depend on internal representation. But I imagine the purpose of this filter is not to make pretty pictures, but to correct faults in source files and filters. In that case it makes sense for the skew always to start from where the data begins.

Another point - the doc says that skew is optional (default 0) - in fact it is mandatory.

[Wilbert]

Happy New Year, Wilbert (and anyone else reading this).
Likewise!

Another point - the doc says that skew is optional (default 0) - in fact it is mandatory.
Oops :) Corrected, thanks!

My first thought was that this was a design fault - the visual result should not depend on internal representation. But I imagine the purpose of this filter is not to make pretty pictures, but to correct faults in source files and filters. In that case it makes sense for the skew always to start from where the data begins.
Makes sense. Perhaps it's to fix the chroma shift here: http://forum.doom9.org/showthread.php?p=1425106#post1425106 I'm not sure however.

[IanB]

A Happy New Year, to all our Avisynth friends and family.

I'm updating the documentation again :) Regarding SkewRows. I noticed that for RGB it skews from the bottom and for YUY2/Y8 from the top. It's perhaps nice to add this as an option where it starts to skew.
Yes as noted above the skewing is memory layout based, so RGB images are skew from the bottom up, YUV images are skew from the top down. I threw it together to read those skewed error messages that some media player users were submitting a short while ago, so no great amount of thought went into the design.

The effect of the algorithm is to paste all of the input rows together as one single very long row, then slice them up based on the new width (= input width + skew). Skew can also be negative in which case the last skew pixels of each line are added to the beginning of the next line and you get some extra lines at the end. The last line is padded with grey pixels when required.

The geometry of the output is calculated thus :-
. OutWidth = InWidth + Skew // signed skew values acceptable
. OutHeight = (InHeight*InWidth + OutWidth-1) / OutWidth // Ceiling

Also, when do you know when to use "Add "Global OPT_AVIPadScanlines=True" option for DWORD aligned planar padding."? Is it sometimes set to false by some input filters?
OPT_AVIPadScanlines controls the memory alignment used in the AVIFile output emulation, class CAVIFileSynth::, Avisynth input filters should have nothing to do with this output option. Programs that use direct Avisynth API input, e.g x264, will be unaffected by this option, but may choose to support it if appropriate.

Microsoft specify 4 byte, DWORD, alignment for the simple DIB compatible formats, RGB24, RGB32, YUY2 and Y8. They make no specification for other formats, i.e. it is format specific.

Avery Lee in VirtualDub assumes all planar YUV formats are packed, i.e. pitch = rowsize, and all DIB compatible formats are DWORD aligned, i.e. pitch = (rowsize+3)/4 * 4.

By default Avisynth conforms to VirtualDub's alignment and packing expectations. For other software using AVIFile input that may assume DWORD alignment of a planar format the user can set OPT_AVIPadScanlines=True. With VirtualDub's direct stream copy mode the Avisynth AVIFile emulation packing is copied through, so DWORD aligned planar AVI files can be created by this method.

Both DirectShowSource (257) and AviSource (260b3) test for and support both packed and DWORD aligned planar memory layouts.

For image widths such that the chroma rowsize is mod4 there is never an issue, i.e YV24 is mod4, YV16 and YV12 are mod8, YV411 is mod16. But for other widths the assumptions made by the software in use becomes relevant.

If the result of processing a planar output Avisynth script, via the AVIFile interface, shows row skewing then OPT_AVIPadScanlines=True may help.

[ajp_anton]

Is there a build of this that includes SetMTmode?

[Overdrive80]

In this link, you have avaliable different versions included MT. http://avisynth.org/mediawiki/Main_Page

[Gavino]

Is there a build of this that includes SetMTmode?
See IanB's answer at post #38:
There is no MT in either the Alpha 1 or 2 releases. I have noted SEt's changes for a subsequent release. I will very probably not be doing threading the messy SetMTmode() way.

[jmac698]

Does this bug exist in 2.6?

#crop bug
exposebug=false#set to true to crash
n=exposebug?241:240
colorbars
crop(0,n,0,n)
#~ File "pyavs.pyo", line 310, in _GetFrame
#~ File "avisynth.pyo", line 139, in BitBlt
#~ WindowsError: exception: access violation reading 0x02DDFFE0

[Gavino]

Yes it does.
Reason is code in transform.cpp:
} else {
// RGB is upside-down
_top = vi.height - _height - _top;
}

if (_left + _width > vi.width || _top + _height > vi.height)
env->ThrowError("Crop: you cannot use crop to enlarge or 'shift' a clip");
For RGB, if _top+_height > vi.height, _top will become negative and will not be caught by the following error check.

[jmac698]

Amazing. I did a quick search and can't find any other bugs reports. If only there were a bounty :) I tend to do advanced/weird stuff and find bugs in any program.

[IanB]

Yes, The "Crop: you cannot use crop to enlarge or 'shift' a clip" test is wrong for RGB. Fixed!


@Gavino: Snap! ;)

[jmac698]

could we update this page:
http://avisynth.org/mediawiki/Known_Issues
I don't know where else to put it.

[jmac698]

I was wondering if this behavior exists in 2.6, and if you can think of a way of reducing memory usage, and also improve the color problems to the same amount of accuracy as Layer, finally why do I get the wrong lines at the top when n>=26?:

#Overlay uses color conversions, this can be a problem if called many times
#you will see an increasing yellowish color at the top of the screen
#the script also uses a large amount of memory
#Layer has none of these issues
#Layer does have issues when n>=26, the wrong lines appear
base=blankclip.trim(0,9)
over=colorbars.trim(0,9)
showissue=true#Be careful with overlayissue, large values of n cause excessive memory use leading to a crash
showissue?overlayissue(base,over,25):layernonissue(base.resetmask,over.resetmask,26)
function overlayissue(clip base, clip over, int n) {
n<2?overlay(base,over.crop(0,n-1,0,1),y=n-1):overlay(overlayissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}
function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}