AviSynth 2.5.6 RC 2 Release Candidate [October 7th]

[LigH]

{ edit - Sorry, just found: "FrameNumber" ~ "current_frame" }

[tsp]

Originally posted by LigH
And now for something completely different:

But: Is there any specific reason why there is no available function to have a condition or value based on the frame number? E.g. something like

Subtitle(string(clip.FrameNumber)+"/"+string(clip.FrameCount))

(just a simplified example) would be great, but seems to be impossible at the moment.

ehh like this?

scriptclip("""subtitle(string(current_frame)+"/"+string(FrameCount))""")

try it it works even in 2.55 :p

Originally posted by kassandro

There is nothing intrinsically bad about raising the alignment. In fact, the 2.5.6 beta did exhibit a programming bug in MPEG2DEC3/DgDecode, which of course must be fixed before 2.5.6 is released. As I pointed, this bug is already there with the old alignment, if the widths of the mpeg2 video is 712. If we would now return to the old alignment we simply would surrender to lousy programming. When we move to 64 bit, we certainly want the chroma to be better aligned. It is therefore better to have these troubles now than later, when we have a lot of other troubles as well.

when we move to 64 bit all filters will have to be recompiled anyway(so that could be a good reason start using pitch instead of width ;) ) so why not just implement the new alignment in the 64 bit version and let the current filters work in the 32 bit version? How expensive are a BlitBit anyway??

[ARDA]

@all
I've been doubting for more than a week to write this post. So my
apologizes in advance if I've misunderstood something.

To avoid too long post I'll not quote.

To discuss nowadays if SSE2 should be included or not seems to me
useless. SSE4 are coming soon and easier conditions for SSE2 are still discussed.

Right aligment seems a condition for any future development.

sh0dan brought a revolution in avisynth when he introduced YV12 colorspace to mention
just the beginning. We all were acquainted to see fast improvements, bugs and their fixes
one day and another. Nowadays we are missing his every day contributions; but I guess
everybody understands that people has also private life.

At that time there were also some voices complaining that all filters should be recompiled, etc...
But great changes has always a cost; and mistakes are unavoidable.

neuron2 has made so many contributions to this comunity that the list would be endless.
Mistakes, maybe, but who hasn't made? So any other considerations are completely wrong.

IanB has started a new and important change with right aligment for SSE2 instructions.
Some considerations about the general gain if just one filter with SSE2 is in the whole chain
has been made.
Obviously just one in the general process is useless; but is that the right question?.
I do not think so. The right question is to create the neccessary conditions to
be able to start step by step including SSE2 where possible and important.

To wait till 64 bits version. I sincerly don't understand. When we most of us have 64 bits machines
and a stable operating system, SSE2 will probably be and old thing (exaggerated). SSE2 are in most computers in market nowadays (with low prices) and already usable under 32 bits operating systems.
Are there here some personal preferences or any other reason I don't get to understand?

I must add I think all should be done in a controlled way to avoid conflicts. And maybe this is the origin
of this small polemic.

A bigger amount of memory will be needed with latest changes cause the bigger pitches.
That's a price should be discussed and suggestions could be done. New CPUs with bigger and faster
caches and another technic improvements of bandwith will not suffer too much.
Many others cpus could have a penalty depending on the algo and many other conditions that
would be too long to expose. High Definition will be our worst enemy about memory questions.

Some final words. Communication and collaboration seem to be the most important today.
And not less important please avoid adjectives and sarcasm. Remember that many members of this forum
have not English language as native one and can misunderstood some posts. Anyway I prefer forum discussion than private message or mailing list; many young developers will take advantage of technics posts.
My apologizes for my poor English.

As always I hope this can be usefull.
ARDA

[Guest]

Originally posted by ARDA
Mistakes, maybe, but who hasn't made? Just for the record, I neither designed nor implemented any code that makes the pitch=width assumption. It was all inherited from MPEG2DEC3.

[ARDA]

Originally posted by neuron2
Just for the record, I neither designed nor implemented any code that makes the pitch=width assumption.
It was all inherited from MPEG2DEC3.

I was speaking in a general way, not pointing that; I know perfectly well where many of those inherited problems come from.

A little off topic but I've made a version of Lumafilter which never finished; fixing static global variables which are still present in DGDecode.dll ; plus SSE2 version; plus row loops which avoid problems with frame loops after separatefileds.
Most things I've done are written at top of cpp. Sources and dll included. I've renamed LumaYV12 to avoid conflict names.
In spite of the fact it's not finished, is a usable plugin. If you prefer to include it in DGDecode.dll delete the link.

[IanB]

Wow! Fortunatly most of the issues have been redressed already.

The -8 sets up 8-alignment on the chroma and 16-alignment on the luma under the new beta. Yes this is not as intended, I will fix it.

How expensive are a BlitBit anyway??Consider a blit the fastest filter that works on all planes and doesn't manipulate it's data in place. Many filters that only manipulate 1 or 2 planes and/or manipulate data in place are faster than a blit.

Just to reiterate and put peoples minds at rest. The final release version of 2.5.6 will not change the default alignment. I will continue to explore chroma priority alignment as the default for a while longer because I believe it is very important to get the infrastructure for 128 bit aligned memory access correct, in place and working (just not as default).

And guys please try and keep the strong emotive stuff out of the posts it makes gleening for the technical (important) stuff harder.

IanB

[Guest]

DGMPGDec 1.3.1b5 has a proper pitch fix made by tritical. Please see the beta thread in the DVD2AVI/DGIndex forum.

Feedback will be appreciated there.

Thank you, tritical.

[tsp]

IanB: Could you make the code a little more threadsafe by changing the VideoFrame:: operator new(unsigned) to something like this:

void* VideoFrame::operator new(unsigned) {
// CriticalSection
for (LinkedVideoFrame* i = g_VideoFrame_recycle_bin; i; i = i->next)
if (i->vf.refcount == 0)
{
InterlockedIncrement(&i->vf.refcount);
return &i->vf;
}
LinkedVideoFrame* result = (LinkedVideoFrame*)::operator new(sizeof(LinkedVideoFrame));
result->next = g_VideoFrame_recycle_bin;
g_VideoFrame_recycle_bin = result;
return &result->vf;
}

and the VideoFrame constructor to something like this:

VideoFrame::VideoFrame(VideoFrameBuffer* _vfb, int _offset, int _pitch, int _row_size, int _height)
: vfb(_vfb), offset(_offset), pitch(_pitch), row_size(_row_size), height(_height),offsetU(_offset),offsetV(_offset),pitchUV(0) // PitchUV=0 so this doesn't take up additional space
{
InterlockedIncrement(&vfb->refcount);
InterlockedExchange(&refcount,0);
}

VideoFrame::VideoFrame(VideoFrameBuffer* _vfb, int _offset, int _pitch, int _row_size, int _height, int _offsetU, int _offsetV, int _pitchUV)
: vfb(_vfb), offset(_offset), pitch(_pitch), row_size(_row_size), height(_height),offsetU(_offsetU),offsetV(_offsetV),pitchUV(_pitchUV)
{
InterlockedIncrement(&vfb->refcount);
InterlockedExchange(&refcount,0);
}

It would be better if refcount was initialized to 1 and cache, ScriptEnviroment::MakeWritable, ScriptEnviroment::NewVideoFrame, ScriptEnviroment::Subframe VideoFrame::SubFrame decreased refcount by 1(to 0) just before returning the frame to PVideoFrame

[IanB]

tsp,

Perhaps you can elaborate on your scenario for thread unsafeness.

In my few minutes thinking about it I agree the code is thread unsafe (lots of AVS is) and the scenario I foresee is 2 threads scaning the freelist together, both grab the same VideoFrame and set about using it, screwing each other in the process. And the window is quite wide, the VideoFrame is "free" until a PVideoFrame eventually does an AddRef(). Your proposed solution does not resolve this conflict, the "InterlockedExchange(&refcount,0)" effectively make it free again.

I assume therefore you have another conflict in mind.

To resolve my scenario VideoFrame's need more carefull management of the free list. Something along the lines of find a candidate, Interlocked increment refcount, take it off the free list, check to see if we got it to ourself (i.e. refcount==1) if okay use it, else do recovery and restart scan for another candidate. Possibly there needs to be some other locking as well.

This subject kinda warrants it's own thread. It's a can of worms.

IanB

[tsp]

This subject kinda warrants it's own thread. It's a can of worms.


the discussion will continue in this thread: http://forum.doom9.org/showthread.php?t=95596

[Guest]

@IanB

Are you aware of the corruption issue with 2.56 discussed here:

http://forum.doom9.org/showthread.php?p=676095#post676089

Falling back to 2.55 solved the problem.

[LigH]

Yes, the HC encoder showed the (AFAIR) "usual" pitch shift - diagonal green lines running through the heavily slanted video.

(See attachment.)

[Guest]

So somebody should inform Hank about this.

[LigH]

hank315 knows it - I did betatests on Windows 2000 for him.

[trevlac]

AviSynth 2.5.6 beta 3 Release (May 5th):

additions:
- Added offsets, gamma and analyze option (ala ColorYUV) in RGBAdjust.


Are the Gamma options in beta 3 ??

I tried all sorts of ways to get RGBAdjust to accept a gg parm, but no luck. I see IanB's code in the CVS ... but I can't get it to work in the build.

BTW: I thought this was a nice addition. I'm not sure of another way to adjust the gamma of each channel seperately. :)

[IanB]

@Neuron2,

Yep, is broken -ve forced pitch option stuffing up DirectShowSource(), fixed.

@trevlac,

From the CVS log Thu May 5 06:20:59 2005 UTC (6 weeks, 6 days ago) by ianb so it probably missed out by a whisker.

IanB

[LigH]

I don't mean to urge - just for curiousity:

Are there still many open issues to solve until the next 2.5.6 beta/RC?

[Wilbert]

1) There's one issue with audio, asf and DirectShowSource. I will report about it here.

2) Another (audio, x264 and DSS) issue which needs to be checked: http://forum.doom9.org/showthread.php?t=96708

Other than that, i'm not sure.

[Wilbert]

AviSynth 2.5.6 beta 4 Release (July 10th):

additions:
- Added DevIL support for RGB32 to ImageSource.
- Added Russian language documentation. Thanks to Fizick and his team. Well done.
- Added Merge() filter. Includes very fast iSSE pavgb code for weight=0.5.
- Added MergeARGB(), MergeRGB() filter.
- Added ShowRed(), ShowGreen(), ShowBlue() filters.
- Added Planar version of env->SubFrame() (thanks TSP).
- Added SetPlanarLegacyAlignment() to select Planar alignment algorithm.
- Added Audio padding control to Trim().
- Added operator MulDiv(multiplicand, multiplier, divisor).
- Added AssumeScaledFPS(multiplier, divisor, sync_audio) maps vi.MulDivFPS.

fixes:
- Fixed 2 bit crosstalk in YUV horizontal resizers, thanks Squid.
- Fixed resource leak in DirectShowSource(), thanks Tritical.
- Fixed minor memory leak in Subtitle() and string(), thanks Tritical.
- Fixed global clip close down problem, thanks Tritical.
- Uninstaller now remove Docs\pictures directory and DirectShowSource and TCPDeliver plugins.
- Fixed ImageReader single file handling.
- Fixed ImageWriter info==false no longer write status text onto frame.
- Trap .WAV clsid handler GPF with filenames gt 47 chars.
- Fixed YUV text access violation, correct bounds alignment tests. (Regression)
- Fixed ExpFunctionCall::Call memory leak, thanks Tritical.
- Fixed PClip leak in MergeChannels(). Destructor chain not called.
- Fixed RGB text alignment inversion. Regression in May 5th ver.
- Fixed vfw resource leaks when opening bad AVI files.
- Fixed rmvb (dss.dll) stuck at 100% during encoding (thx stevencover).
- Fixed Loop audio processing.
- Fixed GeneralConvolution crash with cropped input.
- Restored forced (negative) planar luma alignment functionality.
- Fixed a stack of memory leaks, thanks Tritical.
- Fixed Direct AVISource input of raw YV12 and I420 sources.
- Fixed (fingers crossed) "Evaluate: Recognized exception!" Problems with XPsp2 hard terminate.
- Fixed CACHE_RANGE internal scope test, thanks Tritical.
- Fixed Mask() calc of greyscale, red/blue swapped.

optimizations:
- Run sort -unique|detab on color_rgb.avsi, got rid of all the duplicates.
- YV12 MergeLuma(), MergeChroma() include very fast iSSE pavgb code for weight=0.5.
- Cleanup VideoFrame garbage collection on script close (Thanks TSP).

changes:
- New improved cache!
- Uninstaller now deletes DirectShowSource.dll and TCPDeliver.dll from plugin directory.
- ImageReader doesn't auto fail over to DevIL for DIB/BMP type files. (DevIL crashs on palletted BMPs.)
- ImageWriter now throws an exception for non RGB24 format with DevIL? processing.
- ImageReader/Writer info text colour now pale yellow $f0f080.
- Replaced VideoFrame::SubFrame() with env->SubFrame() (Ready for MultiThreading, Thanks TSP).

As usual download from Sourceforge (http://sourceforge.net/projects/avisynth2/).

PS, this will probably be the last beta :)

[tritical]

A little report on the new cache... it seems to be treating the frame_range that is given for CACHE_RANGE as a diameter instead of a radius. Changing line 731 to if (frame_range*2 + 1 <= h_span) // Use the largest size when we have multiple clients and adding inh_span = h_span*2 + 1; after line 737 seems to make it work as expected. Hopefully IanB can report on the behavior. Also, just wondering where did the MAX_CACHE_RANGE limit of 21 come from? What should one do if a filter could require a larger range than that? just use the default CACHE_ALL?

[IanB]

@Tritical,

Yes I am in rather a quandry about h_span definition, the only internal example of CACHE_RANGE use is TemporalSoften and it uses the parameter as a diameter, probably because the range expunge code previously was wrong. I did a search here and in google generally, and I got nothing definitive. The implication was that it is a radius, but because of the previous bug it has mostly been used used as a diameter (except by you :D ) and as a diameter it has slightly finer control.

As for the limit I thought +/-11 frames was pretty generous, I can easily be convinced to make it higher.

Anyhow I have erred on the side of safety. Where it is to small it will give the new heuristic Frame locker a good workout. In many case CACHE_RANGE should be redundant.

Thorts?
IanB

[tritical]

Having it be a diameter is no problem as long as it is clearly stated as such. Since there has been a lot of ambiguity due to it always being mentioned as a radius but, due to the bug, never actually working that way, I think a clear definition of which it is would be good. Also, having it be a diameter now would insure that filters calling it with that convention wouldn't have unnecessary slowdowns with older avisynth versions (as some of my filters do atm).

On the limit, I was mainly worried because I saw unexpected behavior when using a CACHE_RANGE that was too small, but after looking at it some more it does eventually work itself out after cache_limit increases enough that it starts promoting frames. Out of curiosity, what is the cost of calling env->ManageCache(MC_PromoteVideoFrameBuffer, result->vfb) on all frames generated in the cache regardless of h_span? Or in other words, how much is the gain from not calling it on frames that will be protected?

[LigH]

According to katjarella, HC encoder works well with AviSynth 2.56 b4:

Example picture (http://katjarella.gleitz.info/sub/hc15beta.jpg)

[IanB]

@LigH,

Damn! Thanks for the prompt. The planar alignment issue got missed in the notes.

@All,

** In this release the default alignment for planar images is back as it has always been, 16 Luma, 8 Chroma. **

So all that naughty code out there that assumes a relationship between width and pitch will work again. To test any pluggins with the upcoming SSE2 optimized alignment put a SetPlanarLegacyAlignment(False) at the end of the script.


Having it be a diameter is no problem as long as it is clearly stated as such....Thats where the quandry came from, no clear statement, just vague inuendo. Okay I guess we need a list of all the places people know this issue is alluded to. I still need to do a cleanup pass on the source after any bugs have been shaken out and a nice comment block can be part of that as a start.

On the limit, I was mainly worried because I saw unexpected behavior when using a CACHE_RANGE that was too small,...Previously if the range was to small you effectivly got no cacheing, all the frames got purged as it thrashed thru the list each time and there was no tracking of frames in the pool. Now frames in the range are protected from reuse, other frames take there chances in the pool, so getting it wrong is not that serious anymore. And there is a fairly high price to the LRU pool for giving to many frames protection.

Out of curiosity, what is the cost of calling env->ManageCache(MC_PromoteVideoFrameBuffer, result->vfb) on all frames generated in the cache regardless of h_span? Or in other words, how much is the gain from not calling it on frames that will be protected?The cost per say is negligable. The issue is that frames with protection don't need to take there chance in the LRU pool with other frames and as such I don't promote them so they don't flush other frames competing for normal cacheing. Only when there is a chance that LRU pool caching will help do frames get "promoted". So I guess the gain is improved caching for regular frames.

IanB

[yaz]

thx for the improvements !!!

anyway, would some mod fit the header of the thread to the new release, pls ! (it still refers to b3, may 6)

thx
y

[azsd]

some scripts get 2fps encode speed with 2.5.6 b4....
if replaced the avisynth to b3 or other CVS (16 align) build,the render speed should be about 18fps.
I don't konw is it caused by witch filter,if commented the FluxSmoothST line then speed resumed,but In my option is caused by avisynth.dll

video = DirectShowSource("[FREEWIND][Stand_Alone_Complex_2nd_GIG][DVDRIP][H.264_DD][05].avi", audio=false)
audio = DirectShowSource("vol05.wav")

video = ChangeFPS(video, 19.98)

main = video

main = FluxSmoothST(main, 8, 3)
main = deen(main, "a2d", 1, 8, 12, 3)
main = aWarpSharp(main, 2.5, 2, 0.30, 1)

video = main

video = TextSub(video, "[FREEWIND][Stand_Alone_Complex_2nd_GIG][DVDRIP][H.264_DD][05].tc[M2].ass")

video = LanczosResize(video, 368, 208)

video = Tweak(video, 0, 1.01, -2, 1.025, true)

video = AudioDub(video, audio)

return video

[IanB]

azsd,

Does this simplified script show the problem?main = DirectShowSource("blah.avi", audio=false)

main = FluxSmoothST(main, 8, 3)
main = deen(main, "a2d", 1, 8, 12, 3)

return main

Does the script start fast then go slow after about 100 frame?

Does left arrowing the script back to the start then trying again make the problem go away?

Anyone got a url for the source to FluxSmooth?

Anyone make this script break with a debug version?

IanB

[azsd]

yes,the scrollbar slow down at the frame last time backward from.

the FluxSmooth 1.1a src avaliable here:

hxxp://www.indeus.com/sansgrip/avisynth/

mmm...

It looks like authors webpage moved now,
I had make a mirror here:
hxxp://my1993.com/downloads/source/sansgrip/FluxSmooth-1.1a_src.zip
(same as 0729 build on WarpEnterise collection page)

[LigH]

Why do you mask your links?

[azsd]

lots of anime forums I was daily visted has the rule "don't post direct link" (as manners because direct links will caught by google may cause some ISP block that homepage account.)
so I developed a habit for their recommend _http/hxxp url.

[IanB]

axsd,

Oops looks like I lost a line of code. Try this replacment avisynth.dll (http://avisynth2.sourceforge.net/14Jul2005/avisynth.dll), just replace the one in your windows system directory.

IanB

[azsd]

tested.
parse speed get allright now.

thx IanB!

[Zarxrax]

I believe I have found a bug in the Normalize() filter.
If you do something like DirectShowSource("file.avi").Normalize() then the audio output will be silent. If you do Avisource("file.avi"), or DirectShowSource("file.mpg") then it works fine. Seems to be an issue with loading avi through directshowsource.

[azsd]

I have same slient result with load some mp2 files with DirectShowSource() .
the problem is reproduce,but occured with special audio file,not all audio clip failed in normalize,it may cause by you audio content in your avi between mpg,or matrix mixer pluged in dshow graphic but not in vfw render path.

[IanB]

Do a Normalize(show=true).Info()

1. What is the calculated normalizing factor.
2. What is the peaks frame number.
3. What is the audio sample type.
4. What is the total frame count.

IanB

P.S. Is the audio codec being used capable of seeking? If it cannot then this is the expected behaviour. Normalize reads all the audio samples looking for the maximum value then tries to seek back to the begining, if seeking is not supported DSS just returns silence.

[Zarxrax]

Amplify Factor: 1.1262
Amplify DB: 1.0323
At frame: 383

Sample Type: Integer 16 bit
Total Frame Count: 650
Audio Codec: PCM

[IanB]

It's DirectShowSource() bug:- Reading the very end of the audio stream sets the internal "end_of_stream" flag. The read code checks this on entry and bails when it's set. Nothing ever resets this flag. Fix coming slowly :(

IanB

Edit: After hitting the end of the stream, and seeking back to the begining the stream does not render correctly, it sort of has jitter between the returned block of samples. :mad: Much research required....

[Wilbert]

bug-report: http://forum.doom9.org/showthread.php?p=687962#post687962

The script crashes (ie VDub just quits when loading the script) with v2.56b3 and beyond.

[IanB]

Wilbert,

Was stack overflow from Invoke, fix in CVS, see .../core/avisynth.cpp v1.25

IanB

[Zarxrax]

It's DirectShowSource() bug:- Reading the very end of the audio stream sets the internal "end_of_stream" flag. The read code checks this on entry and bails when it's set. Nothing ever resets this flag. Fix coming slowly :(


IanB

Edit: After hitting the end of the stream, and seeking back to the begining the stream does not render correctly, it sort of has jitter between the returned block of samples. :mad: Much research required....

Sorry to trouble you more, but I have come across a few files that also don't return any audio after using normalize while using Avisource(), so perhaps this is a problem in avisource too. One of the files used ADPCM codec, the other is MP3.

[tritical]

I noticed that with avisource as well. It's because fZeroRead gets set and is never reset. Also, with the directshowsource fix, wouldn't it be better to be setting end_of_stream=false before calling StartGraph() at the end of the seek method? Otherwise, it just sits there until startgraphs WaitForSingleObject call times out because receive returns immediately while end_of_stream is still set to true and it never sets the event... at least that is what happens on my comp.

Also, there seems to be a typo in avisynth_c.h. Two lines at the beginning use "ACSC_USE_STDCALL" while throughout the rest of avisynth_c.h and avisynth_c.cpp it is checking "#ifndef AVSC_USE_STDCALL" notice the C and V switch. I think this was pointed out once in an old thread but it is still there. Or is it really suppose to be that way for some odd reason :D?

[IanB]

Not sure what to do about these stuffed ACM (and DirectShow) codecs. I tried a simple cheat in Normalize() of not getting the last sample, but it doesn't help, you have to avoid having the codec access and decode the last segment. This can mean stopping a few 10,000 samples before the end for a codec with good compression. :eek:

May be a float option specifying seconds from the the end to stop the pass 1 scan, but this is horribly ugly and cludgey. :scared:

Thorts anybody? :confused:

@tritical,

fZeroRead good observation.

Before StartGraph() make sense.

"A[CV]SC_USE_STDCALL" hmmm it's certainly confusing but changing it will change the entrypoint name it searches for. :(

ACSC_USE_STDCALL is defined, so AVSC_CC = "__stdcall"

AVSC_USE_STDCALL is not, so entrypoint is "avisynth_c_plugin_init"

Guess we need to survey the C pluggins and see whats being done.

Never just rains but it sure does pour. :mad:

IanB

[cweb]

Is using avisource safe in this version, if you don't do a Normalize?

[IanB]

It should be no different to previous version regarding the audio source statements, (I haven't worked on them, yet). As far as I can tell they have always been broken after accessing the end of the stream in some mode or other.

Normalize has been given a full rework, so now surely trips up the other latent bug. But now it will correctly normalize all formats and channels. Previously it only normalized 1/(number of channels) of the data, hence only tripped the bug for mono audio.

As a work around, run Normalize(show=true) and then edit your script to use Amplify(number displayed), this also has the benefit of not having to reparse the audio track every time you reload the script, it can take several minutes.

IanB

[Zarxrax]

Normalize has been given a full rework, so now surely trips up the other latent bug. But now it will correctly normalize all formats and channels. Previously it only normalized 1/(number of channels) of the data, hence only tripped the bug for mono audio.

IanB

Does this mean that for stereo tracks, normalize is silencing one channel and leaving only mono audio? Or does it leave both channels intact?
I ask because I'm currently working on a project intended for public viewing which involves nearly 400 video clips, each with their own avisynth script using the normalize function, so I can't really afford to be screwing up all the audio.

[IanB]

@Zarxrax,

No, on the sampling pass it only looked at 1/n samples, hence possibly/probably missed the highest peak. On the amplify pass it processed all the data in all the channels but possibly using the wrong factor. If you are interested have a look at the CVS diffs for audio.cpp

IanB

[Fizick]

return to cache_range question.
What i must set in plugin for pure spatial processing:
child->SetCacheHints(CACHE_RANGE, 0);
or
child->SetCacheHints(CACHE_RANGE, 1);
or
child->SetCacheHints(CACHE_NOTHING, 0);
or
nothing ?

and what for temporal procesing (use prev, cur, next frames):
child->SetCacheHints(CACHE_RANGE, 3); ?

[IanB]

@Fizick,

For pure spatial processing do nothing, the default is optimized for this case. Only diagnostic filters like the time measuring ones should ever use CACHE_NOTHING. Remember the case in scripts with 2+ filters attaching to 1 other filter.

The CACHE_RANGE value is currently a diameter to match the behaviour of previous AVS versions, so 3 is the right value. Around post #170 (http://forum.doom9.org/showthread.php?p=685179#post685179) tritical and myself briefly discussed the issue, it is still unresolved, please express your (and everybody else) thoughts on the matter.

IanB

[Fizick]

Of course, i read your discussion with Tritical.
O.K., here is my thoughts.
1. For pure spatial we must use child->SetCacheHints(CACHE_RANGE, 0);
Almost all old spatial filters use this settings.
2. Yes, i suspect of some old bug with cache.
Firstly I set CACHE_RANGE to radius (in old avisynth versions). But later i discover, that the speed of my temporal filters was decresead. So, I usually experimentally increase the range to increase the speed. So, now i understand, that i empirically use it as diameter. But some my filters probably use not optimal setting. Degrainmedian and DeSpot use range=2, because of range=1 result in slowdown (probably 3 will better for prev, currennt and next frame?) But in DePan I increased it some more (reserve). :)
IMHO, old avisynth (2.5.5) do not strictly consider cache range as diameter,
it was some mix (bugs).
So, It is really not easy issue.
Of course, i can recompile my plugins.
IMHO, the most important problem is not using new plugins in old avisynth versions,
but using old plugins in new avisynth.
However, if new cache strategy is more tolerant to wrong cache range setting,
it is not issue.
So, we must test new super-cache strategy.
But when I look to cache.cpp in CVS, i see that all cache_range code is disabled (commented), and some debug messages is there.
Is it the same code as in 2.5.6beta4 ?
4. sorry for my long and stange post.
Can we

[IanB]

1. For pure spatial we must use child->SetCacheHints(CACHE_RANGE, 0);
Almost all old spatial filters use this settings.You should not do this, this is very bad, particularly for the older AVS versions, the new cache is somewhat defensive about this but not completely immune.V1=AviSource("blah.avi")
V2=V1.SomeFilter() # This is a bad filter, it does (CACHE_RANGE, 0)
V3=V1.OtherFilter() # Because of the above all frames must be built
ThirdFilter(V2, V3) # at least 2 timesI have thought about catching crazy Hint settings, my initial cut is to just nail excessive values but I can see I should also defend against uselessly low values as well. For all AVS versions in general non-temporal filters should not play with the cache hinting. Doing nothing says I am a normal spacial domain only filter.2. Yes, i suspect of some old bug with cache.
Firstly I ... experimentally increase the range to increase the speed. So, now i understand, that i empirically use it as diameter. But some my filters probably use not optimal setting. Degrainmedian and DeSpot use range=2, because of range=1 result in slowdown (probably 3 will better for prev, current and next frame?) But in DePan I increased it some more (reserve). :) Practically it turns out to be Diameter. For the classic "Prev, Current and Next" case a range of 2 is appropriate if the filter askes for the frames in the right order, i.e. Prev (last current), Current (last next) and the Next (built a new, trashes prev). If you ask for Next 1st then you need a range of 3 and of course the user can always use the Reverse() filter which inverts the above argument, so you should probably use 3.So, It is really not easy issue.Amen! Keeping consistancy of interface make things like this very difficult ;) Of course, i can recompile my plugins.This generally won't help much, the problems are in the various versions of AviSynth.Dll, but fixes like range from 2 to 3 can't hurt.IMHO, the most important problem is not using new plugins in old avisynth versions,
but using old plugins in new avisynth.
However, if new cache strategy is more tolerant to wrong cache range setting,
it is not issue.Hence the ultimate decission to go with Diameter. This make all filters old and new as consistant as possible across all AVS versions.So, we must test new super-cache strategy. But when I look to cache.cpp in CVS, i see that all cache_range code is disabled (commented), and some debug messages is there. Is it the same code as in 2.5.6beta4 ?Testing, now there is a really good idea ;) and of course reporting. :D

The cache_range functionality (protected VFB's) is folded into the main code now, the old code, commented out, is for reference so as problems or short commings get reported I can compare easily old and new code. I will probably delete it in the final released version of 2.56.

IanB