AviSynth 2.6.0 [May 31st, 2015]

[Groucho2004]

I do wonder though what's different about the output of NNEDI3 that causes this to happen. I've had no issues with any other filters.
Have you tried what I suggested in my edit above?

[ryrynz]

Tried it, threads=1 and 0, also tried opt=1 and fapprox=0, no change.

[foxyshadis]

Try ending the scripts with Info() to figure out what colorspace nnedi3 is converting to. Maybe that'll sort it.

[real.finder]

ColorBars(width=640, height=480, pixel_type="RGB32")
ConvertToYV12(interlaced=true,chromaoutplacement="dv")
SeparateFields
uToY



ColorBars(width=640, height=480, pixel_type="RGB32")
Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true)
SeparateFields
uToY


there are a noticeable difference in vertical shift between them, I think the ConvertToYV12 do the dv-pal chroma with reverse u and v in shifting

----


edit: look like it not in ConvertToYV12 only

test with yv16

ColorBars(width=640, height=480, pixel_type="RGB32")
ConvertToYV16(interlaced=true)
SeparateFields
uToY



ColorBars(width=640, height=480, pixel_type="RGB32")
Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true)
ConvertToYV16(chromainplacement="dv", interlaced=true)
SeparateFields
uToY


edit: YToUV(VToY8(), UToY8(), ConvertToY8()) (or SwapUV()) before and after ConvertToXXX will solve the problem

[ryrynz]

Try ending the scripts with Info() to figure out what colorspace nnedi3 is converting to. Maybe that'll sort it.

Info() just shows that YV12 being used. Subtitles delivered by xysubfilter appear perfectly normal on top of the stretched pink and green distorted display. Still no closer to figuring this one out. One thing I didn't mention is that nnedi3 used with awarp4 delivers the proper output.

Also if I launch a script playing that doesn't have nnedi3 in it and then change to one that does via ffdshow raw the output is correct, if I start with that script then the picture is distorted.

Another thing I've noticed is that when using MPC and nnedi3/ffdshow any subtitles displayed get processed by nnedi3, with MPDN they don't.. could that be related somehow? Disabling subtitles completely in MPDN doesn't change anything so I guess not.

[StainlessS]

Below Fails in v2.5 but works ok in v2.6.


INPUT=avisource("F:\V\cabaret.avi")
return last


Only mentions of 'Last' in v2.6 ChangeList below


Fixed AviSource NULL GetWritePtr() failure due to premature setting of last_frame.
WriteFileStart/End save current_frame and set Last.
Change implicit Last parsing for argless, bracketless calls to match bracketed cases. (Gavino)


Is it a bug or undocumented change ?

EDIT: Same for

INPUT=Directshowsource("F:\V\cabaret.avi")
return last


EDIT: IGNORE ABOVE ...
Uninstalled Avisynth completely. Deleted remaining Avisynth directory. Ran CCleaner and Cleaned registry too.
Re-installed Avisynth v2.6. No longer succeeds with above code snippit.
No idea at all why it succeeded before :confused::confused::confused::confused::confused::confused:

[Groucho2004]

Hello. Anyone compiled Avisynth using Visual C++ 2015?
Don't do it.
Newer compilers expect the code to be compliant with SEH (Microsoft Structured Exception Handling) which the current code base is not.

Apparently, Avisynth 2.6.1 will be compatible with newer compilers (http://forum.doom9.org/showthread.php?p=1726246#post1726246).

[Groucho2004]

Groucho2004, /SAFESEH:NO
Never used it, I'd have to research what it does and if/how it would help.

[Groucho2004]

I have successfully compiled it (with SEt MT mod). It seems work correctly and exceptions are work too.
Ok. Please run this script with AVSMeter and tell us what happens:
setmemorymax(9999)
n = 12
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 9999)
pointresize(width() - 64, height() - 64).turnleft()
temporalsoften(2,4,8,15,2)
pointresize(width() + 64, height() + 64).turnright()
temporalsoften(2,4,8,15,2)
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)

[Groucho2004]

Groucho2004,
You mean benchmark or memory usage? It works with the same speed as the reference mt 2.6 build and it eats the same memory (using your script or my real usage scripts). The difference is +/-1 %
That script causes Avisynth to throw an out of memory exception after reading 1 or 2 frames. I just wanted to know if your DLL behaves correctly in this situation.

It works with the same speed as the reference mt 2.6 build and it eats the same memory (using your script or my real usage scripts).I'm surprised, to say the least, that the script actually worked for you. :eek:

[Groucho2004]

Groucho2004, I edited "n" to get it working, because it seems to me as a benchmark code for huge frames. A non-edited state gives a memory exception, of course.
Can you post the DLL so we can try it?

Also, did you build the 2.6.0 release code or did you use a current CVS snapshot?

[Groucho2004]

Groucho2004, /SAFESEH:NO
FYI - Ultim and the other AVS+ developers spent many hours re-writing the exception handling code in Avisynth to make it compatible with new compilers.
IanB is doing the same with Avisynth 2.6.1, check the Avisynth CVS.
Yet, you think they are all wasting their time and a simple linker switch would solve the problem?

[Groucho2004]

What problem do you mean? Currently it seems I have no issues yet. If you have any real test case that will crash my build or my build will work incorrectly, please post it. Probably this potential issue is long away from my usage. And, I will try the dev version 2.6.1 later, thanks for a point.
Here (http://stackoverflow.com/questions/550451/will-new-return-null-in-any-case) is some info on one of the issues.
In AVS+, all "new" allocations were checked regarding dependency on returning "NULL" and changed to the non-throwing (std::nothrow) version where applicable.
You can test this by running the script I posted and check the thrown exception. It should look like this:
GetFrameBuffer: Returned a VFB with a 0 data pointer!
size=2123366464, max=2108096512, used=4246732928, free=2113339392, phys=2847870976
I think we have run out of memory folks!
But you're probably just getting something like this:
Evaluate: Unrecognized exception!

The other thing is to implement a way to handle Win32 exceptions (C structured exceptions) as C++ typed exceptions. This can be done by implementing a SEH translator function, that also was done in AVS+.

Yes, your DLL will probably work but it's up to you if you can live with heavily crippled exception handling.

Edit: I just noticed that SEt's modified version does include a SEH exception translator.

[Myrsloik]

This is a less insane version of AVSValue::Assign() in interface.cpp that actually works in both 32 and 64 bit builds:
void AVSValue::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!
array_size = src->array_size;
type = src->type;
string = src->string;
}

I had to fix it when adding my own 2.6 compatibility...

[Fizick]

I tried to recompile C-plugin Yadif with 2.6.0 headers.
GCC and VS compilers detect error in avisynth_c.h with =0 at line:
AVSC_API(int, avs_row_size)(const AVS_VideoInfo * p, int plane=0);
Without =0 compiling is normal.

[Wilbert]

I tried to recompile C-plugin Yadif with 2.6.0 headers.
GCC and VS compilers detect error in avisynth_c.h with =0 at line:
AVSC_API(int, avs_row_size)(const AVS_VideoInfo * p, int plane=0);
Without =0 compiling is normal.
Should be fixed in 2.6.1. Please try.

@rean, your bug should be fixed too in 2.6.1.