AviSynth 2.6.0 Alpha3 [May 25th, 2011]

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

[forclip]

Hi IanB. I want to report a weird audio regression in AviSynth 2.6. For example, using something like this:


video = BlankClip(length=4248, fps=25.000, color=$000000)
audio = NicAC3Source("E:\Temp\1804_0.ac3")
AudioDub(video, audio)


ConvertAudioToFloat()

aa = GetChannel(last, 1)
bb = GetChannel(last, 1)

aa = MixAudio(aa, bb, 0.5, 0.5)
bb = MixAudio(aa, bb, 0.5, 0.5)

MergeChannels(aa, bb)

ConvertAudioTo16bit()


makes audio processing speed and output different from run to run. My application interact with AviSynth via well known AviSynthWrapper.dll.
Now, for example, I want to find peaks in the stream (to apply AmplifydB() later). And the strange is that sometimes the process takes only 2-3sek, sometimes 5-6sek,
and sometimes 12-13sek. Also calculated peaks level different for all 3 cases: 2.807, 2.742 and 2.738 dB accordingly. Tested with build from 25.05.2011 and with
the latest SEt's build. But this problem seems not exists in build from 27.09.09.

Also, while trying to check how it works with different audio decoders, I've found that with bassAudioSource, when it "slows", peak level = 0dB (2.699dB when
this slowness not appears). Strange.. Streamed AviSynth output to WAV and that's how it looks (25 vs 09 = 25.05.2011 vs 27.09.09):

REMOVED

With FFAudioSource seems like there is no problem, but it decode this track as 16bit, while bassAudioSource as 32 float. Strange, but ConvertAudioToFloat(), that already present in the script, didn't change anything in this case.

If you want some additional info - just let me know.

[IanB]

Warning!! The upload site imagebam.com serve hard core porn advertisement's. Do not view the image in the above post in sensitive environments.

[forclip]

Sorry, using AdBlock I can't see such a things, so it wasn't intentionally. Link removed.

[IanB]

@forclip,

With the script as quoted, and substituting a 384Kbit stereo .AC3 file I had lying around, I see no problem with any versions of Avisynth.dll from 2.5.8.5, 2.6.0.0, 2.6.0.1, 2.6.0.2, current CVS and my current development version. I used a fairly old modified NicAudio.dll I built myself based on version 2.0.0.5. circa 2007.

I tried a single pass linear save of the output stream as well as random spot playback.


From your avs_audio.png image, the bass25.wav sample has a big jump in level at around 2:10, this might be bugs with decoding your file with seeking. Add the EnsureVBRMP3Sync() filter to your NicAC3Source() and observe any change in behaviour. Also try to reproduce the results using ColorBars() in place of NicAC3Source() for the audio source.

[forclip]

Ok. With ColorBars() I also can reproduce this strange slowness issue, however audio output seems to be fine and it is not as slow as with the real sources. Using this script:

ColorBars().Trim(0, 50000)
MergeChannels(last, last, last)
MergeChannels(last, last)
ConvertAudioTo16bit()

with AviSynth 2.6 from 2009 it takes ~18sek to find the peaks. With more recent version(s) it takes ~23sek. Also, to get broken output my previous script can be simplified like this:

video = BlankClip(length=4248, fps=25.000, color=$000000)
audio = bassAudioSource("E:\Temp\1804_0.ac3")#.EnsureVBRMP3Sync()
AudioDub(video, audio)

MergeChannels(last, last)
ConvertAudioTo16bit()

The result is attached (and I will PM you with the source file). Uncommenting EnsureVBRMP3Sync() makes the things SLOW AS HELL, it takes something aboud 15 minutes to process! However, the output seems to be OK, but I've tried it only once since it is really VERY-VERY slow. But as I mentioned in my first post, this slowness sometimes appears, sometimes not, but most of the time it appears. Replacing avisynth.dll to version from 2009 - and exactly the same script ALWAYS takes only 4-5sek to precess, w\o any slowness. Before switching to AviSynth 2.6 (from 2.5.8 MT) I've never heard from my users about any problems related to audio processing (except "audio crash" that in 2.6 is fixed), now after we are using AviSynt 2.6, some of them reporting me that audio processing is SLOW from now. I can reproduce it on my side, also I can reproduce it in MeGUI, so this is not my app fault. This strange slowness can be reproduced with avs2wav too, but output seems to be OK, or I've tested it not very well..

Any ideas?

[tebasuna51]

Please, send me also the source file 1804_0.ac3 to see if I can detect any trouble decoding whit NicAc3Source/bassAudioSource.

I don't know for what EnsureVBRMP3Sync() can make differences decoding CBR audio, like ac3 must be.

[IanB]

@forclip,

Between 2.6.0.1 and 2.6.0.2 the ac_expected_next update line was moved later in the code, so for the no audio cache state the skipping chunks case was constantly being incorrectly triggered. This led to all the default audio caches needlessly becoming enabled resulting in lots of extra memcpy'ing happening, slowing things down. Not sure if it's the whole cause but it does have quite a performance impact....
long _cs = ac_currentscore;
if (start < ac_expected_next)
_cs = InterlockedExchangeAdd(&ac_currentscore, -5) - 5; // revisiting old ground - a cache could help
else if (start > ac_expected_next)
_cs = InterlockedDecrement(&ac_currentscore); // skiping chunks - a cache might not help
else // (start == ac_expected_next)
_cs = InterlockedIncrement(&ac_currentscore); // strict linear reading - why bother with a cache

...

>> ac_expected_next = start + count;

if (h_audiopolicy == CACHE_AUDIO_NONE || h_audiopolicy == CACHE_AUDIO_NOTHING) {
child->GetAudio(buf, start, count, env);
return; // We are ok to return now!
}

...

<< ac_expected_next = start + count;

while (count>maxsamplecount) { //is cache big enough?


@tebasuna51,

EnsureVBRMP3Sync() adds a 1MB audio cache and causes a high penalty for any out of order accesses outside the audio cache (a seek to zero plus a linear read up to the new position). It made a good diagnostic tool here.

[forclip]

Great. Now I need to get a new build to check how it works..

[tebasuna51]

...
EnsureVBRMP3Sync() adds a 1MB audio cache and causes a high penalty for any out of order accesses outside the audio cache (a seek to zero plus a linear read up to the new position). It made a good diagnostic tool here.

The: (a seek to zero plus a linear read up to the new position)

is only needed for VBR audio, with CBR you can access directly to needed frame to decode.

The GetAudio function from NicAc3Source do (with SAMPLES_PER_FRAME, StreamOffset and FrameLength fix and know for each ac3):

if (start < BufferStart || start > BufferEnd)
{
// Calculate the index and the sample range of the required frame
_FrameIndex = FrameIndex;
FrameIndex = int(start / SAMPLES_PER_FRAME);
BufferStart = __int64(FrameIndex) * SAMPLES_PER_FRAME;
BufferEnd = BufferStart + SAMPLES_PER_FRAME;

// Seek to the frame, if required
if (FrameIndex != _FrameIndex + 1)
{
_fseeki64(Stream, StreamOffset + __int64(FrameIndex) * __int64(FrameLength), SEEK_SET);

[forclip]

IanB
Thanks for the fix and thanks for the build, seems like this issue is not reproducible anymore :thanks:

[tebasuna51]

IanB
Thanks for the fix and thanks for the build, seems like this issue is not reproducible anymore :thanks:
What build work for you?
The last AVS 2.6.0 Alpha 3 [110525] in SourceForge or a new one?

[IanB]

I gave forclip a private copy of my experimental development version. I have checked the fix into CVS.

The problem was as described above with the ac_expected_next calc being to late in the code.

[Wilbert]

Hi, two comments:

In conditional_functions.cpp:

AVSValue MinMaxPlane::MinMax(AVSValue clip, void* user_data, float threshold, int plane, int mode, IScriptEnvironment* env) {
...
env->ThrowError("Compare Plane: This filter can only be used within run-time filters");

should be MinMax Plane instead of Compare Plane.

Also in avisynth.cpp:

PVideoFrame __stdcall ScriptEnvironment::NewVideoFrame(const VideoInfo& vi, int align) {
...

if (vi.IsPlanar() && !vi.IsY8()) { // Planar requires different math ;)
const int xmod = 1 << vi.GetPlaneWidthSubsampling (PLANAR_U);


empty space should be removed (between sampling and the bracket), or is that allowed?

[Gavino]

const int xmod = 1 << vi.GetPlaneWidthSubsampling (PLANAR_U);


empty space should be removed (between sampling and the bracket), or is that allowed?
White space is not significant, so it's OK.
But perhaps for aesthetic reasons, all three uses of GetPlaneXXXSubsampling in that function should be written the same way. ;)

[StainlessS]

This looks like a bug from Y8 to ConvertToRGB24(), to me.


Colorbars().convertToY8()
Addborders(0,0,5,0)
#crop(0,0,-5,0) # Uncomment, No Red Stripe.
ConvertToRGB24() # Produces LHS vertical Red Stripe in Current VDub & MediaPlayer Classic Home Cinema.
#ConvertToRGB32() # No red stripe
#Addborders(3,0,0,0) # EDIT: Red stripe still there.


EDIT: Tried values up to about 15, only adding 5 on RHS produced the single pixel wide stripe.

[Wilbert]

EDIT: Tried values up to about 15, only adding 5 on RHS produced the single pixel wide stripe.
Good one. The following shows the same problem:

Colorbars(width=645, height=480, pixel_type="YV24")
ConvertToRGB24()

It looks like the left column of pixels is not being written in ConvertYV24ToRGB for pixel_step=3 (RGB24) in some cases. It's in the assembly stuff i think, so i need to pass.

[StainlessS]

Colorbars().convertToY8()
ERR=1 # Vary ERR 0+, Errors at eg 5, 21, 37, 53, 69
Addborders(0,0,ERR*16 + 5,0)
#crop(0,0,-5,0) # Uncomment, No Red Stripe.
ConvertToRGB24() # Produces LHS Red Stripe in Current VDub & MediaPlayer Class Home Cinema.
#ConvertToRGB32() # No red stripe
#Addborders(3,0,0,0) # EDIT: Red stripe still there.

Seems to be every multiple of 16 + 5

[IanB]

Yes the RGB24 overrun save and mask code is borked. It shows up for width%16 == 5.

:Edit: RGB24 AddBorders(N, x, 0, y), N not mod 12 or not mod 16 is also borked.

[IanB]

Fix committed to CVS ConvertToRGB24() (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/convert/convert_matrix.cpp?r1=1.5&r2=1.6&sortby=date)

Fix committed to CVS AddBorders() (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/transform.cpp?r1=1.14&r2=1.15&sortby=date)

[ryrynz]

I have to ask.. how's development coming along IanB? Your first post for this thread mentioned an update when you had more time three years ago. :)

[StainlessS]

There is an update and its called v2.6.0 alpha3 25 May 2011 (about 14.5 months ago, not 3 years).
See 1st post.

EDIT: Thread was started 2009, but has endured several editions of v2.6.
EDIT: Perhaps a more (current) full date in thread title would be better, ie the year.

[cretindesalpes]

Why don't we have IsY8 and IsYV411 at the script level? We currently have to write helper functions to achieve this, which is not very convenient. To know the chroma subsampling H & V ratios would be useful too.

[StainlessS]

Why don't we have IsY8 and IsYV411 at the script level? We currently have to write helper functions to achieve this, which is not very convenient. To know the chroma subsampling H & V ratios would be useful too.

+1 on that.

[IanB]

Need help with AviSynth 2.6. The performance with Yatta is just too slow for me.

I downloaded Alpha 3 and Yatta now crawls. Now I know 2.6 and Yatta work as it seems I'm alone with this issue, everyone else I've talked to say no problems. I don't think it's a hardware issue as others with lesser hardware are having no issues.

So I'm asking AviSynth developers, any idea what could be going on? As soon as I replace the AviSynth.dll with the 2.5.8 version in SysWow64, the performance of Yatta skyrockets. Replace with 2.6, it's a slideshow.First time I tried to reproduce this bug with yatta I couldn't do it (was a dvd with mpeg2dec3 source).

I decided to try something else, a transport stream with dgdecode 1.58 (dvd2avi barfs with this transport stream for some reason) and was able to reproduce the problem as described above (maybe it's specific to dgdecode? mpeg2dec3 seemed unaffected). I suppose dgdecode with any source (doesn't have to be a transport stream) might trigger the problem but this is what I was able to reproduce it with since it's the only thing I really had on hand that I had already saved a dgdecode project with (I generally use dvd2avi for all mpeg2 stuff).

Everything you need:
http://warpsharp.info/random/gosick-avs26-slow.7z

Adjust paths in d2v/yap file then load with yatta (latest 7-131 beta). Hold down the right arrow key (which advances it forwards by 1 frame at a time, holding it down will seek forward) and watch it go really slow (try it again with 2.58 and it'll be fast). Drag around the seek bar too if you want, that'll be slow too. Also, if you hit the preview button (brings up the preview of what it would look like if you loaded the generated script in vdub or something) that preview seems unaffected for some reason.

Although we kind of skipped the ymc step (since I provided the yap for you) it's slow with the preview windows in that as well (cutter and crop, I can't tell if tfm/telecide's preview are affected as they are about the same speed). Avsp and vdub preview seem unaffected and work ok (with loading the avs generated with this yap file (right click anywhere in the video, save all overrides if you like to try it yourself)).when I open a .d2v directly with yatta, yatta goes slow as hell.
however, when I write an .avs like mpeg2source("foo.d2v") and open it with yatta, it seems not to happen.I have finally worked out what is happening with Yatta on Ziddy76's system.

Yatta uses env->Invoke() to build an Avisynth graph to do it's magic. For a .avs file it builds
_ Import("file.avs").ConvertToRGB32().Cache().
For a .d2v source it builds
_ Mpeg2Source("file.d2v").ConvertToRGB32().Cache().

For a YV12 source in Avisynth 2.5.8, ConvertToRGB32() is implemented as YV12.ConvertToYUY2().ConvertYUY2ToRGB32(), and in Avisynth 2.6.0 it is implemented as YV12.ConvertToPlanarGeneric(YV24).ConvertYV24ToRGB(RGB32). ConvertToPlanarGeneric() works it's magic by splitting off the chroma planes to Y8 clips and running them through the resizer core, then bliting the 3 planes back together.

Thus the YV12 source clip is hit 3 times for each output frame, normally the cache deals with this. When using env->Invoke() caches instances are not automatically added, so poor Mpeg2Source gets each frame requested 3 times in the .d2v case. A side effect of invoking Import is that normal cache addition is performed, so in the .avs case it is much faster. Mpeg2Source is highly optimised to deliver frames sequentially in order, if the request is not for frame N+1 then the random seek path is taken and the relevant GOP is decoded from the beginning.

Other code paths that use ConvertToPlanarGeneric() were also suffering from a lack of cache, e.g. RGB32.ConvertToYV12() is almost 3 times faster and is the same speed as RGB32.ConvertToYV24().ConvertToYV12()

I will check the fixes into CVS in the next few days.

[StainlessS]

Addborders bug:


ColorBars(1364,625,pixel_type="RGB32").ConvertToRGB24()
addborders(0,199,0,0,$FF0000)


Left hand side vertical green stripe, top addborders area all horizontally stripey. :eek:

[IanB]

:Edit: RGB24 AddBorders(N, x, 0, y), N not mod 12 or not mod 16 is also borked.
Fix committed to CVS AddBorders() (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/transform.cpp?r1=1.14&r2=1.15&sortby=date)
Confirmed, fixed in CVS

[StainlessS]

Thankyou, sorry did not notice your edit.

[StainlessS]

# 2.6, Windows Media Player 2
Scriptname= C:\z\26.avs
ScriptDir= C:\z\
Scriptfile= 26.avs

simulated scriptdir= C:\z\ # Nothing to do with problem, just pointing out

# 2.6 smplayer, http://smplayer.sourceforge.net/
Scriptname= C:/z/26.avs
ScriptDir= C:\z\
Scriptfile= 26.avs

simulated scriptdir= C:/z/26.avs, line 10) # Nothing to do with problem, just pointing out problem in synthetic functions


2.6 ScriptDir DOS style '\' whereas, ScriptName uses Unix '/', presume one or other is an error.

EDIT: NOt quite the same problem, but in the same ballpark, (maybe):
http://forum.doom9.org/showthread.php?p=1590302#post1590302

[IanB]

ScriptName is the raw passed in string to Import() and is also passed down to the resulting invoke of Eval() for it's error message handling.

ScriptDir and ScriptFile are the result of that string being edited by GetFullPathName() or SearchPath() and as used by the actual file open call, CreateFile().

Simulated ScriptDir and ScriptFile use the error message string from Eval() and do not have access to the actual string used on CreateFile().

The distinction is also shown when using relative paths like "..\..\lib\mylib.avsi".

avisynth > src > core > parser > script.cpp...
303 const char* script_name = args[i].AsString();
304
305 TCHAR full_path[MAX_PATH];
306 TCHAR* file_part;
307 if (strchr(script_name, '\\') || strchr(script_name, '/')) {
308 DWORD len = GetFullPathName(script_name, MAX_PATH, full_path, &file_part);
309 if (len == 0 || len > MAX_PATH)
310 env->ThrowError("Import: unable to open \"%s\" (path invalid?)", script_name);
311 } else {
312 DWORD len = SearchPath(NULL, script_name, NULL, MAX_PATH, full_path, &file_part);
313 if (len == 0 || len > MAX_PATH)
314 env->ThrowError("Import: unable to locate \"%s\" (try specifying a path)", script_name);
315 }
316
317 HANDLE h = ::CreateFile(full_path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
318 if (h == INVALID_HANDLE_VALUE)
319 env->ThrowError("Import: couldn't open \"%s\"", full_path);
320
321 env->SetGlobalVar("$ScriptName$", env->SaveString(script_name));
322 env->SetGlobalVar("$ScriptFile$", env->SaveString(file_part));
323
324 *file_part = 0;
325 CWDChanger change_cwd(full_path);
326
327 env->SetGlobalVar("$ScriptDir$", env->SaveString(full_path));
...
350 AVSValue eval_args[] = { (char*)buf, script_name };
351 result = env->Invoke("Eval", AVSValue(eval_args, 2));
...

[StainlessS]

Thank you kind sir, Managed to create synthetic access to ((I think) line 319 full_path


318 if (h == INVALID_HANDLE_VALUE)
319 env->ThrowError("Import: couldn't open \"%s\"", full_path);


via _GetWorkingDir(), here:
http://forum.doom9.org/showthread.php?p=1590402#post1590402

[StainlessS]

Possible problem in Avisynth recommended API usage, posting link here as suggested by Groucho2004.

http://forum.doom9.org/showthread.php?p=1595368#post1595368

[IanB]

Best guess is it needs an env->DeleteScriptEnvironment() call, new in 2.6, at the end of processing, delete env does not work correctly across msvcrt environments.

The thing=new object; and delete thing; have to be under the same msvcrt environment.

For 2.5 you might be able to directly call env->~IScriptEnvironment(); and then just free(env); to dodge the RT bullet, but this would be in the highly dubious coding practise category and need to be thoroughly traced for each case.

[Groucho2004]

Best guess is it needs an env->DeleteScriptEnvironment() call, new in 2.6, at the end of processing, delete env does not work correctly across msvcrt environments.

The thing=new object; and delete thing; have to be under the same msvcrt environment.

For 2.5 you might be able to directly call env->~IScriptEnvironment(); and then just free(env); to dodge the RT bullet, but this would be in the highly dubious coding practise category and need to be thoroughly traced for each case.

The code for AVSMeter essentially boils down to this (linked to avisynth.lib, using 2.5 API):

try
{
IScriptEnvironment *env = CreateScriptEnvironment(AVISYNTH_INTERFACE_VERSION);

if (!env)
{
printf("%s\n", (LPCTSTR)pad("Could not create IScriptenvironment"));
return -1;
}

AVSValue val;
PClip clip;
PVideoFrame frame;
VideoInfo vidinfo;

clip = val.AsClip();

for (unsigned int uiCurrentFrame = 0; uiCurrentFrame < vidinfo.num_frames; uiCurrentFrame++)
frame = clip->GetFrame(uiCurrentFrame, env);

frame = 0;
clip = 0;
val = 0;
}
catch(AvisynthError err)
{
printf("\r%s\n", err.msg);
return -1;
}



"delete env" is not used because of the reasons you mentioned above and the program ends anyway after exiting the loop.
I don't see how this code could cause problems.