AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Robert Martens]

After a trying couple of weeks upgrading some of my equipment I'm finally getting back to plugin development, and I find myself with a couple of colorspace questions.

First off, is the 2.6 header's documentation for "Colorspace properties" finalized yet? I was trying to get a handle on the proper use of GetPlaneXXXSubsampling, and according to the comment block I'm supposed to "Use (X+1) & 3 for GetPlaneWidthSubsampling" and "Use ((X>>8)+1) & 3 for GetPlaneHeightSubsampling", while in practice this doesn't seem to produce the proper results. Simply calling each function returns the values I expect, since it looks like the functions handle the shift, addition and AND themselves:

interface.cpp
----

...

int VideoInfo::GetPlaneWidthSubsampling(int plane) const { // Subsampling in bitshifts!
if (plane == PLANAR_Y) // No subsampling
return 0;
if (IsY8())
throw AvisynthError("Filter error: GetPlaneWidthSubsampling not available on Y8 pixel type.");
if (plane == PLANAR_U || plane == PLANAR_V) {
if (IsYUY2())
return 1;
else if (IsPlanar())
return ((pixel_type>>CS_Shift_Sub_Width)+1) & 3;
else
throw AvisynthError("Filter error: GetPlaneWidthSubsampling called with unsupported pixel type.");
}
throw AvisynthError("Filter error: GetPlaneWidthSubsampling called with unsupported plane.");
}

...



GetPlaneHeightSubsampling does the same thing, but with CS_Shift_Sub_Height. Does the comment need to be updated, or am I misusing the two functions by using their return values unaltered?


Second, is there an established procedure for handling the case of someone loading a 2.5 interface plugin under 2.6, but then passing planar video in one of the new colorspaces to a plugin that depends on proper chroma subsampling information? I use said info to decide how to step through the pixels of a frame; Avisynth 2.6 flags all planar clips as YV12 when passing them to 2.5 plugins, but doesn't actually convert the data. My plugin therefore ends up assuming a YV12 memory layout, accessing the wrong luma and chroma samples, and spitting bad video out to subsequent filters.

I think it would only be polite to let the user know if this situation arises, but I couldn't find any immediately obvious solution. The best I've managed so far is a trio of try...catch blocks which Invoke a PointResize to 1x1, 2x1, and 4x1 in turn, throwing an error if any of them succeed. It's functional, though perhaps a bit unwieldy, and I wonder if there's another way for plugin authors to deal with this that I'm overlooking. "Don't worry about it, the user will notice something's wrong" is one of them, I suppose, but it seemed worth asking.

[IanB]

@Robert Martens,

The comments are about how the pixel type was composed, hints if you like, on how to write the GetPlaneHeightSubsampling and GetPlaneWidthSubsampling internals.

The formats currently defined are pretty much in concrete, but that does not stop it from being extended. So if you write your planar code for all 1, 2 & 4 subsampling it will be pretty future proof. So I guess it implies you should not generally use IsYV24, IsYV16, IsYV12 and IsYV411 so much these days. Of course if the algorithm explicitly need full size unsubsampled chroma there is nothing wrong with testing IsYV24. Likewise a filter explicitly for NTSC 411 DV should not be afraid to use IsYV411.

Yes 2.5 plugins can get their fingers burnt. We did consider inspecting the input to 2.5 filters but it was quite messy to do and it would limit what could be done with any 2.5 filters that did not care. So far it hasn't presented much of a problem. Our attitude that the user knows best appears to be serving us well.

If a filter is happy being a 2.5 filter there is nothing wrong with that and you should not expect it to need to work outside the api it was written for.

If a filter wants to know about extra planar subsampling then it really needs to be a 2.6 filter.

[Robert Martens]

Thank you for the details, that's very reassuring; I'd worried I was missing something.

The 2.6 build of the plugin in question is on its way to being as generic as possible, and I'll be reviewing the rest of the code presently to take that principle as far as I can, but I'd planned on continuing to offer a 2.5-compatible release for as long as reasonable. It might end up loaded in 2.6, and then accidentally passed one of the new colorspaces, and while I fully understand why you didn't add checks for that in the core, I figured that in my case a friendly error message would be better than bad data or an outright crash. I have a tendency to overthink, though, and they say "kill your darlings", so maybe it's best left on the cutting room floor.

[ryrynz]

Has there been any consideration to scrapping Avisynth 3.0 in favor of developing Vapoursynth to achieve the same sort of functionality? Perhaps 2.6 should be where it ends.

[Keiyakusha]

It is already years since Avisynth 3.0 is not developed by anyone with or without vapoursynth ^__^
2.6 is where it ended even before we saw vapoursynth.

[Chikuzen]

at first, there is a script like this.
ColorBars(322, 240, "YV12")
I compressed this script with UtVideo-ULY0 codec, and read the video with AVISource.
AVISource("colorbars_322x240_uly0.avi")
then, the result is
https://dl.dropbox.com/u/19797864/with_avisource.png
http://www.mediafire.com/view/?w8t91hbf4wi478x

but, if I read this avi with VirtualDub directly, the preview has no problem.
https://dl.dropbox.com/u/19797864/with_vdub.png
http://www.mediafire.com/view/?55cgx8a64988onc

seems AVISource has some problem with mod2 width YUV420 clip.

why this happen ?

[Sparktank]

seems AVISource has some problem with mod2 width YUV420 clip.

Interesting. Not that I use mod2, but interesting.
Google search shows others with the same issue. Doesn't seem to be any work around other than crop to mod16 before converting to AVI.

I've cropped 2 off the mod2 AVI script and the issue is still present with avisource.

FFMS2 and DSS don't seem to have any issues with the unmodified mod2 AVI script.

edit: (this forum needs a "like" function or a "reputation" system. very apt explanation from IanB, even if it's over my technical experience lol)

[IanB]

@Chikuzen,AVISource("colorbars_322x240_uly0.avi", pixel_type="RGB32")returns the same result as VDub (and also YUY2).

It seems UtVideo returns YV12 data as a packed layout (as it should), but with a dword aligned padded buffer size (technically legal, but unexpected). This trips the planar AVIPadScanlines input detection. Looks like I need an new option to override the automatic planar AVIPadScanlines detection.

AVISource and DirectShowSource both check for the case :-
input buffer size == (((Rowsize(Planar_Y)+3)& ~3)*Height+2*((Rowsize(Planar_U)+3)& ~3)*UVHeight)
to detect padded planar scan lines. i.e. buffer size was 117120 but I would normally expect it to be 115920.

Sigh! :(

[StainlessS]

Have been experiencing similar problems recently with UT Video, was beginning to suspect it. (EDIT: was major suspect).

[goldenhige]

YV12 Test
Env: WinXP SP3 32bit, AviSynth 2.6.0 Alpha3, AvsPmod 2.3.1, VirtualDub 1.9.11
Codecs: YV12(raw), UtVideoCodec(ULY0)12.0.0.0, x264vfw r2200bm, ffdshow rev4486(MJPEG,FFVH,FFV1), VP6vfw(VP62) 6.2.6.0, VP7vfw(VP70) 7.0.10.0, VP8vfw 1.2.0
test.avi: 854x480 (854 isn't mod4) ConvertToYV12()->Save to AVI->test.avi

Avisynth: AVISource("test.avi",pixel_type="YV12")
problem: ULY0,x264vfw,MJPEG,FFVH,FFV1,VP62,VP70
no problem: YV12, VP8(but need FlipVertical)


VirtualDub: Video->Color Depth->Decompression format = "4:2:0 planar YCbCr(YV12)"
problem: VP8
no problem: YV12,ULY0,x264vfw,MJPEG,FFVH,FFV1,VP62(but need FlipVertical),VP70

...VP8????

[IanB]

Sigh! :( the packed line detection code does not get applied to compressed formats, so AviSource() stumbles along with the default frame shape from env->NewVideoFrame(vi, -4); Looks like I got some more code to add.

[hajj_3]

you really should put "2011" in the title of this thread, may 25th is just confusing!

[StainlessS]

@Hajj_3, have already made that suggestion. EDIT: Like magic, now it is 2011

[george84]

Trying to use AudioTrim gives error message in VDub

...there is no such function

I double checked that I have 2.60

my code was

x = NicMPG123Source("The Beatles - One - 01 - Love Me Do.mp3").killvideo().eqaudio()

x = AudioTrim(x, 0, 168)

audiotrack = audiotrack + x

[Marsu42]

Confirmed, fixed in CVS

I'm reading a lot about fixes in cvs, any chance of someone compiling a more recent version than the 2011 one please?

[StainlessS]

I'm reading a lot about fixes in cvs, any chance of someone compiling a more recent version than the 2011 one please?

I'm guessing that Mr B would be the best person to do that, time and updates/fixes would make alpha 4 a good idea.

[StainlessS]

Is this a bug


colorbars()

GScript("""
if(defined(LACED)) {
convertToYUY2(interlaced=LACED) # BANG !
} else {
convertToYUY2()
}
""")
return Last


Does Defined() ONLY work properly inside a function ?

EDIT: Emptied out my plugins (bar GScript) just in case an auto loaded script had a LACED, it did not.

[Keiyakusha]

maybe it is time to release 2.6 final already? maybe it won't be as feature reach as we wanted it to be but there won't be sudden huge changes in the future anyway, isn't it? Also this will help to a lot of people who fail to understand that "alpha" doesn't necessarily means that it is broken and can make your computer explode. Because of this we for example have 2.5.8 ported to linux instead of 2.6...

[Gavino]

Is this a bug

colorbars()

GScript("""
if(defined(LACED)) {
convertToYUY2(interlaced=LACED) # BANG !
} else {
convertToYUY2()
}
""")
return Last

Using v2.60 (May 25 2011), it works fine for me, giving error 'I don't know what "LACED" means'.
Did you expect something else?
What exactly do you get?

[StainlessS]

giving error 'I don't know what "LACED" means'.

Same here, I was expecting it to work, ie defined() to say if exists in script or not.

So presumably there is no way to tell if it says 'everything' is defined ?

I wanted to use in this script so that if commented out (AUTOCROP_THRESH) it would call QueryBorderCrop() with
an undefined arg to Thresh (as internally it reacts different
if Thresh not supplied).
http://forum.doom9.org/showthread.php?p=1604080#post1604080

[Gavino]

Same here, I was expecting it to work, ie defined() to say if exists in script or not.

So presumably there is no way to tell if it says 'everything' is defined ?
It's not saying that LACED is defined - it's the Defined() function itself that is giving the error, because it cannot evaluate the nonexistent variable LACED.

Defined() checks the status of values, not variables as such. As the wiki (http://avisynth.org/mediawiki/Internal_functions/Boolean_functions) says, "More formally, the function returns false if its argument (normally a function argument or variable) has the void ('undefined') type, otherwise it returns true."

If you want to check whether a variable exists, put its use inside a try/catch.

[StainlessS]

If you want to check whether a variable exists, put its use inside a try/catch.

Lovely, now why didn't I think of that. :thanks:

EDIT: Perhaps a "Declared(String s)" function would be a good idea [or maybe "VarExist(String s) ]".

[StainlessS]

A non-imaginary bug this time.


RT_Debug(String(HexValue("FFFFFFFF")))
RT_Debug(String(HexValue("80000000")))
return colorbars()



Produce this:

RT_Debug: 2147483647
RT_Debug: 2147483647


From Source

AVSValue HexValue(AVSValue args, void*, IScriptEnvironment* env) { char *stopstring; return strtol(args[0].AsString(),&stopstring,16); }


suggest this:

AVSValue Create_HexValue(AVSValue args, void*, IScriptEnvironment* env) {
char *stopstring;
return (int)(strtoul(args[0].AsString(),&stopstring,16));
}


Gives:

RT_Debug: -1
RT_Debug: -2147483648


EDIT: Will soon up an RT_Stats update that will contain a fix (alternative) for this problem on v2.58 (presume its broken there too) and v2.6a3.

[IanB]

See AviSynth 2.6.0 Alpha4 [Jan 14th, 2013] (http://forum.doom9.org/showthread.php?p=1610746#post1610746)