How to refresh output/clear the cache

[fvisagie]

EDIT: Changed title to better reflect use case (use case more fully explained in post #7 below).

I'm trying to automatically refresh a potentially stale display. Ideally that would be done in a user function but so far I've been unable to successfully call Echo() that way.

For example, this works
function Refresh(clip c) {
Echo(c)
}

BlankClip()
Subtitle("Hello, World!")
Echo(last)

but replacing 'Echo' with 'Refresh' produces
Script error: Invalid arguments to function "Echo"
(New File (1), line 2)
(New File (1), line 9)

Any ideas as to why and how to work around it?

Thanks in advance,
Francois

[StainlessS]

You need at least two clip args to Echo.


Echo (clip1, clip2 [, ...] )

Echo forces getframe accesses to all the input clips. The results from clip2 and up are discarded. The result from clip1 is returned.

This may be useful forcing alternate script paths with ImageWriter and Writefile.


inside square brackets indicates optional.

RT_Graphlink() preceded Echo, and although not exactly the same, may clarify usage.

RT_GraphLink(clip source, clip c1, ... , clip cn, bool b1, ... , bool bn)
Standard filter function. Roughly equivalent to "Echo()" in 2.6a4
This function is a standard filter graph function, not a runtime/compile time function.
It takes a compulsory source clip which it will return unchanged.
The clips, c1 to cn (one or more, at least one of them) are by default forcibly linked into
the filter graph. The bools b1 to bn are optional (zero or more) and would default to True
if not supplied. These bools will if false, switch OFF the forcible linking into the filter graph
for the corresponding clip c1 to cn.
Avisynth does not normally process any filter chains that do not contribute to the output clip,
this filter allows you to select graph chains that you wish to forcibly process.
The usual way to force process an unused chain is to do a StackHorizontal/Vertical and then crop it off again.
The forced clips should all be same length as the source clip (but no error if not), only frame numbers contained
in both source and forced clips will be forcibly accessed when frame n of source clip is accessed.
All args un-named.
Example: [will only render the TestA" and TestC images]
a=ImageSource("d:\avs\1.jpg",end=0) # Single frame
TmpA = a.subtitle("TestA").ImageWriter("d:\avs\TestA_", type="png") # Written
TmpB = a.subtitle("TestB").ImageWriter("d:\avs\TestB_", type="png") # Skipped
TmpC = a.subtitle("TestC").ImageWriter("d:\avs\TestC_", type="png") # Written
RT_GraphLink(a,TmpA,TmpB,TmpC,True,false) # 3rd bool defaults true
return Last


EDIT:
I'm trying to automatically refresh a potentially stale display.

That dont make much sense to me, but I think that Echo is not intended for what you think it is.

[foxyshadis]

In Avisynth, all filters like "Filter(...)" are automatically translated to "Filter(last,...)" if not enough clip arguments are provided and last is defined. Since Echo requires two and is only given one, it's translated to "Echo(last,last)" outside the function, except that in your function, it fails when there is no last. Echo(c,c) would work, but wouldn't really make any sense, like StainlessS points out.

[fvisagie]

Tsk, me not reading the documentation properly, again! Thanks, people.

[fvisagie]

I think that Echo is not intended for what you think it is.

Now that I understand the use of Echo(), I can confirm that you're right. Is there a way of forcing a refresh from source?

[StainlessS]

Not sure that I understand the reason for the refresh.
What are you using to view the source ?
why do you think it needs a refresh ?
(and by the way, there is also a runtime version of RT_Graphlink called RT_YankChain which you can specify the frame number to 'yank').

EDIT: In VirtualDubMod the F5 key refreshes display (reopens and jumps back to the same frame).

[fvisagie]

Not so easy for me to put into words, but I'll try to explain.

Runtime scripts each printing information on its associated clip while analysing video in AvsPmod. The purpose of the printed information - which includes SMPTE - is to assist with tracking and time-synchronising hundreds of little clips during editing. A per-frame active clip counter is incremented by the runtime scripts and used to stack print-outs when multiple clips contribute to the output frame. When scrolling backwards the situation can arise where some clips are produced from source and some from cache. Runtime scripts for clips produced from cache won't be invoked then. The active clip counter will be wrong but will be used by clips produced from source. In all cases where at least one clip is produced from source the output runtime script will also be invoked, and can detect backward motion and for convenience automatically refresh all clips if the latter were possible.

I'll look into RT_YankChain and also the feasability of assigning each clip print-out its own dedicated display position, which idea I already don't like much!

[StainlessS]

What might work would be a function to ClearCache(), but not aware of anything that could do that.

RT_YankChain would not help if cache were the problem, would just get from cache.

[fvisagie]

RT_YankChain would not help if cache were the problem, would just get from cache.

Thanks for saving me the trouble.

[raffriff42]

What might work would be a function to ClearCache(), but not aware of anything that could do that.This function is hypothetical then? (Google says yes)

I understand it's impossible to disable the cache system, is that right?

What about overwhelming the cache with nonrelevant frames, forcing all old versions of the frame we want to 'refresh' out of the cache? (How would that even work?)

[StainlessS]

"hypothetical", sadly, yep.

Gavino gave this to disable cache in v2.6.

function Cache(clip c) { return c }

http://forum.doom9.org/showthread.php?p=1684143#post1684143


Script functions override built-ins.

[raffriff42]

function Cache(clip c) { return c }fvisagie, I think you have your answer!

(no wait, "return c" will return the cached version of c, will it not?)

[StainlessS]

Nope, I think Cache() adds a cache to the downstream side of c, so the script version, dont add a cache to the etc.

[fvisagie]

I understand it's impossible to disable the cache system, is that right?

Although it's possible in 2.6 as StainlessS explained, for performance reasons I'd prefer only an occasional on-demand cache purge.

What about overwhelming the cache with nonrelevant frames, forcing all old versions of the frame we want to 'refresh' out of the cache? (How would that even work?)

I'd considered that, and what counts against it so far is that the approach is non-deterministic and may introduce a double performance hit. To determine how many frames would overwhelm it, one would need to take into account cache size and cache memory consumed per frame used in over-filling, the latter probably governed mostly by resolution and colour depth. The double performance hit would result from clearing the (unwanted) cache, then over-filling it with more unwanted content, then having it again partially cleared and updated with desired content.

The hypothetical ClearCache() would be just perfect ;).

[raffriff42]

In your use case (rewinding a script with multiple runtime elements), I think any ClearCache() would be non-deterministic as well.

Suggest you dub off your script in forward-only mode to a lossless intermediate, then do your seeking etc with that.

[fvisagie]

In your use case (rewinding a script with multiple runtime elements), I think any ClearCache() would be non-deterministic as well.

I'm unsure what you mean by non-deterministic in this sense, but the approach outlined in post #7 does work. If all needed frames are cached when rewinding, no problem - the information printed on cached frames will display correctly. If any frames are produced from source, I've confirmed that the script can detect the condition of Rewinding AND Some_frames_being_fetched_from_source. All that remains to be done is to then clear the cache forcing a refresh (of all input clips, but that does not matter).

Suggest you dub off your script in forward-only mode to a lossless intermediate, then do your seeking etc with that.

Unfortunately the problem would just move to any rewinding done in the intermediate. The per-frame information printed by Avisynth is needed for analysis, so the intermediate would still need to be run through the analysis script.

EDIT 1: I'd misunderstood you here. What you suggest would work, of course. However, that would feel like giving up to me, having been overcome by the challenge of overcoming this problem at its root ;).

EDIT 2: Upon further reflection, although what you suggest is possible, it won't be all that practical in this case. The purpose of the printed information - which includes SMPTE - is to assist with tracking and time-synchronising hundreds of little clips during editing. Using intermediates would require loading the set of originals into the analysis script, creating a set of intermediates, loading the intermediates into and completing the editing script, and finally replacing in the editing script the intermediates with the originals. This entails much manual matching up and much scope for error. Of course, all of this is further complicated by the fact that Avisynth doesn't really load hundreds of clips in one go, although that's an (almost) orthogonal issue.