AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]

[IanB]

Here is the 4th official release of Avisynth 2.6

Get AviSynth_130114.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%204%20%5B130114%5D/AviSynth_130114.exe/download) from SourceForge.

========================
Changelist

Additions
* Info: Audio only clip now creates its own canvas video.
* AviSource: Include packed/padded processing and -ve biHeight logic for compressed input.
* Add Script Functions :- Tau, BitLRotate, BitRRotate, BitChange, BitClear, BitSet, BitTest and their asm aliases.
* Add WeaveRows (blit cost) and WeaveColumns (slow) frame combining filters.
* Add AudioDuration() [as float seconds], IsY8(), IsYV411() & PixelType() [as a string] script functions.
* Add Echo and Preroll filters.
* Add IScriptEnvironment::GetAVSLinkage() and DLLExport AVS_linkage for host usage of avisynth.dll.
* DirectShowSource, 2.6 plugin, support pixel types "AYUV" as YV24, "Y41P" and "Y411" as YV411.
* AviSource: Add Full and Auto pseudo pixel_types. Full is all supported. Auto is YV12, YUY2, RGB32, RGB24 & Y8.
* Add "AudioLengthS" [as a string], "Ord" & "FillStr" script functions.
* Add AudioTrim(clip, float, float) audio priority trimming, args in fractional seconds.
* Add Trim(M, Length=N[, Pad=False]) and Trim(M, End=N[, Pad=False]) function overloads for explicit Trimming. Length=0 means zero frame clip. End=0 means end at frame 0.
* Add SeparateRows (zero cost) and SeparateColumns (slow) frame slashing filters.
* Add Script Functions :- Acos, Asin, Atan, Atan2, Cosh, Sinh, Tanh, Fmod, Log10, BitLShift, BitRShiftS, BitRShiftU and Hex.
* Add "ConditionalSelect","csc+[show]b" runtime filter.
* Add dither option to Levels, RGBAdjust & Tweak.
* Add BitAnd(), BitNot(), BitOr() & BitXor() script functions.
* Add StrCmp() & StrCmpI() script functions.
* Add YV24 support for Limiter show option.
* Add "Global OPT_dwChannelMask={int}"
* Add 0x0063F speaker mask for 7.1 WAVE_FORMAT_EXTENSIBLE.
* Add .dll DelayLoad exception texts to crash message formatter.
* ImageWriter, add support for printf formating of filename string, default is ("%06d.%s", n, ext);
* Add avs_get_error(AVS_ScriptEnvironment*); to avisynth_c interface.
* Catch and save AvisynthError text in more avisynth_c entry points, for kemuri-_9.
* Add ScriptName(), ScriptFile(), ScriptDir() functions (WarpEnterprises).
* Add SkewRows filter.
* Histogram, Levels mode, Improve colour of chroma legends.
* ConditionalFilter, teach about string results.
* Add some more "Add/Remove Software" registry keys to the Installer (XhmikosR).
* AviSource: Support both packed and DWORD padded raw planar input like with DSS.
* Add IScriptEnvironment::ApplyMessage()
* Add ImageSourceAnim (Wilbert)
* Support user upgrade to 178 DevIL.dll (They need to manage CRT dependancies).
* ImageSource: palette and compressed bmp images load correctly now (issue 894702) [need 178 DevIL.dll]
* ImageSource: support for other formats like: gif, exr, jp2, psd, hdr [need 178 DevIL.dll]
* Add YV24 mode to ColorBars.
* Add ColorBarsHD based on arib_std_b28.
* C-api usability enhancements from kemuri9 [Work in progress!]
* Add Undefined(), AudioLengthLo(), AudioLengthHi(), IsYV16() & IsYV24() script functions
* Allow newlines (and hence comments) before '{' -- Gavino
* Added IScriptEnvironment::DeleteScriptEnvironment()
* Added Histogram, population clamp % factor for "Levels" mode,
* Histogram, revert "Stereo" mode to YV12, Add "StereoY8" mode,
* AviSource: Support fourcc "GREY" as Y8
* Added support for argument passing and EAX return value to SoftwireHelper.
* Added "Global OPT_VDubPlanarHack=True" to flip YV24 and YV16 chroma planes for old VDub's.
* Added "Global OPT_AVIPadScanlines=True" option for DWORD aligned planar padding
* Added Matrix="AVERAGE" mode.
* Added ContinuedDenominator/ContinuedNumerator(f[]i[limit]i) script functions.
* Tweak: fix MaskPointResizing + put back Dividee ISSE code (use sse=true).
* Added ChromaInPlacement, ChromaOutPlacement and ChromaResample options to planar colour conversions.
* Added MaskHS.
* Source tweaks to get ready for VC8.
* Add Y8 for DevIL, planarize EBMP.
* Planar support for many filters.
* Added Info() time indicator on audio length and video (current frame & total). (2.5.8)
* Added UtoY8 and VtoY8.
* Added more info to Info(). (2.5.8)
* ColorYUV: Added all adjustment parameters as conditional variables "coloryuv_SETTING". Enable by setting conditional=true.
* ConditionalReader: Added support for type String.
* ConditionalReader: Added offset keyword to offset all frame numbers after the keyword.
* Added SincResize() with optional taps parameter (default is 4).
* Added Custom band setting to SuperEQ to allow all 16 bands to be set from script. Usage: SuperEQ(clip,band1, band2, band3....) values are dB in float.
* Added fast 0-1-0 kernel for YV24 to ConvertBacktoYUY2().
* Added core formats: YV24, YV16, Y8, YV411.


Bugfixes
* Fixed HexValue parsing values greater than 7FFFFFFF, now as unsigned hex.
* Fixed ConditionalReader memory overrun parsing bools.
* Fixed ResampleAudio NOP test to compare vi.num_audio_samples, not sample rate.
* Fixed YV24 -> RGB24 overrun cleanup for widths%16 == 5.
* Fixed RGB24 AddBorders with right=0.
* Fixed conditional_functions error message names (Wilbert).
* Fixed Audio cache ac_expected_next regression.
* Fixed ImageSource deal with add 1 to IL_NUM_IMAGES bug (Wilbert)
* Fixed Overlay YV24 V plane conversion.
* Fixed Overlay YV24 mode with shared input clip, needed a MakeWritable.
* Fixed ImageReader upside down TIFF in 178 DevIL. (Wilbert)
* Fixed string+string bug when total length is 4096*K-1.
* Fixed SincResize misuse of "int abs(int)" (Gavino). Fix Lanczos and Blackman sinc use of float == 0.0, use small limit "> 0.000001".
* Fixed Classic mode legend drawing for planar right limit and yuy2 centre line.
* Fixed possible MT race. Use "env->ManageCache(MC_IncVFBRefcount, ...)" in ProtectVFB.
* Fixed SwapYToUV output image size bug for 3 clip case.
* Fixed Crop limit tests for RGB.
* Fixed Overlay yellow tint on rec601 RGB import conversion.
* Fixed YtoUV() output image size bug for 3 clip case.
* Fixed ConvertToPlanar chroma alignment.
* Fixed Levels (RGB) change use of PixelClip(x) to min(max(x, 0), 255).
* Fixed SwapYtoUV yuy2 crash (StainlessS).
* Fixed Overlay saturate UV in add and subtract mode.
* Fixed Info.h range protect display characters (StainlessS).
* Fixed AviSource packed planar import chroma offsets.
* Fixed AviSource NULL GetWritePtr() failure due to premature setting of last_frame.
* Fixed Mask rounding in greyscale calcs (Wilbert), minor refactor.
* Fixed SelectRangeEvery audio snafu (Gavino).
* Fixed LoadPlugin, SaveString of result string.
* Fixed LoadPlugin, use _vsnprintf.
* Fixed LoadVirtualdubPlugin, don't add vdub filter to chain on load failure.
* Fixed rounding in RGB HResize (JoshyD) (affects all resizers)
* Fixed error message name in the filter VerticalReduceBy2
* Fixed SeparateFields() with variable parity input clip (Wilbert)
* Fixed AviSource, cannot cast__int64* to long*, it does not work!
* Fixed ConditionalReader: Don't allow out of range "Range" to overwrite edge values
* Fixed MonoToStereo with stereo sources.
* Fixed MergeChannels with only 1 input clip.
* Fixed AviSource support for negative height DIB format AVI's.
* Fixed Audio cache crashes.
* Fixed resize with YV411, missing code.
* Fixed ConditionalReader rounding with integer interpolation.
* Fixed Softwire SSE2 bugs.
* Fixed SSSE3 CPU detection.
* Fixed SSSE3, SSE4.1 & SSE4.2 detection.
* Fixed Fastwire encoding of instructions that are >2 opcodes (SSSE3+4).
* Fixed _RPT5() macro for debug builds


Optimizations
* ConvertToPlanarGeneric explicit add Cache before chroma rescaler.
* Overlay minor refactor YV12 -> 444 chroma
* Speedup ConvertToMono(), minor refactor MixAudio().
* Change StackVertical/Horizontal to interative instead of recursive, 2^N performace increase for 3 and more clips, i.e. 1 blit total instead of blit(blit(blit(...
* RGBtoY8 Dynamic ASM code, support for RGB24.
* YV24backtoYUY2 Dynamic ASM code.
* UtoY8, VtoY8 abuse subframe, zero cost.
* YV24<->RGB Add SSE2 and SSSE3 code paths, get rid of wide_enough.
* ConvertToYUY2 Add SSE2, MMX restore full speed on platforms with poor ooox.
* ConvertAudio, manage tempbuffer and floatbuffer independantly.
* ConvertAudio, prefer SSE2 over 3DNow for super AMD cores.
* Info.h, full refactor, a good example of "Never look down", thx StainlessS
* DoubleWeaveFrames, If A not writable, try to write to B, else make new frame
* Histogram, fix GetFrame/NewVideoFrame call order
* HResizer, interleave code +4% faster
* YtoUV() Abuse Subframe to snatch the Y plane / UV planes, Derestrict destination colorformat autogeneration.
* ImageSource: Improve thread interlock code
* ConditionalReader/WriteFile: Full refactor.
* Replace _strdup with SaveString in AddFunction (Thanks Gavino)
* SuperEQ: Improve channel unpacking/packing code.
* H-Resize: Use SSE4.1 (movntdqa) loads for use once memory access.
* H-Resize: Added SSE2 horizontal unpacker.
* Resize: Use SSE3 (lddqu) loads for unaligned memory access.
* Added ultra fast vertical PointResizer (64 pixel/cycle).
* Added dynamic SSSE3 vertical resizer (16 pixel/cycle) ~ twice as fast as old MMX.
* Added dynamic SSE2 vertical resizer (16 pixel/cycle).
* Added dynamic MMX vertical resizer (8 pixel/cycle).
* Added SSSE3 version for RGB<->YV24 conversions.
* Added dynamic compiled MMX/iSSE for RGB<->YV24 conversions. Speed is approx 200% of C-code.


Changes
* BlankClip: Supply useful defaults for new Audio/Video when using a Video/Audio only template clip.
* BlankClip: Use duration from Audio only template as default length for new clip.
* Define new IClip::SetCacheHints cachehint constants.
* Force int call arguments to user script function float params to be explicit floats.
* Splice pass CacheHints through to both children in + and ++ mode.
* WriteFileStart/End save current_frame and set Last.
* ConditionalReader do not ignore syntax errors in input file.
* ImageSourceAnim Pad/Crop images to match first frame (Wilbert)
* ImageSource Add version to messages (Wilbert)
* Initial 2.6 API entry point linkage.
* Use Invoke for graph tail, enhance non-clip output error reporting.
* PopContext when inner block Asserts/throws (maxxon).
* Remove duplicate definitions (Wilbert).
* Enhance non-clip output error reporting.
* Explicitly specify calling sequence as __cdecl for Avisynth softwire routines, (was the compiler default)
* Use env->Invoke("Cache", ...) everywhere instead of Cache::Create_Cache(), allows for Cache to be overloaded by a plugin.
* ConvertToYUY2 Change from 0-1-1 kernel to 1-2-1 kernel.
* Tweak make Interp same units as minSat and maxSat.
* Check HKEY_CURRENT_USER for PluginDir first. (henktiggelaar)
* Make forced, -ve, planar alignment of chroma planes match subsampling.
* Enforce planar alignment restrictions.
* C-api: Remove func sub-struct from AVS_Library struct
* Add error code to plugin load failure message
* Make default planar AVI output packed. Control with OPT_AVIPadScanlines=True.
* WriteFile() now supports unlimited number of unlimited strings. (was 16 by 254 byte strings).
* ConvertToRGB*, make C++ code sample chroma the same as the MMX code i.e. use both pixels.
* ConvertToRGB*, use YV24 path for planar, complain when options are present for YUY2.
* ConvertToYUY2, use YV16 path for planar, complain when options are present for RGB see: http://forum.doom9.org/showthread.php?p=1378381#post1378381
* Thread safe code, part 2.
* Correct IClip baked documentation
* Passify compilation error/warnings (XhmikosR)
* for, const, extern and ansi patches for VC2008 (SEt)
* Disable OPT_RELS_LOGGING option
* Change implicit Last parsing for argless, bracketless calls to match bracketed cases. (Gavino)
* DirectShowSource: Support last minute format renegotiation thru IPin::QueryAccept() & Validate the size of the provided directshow buffer.
* Remove non ascii chars from comments.
* Add core stubs for DirectShowSource, TCPServer & TCPSource, report when plugins are missing.
* Add note for original source downloads - SoundTouch
* Add more lineage history to Info()
* Move convertaudio, alignplanar, fillborder & MIN/MAX_INT definitions.
* Run AtExit before dismantling world.
* Change setcachehints definition from void to int. Test IClip version >= 5.
* Move PixelClip definition to avisynth.cpp
* SubTitle, etc, make X & Y options float (0.125 pixel granularity).
* ShowSMPTE() supports all integer FPS and multiplies of drop frame FPS.
* SubTitle, stop overwriting string constants (Gavino).
* SubTitle, improve pixel registration (Gavino).
* Make Info() CPU display hierarchical.
* Thread safe code, part 1.
* SoftwireHelper: explicit hardware exception handling.
* Resize: Moved GetResampleFunction into Resamplefuntion, to allow overrides.
* Resampler: Removed dead stlf code.
* Updated Soundtouch to 1.31 (2.5.8)
* Put dynamic matrix conversion into separate file.
* Moved chroma subsampling to image_type section.
* Added specific error reporting when requesting chromasubsampling with Y8.
* Split up merge and plane Swappers.
* Split up Plane transfers into separate classes.
* Added automatic destination colorspace detection on planar YtoUV.
* Took out greyscale and RGB32<->RGB24 from convert.cpp and placed them in separate files.
* All code assuming UVwidth = Ywidth/2 and similar should be gone.

[Chikuzen]

What is lacking in order for alpha to grow up to be beta?

[ARDA]

Dear IanB;
Many years without posting, but I've been following all
avisynth news, and congratulations for the great progress you have done.

I was still using v 2.58 and today I installed this new alpha
Everything was working ok, till I accidentally introduced in my script(copy&paste)
a ConvertToYV16(),using an 2.58 plugin to my suprise it was not stopped by
(except Y8 that was stopped,checked afterwards)

if (!vi.IsYV12())
env->ThrowError("only planar (YV12) input");
1) Is it suppossed to be that way ?

When working in place, with src writable, and returning source, it worked
correctly with YV16 and YV24(just checked those two).
2) Is that expected to be that way as well ?

When creating a new frame with
PVideoFrame dst = env->NewVideoFrame(vi,32);
env->MakeWritable(&dst);
and return dst, if I am not wrong , heights and rows obtained
with for instance int height = src->GetHeight(PLANAR_Y);
or int dstheight = dst->GetHeight(PLANAR_Y);
are half the value they should be.
3) Is that correct ?, or I am missing something ?

4) every plugin should be compiled again with new api ?

5) if so, is there anywhere a simple sample, as it used to be
with invert to see how to use new api ?

My apologies if this has been answered before, but I couldn't find.

Thanks for all the effort done during all these years.
Arda

[StainlessS]

Mr B, :thanks: much appreciated.


5) if so, is there anywhere a simple sample, as it used to be
with invert to see how to use new api ?

this is the nearest that I'm aware of:
http://forum.doom9.org/showthread.php?p=1580772#post1580772

[IanB]

I was still using v 2.58 and today I installed this new alpha
Everything was working ok, till I accidentally introduced in my script(copy&paste)
a ConvertToYV16(),using an 2.58 plugin to my surprise it was not stopped by
(except Y8 that was stopped,checked afterwards)

if (!vi.IsYV12())
env->ThrowError("only planar (YV12) input");
1) Is it supposed to be that way ?
Yes, all the planar formats are designed to look like YV12 to the 2.5 baked code. If we look at the 2.5 baked code, it masks most of the pixel type bits and compares what is left :-bool IsYV12() const { return ((pixel_type & CS_YV12) == CS_YV12)||((pixel_type & CS_I420) == CS_I420); }As Y8 is not a 3 plane format it does not have a CS_VPlaneFirst or CS_UPlaneFirst bit so the match fails.

There was much discussion originally about new planar formats and letting the 2.5 plugins YV12 code run. It was agreed that it was more useful to allow it. So as usual the user is in charge and must be aware.
When working in place, with src writeable, and returning source, it worked
correctly with YV16 and YV24(just checked those two).
2) Is that expected to be that way as well ?
Yes, the beginning of the VideoFrame structure is still the same, so the 2.5 baked code correctly loads the offsetU and offsetV members. However the 2.5 code does not know about the new row_sizeUV or heightUV members so will assume the chroma planes are the shape for YV12, so only half a YV16 or quarter of a YV24 may be processed. For code that only processes the luma plane there is no problem. So as usual the user is in charge.class VideoFrame {
volatile long refcount;
VideoFrameBuffer* const vfb;
const int offset, pitch, row_size, height, offsetU, offsetV, pitchUV
const int row_sizeUV, heightUV;
...
When creating a new frame with
PVideoFrame dst = env->NewVideoFrame(vi,32);
env->MakeWritable(&dst);
and return dst, if I am not wrong , heights and rows obtained
with for instance int height = src->GetHeight(PLANAR_Y);
or int dstheight = dst->GetHeight(PLANAR_Y);
are half the value they should be.
3) Is that correct ?, or I am missing something ?
No, the 2.5 baked code for PLANAR_Y the VideoFrame height member is correctly returned. For PLANAR_U and PLANAR_V height/2 is returned, which will be correct for YV12 but wrong otherwise.int GetHeight(int plane) const {
switch (plane) {
case PLANAR_U:
case PLANAR_V:
if (pitchUV)
return height>>1;
return 0;}
return height;
}As the code for env->NewVideoFrame(vi,32); was always within Avisynth.dll the structure returned to the 2.5 plugin is correct for the rest of the 2.6 world.
4) every plugin should be compiled again with new api ?
If they are complete with the 2.5 feature set then no. If they need something from the 2.6 feature set then yes. A correctly written planar format plugin that correctly uses GetPitch(plane), GetRowSize(plane), GetHeight(plane), etc should work correctly with all planar formats when recompiled, otherwise it may only work with YV12. Of course luma only code will work in both cases.
5) if so, is there anywhere a simple sample, as it used to be
with invert to see how to use new api ?
The thread StainlessS pointed to is the active discussion on the subject, but yes if someone would update the API doco and examples it would be appreciated by all.

[ARDA]

Thanks once more IanB;

No, the 2.5 baked code for PLANAR_Y the VideoFrame height member is correctly returned.
For PLANAR_U and PLANAR_V height/2 is returned, which will be correct for YV12 but wrong otherwise.

... otherwise it may only work with YV12. Of course luma only code will work in both cases.

I think I have understood; so those plugins that work in YV12 space and create a new frame
only will be able to work in new planar formats(except for lumas) if they are recompiled with new api.
As for example the one I was using Removegrain(mode=1) or Undot(); those that work in place
will continue working correctly recompiled or not.

I will follow the thread StainlessS (thanks) pointed and see what I can do.

Thanks for taking the time to answer. Arda

[cyberbeing]

DirectShowSource, 2.6 plugin, support pixel types "AYUV" as YV24

This behavior seems very broken. When a decoder outputs AYUV mediatype (packed 4:4:4 YUV + alpha) to DirectShowSource, Avisynth outputs pink video to madVR with a "YV24" (planar 4:4:4 YUV) mediatype. Why isn't the "YV24" pixel type being used here for DirectShowSource input, if Avisynth doesn't support the AYUV format internally?

[IanB]

@cyberbeing,

As far as I know Direct Show MEDIASUBTYPE_YV24 (http://www.google.com.au/search?q=MEDIASUBTYPE_YV24) does not exist except for lavfilters LAVPixFmtConverter.cpp.

Direct Show MEDIASUBTYPE_AYUV seems to be the only compatible 8 bit YUV 4:4:4 format commonly available. Avisynth's DirectShowSource unpacks the data into the Avisynth internal YV24 planar format, discarding the alpha channel, using this code written by Sh0dan many years ago:-for(int x=0; x<rowsize; x++) {
dstY[x] = srcP[(x*4)+1];
dstU[x] = srcP[(x*4)+2];
dstV[x] = srcP[(x*4)+3];
}I don't have any AYUV samples, so I have never tested this code path.

Pink YUV output usually means the U and/or V data values are 255. (similarly green is for U,V=0).

Conflicting information about byte order :-
1. http://www.fourcc.org/yuv.php
AYUV

This is a 4:4:4 YUV format with 8 bit samples for each component along with an 8 bit alpha blend value per pixel. Component ordering is A Y U V (as the name suggests).

2. http://msdn.microsoft.com/en-us/library/windows/desktop/dd206750%28v=vs.85%29.aspx
4:4:4 Formats, 32 Bits per Pixel
AYUV

A single 4:4:4 format is recommended, with the FOURCC code AYUV. This is a packed format, where each pixel is encoded as four consecutive bytes, arranged in the sequence shown in the following illustration.

Figure 2. AYUV memory layout
http://i.msdn.microsoft.com/dynimg/IC162364.gif
The bytes marked A contain values for alpha.


Looks like number 2 might be the answer.

Try this script to see if you get some half arse picture back :-DirectShowSource(...blah..., pixel_type="AYUV")
A=VtoY8()
Y=UtoY8()
U=ConvertToY8()
UVtoY(U, U, Y) # Use U as dummy V which is lost

[cyberbeing]

As far as I know Direct Show MEDIASUBTYPE_YV24 does not exist except for lavfilters LAVPixFmtConverter.cpp.
Considering LAV Video can output YV24, and madVR can accept YV24 (including Avisynth output), does it ultimately matter that it's not a Microsoft approved MEDIASUBTYPE?
I still believe that DirectShowSource accepting and preferring YV24 over AYUV would be a good idea, even if initial support is limited.

Try this script to see if you get some half arse picture back
UVtoY doesn't exist as a function. Did you mean YtoUV?

Using YtoUV(U, U, Y) with your sample script produces a green & purple image.

[IanB]

Yes YtoUV() is it, dyslexia to the rescue. :o

And green/purple is the 45/225 degrees hues one would expect for the U=V case. I will check in a fix for the AYUV unpacker byte order.


It seems lavfilter are declaring their own guid's and these appear to be the values they are using :-const GUID MEDIASUBTYPE_YV24 = {'42VY', 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71};
const GUID MEDIASUBTYPE_YV16 = {'61VY', 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71};
I'll add them to the DirectShowSource wish list when someone confirms I have the correct guid's.

[Blue_MiSfit]

Thank you, IanB!

[Mystery Keeper]

I'm getting "there is no function named..." error for all 2.58 plugins I've got. Examples work fine.

SOLVED: Had to modify registry key at HKEY_CURRENT_USER\Software\AviSynth.

[vcmohan]

What is lacking in order for alpha to grow up to be beta?

Chikuzen's question was unanswered. If I download the alpha exe file and run it will it overwrite on the existing avisynth dll? If so what all files I need to save prior to experimenting with 2.6 alpha4 ?

[THEAST]

Wow, just wow! When I saw this new version on VideoHelp, I couldn't believe my eyes, it has been so long! Really thanks for resuming to update Avisynth, IanB! :worship:

[IanB]

What is lacking in order for alpha to grow up to be beta?Time and testing.

If I download the alpha exe file and run it will it overwrite on the existing avisynth dll? If so what all files I need to save prior to experimenting with 2.6 alpha4 ?The standard Avisynth*.exe installers are designed to install their current Avisynth.dll and associated files over the top of any existing standard Avisynth version. To flip back just reinstall the previous version.

For the inveterate fiddlers I guess you need to save Avisynth.dll and DirectShowSource.dll (it is now a full bird 2.6 plugin), possible the docs as well.

[vcmohan]

Thanks. When I try compiling using the new avisynth.h I get errors wherever it has lines as #include &lt;windef.h&gt; and for all such calls
D:\---avisynth_2_6.h(54) : error C2006: #include expected a filename, found '&'
I am on windows XP 32 bit using MS VC 6

[Groucho2004]

Thanks. When I try compiling using the new avisynth.h I get errors wherever it has lines as #include &lt;windef.h&gt; and for all such calls
D:\---avisynth_2_6.h(54) : error C2006: #include expected a filename, found '&'
I am on windows XP 32 bit using MS VC 6

The HTML Troll invaded your file and substituted HTML entities when you weren't looking. :D

You were probably browsing the SVN/CVS tree and screwed up when saving the file or something to that effect.

[vcmohan]

Thanks. Silly of me

[vcmohan]

I am still getting compilation errors
In the avisynth.h for 2.6 which I googled for and got an official version and it does not have VSLinkage
in "IScriptEnvironment::GetAVSLinkage() and DLLExport AVS_linkage for host usage of avisynth.dll." which was mentioned at the begining of the thread. Where do I get the latest vfersion of Avisynth.h ?

[StainlessS]

vcmohan
http://forum.doom9.org/showthread.php?p=1385169#post1385169

EDIT: perhaps try this:
http://www.tortoisecvs.org/

using:

cvs -d :pserver:anonymous@avisynth2.cvs.sourceforge.net:/cvsroot/avisynth2 checkout -P avisynth

[ARDA]

avisynth.h(Revision 1.39) that is
in core directory in avisynth sources, Wed Oct 10 06:15:00 2012 UTC.
http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/avisynth.h?view=log

[vcmohan]

Thanks

[GrofLuigi]

Thank you very much for the new version!

About DevIL.dll: How do we get the new goodies with version 178 while "managing CRT dependencies"?

GL

[Groucho2004]

About DevIL.dll: How do we get the new goodies with version 178 while "managing CRT dependencies"?

GL
http://openil.sourceforge.net/download.php
Grab the non-Unicode version.

[Wilbert]

@GrofLuigi,

See the two lines above the examples section: http://avisynth.org/mediawiki/ImageReader

[vcmohan]

Are there functions like vi.IsPRGB(), vi.IsPRGB24(), vi.IsPRGB32() for planar rgb formats?
In case of Planar RGB what are the values one can get for PLANAR_A, PLANAR_R, PLANAR_G and PLANAR_B?
Will it be possible to get the ReadPtr or WritePtr for non planar RGB formats as pointer value + 0, 1, 2, and 3 for r,g,b and A? In such a case possibly code for plugins for RGB and all Planar formats can be( where geometry does not matter) simpler?
Is it possible to get number of planes so that Y8 or such can be also be handled with ease?

[Wilbert]

Are there functions like vi.IsPRGB(), vi.IsPRGB24(), vi.IsPRGB32() for planar rgb formats?
In case of Planar RGB what are the values one can get for PLANAR_A, PLANAR_R, PLANAR_G and PLANAR_B?
These are commented out and thus not available yet ...

[IanB]

@cyberbeing,

Try this replacement DirectShowSource_2601.zip (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%204%20%5B130114%5D/DirectShowSource_2601.zip/download).

Please confirm all AYUV, YV24 and YV16 now work as expected.

[mandarinka]

I'll just spam a bit with a sort of useless feedback :)
I installed Alpha4 (32bit) on Win8 64 instead of the previously used 2.5.8. Everything seems to work fine when processing/encoding, using my usual scripts and filterchains. Also including Yatta. Yay!

[Farfie]

Hello. I believe I have found a bug regarding the newest Avisynth with open-gop. I've tried opening many different files in megui and virtual dub, regardless of encoder used, 10bit or 8bit, or any other setting I can find. Files with open-gop make things hang, error, or just crash.
One thing I noticed is that with a shorter duration clip (with open-gop), it might work at first, or for awhile, but eventually hang/error. Perhaps longer duration = more recovery points = more problems?

On a brighter note, this version seems to have fixed this problem with NLMeansCL that I could not find another soul to reproduce for me. Though, I'll need to test more to be 100% sure.
Regardless, thanks for the new version!

[StainlessS]

@Farfie,

You might like to say which source filter you are talking about, perhaps DirectShowSource?

[Farfie]

Ah, my bad. It occurs with FFVideoSource.

[IanB]

FFVideoSource is not part of the core, it is an independent plugin. Report problems in the FFmpegSource (http://forum.doom9.org/showthread.php?t=127037&page=42) thread. You will need to report the version and the build information for that version (who built it).

[cyberbeing]

@cyberbeing,

Try this replacement DirectShowSource_2601.zip (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%204%20%5B130114%5D/DirectShowSource_2601.zip/download).

Please confirm all AYUV, YV24 and YV16 now work as expected.
When using pixel_type="AYUV" I'm seeing "DirectShowSource: RenderFile, the filter graph manager won't talk to me" error under the following circumstances:

Win7DSFilterTweaker
Preferred Decoders = Use Merit
+
Haali Splitter
Auto-load VSFilter = Yes
+
LAV Video
All color formats checked
+
xy-VSFilter
default settings
+
madVR
+
Open a 10bit H.264 MKV with subtitles


Various changes which make it work without error for reasons unknown:

Uncheck P010 in LAV Video
or
Uncheck P016 in LAV Video
or
Uncheck RGB24 & RGB32 in LAV Video
or
Uncheck NV12 in LAV Video
or
Uncheck all RGB formats in xy-VSFilter
or
Uncheck "Follow Preferred Order of Upstream Filter" in xy-VSFilter

[IanB]

@cyberbeing,Please confirm all AYUV, YV24 and YV16 now work as expected.You had a specific example where the AYUV byte ordering was wrong, is this now correct?

You asked for YV16 and YV24 support, as this was fairly trivial, I have provided it. Is the byte order correct for these? Are the GUID's I used acceptable?
"DirectShowSource: RenderFile, the filter graph manager won't talk to me" errorIs the error displayed when the DirectShowSource pseudo renderer input pin remains unconnected after IGraphBuilder::RenderFile call has completed.

If you specify pixel_type="AYUV" then only connect attempts with MEDIATYPE_Video, MEDIASUBTYPE_AYUV will be accepted. I guess any of the changes you note cause MEDIASUBTYPE_AYUV to be one of the video subtype to be attempted.

madVR is a renderer and should not effect DirectShowSource graphs (it provides it's own renderer to snaffle the video frames).

[cyberbeing]

@cyberbeing,You had a specific example where the AYUV byte ordering was wrong, is this now correct?
Yes.

You asked for YV16 and YV24 support, as this was fairly trivial, I have provided it. Is the byte order correct for these? Are the GUID's I used acceptable?
YV24 seems to be correct, but you would need confirm the YV16 mediatype with madshi, since I have no way to test it myself.


Is the error displayed when the DirectShowSource pseudo renderer input pin remains unconnected after IGraphBuilder::RenderFile call has completed.
How would I test this?


If you specify pixel_type="AYUV" then only connect attempts with MEDIATYPE_Video, MEDIASUBTYPE_AYUV will be accepted. I guess any of the changes you note cause MEDIASUBTYPE_AYUV to be one of the video subtype to be attempted.
When pixel_type is specified, does DirectShowSource behave any differently when a filter attempts to connect with an unsupported mediatype, compared to attempts to connect with a supported mediatype which isn't the pixel_type specified? xy-VSFilter always connects twice. Once to determine the mediatypes supported by the video decoder & render, and then reconnects using the preferred mediatype of the decoder which is supported by the renderer.

A) The renderer pin which xy-VSFilter connects to via DirectShowSource is listing mediatypes other than the pixel_type specified
OR
B) The DirectShowSource renderer is rejecting xy-VSFilter's second connection, when the first connection is a mediatype unsupported by Avisynth.
OR
C) Some sort of bug in LAV Filters or xy-VSFilter mediatype negotiations.

Not overly important, but if you don't see anything wrong about DirectShowSource behavior in this case, I'll have the xy-VSFilter dev look into it at some point.

[Mystery Keeper]

YV24 does not seem correct. I get some frames alright and others with 3/4 of chroma broken.

[cyberbeing]

Is there a particular method needed to reproduce that?

Using LAV Video 0.55.2 I haven't noticed any issues with DirectShowSource 2.6.0.1 YV24 input, with output to madVR 0.85.8 or AvsPMod 2.4.1

[Mystery Keeper]

Not really. Just use some filters on it. Got that glitch with both my TempLinearApproximate and dfttest.

[cyberbeing]

Ah, I was testing it without filters with DirectShowSource only in the script.

[ARDA]

@Mistery Keeper

You have almost all your answers in this same thread

http://forum.doom9.org/showthread.php?p=1610888#post1610888


I think you're using the wrong avisynth.h to compile for new planar colorspaces
look this post

http://forum.doom9.org/showthread.php?p=1611790#post1611790


and as an example how to link your plugin with the new api
look at end of page of directshowsource.cpp

http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/plugins/DirectShowSource/
directshow_source.cpp?revision=1.38&view=markup

[IanB]

@Mystery Keeper, To 2.5 plugins all planar formats look like YV12. If you use 2.6 colour spaces with 2.5 filters you have to manage the conflict. TempLinearApproximate and dfttest are both 2.5 filters.


@cyberbeing,You asked for YV16 and YV24 support, as this was fairly trivial, I have provided it. Is the byte order correct for these? Are the GUID's I used acceptable?YV24 seems to be correct, but you would need confirm the YV16 mediatype with madshi, since I have no way to test it myself.One would assume you specify pixel_type="YV16" and see if LAV Video can output YV16 as it appears to do for YV24, and/or leave YV16 as the only checked LAV Video format.
Is the error displayed when the DirectShowSource pseudo renderer input pin remains unconnected after IGraphBuilder::RenderFile call has completed.How would I test this?In GraphEdit or GraphStudio, drop a renderer onto the canvas, the Null Renderer is okay but another may be more suitable. Then choose File>Render Media File with your file as the source. See what gets connected. Interrogate the input pin to the original renderer. Delete the connection to the Renderer input pin, interrogate the now disconnected upstream output pin to see what formats it offers. It needs to match a type DirectShowSource can process.

Also take a DirectShowSource log file, with LogMask=1+16+32, Format Negotiation+Requests to Directshow+Errors, to see what happened during the IPin negotiation.
If you specify pixel_type="AYUV" then only connect attempts with MEDIATYPE_Video, MEDIASUBTYPE_AYUV will be accepted. I guess any of the changes you note cause MEDIASUBTYPE_AYUV to be one of the video subtype to be attempted.
When pixel_type is specified, does DirectShowSource behave any differently when a filter attempts to connect with an unsupported mediatype, compared to attempts to connect with a supported mediatype which isn't the pixel_type specified?
Specifying the pixel_type argument to DirectShowSource() enables the DirectShow interface, IPin::EnumMediaTypes, processing. By default DirectShowSource() returns E_NOTIMPL for this method. Also the IPin::Connect will only accept the specified media type. The special pseudo types YUV, RGB, AUTO and FULL both enumerate multiple types and accept any of those types. See this thread :- Problems with DirectShowSource (http://forum.doom9.org/showthread.php?t=143321)

[Mystery Keeper]

Will 2.6 plugin work with AviSynth 2.5, or should I make different versions?

[cyberbeing]

@cyberbeing,One would assume you specify pixel_type="YV16" and see if LAV Video can output YV16 as it appears to do for YV24, and/or leave YV16 as the only checked LAV Video format.
I see why I couldn't get it to work.

In order for LAV Video to use YV16 with DirectShowSource, you need to set all output formats in the following registry key to 0 except YV16 which needs to be set to 1:
HKEY_CURRENT_USER\Software\LAV\Video\Output

LAV Video -> DirectShowSource -> madVR seems to display YV16 normally.

It seems impossible to make LAV Video connect directly to madVR with YV16 during normal DirectShow playback outside of Avisynth.

Also take a DirectShowSource log file, with LogMask=1+16+32, Format Negotiation+Requests to Directshow+Errors, to see what happened during the IPin negotiation.
Here are some logs of the LAV Video + xy-VSFilter + 10-bit 4:2:0 Video + pixel_type="AYUV" mediatype negotiation problem:

http://www.mediafire.com/?s38n5b4asbobcsi

[Mystery Keeper]

Fixed my plugin. Both YV16 and YV24 seem fine.

[IanB]

In order for LAV Video to use YV16 with DirectShowSource, you need to set all output formats in the following registry key to 0 except YV16 which needs to be set to 1:
HKEY_CURRENT_USER\Software\LAV\Video\Output

LAV Video -> DirectShowSource -> madVR seems to display YV16 normally.Interesting that madVR accepts YV16.
It seems impossible to make LAV Video connect directly to madVR with YV16 during normal DirectShow playback outside of Avisynth.Not that surprising, seeing YV16 is not a known Direct Show media subtype. You could possible force it in GraphStudio, but I would not expect the default graph builder to have a bar of this.
Here are some logs of the LAV Video + xy-VSFilter + 10-bit 4:2:0 Video + pixel_type="AYUV" mediatype negotiation problem:GraphStudio_(Can't_Render_Media_File)_LAV_AYUV_Only_Enabled.log
AVC1, AYUV Okay!

GraphStudio_(Can't_Render_Media_File)_LAV_P016_Disabled.log
AVC1, P010, NV12, YV12, YUY2, RGB32, RGB32, RGB24, RGB24, RGB565, ARGB32, RGB565, ARGB32, AYUV Okay!

GraphStudio_(Color_Space_Converter_Disabled_Can't_Render_Media_File)_LAV_All_Formats_Error.log
GraphStudio_(Connects_Color_Space_Converter)_LAV_All_Formats_Error_RGB32_Output.log
MPC-HC_madVR_LAV_All_Formats_Error_RGB32_Output.log
AVC1, P010, P016, NV12, YV12, YUY2, RGB32, RGB32, RGB24, RGB565, RGB24, ARGB32, RGB565, ARGB32, IYUV, I420, RGB565, MEDIATYPE_Audio, .... Fail!

MPC-HC_madVR_LAV_AYUV_Only_Enabled_AYUV_Output.log
AVC1, AYUV Okay!

MPC-HC_madVR_LAV_P016_Disabled_AYUV_Output.log
AVC1, P010, NV12, YV12, YUY2, RGB32, RGB32, RGB24, RGB24, RGB565, ARGB32, RGB565, ARG32, AYUV Okay!

Looks like the graph builder has a limit of 16 attempts.

I would guess the format negotiation is going somewhat like this ...AVC1 -- try raw x264 video stream

Add an AVC1 decoder
P010, P016, NV12, YV12, YUY2, RGB32 -- X264 codec bids these formats

Add a P010 format converter
RGB32, RGB24, RGB565 -- Try these

Add a P016 format converter
RGB24, ARGB32, RGB565 -- Try these

Add a NV12 format converter
ARGB32 -- Try this

Add a YV12 format converter
IYUV, I420 -- Try these

Add a YUY2 format converter
RGB565 -- Try these, oops that 16When you disable P016 you also avoid the P016 format convert attempts, freeing up more slots for other format converters.

Given your AVC1 decode bids P010 before P016 and they are the same data layout except for the bottom 6 bits being masked and the input data is only 10 bits anyway. I would leave P016 turned off until you have a real need. As P010 is bid first you probably need to turn off P010 to force P016 to get priority.

[mirkosp]

I'm not sure if this is the intended behaviour, but I think "multiply" mode has a small bug, since to my understanding it is supposed to be the perfect opposite of the "subtract" mode in behaviour (no change with white, maximum change with black).
Basically, from what I understand, a pure white clip (255, working with pc_range=true for this specific need) is supposed to keep the clip pixel identical, however, checking with subtract(c,last) (in which last is the overlay result, c is the source), I noticed that it actually... I think darkens by 1, as checking the YPlaneMin and YPlaneMax gives 127 for both instead of 126. If I do mt_invert on the overlay clip (and thus getting a 0 pure black clip instead of the 255 pure white) and use the mode "subtract", I do get the intended result, and the same subtract gives 126 on both min and max value.

[IanB]

@mirkosp,

I assume you are talking about the multiply mode of Overlay().

With no mask clip and default Opacity the code implements this for the Luma channel, a scaled multiply :-baseY[x] = (baseY[x] * ovY[x]) >> 8;
For a Base pixel=255 and an Overlay pixel=255 you get 255*255=65025, and 65025>>8=254.004, so yes you get a unit reduction in value.

For the Chroma channels :-baseU[x] = (baseU[x] * ovY[x] + 128 * (256-ovY[x]) ) >> 8;

Which is more clearly expressed as

baseU[x] = ((baseU[x] - 128) * ovY[x] + 128 * 256) / 256

For Subtract mode the code implements this, a simple subtraction :-Y = baseY[x] - ovY[x];
U = baseU[x] - ovU[x] + 128;

[mirkosp]

Yes, that's what I was referring to. Of course I'm aware that subtract and multiply aren't exactly the opposite, I just meant that with a value of 0 and 255 the opposite situation should arise, as in subtract keeps the same pixel with a 0 overlay and gives black for sure with a 255 overlay, whereas multiply gives black with a 0 overlay and is supposed to keep the input value with 255.
That said, I assume the current approach is for speed purposes... in the meantime I just decided to manually do a multiply with masktools since the very slight speed drop isn't so much of a concern to me as accuracy is, though I'm not sure if at this point the behaviour of overlay's multiply should stay unchanged or not.

[IanB]

Notes about AVISYNTH_INTERFACE_VERSION usage.

Some early adopter 2.6 filter authors seem a little confused. The AVISYNTH_INTERFACE_VERSION is about describing the level of features available, both in the core avisynth.dll and the third party plugin.

For a plugin author it describes what the core IScriptEnvironment vtable contains.

Version 1 is Avisynth 2.0

Version 2 is Avisynth 2.5, with the vtable having members up to IScriptEnvironment::SetWorkingDir(const char * newdir)

Version 3 introduced with Avisynth 2.5.6, with the IScriptEnvironment vtable adding 3 new members ManageCache, PlanarChromaAlignment and SubframePlanar.

Version 4 is reserved and does not apply to any Avisynth version. It's only significance is it greater then 3 and less then 5.

Version 5 introduced with Avisynth 2.6.0, with the IScriptEnvironment vtable adding 3 more new members DeleteScriptEnvironment, ApplyMessage and GetAVSLinkage. Also with version 5 the core provides AVS_Linkage support for baked code replacement.


And through the IClip interface it is the authors responsibility to declare the level of support the plugin provides.virtual int __stdcall IClip()::GetVersion() { return AVISYNTH_INTERFACE_VERSION; }Version 1 is Avisynth 2.0

Version 2 and 3 are Avisynth 2.5, supporting YV12, YUY2, RGB32 and RGB24 colour spaces.

Version 4 is reserved and does not apply to any Avisynth version. It's significance is it greater then 3 and less then 5.

Version 5 is Avisynth 2.6, and the IClip interface must support this updatevirtual int __stdcall IClip::SetCacheHints(int cachehints,int frame_range);Plugins that do not implement the interface must always return zero.

The plugin should also gracefully handle the new colour spaces, YV24, YV16, YV411 and Y8.