AviSynth 2.6.0 Alpha5 [Sep 18th, 2013]

[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).