AviSynth 2.6.0 Alpha5 [Sep 18th, 2013]

[IanB]

Here is the 5th official release of Avisynth 2.6

Get AviSynth_130918.exe (5MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%205%20%5B130918%5D/AviSynth_130918.exe/download) from SourceForge.

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

Additions
* Added Eval(clip, string name, string) alias for oop processing of argument.
* DirectShowSource support non-standard pixel types "YV24" and "YV16".
* 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 :- 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 frame range clamping in ComparePlane (ultim).
* Fixed posible leak with realloc in ConditionalReader (ultim).
* Fixed posible double free in text-overlay (ultim).
* Fixed RGB32 to Y8 pixel right shift from 4th pixel on (Robert Martens).
* Fixed Overlay YV24 Image444 leak.
* Fixed AVISource "AUTO" and "FULL" handling.
* Fixed ImageSource handling of missing ebmp files.
* Fixed DirectShowSource incorrect byte order for unpacking of pixel type "AYUV"
* 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
* Cache auto increase span on sparse misses.
* Cache prevent inactive instances returning VFB early and spoiling active instances hit rate (LaTo).
* 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
* Keep parity across Bob.
* Import: Increase full path buffer to MAX_PATH*4 for multi char code pages like CP932 (Chikuzen).
* Throw error when output number of frames will exceed MAXINT.
* 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.

[IanB]

For info, here are the changes from A4 to A5, based on comparing the two change lists.

Additions
* Added Eval(clip, string name, string) alias for oop processing of argument.
* DirectShowSource support non-standard pixel types "YV24" and "YV16".

Bugfixes
* Fixed frame range clamping in ComparePlane (ultim).
* Fixed posible leak with realloc in ConditionalReader (ultim).
* Fixed posible double free in text-overlay (ultim).
* Fixed RGB32 to Y8 pixel right shift from 4th pixel on (Robert Martens).
* Fixed Overlay YV24 Image444 leak.
* Fixed AVISource "AUTO" and "FULL" handling.
* Fixed ImageSource handling of missing ebmp files.
* Fixed DirectShowSource incorrect byte order for unpacking of pixel type "AYUV"

Optimizations
* Cache auto increase span on sparse misses.
* Cache prevent inactive instances returning VFB early and spoiling active instances hit rate (LaTo).

Changes
* Keep parity across Bob
* Import: Increase full path buffer to MAX_PATH*4 for multi char code pages like CP932 (Chikuzen).
* Throw error when output number of frames will exceed MAXINT.

[IanB]

Reserved 2

[Groucho2004]

Hi Ian,

I have a couple of observations about the new code:
In ImageSeq.cpp, ImageReader::BlankFrame, how did you get the following code to compile (UVPitch not being declared)?
const int UVpitch = frame->GetPitch(PLANAR_U);
if (UVpitch) {
const int UVsize = UVPitch * frame->GetHeight(PLANAR_U);


I also get errors from the Intel compiler in "ImageWriter::GetFrame":
env->MakeWritable(frame);
env->ApplyMessage(frame, vi, ss.str().c_str(), vi.width/4, TEXT_COLOR, 0, 0);

no suitable conversion function from "PVideoFrame" to "PVideoFrame *" exists
env->MakeWritable(frame);
Previously, "frame" had the address-of operator -> "&frame".

[ultim]

Thank you for the new release!

[IanB]

@Groucho2004,

Sorry, got some hw problems, I'll update the SF CVS as soon as it's fixed.

Yes "frame" -> "&frame" and "UVPitch" -> "UVpitch".

[Groucho2004]

I'll update the SF CVS as soon as it's fixed.

Yes "frame" -> "&frame" and "UVPitch" -> "UVpitch".
Thanks.

[StainlessS]

Thank you Mr IB, we all love you. :) (EDIT: big cuddles)

[Groucho2004]

I'll update the SF CVS as soon as it's fixed.
While you're at it and if it's not too much trouble - please get rid of the UPX compression stuff. I think most people now have enough space for a 1.7 MB DLL. :)

[Sparktank]

:D My goodness! Excellent work!

Can't wait to play with it.

I admit, while reading most of the changelist I had to go to bed I got so tired last night.
I'll admit, even moreso, that a lot of the stuff is beyond my complete comprehension. :p

Thanks again! :unavailableemoteofexcitement:

EDIT: oh man, re-reading that: it was not intended to sound BORING, LOL!
I should really wait until I've had my second cup of coffee before posting without proofreading.

[ryrynz]

Nice, can't be far off a beta version now, waiting on SEt to do his thing with the MT version :)

[turbojet]

2.60 is being tested like a stable release and generally thought to be more stable then 2.58. It's a shame some wait years for the next stable build to upgrade. After 4+ years of alpha status is there any chance the next release being labeled 'stable'?

[Groucho2004]

I admit, while reading most of the changelist I had to go to bed I got so tired last night.
I'll admit, even moreso, that a lot of the stuff is beyond my complete comprehension. :p

Thanks again! :unavailableemoteofexcitement:
[/SIZE]
Settle down Beavis. :)

The change log you're looking at is the log with all changes since the release of 2.58. The changes from A4 to A5 are a tiny fraction of that.

[Groucho2004]

After 4+ years of alpha status is there any chance the next release being labeled 'stable'?
See here (http://forum.doom9.org/showthread.php?p=1629125#post1629125).

[IanB]

Okay, new PS fitted, server back, CVS updated.

[Groucho2004]

Okay, new PS fitted, server back, CVS updated.
Thanks. I noticed that A5 uses a lot less memory than previous versions, possibly due to that cache bug you fixed - very nice. One more reason to not use 2.5.8.

[Gavino]

The change log you're looking at is the log with all changes since the release of 2.58. The changes from A4 to A5 are a tiny fraction of that.
For info, here are the changes from A4 to A5, based on comparing the two changelists.

Additions
* Added Eval(clip, string name, string) alias for oop processing of argument.
* DirectShowSource support non-standard pixel types "YV24" and "YV16".

Bugfixes
* Fixed frame range clamping in ComparePlane (ultim).
* Fixed posible leak with realloc in ConditionalReader (ultim).
* Fixed posible double free in text-overlay (ultim).
* Fixed RGB32 to Y8 pixel right shift from 4th pixel on (Robert Martens).
* Fixed Overlay YV24 Image444 leak.
* Fixed AVISource "AUTO" and "FULL" handling.
* Fixed ImageSource handling of missing ebmp files.
* Fixed DirectShowSource incorrect byte order for unpacking of pixel type "AYUV"

Optimizations
* Cache auto increase span on sparse misses.
* Cache prevent inactive instances returning VFB early and spoiling active instances hit rate (LaTo).

Changes
* Import: Increase full path buffer to MAX_PATH*4 for multi char code pages like CP932 (Chikuzen).
* Throw error when output number of frames will exceed MAXINT.

[unreal666]

...
Changes
* Keep parity across Bob
...

it's not in CVS doc (changelist26.htm).

[ultim]

Hello IanB,

The enumeration values for GetCPUFlags() are being shared by both Avisynth and VirtualDub plugin support in Avisynth. VDub plugins loaded in Avisynth will get a function pointer to Avisynth's GetCPUFlags(), and thus it is important that Avisynth uses the same enumeration values for instruction sets as VirtualDub does. This has been ensured historically, but in latest Avisynth the flags of Avs and VDub have diverged.

Avisynth defines CPUF_SSE4_2 as 0x800, but in recent (to-be-released 1.10 series) versions of VirtualDub, the value 0x800 is used for AVX, not for SSE4.2 (a value for SSE4.2 is missing from VDub). As a result, if a VDub plugin that would use AVX gets loaded into Avisynth, Avisynth could report the instruction set as available on SSE4.2-capable CPUs even when they do not support AVX. The plugin would then try to execute illegal instructions and crash.

Could we sync to VirtualDub's values? Assuming VDub keeps adding new flags from LSB to MSB order, we could still define a flag for SSE4.2 without collision if we use an MSB bit. My suggestion:

enum {
CPUF_FORCE = 0x01, // N/A
CPUF_FPU = 0x02, // 386/486DX
CPUF_MMX = 0x04, // P55C, K6, PII
CPUF_INTEGER_SSE = 0x08, // PIII, Athlon
CPUF_SSE = 0x10, // PIII, Athlon XP/MP
CPUF_SSE2 = 0x20, // PIV, K8
CPUF_3DNOW = 0x40, // K6-2
CPUF_3DNOW_EXT = 0x80, // Athlon
CPUF_X86_64 = 0xA0, // Hammer (note: equiv. to 3DNow + SSE2, which
// only Hammer will have anyway)
CPUF_SSE3 = 0x100, // PIV+, K8 Venice
CPUF_SSSE3 = 0x200, // Core 2
CPUF_SSE4 = 0x400, // Penryn, Wolfdale, Yorkfield
CPUF_SSE4_1 = 0x400,
CPUF_AVX = 0x800,
CPUF_SSE4_2 = (1u<<31) // Avisynth-only
};

EDIT: Actually, the instructions in SSE4.2 seem to be irrelevant for image processing, so it is questionable if it needs to be included in the enumeration at all.

[TurboPascal7]

I'd like to hear your opinion on the question above too, IanB.

Also, two bugs in the core filters:
1. ConvertYV16ToYUY2 (https://github.com/jeeb/avisynth/blob/master/src/convert/convert_planar.cpp#L817) - return dst; line is missing. Each frame ends up being processed by both mmx and C versions making the filter slower than it should be.
2. AFH_YV12_C (https://github.com/jeeb/avisynth/blob/master/src/filters/focus.cpp#L751) - leftmost pixel is not processed. x should start with 0 just like it does everywhere else.

[IanB]

@Ultim,

Spoke to Avery :-
This makes sense. I'll add SSE42 = 0x1000. (http://forums.virtualdub.org/index.php?act=ST&f=11&t=21832&#entry94370)I'll reserve AVX=0x800 and adjust SSE4.2=0x1000, thanks.

@TurboPascal7,

Thanks for the 2 bug reports.

[TurboPascal7]

And we'll get AVX=0x800, SSE4.2=0x1000 and AVX2=0x2000. Not really important but still silly.
In fact, does avs even need to have SSE4.2 defined? It's basically useless for video filtering.

[Richard1485]

I can't find a generic thread for requests for updates to Avisynth, so I'll post this here if I may. Avisynth crossfades are simple linear dissolves. Is it possible to change this so that more complicated crossfades, such as those found in NLEs, are possible? I have a thread here (http://forum.videohelp.com/threads/355061-Avisynth-Crossfades) that goes into more detail.

I note that there have been recent, audio-related changes to the Trim() function, so I hope that the developers will consider implementing other audio-related changes, such as a non-linear crossfade. Thanks.

[qyot27]

A couple of related requests:

First,
Can avisynth_c.h be synchronized with the semi-updated version that x264 ships with in extras/? The modifications were authored by kemuri-_9 but the colorspace-specific ones haven't been integrated with the rest of the updates to avisynth_c.h mentioned in the Changelog. For convenience, I converted the changes into a patch:
diff --git a/src/core/avisynth_c.h b/src/core/avisynth_c.h
index e419d03..9b6325b 100644
--- a/src/core/avisynth_c.h
+++ b/src/core/avisynth_c.h
@@ -75,7 +75,7 @@ typedef __int64 INT64;
//

#ifndef __AVISYNTH_H__
-enum { AVISYNTH_INTERFACE_VERSION = 3 };
+enum { AVISYNTH_INTERFACE_VERSION = 5 };
#endif

enum {AVS_SAMPLE_INT8 = 1<<0,
@@ -90,13 +90,46 @@ enum {AVS_PLANAR_Y=1<<0,
AVS_PLANAR_ALIGNED=1<<3,
AVS_PLANAR_Y_ALIGNED=AVS_PLANAR_Y|AVS_PLANAR_ALIGNED,
AVS_PLANAR_U_ALIGNED=AVS_PLANAR_U|AVS_PLANAR_ALIGNED,
- AVS_PLANAR_V_ALIGNED=AVS_PLANAR_V|AVS_PLANAR_ALIGNED};
+ AVS_PLANAR_V_ALIGNED=AVS_PLANAR_V|AVS_PLANAR_ALIGNED,
+ AVS_PLANAR_A=1<<4,
+ AVS_PLANAR_R=1<<5,
+ AVS_PLANAR_G=1<<6,
+ AVS_PLANAR_B=1<<7,
+ AVS_PLANAR_A_ALIGNED=AVS_PLANAR_A|AVS_PLANAR_ALIGNED,
+ AVS_PLANAR_R_ALIGNED=AVS_PLANAR_R|AVS_PLANAR_ALIGNED,
+ AVS_PLANAR_G_ALIGNED=AVS_PLANAR_G|AVS_PLANAR_ALIGNED,
+ AVS_PLANAR_B_ALIGNED=AVS_PLANAR_B|AVS_PLANAR_ALIGNED};

// Colorspace properties.
-enum {AVS_CS_BGR = 1<<28,
+enum {AVS_CS_BGR = 1<<28,
AVS_CS_YUV = 1<<29,
AVS_CS_INTERLEAVED = 1<<30,
- AVS_CS_PLANAR = 1<<31};
+ AVS_CS_PLANAR = 1<<31,
+
+ AVS_CS_SHIFT_SUB_WIDTH = 0,
+ AVS_CS_SHIFT_SUB_HEIGHT = 1 << 3,
+ AVS_CS_SHIFT_SAMPLE_BITS = 1 << 4,
+
+ AVS_CS_SUB_WIDTH_MASK = 7 << AVS_CS_SHIFT_SUB_WIDTH,
+ AVS_CS_SUB_WIDTH_1 = 3 << AVS_CS_SHIFT_SUB_WIDTH, // YV24
+ AVS_CS_SUB_WIDTH_2 = 0 << AVS_CS_SHIFT_SUB_WIDTH, // YV12, I420, YV16
+ AVS_CS_SUB_WIDTH_4 = 1 << AVS_CS_SHIFT_SUB_WIDTH, // YUV9, YV411
+
+ AVS_CS_VPLANEFIRST = 1 << 3, // YV12, YV16, YV24, YV411, YUV9
+ AVS_CS_UPLANEFIRST = 1 << 4, // I420
+
+ AVS_CS_SUB_HEIGHT_MASK = 7 << AVS_CS_SHIFT_SUB_HEIGHT,
+ AVS_CS_SUB_HEIGHT_1 = 3 << AVS_CS_SHIFT_SUB_HEIGHT, // YV16, YV24, YV411
+ AVS_CS_SUB_HEIGHT_2 = 0 << AVS_CS_SHIFT_SUB_HEIGHT, // YV12, I420
+ AVS_CS_SUB_HEIGHT_4 = 1 << AVS_CS_SHIFT_SUB_HEIGHT, // YUV9
+
+ AVS_CS_SAMPLE_BITS_MASK = 7 << AVS_CS_SHIFT_SAMPLE_BITS,
+ AVS_CS_SAMPLE_BITS_8 = 0 << AVS_CS_SHIFT_SAMPLE_BITS,
+ AVS_CS_SAMPLE_BITS_16 = 1 << AVS_CS_SHIFT_SAMPLE_BITS,
+ AVS_CS_SAMPLE_BITS_32 = 2 << AVS_CS_SHIFT_SAMPLE_BITS,
+
+ AVS_CS_PLANAR_MASK = AVS_CS_PLANAR | AVS_CS_INTERLEAVED | AVS_CS_YUV | AVS_CS_BGR | AVS_CS_SAMPLE_BITS_MASK | AVS_CS_SUB_HEIGHT_MASK | AVS_CS_SUB_WIDTH_MASK,
+ AVS_CS_PLANAR_FILTER = ~( AVS_CS_VPLANEFIRST | AVS_CS_UPLANEFIRST )};

// Specific colorformats
enum {
@@ -104,9 +137,18 @@ enum {
AVS_CS_BGR24 = 1<<0 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
AVS_CS_BGR32 = 1<<1 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
AVS_CS_YUY2 = 1<<2 | AVS_CS_YUV | AVS_CS_INTERLEAVED,
- AVS_CS_YV12 = 1<<3 | AVS_CS_YUV | AVS_CS_PLANAR, // y-v-u, planar
- AVS_CS_I420 = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR, // y-u-v, planar
- AVS_CS_IYUV = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR // same as above
+ // AVS_CS_YV12 = 1<<3 Reserved
+ // AVS_CS_I420 = 1<<4 Reserved
+ AVS_CS_RAW32 = 1<<5 | AVS_CS_INTERLEAVED,
+
+ AVS_CS_YV24 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_1, // YVU 4:4:4 planar
+ AVS_CS_YV16 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_2, // YVU 4:2:2 planar
+ AVS_CS_YV12 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_2 | AVS_CS_SUB_WIDTH_2, // YVU 4:2:0 planar
+ AVS_CS_I420 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_UPLANEFIRST | AVS_CS_SUB_HEIGHT_2 | AVS_CS_SUB_WIDTH_2, // YUV 4:2:0 planar
+ AVS_CS_IYUV = AVS_CS_I420,
+ AVS_CS_YV411 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_4, // YVU 4:1:1 planar
+ AVS_CS_YUV9 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_4 | AVS_CS_SUB_WIDTH_4, // YVU 4:1:0 planar
+ AVS_CS_Y8 = AVS_CS_PLANAR | AVS_CS_INTERLEAVED | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 // Y 4:0:0 planar
};

enum {
@@ -191,17 +233,29 @@ AVSC_INLINE int avs_is_yuv(const AVS_VideoInfo * p)
AVSC_INLINE int avs_is_yuy2(const AVS_VideoInfo * p)
{ return (p->pixel_type & AVS_CS_YUY2) == AVS_CS_YUY2; }

+AVSC_INLINE int avs_is_yv24(const AVS_VideoInfo * p)
+ { return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_YV24 & AVS_CS_PLANAR_FILTER); }
+
+AVSC_INLINE int avs_is_yv16(const AVS_VideoInfo * p)
+ { return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_YV16 & AVS_CS_PLANAR_FILTER); }
+
AVSC_INLINE int avs_is_yv12(const AVS_VideoInfo * p)
- { return ((p->pixel_type & AVS_CS_YV12) == AVS_CS_YV12)||((p->pixel_type & AVS_CS_I420) == AVS_CS_I420); }
+ { return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_YV12 & AVS_CS_PLANAR_FILTER); }

-AVSC_INLINE int avs_is_color_space(const AVS_VideoInfo * p, int c_space)
- { return ((p->pixel_type & c_space) == c_space); }
+AVSC_INLINE int avs_is_yv411(const AVS_VideoInfo * p)
+ { return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_YV411 & AVS_CS_PLANAR_FILTER); }
+
+AVSC_INLINE int avs_is_y8(const AVS_VideoInfo * p)
+ { return (p->pixel_type & AVS_CS_PLANAR_MASK) == (AVS_CS_Y8 & AVS_CS_PLANAR_FILTER); }

AVSC_INLINE int avs_is_property(const AVS_VideoInfo * p, int property)
{ return ((p->pixel_type & property)==property ); }

AVSC_INLINE int avs_is_planar(const AVS_VideoInfo * p)
{ return !!(p->pixel_type & AVS_CS_PLANAR); }
+
+AVSC_INLINE int avs_is_color_space(const AVS_VideoInfo * p, int c_space)
+ { return avs_is_planar(p) ? ((p->pixel_type & AVS_CS_PLANAR_MASK) == (c_space & AVS_CS_PLANAR_FILTER)) : ((p->pixel_type & c_space) == c_space); }

AVSC_INLINE int avs_is_field_based(const AVS_VideoInfo * p)
{ return !!(p->image_type & AVS_IT_FIELDBASED); }
@@ -351,7 +405,7 @@ AVSC_INLINE int avs_get_row_size_p(const AVS_VideoFrame * p, int plane) {
else return 0;
case AVS_PLANAR_U_ALIGNED: case AVS_PLANAR_V_ALIGNED:
if (p->pitchUV) {
- int r = (p->row_sizeUV+AVS_FRAME_ALIGN-1)&(~(AVS_FRAME_ALIGN-1)); // Aligned rowsize
+ r = (p->row_sizeUV+AVS_FRAME_ALIGN-1)&(~(AVS_FRAME_ALIGN-1)); // Aligned rowsize
if (r < p->pitchUV)
return r;
return p->row_sizeUV;
@@ -602,7 +656,6 @@ enum {
AVS_CPUF_SSE4_2 = 0x800, // Nehalem
};

-
AVSC_API(const char *, avs_get_error)(AVS_ScriptEnvironment *); // return 0 if no error

AVSC_API(long, avs_get_cpu_flags)(AVS_ScriptEnvironment *);
@@ -715,6 +768,7 @@ struct AVS_Library {
AVSC_DECLARE_FUNC(avs_function_exists);
AVSC_DECLARE_FUNC(avs_get_audio);
AVSC_DECLARE_FUNC(avs_get_cpu_flags);
+ AVSC_DECLARE_FUNC(avs_get_error);
AVSC_DECLARE_FUNC(avs_get_frame);
AVSC_DECLARE_FUNC(avs_get_parity);
AVSC_DECLARE_FUNC(avs_get_var);
@@ -739,7 +793,6 @@ struct AVS_Library {
AVSC_DECLARE_FUNC(avs_subframe_planar);
AVSC_DECLARE_FUNC(avs_take_clip);
AVSC_DECLARE_FUNC(avs_vsprintf);
- AVSC_DECLARE_FUNC(avs_get_error);
};

#undef AVSC_DECLARE_FUNC
@@ -774,6 +827,7 @@ AVSC_INLINE AVS_Library * avs_load_library() {
AVSC_LOAD_FUNC(avs_function_exists);
AVSC_LOAD_FUNC(avs_get_audio);
AVSC_LOAD_FUNC(avs_get_cpu_flags);
+ AVSC_LOAD_FUNC(avs_get_error);
AVSC_LOAD_FUNC(avs_get_frame);
AVSC_LOAD_FUNC(avs_get_parity);
AVSC_LOAD_FUNC(avs_get_var);
@@ -798,7 +852,6 @@ AVSC_INLINE AVS_Library * avs_load_library() {
AVSC_LOAD_FUNC(avs_subframe_planar);
AVSC_LOAD_FUNC(avs_take_clip);
AVSC_LOAD_FUNC(avs_vsprintf);
- AVSC_LOAD_FUNC(avs_get_error);

#undef __AVSC_STRINGIFY
#undef AVSC_STRINGIFY
--
1.7.11.msysgit.1



Second,
This is a patch that adds a GNU-style Makefile to ease users needing to install AviSynth's headers. It installs both avisynth.h and avisynth_c.h:
diff --git a/GNUmakefile b/GNUmakefile
new file mode 100644
index 0000000..083ab09
--- /dev/null
+++ b/GNUmakefile
@@ -0,0 +1,13 @@
+# Makefile
+
+all: default
+
+PREFIX=/usr/local
+
+install:
+ install -d $(PREFIX)/include
+ install -d $(PREFIX)/include/avisynth
+ install -m 644 $(addprefix src/core/, avisynth.h avisynth_c.h) $(PREFIX)/include/avisynth
+
+uninstall:
+ rm -f -R $(PREFIX)/include/avisynth
diff --git a/README-GNUmakefile b/README-GNUmakefile
new file mode 100644
index 0000000..728584b
--- /dev/null
+++ b/README-GNUmakefile
@@ -0,0 +1,18 @@
+AviSynth, as an MSVC-based project, does not have a 'make install'
+routine that users familiar with GNU-style build systems recognize.
+Thus, users must search out the right header(s) from AviSynth's
+source code and manually copy them to wherever their source code
+expects them to be.
+
+As a remedy for this issue when wanting to build libav with
+--enable-avisynth, this Makefile supplies this method of
+installation.
+
+To install:
+make install
+
+To install to a non-standard location:
+make install PREFIX=/path/to/location
+
+To uninstall:
+make uninstall
--
1.7.11.msysgit.1



The reason for this is that libav is in the process of vetting the rewritten AviSynth demuxer that FFmpeg committed back in March. This new version of the demuxer uses the C interface header, and assumes the one included with x264 so that it can use YV24, YV16, YV411, and Y8. For FFmpeg this wasn't a problem, a copy of the header is stored locally in compat/. But libav doesn't want to store a local copy of the header, shifting the responsibility of acquiring and installing it onto the user (I have a stopgap repo on Github that supplies it, but I really don't like that as a solution). So avisynth_c.h in CVS would need to be updated in order to allow the demuxer to even compile correctly, and the GNUmakefile is there to eliminate the burden of manually copying files around.

[ultim]

DynamicAssembledCode::Free() should be using delete[] instead of free().

[ultim]

Hi IanB,

I'd like to ask for your permission to add back the license exception clause to the 2.6 avisynth.h in Avisynth+. Can we, please?

[vcmohan]

Where can one get the new avisynth.h for the 2.6 5th release?

[Groucho2004]

Where can one get the new avisynth.h for the 2.6 5th release?
You can either use the file from the official CVS repo here (http://sourceforge.net/p/avisynth2/cvs/) or use the header from AVS+, from here (https://github.com/AviSynth/AviSynthPlus)

[vcmohan]

You can either use the file from the official CVS repo here (http://sourceforge.net/p/avisynth2/cvs/) or use the header from AVS+, from here (https://github.com/AviSynth/AviSynthPlus) I tried both places. Each wants me to download another software prior. Is there no way of getting this file straight w/o hassle?
Are avisynth+ and avisynth 2.6 header files same?

[StainlessS]

@VcMohan,
you could just copy/paste the text from here:-
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/include/avisynth.h

[zero9999]

I tried both places. Each wants me to download another software prior. Is there no way of getting this file straight w/o hassle?
https://github.com/AviSynth/AviSynthPlus/archive/master.zip

or get the files separately from here (https://github.com/AviSynth/AviSynthPlus/tree/master/avs_core/include). (click RAW)

[vcmohan]

Thanks. I could get avisynth.h from a forked version of avisynth as avisynth plus. Are the original avisynth.h version (official) and this are from the fork identical?

[TurboPascal7]

No. You can get the original one from the alpha5 github mirror here (https://github.com/jeeb/avisynth/blob/master/src/core/avisynth.h). They aren't that different though and should be perfectly compatible.

[ultim]

No. You can get the original one from the alpha5 github mirror here (https://github.com/jeeb/avisynth/blob/master/src/core/avisynth.h). They aren't that different though and should be perfectly compatible.

They are perfectly compatible. Because avs+'s header is actually composed of multiple (a small number of) files though, it might be a bit easier for you to handle 2.6a5's version. EDIT: On the other hand, avs+'s header is x64-compatible.

[TurboPascal7]

Yes, your understanding is correct. Technically, all closed-source 2.6 plugins violate GPL. In practice, no one really cares.

[SEt]

Do I understand correctly that any Y8-compatible close-source plugin is illegal now because Y8 colorspace is added to 2.6?
Not really. You can completely ignore official header and define interfaces yourself. It's the code that is under GPL, not the interfaces as far as I understand.

[Wilbert]

Yes, your understanding is correct. Technically, all closed-source 2.6 plugins violate GPL. In practice, no one really cares.
Speak for yourself TurboPascal7. Only shameless people don't care. But if you have a list of examples let us know.

Not really. You can completely ignore official header and define interfaces yourself. It's the code that is under GPL, not the interfaces as far as I understand.
As far as I understand this is simply not true, because it is a derivative of AviSynth. But feel free to prove otherwise.

The reason the exemption was temporary removed is described here http://forum.doom9.org/showthread.php?t=125582 (plugins can be fixed when the api is finished). Yes if devs stay around the reason is a bit moot.

[TurboPascal7]

Speak for yourself TurboPascal7. Only shameless people don't care. But if you have a list of examples let us know.
What for? To force freedom on people's heads? To make the authors remove the plugins, making its users very happy? Even if I did know any, I'd shamelessly pass, thank you.

As for the reasoning - the point is very moot if the avs dev himself doesn't really stay around. Not to mention that 6 years is quite a long time to finalize the interface, don't you think?

[Guest]

The reason the exemption was temporary removed is described here http://forum.doom9.org/showthread.php?t=125582 (plugins can be fixed when the api is finished). I don't see how anybody can remove the exemption originally granted by the creator of Avisynth, Ben Rudiak-Gould. I will proceed as if the exemption is still in effect, and advise others to do the same.

[ultim]

I don't see how anybody can remove the exemption originally granted by the creator of Avisynth, Ben Rudiak-Gould. I will proceed as if the exemption is still in effect, and advise others to do the same.
Unfortunately, he can remove it. More precisely, he decided to license his own code in the header as GPL (without the exemption), which he has every right to do. Of course that does not remove the exemption from the other parts of the code that he has not written, but since his code is licensed under the GPL, as long as you use his header, you basically have to treat the whole project as GPL. You can ignore his step and treat the AviSynth code as if the exemption was still in effect, but then you must not use his header.

To summarize, you are free to proceed as if the exemption is still in effect if you don't use his 2.6-style header. Otherwise you're violating the licence.

EDIT: Actually, assuming he has contributed his non-header code under the GPL too, without his explicit agreement you cannot use the exemption at all with any of his copyrightable code, not even with other headers. Otherwise it would be possible to add non-GPL headers to GPL code and circumvent the licence in any project this way.

[Guest]

That's goofy. Why would IanB castrate all of us and then never restore the exemption?

What about your header for Avisynth+? What is the status of the exemption?

[TurboPascal7]

Sadly, Avisynth+ can't add it back without permission of IanB.

[Guest]

I will ask IanB to please restore the exemption. It's crazy that he would put a dam in the river like this.

Can't Avisynth+ re-engineer a header from the original exempted one? Why do you have to derive from IanB's stuff? Let him fork a dead end if that is what he wants.

[ultim]

I will ask IanB to please restore the exemption. It's crazy that he would put a dam in the river like this.

Can't Avisynth+ re-engineer a header from the original exempted one? Why do you have to derive from IanB's stuff? Let him fork a dead end if that is what he wants.

He also has contributed other code under the GPL, code that is not in the header. I cannot just take his GPL code and add a non-GPL exemption header, otherwise anybody could circumvent GPL this way in any project. So, although I'm not a lawyer, I'm reasonably sure we either need his agreement to add the exemption back, or we must re-write all copyrightable functionality that he has contributed to the project, both header and non-header code.

I'll edit my previous post accordingly.

[Guest]

Why do you have to take his code?

[TurboPascal7]

Because we already did (ultim wanted to contribute to the 2.6 codebase before creating the fork).
We want to support new colorspaces and keep compatibility with existing 2.6 plugins. Starting from 2.5.8 codebase or rewriting everything IanB wrote during these 6 years would delay new features quite noticeably and that's a lot more important to the end users than some silly licensing question.

[qyot27]

For what it's worth, the 2.6-ish extended version of avisynth_c.h from x264 does have the exemption intact (source (http://git.videolan.org/?p=x264.git;a=blob;f=extras/avisynth_c.h;h=5044efb0aa6816eac59c80c9a85b422d588cb2a4;hb=1ca7bb943d15165a4b9631002a655587d923be63)). Probably because it was done externally and wasn't subject to this particular circumstance - the one in AviSynth's CVS is still the old 2.5 version.

[SEt]

I'm far from law expert, but still think that interfaces are not subject to licensing restrictions (structures, function prototypes,...). For example, does linux kernel need to explicitly grant the permission for every interface to allow its usage in proprietary kernel modules?

I completely agree with TurboPascal7 that licensing restrictions can only harm Avisynth. Personally if I had to choice between going GPL or removing plugin that I don't want to be GPL – result will be removal 100% of the time. And I believe we do have several plugins removed by authors because they were threatened later with GPL stuff.

[Sapo84]

Unfortunately, he can remove it. More precisely, he decided to license his own code in the header as GPL (without the exemption), which he has every right to do.
But he can't change the license of the original code.
In the header I see three copyrights lines, either they are wrong (and he wrote every line of the header himself) or he should have needed consent from all the contributors to redistribute their code with a different license.

[ultim]

I'm far from law expert, but still think that interfaces are not subject to licensing restrictions (structures, function prototypes,...).
Headers are always subject of the license, but the licence may define separate terms for the headers. LGPL is such an example, but GPL is not. LGPL plays with the definition of "header", while GPL plays with the definition of "derived work".

For example, does linux kernel need to explicitly grant the permission for every interface to allow its usage in proprietary kernel modules?
Code that tightly integrates with the kernel is considered derived work, which already lead to problems at least once where NVIDIA couldn't integrate his won code because they didn't want to open-source it. Code that somehow only links to GPL modules over the headers is some kind of a grey zone, e.g. kernel devs allow you to have closed-source kernel modules (maybe they have an exemption for that? - dunno), while it is generally unacceptable to link desktop GPL libraries to closed-source apps. As I said, the difference is how you interpret "derived work", and different people do that differently.

I completely agree with TurboPascal7 that licensing restrictions can only harm Avisynth. Personally if I had to choice between going GPL or removing plugin that I don't want to be GPL – result will be removal 100% of the time. And I believe we do have several plugins removed by authors because they were threatened later with GPL stuff.
And I agree too. Me too would like to relicense Avisynth+ under the LGPL. My posts aren't aimed at defending the current licence of Avisynth, but that the current licence should still be adhered to even if I don't like it. Changing the licence still needs to be done in a legally conformant way - considering the old one too. And we are trying to do that actively.

[SEt]

Headers are always subject of the license, but the licence may define separate terms for the headers. LGPL is such an example, but GPL is not. LGPL plays with the definition of "header", while GPL plays with the definition of "derived work".
I'm not talking about headers. I'm talking about interfaces: if someone would write header for the same interfaces that are defined in GPL header it won't be derived work as I understand. If I release GPL header with prototype of function Add – it absolutely doesn't mean that some other projects that have the same function name with the same parameters that is doing the addition now must be under GPL.

Actually, all that "GPL purity" is one big lie, at least on Windows. While it's considered unacceptable for non-GPL code to use GPL libraries, it's totally Ok for GPL code to even statically link with non-GPL libraries. Our official Avisynth is compiled with VC6 which statically and dynamically link GPL code of Avisynth with absolutely non-GPL code of standard C/C++ library of VC6. And what? No one ever said anything. How Avisynth using external plugins is different to Avisynth using C/C++ library?

[TheFluff]

the gpl is a silly license that nobody complies with, partly because it's actually incredibly difficult to actually be fully compliant, and partly because nobody cares

I really have no idea why people keep choosing it, especially for libraries. I guess they haven't really understood what it actually means.

Actually, all that "GPL purity" is one big lie, at least on Windows. While it's considered unacceptable for non-GPL code to use GPL libraries, it's totally Ok for GPL code to even statically link with non-GPL libraries. Our official Avisynth is compiled with VC6 which statically and dynamically link GPL code of Avisynth with absolutely non-GPL code of standard C/C++ library of VC6. And what? No one ever said anything. How Avisynth using external plugins is different to Avisynth using C/C++ library?
See the GPL FAQ; you are allowed to link to "systems libraries": http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL
However, if you distribute mscvr*.dll together with your GPL plugin, you're technically violating the GPL. By the way, did you know that the exemption in the Avisynth header still requires authors of closed source plugins to distribute the full source code of Avisynth with their plugins?

As I said, nobody (except maybe the FSF) really complies with the GPL fully. It's way too difficult to be compliant.

[LoRd_MuldeR]

Our official Avisynth is compiled with VC6 which statically and dynamically link GPL code of Avisynth with absolutely non-GPL code of standard C/C++ library of VC6. And what? No one ever said anything. How Avisynth using external plugins is different to Avisynth using C/C++ library?

Well, the GPL prohibits applications, which are not released under a GPL-compatible license, to link against GPL'd code. So the GPL is all about what others are allowed or not allowed to do with your code. But here it's the other way around. We have a GPL'd application that, unavoidably, links against certain system/runtime libraries, which are non-GPL. Since it's your application, you decide under which conditions it gets released. So if you, as the copyright holder, decide that linking your app against the VC-Runtime libraries is fine, then it will be allowed. In addition to that, I think the GPL even includes a special exception for fundamental system libraries. Otherwise no GPL'd code would be allowed to run on Windows or Mac OS X...

(The same way, you, as the copyright holder, may decide that using the "interface" header files of your application in some thrid-party applications is not considered a "derived work")

[SEt]

See the GPL FAQ; you are allowed to link to "systems libraries": http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL
Some part of runtime library is always statically linked within the resulting binary, even if you choice dynamic runtime. That is clearly not exempted in our GPLv2 and likely not in GPLv3 (the wording there is even more confusing).

However, if you distribute mscvr*.dll together with your GPL plugin, you're technically violating the GPL.
Official Avisynth does exactly this and distributes msvcp60.dll :p

So if you, as the copyright holder, decide that linking your app against the VC-Runtime libraries is fine, then it will be allowed.
But it won't be automagically granted if you just stick GPL license with your work and not actually word this approval, right?

[TurboPascal7]

rean
So basically you want avs+ to come up with a new API? That is planned but only after features like MT and high bitdepth processing are implemented, since they will affect the API considerably.

I kinda hope(d) we can solve this issue by simply talking to avisynth developers because come on, it's clear that GPL does not work in avs. Unfortunately IanB seems to be ignoring the question (http://forum.doom9.org/showthread.php?p=1653152#post1653152).

[LoRd_MuldeR]

Some part of runtime library is always statically linked within the resulting binary, even if you choice dynamic runtime. That is clearly not exempted in our GPLv2 and likely not in GPLv3 (the wording there is even more confusing).

Whether you link statically or dynamically doesn't matter for the GPL. It does matter for the LGPL - or more precisely for how the LGPL is usually interpreted.

Linking LGPL'd code into a ClosedSource application as a DLL or SO file is generally accepted, while linking it statically is not. As far as the GPL is concerned, both cases are not allowed anyway.

But it won't be automagically granted if you just stick GPL license with your work and not actually word this approval, right?

Well, as has been mentioned before, there is an exception in the GPL for "system libraries", because otherwise no application could be GPL-compliant on proprietary OS, like Windows or Mac OS X.

Even if you avoid linking against the Visual Studio C-Runtimes, which indeed is possible, you still need to use the Win32 API (Kernel32.dll and friends) for fundamental stuff like I/O and memory management.

Consequently, it wouldn't make much sense if any software author would need to explicitly add an exception for something that is required anyway - no matter what.

Last but not least: The intent of the GPL is to prevent GPL'd code from getting "assimilated" into ClosedSource applications - not to put restrictions on what the GPL'd application is allowed to do...

[SEt]

LoRd_MuldeR, as I remember, x264 used to be sources-only software without official binaries due to legal stuff. What looks logical, obvious and required from the view of normal sane person, is not so from the point of law.

The intent of GPL is to consume other open source software and prevent development of everything outside of GPL.

[LoRd_MuldeR]

LoRd_MuldeR, as I remember, x264 used to be sources-only software without official binaries due to legal stuff. What looks logical, obvious and required from the view of normal sane person, is not so from the point of law.

Don't mix up issues with software licenses and those with patent royalties. Those are two mostly independent things.

The GPL explicitly does allow redistribution of binaries (as long as the sources are provided). It also explicitly does allow commercial use. So there's no problem here at all.

However, if an application uses patented technology, such as H.264, you may still need to pay patent royalties to the patent holders - not the software author.

The intent of GPL is to consume other open source software and prevent development of everything outside of GPL.

The intent is that, if somebody incorporates the code that you kindly shared as OpenSource, then he/she will have to share his/her code under the same conditions as you did.

In other words: It ensures that OpenSource remains OpenSource. Thus, grabbing somebody's OpenSource code and turning it into a CloseSource software is prevented.

The intent obviously can not be to create a piece of software that is useless on most platforms, because it's no longer allowed to load the required fundamental system/runtime libraries ;)

[TurboPascal7]

In other words: It ensures that OpenSource remains OpenSource. Thus, grabbing somebody's OpenSource code and turning it into a CloseSource software is prevented.
That's more like LGPL and other licenses that require you to share changes to the OpenSource codebase. GPL is more like a plague - if you touch anything with it, you're finished. You have to share all your code that might be completely unrelated to the library. Code so bad that you don't want anyone to look at it because it's too embarassing. Or maybe code that helps you make some money. Looks like forced freedom if you ask me.

[TheFluff]

Last but not least: The intent of the GPL is to prevent GPL'd code from getting "assimilated" into ClosedSource applications - not to put restrictions on what the GPL'd application is allowed to do...

That is arguably untrue. Both the letter and the spirit of the license actually do have those restrictions (there's a funny line in the GPL FAQ about how Windows-only GPL applications are bad because they're "trapped" on Windows and thus aren't contributing to the open source world, i.e. Linux). If you compile FFmpeg with both GPL-licensed and non-GPL-compatible-licensed modules, the resulting license is "unredistributable". You might think that doesn't matter, but if you actually intend to enforce your license in court you sorta have to make sure you comply with it yourself, or your case is likely to get thrown out. If you're not intending to enforce it, it doesn't really matter which license you pick anyway, now does it?

tl;dr: license your stuff with 2-clause BSD or make it proprietary, you're most likely never going to be able to actually enforce anything other than that anyway

[LoRd_MuldeR]

GPL is more like a plague - if you touch anything with it, you're finished. You have to share all your code that might be completely unrelated to the library.

Yes, that's when somebody else wants to re-use your GPL'd code. Then, indeed, they'll have to put their code under the GPL too - and thus make their sources open. But initially we were talking about the other direction! And, as a matter of fact, quite often a GPL'd application simply cannot get around using some libraries that are non-GPL! For example, under Windows it is technically impossible to create an executable that doesn't use the Win32 API and thus unavoidably loads "kernel32.dll" and friends. Okay, we can go down to the "native" API, but then still "ntdll.dll" will be loaded. And, even if we accept that such "system" libraries are the only exception, what happens if my GPL'd application creates an "Open File" dialog and that dialog - because it's created by the Windows Shell - injects some proprietary Shell Extension DLL's into my process? Or what about things like DirectShowSource in Avisynth, which almost certainly injects some proprietary DShow Filter DLL's into my process? With those examples (and we could go on here forever) it becomes obvious that, in reality, GPL'd application do load and use proprietary libraries - simply because it is unavoidable for those application to actually function.

That is arguably untrue. Both the letter and the spirit of the license actually do have those restrictions

As the author and copyright holder, how can the license put any restrictions on my software that I don't like? I decide which conditions I release my application under. If I decide that, for my application, certain things are allowed, then they are. And I'm free to say: my application is released under the GPL with the following clarifications added by me. For example, I can decide that my application is designed to work with DirectShow Filters and thus loading a DirectShow Filters is considered "using the application" rather than creating a "derived work", because anything else would be insane. Of course I can not decide such things for somebody else's work. And especially not when I re-use somebody else's work. But for my own work I can! Heck, I can even decide to release my application under the GPL and, at the same time, also under a proprietary license of my choice. That's what the x264 devs are doing, by the way ;)

[foxyshadis]

Guys, the reason the exception was removed during development is so that any filters released and abandoned during Avisynth development can be fixed by the community when the interfaces break (inevitably, unfortunately).

I'm fully in agreement that a 6 year alpha cycle for already reasonably stable software is rather disappointing, but you have to admit that in a mere 5 alpha releases it's done a pretty good job of breaking things a few times, and probably will again at this rate. Others are actively developing for it right now, despite still being somewhat fluid. Beta interfaces are supposed to be stable, so maybe the clause could be inserted again when that point comes... but you never know.

[TurboPascal7]

The road to hell is paved with good intentions, yeah.

[vcmohan]

When I convert to YV16 in Avisynth, I find I had to swapUV to correctly display in virtualdub. Is this a normal behaviour?

[Wilbert]

When I convert to YV16 in Avisynth, I find I had to swapUV to correctly display in virtualdub. Is this a normal behaviour?
That happened in old versions of Virtualdub (same for YV24). It should work fine in newer versions.

[vcmohan]

I was using (wrongly) BitsPerPixel()/ 8 as the distance in bytes to the next similar color component. In 2.5 version due to integer maths it worked fine for RGB32, RGB24, YUY2 and YV12. However it brokedown in 2.6 for YV16 and YV24. My question is excepting for calculating frame size this parameter does not appear to have any use. Instead a parameter that gives the distance along width in bytes to the corresponding color component might be useful. How does one get this value without using if statements?
In future Formats might have more than 8 bits per color.

[vcmohan]

I tried to get the latest 2.6 alpha 5 avisynth dll. When I googled it I could see it hosted in a third party (codecs.com) but not in avisynth official page. Can the latest avisynth.h and build of avisynth.dll be made available on avisynth web site?

[StainlessS]

VcMohan,
See Avisynth_130918.Exe link here:-
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%205%20%5B130918%5D/

[Wilbert]

I was using (wrongly) BitsPerPixel()/ 8 as the distance in bytes to the next similar color component. In 2.5 version due to integer maths it worked fine for RGB32, RGB24, YUY2 and YV12. However it brokedown in 2.6 for YV16 and YV24.
What do you mean it broke down? For YV12 BitsPerPixel() returns 12 bit (as in AviSynth 2.5), for YV16 it returns 16 bit and for YV24 it returns 24 bit. Did you expect (or want) something else?

Instead a parameter that gives the distance along width in bytes to the corresponding color component might be useful.
I guess you are looking functions like RowSize(plane), GetPlaneWidthSubsampling(plane) or GetPlaneHeightSubsampling(plane).

[vcmohan]

What do you mean it broke down? For YV12 BitsPerPixel() returns 12 bit (as in AviSynth 2.5), for YV16 it returns 16 bit and for YV24 it returns 24 bit. Did you expect (or want) something else? Sorry you misunderstood. My code broke down as it should. Not of Avisynth.


I guess you are looking functions like RowSize(plane), GetPlaneWidthSubsampling(plane) or GetPlaneHeightSubsampling(plane). I am looking for a parameter similar to pitch to access the next similar color along the width. It will be 4 for RGB32, 3 for RGB24, 2 for YUY2 and 1 for all current Planar formats. Many times I have common code for all RGB and luma of YUY2 and Planar. I am just wondering that such a parameter is desirable or I should continue with if statements to derive it.

[TurboPascal7]

Sounds like you want VideoInfo::BitsPerPixel() / 8. Although that seems to do quite weird things for YUV but you can easily work around that with something like vi.IsPlanar() ? 1 : vi.BitsPerPixel() / 8. This won't work well for 16-bit but well, almost nothing will.

[vcmohan]

yes. Right now I am doing that as mentioned in my first post above. But I thought Avisynth.h may provide such a value by a single call, it will be better.

[Wilbert]

Try VideoInfo::BytesFromPixels(pixels=1). That will work on the first plane only.

[vcmohan]

Try VideoInfo::BytesFromPixels(pixels=1). That will work on the first plane only.

Looks I have to rely on if statements for this value.

[Wilbert]

Looks I have to rely on if statements for this value.
What do you mean? BytesFromPixels(1) should always give the value you want.

[vcmohan]

Yes. It gives the value I am after. But the nomenclature is such I could not guess. Thanks

[hank315]

@IanB
Could you please reinstate the original license with the special exemption (as it was in Avisynth 2.5.8) for the 2.6.x Avisynth.h file:
As a special exception, the copyright holders of Avisynth give you permission to link Avisynth
with independent modules that communicate with Avisynth solely through the interfaces defined in avisynth.h,
regardless of the licenseterms of these independent modules,
and to copy and distribute the resulting combined work under terms of your choice,
provided that every copy of the combined work is accompanied by a complete copy of the source code
of Avisynth (the version of Avisynth used to produce the combined work),
being distributed under the terms of the GNU General Public License plus this exception.
An independent module is a module which is not derived from or based on Avisynth,
such as 3rd-party filters, import and export plugins, or graphical user interfaces.

TIA ...

[vcmohan]

I am a little baffled as an occasional plugin developer. I find that compared to this thread of avisynth 2.6 alpha 5, the threads of avisynth+, avisynth+ plugin modernization and vapoursynth are much more active. I find the discussion contributors are many times same persons in all these threads. Does this mean the future (as one sees at this moment) is for avisynth+ ? Should I therefore study more of avisynth+? Unfortunately while each of them state they are compatible with avisynth 2.5 plugins, any new one developed on any of these platforms are incompatible with others. Should I bide time?

[TurboPascal7]

I am a little baffled as an occasional plugin developer. I find that compared to this thread of avisynth 2.6 alpha 5, the threads of avisynth+, avisynth+ plugin modernization and vapoursynth are much more active. I find the discussion contributors are many times same persons in all these threads. Does this mean the future (as one sees at this moment) is for avisynth+ ? Should I therefore study more of avisynth+? Unfortunately while each of them state they are compatible with avisynth 2.5 plugins, any new one developed on any of these platforms are incompatible with others. Should I bide time?
I'm not going to judge what the future is because I'm very biased, but you should know that avisynth+ does not currently recommend you to write avisynth+-specific plugins. New API extensions are not very stable yet and at some point the API will be obsoleted anyway.

So the best way as far as avs+ and avs 2.6 are concerned is simply writing avs 2.6 plugins. You can use some of the new avs+ features like MT registration without breaking compatibility with regular avisynth and in the unfortunate case the project dies, you'll still have a working plugin.

Of course you can also write avs 2.5 plugins but I see no reasons to do that, aside from licensing restrictions. Yes, vapoursynth will get a chance of loading your plugin if you go 2.5 (won't work if you use env->Invoke and maybe some other things), but if you care about that, it's probably better to add direct cross-platform vsynth support manually anyway.

[foxyshadis]

Myrsloik has pointed out that he'd like to support avs+'s final 2.6 (or whatever) API in VS as well, the current lack of compatibility is mainly because it's been changing constantly. With any luck this situation won't last much longer.

The staggering amount of effort involved in rebuilding legacy plugins for avs+ and VS does obsolete some of the effort put into keeping vanilla avs 2.6 backward-compatible, though, and bringing it all forward is a major gain. Unless someone else forks avs, it looks like avs+ is the future. (Like ffdshow to ffdshow-tryouts.)

[Myrsloik]

Myrsloik has pointed out that he'd like to support avs+'s final 2.6 (or whatever) API in VS as well, the current lack of compatibility is mainly because it's been changing constantly. With any luck this situation won't last much longer.

...

Just to make it clear, there are actually two obstacles. One is that the 2.6 API changes a bit now and then but that's no big issue since it has kinda settled now (due to slow development in general).

The real problem is that memory offsets for frame data are stored in ints and not a 64 bit type in the x64 version of the API. This is insane, ultim knows about it, and prevents all compatibility ever since VS allocates each plane of a frame individually which means that the "offsets" can be too big to fit.

Summary: 32bit avisynth 2.6 alpha 5 api is easy but I'm a bit lazy, everything else is a mess that's better not supported for now. Avs+ will most likely be cleaner to support once it finishes its api since it's internally closer to VS.

[StainlessS]

Seems to be a bug in AviSource as previously posted here: http://forum.doom9.org/showthread.php?p=1675662#post1675662

Concerns techSmith TSCC2 codec, decoder only, found here: https://support.techsmith.com/entries/22849238-Camtasia-Studio-Download-the-TSC2-standalone-codec

2007 Thread with same unresolved problem here: http://forum.doom9.org/showthread.php?p=1062041&highlight=techsmith+avisource#post1062041

and a 27MB HD sample that exhibits the problem here : http://www.mediafire.com/download/7vzc2j6tjahm88v/painting+test+for+avisynth.avi
(courtesy of user eduardobedoya, thank you)

DirectShowSource successfully loads and plays clip, AviSource produces lots of black frames, presumably drop frames.

Vdub current and VdubMod have no problems loading/playing/seeking sample.

[Nevilne]

Not sure where to post this but TCPServer doesn't work with YV24 clips, it only transmits 1/4 cut of chroma to TCPSource but still marks clip as YV24. RGB, YV12 and YV24 planes in RGB (which is expensive for hi res clips) work fine.

[StainlessS]

Bug ChromaUDifference returns NaN indeterminate for Y8. (EDIT: Presumably ChromaVDifference also, untested)


Blankclip(pixel_type="Y8")
ScriptClip("""subtitle(string(ChromaUDifference(Last,Last)))""")
return last.convertTorgb


shows "-1.#IND00".

[TheFluff]

What behavior would you expect? It's an invalid operation, NaN seems like a perfectly reasonable thing to return to me. Throwing an exception would probably be a better idea though.

[StainlessS]

Throwing an exception would probably be a better idea though.

Exactly.

[Wilbert]

Bug ChromaUDifference returns NaN indeterminate for Y8.
I guess the proper behaviour is to output an error message right? Holds for all its variants too.

edit: too late ;)

[Groucho2004]

Bug ChromaUDifference returns NaN indeterminate for Y8. (EDIT: Presumably ChromaVDifference also, untested)


Blankclip(pixel_type="Y8")
ScriptClip("""subtitle(string(ChromaUDifference(Last,Last)))""")
return last.convertTorgb


shows "-1.#IND00".
Yes, it's a division by zero in "ComparePlane::CmpPlane()" (in this particular case). Checking the (float) return value with something like this:
if (_finite(f) == 0)
env->ThrowError("Return value infinite or NaN");

would catch it. However, installing a local/global FP exception handler would be nicer although it could impact performance.

[StainlessS]

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.

EDIT: Simlar failures on AverageChromaU, UDifferenceToNext (probably UDifferenceFromPrevious)

UPlaneMax returns 0
UPlaneMin/UPlaneMedian/UPlaneMinMaxDifference return 255

and probably same for V variants.

[ARDA]

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.


I guess is cause Y8 is also planar. Some testing is lacking.

[Gavino]

If called with RGB, shows error "Plane Difference: Only Planar images (As YV12) supported!".
No reason why Y8 could not be detected before division by zero occurs.
Yes, the obvious place to catch these errors is in the sanity checks at the start of each function, where the input clip properties are already being checked.

[vcmohan]

Is Avisynth 2.6 natively multithread capable. I find that there are various levels of multithreading. One post of avisynth+ states that plugins should specify which level of multithreading is required. If so how to specify this in 2.6? Or one need to call Avisynth.MT specifically?I am confused as a thread Avisynth.MT is also in the forum.

[turbojet]

This build isn't capable of multithreading. AvisynthMT and latest "test" build of Avisynth+ are. Plugins can have internal multithreading, nnedi3 is one of these and should fully load cpu no matter how many cores or avisynth is used.

[vcmohan]

Avisynth+ for parallel processing specifically advises the plugin authors not to multithread internally themselves in the plugin.

[turbojet]

I think it's because they want to be able to handle all threads internally, which makes sense but also requires very stable and complex threading. If all plugins had multithreading there'd be no need for a custom avisynth build. While I know its avisynth+ focus for internal multithreading I think it's too soon to say what's really going to happen since all that's been released is a test build and development seems to be on hiatus.

If I was a plugin developer I'd still try to multithread plugins, after all all that's needed to disable it is to set threads=1.

[huokok]

Hi, I'm a beginner using avisynth and noticed, should I say a minor problem.
I am handling with an anomophic video, after resizing and adding subtile, I noticed that avs behaves differently from normal playing back. Here I mean using Lav and xy-vsfilter for normal palying back.
By default, xy-vsfilter disables PAR compensation, which is exactly the same in Aegisub, as well as normal playing back. I have checked that the VSFilter plugin contained in meGUI (I am using meGUI for encoding) is actually the same with my installed xy-vsfilter (VSFilter.dll).
May I ask why avs deals with .ass files in such way? Or am I misunderstanding something?

[StainlessS]

@huokok, This is the developer forum, try Newbie or Usage forums.

Not sure if this is a caching bug, but it seems weird.


AVISource("D:\AVS\JurassicPark.avi")
ORG=Last
DEL=3

A=ClipBlend(delay=DEL,exponential=true) # Every 30 frames requests frame twice from this clip.
B=ClipBlend(delay=DEL,exponential=false) # but not this one
D=Subtract(A,B)
Q=Stackvertical(ORG,D)
R=StackVertical(A,B)
StackHorizontal(Q,R)
return Last


Requests same frame twice, every 30 frames from clip A, but not from clip B.
The ClipBlend filters are not relevant, its just that I have debugging enabled in them right now.

Is this expected behaviour ?

EDIT:

D=Subtract(B,A)

Requests twice from clip B instead of clip A.

Perhaps does in place subtract rather than NewVideoFrame, but still, should cache not jump in here when MakeWritable called ?

Why every 30 frames, SetMemoryMax(256) and SetMemoryMax(1024) make no difference.

EDIT: Script producing same results

TWICE = True

AVISource("D:\AVS\FlashTest.avi")
ORG=Last
Global A_Frame = -1
Global B_Frame = -1

Function A_fn(clip c) {
c.ScriptClip("""
(current_frame == A_Frame) ? RT_debugF("%d] A called twice",current_frame) : NOP
Global A_Frame=current_frame
return (TWICE) ? Last.invert : Last
""",after_frame=true)
}

Function B_fn(clip c) {
c.ScriptClip("""
(current_frame == B_Frame) ? RT_debugF("%d] B called twice",current_frame) : NOP
Global B_Frame=current_frame
return (TWICE) ? Last.invert : Last
""",after_frame=true)
}

A=A_fn()
B=B_fn()
D=Subtract(A,B)
# Return D # On about 7300 frames does not request any frame twice
L=Stackvertical(ORG,D)
# Return L # On about 7300 frames does not request any frame twice
R=StackVertical(A,B)
#Return R # On about 7300 frames does not request any frame twice (D and L play no part in output clip)
StackHorizontal(L,R) # Request frame twice every 30 frames
return Last

EDITED: Changed to After_Frame=True

Results:

00000001 0.00000000 RT_DebugF: 0] A called twice # ???
00000002 0.02283134 RT_DebugF: 1] A called twice # ???
00000003 1.13505709 RT_DebugF: 29] A called twice
00000004 2.33850622 RT_DebugF: 59] A called twice
00000005 3.53572321 RT_DebugF: 89] A called twice
00000006 4.73558807 RT_DebugF: 119] A called twice
00000007 5.93475008 RT_DebugF: 149] A called twice
00000008 7.13609219 RT_DebugF: 179] A called twice
00000009 8.33965588 RT_DebugF: 209] A called twice
00000010 9.53348637 RT_DebugF: 239] A called twice
00000011 10.73409081 RT_DebugF: 269] A called twice
00000012 11.93526363 RT_DebugF: 299] A called twice
00000013 13.13406563 RT_DebugF: 329] A called twice
00000014 14.34332275 RT_DebugF: 359] A called twice
00000015 15.53387451 RT_DebugF: 389] A called twice
00000016 16.73608208 RT_DebugF: 419] A called twice
00000017 17.93279266 RT_DebugF: 449] A called twice
00000018 19.13314247 RT_DebugF: 479] A called twice
00000019 20.33571243 RT_DebugF: 509] A called twice
00000020 21.53307343 RT_DebugF: 539] A called twice
00000021 22.73343849 RT_DebugF: 569] A called twice
00000022 23.93457794 RT_DebugF: 599] A called twice
00000023 25.13291740 RT_DebugF: 629] A called twice
00000024 26.33256149 RT_DebugF: 659] A called twice
00000025 27.53370094 RT_DebugF: 689] A called twice
00000026 28.73566055 RT_DebugF: 719] A called twice
00000027 29.93317223 RT_DebugF: 749] A called twice
00000028 31.13321686 RT_DebugF: 779] A called twice
00000029 32.33431244 RT_DebugF: 809] A called twice
00000030 33.53618240 RT_DebugF: 839] A called twice
00000031 34.73554611 RT_DebugF: 869] A called twice
00000032 35.93282318 RT_DebugF: 899] A called twice
00000033 37.13544846 RT_DebugF: 929] A called twice
00000034 38.33409500 RT_DebugF: 959] A called twice
00000035 39.53222275 RT_DebugF: 989] A called twice
00000036 40.73387527 RT_DebugF: 1019] A called twice
00000037 41.93296814 RT_DebugF: 1049] A called twice
00000038 43.13276672 RT_DebugF: 1079] A called twice
00000039 44.33391953 RT_DebugF: 1109] A called twice
00000040 45.53221130 RT_DebugF: 1139] A called twice
00000041 46.73321152 RT_DebugF: 1169] A called twice
00000042 47.93227768 RT_DebugF: 1199] A called twice
00000043 49.13507843 RT_DebugF: 1229] A called twice
00000044 50.33272552 RT_DebugF: 1259] A called twice
00000045 51.53367996 RT_DebugF: 1289] A called twice
00000046 52.73460770 RT_DebugF: 1319] A called twice
00000047 53.93500900 RT_DebugF: 1349] A called twice
00000048 55.13346863 RT_DebugF: 1379] A called twice
00000049 56.33296204 RT_DebugF: 1409] A called twice
00000050 57.53406143 RT_DebugF: 1439] A called twice
00000051 58.73265076 RT_DebugF: 1469] A called twice
00000052 59.93371201 RT_DebugF: 1499] A called twice
00000053 61.13440704 RT_DebugF: 1529] A called twice
00000054 62.33270264 RT_DebugF: 1559] A called twice
00000055 63.53389740 RT_DebugF: 1589] A called twice
00000056 64.73960876 RT_DebugF: 1619] A called twice
00000057 65.93464661 RT_DebugF: 1649] A called twice
00000058 67.13314819 RT_DebugF: 1679] A called twice


Checked on three machines, 1st 3GB ram, 2nd 1.5 GB, 3rd 1.GB, same results, every 30 frames called twice.
Tested on 720x576 PAL and 640x400 PAL, same results.

Tested on 32x32 YV12 25 FPS, same again, called twice every 30 frames, memory seems not to be the issue.

Affects:- Avisynth v2.6Alpha4, Avisynth v2.6Alpha5, Avisynth v2.6+r1576
Not Affected:- Avisynth v2.57, Avisynth v2.58, Avisynth v2.6Alpha3

This has to be a bug.

[StainlessS]

Can someone please verify above post as a genuine bug.
Thank you in advance.

Could have bad consequences for any temporal filter that relies on
playing through from start to end without jumping about on the timeline.
(Even those filters that can scroll both forwards or backwards 1 frame at a time,
but dont expect to be asked for the same frame twice, as cache usually works most of the time).

[TheFluff]

Why do you care? Making assumptions about caching behavior is a terrible idea. If your implementation of GetFrame isn't idempotent you deserve everything terrible that could possibly happen to you and if Avisynth actually had a real API you'd be violating it. Making assumptions about frame request order is also an incredibly horrible idea.

[StainlessS]

So everything is Okey Dokey then, you're such an excessively jovial fellow (as usual).

[vcmohan]

Isn't it time to make the alpha version into a Beta if not a release. I found that I had to alter my display threads to 45 days to get to this thread. Because of the long gap in postings I presume that the development has sufficiently matured for a release. Any minor patches can be released later.

[Groucho2004]

Because of the long gap in postings I presume that the development has sufficiently matured for a release.
I think the development has ceased or is at least dormant.

[Sparktank]

You could subscribe to the thread and get isntant emails. Granted, they won't always be about IanB posting anything, but rather anyone posting.
Given that it's been more >=45 days before anyone has posted and you had to change your forum settings, subscription would be more conventional.

Although we're coming on up the 1 year anniversary for this version, it's still pretty impressive all the updates we've gotten recently. The longest we've gone without an update was close to 2 years (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/).

I'm hoping it's just dormant. Where so many other freeware editing products fail, AVS is the one that leaves a pretty big shoe for everyone else to fill up.
I'd hate to see the day that AVS becomes a memory and an underground tool spoken only as bedtime stories.
Techonology advances, but never so accurately as Avisynth. I weep for those who praise commercial industries as leading technological conglomerates with their fancy "in-house" algorithms for upscaling, color-correcting and interpolating. They merely dance in the footprints of the full potential of what can be developed here.

I say, don't let this all end in as a dream. :(

[ARDA]

I say, don't let this all end in as a dream.


Only IanB can lead this dream to a new stage. I hope he will be back soon.

Arda

[vcmohan]

I have ported some of my plugins to 2.6 version and are available on my page for down loading. Any feed back is welcome.

[Reel.Deel]

I have ported some of my plugins to 2.6 version and are available on my page for down loading. Any feed back is welcome.

Wow, you updated quite a bit of plugins. Thanks vcmohan!

[Wilbert]

@vcmohan,

Could you include source files like Planar_2_5_or_2_6.cpp, the header files and the project files in your packages (AdaptiveMedian_src.zip for example), so we can build them too? Are the sources public domain?

edit: typo

[vcmohan]

All source files for the plugins which have 2.6 version are now included. As I have compiled with VC++6, will the project files be useful ? If they will be useful then I will add them also.

[Wilbert]

Thanks for the inclusion! The project files are not useful to me, so i will leave it up to you to include them or not.

[burfadel]

I wonder what will happen now that two prime source filters for Avisynth appear to be dead, FFMS2 and L-SMASH Works? Even if they aren't dead, they might as well be if you can't download them! Because they rely on decoders, you could literally continually have update from them even if the source part hasn't been updated.

[videoh]

Only IanB can lead this dream to a new stage. I hope he will be back soon. He could also return the licensing for his contributions to the original license so that others may carry on the work.

[vcmohan]

is this link for avisynth2.6 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%205%20%5B130918%5D/AviSynth_130918.exe/download) correct and latest? When I tried to install it it wants avisynth2.5 folder.

[StainlessS]

VCMohan,
That is I think from the the correct link however it is the auto download page for the executable, you should have pointed to its parent,
here :http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/
Where it is the AVS 2.6.0 Alpha 5 [130918] file.

Avisynth 2.6A5 (as previous 2.6 Alpha's) all still use an "AviSynth 2.5" folder.