AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]

[StainlessS]

@VcMohan

As you recently posed a query on compiling for both v2.58 and v2.6a4, I assume that you want subsampling for both.
Below some code I use in RoboCrop, perhaps of use:

    myName="RoboCrop: ";

    if(vi.width==0 || vi.num_frames==0)         env->ThrowError("%sClip has no video",myName);
    # ifdef AVISYNTH_PLUGIN_25
        if(vi.IsPlanar() && vi.pixel_type != 0xA0000008) {              // Planar but NOT YV12, ie Avisynth v2.6+ ColorSpace
            // Here Planar but NOT YV12, If v2.5 Plugin Does NOT support ANY v2.6+ ColorSpaces
            env->ThrowError("%sColorSpace unsupported in v2.5 plugin",myName);
        }
    # endif

    bool isyuv=false,isplanar=false,isyuy2=false,isrgb=false,isy8=false;
    int xmod=1,ymod=1;

    if(isyuv=vi.IsYUV()) {
        if(isplanar=vi.IsPlanar()) {
            PVideoFrame src = child->GetFrame(0, env);                  // get frame 0
            int rowsizeUV=src->GetRowSize(PLANAR_U);
            if(rowsizeUV!=0) {                              // Not Y8
                const int ywid=src->GetRowSize(PLANAR_Y);
                const int yhit=src->GetHeight(PLANAR_Y);
                const int uhit=src->GetHeight(PLANAR_U);
                xmod=ywid/rowsizeUV;
                ymod=yhit/uhit;
            } else {
                isy8=true;
            }
        } else {
            isyuy2=true;
            xmod=2;
        }
    } else {
        isrgb=true;
    }

    xSubS=xmod;     // for Planar GetFrame
    ySubS=ymod;

    laced           =   args[3].AsBool(true);
    ymod = (laced)? ymod*2 : ymod;

v2.58 header does not contain GetWidthSubsampling/GetHeightSubsampling

[martin53]

Please forgive me if I'm wrong or if the issue is already known - I couldn't find a similar post.

I suspect a 'memory leak' in the ConvertToYV24() function of V2.60.
I load the test script

ColorBars()
#~ ConvertToYV24()
ScriptClip("return last")

with XMediaRecode and observe its memory usage with ProcessExplorer. While converting the script to a HuffYuv AVI file, XMediaRecode's memory usage stays constant btw. 87 and 90 MBytes.
With the uncommented ConvertToYV24() Line, memory usage grows and grows. With more complex scripts (a ~15 line scriptclip that overlays 4 lines calculated with RTE stats functions over a Histogram("color2") ), the encoder crashes when memory usage reaches about 1,8MBytes.
VDub Portable (1.9.11) also crashes with a message "Think we ran out of memory folks".
OS details in this thread

EDIT: This is the crash script. Omit 'ConvertToYV24()', then it uses about 560MB, not more.

#=====================================================================================================================
function UVMeterBad(clip c) {
	c
	ScriptClip("""	#"
		c = Last
		c1 = c.crop(0,0,-256,0)
		cU = c1.UToY.BicubicResize(c1.width, c1.height)
		cV = c1.VToY.BicubicResize(c1.width, c1.height)
		MYStats(cU, flgs=$23)
		Um= MYS_yMin	#cU.RT_YPlaneMin()
		Ux= MYS_yMax	#cU.RT_YPlaneMax()
		Us= round(MYS_yStdev)	#round(cU.RT_YPlaneStdev)
		MYStats(cV, flgs=$23)
		Vm= MYS_yMin	#cV.RT_YPlaneMin()
		Vx= MYS_yMax	#cV.RT_YPlaneMax()
		Vs= round(MYS_yStdev)	#round(cV.RT_YPlaneStdev)
		Ymax = c1.YPlaneMax()
		MYStats(cU, c1, flgs=$10, prefix="MUS_", MaskMin=Ymax-1)
		MYStats(cV, c1, flgs=$10, prefix="MVS_", MaskMin=Ymax-1)
		c
		Overlay(BlankClip(c,pixel_type="RGB32",color=$80ff00,width=57,height=1),x=c.width-157,y=127,mode="Exclusion")	#cross hor.
		Overlay(BlankClip(c,pixel_type="RGB32",color=$80ff00,width=1,height=57),x=c.width-129,y=99,mode="Exclusion")	#cross vert.
		Overlay(BlankClip(c,pixel_type="RGB32",color=$ffffff,width=Ux-Um,height=1),x=c.width-129+Um-128,y=127+round(MVS_yAve)-128,mode="Exclusion")	#range hor.
		Overlay(BlankClip(c,pixel_type="RGB32",color=$ffffff,width=1,height=Vx-Vm),x=c.width-129+round(MUS_yAve)-128,y=127+Vm-128,mode="Exclusion") #range vert.
		return last
	""", local=true)	#"
	return last
}
#=====================================================================================================================
ColorBars(pixel_type="YV12")
ConvertToYV24()
Histogram("color2")
UVmeterBad()

[Groucho2004]

Originally Posted by martin53

ColorBars()
#~ ConvertToYV24()
ScriptClip("return last")

I can't reproduce this with the given script. I loaded it into VDub and encoded also to HuffYUV. Memory usage settles at about 140K. OS is XPSP3.

[Groucho2004]

Originally Posted by martin53

This is the crash script.

Script error: ScriptClip does not have a named argument "local"

[StainlessS]

@Martin53,
There is a known Overlay bug in v2.6a4, here:
http://forum.doom9.org/showthread.ph...03#post1624303

Use Groucho2004's ICL Avisynth.dll with fixed OverLay for YV24. (just overwrite dll in sytem32/SysWOW64)

EDIT: Groucho, Local is for the GScript version Scriptclip. EDIT: Actually Grunt, not Gscript.

[martin53]

Originally Posted by Groucho2004

I can't reproduce this with the given script.

Did you remove the comment marks?

[Groucho2004]

Originally Posted by StainlessS

Groucho, Local is for the GScript version Scriptclip.

Ah, I see.

[martin53]

Originally Posted by StainlessS

Use Groucho2004's ICL Avisynth.dll

Please give me a hint where I find this dll.

[Groucho2004]

Originally Posted by martin53

Please give me a hint where I find this dll.

Here you go.

[StainlessS]

Groucho, see here for recent nasty little problem concerning GScript Local solution. EDIT: Actually Grunt, not Gscript.
http://forum.doom9.org/showthread.php?t=168538

[martin53]

Originally Posted by Groucho2004

yes, I did.

OK, I also rechecked in parallel and found after the 1st post that some of my experiments stabilized, so what I had assumed to be bad was not always. I always try to give a most simple example, but alas, that misleads me sometimes. Please look at my edit, but StainlessS already posted that it's not ConvertToYV24() alone, but together with Overlay() - as in my real problem script. So, if you'd be so kind to indicate where I can find the fixed dll, thank you!

[martin53]

Here you go.

Many thanks!

[Gavino]

Originally Posted by StainlessS

Local is for the GScript version Scriptclip.

Actually, it's from the GRunT version.

But I expect you can just leave out local=true as I doubt it has anything to do with the problem.

EDIT: Looks like you've now found the solution anyway.

[StainlessS]

OOooops, yes of course.

[vcmohan]

@stainless .Thanks. But I avoided the hassle by adding three calls in avisynth.h 2.5. IsY8() returning false, GetHeight/width subsampling returning 0 or 1. At parameter checking itself I ensure the input formats . In my plugin code I do not by name check any other Planar formats.

[ultim]

Hello, I've got another question about the alignment code, this time though it is purely technical and not ideological

In both NewVideoFrame and NewPlanarVideoFrame, assuming that we need a buffer of size large, the methods reserve size+align*4. For alignment only, size+align-1 is enough, so I was wondering if this overreserve is accidential, or it this on purpose and the align*4 is needed for some implementation detail that I was too stupid to spot.

Contextual information (rant): You might be thinking,"WUUT, this strange dude is still working on alignment?" Yes and no. Well, first of all I cannot allow myself to work on avisynth every day, so progress is steady, but slow. But more importantly, since my last questions about alignment in avisynth I have done a lot of magic (many-many hours) using Git's rebase to clean up my repository, in the hope that upstream (IanB) will accept my proposals this way, when I finally publish them. So that he'll get nice patches Now that I'm done, I'm continuing where I left off, which is (yeah you guessed right) alignment. It looks like I am reverting about 99.9% of my alignment patches, but I still like to understand things even if I don't modify them, which is why I'm asking the question in the beginning of this post. Cheers and thank you for your help!

[IanB]

The off hand answer is so you can run off the end safely with an sse load or store, but as you say size+align-1 would be sufficient. So I don't know, may be you can do some archaeology and find an answer. Here is a link to version 1.1 of Avisyntn.cpp, Thu Jul 4 13:16:41 2002 UTC (11 years, 2 months ago) by richardberg as originally supplied by BenRG. Around version 1.9 Sh0dan started doing something with improving alignment.

[ultim]

Originally Posted by IanB

The off hand answer is so you can run off the end safely with an sse load or store, but as you say size+align-1 would be sufficient. So I don't know, may be you can do some archaeology and find an answer. Here is a link to version 1.1 of Avisyntn.cpp, Thu Jul 4 13:16:41 2002 UTC (11 years, 2 months ago) by richardberg as originally supplied by BenRG. Around version 1.9 Sh0dan started doing something with improving alignment.

Thanks IanB! I really appreciate you being here for us every day and helping us.

As for the reason of the memory allocation in question, I looked at the repository, but unfortunately, there is nothing there to answer me. In the initial checkin (first-ever version 1.1 of avisynth), where the supported alignment was only 8 bytes, the reserved extra space was already 32 bytes. So even here, farthest back in the history, we see that align*4 is used. "+32" was then refactored to "+align*4" in revision 1.12 (Mon Feb 10 16:42:40 2003), but even there, the commit only contains the unhelpful message of "Moved avisynth_2_1 onto MAIN".

"so you can run off the end safely with an sse load or store" cannot be the reason either, because the row pitch (which is calculated based on the alignment) already makes sure that such things cannot happen.

So I have no explanation for the current code right now, so I'm gonna try changing it to "+align-1", do some tests and see if anything breaks apart. My bet is that everything will still work as expected, but ofc it wouldn't be the first time for me to be wrong.

[Wilbert]

I moved all the posts about the fork of ultim to this thread: http://forum.doom9.org/showthread.php?t=168856

[IanB]

Next version, AviSynth 2.6.0 Alpha5 [Sep 18th, 2013]

Also a clickable link for the post above Avisynth forks

I wish link parsing could be re-enabled, in the meantime I wish people would manually do the tags themselves,
i.e. [url]http://forum.doom9.org/showthread.php?t=168856[/url]