AviSynth 2.6.0 Alpha3 [May 25th]

[Gavino]

What makes you think that?
The code dealing with src_left, etc, is common to all the resizers, so it is 'impossible' for sinc to behave differently.

Did you read my post above?
Your shift function does not follow the scheme I indicated.

[IanB]

@jmac698,

The following works exactly as expected.Global signalwidth=16
V1=blankclip(width=signalwidth/4*3,height=8,pixel_type="YV12",length=81,color=$808000)
V2=blankclip(width=signalwidth/4,height=8,pixel_type="YV12",length=81,color=$008080)
StackHorizontal(V1, V2)
Y=Blur(1.0) # Clip with a transition
animate(0,80,"shift",y,0.,0,y,8.,0)
pointresize(256,100)
ScriptClip("""
ph=current_frame/10.
subtitle("shift="+string(ph))
""")

function shift(clip v, float x, float y) {
v
sincresize(last.width,last.height,x,y,last.width,last.height) # subpixel shifting IS working!
}

The excessively complicated example you submitted is always resizing an all black clip. Pretty pointless example.


Please always submit the absolute minimum script that just demonstrates the problem you are reporting. 20+ lines of complicate masktools coding that has nothing to do with the problem is not appreciated. You have been at this long enough to know better. Don't get me wrong I really like masktools, I just hate debugging somebody else's complicated use of it.


The resizers reuse the edge pixel to complete the filter support (ie no of taps) at the boundaries. i.e. the edge pixel is virtually extended beyond the boundary to satisfy the filter support requirements. This may lead to unexpected behaviour when trying to shift transitions that occur within taps pixels of the edge.

[jmac698]

This has to be very quick today,

Global signalwidth=16
V1=blankclip(width=signalwidth/4*3,height=8,pixel_type="YV12",length=81,color=$808000)
V2=blankclip(width=signalwidth/4,height=8,pixel_type="YV12",length=81,color=$008080)
StackHorizontal(V1, V2)
Blur(1.) # Clip with a transition
animate(0,80,"shift",last,0.,0,last,8.,0)
pointresize(256,100)
ScriptClip("""
ph=current_frame/10.
subtitle("shift="+string(ph))
""")

function shift(clip v, float x, float y) {
v
sincresize(last.width,last.height,x,y,last.width,last.height) # subpixel shifting IS working!
}

Had to modify to get your sample to work, and again subpixel shift is not working for me.
I've sent the video of what I get:
http://www.sendspace.com/file/gu2lof

Sorry etc. write more later

md5
dac8162175e2fbff5dec7395ac1d82bc *\WINDOWS\system32\avisynth.dll

[jmac698]

Ok,
Sorry for the poor communication, point by point...

The excessively complicated example you submitted is always resizing an all black clip. Pretty pointless example.

I copied and pasted my post and it showed a red and blue stacked sinewave. I don't see anything being resized by black. I see that there is a big movement at integer shift values, however when I observed more carefully, there is a very small change in luma in subpixel shifts, so indeed there is some effect. However, if you play it back, it's obvious that it's not smooth, which I don't understand. If you compare with bilinear, there is a clear antialiased movement which looks close to ideal.
In fact, I've found that the bilinear subpixel shifting is within +- of an ideal sinewave of that phase. Anyhow we'll leave that example as it's too complicated.

I was not looking for black border effect at this time, but the replicated borders were fine.

Now for the simplified example.
If you look at the video I posted, there is no change in the pattern from .2 to .9 subpixel shift. However I'm running it again and it is showing the same behaviour, it's seems unchanged for most subpixel shifts and then jumps.

Could you verify the md5 for me? Also could the caching aspect come into play here? I was observing this solely in avspmod, so I was using random access frames a lot.

Glitches just seem to love me!

[Gavino]

@IanB

Re SincResize puzzle, is there any possibility that this code in resample_functions.cpp,
double SincFilter::f(double value) {
value = fabs(value);

if (abs(value)>0.000001) {
return sin(value*M_PI)/(value*M_PI);
} else {
return 1.0;
}
}
is using the int version of abs instead of double?
Seems unlikely (for C++ they are both defined in math.h), but it would explain why there is little variation as the shift goes from 0.1 to 0.9, as the two nearest pixels to the resampling point would then always get a weight of 1.0.

LanczosResize(taps=4) which you would expect to be fairly similar to Sinc, shows a lot more variation.

[gyth]

Shifting is working, output of the sinc function might not be.

ColorBars(width=14,height=2,pixel_type="YV12").trim(0,80)

a=animate(0,80,"shift1",0.,8.)
b=animate(0,80,"shift2",0.,8.)

stackvertical(a,b)
pointresize(280,280)

ScriptClip("""
ph=current_frame/10.
subtitle("shift="+string(ph))
""")

function shift1(clip c, float x) {
c.bilinearresize(c.width*20,c.height,x,0,c.width,c.height)
}

function shift2(clip c, float x) {
c.sincresize(c.width*20,c.height,x,0,c.width,c.height)
}

[jmac698]

Holy batman, that looks hideous. Great example, gyth! Maybe I'm not crazy after all :) Bugs still love me though :(

[Wilbert]

@Gavino,

Well spotted (or guessed)! It needs to use fabs there. From script.cpp:

AVSValue Abs(AVSValue args, void* user_data, IScriptEnvironment* env) { return abs(args[0].AsInt()); }

[jmac698]

Yes, great job too Gavino.. he really has a good attention of details.

[Wilbert]

@Gavino,

Well spotted (or guessed)! It needs to use fabs there. From script.cpp:

AVSValue Abs(AVSValue args, void* user_data, IScriptEnvironment* env) { return abs(args[0].AsInt()); }


Sorry, wrong one. That version is only used in scripts ;)

math.h (but i'm not sure whether these are the onces which are called):

_CRTIMP int __cdecl abs(int);
_CRTIMP double __cdecl fabs(double);

[Gavino]

math.h (but i'm not sure whether these are the onces which are called):

_CRTIMP int __cdecl abs(int);
_CRTIMP double __cdecl fabs(double);
My version of math.h (Visual C++ Toolkit 2003) also has:
#ifdef __cplusplus
...
inline double __cdecl abs(double _X)
{return (fabs(_X)); }
abs() is also defined in stdlib.h, but only for int.

Now, resample_functions.cpp includes math.h (via stdafx.h), so it should pick up the 'double' version, unless it was using another version of math.h which does not have it. So maybe this is a wild goose chase, but it's the only dubious thing I can see specific to SincResize.

The silly thing is, the call to abs is redundant, since value has already been made non-negative through fabs on the previous line!

[IanB]

Re SincResize puzzle, is there any possibility that this code in resample_functions.cpp,
double SincFilter::f(double value) {
value = fabs(value);

if (abs(value)>0.000001) {
return sin(value*M_PI)/(value*M_PI);
} else {
return 1.0;
}
}
is using the int version of abs instead of double?
Well spotted, should be fabs and it's redundant anyway.

All the taps between -1 < x < 1 were 1.0

[Gavino]

So was it using a different version of math.h (or perhaps not using it at all)?

[SEt]

In my build the code definitely compiles with "double abs(double)" there.

[Gavino]

In my build the code definitely compiles with "double abs(double)" there.
And does gyth's test run OK on your build?

[jmac698]

http://screenshotcomparison.com/comparison/91203

[Gavino]

Thanks, jmac - that seems to confirm the existence of the problem and its cause.

I doubted your report at first, because there is nothing specific to SincResize that deals with src_left, etc - it turns out that the problem lies in the SincResize kernel and the filter (at least in 2.6.0 Alpha 3) is completely borked, including straight resizing too.

[jmac698]

http://avisynth.org/mediawiki/Known_Issues

[Gavino]

http://avisynth.org/mediawiki/Known_Issues

"This bug exists in 2.58 and 2.6a3..."
SincResize is new at v2.60, it did not exist in 2.58.

[jmac698]

Fixed.

[Gavino]

@IanB - You never answered my question:
So was it using a different version of math.h (or perhaps not using it at all)?
I'm still puzzled why it works in SEt's build but not in yours.
Is there something different in your build environment?

[SEt]

It looks like official avisynth is built with ancient (and very buggy) Visual Studio 6, while mine with 2008 compiler and parts of 2005 and Win7 SDK.

[IanB]

@IanB - You never answered my question:

I'm still puzzled why it works in SEt's build but not in yours.
Is there something different in your build environment?Sorry there was a question there :confused:

As SEt says different build environments.
_CRTIMP int __cdecl abs(int);

[jmac698]

Ok. Anyhow I updated the doc.
So I'm done, sorry if I got off topic, though I think it was overall on the topic of 2.6 documentation. Had to find out, in any case - it's a valid point of discussion. Hindsight doesn't mean it's off topic. Anyhow, the mod will decide - I have no say :)

[StainlessS]

I would like to make a request, with a please or "pretty please" if you like.
It would be real nice if the Info.h header could have compiler directives added to omit
code, eg "// #define INFO_H_DISABLE_PLANAR" with a complimentary set like,
"#ifndef INFO_H_DISABLE_PLANAR", etc. It could live quite happily with the header and
users of that header without complication and give flexibility that is now un-apparent.
In the "C to CPP" thing I upped today,I first did modded versions of Info.h and InfoF.h
so that particular colorspace code could be omitted. I then went back to the "all-or-nothing"
situation that currently dominates, adding another non-standard version may not help too much.
Without the devs, the pluggers have no reason to be, but also, without the pluggers, what would
fate hold in store for the developers. (More free time with the mistress maybe).
API's and headers might well want to be standardised, but Info.h is used by more than just developers,
and should also be usable by both sides without every plugger having to make his/her own version
(and all the confusion that ensues from pluggers that salvage from various sourced plug sources).
I'll even do it if you like (just earlier deleted a similar file), just say "Doit" and I'll PM (EDIT: or post)
you with a link, all you gotta do it upload to the repository.

Not a bad thing. :cool:

[SEt]

Personally I think Avisynth's low level interface should be redesigned, not just headers: nothing complex compiled into every plugin (hi, threading bugs of older headers) and DirectX-like style (so it can be used as C++ classes or plain C functions directly).

[Fullmetal Encoder]

Sorry if this is a stupid question as I'm not very knowledgeable about the inner workings of AviSynth but if it were to be redesigned from the ground-up wouldn't it be prudent to make it compatible with Media Foundation? I believe I've read that MF is much easier to deal with than DirectX, DirectShow,VfW etc. anyway. Would it even be feasible to create a program for MF that operates like AviSynth?

I'm studying C++ so I'm kind of curious.

[SEt]

That I think it should be redesigned doesn't mean it will be anytime soon - no one volunteers to implement so radical changes nowadays. Also, "DirectX-like style" means only low level way of organizing functions in classes - no change to general behavior of Avisynth intended.

[Wilbert]

IanB,

Two questions:

What's the difference between Hex and Hexvalue? They seem to do the same, more or less.

Also, the following are declared twice in script.h:

AVSValue Int(AVSValue args, void*, IScriptEnvironment* env);
AVSValue Frac(AVSValue args, void*, IScriptEnvironment* env);
AVSValue Float(AVSValue args, void*,IScriptEnvironment* env);
AVSValue Value(AVSValue args, void*, IScriptEnvironment* env);
AVSValue HexValue(AVSValue args, void*, IScriptEnvironment* env);

[Gavino]

What's the difference between Hex and Hexvalue? They seem to do the same, more or less.
Each is the converse of the other.
Hex converts an int into a (hex) string.
Hexvalue converts a (hex) string into an int.

[IanB]

Yes as G. says on the Hex/HexValue.

The duplicate code seems to be from a bygone era, Diff (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/script.h?hideattic=0&r1=1.3.2.2&r2=1.3.2.3).

LogRevision 1.3.2.3 - (view) (download) (as text) (annotate) - [select for diffs]
Mon Nov 25 17:00:50 2002 UTC (9 years ago) by sh0dan
Branch: avisynth_2_1
Branch point for: struct_mod
Changes since 1.3.2.2: +29 -0 lines
Diff to previous 1.3.2.2 , to branch point 1.3

Merged latest 2.07 changes (script, color options, parser options).
Handmerged, so there might be a slip or two (seems to work though) (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/script.h?view=log&hideattic=0&pathrev=avisynth_2_1)

[redfordxx]

I am sorry if it is wrong thread for this but I don't know if the following is bug report or my stupidity:

This testclip crashes both MeGui and AvsPMod
r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
r1
However, this works fine:r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
Thanx for comment...

[Gavino]

This testclip crashes both MeGui and AvsPMod
r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
r1
That's because the 'r1' used in the LumaDifference() is evaluated at run-time and refers to the value at the end of the outer script. This sets up a loop in the run-time filter chain since r1 is the result of the ScriptClip() call - leading to ScriptClip requesting a frame from itself, an infinite recursion.

In the second example, r1 is not reassigned, so still has its original value when LumaDifference is evaluated.

See http://avisynth.org/mediawiki/The_script_execution_model/Scope_and_lifetime_of_variables#Runtime_scripts.
This is an example of what I call the 'variable binding problem' and was one of the motivations for GRunT.
Using GRunT, the problem is avoided by writing
r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))", args="r1")
which ensures the binding of r1 is done at compile-time, ie its value at that point in the script is used.

EDIT: But actually, for this example, you don't need to use r1 inside the run-time script, since it is also the input to ScriptClip and hence is available inside as 'last':
r1=r1.ScriptClip("Subtitle(String(LumaDifference(last,r2)))")

[Nickliverpool]

Hello, is this a bug? I think it's a bug

in = FFmpegSource2("F:\BigBuckBunny_320x180.mp4")
in_r = in.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point")
Subtract(in, in_r)

http://img803.imageshack.us/img803/2938/yv12bug1.png

and...
i = ImageSource("p.bmp").ConvertToYV24(chromaresample="point")
i_u = i.UToY()
i_v = i.VToY()
i_y = i.Grayscale()

i2 = i.ConvertToYUY2(chromaresample="point").ConvertToYV24(chromaresample="point")
i2_u = i2.UToY()
i2_v = i2.VToY()
i2_y = i2.Grayscale()

i12 = i.ConvertToYV12(chromaresample="point").ConvertToYV24(chromaresample="point")
i12_u = i12.UToY()
i12_v = i12.VToY()
i12_y = i12.Grayscale()

w = 128
h = 64
StackHorizontal(i.PointResize(w,h),i2.PointResize(w,h), i12.PointResize(w,h))
StackHorizontal(i_u.PointResize(w,h),i2_u.PointResize(w,h), i12_u.PointResize(w,h))
StackHorizontal(i_v.PointResize(w,h),i2_v.PointResize(w,h), i12_v.PointResize(w,h))

The source image:http://img42.imageshack.us/img42/6611/91182967.png
The result:
http://img828.imageshack.us/img828/4302/12759853.png

http://img819.imageshack.us/img819/4059/21147365.png

http://img267.imageshack.us/img267/7643/33253986.png

[Gavino]

Hello, is this a bug? I think it's a bug
I don't.
Because of differing vertical chroma placement in YV12, conversion between YV24 and YV12 with chromaresample="point" effectively introduces a chroma shift.
There is no shift with YUY2, as it has the same placement as YV24 (but with half the chroma missing of course).

[gyth]

ChromaOutPlacement is ineffectual.

ImageSource("91182967.png").ConvertToYV24(chromaresample="point")

StackVertical(\
StackHorizontal(ngc("MPEG2","MPEG2"),ngc("MPEG2","MPEG1"),ngc("MPEG2","DV")),\
StackHorizontal(ngc("MPEG1","MPEG2"),ngc("MPEG1","MPEG1"),ngc("MPEG1","DV")),\
StackHorizontal(ngc("DV","MPEG2"),ngc("DV","MPEG1"),ngc("DV","DV")))

function ngc(clip c, string s1, string s2){
c
ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
ConvertToYV24(chromaresample="point",ChromaInPlacement=s2)
PointResize(128,64)
}
http://i.imgur.com/XxZ0Y.png

P.S. The blocks in the original image are 2x2, so this conversion isn't necessarily lossy.

[IanB]

Point resampling cannot do the required sub-pixel shifting. Point resampling is also known as nearest neighbour.

[Gavino]

ChromaOutPlacement is ineffectual.

P.S. The blocks in the original image are 2x2, so this conversion isn't necessarily lossy.
I believe it is working correctly.
Precisely because of the 2x2 blocks in the original,
ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
gives the same results for all 3 values of s1.

[gyth]

Point resampling cannot do the required sub-pixel shifting.
Would a feature request for ChromaInPlacement="Point" make sense?
L1 L2 L3 L4
C1 C2
L5 L6 L7 L8
L9 LA LB LC
C3 C4
LD LE LF L0
"MPEG2" applies C1 to L5, L6, L9, LA
"Point" would apply C1 to L1, L2, L5, L6

But anyway, you can just shift the chroma back.
ImageSource("91182967.png")
ConvertToYV24(chromaresample="point")
ConvertToYV12(chromaresample="point")
ConvertToYV24(chromaresample="point")
w=width
h=height
MergeChroma(last,last.pointresize(w,h, 0,1, w,h))
PointResize(128,64)

[gyth]

I believe it is working correctly.
Precisely because of the 2x2 blocks in the original,
ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
gives the same results for all 3 values of s1.
Yes, ChromaOutPlacement is choosing the effective location the chroma is being pulled from. And since it is pointwise pulling from a square of uniform color it should always give the same result. Ok, that makes more sense. :)

[Selur]

Don't know for sure if this is known, but when calling:
LoadPlugin("G:\Hybrid\avisynthPlugins\DGDecode.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\decomb.dll")
MPEG2Source(d2v="D:\Encoding Temp\dolbyegypt_41.d2v")
Telecide()
I get a green bar (multiple lines) at the bottom of the page. (does not happen with Avisynth 2.5.8)
-> seems like a bug in Avisynth 2.6 :(

Cu Selur

Ps.: as source I used: http://www.digital-digest.com/movies...php?type=dolby -> Dolby Digital - Egypt

[IanB]

Decomb, yet another package that foolishly assumes UVpitch = Ypitch/2
LoadPlugin("G:\Hybrid\avisynthPlugins\DGDecode.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\decomb.dll")
MPEG2Source(d2v="D:\Encoding Temp\dolbyegypt_41.d2v")
Telecide()
SetPlanarLegacyAlignment(True)

[Selur]

Decomb, yet another package that foolishly assumes UVpitch = Ypitch/2
Which other packages are known to need 'SetPlanarLegacyAlignment(True)' ? (first time I see this function) :)

[Selur]

I wrote a small application (full source (http://www.embedupload.com/?d=9TB0L4FSFM)) to view avs files, but it keeps crashing. I pasted the main part to http://pastebin.com/LB5fCTg5

My problem is cleaning the enviroment and rebuilding a new one. :(
If I loads a new file everything is fine, clip can be viewed without a problem.
To load another clip, I than first call m_env->DeleteScriptEnvironment(); (line 177) to clean up the old environment, initialize a new one (line 53), invoke the Import of the new clip (line 71) and try to call .asClip on the returned AVSValue; all like I did for the first clip. Problem is now the whole application comes crashing down.
To prevent this I added a few lines which check that the enviroment equals NULL before initializing it, problem is: How to do it properly such that I can kill the existing enviroment and set up a new?

Also how to I really delete the enviroment, calling DeleteScriptEnvironment() does not set it back to NULL and if I call delete m_env after calling DeleteScriptEnvironment() the application crashed,..

-> would be cool if someone who knows how to handle avisynth script environment stuff could have a look at it and tell me what I did wrong.
(it's probably something stupid that I missed :))

Cu Selur

[TheFluff]

With Avisynth 2.5 the usual way to delete a script environment is to simply say
delete env;

I don't know if that's still the case with 2.6 though. DeleteScriptEnvironment() wasn't an exported function in 2.5.8 AFAIK.

[Gavino]

To load another clip, I than first call m_env->DeleteScriptEnvironment(); (line 177) to clean up the old environment, initialize a new one (line 53), invoke the Import of the new clip (line 71) and try to call .asClip on the returned AVSValue; all like I did for the first clip. Problem is now the whole application comes crashing down.
Before calling DeleteScriptEnvironment(), you need to set any persistent variables (such as m_res and m_clip) to 0. Otherwise Avisynth will crash when you next assign a value to them, as it will try to free the old values which are linked to a now-deleted script environment.

Also how to I really delete the enviroment, calling DeleteScriptEnvironment() does not set it back to NULL
Of course not - m_env is a variable and the only way to set it to NULL is to set it yourself.
m_env->DeleteScriptEnvironment();
m_env = NULL; // ensure new environment created next time

[Selur]

Thanks Gavino!! Worked like a charm!

Cu Selur

[Selur]

Got another problem. :D
I use the following code to load an Avisynth script:
try {
m_res = m_env->Invoke("Import", infile); //import current input to environment
} catch (AvisynthError &err) { //catch AvisynthErrors
cerr << "-> Avisynth error: " << err.msg << endl;
return;
} catch (...) { //catch the rest
cerr << "-> Unknown error,... " << endl;
return;
}
problem is, it works fine if the input avisynth script is fine, but if it has a problem the whole application just crashes due to the Invoke call,.. (I assumed it would throw a AvisynthError which I could catch,..)

Cu Selur

[TheFluff]

Welcome to the hilarious game of trying to catch C++ exceptions thrown from an external DLL which you have loaded dynamically at runtime. Fun for the whole family!
Except it's not, and if someone looks at your exception handler in a vaguely threatening way it'll most likely freak out and just not catch anything.

In theory, in order to get it to work perfectly reliably you must:

compile your program with the same compiler as the DLL
using the exact same compilation settings, and
using the exact same runtime.


In your case, you can probably get away by just linking to the C++ runtime library dynamically rather than statically.

I remember there being a post somewhere on these boards that explained some gory details regarding this at some length, but I can't find it now.

[Selur]

I'll try to look for the post (did before but didn't find anything).

[LoRd_MuldeR]

Also keep in mind that "try...catch" really only catches C++ exceptions. This means exceptions explicitly thrown by a "throw" instruction.

There are other kinds of program errors, such as Access Violation, Division by Zero and so on, that are not C++ exceptions, but "system exceptions", and thus can never be caught by "try...catch". Not even by "catch(...)" ;)

On Linux you would probably have to deal with Signals to catch these kind of errors. On Windows you have to use the MSVC-only "__try ... __except" construct for this purpose:
http://msdn.microsoft.com/en-us/library/s58ftw19%28v=vs.80%29.aspx

And, to make things even more fun, you are not allowed to use "try...catch" and "__try ... __except" within the same function, even if you use the MSVC compiler. You'll have to use two nested functions instead :rolleyes:


void inner(char *infile)
{
[...]

try {
m_res = m_env->Invoke("Import", infile); //import current input to environment
} catch (AvisynthError &err) { //catch AvisynthErrors
cerr << "-> Avisynth error: " << err.msg << endl;
return;
} catch (...) { //catch the rest
cerr << "-> Unknown C++ exception" << endl;
return;
}
}

void outer(char *infile)
{
__try {
inner(infile);
} __except(1) {
cerr << "-> Win32 exception" << endl;
}
}

[Selur]

Yes, I assumed that the only thing 'Invoke' would throw would be a AvisynthError,.. :/

[TheFluff]

In ordinary circumstances, that is true, and in your test case there it probably is throwing that kind of exception. Your program just dies because of errors in the exception handling.

[Selur]

@LoRd_MuldeR: thanks! the try-except helped. :)

[TheFluff]

http://blogs.msdn.com/b/jaredpar/archive/2008/01/11/mixing-seh-and-c-exceptions.aspx

[Atak_Snajpera]

I have a question.
Why Addborders function in Avisynth 2.6 does not accept odd numbers like in 2.5.8. With AddBorders(0,9,0,9) I get an error message saying that value has to be mod 2 in YUV.

[Groucho2004]

I have a question.
Why Addborders function in Avisynth 2.6 does not accept odd numbers like in 2.5.8. With AddBorders(0,9,0,9) I get an error message saying that value has to be mod 2 in YUV.

I suppose because 2.6 doesn't use this little trick (in transform.cpp):

if (vi.IsYUV())
{
// YUY2 can only add even amounts
left = left & -2;
right = (right + 1) & -2;
if (vi.IsYV12())
{
xsub = 1;
ysub = 1;
top = top& -2;
bot = (bot + 1)& -2;
}
}

[IanB]

In 2.5.8 AddBorders blindly adjusted invalid values to the nearest valid ones. So AddBorders (9,9,9,9) silently became AddBorders(8,10,8,10). This tended to mask such errors in scripts causing unexpected results.

In 2.6 the decision was taken to never adjust or mask user input that violated the chroma sub-sampling constraints and to always report it.

[Atak_Snajpera]

So I see that from now on I will have to do something like this

video=Spline36Resize(video,720,462).ConvertToYUY2.AddBorders(0,9,0,9).ConvertToYV12

[Wilbert]

So I see that from now on I will have to do something like this
Just like IanB said: AddBorders(8,10,8,10). You will get the same result as before.

[AvxSynth Pirate]

Folks,

has anyone tested executing SoftWire-generated code on 64-bit systems ? I've been trying to port it to AvxSynth, and have certain issues which I'd like to discuss (possibly offline ?)

[Wilbert]

There seems to be an issue with Overlay and YV24. The following script results in a crash (thx to Unreal666 for reporting the issue):

in = BlankClip(width=768, height=575, pixel_type="YV24") # other pixel types work fine
tmp = in.BlankClip(width=height(in)*16/9/2*2).ConvertToYV24()
tmp.Overlay(in) #only mode="Chroma" seems to work


In overlay.cpp:
PVideoFrame __stdcall Overlay::GetFrame(int n, IScriptEnvironment *env) {

FetchConditionals(env);

// Fetch current frame and convert it.
PVideoFrame frame = child->GetFrame(n, env);
if (vi.IsYV24() && inputCS == vi.pixel_type) { // Fast path
// This will be used to avoid two unneeded blits if input and output is yv24
// Note however, that this will break, if for some reason AviSynth in the future
// will choose different alignment on YV24 planes.
if (img)
delete img;
img = new Image444(frame->GetWritePtr(PLANAR_Y), frame->GetWritePtr(PLANAR_U), frame->GetWritePtr(PLANAR_U),
frame->GetRowSize(PLANAR_Y), frame->GetHeight(PLANAR_Y), frame->GetPitch(PLANAR_Y));
} else {
inputConv->ConvertImage(frame, img, env);
}

I guess the third write pointer should write PLANAR_V instead of PLANAR_U, but that doesn't cause the crash.

It can't evaluate 'frame->GetWritePtr(PLANAR_Y)', but i don't understand why. Perhaps it's not writable. Putting 'env->MakeWritable(&frame);' in front of the Image444 call seems to solve the problem:


PVideoFrame __stdcall Overlay::GetFrame(int n, IScriptEnvironment *env) {

FetchConditionals(env);

// Fetch current frame and convert it.
PVideoFrame frame = child->GetFrame(n, env);
if (vi.IsYV24() && inputCS == vi.pixel_type) { // Fast path
// This will be used to avoid two unneeded blits if input and output is yv24
// Note however, that this will break, if for some reason AviSynth in the future
// will choose different alignment on YV24 planes.
if (img)
delete img;
env->MakeWritable(&frame);
img = new Image444(frame->GetWritePtr(PLANAR_Y), frame->GetWritePtr(PLANAR_U), frame->GetWritePtr(PLANAR_V),
frame->GetRowSize(PLANAR_Y), frame->GetHeight(PLANAR_Y), frame->GetPitch(PLANAR_Y));
} else {
inputConv->ConvertImage(frame, img, env);
}

[IanB]

Recently reported here "Overlay and YV24 (http://forum.doom9.org/showthread.php?p=1560468#post1560468)".

And fixed here (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/overlay/overlay.cpp?r1=1.18&r2=1.19).

[Gavino]

fixed here (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/overlay/overlay.cpp?r1=1.18&r2=1.19)
What about Wilbert's other point?
I guess the third write pointer should write PLANAR_V instead of PLANAR_U

[gyth]

Would a version increment be possible?
I'd like to be able to use version number to check if audiotrim will be available.

Assert(VersionNumber >= 2.6, "[ERROR] AVISynth 2.60 required, found "+VersionString)

And could there be a sample based version?
I'm faking it like this for now.
ar=AudioRate
AssumeSampleRate(4672).audiotrim(1,0).AssumeSampleRate(ar)

[StainlessS]

Time("%c") "Date and time representation appropriate for locale",

Here in the UK I'm getting eg "04/27/12 09:37:43", ie 4th day of the 27th month,
in the UK, we rarely have more than 12 months in the year.

In Control Panel (XP), "Regional and Language Options", under "Short Date" it
gives "27/04/2012" for today.

EDIT: UK Longdate=27 April 2012,
via Time(%#c) gives Long Date & Time, "Friday, April 27, 2012 22:24:41",
Less confusing but not right.

EDIT: Glad I dont live on Venus, where a day is actually longer than a year.
(And the sun rises in the West, once a day, {~245 Earth days}, I think).

[TheFluff]

Blame microsoft's implementation of strftime(3), or blame whoever did setlocale(LC_ALL, "C").

That being said, if you want a specific format, use a specific format string. I strongly doubt strftime() will respect the date/time format settings in the windows control panel under any circumstances.